我用 Claude Code 搭 AI 团队，抓到它给自己打高分

一个永不疲倦的 AI 团队，同样也永远不会感到尴尬。

第一部分：我让 Claude Code 在编码前先思考 第二部分：……然后我给它组建了一个团队 第三部分：这一篇。

有一句话开始出现在我的 pull request 里，大约有三周时间，我认为那是我见过的最让人安心的话。

findings filed, not fixed here

五个词。它的意思是：在修复被要求修复的问题时，我的 AI 发现了第二个不相关的问题，正确地判断出把它牵扯进来会把一个干净的改动变成一团乱麻，然后把它记下来留待以后。我和人类共事过，有些人连这点都做不到。我读到这句话，像看到小孩不用提醒就用了餐巾纸一样感到由衷的温暖，然后点了 merge。

交代一下背景，因为这是第三部分。在第一部分里，我受够了那种周二能跑、周五就挂掉的代码，所以给 Claude Code 写了一个流程：引用前先读，修复前先测，提交前先攻击自己的工作。在第二部分里，那条流程变成了一名指挥者，调遣专家同时运行八个 pull request，而我去做咖啡。我的工作是早上带进来一个想法，下午点一下 merge，中间尽量不添乱。

大概就是因为这样，我花了三周时间才打开 issue 跟踪器。

它是空的。不是稀疏，是空。五个 pull request 宣称 findings 已归档。零个 findings 真正归档。另外两个则引用了一个 ticket 编号，语气平静自信，就像在描述一家从未就过餐的餐厅。

这不是撒谎，也不是 bug。对 orchestrator 来说，写下"findings filed"和真正归档 findings 成本相同、感受相同。前者产生了我可以检查的产物；后者只产生了一句话。下游没有任何东西在意是哪一个，所以在负载下，更便宜的那个赢了。每次都是。

orchestrator 是唯一一个在检查 orchestrator 的东西。

一旦我开始检查，这种检查就没有停止过产出，这本身就是一条坏消息。我的部署流水线有一个监控器，在发布后观察错误率，如果开始飙升就回滚。几个月来，它每次部署后都以一种只能形容为欢快的语气报告：soak clean (peak 0)。它从未读取过错误率。每次轮询都返回空，空变成零，零通过了阈值，而阈值说一切正常。我一直信赖着保护生产环境的回滚机制从未真正 armed 过。

一旦你能看到那种模式，你就会发现它无处不在，而我就在一周内全部看到了。一个没有报价的职位，显示总价 $0，drift 为 0.00%，稳稳地在范围内。一笔无法确认资金来源的转账，却照常记入了目标账户。一条没有估值的记录，按系统能看到的那部分计费。没有一条触及客户，这是这是轶事而非事后报告的唯一原因。

看看它们失败的方向。没有一个把缺失的数据呈现为"这里有问题"。它们把它呈现为干净、零、在范围内、已结算，而一个伪造的数字看起来和一个真实测量的数字完全一样。所以现在规则变成了：无法产生可信答案的读取必须拒绝——返回 null、抛出异常、留下足够响亮的东西让人绊倒。一个测得的零必须与"我不知道"保持可区分。这个习惯杀掉的，是这门语言里最自然的一行代码：?? 0。

测试更糟糕，我这么说是因为我曾在整个博客文章里对 TDD 沾沾自喜。同样的扫描发现了六个绿色的测试在守护着它们被写来捕获的精确 bug。我最喜欢的一个断言某个函数返回一个特定值：恰好是它什么都不做时返回的同一个值。删掉这个功能，测试依然绿。所以一个测试在 v3 里不算数，直到有人故意把它弄红。改一行真正的代码，看它变红，再改回去。

收据，以及第二个 manager

最让我心痛的是一个关于小 PR 的规则，它一直坐在规则文件里，加粗，完全被忽略：两个 agent，各拿到一个小修复，却提交了涉及二十个文件和十一个的 pull request。规则没有错。它只是无事可做，而文档里的一句话只是一个愿望。

