但到了第七周或第八周，其中一个团队遇到了瓶颈。他们甚至无法进行任何简单的修改，因为总会出问题。我与他们会面时，团队最初将问题归咎于技术债务：代码混乱、架构糟糕、仓促实现。但随着我们深入调查，真正的问题浮出水面：团队中没有人能够解释某些设计决策背后的原因，或者系统的不同部分应该如何协同工作。代码或许确实混乱，但更大的问题在于，他们对系统的理论认知，也就是他们共同的理解，已经支离破碎甚至完全消失。他们积累认知债务的速度远超技术债务，这让他们束手无策。
这篇文章现在对我来说非常应景（谢谢分享，西蒙！ ）。
本周早些时候，我开始着手开发一款 iOS 音乐播放器。这似乎是一个足够有挑战性的项目，它能帮助我成为一名更优秀的自主程序员，而且这个想法我非常感兴趣，但实际上我永远不可能独自完成。
我发现，看着代币飞速流逝，然后代码一点点变成现实，这种感觉真的会上瘾。就像玩老虎机一样：也许这次就能解决界面卡顿的问题！……哎呀，不行，代币用完了。看来得升级到Max版本了！
我还意识到，我的生活中一直缺少一些东西：创造的乐趣。我记得第一次在iPhone的Plex应用里看到我的Plex媒体库时，那种感觉就像当年我搞清楚如何修改Windows 95“现在可以安全关闭计算机了”的提示信息一样。我竟然让电脑这么做了！
没错，认知债务。
我把MVP版本搭建出来并运行了，但之后尝试重构，结果把整个代码库搞得一团糟。我完全没注意应用程序的架构，很快我就发现自己竟然用了三个不同的队列来存储媒体文件。这简直是一团糟，完全无法接受。
所以我打算把代码库全部清空，重新开始。这次，我会制定一个更好的计划。这个计划能让我更接近项目核心，让我更专注于架构设计。
让我们看看结果如何。
原文： https://margaretstorey.com/blog/2026/02/09/cognitive-debt/