【Gemini翻译】 《认知债：当速度超越理解》http://t.cn/AXcl8MlF

这位工程师在一个迭代（Sprint）中交付了七个功能。DORA 指标看起来完美无瑕。晋升报告简直是信手拈来。

六个月后，一项架构变更需要修改这些功能。团队中没有人能解释为什么某些组件存在，或者它们是如何交互的。开发它们的工程师盯着自己的代码，就像盯着陌生人的代码一样。

代码的生产成本已经变得比理解成本更低。

【理解滞后】

当工程师手动编写代码时，会同时发生两个并行过程。第一个是生产：字符出现在文件中，测试被编写，系统发生变化。第二个是吸收：心理模型形成，边缘案例变得直观，架构关系固化为理解。这些过程是耦合的。打字的动作迫使大脑参与。实现的摩擦为推理创造了空间。

AI 辅助开发解耦了这些过程。一个提示词（Prompt）在几秒钟内生成数百行代码。工程师进行审查、调整、迭代。产出加速了。但吸收无法成比例地加速。真正理解构建了什么、为什么要这样构建以及它与其它所有事物的关系的认知工作，仍然受限于人类的处理速度。

这种产出速度与理解速度之间的差距就是认知债。

与通过系统故障或维护成本表现出来的技术债不同，认知债对速度指标是不可见的。代码运行正常。测试通过。功能交付。赤字仅存在于构建系统的工程师脑海中，表现为对自己工作的某种不确定性。

债务并非真正不可见。它最终会出现在可靠性指标中：平均恢复时间（MTTR）拉长，变更失败率（CFR）攀升。但这些是滞后指标，与驱动季度决策的速度指标相比，存在数月的滞后。当 MTTR 发出问题信号时，理解赤字已经复利增长了。

【组织实际衡量的是什么】

工程绩效体系演变为衡量可观察的产出。完成的故事点。交付的功能。合并的提交。审查周转时间。这些指标出现在产出与理解紧密耦合的时代，那时交付某样东西意味着理解某样东西。

指标从未直接衡量理解，因为理解是被默认假设的。交付功能的工程师被假定理解该功能。这一假设之所以成立，是因为生产过程本身迫使了理解的产生。

该假设不再成立。工程师现在可以在仅维持对实现表面熟悉的情况下交付功能。功能可以运行。指标记录了成功。传统上随这些功能一起积累的组织知识，根本没有以同样的速度形成。

绩效校准委员会看到了速度的提升。他们看不到理解的赤字。他们看不到，是因为组织衡量系统的任何产物都没有捕捉到这个维度。

【审查者的困境】

关于认知债的讨论通常集中在生成代码的工程师身上。更尖锐的问题在于审查代码的工程师。

代码审查演变为一种质量门。资深工程师检查初级工程师的工作，捕捉错误，提出改进建议，转移知识。限速因素始终是初级工程师的产出速度。资深工程师审查的速度快于初级工程师生产的速度。

AI 辅助开发倒置了这种关系。初级工程师现在生成代码的速度快于资深工程师批判性审计的速度。生成的代码量超过了进行深度审查所需的带宽。必须有所取舍，通常牺牲的是审查深度。

审查者面临着不可能的选择。维持以前的审查标准，成为抵消 AI 带来的速度增益的瓶颈。或者按照代码到达的速度进行批准，并寄希望于测试能捕捉到审查遗漏的问题。大多数人选择后者，通常是无意识的，因为组织压力倾向于吞吐量。

这就是认知债复利增长最快的地方。作者的理解赤字可能通过随后与代码的接触而恢复。审查者的理解赤字则会传播：他们批准了自己并不完全理解的代码，而这些代码现在带有隐含的认可。组织关于“被审查的代码即是被理解的代码”的假设不再成立。

【倦怠模式】

大量使用 AI 工具的工程师报告了一种与传统倦怠不同的特定疲惫形式。传统倦怠源于持续的认知负荷，即在解决复杂问题时大脑需要承载过多的东西。新模式则源于更接近认知断层的东西。

工作进展很快。进步显而易见。但工程师体验到一种持久的感觉，即不太能掌握自己的产出。他们可以执行，但解释需要重新构思。他们可以修改，但预测变得不可靠。他们构建的系统即使运行正确，也感觉有些陌生。

这创造了一种独特的心理状态：高产出结合低信心。工程师产出更多，同时对自己产出的东西感到更不确定。在根据可见产出进行堆叠排名的组织中，这产生了一种压力，迫使人们即使在不确定性增长的情况下也要继续生成。

停下来深入理解所建内容的工程师在速度指标上会落后。优先考虑吞吐量而非理解的工程师则能达成季度目标。激励结构选择了加速认知债积累的行为。

【当组织记忆失效时】

