三重债务：软件系统中意义的三大威胁

几周前，我在滑铁卢大学就“三重债务模型”进行了演讲。 在那次演讲中，杰西·霍伊发现， 三重债务模型与皮尔士在19世纪提出的符号学三元模型之间存在着有趣的关联。

简而言之，符号学是研究符号如何产生意义的理论。皮尔士的模型包含三个不可或缺的要素，只有当这三者同时发挥作用时，意义才能得以形成。

• 对象：被理解的事物（例如：在十字路口必须停车这一概念）。 • 符号：对被理解的概念所作的有形表征（例如：一个红色的八角形停车标志）。 • 解释者：基于其先前经验，在解释者心中所形成的含义或理解（例如：一位驾驶员驶抵十字路口）。

皮尔士认为，要使意义得以产生，这三个部分缺一不可。 符号不仅只是“指向”对象，它还能帮助在解释者的脑海中构建对该对象的解读， 并在此基础上，结合其已有的知识和过往经验来加以深化。

以皮尔士的三元结构为视角，审视三重债务模型：软件系统即为对象； 意图文档是传达系统逻辑的符号；而理解则是在开发人员的心智中，基于他们自身的先前经验而逐步建构起来的。 若这些符号缺失、过时，或彼此矛盾，那么意义便可能难以重建。 正是通过这一模型，我得以在一篇关于缺失的停车标志的帖子中， 阐释出意图债务与认知债务、技术债务之间的区别，以及为何在当今这个充满代理式开发的世界中， 意图债务至关重要。

皮尔士指出，如果符号学三元结构中的任何一部分出现薄弱，意义便会随之退化。 举例来说，如果对象发生了变化，但符号却没有相应调整，那么这些表征就会变得具有误导性。 我们常常在软件开发中看到这样的现象：当代码发生变更、用户需求不断演变时， 若意图文档或上下文未及时更新，就可能导致解读出现偏差或不完整。 另一方面，如果符号过多，也会让解读变得更加困难，尤其是当解释者本身对相关知识的理解尚浅时。 在最近的一篇帖子中，我探讨了过多的符号如何在代理式软件开发中引发认知债务的问题。

我们可以将“三重债务”视为软件系统中三种不同的意义威胁。 技术债务会削弱整个系统本身；意图债务会削弱那些用来传达系统逻辑的符号； 而认知债务则会削弱开发人员和团队构建并维护对系统共同理解的能力。

展望未来，我们需要为代理和人类设计更优质的“符号”，并且需要找到更好的方法，帮助人类——尤其是人类——识别并选择正确的符号，从而基于自身的经验和专业知识，构建出真正有意义的意义。 然而，首先，我们需要弄清人类与人工智能代理如何实现高效协作。什么样的认知支持能够帮助开发人员理解人工智能生成的各类成果，判断哪些输出应予以采纳或拒绝，并确定生成的代码与意图文档是否真正准确地反映了他们以及最终用户的真实意图？

我们已经积累了数十年的程序理解研究成果，并且对开发人员如何理解和驾驭软件有着深入的了解。 但我们仍不清楚的是：当代码、规范、设计以及系统逻辑越来越多地由多个代理在人为监督控制下生成， 而开发人员必须在工具、对话以及时间维度上穿梭、寻找线索时，这些理论又将如何发挥作用？ 软件开发方式的这些变革，或许会从根本上改变软件团队中意义的构建与维护方式。

我们目前主要专注于为代理设计工具，但那些需要跟上节奏、理解代理所生成的内容、并维护共享理解的人类又该如何应对呢？我们仍在努力探索这一问题的答案。

更多阅读

• 《三重债务》论文，ACM Queue，2026年5月 论文链接

• 皮尔士的符号学三元模型及其意义解析，可参见此链接

• 《缺失的停车标志：为什么某个项目可能拥有高意图债务，却低认知债务》博客文章

• 《符号虽在，我们却仍迷失：项目为何可能拥有低意图债务，却高认知债务》博客文章

• 安妮·维拉的《中间循环》（监督式工程实践）博客文章

• 《认知之旅》（一款用于修复认知债务的工具）帖子