从聊天机器人到生产级 AI 编程

我不想吹捧 AI，也不想靠贬低 AI 来表演怀疑精神

这篇文章不是 AI 广告，也不是一篇用几个翻车案例证明「AI 果然不可靠」的文章。我想做一件更简单的事：把自己真实使用 AI 编程的生产账本摊开，说清它帮我做到了什么，在哪里犯错，以及我怎样把这些错误变成系统规则。

过去大约三个月，我同时高强度使用 Claude Code 和 OpenAI Codex。我订阅的是每月各 200 美元的 Claude Max 和 ChatGPT Pro，基本每周都会把两边的可用额度跑满。这些额度不是用来反复生成 demo，而是在持续开发和运营一个真实的德州扑克产品 BluffKing：Rust 游戏引擎、基于 Axum 与 WebSocket 的后端服务、PostgreSQL 数据库、Vue H5、Flutter 移动端、回放系统和本地 solver coach，都在同一个生产工程里长期演进。

我也把产品带进了 H5、iOS、Android 和 Telegram 四个真实客户端的生产/发布链路。产品已经在线运行；H5 支付入口与订阅、会员权益系统已部署到生产，取消和退款流程也已实现：Stripe 测试模式与 Google Play 沙盒有完整的购买、取消、退款闭环证据；Telegram Stars 已在测试服务器验证购买与退款，但续订和有效订阅取消尚未验证；Apple 回放链路已绿，但还差第一笔沙盒购买。但我不会把「代码已上线」、「沙盒/测试闭环」和「每个渠道都完成真实资金验收」混成一个状态：截至本文审阅时，部分钱包、原生商店和链上渠道仍在完成最后的生产实付或商店验收。这不是一个只能跑 demo 的项目，但也不应该被包装成「所有支付渠道全绿」。

AI 并没有单独完成这一切。我负责产品目标、风险取舍、账号身份、付款授权和最终责任。两个 AI 的分工也不对称：普通仓库任务谁都可以实现，再由另一方审查；需要已登录 Chrome、网页控制台、打包上传或商店操作时，我直接交给 Claude Code，Codex 主要审查 diff、命令输出和页面证据；Claude 额度中断或 Codex 主动承担实现时，则反过来由 Claude 审查。我真正想分享的，就是这条从「会聊天」到「可参与 production」的中间路径。

这篇文章写给谁

• 已经用过 ChatGPT、Claude 等对话产品，也让 AI 写过函数或脚本；
• 自己有真实仓库、测试、CI 和生产环境，但还不敢让 Agent 大规模参与；
• 想提高开发速度，又担心幻觉、密钥、错误部署和「AI 说完成了」的假结论。

读完以后，你应该得到什么

你不需要立刻复制我的全部系统。这篇文章的目标是让你先建立一张 AI 编程地图，分清 model、Terminal、Shell、CLI、agent、本地/云端/Remote Control、memory、MCP、skill、plugin、workflow、harness 和 hooks；再看懂它们怎样在真实项目中连起来；最后能安全完成第一个可验证、可回退、可审查的生产级小改动。

我推荐 AI 编程，不是因为 AI 不会犯错，而是因为它的错误可以被工程化地约束、发现和修复，而对我而言，它带来的生产力提升真实存在。

先把不同层放回各自的位置

GPT、ChatGPT、Codex、Claude Code、Terminal 和 CLI 不是同类东西，不应放在一张「谁更强」的对比表里。它们是一条调用链上的不同层：

我给初学者的明确推荐

如果你的目标是让 AI 参与真实仓库，我最推荐的起点是：从项目目录的 Terminal 启动一个编程 Agent CLI——Codex CLI 或 Claude Code。不要先纠结哪个模型排名第一，先选一个能读你的仓库、执行现有测试、展示 diff 且有明确权限边界的 Agent。

• 为什么不以普通对话窗口为主：它适合解释和讨论，却不一定拥有当前仓库、命令执行和可核对证据。
• 为什么先选 Terminal + CLI：当前目录、Git 状态、环境变量、测试输出和退出码都直接可见，也最容易进一步脚本化为 workflow 和 harness。
• IDE 怎么用：当作看代码、对比 diff 和手工调试的辅助界面；不必为了用 Agent 放弃你熟悉的 IDE。
• 什么时候用双 AI：先用一个 Agent 跑通「小任务→diff→验证→回退」；稳定后再加第二个新会话、尽量只读的 reviewer。

