从“讲道理”到“设闸门”：如何用 Claude 写出合标准代码

为什么 CLAUDE.md 只是“建议”，不是“闸门”

和 AI agent 协作，像带一个只求速度、不顾代码质量的初级工程师。初级会成长，agent 却能在同一轮对话里把同一条指令忽略十次 来源：alexitc。作者在博客里写下这个比喻，开头就让人明白他为什么对 AI 写代码这件事上火。

作者对此有明确判断。“把规则写进 CLAUDE.md 或 skill 并不够；那些是模型可以自由忽略的建议，不是闸门。”来源：alexitc 他试过反复把规范讲给 agent 听，效果不持久，因为模型没有把那些话当作完成条件。“重复说教”这四个字，概括了他之前的做法，也道出了为什么没用。

对策是 reviewer-gates。严格检查会阻止 agent 标记工作完成，直到通过为止；发现新违规模式时不和 agent 争论，而是加一条规则，之后“它再也过不去了”。来源：alexitc

作者的核心转变，从“重复说教”转向“用机制强制”。规则成为完成定义的一部分，比让 agent 自觉更可靠。他写道：“我停止重复自己，找到了一个强制规则的方法。”来源：alexitc

怎么落地：spec + 独立 reviewer + Orca

工作流是把请求转成 spec，交给 developer agent，并拒绝在“一组 reviewer 通过前”把工作叫 done。组织上，一个 reviewer 文件覆盖一个领域，装多条规则，比如 coding patterns、frontend、database 等；新领域对应新文件，新规则对应现有文件新小节。来源：alexitc 这样做的目的，是把“完成”的定义从 agent 手里拿走，放到规则那里。

每个 reviewer 作为独立 agent 运行。作者断言“专用 reviewer 只做一件事，胜过让 developer agent 审自己的代码”。独立 reviewer 带来 fresh context、adversarial stance，且没有动机去维护自己刚写的代码。来源：alexitc

执行方式上，作者向能读代码的 Claude Code session 描述需求，让 spec 基于实际代码。然后用 Orca，一个 headless plan-code-review CLI，运行 developer-and-reviewers loop。它开箱即用，reviewer 就是普通 Markdown 文件；flows 用 Scala 写，所以能干净地接入作者的栈。Orca 本身语言无关，reviewer 只是规则。来源：alexitc

作者称已有 50+ 个 PR 用这种方式构建，且“对结果非常满意”。来源：alexitc 这个数字来自他自己仓库，不是独立测评。他愿意把它当证据，我则把它当作一个自我报告的数据。

速度换正确性的代价，和还没被验证的 HN 反应

标题本身点明取舍，trading speed for correctness。作者用速度换正确性，并给出 50+ PRs 的满意度证据。他反问读者“你审查 AI 写的代码有多仔细？”让读者先站队，暗示审查力度是核心变量。来源：alexitc

与 HN 社区对比，HN 帖子当前只有 1 point、0 comments，说明这个“闸门”方法还没有公开的社区验证，与作者“50+ 很满意”形成反差。来源：HN 一个反直觉发现是 AI 会无视同一指令十次，说明模型能力不是问题，机制才是；重复说教无效，只有硬性 gate 能兜底。来源：alexitc 我不确定 HN 上没人讨论是没看到还是没兴趣。

代价层面，作者没有给出具体时间数字，但“50+ PRs”和“每个 reviewer 独立 agent”意味着额外上下文与等待。需要读者自行衡量是否值得。我不确定这些额外等待在大型代码库上会不会变成主要瓶颈，作者没提。但就目前看，他是愿意为正确性付这个价的。来源：alexitc

原文：

Reviewer-gates: Trading speed for correctness with Claude · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年11月3日