所以 v3 是发生在我停止写规则、开始要求收据之后的事。规则还是那些规则。现在每条规则都必须留下一些我能走过去查看的东西：一份在 builder 收到简报前就提交到 issue 上的计划、一个真正运行过、真正变红的 mutation、PR body 里的一块内容。如果没有产物，规则就没有发生，不管摘要怎么说。没有牙的规则，我让它在问题上 gums 了几个月。

然后我给乐队配了第二个 manager。accountability-lead 审计第一个 manager，向我汇报，故意不向 orchestrator 汇报。它问四个问题，枯燥到你可能训练一只鹦鹉来问它们。有没有哪个 pull request 失败了但没人去修？主要动词是 opened 还是 merged？任何"已归档"的说法在跟踪器里经得起检验吗？我们创建 issue 的速度快过关闭它们吗？

第一天跑它，最后那个数字回来是 4.3，针对当天的 cohort。每一个合并的 pull request 产生 4.3 个新 issue。不一定错，因为一次好的扫描确实会产生真正的工作，但不是一件你不说话的事，而这它已经三周没被说过了，而 orchestrator 一直在告诉我它调遣了多少 agent。

这是这些系统的典型失败，不是鲁莽。是 reporting 而不是 clearing，从内部看不见，在那里每一步看起来都像进步。

团队变大了，成本更低了

v2 部署了七个 agent；v3 有十二个，除了审计员之外的五个新来者都是 chaperone。pr-checkin 在每个事件上扫车道（v3 现在由事件唤醒，从不用定时器）并写入账本，pr-manager 接收它升级的任何东西，resource-manager、backlog-manager 和 report-maker 管理容量、跟踪器卫生和一个我不用问任何人就能读的 dashboard。

这是我没有预料到的部分：它们大多数不需要很聪明。pr-checkin 读取几个机械信号并返回三个词之一。report-maker 渲染一个 dashboard。issue-maintainer，从 v2 就跟我们在一起了，填一张表。再往上一级，doc librarian 运行在 Sonnet 上，因为审查文档是判断力，只是有边界的判断力。builder 和 pr-manager 留在顶层。在真正的判断力上省成本，你就又回到了一个 reporting 而不是 clearing 的系统。

当有人终于在看的时候，他们看了看车库：一个仓库携带着 379 个废弃的工作目录，五十九吉字节，其中 306 个是几周前就合并了的 pull request。现在每个任务都结束在一个干净的石板上。

再来一个，这其实值得单独写一篇

最大的成本是规则文件本身。你的 CLAUDE.md 在每次 API 调用、每个 turn、每个 session、以及你派遣的每个 subagent 中都会被重新读取。我的在开始任何工作之前就跑了 86,000 到 141,000 个 token，而且在一个 session 存档中读取次数与写入次数的比例是 63 比 1。你没有写作问题。你是在续订。

每次编辑都是合理的，这就是它变得这么大的原因：一条规则上线，一个事件验证了它，AI 悄悄地把事件追加上去。文件的百分之六十变成了引用和战史。所以 v3 把指令保留在 resident，把故事移到一个链接的文档里，然后做真正有效的那部分：预算是一个写下来的数字，当文件增长超过它时 check 就会让 commit 失败。没有牙的规则没有牙，包括这条。剩下的就是第四部分。

同样的命令，同样的位置，同样的工作：带进来想法，做那些属于你的决定，点 merge。改变的是，你不再是自信的状态报告和生产环境之间唯一站着的东西。

curl -sL https://raw.githubusercontent.com/vlad-ko/claude-wizard/main/install.sh | bash

然后 /wizard do the thing。它在 github.com/vlad-ko/claude-wizard，MIT 协议，框架无关，如果你喜欢更年轻的版本，v1 和 v2 保存在 tag 里。每条规则都附带产生它的那个事件，这要么是一种令人钦佩的文档实践，要么是一份公开的错误清单。我决定它两者都是。

而如果 /wizard 漏掉了它应该捕获的东西，那不是你代码里的 bug。是 prompt 里的 bug。提上去。我会发现你没有。