60年码龄的老程序员：别读agent的代码

Uncle Bob Martin 写了快60年代码。他最近在网络上分享了一个操作，原话：

我不读agent写的任何代码。这是我能利用它们生产力的唯一方式。 我做的事是给agent套上极端约束——单元测试、Gherkin测试、QA流程、质量指标、变异测试、测试覆盖率，等等。最终，我对它们生成的代码有很高信心，因为它们必须跑赢所有约束和测试。

不读代码，靠测试墙来信任。0xAA 把这套思想做成了开源 skill：old-coder（老码农）。

安装一行命令：

npx skills add https://github.com/amazingang/old-coder

支持 Claude Code、Codex CLI、Cursor、Aider，或者你自己的 agent loop。纯 markdown，不挑食。

流程比看起来更完整

old-coder 不只是"跑测试然后出报告"。它把整个 TDD 循环嵌进去了：

SPEC → RED → GREEN → REFACTOR → GAUNTLET → EVIDENCE

你只需要读两份文档：

• SPEC（写代码之前）—— agent 先出一份测试计划，包含具体的行为示例和需要安装的工具。你只需要点一次头。
• EVIDENCE（写代码之后）—— 一份可复现的闯关报告，所有数据来自一次全新运行。你一行命令就能重跑验证。

中间发生了什么？agent 自己写测试、看它失败、写代码让它通过、重构——然后被推进 gauntlet。

Gauntlet 里到底有什么

不是笼统的"10+关卡"。八个核心关卡，每个回答一个具体问题：

除此之外还有一层按风险选配的领域关卡——并发、UI检查、API兼容性、性能、可观测性。规则是：effort scales with risk。改个 typo 只跑几个检查；涉及钱、登录、数据、并发的，全部跑满，而且 agent 得先用恶意输入攻击自己的代码。

怎么防止 agent 自己骗自己

agent 在给自己的作业打分，所以规矩定得很死：

• 永远不能弱化测试来让它通过
• 永远不能报告没跑过的检查
• 没验证的东西标 unverified，不能标 pass
• 如果没人批准过 spec，报告必须声明并降低置信度

还有一个坦率的上限声明：gauntlet 只能证明代码符合 spec，不能证明 spec 覆盖了所有该覆盖的东西。这就是为什么 spec 必须交给你审。

Demo 已经跑通了

仓库里带了一个 rate-limiter 的完整 demo。跑出来的结果：17个测试，100%分支覆盖率，8/8 植入的bug被抓住。而且这套流程还揪出了一个真实 bug——一个 NaN 时间窗口悄悄滑过了输入验证。

一行命令可以复现整份报告：

cd demo-rate-limiter
python3 -m venv .venv && .venv/bin/pip install -r requirements-dev.txt -e .
./tools/gauntlet.sh

回到 Uncle Bob 的讨论区。有人问：代码质量还重要吗？他的回答：重要，而且比以前更重要。混乱的代码会拖慢 agent。他亲眼见过 agent 在自己的烂摊子里打转，绕不出来，最后只能他亲自接手。所以他用极端约束卡死函数大小、圈复杂度和测试覆盖率——让 agent 保持流畅。

还有人问：谁来监督约束本身？回答：你。你是工程师，最终你负责。就像监督人一样监督 agent——保持关注，但不必逐行读代码。

如果你还在纠结要不要读 agent 写的每一行代码，试试这个思路：别读了，让它们先跑一遍关卡再说。

old-coder 在 GitHub 上开源了：github.com/AmazingAng/old-coder