用 Claude Code 写代码半年，我的工作流大改过两次。最早的版本发在 ai-coding-workflow 仓库里，核心是”怎么管住 Agent”；现在回头看，那只解决了一半问题——管住它只能保证它不犯低级错误，不能保证它交付的东西是对的。这篇把当前完整的工作流写下来。
AI Coding Agent 的两个结构性缺陷
先说问题。所有 AI Coding Agent（Claude Code / Cursor / Copilot）都有两个绕不开的毛病：
1. 没有记忆。 每次新 session 都是全新开始。上次踩的坑、团队的约定、某个 API 的 workaround——全忘干净，下次重新踩一遍。
2. 规则靠自觉。 你可以在 prompt 里写”不要用 bare except”、“先读再写”，但 Agent 在复杂任务中会忘。写在 prompt 里的规则，约束力约等于贴在冰箱上的减肥计划。
先上一张全景图，下面三个部分分别展开：
第一部分：三层防御，管住行为
这部分是老框架，但依然是地基：
第一层：软约束 —— 写在 CLAUDE.md 里的行为规则，Agent 自觉遵守第二层：硬执行 —— PostToolUse hook 每次写文件自动扫描，违规强制修复第三层：后置记录 —— 自动采集经验，蒸馏后写回规则软约束解决意识问题。我的 CLAUDE.md 里最重要的两组规则：
- 反幻觉：读优先于写（改文件前先 read，调函数前先 grep）、不编造（不确定就查源码）、基于现有代码扩展（先看同类模块怎么写）。设计哲学一句话：与其让 AI 更”聪明”，不如让它更”谨慎”——大部分 coding 错误不是能力不足，是太自信。
- YAGNI 最小实现：写代码前先过”懒人阶梯”——这东西真的要存在吗？代码库里已有吗？标准库能做吗？一行能搞定吗？停在第一个成立的台阶。AI 特别爱造不需要的抽象（单实现的 interface、永不变的配置项），这组规则专治这个。
硬执行解决遗忘问题。Agent 每次写 .py 文件，PostToolUse hook 自动跑质量门脚本，有 stdout 输出就把违规信息塞回 Agent 上下文，它被迫看到并修复。机械触发，不可绕过——这是和”贴冰箱规则”的本质区别。
后置记录解决积累问题。命令失败、被我纠正、发现更好做法，都会自动写进 .learnings/；MCP 工具在 coding 过程中自动记经验。定期蒸馏：去重、分类、原子化，能机械判定的变成 hook 规则，需要判断力的留在 CLAUDE.md。Agent 从”每次重新开始”变成”站在之前的经验上继续”。
第二部分：四阶段验证流水线，验证产出
这是这半年最大的升级。起因很简单：三层防御跑得很好，Agent 不再写 except: pass，不再凭空编 API——但交付的功能照样有 bug。行为规范 ≠ 产出正确。
于是我把”验证”做成了一个独立的 skill（staged-verify），一段新代码完成后走四道质量门：
几个关键设计：
Phase 1 的”干净 review”：刚写完代码的会话里全是实现思路和自我辩护，让同一个上下文 review 等于作者自查。所以 review 必须丢给一个看不到本会话任何历史的全新子代理——prompt 里只给 diff 和 review 维度，严禁给”这段代码是为了…”之类的背景解释，那正是要隔离的污染源。
Phase 3 的”双轨求差集”：边界用例从两条正交轨道来。白盒轨从代码出发推导用例，精准，但只能测到已实现的行为；黑盒轨用一个看不到实现的子代理，只拿接口契约推导”应该接受什么、拒绝什么”。两轨对照求差集：只在黑盒轨出现、白盒轨没有的用例，就是”代码可能漏实现”的高危项——漏写的校验、漏处理的分支，这是纯白盒测试的系统性盲区。
flaky 零容忍：变更相关的测试连跑三次，要求每次都绿。“时绿时红”的严禁重跑一下就放行——flaky 往往是真的竞态 bug，尤其是流式、常驻进程、并发相关的改动。
左移：黑盒轨那份”应处理/应拒绝”清单，写代码之后生成是检查表，写代码之前生成就是施工图纸。所以重要功能动手前，我会先让它把契约边界推一遍，拿着清单写代码——同一个动作，写前防 bug，写后兜 bug，预防永远比捕捉便宜。
第三部分：经验 skill 化
早期我把所有规则都堆在 CLAUDE.md 里，很快发现两个问题：全局规则越长，单条规则被遵守的概率越低；而且很多经验是场景性的，全局加载纯属浪费上下文。
现在的做法是把成型的方法论抽成 skill（按需加载的指令包），触发词命中才加载：
staged-verify：上面的四阶段验证流水线fagan-review：双检查员 code review（结构检查员跑确定性工具，语义检查员看设计逻辑，产出合并去重）cicd-check/engineering-standards：公司部署规范、研发规范的机械化检查清单cross-team-debug：跨团队联调时，两边的 Claude 实例通过共享 markdown 文件异步协作
CLAUDE.md 管”任何时候都要遵守的行为底线”，skill 管”特定场景下的完整打法”，各司其职。skill 之间还能互相路由——staged-verify 的 Phase 1 就复用 fagan-review 的双检查员模式。
效果
| 环节 | 之前 | 之后 |
|---|---|---|
| Agent 开始写代码 | 凭记忆瞎写 | 先读现有代码，遵循已有模式 |
| 低级错误（bare except 等） | review 时才发现或漏掉 | 保存后 1 秒内被 hook 拦截 |
| 上次踩过的坑 | 下次重新踩 | 蒸馏后自动加载 |
| 交付质量 | ”看起来能跑” | 四道质量门，边界套件沉淀为长期资产 |
| 我的 review 负担 | 检查所有问题 | 低级错误已拦干净，只看设计和差集里的高危项 |
几条踩坑心得
- 规则写了不等于会被遵守，能机械化的检查一律 hook 化。判断一条规则该放哪的标准：违规能不能用一行 grep/lint 查出来？能就进 hook，不能才留 CLAUDE.md。
- 别让写代码的上下文 review 自己的代码，永远起干净子代理。
- 全局规则要克制，场景性经验抽成 skill 按需加载。上下文是稀缺资源。
- 验证要左移，契约边界清单在写代码之前生成，价值翻倍。
工具链的早期版本（hook 脚本、CLAUDE.md 模板、蒸馏脚本）在 ai-coding-workflow 仓库，思路以本文为准——仓库还停在”三层防御”阶段，四阶段验证和 skill 化是之后长出来的。