用 debug 代码的思维，debug 你的 AI 开发流程
Table of contents
把整套 AI 开发流程当成一份代码来 debug，是我最近用 AI 开发最核心的 mindset 转变。
AI 一定会有出错的时候，当AI出错的时候，正确的方式应该是：像查一个线上 bug 一样去定位：是哪一步断了，是上下文不够，还是工具没接，还是任务描述没写清楚，找到问题，沉淀方案，补上缺口，再跑一遍，直到能完全放手。
而不是：认为 AI 能力不到位，走回人力开发。
这篇不聊具体用哪个 AI 工具，只讲我自己这套 AI 开发工作流是怎么一步步 debug 和沉淀出来的。
1️⃣ 永远不要亲手改代码
我身边有不少工程师是这么用AI的：agent 写了一半的代码出了问题（通常是跑偏），第一反应是直接人工接手过来改，理由通常是跑偏代表 agent 没理解这个需求，人工写会更快。
但我觉得，这个判断是完全错误的。
现在coding这个事实际上已经被AI解决了， agent 写代码的速度，早就远超人手动敲的速度了，你花半小时接手改的那段逻辑，agent 可能三分钟就能重跑一个更好的版本。
所以真正该把精力花在的，是找清楚它为什么跑偏，修的是流程，不是代码本身。
走回人工接手修改的模式，等价于线上 bug 还没定位根因就直接 hotfix，下次还会在同一个位置再断。
我自己设了一个粗糙的原则：只要 agent 在我的工具范围内能自己闭环，我就不上手。就算它比我慢，就算它的路径比我直接改要绕，也无所谓，因为这次让它闭环，下次它就能在同样的场景下自己搞定。
你把全部精力花在搭 agent 流程、修 agent 流程上，完整的接纳AI开发。
2️⃣ 上下文永远是Agent最重要的东西
agent 跑偏，十有八九不是它笨，是任务描述有问题，要么边界不清，要么测试场景没写，要么涉及的文件没列出来。
我现在做代码任务基本不让它上来就干，标准流程是先 /ce-plan 出一份详细的实现计划，写清楚要解决什么问题、边界在哪、具体要改哪些文件、每个功能单元怎么测，重要的计划还会让 Codex 再审一遍，有 Critical 或 Important 的问题没修不让过。
计划扎实了，再 /ce-work 执行，跑偏的概率直接低一个量级。
我粗算过一下，多花十分钟把计划抠清楚，平均能省下它跑歪之后我来回纠偏一个小时。
另一个经验上的数据是：最好input prompt是期待的output长度的3倍以上，只有你的input足够详细，output跑偏的概率才会降到最低，这也是我为什么不支持省token的那套用法，个人使用真的没必要为了省那三瓜两枣降低模型任务的成功率。
所以现在我的一个任务从提出需求，到真正的合入代码，基本都需要耗时两小时以上，改动量经常涉及几十个文件的数千行代码以及数千行文档，但是跑偏的概率很小，小到我已经不Review任何一次修改了，output的总结文件也不是每次都看。
计划执行完之后，还有一个 /ce-compound 的环节，把这轮的新知识、踩过的坑、改过的判断沉淀进知识库，下一次同类任务直接继承上下文，不用重新交代背景。
3️⃣ 给 agent 眼和手
这一步我觉得是 agent 能不能真正闭环最关键的一个基础设施问题。
如果 agent 看不到真实的结果，它只能干活干一半，改完代码不知道 CI 有没有过、PR 有没有 review 意见、部署起没起来、线上日志有没有报错，每个节点它都要回来找你要具体信息，你就变成了人肉粘贴板，把结果一条条转给它。
我现在本地接了几个基础能力：
kubectl可以直接看 develop 和 prod 环境的workload更新状态- gcp log 可以直接看 develop 和 prod 环境的业务日志
gh可以看 PR 状态、CI checks、review comments- Apifox Open API import 可以在合入部署后自动把最新接口文档同步进去
- meggle mcp 可以在合入之后自动处理需求单状态
接上之后，agent 能自己走完整圈：写代码 → 提 PR → CI 红了自己去读日志修 → deploy 了自己跑日志查询 看 5 分钟有没有 ERROR → 确认没问题才结束。
中间我不需要粘贴任何东西，它看到什么，跟我看到的是同一份数据，并且agent几分钟就能处理完我数小时才能吸收的数据。
4️⃣ 权限和隔离
Claude Code 默认模式下，每跑一个命令都要停下来问你能不能执行，你等于是它的人肉确认按钮，loop 根本跑不起来，我们把这种人戏称为yes工程师。
我每次启动 Claude 的时候都会加 --dangerously-skip-permissions，让它一口气把活干完，中间不打断。
但这里有一个很关键的前提：放权和隔离必须配套。
所有工程改动都在 /private/tmp/<project>-<feature> 的独立 worktree 里进行，每次开发前 git worktree add 基于共享 dev 集成分支开一个 feature 分支，agent 全程在这个 worktree 里改代码、跑测试、commit、push、提 PR、处理 review 意见，主仓一点都不受影响。
如果它跑出了预期外的命令、或者把某个文件改乱了，删掉 worktree 重来，整个过程翻车成本极低，主仓永远干净，我打开 IDE 看到的永远是最新 main 的状态。
PR 合入之后自动清理：git worktree remove --force && git worktree prune，再让主仓 fetch origin dev main，如果当前分支干净就快进，有未提交改动就只 fetch 不动。
只放权不隔离是很蠢的行为，而只隔离不放权是在给自己制造额外确认负担。
5️⃣ 搭一套 agent 能自闭环的研发工作流
这部分是我目前花时间最多、也是沉淀最多的一块，平日里大部分时间都花在打磨这套研发工作流上，目前已经彻底跑通了。
目标只有一个：agent 收到足够详细的需求之后，能从写代码一路跑到确认线上没问题，中间不需要人来粘贴结果或者手动确认。
现在这套流程分四个环节：
协作与审核
1.写代码之前，先通过 worktree来创建一个新的工作区，保证并发修改不会乱。 2.Claude Code 修改完成后自动提交给 Codex 审核，有 Critical 或 Important 的 issue 没修就不让过，审核通过后才提 PR。 3.GitHub 项目上配置了一个 Code Review 机器人，当 PR 提上去之后，机器人会对 PR 做二次审查，从安全性、可维护性、依赖版本、上游依赖安全性、API 合约兼容性到测试覆盖率，生成 inline comments，这个机器人是完全异步跑的，不阻塞 CI。
异步处理
Code Review 机器人跑完之后，后台有另一个 agent 在等着，它会读 PR 的机器人 comments，判断哪些是真正需要改的、哪些是误报，然后自己去修改代码、re-push，等 CI 重跑。
这个环节以前是我来做的：CI 跑完，看 comment，粘贴 comment 让agent再重新改，再等 CI，一个来回最少半小时。
给agent gh的登录态之后，现在这整个循环是 agent 自己跑的，而且完全异步等待，没有任何人为的时间损耗。
部署与监控
PR 合入之后进 develop 环境，agent 自己跑去日志平台看业务日志，连续观察一段时间没有 ERROR 级别的报错以及监控数据符合异常之后，才会自动创建 release PR，从 dev 往 main 提。
CI 绿了不等于可以发线上环境，develop 环境真实业务日志没报错才发，这两件事不一样。CI 测的是代码逻辑，线上跑的是真实流量，有些问题 CI 覆盖不到，必须看实际跑出来的日志。
release PR 从 dev 往 main 是自动创建、自动等 CI、自动合入的，发 Prod 不需要人工触发。
线上运维
如果线上出了问题，第一步是用 Feature Flag 快速关掉对应功能，不用 rollback，也不用回滚发布，改一个 flag 就行，这个速度比 rollback 快得多，我设置的时间是 2min，而且影响范围更可控。
然后 agent 去读线上日志，定位根因，在 feature 分支上修好，再走一遍这个完整流程，直到线上确认无异常，整个 PR 才算真正完成。
很多人以为 PR 合入就算完了，我自己以前也这么觉得，直到经历了几次合入后 develop 环境异常之后，我把规则改成了：PR 合入线上环境不是结束，线上超过 10 分钟无报错 + 监控无异常 才是结束。
之后这里还打算加上线上定时的日志巡检，然后提交fix分支修复对应的偶现或者高频报错。
6️⃣ 将沉淀的文档视为唯一真相
agent 是无状态的，你不沉淀下来，它下次会犯同样的错。
我自己沉淀三类东西：
项目约定，写进项目的 CLAUDE.md，比如这个服务改代码必须同步更新哪些文档、调用 LLM 的改动必须补真实 Runnable 路径的集成测试（不能只有 mock）。这些规则一旦写进去，agent 每次碰到那块代码就自己带上这些约束。
跨项目的个人偏好，写进 ~/.claude/CLAUDE.md，比如所有改动在 /private/tmp 的独立 worktree 里做、PR 完整闭环的定义是什么、什么时候要走 Codex 审这个闸门。这类文档是跨项目全局生效的，换一个仓库，同样的约定自动继承。
犯错复盘，错误现象是什么、根因在哪一步、修法是什么、要不要配一个新工具或者规则。纯 mock 的单测有盲区，光靠自己记住不够，你的下一个 session 里的 agent 不知道你踩过这个坑，
必须以沉淀下来的文档作为记忆系统和唯一真相，而不仅仅作为参考资料。
这套流程我在自己的几个项目上跑了几个月，流程是一个 bug 一个 bug 修复中沉淀出来的，每次 agent 跑偏，我就复盘一遍，找到是哪一步的问题，补上工具或者文档，重新跑，直到那个场景下 agent 能自己闭环。
搭这套东西本身也在 debug，只不过 debug 的对象是流程，不是代码。