Ai

一、科学上网 我自己用了 4 年的机场: https://0522.ppg02-mqelltoq.top/#/register?code=vNYrOFMX 机场域名偶尔会换,记得收藏里面的链接发布地址 二、账号注册与订阅 OpenAI、Claude 注册、订阅需要短信验证和国外信用卡支付。 临时接码平台: https://hero-sms.com/?ref=1128898 代充订阅、合租、国外手机号: https://bewild.ai?code=PH5MIFSB 三、AI 工具使用方式 基本上所有 AI 平台都提供以下入口: 网页端 桌面 / 移动端 App 命令行工具(CLI) IDE 插件(VS Code、JetBrains 等) 随手问答用网页或手机App,写代码用桌面APP，CLI 或 IDE 插件。 四、博主推荐 B 站 马克的技术工作坊 布鲁歇一歇 王自如 AI 公众号 花叔 数字生命卡兹克 AIArtWorks 刘润 五、最简配置:CLAUDE.md 四原则 在项目根目录放一个 CLAUDE.md,Claude Code 启动时会自动加载。内容就这四条(源自 forrestchang/andrej-karpathy-skills,GitHub 22 万 star): 先想清楚再动手——不臆测;不确定就问;存在多种解读时摆到台面上,不默默选;权衡讲清楚 简单优先——解决问题所需的最少代码;不做预判性设计;不加未被要求的灵活性;不为不可能发生的场景写错误处理 外科手术式改动——只碰必须碰的;不"顺手优化"周边;匹配现有风格;只清理本次改动制造的孤儿(import / 变量 / 函数),不静默删改动前就存在的死代码 以目标驱动执行——把任务转为可验证目标(“修 bug” = “写复现测试 → 让它通过”);多步任务先给简短计划(步骤 → 验证点) Codex 用户把同样内容存为 AGENTS.md 即可。 ...

任务类型 工具 / 模型 说明 / 能力边界 成本 厂商 文档整理 / 项目重构 / 架构设计 Claude Code（基于 Claude Opus） 高质量理解长上下文，支持跨文件重构和工程分析；生成方案/代码，但需要外部环境执行 pro订阅 claude 写代码 / 单文件实现 OpenAI Codex（GPT-Code 系列） 自动生成可运行代码，适合函数、模块、脚本任务；执行依赖你的环境或接口 plus订阅 openAi 实时代码辅助 / IDE 提示 GitHub Copilot IDE 插件，提供智能补全和片段建议，不提供 API 对话 / 问答 /策略讨论 ChatGPT Plus 快速交互、概念解释、方案讨论 plus订阅 openAi 机械重复 / 简单批处理任务 国内轻量模型 低成本处理大量重复操作或简单格式化任务 miniMax 自动化执行 / 跨渠道智能代理 OpenClaw 可自托管的 AI Agent 框架；整合多模型、消息渠道和技能；能持续管理任务、执行脚本、调用 API 和操作工具；适合自动化工作流和多通道触发，需配置和监管

