如果你还在争论"AI 写的代码能不能用"，外面的问题已经换成了"AI 代码合并之后，谁来负责"。一边是平台数据说近一半新代码已经出自 AI，一边是严格的随机对照实验发现资深开发者用了 AI 反而慢 19%。这两件事都是真的，中间差着的，是一笔每个认真用 AI 写代码的人都该算清的账——认知债务。
先看两组打架的数据
2026 年发表于《Management Science》的三项随机现场实验，汇总了 4867 名开发者，随机获得 AI 代码补全工具的人，完成的任务或提交审查的代码改动数量，平均增加约 26%。知乎这是目前"挺 AI 派"最硬的证据：真实工作场景里，补全类工具确实能抬高某些任务的产出。
但另一组实验的对象，是 16 名维护着平均超百万行代码库的资深开源开发者。他们原本估计，使用AI以后，完成任务的时间能减少24%。结果他们在AI的帮助下把246个真实任务做完，反而多花了19%的时间。有意思的是，试验结束以后，这些程序员觉得AI让自己快了20%。知乎实测慢 19%，体感快 20%，这个反差就是坑的位置。矛盾根源并不难解释：两边测的不是同一批人、同一种工具、同一类任务。补全工具对付边界清晰的小任务立竿见影；智能体钻进熟悉的复杂老项目，光解释背景就可能比自己动手更贵，而流畅的生成过程又让人系统性低估等待和返工。
更真实的细节是：METR 试验中，虽然程序员使用AI后平均变慢了，但试验结束后仍有69%的人继续使用Cursor。知乎对很多人来说，AI 的价值不只是省时间，少查资料、少写样板代码本身就值得付费。所以"用不用"早就是伪问题，真问题是"怎么把账算清"。
你真正欠下的，是认知债务
写代码从来不是软件开发里最贵的环节。假设一个功能原来需要100小时，其中25小时用于写代码，另外75小时用于理解需求、设计方案、阅读旧代码、测试、评审和上线。现在AI让写代码快了5倍，25小时变成5小时，但整个功能却仍然需要80小时。知乎AI 压缩的恰好是最便宜的那一环，最隐蔽的成本因此转移到了两个新词上。
第一个叫理解债务。学术界把这个现象叫做理解债务。系统在跑，但没有任何一个活人脑子里有这套系统完整的结构图。知乎把需求扔给 AI、AI 一次改十几个文件、测试跑通就合并，人与系统之间就出现了一道认知断层。几个月后故障告警，原作者看代码的反应和看陌生人代码一模一样，翻出版本记录才发现，那是自己三个月前按下回车接受的方案。
第二个叫复用崩塌。这一点GitClear在2026年发布的针对六亿多次代码变更的分析报告里表现得非常明显。数据显示，代码库里的跨文件函数复用率在断崖式下降，而重复的代码块和复制粘贴在急剧增加。知乎逻辑很简单：上下文没给足时，AI 不会全库搜索现成的工具类，当场新写一个辅助函数最快、也最不容易在生成阶段报错。时间一长，系统里就会长出五套时间格式化函数、三套大同小异的鉴权逻辑，每个文件单看都完美，整个系统却在加速膨胀。
膨胀的代价最终由真实事故买单。今天知乎上刷屏的一个案例：一名工程师把订单状态流转的需求喂给智能体，几百行代码几分钟生成，单元测试全绿，直接合并。三个星期后，线上开始零星出现订单状态错乱的客诉。知乎排查发现，AI 为了让单元测试通过，在缓存层做了一套复杂的异步补偿机制，与团队"核心资金流转必须走数据库事务"的底层规范完全相悖——这条规矩没有写在任何 AI 读得到的文件里，所以 AI 不可能知道。
落到个人效率上也一样：AI虽然很快生成了代码，但开发者接受的结果却不到44%，他们要花大约9%的时间用来审查和修改AI输出，还要用4%的时间等待AI生成。知乎AI 交付的“完成品”，不到一半能直接用，剩下的都要人逐口消化。
分工结构上，2026年6月，Anthropic分析了大约40万次Claude Code真实交互，涉及约23.5万名用户。结果挺能说明目前的coding分工的：人类作出了大约70%的规划决定，AI作出了大约80%的执行决定。知乎“做什么、选哪个方案、什么算完成"还在人手里，AI 接管的是"怎么写出来”。效率天花板正好卡在这里：实现环节被压到极致，判断环节一分钟没省。
社区开始给 AI 代码立规矩
审查端的压力已经写进数据。全球最大代码平台正在被vibecoding搞废。6.3亿个仓库，将近一半新代码是AI写的，但开发者信任度从77%跌到60%。哔哩哔哩信任下滑的直接原因，是扫描出来的质量问题。
CodeRabbit扫了470个PR，AI代码严重问题是人工的1.7倍。哔哩哔哩审查压力从“看得过来”变成了“看不完”。
老牌开源项目的防守更直接：cURL砍了bugbounty，Ghostty封杀AI提交，tldraw关掉所有外部PR。哔哩哔哩Codeberg社区的成员近期以358票对144票的结果，通过了修改服务条款的决议，禁止主要包含AI编写代码的项目。哔哩哔哩一刀切的禁止之外，Rust 社区给出了更精细的样本。
目前rust-lang/rust仓库还有1281个未关闭的PR。真正稀缺的从来不是代码，而是审阅者的判断力和时间。36氪
本周，Rust 五个团队正式采纳的 AI 编程准则，核心一句话就能概括：可以用LLM回答问题、分析、提炼、完善、检查、提出建议和审查，但不能用它来创造。36氪落到操作分三层：私人用途完全放开，翻译、改错别字、找 Bug 必须披露，LLM 直接生成评论、文档和编译器诊断则明确禁止；故意隐瞒 LLM 使用情况，按与骚扰同级的违反行为准则处理。
最有意思的是它给 AI 代码装的"熔断器"：如果在任意一个六周时间窗口内，已经合并的PR中有超过一半是由LLM创建的，那么所有LLM创建的PR都将暂停合并，直到它们的占比重新下降到50%以下，而且至少要冷却10天。36氪这等于第一次把"AI 代码占比"当成需要监控的工程指标写进流程，这个思路对任何团队的合并队列都成立。
怎么用，取决于你是哪一档
对入门开发者，AI 在陌生任务上的增益最大，坑也最深：心智模型还没建立，每一次"测试绿了就合并"都是在预支认知债务。Anthropic 的数据里有个残酷对照：表现出中等以上领域知识的用户，达到明确成功标准的比例约为28%至33%，新手只有15%。知乎先想清楚自己要什么再让 AI 动手，否则它生成得越多，你后面要改得越多。
对资深开发者，那 19% 的"慢"不是工具不行，而是审查变成了主业。与其和 AI 较劲生成新功能，不如把力气花在两处：一是把团队口口相传的规矩整理成机器可读的上下文，AI 看不见的规范它一定会违反；二是反向使用 AI，让它给老代码补注释、生成机械的单元测试、批量替换废弃接口，把单向膨胀变成边建边拆。
对团队决策者，记住三笔账。第一笔，生成速度不等于交付速度，省下的时间会转移到审查环节——DORA在近期的报告里非常敏锐地提出了验证税这个概念。什么意思呢，就是你用AI省下来的写代码的时间，并没有真正变成你的闲暇时间，而是转移到了验证环节。知乎第二笔，把复用率、审查耗时、回归缺陷率做成看板，它们比"AI 代码占比"更值得盯。第三笔，借鉴 Rust 的熔断思路，给 AI 代码在合并队列里的占比设一条阈值线。
三个值得盯的后续信号
第一，Rust 第一个六周周期的数据。带 ai-assisted 标签的 LLM PR 会不会压垮合并队列，将直接决定这场实验继续还是收缩，这是"AI 代码占比阈值"第一次有了大规模量化观测。
第二，METR 已明确 2025 年的结论不能代表 2026 年代工具的能力，后续实验出现提速信号但不确定性仍大。更新版实验发布时，重点看"资深者变慢"是否被推翻，这决定本文结论的成色。
第三，GitClear 式的复用率指标会不会进入主流工程报告。一旦"代码膨胀"变成可度量的 KPI，认知债务就从感受变成了账目。
目前最诚实的结论是：真实提效已经存在，真实减速也发生过。知乎代码生成的成本正在趋近于零，判断一段代码该不该合并的能力正在变得前所未有的昂贵。先算清这笔账，再决定怎么合并。
