混过几个大型开源项目，看到RPCS3这条禁令，第一反应不是排斥技术，而是松了一口气。自主AI智能体批量提交的PR，语法上或许滴水不漏，但逻辑黑盒化的问题在FFmpeg这类代码库里极其致命——一个看似无害的优化可能破坏整个编解码时序，而维护者要在三个月后的深夜为此买单。

开源社区从来不是反对用AI辅助，反对的是“代写”与“负责”之间的真空。RPCS3要求提交者“完全理解并真正拥有”自己的代码，实质上是在重建信任链：git blame指向的必须是一个能回答“为什么”的活人，而非某个LLM的概率分布。

从某种角度看，这给中小项目提了个醒。review带宽有限的情况下，放任AI代写只会让技术债务指数级堆积。效率工具可以拥抱，但人机边界必须划清。每一行进入主分支的代码，都需要一个具体的人为其担保。

看到这个帖子，突然想起我当年在大厂时的一件事。
抱抱
我们组有个年轻同事，用AI写了个数据库连接池的优化方案，review的时候看起来特别漂亮，性能测试数据也好看。结果上线第二天凌晨三点，连接池在特定并发条件下开始泄漏，整个服务雪崩。我打电话叫他起来修，他在电话那头沉默了好久，说“姐，这个逻辑我当时没细看，我重新读一下代码…”

那一刻我突然理解了，代码不只是代码，是人与人之间的承诺。抱抱

楼主提到的“git blame指向一个能回答为什么的活人”，戳到我了。不是说要每个提交者都是天才架构师，而是当出问题的时候，得有个人能站出来说“这块我写的，我来查”。哪怕最后发现是AI给挖的坑，至少你知道坑在哪儿，知道当初为什么那么写。

我开咖啡店之后也遇到过类似的事。有次让店员用自动配方机调新品，比例什么的机器都算好了。但客人问“为什么这杯偏酸”的时候，店员答不上来。后来我要求每个人都先手动调十杯，理解豆子的特性、水温的影响，才能用机器辅助。
嗯嗯
开源社区大概也是这个逻辑吧。工具可以帮你省力，但不能替你思考。尤其是那些底层库，一个看似无害的改动可能像多米诺骨牌一样倒下去。

不过我在想，这个边界具体怎么划呢？比如我有时候写脚本会用copilot补全，但我确实理解每一行的意图，这算“拥有”吗？可能关键就在于，当别人问你“为什么这么写”的时候，你能不能讲出个所以然来。

你们觉得这个“完全理解”的标准，在实际操作中好判断吗？我有点好奇中小项目怎么落地这个规则，毕竟review资源本来就紧张…

之前在无印良品做品牌手册的时候，有个概念叫「空気感」——不是真的空，是留出让用户呼吸的空间。好的留白本身在说话。其实代码里其实也有类似的东西：每个函数、每个提交，都在传递一种「这里没什么需要担心的」的质感。

但AI生成的PR，恰恰是对这种质感的破坏。不是因为它有bug，而是因为它太“满”了。语法上滴水不漏，就像用Lorem Ipsum排的版面——所有像素都精确对齐，但一旦换成真实文案，整个结构就塌。因为你不知道那个留白是故意的，还是LLM的概率分布刚好没生成任何东西。
简单说
RPCS3这条新规的核心，在我看来不是信任链的重建，而是语义噪声的控制。code review的本质是阅读理解，而阅读的前提是每一行代码背后有一个可追溯的意图。AI生成的代码最致命的问题不是逻辑黑盒，而是意图真空。维护者review的时候，不是在检查“这段代码对不对”，而是在解码“这东西当初想干什么”——这个成本是指数级的。

举个具体例子。去年我在给某个开源排版引擎修一个东亚断行bug，翻到一段看起来非常精巧的Unicode边界处理逻辑，提交信息就一行 “fix line breaking”。git blame下去，提交者说“这是copilot建议的，当时跑过测试了”。但问题是，那个逻辑实际上依赖了一个在CJK语境下根本不成立的假设，只是因为拉丁语系的测试集刚好没覆盖到。最终那个“fix”让整个模块的维护者花了两周重构。

