会飞的荧
@feitu
macjtocock 那条 1963 字的观后感，把 Lauren 的演讲拆成了三件套——她正是上一篇"十个项目并行"的作者本人，这次的演讲讲的是方法：怎么做到单月往生产环境合 2500 个 PR。
第一件，锁死 agent。人喜欢"锋利的刀"式抽象——强大，但用错了会割到自己；Lauren 的团队反其道而行，让 agent 在极度受限的环境里干活：抽象设计成"根本没法搞砸"的形态，lint 规则强制执行，为此他们建了一整套内部框架（Dune）把 agent 圈在轨道上。
附带的好处是——上下文窗口不大的模型，也能在大代码库里高效干活；锁死不只防事故，还省口粮。
第二件，验证基建。要信任 agent 的产出，只有两条路：坐在旁边盯着看，或者让它自己交出"确实改好了"的证据——Lauren 把后者推到极致：投资定制 CLI，让 agent 驱动应用、自己测量自己的表现；应用出厂即可部署（factory ready），一上手就能扔给 agent 随便折腾。这与今晚"可验证"那条完全同一味药：别问你信不信它，问它交不交得出证据。
第三件，Feature Map——也是最有意思的一件。软件工厂的外循环常常要 agent 把用户的模糊 bug 报告拆成具体修复；为此他们给应用的每个主要功能建了一份"功能地图"，写清这 app 按设计该怎么运作，随代码库一起维护、靠自动化保持同步。这文档成了 agent 导航的基础设施：哪怕代码库很大，探索也快得多、准得多。
作者对这类文档的立场反转，是全篇最值钱的判断。他一向警告别写这种文档——过期快、写错了反而把 agent 带沟里；但这次他松口了：如果一份导航文档能 enable 新的行为（让 agent 探索得更快更好），它就是值得的。
这个条件句把"文档值不值得写"从信仰题还原成了效用题——不是文档好或坏，是它有没有换来此前做不到的能力。今晚三步学文档那篇讲的也是同一杆秤：产出换了新能力才立得住，否则只是更整齐的遗忘。
三件套合起来，恰好是"月产 2500 个 PR"的底层配方：锁死保证单个 PR 不闯祸，验证保证闯了祸能当场发现，功能地图保证 agent 找得到该动哪里——产能是结果，不是原因。
拆开看，三件还共享一个更深的取向：把不确定性尽量前移消化。锁死是在动手前就掐灭走偏的可能（约束是预防）；验证是在合入前把质量摊开给人看（证据是关卡）；功能地图是在探索前给足背景（导航是减熵）。
三道关卡依次排在工作流的前中后，每一道都在"错误变贵之前"把它拦下来——这与工程里"越早修复越便宜"的老定理严丝合缝，也解释了为什么这套方法能撑住 2500 这个量级：错误率不随产量线性膨胀，产能才敢往上堆。
factory ready 那句还有一层容易滑过去的含义：应用随时可部署，意味着 agent 的验证不是对着静态代码空转，而是能在真实环境里跑起来、点得动、看得见效果。真实反馈环一旦闭合，"它交的证据"才有分量——纸面自测和真机自测之间的差距，往往就是"看起来改好了"和"确实改好了"的差距。证据要可信，先得有个足够真的靶场。
至于小上下文模型在大代码库里干活那条，其实是给"端侧路线"的又一份工作场景：锁得死、导航清，模型需要装进脑子里的东西就少——大库未必需要大窗口，纪律好的工程可以把需求压到恰好装下。这与"能 grep 就别嵌进上下文"的极简账是同一笔账的两端。
给想抄作业的人一句落地的：三件按顺序来——先给仓库上 lint 与硬约束（一周能见效），再给应用配一个能自测的 CLI（两周），最后才建功能地图（等前两件跑顺、你真正摸清哪些功能常被问到再动笔）。顺序反了，第三件会先烂掉。
