复杂性显现理论：让隐藏的问题变得可见

一、我们为什么需要复杂性显现理论？

在软件开发中，经常会出现一种现象：

程序员能够读懂每一段代码，却不一定能够理解整个系统；AI 能够分析很多文件，却不一定能够发现隐藏在模块之间的问题。

一个程序可能有几百个模块，每个模块单独看起来都没有明显错误，但模块之间的依赖关系可能已经非常复杂。修改一个模块，其他几个模块就出现异常。开发者反复修复局部问题，却始终找不到系统性原因。

问题出在哪里？

有时，问题并不在某一行代码，而在于代码之间的关系没有被充分呈现出来。

如果我们把模块依赖关系画成图，就可能发现循环依赖；如果把程序运行过程记录为日志，就可能发现异常发生的真实顺序；如果把状态转换画成状态机，就可能发现某些状态无法退出。

原本隐藏在代码中的问题，因为获得了新的表达形式，才变得容易被发现。

类似的现象也存在于其他领域。

一个组织中的每个人都可能认真完成自己的工作，但部门之间的协作关系可能存在严重问题。

一个决策过程中的每个步骤都可能有其局部理由，但将全部信息放在一起后，才可能发现相互矛盾的假设。

一个人可能知道很多事实，却因为缺乏合适的结构，始终无法理解这些事实之间的联系。

这些现象提示我们：理解复杂对象，不仅取决于观察者的能力，也取决于对象的信息能否以适当的形式呈现出来。

由此，我们提出一个初步概念：复杂性显现理论。

它研究的问题是：如何通过适当的信息提取、结构表达、关系建模和交互工具，使复杂系统中原本隐含、分散或难以直接观察的信息，变得可以理解、检查和验证？

这套理论最初可以应用于 AI 编程，但它的潜在适用范围并不局限于软件开发。

二、什么是复杂性显现？

复杂性显现，是指通过适当的外部表达，将复杂对象中原本隐含、分散或难以直接观察的结构、关系、过程和约束，转换为能够被观察、理解、检查和验证的对象。

这里所说的复杂性，不仅指对象本身包含大量元素，还包括元素之间存在大量相互作用、依赖关系、状态变化和约束条件。

例如：

• 一段代码可能很简单，但它依赖的模块很多，因此修改风险很高。
• 一个流程中的每个步骤都很清楚，但不同步骤之间存在相互矛盾的条件。
• 一项任务看起来已经完成，但实际运行状态与预期状态不一致。
• 一个组织的各个部门都在提高效率，但整个组织的协作成本反而不断上升。

这些问题并不一定能通过增加阅读时间、编写更多说明或要求人们更加认真来解决。

有时，我们需要改变的是信息的呈现方式。

例如，将分散的代码转换成模块依赖图，将隐含的业务规则转换成约束条件，将难以复现的运行过程转换成结构化日志。

这些操作不会自动消除系统本身的复杂性，却可能降低理解复杂性的成本，并提高发现问题的概率。

因此，需要区分两个概念：

复杂性本身，是对象所具有的结构、关系、变化和相互作用。

复杂性的可理解性，则与观察者能够获得什么信息，以及这些信息如何被组织和表达有关。

复杂性显现理论主要研究后者，同时研究如何借助这些表达方式，更有效地识别和处理前者。

它的核心目标不是让所有复杂问题都变得简单，而是让复杂问题更容易被发现、定位、分析和验证。

三、复杂性为什么会隐藏？

复杂系统中的信息，通常不会自动以人类容易理解的方式出现。

1. 信息分散

一个问题所需的信息可能分布在多个文件、模块、数据库或工作环节中。

例如，一个功能的异常可能涉及前端参数、后端接口、数据库记录和异步任务。

单独查看任何一个环节，都可能找不到完整原因。

只有把相关信息关联起来，才能看到完整的问题链条。

2. 关系隐含

系统的组成部分可能很容易识别，但它们之间的关系不容易识别。

例如，两个模块分别只有几十行代码，却通过多层调用形成复杂的依赖关系。

只看模块本身，很难判断一次修改会影响多大的范围。

这时，依赖图和调用图比逐个阅读文件更有帮助。

3. 状态不可见

程序和组织都可能随着时间发生变化。

某个问题可能只在特定条件、特定顺序或特定状态下出现。

静态地观察一个对象，无法完整理解它的动态行为。

