AI委托悖论：你无法评估自己不会做的工作

每个曾将模块委托给外包的工程师都知道那种感觉：代码交回来了，测试通过了，演示也能跑——但你完全不知道它到底好不好。你没有写它，你不完全理解其中蕴含的决策，而你即将进行的审查更像是走过场而非真正的实践。现在把这种动态乘以你代码库中每一个AI辅助的提交。

AI委托悖论很容易表述，却很难逃脱：你最需要用来评估AI生成工作的技能，恰恰是你停止亲自动手后退化最快的技能。这不是未来的风险，而是正在发生的事实，在那些拥抱AI编码工具的工程组织中已经可以量化测量。

自信与能力的倒挂

近期研究中最令人不安的发现不是AI工具有时会产生糟糕的代码，而是开发者系统性地误判了他们所获得产出的质量。

METR在2025年进行的一项随机对照试验发现，经验丰富的开源开发者在使用AI编码工具时实际上慢了19%——而他们自己认为快了20%。这是感知与实际表现之间39个百分点的差距。研究结束后，69%的参与者表示他们仍会继续使用这些工具。

这不是固执，而是一个测量问题。AI工具生成的代码看起来正确。它能编译，遵循命名约定，有合理的结构。失败之处是微妙的：遗漏的边界情况、被忽略的现有模式、在特定部署环境中不成立的安全假设。发现这些问题需要的恰恰是通过编写代码（而非审查代码）才能建立起来的深层系统理解。

自信与能力的倒挂在初级工程师身上打击最大。Qodo的2025年AI代码质量状况报告数据显示，工作经验不足两年的开发者报告的AI工具质量改善最低（51.9%），但在未审查的情况下提交AI代码的信心最高（60.2%）。高级开发者看到更高的质量收益（68.2%），但对未经审查就提交代码的信心远低得多（25.8%）。经验教会你知道自己不知道什么，而缺乏经验则不会。

理解力债务：无人追踪的指标

技术债务有成熟的词汇体系。理解力债务没有，这本身就是问题的一部分。

理解力债务是系统中存在的代码量与任何人类工程师真正理解的代码量之间不断扩大的差距。与技术债务不同，它是隐形积累的。测试通过。Linter清洁。DORA指标看起来健康。但对系统实际如何运作的集体知识正在底层侵蚀。

Anthropic在2026年1月的一项研究跟踪了52名学习异步编程的工程师。AI辅助的参与者完成任务的时间与对照组大致相同，但之后的理解力测试得分低了17%——50%对67%。最大的性能下降恰恰发生在调试任务中。研究人员识别出六种不同的AI交互模式，只有那些需要主动认知参与的模式才能保持学习成果。被动委托——让AI解决问题并接受结果——无论输出多么正确，都会损害技能形成。

这创造了一个反馈循环。委托越多的工程师对代码库的理解越少。理解越少，他们审查AI输出的能力越差。审查效果越差，他们遗漏的Bug越多。遗漏的Bug越多，他们就越信任AI的输出（因为Bug直到生产环境才会暴露）。越信任，就委托越多。

GitClear对2.11亿行代码的分析量化了一个症状：代码重复相比AI之前的基准增长了4倍，而重构从代码变更的25%下降到不足10%。在他们的数据集中，复制粘贴代码首次超过了移动（复用）代码。代码库增长更快，同时变得更不被理解。

软件外包的前车之鉴

这种模式并不新鲜。软件行业在2000年代和2010年代的离岸外包浪潮中已经经历过类似的版本。

套路很熟悉：把工作发给更便宜、更快的团队。收到看起来完整的交付物。几个月后发现架构站不住脚，测试覆盖是表面文章，原团队中没有人足够了解系统来维护它。失败模式从来不是"外包团队写了烂代码"，而是客户团队评估工作的能力与他们委托出去的工作量成正比地衰退了。

在每一个被标记为"供应商失败"的外包灾难背后，更深层的真相通常是相同的：客户方有人停止了关注，或者从未深入参与到能够有效关注的程度。验证能力退化了，因为客户团队不再亲自做这项工作，而你无法在停止实践的工作中保持专业能力。

AI委托以个人开发者的速度而非组织速度重现了这种动态。不是一个团队在几个季度内逐渐失去系统理解，而是单个开发者可以在几周内积累理解力债务。AI是世界上最快、最随叫随到、最顺从的外包商——当你不再仔细审查时，它从不反驳。

加载中…