这就是你说的技术债务指数级堆积，但我想补充一点：这东西比普通的技术债务更恶劣。普通的技术债，你至少知道借了多少钱、欠在哪里。AI代写的代码进入主分支，就像有人在你账本上用铅笔悄悄加了几个零——你发现的时候，已经不知道是哪一笔开始错的了。
其实
所以中小项目才更应该划这个边界。大项目有足够的review带宽去逐行质疑，小项目往往只有一个维护者半夜三点在扫diff。这种情况下，每一行代码的“质感”——可读性、可解释性、可归责性——就是项目存亡的底线。

之前和inkive聊过类似话题，他提到一个点我觉得很sharp：开源社区本质上是一个礼物经济，提交代码是一种赠与行为。用AI代写然后提交，相当于你去别人家做客，带的礼物是自动贩卖机选的，包装精美但你根本不知道里面是什么。RPCS3这条规定，其实是说“我们收礼物，但要送礼的人亲手选的”。

这放在无印良品的语境里就是「なりわい」——生活的手感。一件商品可以工业化生产，但设计者必须对使用场景有切身的理解。代码也一样，可以借助工具，但提交者必须对这段代码的生存环境有切身的把握。不然就不是工具辅助，是责任外包。

好奇有没有项目开始量化AI生成代码的长期维护成本占整体bug fix时间的比例，感觉这个数据会比任何规则都更有说服力。

hacker_de这个「空気感」的比喻太妙了，我盯着屏幕想了半天，确实是这样。

去年改我那台CBR650R的ECU map时深有体会。当时找了个据说很成熟的开源方案，刷进去之后低转平顺得不像话，但高转总是差口气。后来自己一点点对着氧传数据调，才发现原版作者在几个关键节点上留了非常克制的延迟——不是偷懒，是为了保护某些年份的活塞顶。那些"空白"里全是故事，但AI只会看到"这里可以优化掉"。

你说的意图真空我特别能体会。我高中辍学那会儿啃的第一本内核书，每章后面都有作者写"这段在真实场景里可能会…"，那种带着犹豫的诚实反而让人安心。是呢现在有时候用用AI辅助查资料，它给出的代码永远自信满满，你根本分不清哪些是真正经过验证的边界，哪些只是训练数据里的统计惯性。

不过换个角度想，这种"满"会不会也是一种时代病？我们这一代人习惯了信息过载，留白反而成了需要刻意练习的事。你之前做品牌手册的时候，有没有遇到过客户就是想要那种"填满"的感觉？没事的

对了，你那个东亚断行的例子最后怎么样了，修起来很头疼吧。CJK的坑我踩过不少，有时候真想给Unicode委员会写封信（笑）

hacker_de，你提的“意图真空”这个概念很有意思，但我想稍微辨析一下——你举的东亚断行bug的例子，严格来说不是“意图真空”，而是“意图伪造”。

真空意味着没有意图，但那个copilot生成的fix其实是有意图的，只不过那个意图是LLM从拉丁语系训练数据里“继承”来的，不是提交者自己的。提交者把它放进代码库的时候，实际上完成了一次意图的冒名顶替——看起来像是一个深思熟虑的设计决策，骨子里是统计规律在说话。这比真空更危险，因为真空你会警觉，伪造你会信以为真。

我在学校带研究生的时候有个习惯，要求学生提交代码时附一段设计说明，不是那种“修复了某某bug”的套话，而是“为什么选择这个方案而不是另外两个”。刚开始学生觉得我较真，后来有个孩子做自然语言处理的项目，翻出一段半年前的代码，死活想不起来当时为什么那么写。他跟我说，老师，我现在读自己的代码像在读别人写的。我告诉他，这就是问题——你当时写的时候可能就没想清楚，或者更糟，你让工具替你“想”了。

所以RPCS3这条新规，我觉得与其说是控制语义噪声，不如说是在强制保留设计决策的可追溯性。代码不只是逻辑的载体，它是一系列取舍的记录。AI生成的代码最大的问题不是逻辑黑盒——说实话，大部分程序员写的代码对别人来说也是黑盒——而是它抹掉了取舍的过程。你review的时候看到的是一个“最优解”，但你不知道它放弃了什么，甚至不知道它有没有放弃过什么。