因此，需要通过日志、状态追踪、事件记录和状态机等方式，呈现对象在不同时间发生了什么变化。

4. 约束没有显式表达

有些规则存在于开发者的经验、团队的习惯或管理者的判断中，却没有转化为明确的约束。

例如，某个模块不应该依赖另一个模块，某项资源必须在任务结束后释放，某个状态下不允许执行特定操作。

当这些规则没有被明确表达时，人类和 AI 都可能在修改过程中无意违反它们。

5. 局部信息掩盖整体问题

一个局部操作可能是合理的，但多个局部操作组合起来，却可能产生不良结果。

例如，每个部门都通过增加审批来降低自身风险，最终却导致整个组织的决策速度大幅下降。

或者，每个模块为了方便调用其他模块而增加依赖，最终使系统变得难以修改。

这类问题需要通过整体结构和系统行为来识别，不能只靠局部分析。

四、复杂性显现的基本原理

根据以上问题，可以提出五项初步原则。

原理一：适当的表达能够提高问题的可发现性

信息是否存在，与信息是否容易被发现，是两回事。

代码中可能已经包含了全部依赖关系，但开发者未必能够在脑中准确还原这些关系。

将依赖关系提取出来并形成图形，可能使原本难以发现的循环依赖一目了然。

因此，分析复杂问题时，不应只问：

我们还缺少什么信息？

还应问：

已有的信息，是否已经以适当的形式呈现？

原理二：关系往往比孤立元素更能解释复杂问题

在复杂系统中，许多问题不是由单个元素直接造成的，而是由多个元素之间的关系产生的。

一个模块是否危险，不仅取决于它自身的代码质量，还取决于它被多少模块依赖、依赖了多少其他模块，以及这些依赖是否形成循环。

一个组织的效率，不仅取决于每个部门的工作效率，还取决于部门之间的信息流动、协作成本和决策关系。

因此，复杂性显现不仅要呈现对象，还要呈现对象之间的关系。

原理三：动态问题需要动态证据

静态结构可以揭示依赖关系，却不一定能说明程序实际如何运行。

程序运行日志可以记录执行过程，却不一定能完整说明系统为什么采用这种架构。

因此，复杂问题往往需要多种证据共同解释。

例如，将静态依赖图、运行时调用链、错误日志和测试结果关联起来，才能更全面地判断问题来自哪里。

原理四：表达形式应当服务于具体问题

并不是所有信息都适合用文字呈现，也不是所有问题都需要画图。

不同的问题，需要不同的表达方式。

• 需要了解程序执行顺序时，可以使用日志和调用链。
• 需要了解模块关系时，可以使用依赖图。
• 需要了解页面结构时，可以使用 DOM 树。
• 需要定位网页元素时，可以使用 XPath 或 CSS Selector。
• 需要分析状态变化时，可以使用状态机。
• 需要检查行为是否符合预期时，可以使用自动化测试和断言。
• 需要分析视觉位置时，可以使用 SVG、坐标、锚点和几何关系。

关键不是尽可能多地展示信息，而是找到最适合当前问题的表达形式。

原理五：显现结果必须接受验证

图形、日志和模型并不天然等于事实。

依赖图可能遗漏动态调用，日志可能缺少关键上下文，状态机可能没有覆盖全部情况，自动生成的文档也可能已经过时。

因此，复杂性显现的结果必须尽可能与真实对象进行对照。

如果一张图无法反映实际依赖关系，那么它可能增加误解，而不是减少误解。

复杂性显现不仅要让信息变得可见，还要关注这些信息是否准确、完整，以及是否能够被验证。

五、复杂性显现的五个层次

为了将理论转化为工程方法，可以暂时把复杂性显现划分为五个层次。

第一层：对象显现

让我们知道系统由什么组成。

例如：

• 软件模块列表；
• 文件与目录结构；
• 类和对象关系；
• 数据库表结构；
• 页面组件树；
• 组织部门和岗位结构。

这一层主要解决对象不清楚的问题。

第二层：关系显现

让我们知道对象之间存在什么关系。

例如：

• 模块依赖图；
• 方法调用图；
• 数据流图；
• 数据库关联图；
• 组织协作关系图。

这一层主要解决关系隐藏的问题。

第三层：过程显现

让我们知道系统实际发生了什么。

例如：

• 程序运行日志；
• 请求追踪；
• 任务执行时间线；
• 状态转换记录；
• 业务流程图。