Codex 还是 Claude Code：按你真正依赖的环境选

为什么我的日常入口一直是 Terminal

对我来说，Terminal 不是一个更「专业」的聊天框，而是工程现场。Agent 从正确的仓库或 worktree 启动后，当前目录、Git 状态、依赖、环境变量、命令输出和退出码都在同一条证据链上。

cd /path/to/project
git status
codex        # 或者：claude

我的常用路径是：进入项目目录 → 启动 Codex 或 Claude Code → 用自然语言说明目标、限制和完成条件 → Hook 检查当前 session 是否已经隔离。只读任务可以留在当前目录；如果 Agent 要在共享的 main 工作区写代码，Hook 会阻止写入，并要求它调用项目脚本创建独立 worktree，再在里面读文件、修改代码和执行测试。这样多个 session 才能并行工作而不共享同一个 HEAD 和未提交修改。最后，我再让另一个 AI 审查真实 diff 与验证证据。后文反复出现的命令、工作目录、Git、权限和 hooks，都是从这个入口展开的。

「远程」也不是一回事：对话、云沙箱与远程控制本机

判断一个 AI 工作方式时，最关键的问题不是「我在手机还是电脑上发 Prompt」，而是：代码和命令究竟在哪台机器上运行？

Remote Control 也不等于 Computer Use。Remote Control 是「人在远程驱动一个本机 Agent session」；Computer Use 是「Agent 自己看、点、输入操作系统或应用界面」。两者可以组合，但权限和风险要分开评估。

Browser、Computer Use 与「接管我现有的 Chrome」是三条不同路径

OpenAI 的内置 Browser 使用独立于日常浏览器的 profile；Computer Use 可以操作桌面应用和图形界面；只有 Chrome 扩展这条路径会接入我已经登录、正在使用的 Chrome。它们看起来都是「AI 在点浏览器」，实际依赖的权限、插件和故障边界完全不同。

我的实际处理方式不是每次先测试 Codex，而是直接按工具稳定性分工：凡是需要使用已有登录态 Chrome 或操作网页后台的任务，我都交给 Claude Code，例如填写 Stripe 控制台表单，或打包上传 iOS、Android 应用并操作商店后台。Codex 在这类任务里主要充当 reviewer：审查代码 diff、命令输出、状态记录和 Claude 提供的页面证据，不负责浏览器执行。这不代表 Codex 的 Chrome 链路已经修好，只是我不会再让一条反复失效的工具链阻塞生产工作。

一张能力图，而不是另一套章节编号

下面只是一张系统关系图：它帮助你看清能力怎样叠加，不代表必须按六个阶段依次安装。

第一次使用 AI 编程，任务要足够小

不要从「重写整个项目」开始，也不要第一次就把支付、权限或数据库迁移交出去。最适合入门的任务应该范围清楚、结果可验证、失败后容易回退，例如：

• 修复一个可以稳定复现的小 Bug；
• 给已有函数增加边界测试；
• 补一个表单校验或错误提示；
• 重构一个输入输出明确的函数；
• 先让 AI 解释一条调用链，不修改代码。

第一次跑通一个可信的小闭环，比第一次生成几千行代码重要得多。

给 AI 的任务卡：五项就够了

提示词不需要神秘。把下面五件事说清楚，效果往往就会大幅改善：

目标：登录失败时显示服务端返回的具体错误。

现象：当前所有失败都显示“网络错误”。

范围：只修改登录请求和错误展示，不调整页面设计。

验收标准：
1. 密码错误时显示正确提示；
2. 断网时仍显示网络错误；
3. 成功登录流程不受影响；
4. 增加回归测试。

限制：不修改接口协议，不增加新依赖。

如果你自己还说不清验收标准，AI 大概率也只能猜。先定义「怎样才算正确」，再让它动手。

一套可以直接照做的工作流

第一步：先保护现有工作，再隔离任务

