Article: Comprehension as an Architectural Characteristic: A System That Is Not Understood Cannot Evolve Safely

作为架构特征的理解：无法理解的系统无法安全演进 - InfoQ

InfoQ 首页 Articles 作为架构特征的理解：无法理解的系统无法安全演进

架构与设计

框架之下：为什么代理上下文是一个基础设施问题（网络研讨会 8月27日）

作为架构特征的理解：无法理解的系统无法安全演进

2026年8月10日 13分钟阅读

作者：

• Jacobus Meintjes

• Narayana Rengaswamy

• Paul Katsande

• Sureshbabu Bikki

审阅者：

• Luca Mezzalira

#### 关注我们

Youtube

232K 粉丝

Linkedin

26K 粉丝

Instagram

新

RSS

19K 读者

X

57.1k 粉丝

Facebook

21K 赞

Bluesky

收听本文 -

0:00

音频准备播放

您的浏览器不支持音频元素。

正常

1.25x

1.5x

喜欢

新下拉阅读列表

• 阅读列表

关键要点

• 人类理解是一种内在的架构特征，必须积极维护。与性能或可用性不同，它会随着时间的推移悄然退化，无法理解的系统无法安全演进。

• AI 已使代码生成商品化，消除了在实现过程中自然形成的理解。现在必须在生成前而非审查时寻求理解。

• 理解无法直接测量，但其退化会产生团队可以监控并采取行动的信号。

• 为了使系统可演进，团队必须对本质上复杂的内核及其接口保持共同模型。理解必须从代理到个人，再从个人到团队流动。

• 人工审查是理解检查点而非质量门，用于验证、强化和传播代码生成前获得的理解。

本文由

在线 InfoQ 认证架构师计划

的参与者撰写。它代表了他们工作的顶点，反映了该小组在人工智能与现代软件架构交叉点上的集体学习成果。

理解难题

在处理复杂系统的成熟团队中，可能会经历生产事故调查会议，其中大部分时间都花在弄清楚系统是如何连接的以及它实际做了什么，而不是寻找错误。最终，团队不得不深入代码中，以解决团队集体记忆无法覆盖的问题——系统的行为方式。这个问题的出现是因为理解从未扩展到团队中的某些个体之外。

在演化架构中，系统应被设计为能够吸收并适应不断变化的需求和不断变化的环境。但要真正实现这种适应性，团队成员需要对系统本身有深刻的理解。正如 Peter Naur 在《Programming as Theory Building》中所论述的，仅仅理解代码是不够的，你必须理解构建它的程序员头脑中所持有的底层“理论”，这里的“理论”指的是程序员为理解程序如何运作而构建的思维模型。他的观点是，系统包含的不仅是代码，还包括理论。因此，该理论在团队中被广泛且持久地持有，是系统本身的属性。Margaret-Anne Storey 在她的论文《From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI》中进一步扩展了这一观点，她定义了三种不同类型的系统债务：技术债务、认知债务和意图债务。认知债务是系统共享理解的隐性损失（根据 Naur 的定义即理论的丧失）；意图债务是系统现状背后原因的缺失。与性能和可用性等特性不同，这种属性会随着时间的推移悄无声息地恶化，而无法被理解的系统将无法安全地进化。由于人类理解既包含“是什么”也包含“为什么”，它既是认知债务又是意图债务的直接解药，必须被认定为演化架构的固有架构特性。

侵蚀理解的三大力量

#### 相关赞助商

• 警报疲劳正在消耗你的资源：生产可靠性与人工智能采用现状

#### 相关赞助商

在由多个团队维护的复杂系统中，集中式决策往往会造成瓶颈和知识孤岛。决策需要排队等待少数人处理，知识也集中在他们手中。为克服这些瓶颈并真正实现演化架构，组织可能会转向去中心化的架构决策模式。虽然这种方式能优化流程并让团队在本地子领域中发展深厚的专业知识，但全局视角会变得碎片化。团队可能了解自己服务的工作原理，却可能失去最初划定系统边界背后“为什么”的理解。缺乏共享的治理和实践，本地理论会逐渐偏离，加剧组织的知识碎片化。

