RPCS3团队前两天扔了个新规，自主AI智能体不准提PR，要求merge的人必须对自己提交的每一行代码负全责。这消息出来，有人喊开倒车，我却觉得切得漂亮。

搞OpenResty和Nginx这些年，最深的教训是：线上不怕出bug，怕的是出了bug你发现git blame指向一个没法问责的黑箱。AI生成的代码可能CI全绿、review也挑不出刺，但真到了worker进程里碰上个边缘case，你找谁去追问设计上下文？开源社区能转起来，靠的是贡献者之间的技术信任链，不是对LLM概率分布的宗教信仰。

工具就是工具，Copilot当个高级autocomplete用挺好，但签字的手和背锅的脑子必须是人类的。为了追效率把开源项目搞成不可维护的黑盒，那才叫真翻车。

看到这个突然想起来我上个月用Copilot写的一个Python脚本，跑了一周才发现有个edge case直接漏了，literally就是楼主说的那种“CI全绿review也挑不出刺”的代码… 当时git blame指向我自己（笑死 用的是我的commit），但我根本不知道那几行为什么那么写，最后debug花的时间够我手写三遍了

btw darwin26之前说过一句特绝的，“AI生成的代码就像别人嚼过的口香糖，你永远不知道里面有没有钉子”，我当时还觉得夸张，现在想想真就这么回事
好家伙
不过话说回来，我觉得RPCS3这个政策其实挺妙的，它没一棒子打死AI辅助，只是说你别让AI当commit author，人必须为每一行负责。牛啊这让我想起在温哥华这边打工的时候，厨房里可以用料理机切菜，但主厨必须尝过每一道菜的味道才能出餐。工具再厉害，味蕾和判断力还是人的。开源社区说白了就是个开放式大厨房，你端上来的代码别人要吃的，你不能说“我也不知道这里面放了啥，反正料理机说OK”

而且我特别赞同楼主说的“技术信任链”这个概念。上次给一个open source项目贡献文档，reviewer直接问我“你这块理解是基于什么场景的”，我要是说“ChatGPT告诉我这么写”那就彻底社死了… 但因为我确实自己跑过测试、踩过坑，能解释清楚上下文，最后merge得很顺利。信任就是这么建立起来的，一行一行commit攒出来的。

但有一点想补充，就是我觉得有时候禁止AI提PR可能也是为了保护提交者自己。你想啊，如果AI生成了一个看似完美的patch，你merge进去了，结果几个月后发现是个安全漏洞，背锅的是你，不是那个LLM。到时候简历上还得写“曾为某知名项目贡献过漏洞一个”，想想就窒息

还有一个角度我最近一直在琢磨，就是AI生成的代码往往缺乏设计意图。代码本身是思想的物化，但LLM只是概率分布，它没有意图。我读别人写的代码的时候，其实是在读那个人的思维方式，知道他为什么在这里用singleton、为什么这个变量命名成这样。但AI生成的代码就有点像… 嗯，像是你在二手书店随便翻到一本没有做者没有前言的书，字都认识，但不知道为啥要写这本书。这种代码混进项目里，长期维护的时候就会变成一个个黑箱。

不过话说回来，我认识几个在startup的朋友，他们现在开发速度要求特别变态，不用Copilot根本赶不上deadline。所以就挺矛盾的，效率和质量到底怎么平衡。可能RPCS3这种老牌项目更看重长期可维护性吧，毕竟模拟器这种东西，一个bug可能要等几年才被发现。

突然觉得这个话题跟我囤书不看一个道理哈哈 书买回来就是我的了，代码merge进去就是项目的一部分了，但到底消化了多少、能不能维护，只有时间知道

话说楼主你那个“git blame指向一个没法问责的黑箱”形容得太精准了 绝了 我以后写post