这一层主要解决动态行为难以观察的问题。

第四层：约束显现

让我们知道系统应该遵守什么规则。

例如：

• 架构依赖规则；
• 输入输出约束；
• 状态转换条件；
• 资源生命周期要求；
• 权限与安全规则；
• 业务流程中的必要条件。

这一层主要解决正确性标准不明确的问题。

第五层：偏差显现

让我们知道实际情况与预期之间有什么差异。

例如：

• 实际依赖违反架构规则；
• 实际运行结果与预期结果不一致；
• 修改代码后出现新的回归错误；
• 某项任务存在未处理的异常路径；
• 组织的实际运行方式偏离了制度设计。

这一层将前面的对象、关系、过程和约束结合起来，帮助我们发现问题。

这五个层次不是严格的线性流程。实际工作中，我们可能从一个错误开始，追溯到运行过程，再发现结构问题，最后补充新的约束。

它们更像是观察复杂系统的五种互补视角。

六、复杂性显现的核心循环：从看见问题到验证问题

复杂性显现不是简单地把系统画成图，也不是把所有信息记录下来。

真正有价值的是将信息呈现与问题解决连接起来。

可以把这一过程组织成一个循环。

第一步：确定需要理解的对象

首先明确当前要解决的问题。

例如：

• 为什么修改一个模块会导致其他模块发生异常？
• 为什么某个动画中的人物部位会发生错位？
• 为什么某个任务在部分情况下无法结束？
• 为什么增加了审批环节，整个组织的效率反而下降？

问题不同，需要观察的对象也不同。

第二步：选择适当的表达形式

根据问题特点，选择能够揭示相关信息的表达方式。

如果问题涉及模块关系，可以生成依赖图。

如果问题涉及执行顺序，可以增加日志和调用追踪。

如果问题涉及图形位置，可以提取坐标、锚点和变换关系。

如果问题涉及任务状态，可以构建状态机。

如果问题涉及组织协作，可以绘制流程图和责任关系图。

第三步：发现异常或值得研究的关系

通过新的表达形式，寻找原本难以观察的现象。

例如：

• 两个模块之间存在循环依赖。
• 某个状态存在进入路径，却缺少正常退出路径。
• 一项资源在异常分支中没有释放。
• 某个视觉部件的坐标变换与其父节点发生冲突。

此时得到的仍然只是候选问题，而不一定是最终原因。

第四步：建立可检验的假设

将模糊的观察转换为可以检查的判断。

例如，原始描述是：

「修改这个模块后，其他地方总是出错。」

进一步形成的假设可以是：

「模块 A 与模块 B 存在双向依赖，导致修改 A 的接口时，B 的行为也会发生变化。」

随后就可以检查实际依赖关系，分析调用链，并通过受控修改观察结果。

第五步：实施修改并验证

在确认问题后，修改代码、配置或系统结构。

然后通过测试、日志、运行结果或其他证据，检查修改是否达到预期目标。

如果问题仍然存在，就应重新检查假设，而不是不断增加补丁。

第六步：将有效经验转化为长期资产

如果某次分析发现了架构问题，就可以增加自动化检查。

如果某次调试发现某种错误容易反复出现，就可以增加对应的测试。

如果某种图形能够显著降低定位成本，就可以将其集成到开发工具中。

这样，一次问题处理就不只是解决了眼前的错误，还可能提高系统未来发现同类问题的能力。

整个循环可以概括为：

确定问题 → 选择表达 → 发现异常 → 建立假设 → 验证判断 → 修正系统 → 沉淀经验。

这不是一个只能从头到尾执行一次的流程，而是一个可以反复迭代的过程。

七、从 AI 可理解接口到人机共同认知环境

复杂性显现理论的一个重要应用，是改善人类与 AI 的协作。

在编程过程中，人类经常使用一些不够精确的表达：

• 这个位置不对。
• 两个模块之间好像有问题。
• 这个控件没有正确连接。
• 这个动画看起来不自然。
• 程序运行了，但结果不对。

这些描述对人类来说可能已经足够，因为人类可以指着屏幕、观察动画、点击按钮，或者根据经验理解问题。

但对 AI 来说，它可能知道问题属于哪一类，却不知道具体对象、内部结构、实际状态，以及什么结果才算正确。

这时，继续增加自然语言描述，不一定是最有效的解决办法。

更好的方式可能是建立适当的观察和操作环境。