团队成员流动也会加剧这一问题。当人员离开团队时，他们会带走部分“理论”。新成员必须从头重建理论，依靠的通常是只记录“是什么”而非“为什么”的文档。缺乏对某些边界存在历史原因的理解，他们可能会退而求其次地进行战术性修补，而非与原始设计相匹配的系统性改进。久而久之，这会侵蚀架构的完整性。

生成式人工智能（GenAI）是这三种力量中最新且最快的。它减少了过去用于生成理解作为副产品的实施工作量，但这些工作量也曾帮助开发者构建系统的心理模型。在生成式人工智能在软件工程中变得突出之前，理解能力自然地在设计、实施和验证阶段形成并得到强化。随着这项技术的成熟和交付压力变得前所未有的显著，我们看到企业软件中出现了“在没有理解的情况下交付”的趋势。在一次向客户演示功能时，我们团队的一位经验丰富的工程师不得不花费大量时间去理解她一周前部署的一段代码是如何运作的，因为她从未形成过这段代码的心理模型。这段代码通过了所有质量检查，但演示是第一次出现理解债务的问题。

Arvind Narayanan 和 Sayash Kapoor 最近的一篇文章讨论了软件工程师的工作是一个“决策-执行-交付”的三明治结构，理解是这三个层次的前提条件。

生成式人工智能压缩了中间的执行层，我们认为过去在三个层次中自然形成的理解现在应该在两端有意识地创建。这是形成对本质上复杂部分理解的地方——在“生成”阶段之前和之后。软件工程师必须在这两个阶段投入心理努力，将设计与现有系统结构联系起来，以组织和创建心理模型。

知识碎片化、团队人员流动和AI生成的变更——每种都会以不同的速度侵蚀理解能力，导致无法安全更改的系统。

检测和衡量理解能力的丧失

架构师和技术领导者可以通过监控几个关键指标来量化系统理解能力的侵蚀。用于此的自然工具是适应性函数（fitness functions）——它们让架构师表达重要的架构特性并自动验证这些特性。自动适应性函数可以衡量理论损失的一些领先指标，但无法衡量意图本身的理解。没有任何流水线检查能确认人类是否理解变更存在的原因。自动化的工作是检测理论退化的条件；验证变更是否符合意图以及是否有人真正持有该理论的任务属于下一节中描述的人工检查点。

因此，我们特意扩展了这一术语。下面列表中的“适应性函数”评估代码周围的社技系统（sociotechnical system），其中一些可以完全自动化。其余的是监控指标而非可执行检查，在某些情况下这是有意为之，而非限制。当强制执行时，关于人员的指标会改变行为——一个阻止PR的门禁可能被绕过以规避障碍——当绕过游戏难以或无害时强制执行，否则进行监控。将阈值视为调查的触发器，而非目标。如果存在可以绕过的门禁，跟踪豁免和覆盖情况，以便修正阈值或改进团队实践。

图1：理解能力必须在执行阶段前后形成。来源：作者使用 draw.io 创建

代码审查动态

拉取请求（Pull Requests）是知识共享的主要载体。功能失调的审查指标通常指向共享理解的崩溃。留意这些早期预警信号：

• 大型PR规模：当PR过于庞大无法审查时，其本应承载的知识流动将无法实现。通过阻止大PR来强制执行（为您的上下文定义阈值）。要求作者拆分PR，并在设计审查阶段尽早发现此类问题。

• 智能代码审查者：不要让智能代码审查成为PR的唯一审查者——它们可以作为第一审查者，但必须随后由人类审查者跟进。通过CodeOwners等策略强制执行此规则。