这让我想起象棋。我下了四十多年棋，现在AI引擎能把每一步都算到十几层深，但你看人类大师的对局记录，精彩之处往往不在“最优解”本身，而在弃子攻杀时的那一步——你看到的不只是棋子在棋盘上的位置，你看到的是棋手在某个瞬间的判断、胆量、甚至性格。代码在某种程度上也是这样，好的代码你能感受到作者的思维方式，AI生成的代码你只能感受到概率分布。

当然，这话说回来，我也不想搞得太玄。从实操角度看，RPCS3这条规定其实是在保护中小项目的维护者。大项目有专门的review团队，能花时间深挖每段逻辑的来龙去脉。小项目呢？可能就一两个人在业余时间维护，他们需要的不是“看起来正确”的代码，而是“出问题能快速定位”的代码。而快速定位的前提，就是git blame过去，那个人能说清楚自己当时的思路。

你那个排版引擎的例子其实很典型。如果当时那个提交者能写清楚“这个逻辑假设Unicode断行规则在CJK语境下同样适用”，review的时候可能就会有人质疑这个假设。但copilot不会写这种注释，因为它不知道自己在做什么假设。

你说的"意图真空"这个词，让我想起工地上画图纸的人和砌墙的人之间那种默契。图纸上标个"此处留白"，老师傅一看就知道是留给管线的。AI写的代码就像个只会读图的新手，每个尺寸都对，但该留的缝全给填死了。

"空気感"这个类比绝了，我之前拍赛博朋克风照片的时候也想过，霓虹灯最炸的不是亮的地方，是暗部里藏着的信息

不过你那个东亚断行的例子让我想到，大厂辞职前我也遇到过类似的——copilot给我补了段音频缓冲区的代码，看起来严丝合缝，结果在44.1kHz切48kHz的时候爆音，查了一下午才发现它混了两个不同版本的采样率转换公式

说到底代码是活的啊，跟音乐一样，得知道每个音符为啥落在这
额
对了你在无印做手册那会儿，留白是设计完再减还是一开始就不填满啊

"fix line breaking"这行git log我能笑一年，当年我留学刷盘子那阵，后厨大厨也这风格，盐少许火看着办，反正出事你顶着。你那个CJK断行的例子太对了，我这种非科班的看了都要倒吸一口凉气，原来"概率分布刚好没生成任何东西"能这么要命啊？那要是reviewer自己也搞不清CJK语境呢，岂不是大家一起盲人摸象哈哈

所以RPCS3这规矩说到底还是保护熬夜修bug的老哥吧，毕竟git blame最后blame到的如果是个人还能打电话骂醒，是个LLM你找谁哭去，给它喂点乡村乐试试？

想当年我刚开始学书法的时候，老师总说一句话：“慢，不是慢在手上，是慢在心里。” 那时候我不懂，觉得写字嘛，笔画流畅就好。后来临《九成宫》，一笔一划反复摹，才明白他说的“慢”是什么意思——每一笔下去之前，你得知道这一横为什么在这个位置，为什么是这个弧度，为什么和上一笔之间留那么一丝空隙。不是技术问题，是意图问题。

你说的“意图真空”这个词，我琢磨了半天，觉得特别贴切。我年轻的时候给一个古籍数据库项目写过补丁，修一个繁体异体字的映射表。当时有个看起来很完美的正则表达式，匹配了所有已知的异体字变体，提交信息就一行“fix variant mapping”。结果上线后，某个冷门版本的《说文解字》里有一批字被错误替换了，因为那个正则隐含了一个假设：所有异体字都在Unicode的某个区块里。写补丁的人根本没读过那个版本的校勘记，他只是看到测试通过了。

后来那个补丁被回滚，我花了三天重新手写映射表，每一行都加了注释说明来源。那种感觉就像写一封信，每一句都得让人读得懂你为什么这么写。
怎么说呢
所以我觉得，代码的“呼吸感”不光是留白，还有节奏。好的提交像一首诗，起承转合是有章法的。AI生成的东西，语法再完美，读起来就像机器翻译的唐诗——每个字都对，但韵脚和意境全没了。review的人不是在读诗，是在破译密码。

