前两天翻到 Cockroach 一篇博客，10 月 9 号发的，我拖到上周才点开。光这个拖延速度，就够去他们医院挂个号。
先看数字。
2024 年给 MOLT 加 Oracle 支持：九个月，工程成本十六万美元。
今年加 Db2：四月某个周三晚上开工，周五下午收工，不到两天，烧掉 4172 美元的 token，全程没有一行代码是人写的。
快 164 倍，便宜 38 倍。我盯着这个倍数看了半分钟，心情和第一次看 AI 三秒写完我憋了一下午那条 SQL 时一模一样——一半是"牛逼"，一半是"那我呢"。
但让我坐直的不是数字，是他们怎么干的。
没搞一个超级 agent 一把梭。他们把这件渡劫的事，改成了一家教学医院。工具叫 MOLT，医院叫 MOLT Sinai，Sinai 借的是多伦多和纽约那两家西奈山医院的名字。在这套东西里，issue 是患者，合并是出院，负责拍板的人类叫 Chiefs of Medicine。
【此处本来该有一张组织架构图，我画不出来，各位脑补】
再往下翻角色表：分诊护士、Fellow、查房主治、出院护士。辅助岗还配了护士长、感染控制、安全科、研究科。
我第一反应是"这不是写软件，这是拍《白色巨塔》"。第二反应是"改 bug 这事本来就应该按急诊流程办"。第三反应是"别急，先看事故记录"。
事故来了。
一、他们的门槛，是照着人的脑子定的
规划阶段只要估计变更超过 1000 行（含测试），Fellow 必须拆成子 issue、挂依赖图；拆完还超 1000 行，接着拆。
为什么是 1000？不是为了迁就模型的上下文窗口，是为了让审查者——不管这审查者是人是 agent——能把整个变更在脑子里放得下。
一千行，人类脑容量的天花板，被硬生生写成了流水线的阈值。头一回见有人把"人脑装不下"当硬指标写进配置里。
也有让人心里一暖的。有个 Attending 在一份已经过了好几轮审查的 PR 里，挑出了一行 docstring 的毛病。而且它没自己把 PR 退回去，是提请人类裁定。这一下不算显灵，是它真把自己当主治了。
但同一套流程咬起人来也是真咬。
一个把 UI 文案从 Validating 改成 Verifying 的单行改动，走了五轮返工，一路闹到 Chief，争的焦点是：低风险 PR 能不能在 CI 抖动的时候先合。另一个 PR，一行代码毛病没有，被 PR 描述里的一个拼写错误拦下。还有个标了紧急的 issue，修复内容就是在一条代码路径里调用一个早就存在的函数、跟旁边三条同类路径对齐——十一次返工，两天。
我看到这里笑了一下，然后有点想哭。
这不是 AI 写代码写出的毛病。这是 AI 把贵司的 code review 学了个一模一样。
（真的。你们组那个卡你三天的老哥，现在有替身了。而且替身不会累，不会下班，不会在群里假装没看见。）
二、提示词腐化这段，建议维护 system prompt 的人打印出来贴墙上
七月他们审计了 25 份 skill 文件，十万字出头。结论是能删掉 2.3 万字，23%，删完不影响任何门禁、命令、模板和标记。冗余长什么样？同一条规则在好几个文件里各写一遍，六千字散落在七十处。其中一份文件，47% 是废话。
为什么？因为这玩意儿跟代码一样会腐化——而且比代码更没救：代码烂了还有测试兜着，规则只加不删，没人拦。
后果很具体。出院护士每次上班，先读 21800 词的指令，接近 29000 token，读完才准开 PR。基础协议被全部十五个角色加载，所以那里堆的冗余最贵。
你们组最严格的 reviewer，每次 review 之前得先背一遍员工手册，才准看第一行 diff。就是这么个画风。
他们还打算给 prompt 做个 linter。我第一反应是"这也行"，第二反应是"我们组的 prompt 早该 lint 了"，第三反应是"算了吧，lint 出来的问题我也修不动"。
三、然后是断路器
他们发现返工根本不收敛。某个安全审查窗口里，三个复杂 issue 分别走了九轮、九轮和七轮，烧掉 631 美元——而那个窗口，整家医院才花 1046 美元。三分之二的钱，花在三个 agent 原地打转上。
安全科给的结论刀刀见血：审查流程缺一个可计数的非收敛断路器，所以循环要么升级太晚，要么永远不升级。
修复已经合了：PR 连续四轮返工、每轮都冒新的阻塞性发现，或者任何实质返工累计到六轮，审查者必须移交主治。
人类 reviewer 什么时候能配上这个断路器，我不知道。我只知道我见过一个 PR，同一个文件、同一个变量名，来回改了七轮，最后是作者自己受不了，把文件删了重写。
（这段是我编的。但是不是很有画面感？）
四、真正让我服气的，是那堆病历
每个 issue 的档案里存着：规划方案、编码前写的复现测试和失败记录、治疗计划的每一次修订、每一次交接、每一次审查的结论和理由，还有每个阶段用了哪个模型、多少 token、多少耗时、多少成本。档案放在 archive 分支，跟代码一起合，所以 PR 的 diff 里干干净净，只有代码。
结果是五个月之后，他们仅凭 issue 讨论串，就能重建 1238 个 PR 当初为什么要合。
我看到这句停了很久。
因为我们组 GitHub 上躺着的那些"这里为什么要加个 sleep"，git blame 指向的那个人两年前离职了，commit message 写着"fix"。
同样是五个月。人家攒出一本能查的病历，我们攒出一堆谜语。
【灯光渐暗】五个月，一百多万行代码进进出出，只有 7 次回滚。这个数字摆在这儿，你就知道那堆病历不是白写的。
他们自己也认了一件事：搭这套东西的两个人加起来四十多年行业经验，所以它其实并不具备教学医院培养新人的功能，对没有完整日程、需要时间慢慢攒判断力的应届生不完全适用。
翻译一下：它擅长让你睡觉的时候也有人干活，不擅长把人教会怎么干活。
还有个细节我想单独留着——研究科一开始每三个小时巡一遍代码库、提新功能，提得太多，团队审不过来，先降到一天一次，再给未接纳的提案设了十个的上限。他们说，有时候你在交互式会话里灵光一闪，去医院一查，几周前就有人提过同一个 issue 了。
恭喜。你现在是团队里最有新意那个人的最后一块阵地，也快守不住了。
（郑重声明：本文所有"我们组"的情节均属文学创作，如有雷同，说明你我坐在同一栋楼里，只是楼层不同。评论区扣个"我们组也这样"，我数数到底有多少家医院已经开张 🫠）