• 审查功能失调：当审查工作集中在少数人身上，或组织动态阻碍审查者对资深成员提供有效反馈时，批准将变成形式主义。这只能通过监控来发现。跟踪已批准PR中无实质性评论或仅含“LGTM”的比例，以及团队内部审查的分布情况。轮换审查者，赋予团队每个人审查PR的权力，无论职位高低。明确要求挑战任何作者的设计或代码都是预期行为，包括架构师的代码。

• 缺失的设计审查：涉及重大影响范围的代码变更（本质上复杂的内核和接口）在变更规模大小无关的情况下，必须事先进行设计审查。这难以强制执行，因此需跟踪那些触及核心模块且未经过事先设计审查就合并的PR。要求作者组织团队会议讲解设计变更，以弥补错失的设计审查机会。

知识分布

当关键上下文信息被少数工程师掌握时，项目会陷入停滞。注意只有一人掌握系统意图的情况。“等Dave来决定”应引起团队警觉。作者度（DOA）衡量个人对系统构建的贡献程度。高DOA意味着知识集中在少数人身上。请注意DOA的局限性；将其视为众多可用信号之一。使用git-truck等工具监控，这些工具可以绘制代码库中的知识分布并暴露严重的单点故障。低卡车因子意味着系统理解力脆弱。轮换负责此类模块的开发人员，为这些模块增加多位负责人，并组织学习会议。

入职摩擦

新员工达到生产力所需时间是系统可理解性的直接指标。如果入职时间呈上升趋势，项目认知负担可能也影响着资深团队成员。跟踪新员工参与系统设计和架构的时间，而不仅仅是提交PR的时间。鼓励新工程师记录令人困惑的问题——缺失的文档、过时的契约、隐式的依赖关系。定期审查并解决这些问题。

意图文档缺失

缺乏伴随“为什么”的设计决策或变更会随时间推移甚至让创建者感到困惑。文档是对“未来是否有人需要它”的回答。通过检测PR触及核心或结构性边界时未添加ADR或说明理由来监控此类问题的来源。同时跟踪修改现有模块时需要挖掘缺失上下文的情况。通过添加轻量级ADR来捕捉意图来解决此问题。

破坏架构边界的变更会使“局部推理”变得不可能，一个看似孤立的变更可能在不相关的区域产生意料之外的副作用。使用架构适应性函数在约束条件被违反时阻止构建过程，并在必要时重新设计接口或依赖关系。

理解检查点

人工评审者不能仅通过阅读代码就完全信任代码本身所表达的内容。此时的人工评审是一个理解检查点，而非质量门禁。适应性函数等反馈传感器应能捕捉不良输出，而人工评审的作用是把握意图，构建变更行为及其原因的理论框架。这就是为什么在智能体工程流程中，设计评审比代码评审更为重要的原因。

工程师在设计和实现阶段理解模块与模块生成后理解之间存在本质差异——这正是主动思考与被动思考的区别。当主动解决问题且没有现成方案时，会催生与上下文相关的创造性解决方案。这有助于系统以有机方式演进，由与业务领域和约束条件相关的关键决策驱动。如果仅在代码审查和验证环节寻求理解，真正的理解将永远无法形成。事前理解确保人类始终掌控正在构建的系统。事后理解意味着你将不再决定系统的设计；由于系统可以以多种方式构建，若未提前做出决策，最终会得到一个统计意义上的默认设计——这是LLM训练所形成的，而非你的上下文所要求的。

这并不意味着每次变更都必须遵循此流程。将繁琐工作委托给AI仍然很有意义，评审者只需掌握足够信息以验证输出，而无需将其提升到共享理解层面。判断何时需要为本质复杂的核心保留理论，何时可以放手。