先记录当前分支、基线 commit、工作区状态与 worktree。若已有未提交修改，先确认它们属于谁；不要让 Agent 自行 stash、reset、clean 或整库 restore。每个新任务应在独立 feature worktree 中写，两个 AI 不得共用同一工作目录。

git branch --show-current
git rev-parse HEAD
git status --short
git worktree list

# 确认基线和现有修改后，再从记录的基线创建隔离 worktree
git worktree add ../project-login-fix -b fix/login-error-message HEAD
cd ../project-login-fix

第二步：让实现者先调查，再修改

请先阅读项目规则和相关代码，确认根因后再修改。

要求：
1. 控制修改范围，不改变无关行为；
2. 增加一个修复前失败、修复后通过的回归测试；
3. 运行相关测试或真实环境验证；
4. 最后列出修改文件、验证结果和剩余风险；
5. 证据不足时，不要声称已经完成。

第三步：把实际差异和证据交给第二个 AI

我的实际流程里，这一步由另一个 AI 完成，不是我先逐行人工审 diff。审查者使用独立上下文，直接读取真实差异、相关代码和测试证据。

你是独立代码审查者，没有参与前面的实现。

请检查实际 diff 以及必要的上下游代码，重点寻找：
1. 逻辑错误和边界条件；
2. 安全、隐私、并发或兼容性问题；
3. 新增回归风险；
4. 缺失、无效或验证层级错误的测试；
5. 与项目现有规则冲突的修改。

不要因为测试通过就默认代码正确。

输出：
VERDICT: APPROVED 或 CHANGES_REQUESTED
OPEN: 尚未解决的问题列表

第四步：在流程内部闭环

审查者发现确认的问题后，不要停在报告，也不要把决定重新抛给人。直接进入「修复 → 测试 → 重新审查」，直到证据通过、审查明确批准并且 OPEN 为空。

第五步：人在本地或生产环境验收结果

我通常不逐行检查代码差异，主要介入最终结果验证：根据任务在本地或 prod 实际操作关键流程，确认功能是否真的可用、是否满足需求。发现问题后，我把复现步骤和真实现象交回 AI，继续「修复 → 测试 → 审查」。必须由账号持有者完成的身份确认、2FA、签名和付款授权仍由我控制；打包、上传、提交审核或已明确授权的发布操作，则可以由 Claude Code 执行并由 Codex 复核，不需要假装每一步都是我手动点完。

证据应该与风险匹配

先把验证层写进完成条件。第三部分会用真实案例解释为什么单元测试、浏览器、设备与生产证据不能互相替代。

完成是一项主张，证据才是事实。

模型、Token、上下文、幻觉与 Memory

Agent、Tool、Permission、Sandbox 与子 Agent

MCP、Connector、Skill、Plugin 到底有什么区别

Skill 告诉 Agent 「这类任务应该怎样做」；MCP 给它「能用什么外部工具」；Plugin 则把这些能力组装成可安装的包。

一个常见误区是安装越多 plugin 就越强。实际上，过多工具和 skill 会占用发现上下文、增加选错工具的概率。我曾因 skills-context 预算警告检查全局配置，最后关闭不必要的 plugin，而不是继续往 Agent 里塞更多描述。

Markdown 文件不只是文档，而是 Agent 的长期操作系统

Markdown 指令的优势是人和 AI 都能读、可进 Git、可审查、可追踪。它的局限也很明显：它主要是指令，不是强制执行。Agent 可能忘记、误解或遇到冲突。所以重要规则要向 hooks、测试、CI 和可执行 gate 升级。

Workflow、Harness、Hook、Gate、CI 不要混用

这些词之间最容易混淆的地方是：Skill 是方法，Workflow 是次序，Harness 是执行容器，Hook 是触发点，Gate 是准入判定，Artifact 是结果证据。成熟的 AI 编程系统通常会同时用到它们，而不是选其一。

我在 BluffKing 中怎样把这些概念连起来

