我在最近教的一门创业课程中生动地看到了这种动态。学生团队在整个学期中构建软件产品，快速行动以交付功能并满足里程碑。但到了第 7 或 8 周，一个团队撞到了墙上。他们甚至无法在不破坏意外的情况下进行简单的更改。当我与他们会面时，团队最初将其归咎于技术债务：混乱的代码、糟糕的架构、仓促的实现。但随着我们深入挖掘，真正的问题出现了：团队中没有人能解释为什么做出某些设计决策或系统的不同部分应该如何协同工作。代码可能很混乱，但更大的问题是系统的理论，他们的共同理解，已经碎片化或完全消失了。他们积累认知债务的速度比技术债务还快，这使他们瘫痪了。 我认为这是一个值得思考的有价值的话题，但当我思考它时，我以类似于我看待技术债务的方式来看待它。许多人将技术债务视为在一个草率的代码库中积累的坏东西——糟糕的模块边界、糟糕的命名等等。我用"垃圾"（cruft）这个术语来表示那样的坏东西，我用技术债务比喻作为一种思考如何处理垃圾带来的成本的方式。要么我们支付利息——使对代码库的每次进一步更改都变得更难一点，要么我们偿还本金——进行明确的重组和重构以使代码更容易更改。 在认知领域中，这种垃圾和债务比喻的分离是什么？我认为垃圾的等价物是无知——既对代码也对代码正在支持的领域。然后债务比喻仍然适用，要么添加新功能的成本更高，要么我们必须进行明确的投资来获得知识。债务比喻提醒我们，我们做什么取决于它们之间的相对成本。对于认知问题，这些成本同时适用于人类和精灵（The Genie）。
Martin Fowler他们探讨的一种情况，我同样觉得这是一个非常有价值的话题，当vibe coding的代码规模很大时，哪一天他的改动达不到我们的期望时，我们无法对代码做改动，导致原来的代码价值很低。
Fragments: February 13
fragments 13 Feb 2026