AI 写的代码别直接提 PR

Simon Willison 说，让同事替你看 agent 生成的改动，等于把活推给别人。附四条自检标准。

写代码变便宜之后，最先坏掉的不是代码质量，是协作礼仪。

Simon Willison 在他的《Agentic Engineering Patterns》里专门开了一节讲反面案例，第一个点名的是：不要把自己没审过的代码提成 PR。

他的质问很直接：如果一个 PR 里是几百上千行 agent 生成的代码，你自己都没确认能跑，那你其实是在找人替你干活——对方完全可以自己开一个 agent，凭什么要花时间读你的？他觉得这种提交「常见，且让人非常恼火」。

什么样的 PR 才合格

他给了四条标准，每条都在讲「你替审稿人省了什么」：

1. 代码确实能跑，而且你敢担保。 交付能用的东西是你的工作，不是概率问题。
2. 改动小到能被高效读完。 几个小 PR 永远好过一个巨型 PR；拆分和 rebase 交给 agent 做，几秒钟的事。
3. PR 里带上背景。 这次改动服务的是什么目标，关联哪条 issue 或哪份规格。
4. PR 描述也要自己读一遍。 agent 写的描述看起来很专业，但不读就丢给同事，同样是不礼貌。

他自己加的第五条

除了标准，他还提了个更实际的要求：给出你确实动手验证过的证据。

写在 PR 里的一句话、一条手动测试记录、一个具体的实现取舍说明，或者一段录屏截图——目的不是自证清白，是告诉审稿人：你的时间不会白花在翻细节上。

编辑判断

这篇的价值在于把「AI 提效」这件事的成本从工具侧挪回了人侧。多数教程在教你怎么让 agent 一次写更多，这一节在教你怎么让同事少花时间——两个方向恰恰相反。

适用性是最强的一点：不分语言、不分公司大小，只要团队用 PR 流程就能直接套。它也解释了一个正在变多的现象：AI 让提交量涨了几倍，评审环节反而成了新的瓶颈。

局限也要说清楚。一是篇幅很短，只讲到了「不要甩给协作者」这一种反面模式，团队内部用 agent 互改代码、agent 之间互相 review 的做法他没展开。二是作者本人是重度 agent 用户和工具作者，他的工作流偏向个人与小团队，大厂里那套强合规、强评审的流程里，这套建议可能要打折。

最能直接拿走的一句：agent 让写代码的门槛降到了零，评审的门槛没降。 谁能先把自己的评审成本压下来，谁才真的从 agent 里拿到了速度。

---