看看这篇文章，cladue团队是如何使用规范来用agent编写代码的https://x.com/addyosmani/status/2114604912520921136

回复 群友 3131 先说这篇讲的是 Claude Code 团队做代码审查（code review）的方式：Claude 已经写了约 90% 的代码，每千行改动都靠人逐行读已经不可能。他们从 6 月到 9 月合并的 PR 数量翻了一倍多，回滚率反而降了 40% 以上，靠的是把“读代码”这件事自动化，而人只负责机器干不了的部分。 核心思路：不再用“有没有人读过这段代码”衡量质量，而换成“这个改动可能出什么问题、该由哪道检查来接住”。 整个流程是七层，机器全程参与，中间不再只有一道人审关卡；前面几层会拦下大部分问题： 1. 在提交 PR 之前：先让 Claude 跑可执行验证，比如测试、build、截图与设计稿对比，并且要求它给出证据，不允许只说一句“做完了”。另外再用一个全新上下文的 subagent 审查 diff，还跑了内部 skill，例如找 bug、缩减 diff、校验 UI 是否符合设计规范。作者的原话是：给 Claude 一套验证流程，输出质量能提升两三倍。 2. 每个 PR 必过 AI review：把 diff 放进全仓库的上下文里审查，同时对照 PR 作者的意图，检查改动有没有真正解决问题、有没有融入整体系统、有没有破坏别处。这份发现会再经过多个 agent 并行排查、投票确认，只留下票数足够的结论，纯风格类问题会被过滤掉。评论分 重要/小问题/既有问题 三级标注。 3. 安全审查有拦截权：只要还有没关闭的发现，PR 就不能合并。 4. 自动检查有拦截权：lint、类型检查、各平台测试、build，一个 CLI 的 PR 动辄几十道检查。 5. 人工审批按风险分级，而且分级看的是改动本身，不看作者是谁。分类器判断风险等级，还有一层判断“这个改动是否需要额外一个人批”。敏感路径和 CI 配置文件永远要人批。只有仓库所属团队在 trusted list 上才能走宽松路径。关键一条：agent 的批准不算人的批准；agent 提的 PR，操作这个 agent 的人始终算一个必需的评审人。而且一次批准只对一次 commit 有效，有新 commit 就得重新批。 6. 合并队列 + feature flag + 灰度。 7. 出问题就快速回滚，每周 on-call 复盘时追查“本该是哪一层拦住的”。 规范这件事，其实就沉淀在三个文件里： CLAUDE.md 写技术栈、约定、目标和非目标，每次 review 都读，所以大仓库里要写得短，其余内容链接出去。 REVIEW.md 是 code owner 告诉 reviewer “我这块什么重要”。好的写法包含：定义什么叫失败，比如文档不能骗人、配置不能路由错；限定不要吹毛求疵；写清忽略路径；要求引用文件和行号而不是猜文件名；要求给顶层结论摘要。他们还会反过来验证 reviewer 是否真的遵守了 REVIEW.md。 再加 lint 规则和 skill，以及 PR 模板里的“怎么测的、风险多大、怎么回滚”三问。 这套流程里最难、也最值得抄的一段，是让审查收敛。他们发现 agent 作者和 agent reviewer 会一直来回打转：有个 PR 一晚上来回了五十多轮。看 git blame 后发现，被反复挑出来的约 59% 是早就存在的旧代码，每轮只是多挖出几个陈年老 bug，新问题极少。于是改成：最多三轮，超过三轮就要求作者重新评估方案；之后的复审只看新增 diff；指明 bug 类别，让作者一次全修，而不是一次修一行；不重复报告已经提过的问题。几轮下来，每个 PR 的平均审查轮次明显下降。 人还要干什么：决定要不要做这件事，也就是产品品味和愿景；审计危险代码，例如计费、自动更新、CI；架构评审；验证证据，比如测试输出、跑过的命令、截图；以及最终负责：谁合的就谁担。 还有个我觉得最有价值、也最少被提的点：如果机器读完了大部分代码，新人怎么学习代码库？他们没有搞正式机制，而是谁要了解某块，就让 Claude 现场生成一份针对那段代码的讲解，顺带做个可视化小 artifact。理由是读一行改文案的 diff 学不到东西，读一份模块讲解学到得多。 如果要落地，最低成本的做法是：先写短的 CLAUDE.md 和 REVIEW.md，用 hook 自动跑 formatter/linter，本地用 /code-review 和 /security-review，PR 模板加测试/风险/回滚三问，强制 CI 和“所有 review 线程关闭才能合”，限轮次，按风险分级审批，合并队列和一键回滚，最后把每次事故和回滚都存成 eval 集，改 prompt、工具或模型时重跑评分。