5.0
关注
AI SCORE
观点评论2026-05-18 20:08
认知债务比技术债务更危险
DEV Community · Julien Avezou#团队协作#代码质量
Editor brief · 编辑速览
技术债务已广为人知，但团队对陌生代码的理解缺陷（认知债务）往往被忽视。文章讨论如何识别和改善代码可理解性问题。
技术债务已广为人知，但团队对陌生代码的理解缺陷（认知债务）往往被忽视。文章讨论如何识别和改善代码可理解性问题。
你有没有曾经被抛进一个陌生的代码库，同时截止日期逼近、压力不断上升、故障越来越难以解决？
我经历过，这不是一段愉快的经历。
这让我开始思考工程团队很少衡量的一种负债。
某种更微妙的东西：
我把 comprehension debt（理解债）定义为系统变化的速度与团队对系统的理解程度之间的差距。
而 AI 正在让这个差距变得更加重要。
AI 没有创造这个问题。
这个问题早在 AI 出现之前就存在了。
团队始终都在与知识孤岛、未文档化的系统、脆弱的所有权和"只有一个人知道这怎么工作"的局面作斗争。
但 AI 可以加速这个问题。
当 AI 帮助我们更快地编写、重构和交付代码时，代码库的演进速度可能会超过团队对系统的共享理解。
配合强有力的代码审查、解释、文档和所有权，这是有用的。
但当它演变成这样就很危险：
"代码改了，但没人真正对系统的理解有所加深。"
这就是我想让其更加可见的那种风险。
如果我能以某种方式量化 comprehension debt 呢？至少达到一定程度的近似。
我开始探索会影响理解程度（无论是改善还是恶化）的各种变量和因素。
基于我自己的经历、与其他工程师的对话以及我在不同团队中看到的模式，我开始构建一种评分方法来近似衡量 comprehension debt。
我的目标是帮助工程团队发现关键或高度关联的系统何时变化速度超过了团队对其的理解。
让我们从更正式的定义开始：
当系统影响、复杂性、依赖表面积、变化速度和 AI 辅助的变化速度超过团队的理解程度、覆盖范围、冗余度、文档质量和人工所有权时，comprehension debt 就产生了。
我的理论基础不仅仅来自纸面。
我最近在我过去的一个团队中亲身经历了高 comprehension debt 的负面影响。
那是一段压力很大且令人沮丧的经历。
我常常感到落后，不得不努力跟上。
随着时间推移，故障变得越来越严重，越来越难以解决，因为团队对系统的理解水平太低了。
服务存在。
工单不断流转。
但系统的共享心智模型没能跟上。
这是一个很难的工作状态。
你总是在被动应对。
你不仅仅在调试故障。
你在调试自己对上下文的缺失。
AI 辅助开发可能非常有用。
我自己经常使用 AI。
但我总是回到这个问题：
我们是在增加交付速度而不增加理解速度吗？
因为这两者不是一回事。
一个团队可以交付更多代码，同时对系统的理解却随时间推移而减少。
AI 可以帮助生成实现方案、重构代码、解释文件、编写测试和加速重复工作。
但如果 AI 辅助的改动被合并时没有足够的人工解释、审查、文档或所有权，comprehension debt 就会更快地积累。
更好的问题应该是：
"团队是否仍然能够安全地解释、审查、修改、部署和恢复这个系统？"
这不是要成为一个完美的数学模型。
这是一个尝试，目的是让一个隐形的工程风险变得足够可见，以便讨论、比较和改进。
从高层看，评分结合了两个方面：
这些因素增加 comprehension debt：
这些因素减少 comprehension debt：
所以粗略的模型是：
Comprehension Debt =
系统压力
+ 依赖压力
+ 所有权集中度
+ 可选的 AI 加速
减去
人工覆盖
+ 文档质量
+ 审查冗余度
+ 近期接触
+ 运维熟悉度
为了检测危险的缺口，对关键系统执行最小可行覆盖（MVC）检查。
对于关键系统，该表格检查它是否拥有：
如果缺少其中任何一项，系统就会被标记为 MVC 缺口。
即使整体债务评分看起来中等，具有 MVC 缺口的关键系统也应该被标记。
我非常欢迎关于如何改进这一方法的反馈。
什么信号告诉你团队开始失去对一个系统的理解？
你是否注意到 AI 改变了系统演进速度与团队理解速度之间的相对关系？
我认为随着 AI 生成和自动化的加速，这将成为一个更大的工程领导力问题。
我们在生成代码方面做得越来越好。
但我们仍然需要在保持共享理解方面做得更好。
为了让这个问题更容易理解，我把这个方法转化为了一个电子表格模板：System Comprehension Heatmap
工程师-系统矩阵
可选的 AI 加速评分
最小可行覆盖检查
快速入门 PDF 指南
你可以免费获取它
我很想听到你的反馈。