任何系统都必须被理解、设计、构建、验证和维护，即使随着技术发展，流程中某些环节可能被加速。团队应首先验证需求，确保其明确且可测试，并有文档化的验收标准，然后再允许智能体进行编码。这并非要求进行大规模前期设计，因为此处的单元是用户故事而非整个系统。在智能体工程中，决策-执行循环运行得更快，人工工程师必须把握变更的意图——即什么在变化，以及边界处行为如何变化——这样才能在不丢失理论的情况下委托构建工作。

让工程师用自己的话解释代码，并将该解释带入PR描述和合并提交信息中。价值完全在于手动编写提交信息/PR描述，而非让智能体自动生成。编写信息的摩擦力正是作者发现是否真正掌握理论的探针。

维持共享模型

个体理解虽然必要，但仍然不够。当工程师在脑海中对系统有一个简化的模型时，理解上的差异容易解决。但当子系统进行通信、不同团队互动时，心智模型的差异则代价高昂。有界上下文的接缝处是必须共享理解的最关键区域。例如，一个 API 模式可以解释请求和响应的结构、前提条件和授权，但不会涉及契约的行为方面——如幂等性、重试安全性、排序要求、一致性以及交付保证。这种行为属于理论范畴，必须在双方之间形成共享的理解。ADR（架构决策记录）和上下文地图等工具和产物是必要的，但它们本身并不能维持理解。这种共享模型只能通过知识流动来实现：保持有意识的团队拓扑结构，让工程师在模块之间进行配对和轮岗，使理论不被局限于某一个工程师，同时采用去中心化的架构决策机制。

图 2：个体理解是必要的，但并不充分——它必须继续流向团队，以应对人员流动。来源：作者使用 draw.io 创建

随着生成式人工智能（GenAI）的出现，知识孤岛问题被放大。当代理生成代码的速度超过人类理解的速度时，知识流动多了一个初始环节——代理与个体之间的环节。指导代理的人必须能够解释设计——不是通过从生成的输出中学习，而是通过将实际实现与设计时的心智模型进行协调。理解检查点处理代理到个体的环节；上述实践则维持个体到团队的知识流动，使共享理解更加持久。如果理解是一种架构特性，那么理解债务（系统实际状态与团队理解之间的差距）就是一种会累积利息的负债。就像技术债务一样，它不能通过一次性的努力来偿还。这些实践只有作为持续的习惯才能奏效，因此必须将理解嵌入到流程中，使其适用于尚未加入的工程师。

有意识地构建理解

将理解视为架构特性意味着要给予它与其他特性相同的待遇：提供可监控的领先指标、用于自动化的适应性函数，以及能够维持标准的实践。如果你只在代理生成的代码投入生产后才发现理解上的差距，那么你已经失去了低成本的解决机会。碎片化、人员流动和生成式人工智能都会以各自的速度扩大这一差距，而它们都不会发出预警——系统继续通过其门禁检查，而背后的理论却在不知不觉中逐渐变薄。因此，要在接缝处、核心领域以及系统应具备可进化性的任何地方，有意识地构建理解。

进化架构承诺了能够安全吸收变化的系统。这一承诺的价值取决于其背后的共享理解，而这种理解只有在有意识且持续地进行工程化时才能得以延续。

• 架构与设计

• 文化与方法

• 生成式AI

• 领导力

• 架构 ICSAET

• 进化架构

• 人工智能

• 代码审查

• InfoQ 认证计划

• 架构

• 敏捷开发

• 相关编辑内容

• InfoQ 流行内容条目

Stripe 使用图搜索和状态机实现数据库修复自动化 微服务平台：当团队拓扑遇上微服务模式 Vercel Labs 发布 Zero：一种面向代理的图优先语言 OpenAI 代理团伙利用 Artifactory 零日漏洞逃逸沙箱并入侵 Hugging Face 文化与方法趋势 2026：人工智能工程的人文维度 InfoQ 文化与方法趋势报告 - 2026

InfoQ 新闻通讯

每周二发送上周 InfoQ 内容精选摘要。加入超过 25 万名高级开发者的社区。[查看示例](#)

我们保护您的隐私。