代码不审了，只审 spec：Agent 流水线先卡在哪

X 上有人转述某家前沿实验室最新的开发流程，一共六条，属于二手消息。流程大意是：大部分代码由 Agent 按 spec 写，人不再审代码，只审 spec；Agent 给每个 PR 打风险分，低风险自动合并，高风险才找人；CI 挂了，Agent 在后台自动修；大多数 PR 不会被合并，Agent 持续淘汰烂代码和烂测试；代码量大到 Git/GitHub 扛不住，团队干脆自研了一套。

先补背景。spec 是规格说明，PR 是代码合并请求，CI 是持续集成。对不写代码的读者，可以把 spec 看成施工图，PR 看成待验收的施工段，CI 看成每次提交后的自动检查。原帖作者的判断是，软件开发会像制造业一样变成流水线，稀缺的不再是写代码，而是写 system design 和设计 evaluation system 的能力。这个判断有吸引力，也把问题往后推了一步：流水线要跑起来，质检标准谁写。

回复区比主帖更接近现场。网友 Gabe 提到，只审 spec 听着优雅，实际 spec 的歧义率和漏写边界才是新瓶颈，Agent 照着模糊 spec 写出的烂代码还得人类回头补锅。网友 byteswim 问得更直接：线上生产系统出了大 bug、宕机、安全漏洞，谁来负责，找人怎么找。网友 viest 盯住风险分：这步谁来校准，低风险自动合并那批 PR 事后出 bug 的比例，才是这套流程最该看的数字。网友 Jack Ma 则对 Agent 自动淘汰烂测试打问号，淘汰标准谁定。还有网友 A_shen 问，程序员以后去哪练 taste。这些回复没有否定效率，它们指出的是同一件事：错误发现点后移了。

画面不难想。CI 红灯挂着，Agent 在后台排队修；PR 多到 GitHub 页面转圈，团队自研代码托管；风险分像闸机，低风险放行，高风险拉人。省下的是逐行审代码的时间，押上的是 spec 质量和评估系统。低风险自动合并如果误判，账单不会在合并时出现，会在事故群里出现。那时候风险分不会背锅，签字的人要背。原帖说 Agent 持续淘汰烂代码和烂测试，听着像自动清淤，但淘汰标准本身也需要被评估。有网友调侃，写屎山也无所谓，等下一代 frontier model 来修。这句话好笑，也暴露了流水线的边界：模型可以修代码，责任不能自动合并。

所以这套流程真正稀缺的，可能不只是写 system design 和 evaluation system 的人，还包括能校准 evaluation system 的人。spec 写得清，风险分才有的放矢；风险分校准得住，自动合并才不是赌博；事故责任清楚，流水线才敢开快。软件开发确实在向制造业靠，但工厂不是没有质检，质检也不是一句低风险自动合并。原帖链接在这里：原帖。