这两年，AI技术越来越成熟，在很多场景上给不同的岗位提供了大量的生产力。 但是作为数据行业从业人员，其中有个场景我想泼一下冷水。 比如被讲得很热的ChatSQL。 接个大模型，挂上数据库，做个对话框，让业务一句话取数，仿佛传统 BI 的门槛一下子就要被抹平。 这种想象不是完全没有根据。只要场景足够干净，问题足够标准，今天的模型确实已经能生成一段相当像样的 SQL，甚至把结果也答得像模像样。 但我对 ChatSQL 的判断一直比较克制。不是因为它没用，而是因为它在企业里真正要解决的，从来都不是"写出一条 SQL"这么简单。 一，ChatSQL 最难的不是生成，而是语义 很多人第一反应是：模型还不够强，等下一代就好了。 这个判断的问题在于，它把 ChatSQL 的核心难点理解成了生成能力。 可在企业环境里，模型最先撞墙的地方往往不是不会写 SQL，而是不知道你们公司到底在说什么。 “活跃客户"怎么算？ “新增付费用户"包不包含试用转正？ “业绩下滑"看收入、利润，还是回款？ 这些问题本质上都不是自然语言理解问题，而是业务语义问题。模型可以把一句话翻成查询，但它翻不了一家企业内部本来就没有统一好的口径。 所以 ChatSQL 如果一上来就做成"人话转 SQL”，最后大概率不是输在模型，而是输在语义基础太薄。 二，语义层很重要，但它不是银弹 讲到这里，很多团队会自然转向另一个答案：那就建语义层。 这个方向没错，但也很容易被误解。 语义层的价值在于，把常见指标、维度、实体关系和口径规则结构化，让模型不必每次从数据库字段里重新猜业务世界。没有这层东西，系统几乎很难稳定。 但语义层本身不是一个轻巧组件，它更像是一种治理成果的交付形式。 换句话说，语义层不是补丁，而是地基的外化。 如果企业本来就没有统一指标、没有稳定口径、没有明确的责任边界，那语义层也只是把混乱包了一层更漂亮的壳。它让问题显得更工程化，但并不会自动把问题解决。 所以我更愿意把它理解成入场券，而不是终局方案。没有它，很难上线；只有它，也过不了关。 三，Demo 证明不了产品成立 ChatSQL 最容易骗人的地方，就是 Demo 总是很好看。 因为 Demo 里的问题通常都被精心挑过：定义清楚，范围有限，口径提前对齐，数据表也知道该怎么连。这样的条件下，模型表现出色并不奇怪。 但产品成立的标准完全不是这个。 真正的用户问题通常带着模糊、跳跃和上下文缺失。很多人问的不是一个可以直接翻译的问题，而是一个需要先被澄清的问题。 比如：“最近业绩下滑的团队有哪些？” 一个靠谱的分析师听到这句话，第一反应不会是立刻写 SQL，而是先追问。最近是多久，业绩看什么，下滑按什么基线，异常值要不要去掉，外包团队算不算。 也就是说，真实分析过程本来就不是一次翻译，而是一段澄清和收敛的过程。 而大多数 ChatSQL 产品，目前只接住了"生成查询"这一步，却没有接住分析师原本承担的职责：澄清、解释、回退、修正、多轮一致性。 所以 Demo 证明的是模型有翻译能力，不等于产品已经具备交付能力。 四，ChatSQL 最脆弱的地方是信任，不是准确率均值 很多讨论喜欢问：“准确率做到 80% 多，能不能上线？” 这个问题本身问得就有点偏。 如果 ChatSQL 只是给分析师自己做探索，用来找方向、提假设、少写点重复 SQL，那么它不需要像财务系统一样严苛。因为分析师本身有判断力，答偏了也知道怎么纠回来。 但如果它要直接进入经营分析、财务对账、审计追责这种高责任场景，标准就完全不同了。 这些场景里，决定系统能不能活下来的，不是平均准确率，而是关键问题能不能稳定答对，答错了能不能被及时发现，发现之后能不能追溯。 因为用户对这类系统的信任建立得很慢，崩塌得却很快。十次答对未必能让人真正依赖它，但一次关键错误，足以让整个部门彻底弃用。 ...

你现在是一个软件工程师助手，需要与我协作完成开发任务。 请严格遵守以下流程： 【阶段一：分析与方案】 不要直接修改代码 先完整理解需求和现有代码结构 给出一个详细的实现方案，包括： 修改哪些文件 每一步要做什么 可能的风险点 是否有更优方案（如有请说明） 输出清晰的分步骤计划（Step 1, Step 2, …） 完成后，停止执行，等待我的确认。 【阶段二：执行（必须等我确认后）】 严格按照确认的步骤逐步执行 每执行一步都需要： 说明本步做了什么 展示具体代码改动（diff） 不要一次性完成所有步骤 【约束规则】 不允许跳过方案阶段 不允许一次性修改多个步骤 不允许未经确认直接改代码 如果发现方案需要调整，必须重新提出方案并等待确认 【输出要求】 结构清晰，步骤编号明确 解释要简洁但完整