1. 任务进来：任务可能来自我的 Prompt，也可能来自定时巡检和共享 ledger；AGENTS.md 与 CLAUDE.md 自动补上仓库的长期规则。
2. 先找事实：代码、Accepted ADR、实时控制台或 canonical JSON 决定当前状态；memory 只负责帮助定位。
3. 隔离修改：new-session.sh 从 main 创建独立分支和 worktree，每个 AI session 有自己的文件和 HEAD。
4. 按任务选 Skill：视觉修改触发真实浏览器验证，发布回归触发 bug-free-codex，紧急修复有独立 hot-fix 边界。
5. 用 Harness 生成证据：从 Rust 引擎、需要 PostgreSQL 的服务端集成测试、Vue/Vitest 到 Flutter、Playwright、iOS/Android/H5/Telegram 多端房间，确定性与外部设备证据分开记录。
6. 跨厂商审查：Codex 写的补丁由 Claude 审，Claude 写的由 Codex 审。发现的确认问题在同一 workflow 内直接修复并重审。
7. 结构性防越过：Agent hook 禁止在共享 main 工作树编辑，Git hooks 禁止直提交/隐藏改 main，finish-session.sh 是受信任的合并边界。
8. 交付后持续运行：CI/CD 验证发布合同，heartbeat manager 定时巡检并分类、指派问题，ledger 让 Claude、Codex 和后续 session 看到同一当前状态。

这才是我所说的「大规模把 AI 用到 production」：不是让 Agent 拥有无限权限，而是让它在明确的规则、工具、隔离、验证和审查中自主完成尽可能多的工作。

我有没有做 Agent Loop？做了，但不同层的成熟度不同

Agent loop 并没有一个行业唯一标准。它的共同核心是：读取目标 → 调用工具 → 观察结果 → 根据结果继续修复，而不是每一步都等人类复制输出、再发下一条 Prompt。把循环写进 workflow 或 harness 后，还要增加状态、最大轮数、失败分类和退出条件，否则只是在无限「再试一次」。

所以，这套系统不是「没有 loop，只能靠人逐步操作」，也不是「已经无人值守交付一切」。已证实的是 Agent 内循环、跨模型审查循环和定时巡检；仓库也实现了有界 QA→修复→重跑能力。尚未由运行证据证明的是「自动发现 → 修复 → 审查 → 合并 → 发布」整条链路长期无人闭环。

我用这套方法真正改善了什么

亮点不是「我同时打开了两个 AI」，而是在大量普通任务中把人从逐步盯命令、复制日志和反复批准中移出，将时间集中到产品意图、最终验收和高风险边界。下面每一项都有对应的代码、脚本、Hook、提交或运行记录。

为什么一个 AI 会自信地犯错，两个 AI 也会一起漏

一种常见的失败并不是 AI 完全不会写，而是它会沿着一个错误前提持续向前，而且表达得非常确定。它可能：

• 修复眼前现象，却没有找到根因；
• 只阅读一个文件，漏掉上下游协议或状态变化；
• 让现有测试通过，却没有补上能复现问题的回归测试；
• 在前端单元测试通过后，默认真实浏览器也正确；
• 用一段漂亮的总结掩盖没有真正运行过的验证。

同一个 AI 写完再让它「检查一下」，经常仍会沿用自己的原始假设。第二个 AI 可以增加一条判断路径，但它不是正确性证明：两个模型可能共同误解需求、共同相信一组不完整的测试，或者在同一份过期事实之上达成一致。

我的 Git 历史里，双 AI 协作后仍漏掉过哪些问题

这几类问题分别来自验证层错误、需求验收缺失、修复引入回归和外部事实漂移。它们不可能只靠「多投一票」解决。

我真正使用的是多层防线，不是双 AI 魔法

下面是系统控制层，不是另一张测试类型清单：前面的证据表回答「该跑什么」，这里回答「谁负责阻止错误继续流动」。

可靠性不是两个模型投票投出来的，而是多个相互独立的失败检测器叠出来的。

双 AI 的正确定位：多一道独立检查，不是正确性证明

Claude 和 Codex 谁写、谁审并不是关键。关键是角色分离、审查独立，以及审查者必须看到真实代码和证据，而不是只读实现者写的总结。即使两个 AI 都批准，也只能说明它们在给定上下文里没有发现问题，不能说明用户需求已经被完整满足。

