有个现象越来越普遍：某位工程师在一个迭代里狂揽八个需求。交付数据相当漂亮（DORA 指标），晋升材料写得更是顺理成章。
但半年后，当架构调整需要改动这些功能时，尴尬的事情发生了——团队里没人能解释清楚当初为啥这么写，甚至连当事人看着自己的代码都一脸懵，仿佛在看陌生人的遗物。
这揭示了一个正在发生的深刻变化：现在的代码，生成的成本已经比理解它的成本还要低了。
理解的滞后：代码“生产”与“内化”的脱钩
以前手写代码时，其实是在干两件事：
- 生产：代码敲进文件，测试写好，系统跑通。
- 内化：脑子里建立起模型，搞懂了边缘情况，弄清了架构关系。
这两件事是锁死的。敲代码的苦功夫，逼着你必须深度思考。
但 AI 辅助开发把这把锁给撬开了。一个提示词，几百行代码秒出。工程师要做的只是看看、改改。输出速度起飞了，但“脑子跟上”的速度没变。真正搞懂“写了啥”、“为啥这么写”、“跟其他模块啥关系”，还得靠人脑慢慢磨。
这种 “生成速度”和“理解速度”之间的剪刀差，就是“认知债务”。
和技术债不一样，认知债务是隐形的。代码能跑，测试能过，功能按时上线。这种债务只存在于开发者的脑子里，表现为对自己写的东西心里没底。
指标的假象：被速度掩盖的“空心化”
现在的工程绩效体系，测的都是看得见的东西：干了多少活？上了多少线？代码提交量多少？
这套体系诞生于那个“写出来就代表懂了”的时代。那时候，交付即理解。
现在，这个逻辑不成立了。 工程师现在可以只懂个皮毛就把功能推上线。原本该在开发过程中积累下来的组织经验，根本没沉淀下来。绩效考评只看到了效率提升，却没人能看到理解的亏空。
等到半年后，线上故障修复时间（MTTR）变长，回滚率飙升，这些滞后指标亮红灯时，认知债务的利息已经高得还不起了。
代码审查的死局：高级工程师也难为无米之炊
提到认知债务，大家常担心写代码的人。其实更惨的是审代码的人。
以前 Code Review 是个质量关卡。高级工程师审初级工程师的代码，抓虫、指导、传帮带。瓶颈通常在写代码的人手里——高工看得比写得快。
AI 开发把这个关系倒过来了。现在的初级工程师（甚至高工自己）生代码的速度，远超高级工程师深度审计的速度。
这就陷入了两难：
- 坚持审细？那你就是阻碍 AI 效率的瓶颈。
- 走马观花点通过？那就是在赌测试能兜底。
大多数人在无意识中选了后者。因为组织逼着要吞吐量。结果就是，Reviewer 批准了自己都没完全看懂的代码，“已审查”的标签变得毫无含金量。
新型倦怠：高产出的“心虚”
重度使用 AI 的工程师，正在产生一种特殊的疲惫感。
这种累不是因为脑力消耗大——毕竟活儿干得很快。这种累源于一种 “疏离感” 。活是干完了，但总觉得自己像个局外人。要解释原理得重新看代码，要改需求生怕改出坑。系统是自己建的，却感觉像是别人的。
这导致了一种很扭曲的心理：产出越高，心里越虚。 在那些只看产出排名的公司里，这种焦虑逼着工程师只能继续加速，用更快的交付来掩盖理解上的空虚。
停下来搞懂代码的人，KPI 跑不过那些只管撸代码的人。激励机制在奖励那些制造认知债务的行为。
黑盒套黑盒：债务的爆雷
认知债务攒够了，雷爆得比谁都响。
最典型的是 “反向信任” 。以前老代码哪怕写得烂，跑久了大家也觉得它是稳的。现在不一样了，AI 生成的老代码，谁碰谁炸。因为当初写的人就不懂，现在懂的人更是零。一旦出 Bug，相当于在调试一个“AI 写的黑盒”，本来 10 分钟能改好的小问题，变成了 4 小时的考古现场。
更长远的风险是人才断档。新人过度依赖 AI，就失去了通过踩坑积累“技术直觉”的机会。这其实是在透支未来的架构师储备，来换这一个季度的交付数据。
测不出的“理解”，迟早要还的债
在管理层眼里，AI 带来的全是红利：人效提升、排期缩短。认知债务？那是看不见的。
问题的核心在于：系统在疯狂优化它能度量的指标，但这些指标已经失真了。
现在的考核表里，并没有“不看代码能讲清楚自己系统逻辑的人数”这一项。只要理解力无法量化，激励导向就会继续向速度倾斜。这不是哪个人领导无能，而是我们的评价体系跟不上技术变了。
这笔账最终是要还的。要么是高昂的维护成本，要么是无人能解的重大事故，要么是面对新需求时的一推就倒。当下的“人效提升”，可能只是对未来的一次提前透支。
要破局，或许得从把‘理解力’纳入工程效能指标开始——毕竟，能讲清楚的代码，才是好代码。