例如，开发者发现一个 SVG 动画中的头部与身体连接不自然，却不知道问题属于锚点、坐标系还是父子变换关系。

AI 可以生成一个调试界面，显示相关元素的层级、坐标、边界框和锚点。

开发者在界面中选择出问题的部位，或者标记期望的位置。

AI 再根据这些信息检查相关结构，提出原因假设，修改代码，并重新渲染验证。

在这个过程中，人类不必先把自己的感受翻译成准确的专业术语。

AI 也不必仅仅依靠自然语言猜测问题。

双方通过共同的外部对象进行协作。

人类容易理解的表达与 AI 容易处理的表达

有些表达形式同时适合人类和 AI。

例如：

• 模块依赖图既能帮助人类理解架构，也能供 AI 分析循环依赖。
• 状态机既能帮助人类检查流程，也能用于自动生成状态转换测试。
• SVG 既能显示视觉结果，也能提供机器可读取的几何结构。
• 结构化日志既能帮助人类追踪问题，也能供 AI 进行事件关联。

这些形式构成了人类与 AI 共同理解复杂系统的重要基础。

但两者的交集并不意味着所有信息都应该使用同一种格式。

人类可能更容易通过图形发现整体异常，AI 则可能更适合批量分析大量结构化关系。

因此，更理想的设计是让不同表达形式相互关联。

人类在图中点击一个模块，AI 就能定位对应的代码、日志和测试；AI 发现一条异常依赖，也能在图中高亮显示。

这样，双方看到的不是彼此孤立的信息，而是同一个系统的不同视图。

八、AI 不仅应该生成代码，还应该生成理解代码所需的工具

这是复杂性显现理论在 AI 编程领域最值得探索的方向之一。

传统的软件开发工具，主要服务于人类程序员的手工编程。

AI 编程工具则往往侧重于生成代码、搜索文件、运行命令和执行测试。

但对于复杂项目，还可以要求 AI 额外构建一套帮助人和 AI 共同理解系统的工程工具。

例如：

这些工具并不一定需要一次性全部开发。

AI 可以根据当前遇到的问题，按需创建最小的分析工具。

例如，当 AI 连续多次修改同一功能都没有解决问题时，它不应该只是继续尝试新的修改。

它可以先暂停修改，分析相关模块的调用关系，检查数据流和状态转换，再决定是否需要调整架构。

当现有日志无法解释一个问题时，AI 可以提出增加哪些事件记录。

当模块关系难以理解时，AI 可以生成依赖图。

当程序的行为与预期不一致时，AI 可以构建最小复现程序或自动化测试。

这种方法将 AI 的工作从单纯的代码生成扩展到分析工具建设、系统理解和工程诊断。

当然，生成的分析工具本身也需要验证。依赖图可能遗漏动态调用，静态分析可能无法准确反映运行时行为，测试也可能没有覆盖关键路径。

因此，不能把可视化结果直接当作事实，而应明确它的证据来源和覆盖范围。

九、如何衡量复杂性显现是否有效？

如果复杂性显现理论要成为可复用的工程方法，就需要回答一个问题：

我们如何知道某种显现方式真正改善了问题解决能力？

不能仅仅因为图形看起来更漂亮、文档更加详细，或者 AI 输出了更多分析内容，就认为效果更好。

可以从以下几个维度进行评价。

1. 问题发现能力

显现方式是否帮助人类或 AI 发现了此前遗漏的问题？

例如，生成依赖图后，是否发现了原本没有意识到的循环依赖？

2. 定位效率

从出现问题到找到相关代码、模块或状态，所需要的时间是否减少？

可以记录问题定位前后的时间，并在类似任务中进行比较。

3. 判断准确性

分析者提出的原因是否与后续验证结果一致？

如果一张图产生了大量错误警报，或者让开发者误判问题来源，就不能认为它有效。

4. 修改有效性

根据显现结果实施的修改，是否真正解决了问题？

可以通过测试通过率、回归错误数量和实际运行结果进行检查。

5. 维护成本

生成、更新和理解这些表达形式，需要付出多少额外成本？

如果一套复杂的可视化工具需要大量人工维护，却很少帮助解决问题，那么它的价值可能有限。

6. 知识复用能力

这次分析形成的规则、工具和测试，能否帮助解决未来的同类问题？

例如，某次发现的模块依赖问题，是否能够转化为自动化架构检查，从而避免同类问题再次出现？