同一个模型的不同版本，可以互相审查吗？

可以，基本思路相同：制造第二条判断路径；但独立性不是同一个等级。不同版本的能力、上下文窗口和推理行为可能不同，因此通常比「同一会话自检」更有价值；但同一模型家族仍可能共享训练偏好、表达风格、工具习惯和盲点。

把 AI 带进生产最常见的十一个坑

这些不是已经「永久消失」的问题，而是现有流程持续防范的风险。目标不是零 bug，而是让错误更容易被发现、被拦下、被回退，并且不会在下一个 session 里被忘掉。

附录：需要时再查的 Claude/Codex 术语

这些词不是开始 AI 编程的前置考试。遇到相关场景时回来查即可；第一遍阅读可以直接跳过。

从 GPT 对话用户到 AI 编程入门：四周路线

这不是第二套正文，而是一条执行索引：每周只增加一个能力层，并回到前文完成对应练习。

第一周：只读理解，建立信任校准

先按入口选择和运行位置启动 Agent。让它只读解释架构、画一条调用链、找测试入口；抽查事实，观察它会在哪里猜测。

第二周：完成第一个可回退小改动

按小任务与任务卡选择一个可回退改动，再照五步工作流跑通「调查 → 修改 → AI 审查 → 本地或测试环境验收 → 必要时回退」。

第三周：把重复经验变成系统

回看能力扩展、Markdown 指令与机械约束：创建一份简短准确的 AGENTS.md，把一个重复任务做成 Skill，再用一个简单 Hook 阻止明确错误。

第四周：加入第二个 AI 和证据化 Gate

按双 AI 失效模式与十一个坑形成「实现 → 独立审查 → 修复 → 重新验证」闭环。Reviewer 只是一个传感器，最终结论仍受真实环境证据与人类验收约束。

跳读用 FAQ：初学者面对的十个决策

它是前文索引，不是第二套教程。想快速做决定时先看直接答案，再沿关键词回到对应章节。

把这篇文章直接喂给你的 AI，它真能搭起来吗？

可以搭出一套最小可用版，但不是把 HTML 丢进普通聊天窗口就会自动完成。你需要从仓库目录启动能读文件、写代码和执行命令的编程 Agent CLI，再把本文与下面的 Prompt 一起交给它。只有聊天能力、没有仓库工具的 AI，最多只能给你一份搭建方案。

下面的默认权限边界故意比我的成熟项目更保守：初学者先禁止 commit、push、merge 和 deploy；等自己的 review、回滚与发布 Gate 真实跑通后，再逐项授权 Agent 执行。这是启动配置，不是对我当前工作流的反向描述。

可直接复制给 Codex 或 Claude Code 的启动 Prompt

你现在位于我的项目仓库中。我附上了一篇《从聊天机器人到生产级 AI 编程》。
请不要照抄文章里 BluffKing 的路径、命令或技术栈，而是为当前仓库搭建一套“最小可信 AI 编程闭环”。

工作方式：
1. 先只读盘点：识别技术栈、Git/CI、测试入口、现有指令文件、hooks/scripts、高风险区域与你当前的工具/权限。记录当前 branch、基线 commit、git status --short、git worktree list 与改前 diff；不要猜测，也不要输出可能包含密钥的内容。
2. 写入前保护现有工作：若当前是共享 main、存在不属于本任务的未提交修改，或无法辨认修改归属，不得在当前目录写。优先进入现有隔离 feature worktree；若 Git 状态允许，可从记录的基线新建独立 worktree；否则标记 NEEDS_USER。禁止自行 stash、reset、clean、rebase 或整库 restore。
3. 先输出“现状 → 缺口 → 最小改造”表，然后只在隔离 worktree 内实施安全、本地、可回退的修改；不要等我对每个普通文件确认。
4. 复用现有约定，避免平行造第二套体系。指令文件保持精简；重复性关键规则改为可执行检查。
5. 最少交付：
   - 适配当前 Agent 的项目指令文件（已存在则修正，不要盲目覆盖）；
   - 包含目标/现象/范围/验收/限制的任务卡模板；
   - 调用项目现有测试的最小验证脚本或 harness，错误时非零退出；
   - 独立 review gate：先检测第二个独立 session/model 是否真的可调用；可调用时，用新会话、只读权限审查一个无害 patch，必须读真实 diff/需求/证据并输出可解析的 VERDICT 和 OPEN。只有模板不算 READY；不可调用就标记 UNSUPPORTED 或 NEEDS_USER，交付 gate 必须保持关闭；
   - 从 branch/worktree 到验证、审查、回退的运行说明。