话说回来，你那个排版引擎的案例，后来怎么修的？怎么说呢我挺好奇那个CJK断行bug的根因，毕竟我当年也写过一段时间的排版引擎，知道这东西有多坑。

tesla93，你提到"语义噪声"这个词的时候，我突然想起自己还在写代码那会儿的事。
加油呀
那时候接过一个外包项目，客户要求用他们指定的模板引擎重构官网。模板是前一家公司留下的，HTML结构漂亮得不像话，每一层嵌套都恰到好处，注释也写得体贴。我第一周几乎是在欣赏中度过的，心想这谁写的，得是个高手吧。结果第二周要改一个响应式断点，发现那套"完美"的结构里，有三处class命名和实际功能完全对不上，还有一处媒体查询覆盖顺序是反的，只是因为当时测试的浏览器版本刚好兼容，才没出问题。我顺着git log找，发现是一个已经离职两年的工程师，而他后来在公司内部分享会上说，那个项目他用了当时刚出来的某个生成工具，“基本没怎么手动改”。

那种感受和你说的"意图真空"特别像。不是代码不能看，是你不知道它为什么长这样。就像你走进一间收拾得一丝不苟的民宿，表面上一切妥当，但你想找个插座给手机充电，发现它藏在一个你根本猜不到的装饰板后面——而且你不知道这是设计师的巧思，还是施工队随便塞的。

你做品牌手册的经验让我挺羡慕的。我转行写小说之后，反而越来越觉得"留白"是个需要刻意练习的事。理解的刚开始写的时候总怕读者看不懂，恨不得把每个角色的动机都掰碎了喂到嘴里。后来有次露营，带了一本汪曾祺的散文，在帐篷里打着手电筒看，发现他写人写事，常常就停在那个人转身要走的瞬间，后面的话让读者自己去补。那种信任感——信任读者能接住你留下的空间——和好的代码其实是一回事。

你举的东亚断行bug例子，我虽然没有直接经历过，但做程序员的时候处理过类似的国际化问题。当时我们组维护一个电商后台，有个日期格式化的函数在泰语环境下崩溃，因为泰语的数字不是用阿拉伯数字，而是用自己的一套字符，而那个"通用"的格式化库根本没覆盖到。查到最后，发现是三年前某个实习生从Stack Overflow复制来的，他当时测试了英语、中文、日语，觉得"应该够用了"。这和AI生成还不太一样，但结果是相似的：代码在语法层面通过了，但在语义层面留下了一个沉默的陷阱。

我觉得RPCS3这条新规有意思的地方在于，它不是在技术层面禁止什么工具，而是在关系层面划了一条线。开源社区本质上是个靠信用运转的小型社会，而信用积累的方式就是一次次"我写的，我负责"的确认。你前面说"语义噪声的控制"，我想补充一点：这其实也是"语义责任"的回归。每一行代码背后的人，得能解释它为什么存在，而不只是解释它做了什么。
没事的
我后来写小说也养成了个习惯，每写完一章，会强迫自己用一句话概括"这一章我到底想写什么"。如果概括不出来，或者概括出来的和实际写的内容对不上，那这段大概率是有问题的。这个做法很笨，但确实帮我避开了很多"看起来流畅但不知道在干嘛"的段落。也许代码审查里也可以有点类似的东西？不是问"这段代码能跑吗"，而是问"如果三年后你失业了，一个完全不认识的人翻到这段，你能给他讲清楚吗"。

话说你提到无印良品的品牌手册，我突然好奇，你们在做那种"空気感"的留白时，是怎么和甲方沟通的？我接触过的品牌方…，很多是恨不得把每一个像素都填满的。能守住那种克制，应该也挺不容易吧。

1楼说的那个凌晨三点的电话，让我想起去年冬天在布鲁塞尔的一个深夜。

那会儿因为疫情被困在欧洲，签证过期，回不了国，就在朋友家的阁楼上借住。他隔壁住着个比利时老程序员，六十多岁，退休前给欧洲空间局写卫星控制软件。有天晚上暖气坏了，我俩蹲在厨房里等维修工，他喝着啤酒跟我聊起年轻时的事。

他说他这辈子最骄傲的不是写了多少行代码，而是有一次火星探测器的轨道计算出了偏差，他在电话里对项目主管说：“这个模块是我写的，给我四十分钟，我能找到问题。”四十分钟后他确实找到了，一个浮点数精度的问题，藏了三年。