这些指标不一定适用于所有任务，也不应被简单合并为一个总分。

更合理的做法是，根据具体工程目标，选择最相关的指标，并通过实际案例进行验证。

十、复杂性显现不是越多越好

复杂性显现本身也可能增加复杂性。

例如，一个大型项目可能拥有数百张架构图、数千条日志和大量自动生成的文档。

如果这些信息缺乏组织，开发者就可能花更多时间寻找资料，而不是解决问题。

AI 也可能受到过多冗余信息的干扰。

因此，需要考虑一个重要原则：

显现的目标不是最大化信息数量，而是以合理的成本，呈现当前决策和问题解决所必需的信息。

这意味着，显现过程需要考虑三个问题：

• 哪些信息与当前问题有关？
• 需要呈现到什么粒度？
• 哪些信息应该长期保存，哪些只需要临时生成？

例如，在排查一个简单的输入校验错误时，可能只需要相关日志和测试结果。

而在重构一个存在大量循环依赖的系统时，才有必要生成完整的模块依赖图。

合理的显现方式，应当根据问题的规模和风险动态调整。

此外，表达形式还必须尽可能保持与真实系统一致。

架构图可能过时，文档可能与代码不一致，AI 生成的模型也可能存在遗漏。

因此，需要研究如何自动更新表达、标记信息来源，并对重要结论进行验证。

十一、从一次性调试走向持续性的工程能力

复杂性显现还可以从临时工具发展为长期的工程基础设施。

例如，一个项目在开发初期可能只需要基本日志。

随着系统变得复杂，可以逐渐增加：

• 模块依赖检查；
• 关键调用链追踪；
• 状态转换记录；
• 架构约束测试；
• 自动化回归测试；
• 关键操作的审计记录。

这些能力并不需要一次性全部建设。

可以根据真实问题逐步增加。

当某类问题反复发生时，应当考虑能否把它转化为自动化检查。

当某项结构关系经常影响开发决策时，应当考虑能否持续生成相关图形。

当某个关键行为无法通过现有日志还原时，应当考虑增加必要的事件记录。

通过这种方式，复杂性显现可以逐步融入软件的设计、开发、测试和维护过程。

一次问题处理的成果，不再只是修复了一处错误，还可以包括新的分析工具、架构规则、测试用例和诊断能力。

这些成果可以在后续开发中反复使用。

十二、复杂性显现理论的应用范围

虽然这个概念最初来自软件开发，但它可能具有更广泛的适用性。

1. 软件工程

将模块依赖、调用关系、状态变化、运行异常和架构约束显现出来，降低理解和维护复杂软件的成本。

2. AI Agent

让 Agent 能够观察任务状态、理解工具之间的关系、追踪执行过程，并验证任务是否真正完成。

3. 组织管理

将部门之间的信息流、责任关系、审批流程和资源依赖显现出来，识别局部优化造成的整体问题。

4. 复杂决策

将决策依据、关键假设、因果关系、利益影响和不确定性显现出来，使决策更容易被检查和复盘。

5. 教育与知识表达

将难以理解的概念转换为结构图、动态演示、交互实验和因果模型，帮助学习者理解知识之间的联系。

这些应用的具体方法会有所不同，但共同目标是：通过更合适的表达方式，提高复杂对象的可理解性与可检查性。

需要注意的是，显现并不等于完全理解。一个复杂系统可能存在无法充分观察的信息，也可能受到不确定性、测量误差和模型局限的影响。

因此，理论的适用范围、有效条件和局限性，还需要通过具体案例进一步研究。

十三、复杂性显现与工程认知外部化

复杂性显现还涉及一个更深层的问题：人类如何理解超出自身工作记忆和注意力承载能力的复杂系统？

一个开发者可能需要记住：

• 哪些模块可以调用哪些模块；
• 哪些状态可以转换到哪些状态；
• 哪些参数必须保持一致；
• 哪些修改会影响其他模块；
• 哪些异常需要特殊处理。

当这些信息主要存在于个人记忆中时，系统就会变得脆弱。

人员更换、上下文丢失、AI 切换会话，都会增加理解成本。

如果把这些信息转换为图、规则、日志、测试和结构化文档，就能让一部分原本依赖个人记忆的工作变成可重复的工程过程。

这种做法可以称为工程认知外部化。

它与复杂性显现密切相关，但两者的关注点不同。