工程组织中的知识以两种形式存在。第一种是显性的：文档、设计文档、记录的决策。第二种是隐性的：随着时间推移构建和维护系统的人脑海中的理解。隐性知识无法完全外化，因为它很大程度上作为直觉、模式识别和上下文判断而存在，这些是在直接参与工作中形成的。

当构建系统的人离开或轮岗到新项目时，隐性知识也随之流失。组织传统上通过工程工作的正常过程来补充这些知识。在现有系统基础上构建的新工程师，通过实现的摩擦发展出自己的隐性理解。

AI 辅助开发潜在地短路了这种补充机制。如果新工程师可以在不形成深度理解的情况下生成有效的修改，他们就永远不会形成传统上会积累的隐性知识。组织失去知识不仅是通过人员流失，还因为形成不足。

这创造了一种延迟的失效模式。系统继续运行。新功能继续交付。但真正理解系统的人才储备逐渐耗尽。当环境最终需要这种理解时——当某样东西以意想不到的方式崩溃，或者需求变化需要架构推理时——组织就会发现赤字。

【债务如何复利】

随着认知债的积累，会出现三种失效模式。

第一种涉及到一个通常可靠的启发式方法的反转。工程师通常信任已经在生产环境中运行多年的代码。如果它存活了那么久，它可能就是有效的。代码存在的时间越长且没出问题，它赢得的信心就越多。AI 生成的代码反转了这种模式。它保持不动的时间越长，就越危险，因为周围人类的上下文窗口已经完全关闭。在编写时就几乎不被理解的代码，在编写者离开后变得完全晦涩难懂。

他们在调试一个由黑盒编写的黑盒。

第二种失效模式在事故期间显现。警报在凌晨 3:00 响起。值班工程师打开了一个他们没有参与构建、由他们没有监督的工具生成、以假设他们具备并不拥有的熟悉度的方式记录的系统。他们正在调试一个由黑盒编写的黑盒。当有人理解系统时，本可以是十分钟的修复，在没人理解时变成了四小时的取证调查。将此乘以足够的事故，总成本就会超过 AI 辅助开发所提供的任何速度增益。

组织实际上是在用未来的主任工程师（Staff Engineers）储备换取本季度的功能交付。

第三种失效模式在更长的时间尺度上运作。主要依赖 AI 辅助开发的初级工程师永远无法形成手动实现带来的直觉。他们交付功能，却没能形成支撑架构判断的“伤疤组织”。组织实际上是在用未来的主任工程师储备换取本季度的功能交付。由于五年后本应成为资深架构师的人才尚未缺席，这种成本不会出现在当前的人头模型中。他们只是从未形成。

【总监视角】

从工程领导层的角度来看，AI 辅助开发表现为生产力的提升。团队交付更快。路线图被压缩。招聘讨论变得更有利。这些是传播到组织汇报结构中的可观察信号。

在这些团队中积累的认知债并不表现为信号。没有“能在不重新阅读的情况下解释自己代码的工程师”这一指标。没有“组织理解深度”的仪表盘。这个概念不符合季度业务回顾格式或人员编制辩护叙述。

总监根据可观察的信号做出决策。当这些信号一致表明成功时，加大对产生这些信号的方法的投入，在领导层可用的信息环境下是理性的。决策根据数据来看并没有错。只是数据是不完整的。

【该模型的局限性】

认知债框架并不适用于所有工程工作。有些任务确实是机械性的。有些代码库确实受益于不带深度架构理解的快速迭代。有些功能确实不需要通过手动实现形成的理解水平。

该模型还假设理解以前是以足够的速度形成的。这个假设可能过于慷慨。工程师在对自己工作的理解深度上一直存在差异。分布可能只是在发生偏移，而不是出现了一个全新的现象。

此外，工具和文档实践可能会进化以部分缩小理解差距。如果组织开发出捕捉和传递 AI 辅助开发未能有机形成的理解的方法，债务可能证明是可控的，而非累积性的。

【衡量问题】

系统正针对其衡量的内容进行正确的优化。但它衡量的内容已不再能捕捉到真正重要的东西。

根本挑战在于组织无法优化他们无法衡量的东西。速度是可衡量的。理解则不然，或者至少通过目前反馈到绩效评估、晋升决策或人员规划中的任何机制都无法衡量。

在理解变得对组织决策系统可见之前，激励结构将继续倾向于速度。优先考虑理解而非产出的工程师，看起来会比优先考虑产出而非理解的同行生产力更低。绩效校准将奖励那些债务积累更快的行为。

这不是个别经理或工程师的失败。这是一个为生产与理解相耦合的时代设计的衡量系统，运行在一个该耦合不再成立的时代。系统正针对其衡量的内容进行正确的优化。但它衡量的内容已不再能捕捉到真正重要的东西。

差距最终会显现。无论是通过超出预期的维护成本，还是通过需要无人具备的理解能力的事故，亦或是通过暴露了在缺乏深度理解的情况下构建的系统的脆弱性的新需求。显现的时机和形式仍不确定。但潜在的动态却是确定的。