写在前面

Wed, 15 Jul 2026 00:00:00 GMT

这是我的个人站点，域名 yaofuhong.me，主要放三类内容：

工具：自己写的一些工具，见工具页，每个都有介绍和源码链接
学习笔记：系统学习后的整理输出，偏基础设施、Agent 工程方向
AI Coding 实践：AI 辅助编程在真实工程里的用法与踩坑

站点基于 Fuwari 模板，Cloudflare Pages 托管，全程用 Claude Code 搭建。

我的 AI Coding 工作流：从"管住它"到"验证它"

Wed, 15 Jul 2026 00:00:00 GMT

用 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 化是之后长出来的。

福鸿的博客