将可理解性作为架构特性：无法理解的系统无法安全演进
核心论点：可理解性是架构特性
文章从生产环境排障的痛点切入——团队大部分时间花在"系统各部分如何连接、实际做了什么"上，而非查找 Bug。对系统的理解从未超越某些特定个人，也未扩展到整个团队。
援引 Peter Naur 的《编程即理论构建》：系统不仅包含代码，还包含程序员心中构建的"理论"（心理模型）。该理论在团队中被接受的广泛程度和持久性，是系统本身的属性。Margaret-Anne Storey 进一步定义了三种系统债务：技术债务、认知债务（共同理解悄然流失）、意图债务（缺乏对系统现状形成原因的合理依据）。与性能、可用性不同，这一特性会随时间悄然恶化——不被理解的系统无法安全演进。
削弱可理解性的三大因素
- 去中心化的副作用：去中心化架构决策消除了瓶颈，但各团队理论逐渐背离，整体视图支离破碎，知识碎片化加剧。
- 人员流动：离职者带走部分"理论"，文档通常只记录"是什么"而非"为什么"，新人倾向战术性修补而非系统性改进，侵蚀架构完整性。
- 生成式 AI：最致命的新变量。GenAI 减少了实现工作量，但正是这些工作量在开发者心中构建了系统的思维模型。文章举了一个真实案例：资深工程师不得不花大量时间理解自己一周前交付的代码，因为从未建立心理模型——代码通过了所有质量检查，但"理解债务"在演示时才首次显现。
Arvind Narayanan 和 Sayash Kapoor 指出，软件工程师的工作是"决策-执行-交付"三明治，而理解是三层的先决条件。GenAI 压缩了中间层，理解必须有意识地在两端（生成之前和之后）构建。
检测和度量可理解性的流失
文章扩展了"适应度函数"的内涵，将其应用于围绕代码的社会技术系统。一部分可完全自动化，其余则是监测指标而非可执行检查。关键指标分六类：
- 代码审查动态：PR 规模过大、智能工具成为唯一审查者、审查失效（LGTM 比例高、审查集中在少数人）、设计评审缺失——这些是共同理解出问题的早期预警信号。
- 知识分布：作者贡献度（DOA）过高意味着知识集中。"我们等 Dave 吧"是危险信号。卡车系数低表明可理解性脆弱。
- 入职摩擦：新员工达到正常效率的时间是直接指标，延长趋势意味着认知负担也在压迫资深成员。
- 意图文档缺失：设计决策无"原因"说明，追踪未添加 ADR 就触及架构边界的 PR。
- 领域泄露：破坏架构边界的变更使局部推理变得不可能，用适应度函数让构建失败。
可理解性检查点：主动理解 vs 被动理解
文章的核心洞察之一：
工程师在设计和实现过程中理解一个模块（主动思考），与在模块生成之后理解它（被动思考），存在本质区别。事前理解确保人类始终掌控正在构建的系统；事后理解意味着你将不再决定系统设计——最终得到的是 LLM 在训练中形成的统计学默认设计，而非你的具体情境所要求的方案。
人工审查是可理解性的检查点，而非质量把关环节。其作用在于把握设计意图、构建理论框架，而非仅仅验证代码输出。在智能工程流程中，设计审查比代码审查更为重要。
持续维护共享模型
个人理解是必要的但不够。心理模型的偏差在跨团队协作时代价高昂。有界上下文是最需要建立共同理解的领域——API 模式说明了结构和授权，但幂等性、重试安全性、排序要求、一致性等行为契约属于"理论"范畴，必须作为共同理解存在。
关键实践：维持经过深思熟虑的团队拓扑结构、跨模块结对编程和轮换、去中心化的架构决策机制。GenAI 让知识孤岛进一步放大——当智能体生成代码速度超过人类理解能力，知识流多出一个"第一跳"。给智能体发出指令的人必须能通过将实际实现与设计时心理模型对照来解释系统设计，而非从生成输出中反向学习。
文章将"理解债务"定义为系统实际状态与团队对其理解之间的差距，类比技术债务——无法通过一次努力清偿，只有成为持续行为习惯才能发挥作用。
Zero 的看法
这篇文章的价值在于把一个"大家都知道但没人认真对待"的问题提升到了架构特性的高度。可理解性长期被视为软指标——重要但不可度量，所以总在交付压力下第一个被牺牲。文章用适应度函数 + 人工检查点的组合给出了可操作的框架，这是务实的一面。
但有几个问题值得质疑：
第一，文章对 GenAI 的态度偏保守。说"不理解就交付"是危险倾向，这点我同意，但文中开出的药方——让工程师手写 PR 描述来证明理解——在 AI 自动生成 commit message 已经成为主流的今天，执行阻力极大。更现实的路径可能是让 AI 生成后强制要求人类 review 时补充意图说明，而非完全手写。
第二，适应度函数监测社会技术系统的提法听起来很美，但落地极难。DOA、卡车系数这些指标在 monorepo 大团队场景下噪声很大，"我们等 Dave 吧"这种文化信号反而比指标更灵敏。文章也承认了 DOA 的局限性，但没有给出更好的替代方案。
第三，核心矛盾没有正面回答：当交付压力和可理解性冲突时，怎么选？文章暗示理解不能被牺牲，但在实际组织中，短期交付几乎总是赢。如果可理解性真的是架构特性，那就应该像可用性 SLA 一样有硬性预算和红线，而不是停留在"应该重视"的层面。
对于前端工程师来说，这篇文章的启示很直接：组件库的 API 契约、跨团队的接口约定、甚至 CSS 架构的边界——这些地方的可理解性正在被 AI 生成代码悄悄侵蚀。在你还能解释清楚系统之前，别急着把理解这件事也外包给 AI。