6. 用项目已有命令验证新闭环。失败自测只能新建一次性 fixture、注入临时环境变量或调用明确的 false 命令；不得破坏现有业务代码、测试或配置。测试前后比较精确 status/diff，删除自己创建的 fixture，并证明用户原有状态未变化。
7. 对 review gate 至少验证四条路径：真实独立 reviewer 对无害 patch 的端到端 dry run；reviewer 缺失或超时；非法 verdict；OPEN 非空。后三种都必须阻断；若没有可调用的独立 reviewer，第一条标记 UNSUPPORTED，不能伪造绿色。
8. 最后列出：变更文件、实际命令与结果、未实施项及原因、剩余风险、完整回退方法。回退只能删除本次新建文件或反向应用本次精确 patch，禁止用整库恢复覆盖原有工作。
9. 输出能力矩阵：Memory、MCP、Skill、Plugin、Markdown 指令、Hooks、Harness、Workflow、Worktree、独立 Review、Automation、Remote Control。每项标记 READY / BUILD_NOW / NOT_NEEDED / UNSUPPORTED / NEEDS_USER，并给出证据与最小下一步。READY 必须代表真实可调用且通过正反例验证，不得只凭模板或配置文件。不要为了齐全而安装。

默认权限边界：
- 不安装全局软件，不新增付费服务，不读取或输出密钥。
- 不修改 Git 全局配置，不直接安装 hook；可在仓库内生成待审查的 hook/gate 脚本与安装说明。
- 不碰改前已存在的修改，不自行 stash、reset、clean、rebase 或整库 restore。
- 不 commit、push、merge、deploy、发送外部消息或写入生产数据。
- 遇到验证码、2FA、签名、付款、删除数据、生产发布或不可逆操作时停止，精确说明所需的人类动作。
- 证据不足就标记 NOT_VERIFIED，不得声称完成。

这份 Prompt 能让 Agent 搭起「最小闭环」，但无法一次复制出一套经过三个月演进的完整系统。

最后：AI 编程值得用，而且你今天就能开始

如果你已经用过 ChatGPT 或 Claude 对话，就不需要等学完 Memory、MCP、Skill 和 Hooks 才开始。真正的第一步，是从项目目录的 Terminal 启动 Codex CLI 或 Claude Code，让它直接读取仓库、修改代码和运行现有测试；你负责说明要解决什么，以及怎样才算真的解决。

我已经用这种方式，让一个人配合 Claude Code 和 Codex，持续开发和维护一个横跨 H5、iOS、Android 与 Telegram 的线上产品，也处理支付、订阅、退款、商店发布和线上问题。这些证据足以让我相信，编程 Agent 已经能承担大量真实的工程工作。但它仍会写错、漏需求，两个 AI 也可能一起漏，所以「Agent 说完成了」不能直接当成结果；最后仍要看测试、浏览器、设备、线上状态，或者你亲自操作后的真实表现。

明天开始时，只做这四件事

1. 进入一个你熟悉的项目目录，启动一个编程 Agent CLI。
2. 交给它一个可回退的小任务，写清目标、现象、范围、验收标准和禁止项。
3. 让 Agent 自己调查、修改和运行测试，并报告实际改了什么、执行了什么。
4. 你在本地或测试环境操作一次，确认最终结果真的符合需求；不符合就把现象交回去继续修。

做到这里，你就已经从「会用 GPT 聊天」进入了 AI 编程。等这个流程稳定后，再增加第二个 AI 审查、独立 worktree、Skill、Hook、MCP 和自动化 Gate。本文介绍这些概念，不是让你一次装齐，而是让你每遇到一个真实问题，都知道下一层能力该加在哪里。