生成式AI正以前所未有的速度产出代码，但人类理解的速度并未同步提升。系统"理解债务"——团队对系统实际运行逻辑的认知差距——正在成为软件安全演进的最大隐性障碍。
软件工程正在经历一场结构性变革。生成式AI让代码产出速度大幅提升，但一个根本性问题也随之浮出水面：系统正在变得无法被理解。
早在1992年，计算机科学家 Peter Naur 就在《编程即理论构建》中指出：系统不仅包含代码，还包含程序员心中为理解系统运行机制而构建的心理模型——即"理论"。当团队成员离开，理论也随之流失。
这一观点在AI时代获得了新的紧迫性。Margaret-Anne Storey 在近期研究中定义了三种系统债务：技术债务（代码质量）、认知债务（共同理解流失）、意图债务（缺乏对现状成因的合理依据）。其中，认知债务与意图债务直接指向"理解"的缺失。
一个不被理解的系统，无法安全地演进。
研究者 Arvind Narayanan 和 Sayash Kapoor 将软件工程师的工作描述为"决策—执行—交付"三明治，而理解是这三层的先决条件。生成式AI压缩了中间的执行层，但理解必须在两端有意识地构建——在生成之前理解设计意图，在生成之后验证输出是否匹配。
理解在设计、实现、验证三个阶段自然形成。开发者通过亲手编写代码建立起心理模型。
执行层被压缩，理解不再自然产生。必须在"生成前"与"生成后"有意识地构建，否则理解债务持续累积。
注：对比基于Narayanan & Kapoor的"决策—执行—交付"模型，左侧为传统软件工程流程，右侧为AI辅助下的新流程。理解债务的积累速度取决于两端理解构建的投入程度。
理解债务并非突然出现，而是由三股力量以不同速度持续侵蚀系统可理解性。三股力量叠加，加速了"理论"的流失。
去中心化架构决策虽消除了瓶颈，却导致整体视图破碎。各团队深耕自身子领域，却逐渐丧失对系统边界为何如此划定的理解。缺乏共同治理时，各团队的理论相互背离，知识碎片化加剧。
当人员离开，他们带走了部分"理论"。新成员必须从头重建，而现有文档通常只记录"是什么"，而非"为什么"。缺乏历史背景的新人不得不采取战术性修补，侵蚀架构完整性。
这是最新且增长最快的因素。AI减少了实现工作量，但正是这些工作原本在开发者心中构建起系统的思维模型。交付压力下，"不理解就交付"的倾向正在渗透企业级软件。代码通过所有质量检查，但理解从未真正建立。
注：三股因素以不同速度、不同方式侵蚀可理解性，其中AI加速是最新且最隐蔽的——它不会主动发出预警，系统仍然通过各个关卡，背后的理论基础却在悄然削弱。
架构师可以通过监控若干关键指标，量化系统可理解性的流失。这些指标构成了"适应度函数"——它们自动检测理论流失的先行信号，但无法替代人类对设计意图的判断。
指标是调查的触发点，而非目标。
注：以上指标中，PR规模、设计评审、代码所有者策略可强制执行；其余指标更适合监控，阈值仅作为调查触发点，避免被钻空子绕过。
应对理解债务，核心是建立可理解性检查点——在AI生成代码之前和之后，有意识地进行理解验证。
设计审查比代码审查更重要。人工审查者的作用不是把关质量（那是自动化测试的职责），而是把握设计意图，构建关于功能变更及其原因的理论框架。
持续维护共享模型同样关键。个人理解是必要的，但仅靠个人理解远远不够。通过跨模块结对编程、轮换机制、去中心化架构决策，促进知识在团队中流动，避免理论孤立存在于某一位工程师手中。
注：应对策略可分为两类——"生成前"的策略（设计审查、意图文档）确保理解先行，"生成后"的策略（手动提交信息、代码审查）验证理解是否真正建立。两者缺一不可。
理解债务与技术债务有一个关键区别：技术债务可以通过重构逐步清偿，而理解债务一旦累积，会从根本上削弱系统安全演进的能力。
当智能体生成代码的速度超过人类理解的速度，组织面临的不是效率问题，而是认知脆弱性问题。系统仍然通过所有测试，但团队对其运作方式的共同理解正在悄然流失。更隐蔽的是，这种流失不会主动发出预警——直到某次关键变更引发意料之外的连锁故障。
那些将"理解"视为流程副产品而非架构特性的团队，在AI时代将面临越来越高的认知利息。
可理解性是一种架构特性，而非文档任务。在AI生成代码的时代，有意识地构建理解不是效率的妥协，而是系统能够安全演进的必要前提。不解决理解债务的团队，终将被自己的系统反噬。
将可理解性纳入架构特性的首要指标。
为每个核心模块设置"可理解性检查点"，在AI生成前后各做一次理解验证。
让工程师手动编写提交信息——这是检验理论是否真正建立的试金石。
理解债务不会自动消失，但可以从今天开始有意识地构建。