写代码跟焙茶一个理，机器能控温，但出锅前必须人亲自尝火候。RPCS3这次ban了自主AI智能体提代码，要求PR作者fully own every line，不是开倒车，而是给AI辅助开发划了条硬边界。

大模型写代码确实像开了外挂，但自主Agent提交的patch，隐蔽的side effect、幻觉引入的bug，review成本可能远大于重写。开源项目不是gacha池，不能抽卡式出码然后人类兜底。开发者必须对可维护性负全责，这跟信任链一样——你可以用AI当copilot，但final commit的按钮得按在人类手里。

我以前被坑过，现在连室友的转账都要double check，何况是 thousands of lines 的codebase。让AI写，让人担责，这才是健康的human-in-the-loop。

sudo make me a sandwich

看到RPCS3这个决定，我第一反应是想起去年读的一篇论文，来自NYU和Cornell的研究者做的实证分析，他们让有经验的开发者review AI生成的patch，发现识别隐蔽逻辑错误所需的时间平均是review人类代码的2.3倍。这个数字很值得玩味——不是说AI写得差，而是它的错误分布和人类不一样，reviewer的认知模型还没适配过来。

楼主提到“review成本可能远大于重写”，我觉得可以再往深挖一层：成本不仅体现在时间上，更体现在一种“注意力税”。人类写代码，哪怕质量参差不齐，错误模式是有迹可循的——新手容易犯边界条件错误，老手可能在重构时引入回归bug，reviewer心里大致有个谱。但大模型生成的代码，它的“思维路径”是黑箱，你永远不知道那个看似正确的循环里是不是藏了一个概率极低的token预测偏差。这就导致review时你不得不切换到一种“全量怀疑”模式，每一行都要像拆弹一样重新推导逻辑，这种认知负荷才是真正的隐性成本。

我之前在部队做文书时处理过自动化生成的报表，系统导出的数据看起来规整，但偶尔会在汇总行少算一个零，原因是上游某个字段的空值处理逻辑和下游不一致。后来我养成习惯，凡是机器吐出来的东西，先抽样手工复算三遍才敢往上交。这个习惯带到代码review上也类似——我现在看AI写的PR，会先假设它一定有至少一个“看起来完全正确但实际语义偏移”的错误，然后像玩找茬游戏一样去定位。这种心态本身就拖慢了效率。
嗯
不过我想补充另一个视角：RPCS3要求“fully own every line”，这个边界在实际操作中可能比想象中模糊。严格来说如果我用Copilot补全了一个函数体，然后自己改了变量名、调整了逻辑顺序，这算不算fully own？如果我用ChatGPT生成了一个算法框架，然后逐行理解并重写成符合项目风格的版本，这又怎么算？我觉得关键不在于代码是不是从AI脑子里出来的，而在于提交者是否能对每一行的设计意图做出清晰解释。之前Linux内核社区讨论过类似问题，Greg KH的态度就是：只要你敢在邮件列表里defend your code，并且能回答为什么这么写，那不管代码怎么来的都行。但如果连你自己都说不清某个判断条件为什么是>=而不是>，那这行代码就不该合入。

所以human-in-the-loop的精髓可能不是“人按按钮”，而是“人能讲清楚为什么”。这比单纯强调责任归属更可操作，也更能倒逼开发者真正理解AI生成的代码，而不是当搬运工。严格来说

说到幻觉引入的bug，我手头正好有个案例。上个月我用某个主流模型辅助写一个并发队列的测试用例，它给我生成了一个看似完美的无锁结构，但实际在weak memory model下会有reorder问题。严格来说如果不是我恰好读过preshing的博客，那个bug可能就溜进代码库了。这种错误review时极难发现，因为它不是语法错误也不是逻辑矛盾，而是对特定硬件内存模型的假设错误——reviewer得同时懂并发理论、编译器优化、和目标架构的内存序，才能看出问题。这已经超出了常规code review的能力范围。

所以回到RPCS3的做法，我觉得与其说这是“开倒车”，不如说是在当前技术阶段的一种风险规避策略。等哪天AI能自动生成形式化验证的证明，或者至少能附带一份它自己的“设计决策记录”，那时候再谈自主提PR也不迟。

sudo make me a sandwich 这个梗让我想起xkcd，不过现实中我们大概更接近“sudo make me a code review”的状态 (笑