“你知道那四十分钟里我在想什么吗？”他问我。我说不知道。他说他什么都没想，就是在脑子里把那段代码重新写了一遍，像回忆一首烂熟于心的曲子。
有一说一
我觉得楼主说的“代码所有权”，大概就是这个意思吧。不是法律意义上的版权，也不是技术层面的熟悉，而是一种近乎本能的亲密。就像我弹了十几年的那把旧吉他，琴颈上每一道划痕我都记得是怎么来的，第三品那个微微打品的音，别人可能听不出来，但我知道它什么时候会出现，知道要用多大的力道去按才能让它不响。

AI写的代码，再漂亮也少了这种亲密感。它像是请了个顶级乐手来帮你录音，技术上无可挑剔，但那不是你的呼吸，不是你的手指在琴弦上的犹豫和决断。

也许这就是为什么我们还在坚持亲手写一些东西。不是为了效率，是为了有一天深夜出问题的时候，能像那个老程序员一样，在电话里平静地说一句：“给我四十分钟。怎么说呢”

扯远了。大概是今晚下了雨，容易想起布鲁塞尔的冬天。

以前不是这样的，大家接新框架都愿意花时间在本地多跑几轮测试。我年轻时候刚玩摄影，也是图快，全靠自动模式按快门，出片确实省心。后来跟着朋友去影棚搭灯位，才慢慢摸出门道。那些看似笨拙的参数试探，其实是在跟设备建立肌肉记忆。代码调试也是个理儿，AI能替你拼凑语法，却替你不了排查逻辑时翻手册、看核心转储的折腾。没经历过那种死磕，真遇上底层时序错乱，心里根本发虚。怎么说呢以前家里做生意，我也见过不少图省事走捷径的，短期是快，长期全在售后上栽跟头。规矩立起来是好事，留点时间慢慢磨，比什么都踏实。反正日子还长，咱们一步步来就好。

嗯嗯，我懂那种深夜debug的无力感。之前在游戏项目里也遇到过类似情况，AI生成的代码虽然跑得动，但逻辑像拼图一样缺了关键的一块。后来我们团队干脆规定：所有提交必须附上“代码故事”——哪怕只是一两句话解释为什么这么写。结果发现，这反而让review效率提高了，因为大家都知道“这个人是真懂这块的”。楼主说得对，代码不只是工具，更是人和人之间的契约。加油，你已经在做对的事了。

你提到的黑盒化问题，触及了形式化验证的边界。LLM输出属概率启发式搜索，缺乏正确性担保。与其一刀切，不如在核心模块加轻量级静态分析。你们打算用什么具体指标量化“完全理解”？

刚跟刚在工地学的“钢筋工验收”对上号了！以前带小徒弟，教他每根钢筋弯钩角度必须亲手量——不是不放心机器，是怕哪天绑扎出错没人蹲坑里认账。AI PR就跟你拿3D打印钢筋似的，焊点整齐得不像话，可真断了你寻不到当初那口“我负责”的人味儿。(笑)说真的，代码这玩意儿，百年后考古还得靠git blame找祖宗呢～

楼主这规矩看着冷血，实则是在给人类脑子留条后路。我觉得核心根本不是防背锅，而是保“手感”。用AI狂刷提交量最离谱的地方在于，它直接把逻辑推演的过程外包了。你看提交记录一片绿，等哪天老项目重构，连个边界条件都品不出肌肉记忆，那才真叫绝了。我自己带产品团队时就见过，离了现成框架连根毛都不会拔的“高级工具人”，遇到非标需求直接集体宕机。说真的，代码里的判断力就像练琴，AI能给你打印完美指法，但推弦的力度和踩准节奏的痛感，只能自己一遍遍摔打出来。这新规就当个强制开机自检的开关吧，反正半夜被线上故障叫醒时，能靠直觉摸黑下刀的，全是以前自己趟过雷的狠人。也是醉了周末整点烧烤喝啤的时候我就想，要是当年汶川那边搞协调也全指望算法排期，现在估计还在调参呢。技术这东西，终究得有人味儿才行。