工程认知外部化强调：将原本依赖人脑记忆和推理的信息与关系，转化为外部可保存、可共享、可检查的表达。

复杂性显现强调：如何通过这些表达，使复杂系统中原本难以观察的结构和问题变得容易理解与发现。

前者可以为后者提供重要方法，后者则进一步关注这些方法如何提高问题识别和纠错能力。

在 AI 参与开发之后，这种外部化还可以进一步发展为人类与 AI 共同使用的工程认知环境。

不过，并不是所有信息都值得外部化。

更合理的做法是优先处理那些容易遗忘、容易冲突、影响范围大、难以从局部代码直接推断的关系，并根据实际收益决定是否继续投入。

十四、下一步需要研究什么？

复杂性显现理论目前仍处于初步构建阶段。要使它从一个有启发性的观点发展成更完整的方法体系，还需要进一步回答以下问题。

1. 什么信息最值得显现？

不是所有信息都需要展示。

过多的日志、图表和指标，可能使人和 AI 面临新的信息负担。

需要研究如何识别对当前任务最有价值的信息，以及如何根据问题动态调整呈现内容。

2. 如何判断一种表达是否有效？

一张图可能看起来很清楚，却没有帮助发现真正的问题。

一种表达是否有效，应该结合具体任务判断，例如是否缩短了问题定位时间、是否提高了错误发现率，以及是否减少了错误修改。

3. 如何保持表达与真实系统一致？

架构图可能过时，文档可能与代码不一致，AI 生成的模型也可能存在遗漏。

因此，需要研究如何自动更新表达、标记信息来源，并对重要结论进行验证。

4. 如何控制复杂性显现本身的成本？

生成工具、维护模型、记录日志和构建可视化界面，都需要投入资源。

如果这些成本超过了它们带来的收益，复杂性显现就可能变成新的负担。

因此，需要根据系统规模、风险和任务特点，选择合适的显现粒度。

5. 如何让人类与 AI 共同参与问题发现？

人类可能发现 AI 忽略的整体异常，AI 也可能发现人类难以注意到的复杂关系。

如何将双方的观察、判断和操作结合起来，形成可追溯、可验证的协作过程，是值得继续研究的问题。

6. 如何让显现过程本身逐渐自动化？

如果每次遇到复杂问题，都必须由开发者手动决定应该画什么图、增加什么日志、编写什么分析脚本，那么复杂性显现的成本仍然可能很高。

未来可以探索让 AI 根据问题特征，主动判断当前缺少哪些证据，并选择或构建相应的观察工具。

这意味着，AI 不仅需要理解已有的表达，还需要具备改善表达环境的能力。

十五、结语：让问题更容易被发现，而不是只要求人更加努力

我们经常把复杂问题归因于知识不足、能力不足，或者要求参与者更加认真。

但有些问题并不是因为信息不存在，而是因为信息没有以适当的方式呈现出来。

代码中可能已经包含模块之间的依赖关系，但没有依赖图，我们就很难快速看清整体结构。

程序中可能已经存在异常发生的线索，但没有适当的日志和追踪机制，我们就很难还原实际过程。

组织中可能已经存在资源错配和责任冲突，但如果缺少关系模型，我们就可能把系统问题误认为个别人员的问题。

因此，理解复杂系统不仅需要增加知识，还需要改善观察和表达的方式。

AI 的发展使这一方向具有了新的可能性。AI 不仅可以阅读已有信息，还可以参与构建分析工具、生成结构模型、发现异常关系，并验证修改结果。

与此同时，人类也可以通过可视化、标注和交互操作，更直接地表达原本难以用专业术语描述的问题。

复杂性显现理论的初步主张是：通过适当的外部表达，使复杂系统中原本难以观察的结构、关系、过程和约束变得可理解、可检查、可验证，从而提高人类与 AI 发现问题和纠正问题的能力。

我们不应只追求让人和 AI 更努力地理解复杂系统，还应该努力设计能够帮助双方看清复杂系统的环境。

当现有信息不足以解释问题时，我们可以构建新的观察工具；当某种关系反复造成错误时，我们可以将其转化为显式约束；当一次调试发现了系统性问题时，我们可以把经验沉淀为长期可复用的工程能力。

我们不仅要让 AI 帮助我们构建软件，还要让 AI 帮助我们构建一套能够理解、观察、检查和修正软件的环境。

这就是复杂性显现理论希望探索的方向。