我所听到的关于 Cognitive Debt（截至目前）

Source: Hacker News

一周前，我写到了生成式和代理式 AI 可能正在放大我所称的认知债务：即系统不断演变的结构与团队对该系统如何运作、为何运作以及随时间如何改变的共享理解之间累积的差距。

这篇文章在不同社区引发了深思的讨论。与其逐条回复，我想把我听到的内容进行综合，并将其与我所阅读的其他思考联系起来。随着讨论的进展，我可能会对本文进行更新。

对共享理解日益增长的担忧

几位从业者，包括 Simon Willison 和在 Hacker News 对 Martin Fowler 文章的讨论 中的其他人，描述了他们直接经历认知债务的情况。他们谈到在自己的项目中迷失方向，发现更难自信地添加新功能。他们可以更快地推进，但失去了将决策与意图、意图与代码相连接的更深层次的意义构建。

这不仅仅是代码质量的问题。它关系到个人开发者和产品团队是否能够保持对系统正在做什么以及为何如此的连贯心智模型。

在这些讨论中，一个主题始终如一：速度可能超过理解。

认知债务伤害开发者，而不仅仅是软件

Technical debt lives in the code.
Cognitive debt lives in people.

当共享的理解逐渐瓦解时，痛点会体现在：

• 对变更失去信心
• 评审负担加重
• 调试摩擦增多
• 入职速度变慢
• 压力与疲劳

软件可能仍然“能运行”，但系统的理论变得更难获取和跟踪。成本不仅是结构性的，更是体验性的。

Siddhant Khare 已经写过关于AI 疲劳的文章。Steve Yegge 反思了由 AI 加速开发导致的倦怠。Annie Vella 则优雅地论述了当系统变得更难推理时，不确定性的情感与认知体验。这些观点强化了这样一个认识：这不仅是工程学科的问题，更影响开发者的感受和工作方式。

认知债务，像技术债务一样，必须偿还

Martin Fowler 指出，和技术债务一样，cognitive debt must eventually be repaid。我赞同。

重建丢失的知识需要恢复系统的分布式理论。这包括捕获意图、决策背后的理由、关键约束以及架构如何支持变更。

这种理论并不仅仅存储在代码中。它分布在：

• 人员
• 文档
• 测试
• 对话
• 工具
• 以及日益增多的 AI 代理

偿还意味着维护所有这些，而不仅仅是重构代码或更新架构文档。

在必须快速推进的压力下——无论是初创公司争取学习速度，还是大型组织推动 AI 采纳——这种偿还往往显得成本高昂且容易被延后。

“这只是工程”，但激励正在改变

几位评论者（包括 Michael Würsch）认为，cognitive debt reflects a failure of good engineering discipline。明确的规格、严格的评审、广泛的测试以及明确的架构文档应该能够防止知识流失。

原则上，我同意。实践中，激励正在转变。AI 降低了生成结构的成本，使得结构的演进速度可能快于共享理解的稳定。即使是有纪律的团队也必须有意识地限制或塑造其实践，以保持理解与变化保持一致。

如果规格和文档不是团队积极参与的活的工件，它们就不足以满足需求。

新兴的缓解策略

令人鼓舞的是，许多读者分享了他们是如何缓解认知债务的。他们描述了：

• 更严格的审查实践
• 编写捕捉意图的测试
• 持续更新设计文档
• 将原型视为一次性使用

还有一些人提到使用AI 来降低这些实践的成本，甚至用于支持认知跟踪、依赖管理和解释。

如果有意识地使用，AI 可能有助于让认知工作更加可见，而不是被掩盖。

开放性问题：高绩效团队将如何适应？

高绩效团队一直在有意识地管理技术债务。随着 AI 在初创公司和大型企业中的广泛采用，问题变成了团队将如何管理认知债务。

• 他们将如何塑造社会技术实践和工具，以外化意图并维持共享理解？
• 他们将如何利用生成式和代理式 AI，不仅加速代码产出，还保持团队的共同理论？

随着 AI 减少技术摩擦，共享理解可能会成为绩效的瓶颈。

我会继续关注这一演变。如果你在真实团队中看到有效的缓解实践，期待向你学习。