四分之一PR不是产能问题，而是成本搬家
四分之一PR带来的核心变化，不是代码产量，而是维护者承担的证伪成本。 把这个比例摊开：每100份PR里有25份由AI生成，增加的不是可交付价值，而是25次额外判断。我起初把“AI垃圾”当成质量标签，后来更在意它制造的负担：代码即使能编译、测试能过，只要作者没说清问题、理由和边界，维护者仍要重建上下文。
AI标签本身不该成为判决。人类也会制造垃圾，AI也能写出好补丁，按来源封杀既不公平，也抓不住要害。真正该问的是：改动是否必要、能否验证、出错后谁收拾。生成成本接近零后，提交者会多投一些“也许有用”的草稿；这种供给过剩是经济问题，不是道德问题。
100份PR里有25份AI草稿，提交者获得25次机会，维护者承担的却是25次判断；“多写”从来不等于“多做”。
真正昂贵的是审查，不是生成
生成器优化的是产量，独立开发者被卡住的是注意力。 团队还能分摊审查，独立开发者只能自己付。我审PR时会列4项：它想解决什么、实际改了什么、测试证明了什么、依赖会不会出问题。25份AI PR按这4项核验，就是100个审查单元；即使全部值得合并，解释成本也不会消失。
最便宜的反例，是只改1行、附1个可复现测试、意图清楚的PR，它完全值得快速通过。最贵的反例，是横跨3个文件、声称“已修复”却无法复现原问题的PR。AI能快速给出答案，却经常不交代问题，维护者得把补丁反向还原成需求，再判断它是否值得进入仓库。
25×4＝100：生成端可以迅速交差，审查端仍要逐项证明；瓶颈从来不是“写得慢”，而是“信不过”。
一次合并，是维护债开始计息
一次合并只是代码进入仓库，不是维护责任的结束。 我把后续成本拆成3个时间点：刚合并时是否引入缺陷，依赖变化后还能否工作，下次升级时旧假设会不会重新爆炸。生成器只经历第1个时间点，维护者却可能一路赔到第3个。
在《改造 Hermes Memory Provider 的曲折历程》（2026-06-01）里，我写过要靠排除错误答案看见本质。今天我的判断更尖锐：AI不只生成错误答案，还批量生成等人排除的草稿。即使最终只有1个人维护，生成、审查、测试、升级这4种责任仍可能压在同一个人身上。
1份被接受的AI PR会经过“合并、变化、升级”3个阶段；今天省下的生成时间，可能明天就变成定位时间。
我仍然没想明白：当生成器能交100份、维护者只看得完25份时，该限制AI PR数量，要求作者披露上下文，还是给审查本身付费？我暂时没有答案。比起PR总数，我更想追踪每1份有用改动究竟让维护者付出了多少分钟；否则我们所谓的提速，是否只是把账单寄给了明天？