# 软件工程 / 架构设计方法论知识图谱 · AI 友好索引

节点 168 | 边 364 | 组 18

## 节点总表

| ID | 名称 | 类型 | 层 | 域 | 阶段 | 分组 | 定义 |
|---|---|---|---|---|---|---|---|
| ESS-H-01 | 信息隐藏 | 方法原则 | essence | H | 进阶 intermediate | GL-ESSENCE | 以「隐藏困难或可能变化的设计决策」作为模块分解判据：每个模块把一类易变决策封装为自己的秘密，接口只揭示尽量少的内部工作，使变更局部化。它规定的是划分依据与边界，而非模块的物理形态或大小。它是模块化有效性的根本来源之一。 |
| ESS-H-02 | 内聚与耦合 | 方法原则 | essence | H | 基础 basic | GL-ESSENCE | 衡量模块划分质量的两个互补维度：内聚是模块内部元素隶属同一目标的程度，耦合是模块之间相互依赖的程度。目标是高内聚、低耦合，但二者只是启发式方向，并非有普适阈值的绝对指标。它衡量的是结构对变更的承载能力。 |
| ESS-H-03 | DRY 单一知识来源 | 方法原则 | essence | H | 基础 basic | GL-ESSENCE | 系统内每个知识点应有单一、无歧义、权威的表示，避免同一知识的多份副本各自漂移。它针对的是「知识重复」而非机械的代码重复，核心判据是：一处规则改变时，是否需要在多个位置同步修改。它衡量的是知识的归属是否清晰。 |
| ESS-H-04 | 抽象泄漏 | 方法原则 | essence | H | 高级 advanced | GL-ESSENCE | 所有非平凡抽象都会在不同程度上泄漏其底层实现：性能、故障与边界行为会穿透抽象边界，使用者被迫了解本应被隐藏的细节。这是抽象与封装固有的边界，而非实现缺陷。它要求设计者主动管理而非幻想消除这种穿透。 |
| ESS-G-01 | 关注点分离 | 方法原则 | essence | G | 基础 basic | GL-ESSENCE | 按不同关注点维度把系统分解为可独立处理的部分，使每部分只承担一组相关职责。它是分解问题的元原则，为模块化与分层提供依据，成败取决于维度是否真正正交。若干流派在细节上各异，却共享同一目标：把软件切成层，且至少一层承载业务规则、另一层承载用户与系统接口。分离到位后应表现出五项可观察性质：不依赖某个功能齐备的库；业务规则脱离界面与库即可测试；界面可整体替换而其余部分不动；持久化产品可更换而规则不被绑定；业务规则对外部世界的接口一无所知。因此验收标准不是画了几条线，而是替换任意一个外部元素时改动是否被限制在边界外侧。 |
| ESS-G-02 | 依赖倒置与依赖规则 | 方法原则 | essence | G | 进阶 intermediate | GL-ESSENCE | 稳定策略不应依赖易变细节：通过抽象使高层策略与低层实现都依赖抽象，让源码依赖方向指向更稳定、更抽象的一端。其含义不是高层依赖低层再调用回来，而是双方都依赖一个由稳定侧拥有的抽象——高层定义它需要的能力，低层去实现它。配套的依赖规则要求源码依赖只能由外层指向内层，禁止反向，由此形成单向依赖图，稳定且抽象的核心不被细节牵引，边界可替换，实现细节可独立演化。但把它当铁律并不现实：系统必须依赖大量具体设施，有些具体类型改动极罕见且受严格控制，对它们的依赖不该也无法回避。可容忍的是一层稳定背景，例如操作系统与平台设施；要避开的是团队正在活跃开发、频繁变动的模块。 |
| ESS-G-03 | 边界与接口隔离 | 方法原则 | essence | G | 进阶 intermediate | GL-ESSENCE | 在模块、服务与层之间显式划定边界，并让跨边界交互仅通过窄而稳定的接口进行，把内部实现与外部契约隔离开。边界决定变更传播范围与理解成本。它要求把跨边界交互收敛为显式承诺。 |
| ESS-O-01 | 本质复杂度与偶然复杂度 | 方法原则 | essence | O | 高级 advanced | GL-ESSENCE | 这组区分由两个不对称的部分构成。本质复杂度是问题领域自身固有的概念结构，它来自所服务现实的概念关系本身，任何单一技术或管理手段都无法把它消除；偶然复杂度则是实现方式、工具局限与表示选择带来的负担，可以被工程手段持续削减。定义的关键在于归属判据而不是字面分类：某一部分难度究竟算哪一类，要看它是否随表示方式的改变而消失。这也解释了为什么这条区分是决策工具而非学术标签——它把该投问题理解还是该投工具改进变成一个可以追问的问题，使投入方向有据可依。判据可以写成一次替换实验：追问若换掉这项技术、改用另一种表示，问题的核心概念结构是否依然存在。仍然存在，说明这部分难度属于本质； |
| ESS-O-02 | 架构即权衡 | 方法原则 | essence | O | 进阶 intermediate | GL-ESSENCE | 把架构决策定义为取舍，依据是一个结构性事实：质量属性无法被孤立地达成，改善其中一项必然对其他项产生或正或负的影响。敏捷性与稳定性、安全性与性能、性能与可修改性、可靠性与成本，很难同时达到最优；再叠加预算、工期、遗留系统与团队能力等约束，架构本质上是在有限资源下的一组选择。由此推出的直接后果是最优架构这一提法失去意义——同一份设计在不同语境下会被判为恰当或失当，取决于该语境看重哪些属性、受哪些成本与合规约束。可操作的形态是把决策写成有向的代价与收益对照：选定某方案意味着接受某一组具体代价，并因此保住某一组具体收益。 |
| ESS-L-01 | 软件演化定律 | 方法原则 | essence | L | 高级 advanced | GL-ESSENCE | 描述 E 型软件在持续演化中反复出现的规律：系统必须持续变更否则逐渐失效，而持续变更又使复杂度递增、质量下降，需要以自我调节与反馈治理。它把演化视为常态而非异常。它把演化确立为需要持续投入的常态过程。 |
| ESS-N-01 | 康威定律 | 方法原则 | essence | N | 进阶 intermediate | GL-ESSENCE | 设计系统的组织受沟通结构约束，其产出会复制该组织的沟通结构；系统架构与组织结构之间存在保结构的对应关系。它提示架构设计与组织设计必须协同。它把组织设计纳入架构决策的范畴。 |
| ESS-F-01 | 软件需求 | 方法原则 | essence | F | 基础 basic | GL-ESSENCE | 软件需求是「须被某物展现、以解决现实世界问题的属性」；它描述系统应满足的「什么（what）」而非「如何做（how）」，属于对解决方案的约束与对问题空间的陈述，而非设计决定。 |
| ESS-F-02 | 干系人与需要 | 方法原则 | essence | F | 基础 basic | GL-ESSENCE | 干系人是对系统或其具备满足其需要与期望的特性拥有权利、份额、主张或利益的个人或组织；需要是对其 needs、wants、desires、expectations 与感知约束的引出，需求则由需要转化而来。 |
| ESS-F-03 | 需求可追溯性与可验证性 | 方法原则 | essence | F | 进阶 intermediate | GL-ESSENCE | 可追溯性要求每条需求都能双向链接到其来源与后续制品，可验证性要求能用客观方法判定需求是否被满足；两者共同使需求可被确认、变更影响可被分析。 |
| ESS-F-04 | 需求的不确定性与变更 | 方法原则 | essence | F | 进阶 intermediate | GL-ESSENCE | 需求在初始阶段总是不完整、模糊，并会随环境与认知变化而被修订；成功的软件必然被改变，因此需求管理必须把变更视为常态，而非应被消除的异常。 |
| ESS-F-05 | 业务与任务价值 | 方法原则 | essence | F | 进阶 intermediate | GL-ESSENCE | 需求源于业务或任务的价值目标：先定义问题或机会空间、评估备选方案，再由此导出干系人需要与系统需求，使每条需求都能回答它在为谁创造何种价值。 |
| MTH-F-01 | 需求工程过程 | 方法 | methodology | F | 进阶 intermediate | GL-METHOD | 以业务或任务分析为起点，依次经干系人需要与需求定义、系统需求定义，并在各技术过程中嵌入需求活动，由需求管理贯穿的过程链；其信息项包括业务、干系人、系统与软件需求规格。 |
| MTH-F-02 | 需求获取 | 方法 | methodology | F | 基础 basic | GL-METHOD | 系统化地从干系人、领域文档、现有系统与运行环境等来源引出需要与需求的实践；目标不是记录已陈述的诉求，而是发现真实、隐含乃至尚未成形的需要。 |
| MTH-F-03 | 干系人识别与分析 | 方法 | methodology | F | 基础 basic | GL-METHOD | 系统识别受系统影响或能影响系统的个人与组织，分析其关注点、影响力与需要，并持续维护覆盖多层级角色的干系人视图的方法。 |
| MTH-F-04 | 需求规格说明 | 方法 | methodology | F | 进阶 intermediate | GL-METHOD | 把需求以明确、无歧义、可验证的方式文档化为信息项（如软件需求规格说明）的方法，要求单条需求具备必要、无歧义、单一、可行、可验证等特性，需求集具备一致、完整、可理解等特性。 |
| MTH-F-05 | 功能与非功能需求分类 | 方法 | methodology | F | 基础 basic | GL-METHOD | 把软件需求区分为功能需求（软件须执行的功能与行为）与非功能需求（功能之外的质量约束与属性），并另行识别技术约束与服务质量约束的分类方法。 |
| MTH-F-06 | 需求属性与优先级 | 方法 | methodology | F | 进阶 intermediate | GL-METHOD | 为每条需求赋予唯一标识、优先级、依据与假定难度等属性，并据此对需求排序与范围匹配，使有限的工程投入投向最高价值与最必要的需求。 |
| ESS-I-01 | 测试作为验证与反馈机制本质 | 方法原则 | essence | I | 基础 basic | GL-ESSENCE | 软件测试是以发现缺陷、评估质量为目的的活动集合；其本质不止于事后验证——它同时为开发提供持续反馈，使团队能在变更中保持正确性，因此测试是质量保障与支持演进的双重机制。 |
| ESS-I-02 | 可测试性本质 | 方法原则 | essence | I | 基础 basic | GL-ESSENCE | 可测试性说的是软件在多大程度上容易被证明有缺陷，而不是它究竟有没有缺陷。这一定位把它从测试活动的属性挪到了被测制品的属性上：同一支测试团队、同一套方法与工具，面对可测试性不同的两份系统，建立受控情境、读取内部状态、取得稳定反馈的代价会相差数量级。它由结构赋予，属于设计期就应当确定的性质，事后很难补齐；模块边界与依赖方向一旦改变，同一份功能代码所需的测试投入就会显著变化。由此可以推出它的两个容易混淆之处。其一，它衡量的是验证成本而非正确性本身，一个可测试性极差的系统也可能几乎没有缺陷，反过来测试写得很顺手也并不等于测试已经做够。 |
| ESS-I-03 | 错误、缺陷与失效 | 方法原则 | essence | I | 进阶 intermediate | GL-ESSENCE | 错误是人的行为产生的不正确结果，缺陷是制品中导致其偏离预期行为的瑕疵，失效是系统运行时表现出的与规定行为不一致；三者构成「错误→缺陷→失效」的因果链，是测试活动的认知对象。 |
| ESS-I-04 | 测试的不可穷尽性 | 方法原则 | essence | I | 进阶 intermediate | GL-ESSENCE | 测试只能证明缺陷的存在、无法证明其不存在；由于输入、状态与执行路径的组合空间在现实中不可穷尽，测试永远是抽样活动，因此测试策略的核心不是穷尽验证，而是基于风险选择最有价值的样本。 |
| MTH-I-01 | 测试层次 | 方法 | methodology | I | 基础 basic | GL-METHOD | 测试层次是按开发生命周期阶段组织并一起管理的测试活动分组，通常从组件级逐层上升到系统级与验收级；每个层次针对不同的测试对象与关注点，回答不同的问题，并对应不同的缺陷类型与执行主体。 |
| MTH-I-02 | 测试类型 | 方法 | methodology | I | 基础 basic | GL-METHOD | 测试类型是与特定质量特性相关的一组测试活动，如功能测试与非功能测试，也可按是否依赖内部结构分为黑盒、白盒与经验型；大多数测试类型可应用于每一个测试层次，层次与类型是两个正交的坐标。 |
| MTH-I-03 | 测试驱动开发 | 方法 | methodology | I | 进阶 intermediate | GL-METHOD | 测试驱动开发（TDD）是先写测试、再写实现、随后重构的开发技术，核心为红-绿-重构三步循环：先写一个失败的测试明确目标，再以最小实现使其通过，最后在测试保护下改善结构。 |
| MTH-I-04 | 测试金字塔与反模式 | 方法 | methodology | I | 进阶 intermediate | GL-METHOD | 测试金字塔是按粒度与数量组织自动化测试的模型：底层应有多得多的快速隔离单元测试，中层为适量服务/集成测试，顶层为少量端到端测试；倒置的金字塔（冰淇淋甜筒）与缺失中间层的沙漏是典型反模式。 |
| MTH-I-05 | 测试替身与测试策略 | 方法 | methodology | I | 进阶 intermediate | GL-METHOD | 测试替身是在测试中替换生产对象的任何协作对象的泛称，包括哑元、伪造、桩、监视与模拟五类；按需要隔离的程度选择替身类型，并控制替身的使用范围，是平衡测试速度、确定性与保真度的关键策略。 |
| MTH-I-06 | 质量门控与持续集成 | 方法 | methodology | I | 进阶 intermediate | GL-METHOD | 持续集成要求开发者频繁把改动合并回主线，并由自动化构建与测试验证；质量门控则用一组在分析时度量的条件判定制品是否可发布，任一条件不满足即阻断构建或合并，把测试与质量检查制度化为交付闸门。 |
| MTH-I-07 | 软件测试过程模型 | 方法 | methodology | I | 高级 advanced | GL-METHOD | 软件测试过程模型把测试描述为可治理、可管理、可实施的分层过程：组织级制定测试方针与策略，管理级规划、监控与收尾测试项目，动态级设计、实现、执行并报告具体测试，可配合不同开发生命周期使用。 |
| ESS-J-01 | 构建发布运行分离 | 方法原则 | essence | J | 基础 basic | GL-ESSENCE | 软件交付须严格分离构建、发布、运行三阶段：构建把代码转换为可执行制品，发布把制品与当次配置合并为带唯一标识的不可变版本，运行只启动选定版本，且运行阶段不存在把改动写回构建的通道。 |
| ESS-J-02 | 开发生产一致性 | 方法原则 | essence | J | 基础 basic | GL-ESSENCE | 开发、预发与生产环境应尽可能相似，把时间差、人员差与工具差压到最小，并使用同类型同版本的支撑服务，使在早期环境中验证过的行为在生产中依然成立。 |
| ESS-J-03 | 不可变基础设施 | 方法原则 | essence | J | 进阶 intermediate | GL-ESSENCE | 部署完成后的基础设施（服务器、网络设备、运行实例）不再被就地修改，任何变更都通过创建新版本并替换实例实现，从而把运行环境的实际状态锚定在经测试的制品上。 |
| ESS-J-04 | 部署即变更管理 | 方法原则 | essence | J | 进阶 intermediate | GL-ESSENCE | 部署不是一次性的文件拷贝，而是一次受控、可审计、可回滚的变更：应明确谁在何时以何制品更改了哪个环境的什么状态，并为失败预留恢复路径。 |
| MTH-J-01 | 部署流水线 | 方法 | methodology | J | 基础 basic | GL-METHOD | 把从代码到生产的交付拆为多个自动阶段，每阶段提升置信度（通常以更多时间为代价），只构建一次并让同一制品逐环境提升，从而尽早检出会导致生产问题的变更。 |
| MTH-J-02 | 发布工程 | 方法 | methodology | J | 进阶 intermediate | GL-METHOD | 以可复现、自动化的方式构建并交付软件的工程学科，覆盖源码管理、编译、构建配置、包管理与安装，确保每次发布都可重复，而非一次性的独特雪花。 |
| MTH-J-03 | 封闭构建 | 方法 | methodology | J | 进阶 intermediate | GL-METHOD | 对构建机器已安装的库与软件不敏感、只依赖已知版本编译器与库的自足构建过程，使同一版本在不同机器上构建得到一致结果。 |
| MTH-J-04 | 配置外置与显式化 | 方法 | methodology | J | 基础 basic | GL-METHOD | 把随部署环境变化的一切（凭据、资源句柄、每次部署的取值）从代码中严格分离并显式声明，使同一不可变制品能通过注入不同配置部署到任意环境。 |
| MTH-J-05 | 渐进暴露部署策略 | 方法 | methodology | J | 进阶 intermediate | GL-METHOD | 把新版本分阶段、逐步暴露给更大范围的用户与基础设施，而非一次性全量切换；蓝绿以双环境切换、金丝雀以小比例扩量、滚动以实例渐替，均以健康判据驱动推进。 |
| MTH-J-06 | 发布与部署解耦 | 方法 | methodology | J | 高级 advanced | GL-METHOD | 把把制品投入运行环境（部署）与让功能对用户可见（发布）分离，使代码可以先部署而暂不启用，功能的开放由运行时开关独立控制。 |
| MTH-J-07 | 可回滚性与爆炸半径控制 | 方法 | methodology | J | 高级 advanced | GL-METHOD | 为每次变更预置快速、可靠的恢复能力，并把失败的影响限制在尽可能小的范围：通过制品版本化与路由切换实现快速回滚，通过渐进暴露与故障隔离压缩爆炸半径。 |
| ESS-K-01 | 可靠性即风险管理 | 方法原则 | essence | K | 基础 basic | GL-ESSENCE | 服务可靠性不是追求零故障，而是在创新速度与稳定之间对可接受风险做显式管理：把不可靠度视为有限、可预算的资源，据此决定何时发布、何时加固。 |
| ESS-K-02 | 故障不可避免性与容错 | 方法原则 | essence | K | 基础 basic | GL-ESSENCE | 可靠性与容错这组概念要先分清两个词。局部停止正常工作叫故障，例如一块盘坏掉、一台机器宕机，或所依赖的外部服务中断；整个系统不再满足对用户承诺的服务级别目标叫失效。两者其实是同一件事在不同观察层次上的称呼：只有一块盘的系统里，盘坏就是系统失效；而在多盘系统里，单盘坏掉只是整体视角下的一项故障，只要数据在别处还有副本，服务就能继续。由此得到容错的定义，即出现某些故障时仍能照常提供服务；反过来，某部分一旦出问题就必然升级为整体失效，这个部分就是单点故障。 定义里还隐含一层要求：容错总是相对于某个服务级别承诺而言的，离开承诺就无所谓失效。 |
| ESS-K-03 | 可观测性本质 | 方法原则 | essence | K | 进阶 intermediate | GL-ESSENCE | 可观测性是仅凭系统对外产生的输出，推断其内部状态、回答未预先设问之问题（未知未知）与「为什么」的能力；它要求系统先具备充分的自我表达，而非事后拼凑。 |
| ESS-K-04 | 度量驱动的反馈闭环 | 方法原则 | essence | K | 进阶 intermediate | GL-ESSENCE | 运维与可靠性改进必须以可观测的度量形成闭环：用度量暴露现状、驱动决策、验证效果，再据结果校准下一轮行动，使改进成为持续的反馈过程而非一次性工程。 |
| MTH-K-01 | 服务等级目标方法 | 方法 | methodology | K | 基础 basic | GL-METHOD | 用「好事件数 / 总事件数」定义服务水平指标，据此设定低于百分之百的目标值与聚合窗口，并与含后果的协议相区分，把模糊的服务质量转化为可度量、可协商、可决策的目标。 |
| MTH-K-02 | 错误预算政策与燃尽率告警 | 方法 | methodology | K | 进阶 intermediate | GL-METHOD | 把允许失败量（100% 减去目标）配套为组织政策，明确预算耗尽时的发布、回滚与加固动作；并以多窗口、多燃尽率组合告警，在预算被快速消耗时及时触发干预。 |
| MTH-K-03 | 四大黄金信号监控方法 | 方法 | methodology | K | 基础 basic | GL-METHOD | 面向用户的系统若只能测量四个指标，就选延迟、流量、错误与饱和度；它们覆盖用户感知的核心维度，并以症状而非原因驱动告警，从而在信息有限时仍能及时发现并定位问题。 |
| MTH-K-04 | 可观测性信号关联方法 | 方法 | methodology | K | 进阶 intermediate | GL-METHOD | 用数值聚合、带上下文的事件记录与请求级路径追踪三类信号共同刻画系统，并通过统一的身份与时间基准把它们关联起来；价值在于信号可相互串联以定位根因，而非信号数量或支柱的划分。 |
| MTH-K-05 | 事件响应与无指责复盘方法 | 方法 | methodology | K | 进阶 intermediate | GL-METHOD | 以明确的角色分工、活文档与显式交接组织事件响应，尽快缓解影响；事后以无指责复盘聚焦系统性成因、假设参与者基于当时信息善意行事，并把行动项闭环为可验证的改进。 |
| MTH-K-06 | 混沌工程方法 | 方法 | methodology | K | 高级 advanced | GL-METHOD | 在生产环境中对系统做受控实验：先定义稳态与假设，再注入真实的动荡变量，比较对照组与实验组的差异以证伪假设，从而主动发现系统性弱点并建立对系统韧性的信心。 |
| MTH-K-07 | 容量规划与变更管理方法 | 方法 | methodology | K | 高级 advanced | GL-METHOD | 以意图驱动的方式编码服务依赖与冗余约束、随需求与供给变化自动重算资源计划；同时把发布变更视为首要故障来源，以渐进暴露、分批与门控降低变更风险并测量其效果。 |
| ESS-L-02 | 技术债本质 | 方法原则 | essence | L | 进阶 intermediate | GL-ESSENCE | 技术债是用短期便利换取长期变更成本的设计权衡，其本质是经济取舍而非道德评判：审慎而有意的债务可加速交付，判断标准是债是否审慎、是否被及时偿还，而非是否存在。 |
| ESS-L-03 | 架构侵蚀与漂移 | 方法原则 | essence | L | 高级 advanced | GL-ESSENCE | 架构侵蚀是违反既定架构约束的改动导致的系统脆化，架构漂移是对架构不敏感的改动导致的逐渐失一致；两者共同使系统越来越抗拒变更，是架构层腐化的两种机制。 |
| ESS-L-04 | 演化的不可逆性 | 方法原则 | essence | L | 进阶 intermediate | GL-ESSENCE | 成功投入使用的软件必然持续被修改，且演化在方向上是不可逆的：需求、环境与依赖的变化使系统无法回到先前状态，冻结系统只会加速其价值衰减。 |
| ESS-L-05 | 变更成本随复杂度增长 | 方法原则 | essence | L | 进阶 intermediate | GL-ESSENCE | 这条原则描述的是一种随规模累积的效应：项目小时代码可以短小漂亮，一旦持续扩张，结构就越来越难把握，每一次改动都要付出更多的理解与验证成本。这种状态被形象地称为复杂泥潭。它的定义要点是成本的位置发生了转移，复杂度并不直接表现为功能缺失或性能下降，而是表现为动手变慢、出错变多、预算与排期双双失守。因为结构越难让人推理，改动者就越容易漏看隐含前提、副作用与意料之外的相互干扰。所以简单性被提升为构建系统时的关键目标之一，它与可运维性、可演化性并列，共同构成可维护性的三个面向。 把这层定义再推进一步，可以看出复杂度并非某种可以一次性清除的杂质，而是一种随功能与规模必然增长的存量。 |
| MTH-L-01 | 行为保持重构 | 方法 | methodology | L | 基础 basic | GL-METHOD | 在不改变可观察行为的前提下重组软件内部结构，使其更易理解、更易修改；判定重构是否成立的硬标准是行为不变，治理要点是把小步变换持续进行而非安排一次性大改。 |
| MTH-L-02 | 代码坏味道启发式 | 方法 | methodology | L | 基础 basic | GL-METHOD | 把代码中易于察觉的表层迹象作为可能指向更深层结构问题的启发式信号，用以发现重构对象与时机；坏味道提示「值得检查」，但不等于「一定有问题」，不能机械照改。 |
| MTH-L-03 | 技术债象限与偿还策略 | 方法 | methodology | L | 进阶 intermediate | GL-METHOD | 以「有意/无意」与「审慎/鲁莽」两组正交判据对债务分诊，据此制定差异化偿还策略：审慎有意者计划偿还，审慎无意者随认知更新修正，鲁莽者立即纠正，并按变更热点优先偿付利息最高的债务。 |
| MTH-L-04 | 演进式架构 | 方法 | methodology | L | 高级 advanced | GL-METHOD | 把「有引导的增量变更」确立为跨多个架构维度的首要原则：通过定义架构维度、以可执行机制持续校验合规，并用增量交付验证，使架构能在不失去完整性的前提下持续演化。 |
| MTH-L-05 | 架构适应度函数 | 方法 | methodology | L | 高级 advanced | GL-METHOD | 对某些架构特性提供客观完整性评估的可执行机制：把架构意图转写为可判定、可量化的校验，在构建或运行时持续验证，使架构约束不依赖人的记忆与自觉，从而抑制架构漂移。 |
| MTH-L-06 | 遗留系统渐进治理 | 方法 | methodology | L | 高级 advanced | GL-METHOD | 对难以安全修改的遗留系统，先以接缝与特征测试建立覆盖既有行为的安全网，再以绞杀者方式增量迁移新功能、逐步替代旧系统，避免缺乏保护的大规模重写。 |
| MTH-L-07 | 弃用与日落策略 | 方法 | methodology | L | 进阶 intermediate | GL-METHOD | 对将被淘汰的能力采取分级的退场流程：先发出弃用信号并提供替代与迁移路径，留足通知期，再按版本语义区分兼容的弃用与破坏性的移除，从而在收敛接口的同时不破坏既有依赖。 |
| ESS-M-01 | 可维护性本质 | 方法原则 | essence | M | 基础 basic | GL-ESSENCE | 可维护性不是单一属性，而是被拆成三根支柱，各有明确所指。可运维性让组织能省力地把系统稳定跑下去：开放关键指标供监控采集、不让任何一台机器成为必需、给出清晰文档与可预期的操作模型、提供合理默认值同时允许覆盖、在恰当处自动修复也保留人工接管。简单性要求采用为人熟知且前后一致的模式与结构，把不必要复杂度挡在外面，使新加入的人也能读懂系统。可演化性要求系统在需求变动时便于调整与扩展，包括事先未预料到的使用场景。三者共同的动机是成本结构：软件的主要开销落在持续维护而非初次开发，涵盖修缺陷、保持运行、调查失效、适配新平台、支持新场景、偿还技术债与添加功能； |
| ESS-M-02 | 可演化性与可扩展性 | 方法原则 | essence | M | 进阶 intermediate | GL-ESSENCE | 可伸缩性之所以不能简化为一个标签，是因为它由两步组成：先刻画负载，再评估资源与性能的关系。刻画负载通常取某项吞吐量指标，比如每秒请求数、每天新增数据量或每小时结账次数，有时取峰值如同时在线人数；读写比例、缓存命中率、单用户数据项数等统计特征同样会改变访问模式与伸缩要求。第二步从两个角度提问：资源不变时加大负载，性能如何变化；希望性能不变时，要增加多少资源。常见的经验是资源翻倍换两倍负载，即线性伸缩，偶尔因规模经济或峰值更均匀而优于线性，但更常见的是成本增长快于线性——数据量大时，同样大小的写入也要做更多工作。 |
| ESS-M-03 | 性能效率本质 | 方法原则 | essence | M | 基础 basic | GL-ESSENCE | 性能效率的可操作含义是：起点为某个具体事件抵达系统，终点为系统在给定的时间或资源预算内交出响应。因此一条可用的性能陈述至少要同时说清三件事——负载以什么形态、以多快的节奏到来；允许多长的等待或多大的资源开销；以及用什么量去判定是否达标。反例是把性能写成「系统应当很快」，它既没指明哪类事件，也没指明并发规模与度量口径，因而无法验证也无法验收。另一处容易被忽略的边界是：性能要求即便从未被明文写出，也客观存在并被使用者感知，例如按键后整整一秒才显示字符的编辑器会被直接判定为不可用；所以缺省的性能期望应被主动补写成场景。 |
| ESS-M-04 | 可靠性与可用性 | 方法原则 | essence | M | 进阶 intermediate | GL-ESSENCE | 可靠性用一句话概括就是即使出了问题也能继续正确工作，其外延由用户期望给出：功能符合预期、允许用户犯错或以非预期方式使用、在预期负载与数据量下性能足够、能挡住未授权访问与滥用。定义的关键动作是把故障与失效分开：故障指系统的某个部分停止正常工作，失效指整个系统不再提供所需服务、即未达到服务级别目标。二者常被混为一谈，其实只是观察层次不同——单块硬盘停转对只有一块盘的机器就是失效，对多盘系统只是一项故障，只要别处还有副本，系统就可能容忍它。可靠性因此以服务级别目标来衡量。容错总是针对特定类型与数量的故障而言，无法容忍某部分故障的部分称为单点故障； |
| ESS-M-05 | 质量属性不可直接测量 | 方法原则 | essence | M | 基础 basic | GL-ESSENCE | 质量属性的界定要点有三：其一，它描述的不是系统做什么，而是干系人对系统效用的满意程度；其二，它必须能被量化观察或验证，否则无法进入验收；其三，它总是附着在功能之上——同一段功能可以配不同的响应快慢、允许出错频次与上手难度等标注。因此质量属性不是功能的替代品，而是对功能的约束与修饰：脱离功能谈质量属性会失去落点，只谈功能不谈质量属性则无法判断系统是否真的好用。可量化这一条是硬约束，不可量化的质量诉求既无法判定也无法验收，只能停留在主观评价层面。 |
| MTH-M-01 | 质量属性战术映射方法 | 方法 | methodology | M | 进阶 intermediate | GL-METHOD | 战术是影响某项质量属性响应能否达成的设计决策，它直接作用于系统对某类刺激的反应。与模式的区别在于作用范围：战术瞄准单项质量属性的响应，模式描述的是特定语境下反复出现的设计问题及其被验证过的解法，用元素的角色、职责、关系与协作方式来表述。适用边界在于：一条设计决策如果说不清它针对哪类刺激、要改变哪项响应，就还不构成战术，只是普通的实现选择。把每项质量属性目标映射到一组可组合的战术，再由战术组合成架构策略、打包为模式，这一映射的作用是把抽象的质量目标转化为具体、可评审的设计动作。战术位于模式与单条质量属性之间：模式是面向完整问题的打包方案，粒度大、语境强； |
| MTH-M-02 | 可修改性战术应用 | 方法 | methodology | M | 进阶 intermediate | GL-METHOD | 可修改性指系统在需求或环境变化时，以可接受的代价完成修改的能力。其方法以耦合、内聚与成本动因为依据应用一组战术：推迟绑定时间、局部化变更、防止涟漪效应，使修改集中在局部、缩小受影响模块数与回归风险，从而降低变更成本。判据不是代码是否整齐，而是「改动一个模块时，有多少其它模块必须随之改动」。影响范围由模块之间的相互牵连程度与模块内部职责的聚合程度共同决定：牵连越高、聚合越低，一次改动波及的范围就越广。变更成本等于改动本身的成本加上因耦合被牵连的其它模块的成本，故减少后者往往比减少前者更能显著降低总成本。 |
| MTH-M-03 | 可用性战术应用 | 方法 | methodology | M | 进阶 intermediate | GL-METHOD | 可用性讨论的起点是把两个词分清：失效指系统不再按规格交付服务，且这一情况能被参与者观察到；故障指可能导致失效的潜在原因。二者是因果而非同义关系，一组故障有可能引发失效，也可能被挡住而不引发。这个区分支撑了整章的策略：战术的作用就是阻止故障演化为失效，或者在无法阻止时把影响限定住，并让修复成为可能。由此也可以解释为什么没有宕机不能证明架构可用——故障可能一直在发生，只是尚未被观察到。围绕这个目标，可用性战术按目的分三类：检测故障、从故障中恢复、预防故障。 |
| MTH-M-04 | 质量模型应用方法 | 方法 | methodology | M | 进阶 intermediate | GL-METHOD | 以标准化的质量模型（由质量特性与子特性构成的框架）为共同参照，把分散的质量关切组织为可规定、可测量、可评价的维度，并据此在需求、设计与评价之间建立一致的映射。 |
| MTH-M-05 | 可维护性评估方法 | 方法 | methodology | M | 高级 advanced | GL-METHOD | 沿可维护性的子特性组织证据，结合结构度量、变更历史与维护过程指标，对系统「修改得有多有效、多高效」做出可比较判断，并据此定位需优先治理的结构问题。 |
| MTH-M-06 | 质量属性权衡决策方法 | 方法 | methodology | M | 高级 advanced | GL-METHOD | 面对相互牵制的质量属性，先以场景明确各属性目标与可接受边界，再识别同时影响多个属性的权衡点，通过显式比较与优先级排序做出可解释、可复核、可撤销的决策。质量属性很少能同时最优：为提升性能引入缓存会加剧一致性难度，为增强安全增加校验会拖慢响应，为提高可用性增加冗余会抬高成本与复杂度，为改善可维护性增加抽象会消耗运行期资源。因此架构设计的本质不是让每个属性都最大化，而是在给定语境下选择一组彼此相容的目标，并对冲突处做出有依据的取舍。 |
| ESS-N-02 | 组织-架构同态 | 方法原则 | essence | N | 进阶 intermediate | GL-ESSENCE | 组织沟通结构与其所设计系统的架构之间存在保结构的同态关系：沟通密集处趋于高内聚，沟通稀疏处趋于系统边界；若每个子系统各有独立设计组，两种结构几乎完全一致。 |
| ESS-N-03 | 团队边界与架构边界耦合 | 方法原则 | essence | N | 进阶 intermediate | GL-ESSENCE | 团队边界与系统架构边界相互耦合：团队负责范围若与模块边界错位，跨边界协调成本会以接口复杂度、交接与返工的形式转嫁到系统上，二者需同步演化。 |
| ESS-N-04 | 认知负荷约束 | 方法原则 | essence | N | 基础 basic | GL-ESSENCE | 团队能承载的复杂度有限，每一个新增的工具、职责或领域都消耗其心智带宽；认知负荷因此是划分团队与架构时必须显式考虑的约束，而非可忽略的软因素。 |
| ESS-N-05 | 组织即设计系统 | 方法原则 | essence | N | 高级 advanced | GL-ESSENCE | 承担系统设计的组织本身也是一个需要被设计的系统：其结构、边界、沟通与激励机制共同决定它能产出什么样的架构，因此组织设计应被视为技术设计的组成部分。 |
| MTH-N-01 | 逆向康威操作 | 方法 | methodology | N | 进阶 intermediate | GL-METHOD | 主动演进团队与组织结构，使其沟通结构对应期望的软件架构，从而让目标架构在组织沟通结构的塑形作用下自然生长，而非在既有组织形态下被扭曲。 |
| MTH-N-02 | 团队拓扑四类型 | 方法 | methodology | N | 进阶 intermediate | GL-METHOD | 把团队设计约束为四种基本形态——对齐价值流的团队、教练赋能团队、复杂子系统团队与平台团队——借成熟模式引导快速流动，同时以有限类型抑制组织设计的随意性。 |
| MTH-N-03 | 团队交互模式 | 方法 | methodology | N | 进阶 intermediate | GL-METHOD | 显式定义团队之间的交互方式——限时高带宽协作、清晰边界的服务消费、以及教练式促进——以消除含糊的协调要求，使团队边界的成本与收益可被管理。 |
| MTH-N-04 | 平台团队与最薄可行平台 | 方法 | methodology | N | 进阶 intermediate | GL-METHOD | 以产品方式建设平台团队，把通用能力封装为可自助使用的内部产品，以降低流对齐团队的认知负荷、加速交付；并以最薄可行平台约束平台规模，避免臃肿平台制造新依赖。 |
| MTH-N-05 | DORA 交付效能指标 | 方法 | methodology | N | 进阶 intermediate | GL-METHOD | 以一组经过实证的软件交付效能指标——吞吐侧的变更前置时间、部署频率、失败部署恢复时间，与不稳定侧的变更失败率、部署返工率——衡量组织把变更交付到生产的效能，并用于改进而非考核。 |
| MTH-N-06 | 团队边界治理 | 方法 | methodology | N | 高级 advanced | GL-METHOD | 把团队边界视为需要持续校准的活对象：以价值流、所有权、认知负荷与交付信号为依据，周期性评估并调整边界与交互方式，防止边界随组织惯性僵化或频繁漂移。 |
| ESS-O-03 | 权衡的不可消除性 | 方法原则 | essence | O | 进阶 intermediate | GL-ESSENCE | 任何设计都在有限资源与相互牵制的目标之间做选择，优化一个维度通常以牺牲另一个为代价；权衡不能被消除，只能被显式化、迁移，或在具体语境下选出更合适的落点。这一定义有三层含义需要分开。第一层是它的形式：取舍不是方案的缺陷，而是方案的定义本身，选定某条路径就等于同时接受了一组代价并保住了一组收益，因此描述一个架构决策的完整方式是成对陈述而不是单向宣称。第二层是它的来源：权衡之所以不可消除，一是资源有限，时间、算力、人力与注意力无法同时无上限地投向每个方向；二是目标之间存在结构性冲突，一方改善会直接牵制另一方，这层冲突不会因为预算变多而消失。 |
| MTH-O-01 | 覆盖与精度的不对称权衡 | 方法 | methodology | O | 进阶 intermediate | GL-METHOD | 在同一活动中，高覆盖（宁多勿漏）与高精度（宁缺毋滥）此消彼长；因漏失常不可补救而噪声多可过滤，代价不对称，故默认偏向覆盖，再以分层门控逐级精筛。 |
| MTH-O-02 | 准入与触发时机选择 | 方法 | methodology | O | 进阶 intermediate | GL-METHOD | 决定何时、由谁把产物推进下一环节：人工门控可控但易漏、自动流转高效但可能放行半成品，应在「可信度门槛与发生频率」两个维度上选择人工、自动或半自动策略。 |
| MTH-O-03 | 技术选型的够用原则 | 方法 | methodology | O | 进阶 intermediate | GL-METHOD | 技术选型方法处理的是在标准、框架、架构风格与外部构件之间做选择的问题：按适用域与约束匹配需求，挑出刚好覆盖质量属性场景的方案，因为任何额外能力都伴随新的复杂度。其判据落在质量属性场景上——在能覆盖当前需求与可预见需求的前提下，选那个其余代价最小的方案，而不是功能清单最长或技术最新潮的那个。它要求同时说清三件事：当前方案满足哪些场景、刻意不满足哪些场景、以及在什么条件下应当改变选择，使选型从一次性拍板变成可持续复核的工程判断。据此，「够用」不是能力上的将就，而是把不产生收益的复杂度明确排除在外。 |
| MTH-O-04 | 能力-成本-速度三角 | 方法 | methodology | O | 进阶 intermediate | GL-METHOD | 在能力/质量、成本与交付速度之间取舍时，须区分一次性成本与持续成本，先量化各方案的人力、基础设施与运维开销；研究表明速度与稳定可兼得，成本优化的重点应是持续成本与减小变更批量。 |
| MTH-O-05 | 质量属性冲突治理 | 方法 | methodology | O | 高级 advanced | GL-METHOD | 质量属性冲突治理，指在架构决策过程中把多个质量属性之间此消彼长的关系从隐性经验转为显式可裁决对象的成套做法。它处理的不是单个属性如何达成，而是当若干属性同时提出要求、且这些要求由同一批设计决策承载时，如何给出有依据、可追溯、可重议的取舍。这里的治理一词有两重含义：一是承认冲突的常态化，不把「所有属性同时最优」当作可追求的目标；二是把处理冲突的动作固定成流程，使结论不依赖某一次讨论中谁的声音更大。它的治理单位是场景而不是属性名词：属性只有被写成带刺激、环境与响应度量的场景之后，才可能被比较、被排序、被判为达成或未达成；离开场景，「性能好」「安全性高」这类表述无法支撑任何裁决。 |
| MTH-O-06 | 粒度与边界设定 | 方法 | methodology | O | 高级 advanced | GL-METHOD | 决定模块、服务、知识域与团队按什么分解、切到多细：应围绕可能变化的设计决策（信息隐藏）而非处理步骤切分，用内聚耦合度量与认知负荷约束边界，并使架构边界与团队边界同步演化。 |
| MTH-O-07 | 自动化方式选择 | 方法 | methodology | O | 进阶 intermediate | GL-METHOD | 在规则/模板、模型生成与纯人工之间选择实现方式：模板与规则零成本且可控，模型与自动化适合高频或复杂场景；应按沉淀粒度与可信度门槛选择，并为自动化配置持续执行与反馈闭环。 |
| MTH-O-08 | 复杂度阶梯与演进时机 | 方法 | methodology | O | 进阶 intermediate | GL-METHOD | 在简单与复杂方案之间选择与进阶时机：复杂方案的建设、延迟与一致性成本更高，应先跑通最简单可工作的方案，待出现明确且当前的跨域或规模需求时再逐步演进，而非为预想的未来提前复杂化。 |
| MTH-O-09 | 理解成本优先的简单原则 | 方法 | methodology | O | 进阶 intermediate | GL-METHOD | 这里的简单性指采用人们熟悉且前后一致的模式与结构，使新加入的工程师也能较快理解系统，而不是指功能数量少。书中把简单性列为可维护性的三根支柱之一，与可运维性、可演化性并列，理由很直接：维护成本占据软件生命周期支出的大头，而复杂度会让每一个改动系统的人都变慢，进而推高维护成本。判别困难也写得很诚实——是否简单带有主观成分，缺少客观刻度，因此同一个系统可以因为把复杂实现藏在简单接口之后而被认为简单，也可以因为实现本身直白却暴露大量内部细节而被认为复杂。所以简单性应作为设计目标显式提出，并接受它需要靠判断而非靠计数来裁定，也需要在评审中被反复追问，而不是默认它已经成立。 |
| MTH-O-10 | 增量演化与一致性治理 | 方法 | methodology | O | 高级 advanced | GL-METHOD | 在演化中治理一致性：优先用增量同步、契约与弃用信号替代全量重建，用适应度函数持续防止架构漂移，并以 expand/contract、绞杀者等模式渐进迁移，使变更小批量、可回退。 |
| MTH-O-11 | 度量与反馈闭环 | 方法 | methodology | O | 高级 advanced | GL-METHOD | 建立轻量、客观、可复现的评估体系与反馈闭环：用真实场景与基线度量、以多指标协同避免单点失真，并把度量接入持续执行与复测；同时警惕古德哈特定律，防止指标一旦成为目标即被博弈。 |
| ESS-G-07 | 架构描述与对应关系 | 方法原则 | essence | G | 进阶 intermediate | GL-ESSENCE | 架构本身是不可见的抽象，表达架构的工件称为架构描述（AD）。AD 由描述元素、模型种类与对应关系构成，并以对应的强制规则约束视图内部及视图之间的一致性、可追溯与组合，使多份面向不同关注点的局部表达汇成对同一架构的统一、可校验的整体。 |
| MTH-G-05 | 架构文档化方法 | 方法 | methodology | G | 进阶 intermediate | GL-METHOD | 以「文档化相关视图，再文档化适用于多个视图的信息」为组织原则的架构文档化方法：先按预期用途与干系人关注选择视图，再表达每个视图的「如何组织、架构是什么、为何如此」，并以跨视图信息与一致性校验避免文档过载与失真。 |
| MTH-G-06 | 效用树与敏感点权衡点分析 | 方法 | methodology | G | 高级 advanced | GL-METHOD | 把质量属性自顶向下细化为带刺激与响应度量的场景并排序，形成效用树；再沿树把架构决策逐条映射到场景上，标出对单一属性响应影响显著者与同时反向影响多项者，并归纳风险主题。它把笼统的质量目标变成可探测、可排序、可聚焦的风险清单。效用树的结构可以逐层读出：根节点表示系统整体的好，其下一层列出该系统必须呈现的主要质量属性，再下一层把每个属性细化为与本系统相关的具体侧面，叶片位置放的是以刺激与响应度量写成的场景。它之所以被设计成树而非清单，是因为自顶向下逐层收窄能把笼统的属性名逼到可判定的场景，避免停留在可修改、高吞吐这类无法验收的层面。 |
| ESS-H-08 | SOLID 职责划分与替换性 | 方法原则 | essence | H | 进阶 intermediate | GL-ESSENCE | SOLID 是一组以职责划分与可替换性为判据的面向对象设计原则族：单一职责约束变更原因，开闭原则要求以扩展而非修改应对变化，里氏替换与接口隔离约束子类型与接口依赖，依赖倒置约束依赖方向。 |
| ESS-H-09 | 设计模式与反模式 | 方法原则 | essence | H | 进阶 intermediate | GL-ESSENCE | 设计模式是对反复出现的设计问题所给的可复用解法模板，提供团队共同语言但不保证适用；反模式是初看合理却适得其反的常见解法，二者把设计经验的正反两面固化为可传承的知识。 |
| MTH-H-03 | 战略式编程与持续设计投入 | 方法 | methodology | H | 进阶 intermediate | GL-METHOD | 一种把系统设计视为贯穿开发全过程的持续投入、而非开工前一次性阶段的编程纪律：以持续、小步的设计改进对抗复杂度的累积，使系统长期保持易于理解与修改。 |
| MTH-H-04 | 代码复审与可读性治理 | 方法 | methodology | H | 进阶 intermediate | GL-METHOD | 以评审流程把可读性与结构标准组织化、可教学地传播的治理方法：把代码评审从个人偏好检查转为有依据、有导师机制的常规活动，在变更合入前对结构、接口与可读性施加统一约束。 |
| CAS-X-01 | 去中心化聊天架构逆向 | 案例 | — | X | 进阶 intermediate | GC-CASE | 对一个仅有 58 份设计文档、尚未实现的开源去中心化聊天项目做架构逆向：从设计文本提炼 18 个模块及其依赖关系，重建模块依赖 DAG 与三条核心数据流 DAG，并输出全景理解与深度需求分析。 |
| CAS-X-02 | 网申填写扩展逆向架构 | 案例 | — | X | 进阶 intermediate | GC-CASE | 对 Chrome MV3 网申自动填写扩展的逆向架构分析：梳理 popup、content、background、options 四模块职责，解剖 12 个站点适配器、双通道消息协议与隐私脱敏机制，并评估其零依赖零构建选型。 |
| CAS-X-03 | 网申 v3 多模块解耦 | 案例 | — | X | 进阶 intermediate | GC-CASE | 一套面向高可扩展性的网申信息速查扩展架构：以 schema.js 为唯一数据驱动源，把数据模型、存储、纯函数与渲染组织为严格单向依赖的共享层，供 popup 与页面浮层双容器复用，并先立跨模块接口契约。 |
| CAS-X-04 | 网申 v2 深度重构 | 案例 | — | X | 高级 advanced | GC-CASE | 一次由「改一处漏多处」症状触发的深度重构：定位到接口定义散落 12 个文件、存在 7 种接口形态的根因后，以单一契约源、dispatch 消息表与能力注册中心重建三层契约系统，恢复可审计与可校验性。 |
| CAS-X-05 | preset 通道耦合分析 | 案例 | — | X | 高级 advanced | GC-CASE | 对 harness「委派工具层→续用管理器→preset 服务→MCP 服务器」这条通道做耦合分析：识别契约、服务定位、数据契约、组合语义、路径与装配一致性六类耦合点，定位「静默丢弃特化」与「装配漂移」两处实质缝隙。 |
| CAS-X-06 | 插件 DAG RC5→RC7 升级 | 案例 | — | X | 高级 advanced | GC-CASE | 一次知识库随上游源码版本升级的级联维护：以三层差异分析把 219 个包收敛为 26 个实质变更包，经编译、运行时、组合三类依赖判定更新 DAG 数据后全量重生成页面，并以静态门控加渲染验证收口。 |
| CAS-X-07 | 插件 DAG 两次级联升级 | 案例 | — | X | 高级 advanced | GC-CASE | 在同一知识库上继续两轮上游级联升级：处理数百次提交与包的增删，暴露「依赖声明不等于运行时引用」、分层须按最长路径深度、纯外部依赖边不得入主图等差分陷阱，并以全量门控校验收口。 |
| CAS-X-08 | dsh-manager 插件深度分析 | 案例 | — | X | 高级 advanced | GC-CASE | 以「编译依赖、运行时注入、组合装配」三硬依据加源码行号，对第三方插件做依赖、功能、需求溯源与设计问题裁决，并复用上游 DAG 知识库节点标识，使分析结果可与主图互查。 |
| CAS-X-09 | harness 源码架构解析 | 案例 | — | X | 高级 advanced | GC-CASE | 对 deepseek-harness 官方源码做分层解析：镜像官方架构文档，按九个层与九十余模块建立文档集群，产出跨层联动矩阵与七条关键路径，并钉住「模型可见即已记录」、能力缝三角等设计不变量。 |
| CAS-X-10 | dsh 插件依赖增量定位 | 案例 | — | X | 进阶 intermediate | GC-CASE | 以官方插件 DAG 为蓝本，对一个官方清单之外的全新社区插件做功能定位与依赖位置增量分析，产出可下钻交互依赖图与多形态文档的源码级架构逆向案例。 |
| CAS-X-11 | Hermes 七层架构总览 | 案例 | — | X | 高级 advanced | GC-CASE | 对八千余文件的工业级 AI Agent 项目做七层架构总览逆向，揭示其「越用越聪明」的自进化闭环如何在层间传导的控制型架构案例。 |
| CAS-X-12 | MCP 四件套选型对比 | 案例 | — | X | 进阶 intermediate | GC-CASE | 对四个同类 MCP 服务器做源码级能力与成本对比，并以常驻 token 预算为轴给出分级接入策略的技术选型实战案例。 |
| CAS-X-13 | Claude Code 架构逆向 | 案例 | — | X | 高级 advanced | GC-CASE | 以社区逆向源码、系统提示词与官方文档三源交叉验证，还原一个商业 Agent 的查询引擎、子Agent、工具与权限体系的逆向分析案例。 |
| CAS-X-14 | OpenSpec 规约驱动解析 | 案例 | — | X | 进阶 intermediate | GC-CASE | 对比规约驱动开发工具链 OpenSpec 与 Superpower 的元模型、工件依赖 DAG 与安全门控，提炼「规约先于实现」工程形态的解析案例。 |
| CAS-X-15 | Open Code Review 图谱 | 案例 | — | X | 高级 advanced | GC-CASE | 对阿里开源 AI 代码审查 CLI 做源码级解析并构建「知识 + 实践资产 + AI 索引」三合一知识图谱的工程案例。 |
| CAS-X-16 | 控制理论⊗Agent 设计 | 案例 | — | X | 高级 advanced | GC-CASE | 将控制理论五维（负反馈 / 状态估计 / PID / 鲁棒 / 分层）系统映射到 Agent 工程环节，并以真实产品案例验证的跨学科方法论案例。 |
| CAS-X-17 | 技术知识中枢交付法 | 案例 | — | X | 高级 advanced | GC-CASE | 从模糊需求到上线，把 AI Agent 驱动的端到端交付固化为四阶段加双共识加迭代的可迁移方法论的实战提炼案例。 |
| CAS-X-18 | AI Agent 架构 DAG 复盘 | 案例 | — | X | 进阶 intermediate | GC-CASE | 对四个工作日内独立完成三个异构对象 DAG 分析的方法论复盘，总结「采集→建模→生成→门控→交付」可复用管线与关键教训。 |
| TEC-F-01 | 需求可追溯性与影响分析 | 技术 | technology | F | 进阶 intermediate | GL-TECHNOLOGY | 以需求库为中枢，把需求条目、属性与上下游制品（干系人需求、系统需求、设计、测试、代码）建立可查询的追踪关系，并以结构化查询支持变更影响分析的需求管理平台化落地。 |
| TEC-F-02 | 需求技术债识别与度量 | 技术 | technology | F | 高级 advanced | GL-TECHNOLOGY | 识别并度量需求技术债——理想规格与实际实现之间的差距——的技术做法，把需求层的债务纳入技术债管理（TDM）的识别与度量阶段，使需求质量缺口可被发现与跟踪。 |
| TEC-N-01 | 交付效能度量与仪表化 | 技术 | technology | N | 进阶 intermediate | GL-TECHNOLOGY | 把交付效能指标的采集、聚合与呈现平台化：从版本控制与流水线事件自动计算并持续反馈，并以治理机制约束指标被博弈（gaming）的风险，使度量服务于改进而非考核。 |
| TEC-N-02 | 团队拓扑落地与规模化 | 技术 | technology | N | 高级 advanced | GL-TECHNOLOGY | 在规模化组织中落地团队拓扑四类型与三交互模式，以认知负荷管理与快速流动为约束、显式定义团队交互方式的组织实践，用于把团队结构与被期望的架构对齐。 |
| TEC-G-01 | AWS 良好架构框架 | 技术 | technology | G | 进阶 intermediate | GL-TECHNOLOGY | AWS 发布的云架构最佳实践对照框架，以运营卓越、安全、可靠性、性能效率、成本优化、可持续性六大支柱组织设计原则与评审问题，用于一致地度量工作负载与最佳实践的偏差。 |
| TEC-G-02 | GCP 良好架构框架 | 技术 | technology | G | 进阶 intermediate | GL-TECHNOLOGY | Google Cloud 发布的云架构建议框架，以运营卓越、安全隐私与合规、可靠性、成本优化、性能优化、可持续性六大支柱及 AI/ML、金融等跨支柱视角，指导设计安全、高效、韧性、高性能且可持续的云拓扑。 |
| TEC-G-03 | Azure 架构中心 | 技术 | technology | G | 基础 basic | GL-TECHNOLOGY | Microsoft 维护的 Azure 架构中心，汇集云架构风格目录（N 层、微服务、事件驱动等，含适用性、收益与挑战）与安全部署实践，指导按业务驱动与非功能需求选择风格并安全发布变更。 |
| TEC-G-04 | ThoughtWorks 技术雷达 | 技术 | technology | G | 进阶 intermediate | GL-TECHNOLOGY | Thoughtworks 技术咨询委员会每年发布两次的技术快照，以技术/方法条目（blip）经四象限与四环（Adopt/Trial/Assess/Caution）组织，表达对技术采用程度的带观点推荐，并明确不追求全面、不接受厂商付费影响。 |
| TEC-H-01 | SonarQube 静态分析平台 | 工具 | technology | H | 进阶 intermediate | GL-TECHNOLOGY | SonarQube Server 是面向持续集成的静态代码分析平台，以规则引擎自动检测代码坏味道、缺陷与安全热点，并通过质量门控把分析度量转化为变更准入判断，同时区分整体代码与新代码以支撑增量治理。 |
| TEC-H-02 | SQALE 技术债评估方法 | 技术 | technology | H | 高级 advanced | GL-TECHNOLOGY | SQALE 是一套以生命周期期望为基准、力求客观可复现地评估源代码质量并量化技术债的方法，由若干基本原则与质量模型、分析模型、指数、指标等组件构成，供组织与厂商实现。 |
| TEC-H-03 | 技术债量化度量指标 | 技术 | technology | H | 高级 advanced | GL-TECHNOLOGY | 技术债量化度量把代码缺陷折算为可计算的债务规模与比率：以修复成本累加得到技术债额，用技术债比率（债务与开发成本之比）映射可维护性评级，并区分整体代码与新代码以支撑增量治理。 |
| TEC-H-04 | 依赖结构度量与渐进收紧治理 | 技术 | technology | H | 高级 advanced | GL-TECHNOLOGY | 依赖结构度量与渐进收紧治理把组件间的依赖关系折算为稳定性与抽象度等可计算指标，用归一化距主序列距离定位偏离健康线的组件，并以先告警、后报错的级联阈值在受控节奏内把结构拉回健康区间。 |
| TEC-I-01 | 持续集成服务与流水线 | 技术 | technology | I | 进阶 intermediate | GL-TECHNOLOGY | 持续集成服务与流水线是把「频繁合并回主线、每次合并自动构建并运行测试」制度化的技术载体：由单一代码主线、自动化构建与测试执行、结果回传与即时反馈构成，使集成错误在产生后最短窗口内暴露。 |
| TEC-I-02 | 关键字驱动测试框架 | 技术 | technology | I | 高级 advanced | GL-TECHNOLOGY | 关键字驱动测试（KDT）是 ISO/IEC/IEEE 29119-5 定义的一种自动化测试框架范式：把测试操作抽象为可复用的关键字，测试用例由「关键字＋参数」序列描述，驱动层负责解释执行，从而将测试意图与底层脚本实现分离。 |
| TEC-I-03 | xUnit 测试框架族 | 技术 | technology | I | 进阶 intermediate | GL-TECHNOLOGY | xUnit 测试框架族是按「测试类—测试方法—断言—夹具」结构组织并自动执行单元测试的一类框架，命名源自 JUnit 及其衍生家族；它把测试书写、发现、执行与报告统一为开发者可直接使用的代码骨架，是单元测试与测试驱动开发的主要工具载体。 |
| TEC-J-01 | Kubernetes 部署编排 | 工具 | technology | J | 进阶 intermediate | GL-TECHNOLOGY | Kubernetes 是容器编排平台，其 Deployment 控制器以声明式方式管理无状态工作负载的创建、扩缩与更新，默认采用滚动更新策略，并通过保留历史 ReplicaSet 支持版本回退。 |
| TEC-J-02 | 不可变基础设施实现 | 技术 | technology | J | 进阶 intermediate | GL-TECHNOLOGY | 不可变基础设施实现指部署后的实例不再被就地修改，任何变更都通过从受测基础镜像重建新实例并替换旧实例来完成，从而消除运行期配置漂移。 |
| TEC-J-03 | 蓝绿部署 | 技术 | technology | J | 进阶 intermediate | GL-TECHNOLOGY | 蓝绿部署维护两套尽可能相同、均可承担全量负载的生产环境，任一时刻仅一套承载流量；新版本在另一套环境验证通过后整体切换流量，异常时切回原环境实现快速回滚。 |
| TEC-J-04 | 金丝雀发布 | 技术 | technology | J | 高级 advanced | GL-TECHNOLOGY | 金丝雀发布先把新版本部署到不接用户或仅接少量用户的基础设施上，再按健康指标逐步放大流量与用户比例直至全量，从而把新版本故障的爆炸半径限制在受影响的小范围内。 |
| TEC-J-05 | 部署自动化 | 技术 | technology | J | 进阶 intermediate | GL-TECHNOLOGY | 部署自动化把从构建产物到各环境的部署过程脚本化、参数化并纳入版本控制，使任何持有凭据者都能把任意已构建制品一致地部署到任意环境，且过程尽量幂等、可重复。 |
| TEC-J-06 | 部署流水线工具化 | 技术 | technology | J | 基础 basic | GL-TECHNOLOGY | 部署流水线把从提交到生产的构建过程拆分为多个置信度递增的自动化阶段，前一阶段产出的制品供后续阶段逐级晋级，生产部署通常是流水线的最后一个阶段。 |
| TEC-K-01 | 断路器与重试退避 | 技术 | technology | K | 进阶 intermediate | GL-TECHNOLOGY | 断路器、超时与重试是一组协同的远程调用稳定性实现：超时限制等待，断路器在失败达阈值后快速失败以阻止级联，重试仅针对幂等操作的瞬时故障并以指数退避加抖动控制节奏。 |
| TEC-K-02 | 可观测性信号采集 | 技术 | technology | K | 进阶 intermediate | GL-TECHNOLOGY | 通过 traces、metrics、logs 等信号从系统外部推断内部状态，以回答未知未知与为何发生；工程界习称三支柱，其价值关键在于信号可关联而非数量多少。 |
| TEC-K-03 | 服务等级目标与错误预算 | 技术 | technology | K | 高级 advanced | GL-TECHNOLOGY | 用 SLI（好事件/总事件）度量服务水平，设定小于 100% 的 SLO 目标，并以错误预算等于 100% 减 SLO 驱动发布与加固决策；SLA 则是含后果的对外契约。 |
| TEC-K-04 | 混沌工程实践 | 技术 | technology | K | 高级 advanced | GL-TECHNOLOGY | 在生产中对系统做受控实验以建立对其抵御动荡条件能力的信心：定义稳态、提出假设、注入真实事件、比较对照组与实验组以证伪，并最小化爆炸半径。 |
| TEC-K-05 | 无指责复盘实践 | 技术 | technology | K | 进阶 intermediate | GL-TECHNOLOGY | 无指责复盘是一种事故发生后的书面复盘，其记录对象包括影响范围、处置与缓解过程、根因分析与后续行动项，而它的定义性特征在于聚焦方向：考察导致事件的那些系统性原因与当时的决策情境，而不是追查哪个个人或团队该被追究。它之所以被称为一种文化而不只是一份文档，是因为它同时规定了两件事——产出什么内容，以及以什么态度对待参与者。书中把它归入提升系统抵御人为失误能力的手段之列，与测试、回滚机制、渐进发布、监控与可观测性、界面设计并列，说明它的定位是组织层面的可靠性工程实践，而非单纯的行政流程。理解这一定义要抓住三组区分。 |
| TEC-K-06 | DORA 交付指标 | 技术 | technology | K | 基础 basic | GL-TECHNOLOGY | 用一组软件交付效能指标衡量组织的交付吞吐与稳定性；当前官方口径为五项指标，由早期四键扩展而来，并已用失败部署恢复时间取代平均修复时间。 |
| TEC-L-01 | 架构适应度函数工具化 | 技术 | technology | L | 高级 advanced | GL-TECHNOLOGY | 把架构约束与质量目标转写为可自动执行、可量化判定的校验，并借助测试、静态分析、监控与部署流水线门禁等机制持续运行，使架构意图不再依赖人的记忆与自觉。 |
| TEC-L-02 | 绞杀者渐进式替换 | 技术 | technology | L | 高级 advanced | GL-TECHNOLOGY | 在遗留系统之上或之旁增量构建新实现，通过可切换的接缝与路由逐步把功能与数据迁移过去，逐步替代旧系统，而非一次性整机重写。 |
| TEC-M-01 | 质量模型工具化 | 技术 | technology | M | 进阶 intermediate | GL-TECHNOLOGY | 把 SQuaRE 系列标准的质量特性与子特性框架落为可操作的检查表、需求模板与评价工具，使质量关切在需求、设计与评价之间以同一坐标被规定、测量与比较。 |
| TEC-M-02 | 可维护性量化 | 技术 | technology | M | 高级 advanced | GL-TECHNOLOGY | 把可维护性与技术债转写为可计算指标：以修复违规的成本估计债务本金、按对可维护性的影响折算利息，沿质量子特性组织规则与评分，使变更成本可比较、可追踪。 |
| TEC-M-03 | 可修改性战术实现 | 技术 | technology | M | 进阶 intermediate | GL-TECHNOLOGY | 可修改性战术的实现，指把推迟绑定时间、局部化变更与防止涟漪效应这三类设计决策落到具体结构机制上，包括接口与间接层、易变决策的封装位置、依赖方向约束与依赖反转，目标是缩小每一次修改的影响半径。第八章节把这些手段归入三个抽屉。一是提升内聚，做法是拆分职责过杂的模块、把散落各处的同类职责重新归拢。二是降低耦合，做法是加壳封装、插入居间者、把公共能力抽成共享服务、约束模块可见与可依赖的范围。三是推迟绑定，做法涵盖构件替换、编译期参数化、切面、配置期赋值、资源文件、运行期发现、参数解释、共享仓库与多态分派。 |
| ESS-G-04 | 模块化与分解 | 方法原则 | essence | G | 基础 basic | GL-ESSENCE | 模块化与分解指的是把整体切成若干能够各自独立运转的较小单元，使每个单元的扩容、部署与故障处置不再被其余部分牵连。它被视为可伸缩性最通用的一条做法，因为服务化、数据分片、流式处理以及节点各自持有本地资源的形态，底层走的都是同一条思路。定义的重心并不落在切这个动作上：真正的判定标准是切完之后各单元能否在负载增长时被单独放大。哪些职责应当留在一起、哪些应当分开，并没有通用答案，因此分解的边界是相对的，取决于当前负载形态与团队条件，而不是可以照抄的结构模板。切得过细同样会反噬。 判断边界是否合理，有一个可操作的观察点：某单元能否在不牵动邻单元的前提下完成一次容量调整或一次故障切换。 |
| ESS-G-05 | 架构风格 | 方法原则 | essence | G | 进阶 intermediate | GL-ESSENCE | 定义一类系统结构组织方式的模式：规定该系统实例中可用的组件与连接件词汇表，以及它们的组合约束，从而约束设计空间并带来一组可预期的属性。 |
| ESS-G-06 | 视图与视角 | 方法原则 | essence | G | 进阶 intermediate | GL-ESSENCE | 按不同干系人的关注点，从特定角度表达系统架构的概念结构；视角是一类视图的构造与解释约定，视图则是按某个视角约定所作的具体表达。 |
| ESS-H-05 | 深模块与浅模块 | 方法原则 | essence | H | 进阶 intermediate | GL-ESSENCE | 以“接口复杂度与所提供功能之比”评价模块的两种形态：深模块提供强大功能却只有简单接口，浅模块接口相对复杂却功能不足，未能隐藏显著复杂度。 |
| ESS-H-06 | 组合优于继承与脆弱基类 | 方法原则 | essence | H | 进阶 intermediate | GL-ESSENCE | 在复用与扩展中优先采用对象组合而非类继承：继承以暴露父类实现为代价换取复用，组合只依赖被复用对象的接口，从而维持封装边界与替换能力。 |
| ESS-H-07 | 可读性与认知负荷 | 方法原则 | essence | H | 基础 basic | GL-ESSENCE | 把代码可读性视为一种工程要求：代码被阅读的次数远多于被编写，理解与修改代码的成本由读者所需的认知负荷决定，而非由风格偏好决定。 |
| MTH-G-01 | 架构决策记录 | 方法 | methodology | G | 基础 basic | GL-METHOD | 把每个架构上重要的决策记录为短文本文件（含上下文、决策、状态与后果），使决策依据、取舍与被否决的备选可被追溯、复核与取代，而非散落在会议记录与个人记忆中。 |
| MTH-G-02 | 质量属性场景与ATAM | 方法 | methodology | G | 进阶 intermediate | GL-METHOD | 质量属性场景是把「快」「稳」「可改」这类说法转成可验收需求的固定格式，共六个位置：谁发出刺激、刺激是什么、处于什么环境、作用于哪个制品、系统应给出什么响应、响应用什么度量判定。它的价值在于绕开两个常见麻烦——属性定义本身不可测，以及同一现象被不同属性社群各自认领。两个补充限定：六个位置在早期常被省略，但知道它们存在会迫使设计者逐项确认是否真的不相关；响应度量是整条场景能否被验收的关键，缺了它场景就退化为愿望。因此场景既不是模板填空的产物，也不是需求的替代物，而是把质量诉求推到可判定状态的载体。 |
| MTH-G-03 | 架构风格选择方法 | 方法 | methodology | G | 高级 advanced | GL-METHOD | 架构风格可理解为对一类系统组织方式的命名与约定：风格固定了可用构件的种类、连接方式的种类，以及二者允许如何拼装。选型方法则以质量属性场景为判据，把候选风格的构件—连接件约束逐项映射为属性收益与代价，在具体子域上择优，而非寻找普适最优。其要点有三：其一，风格的本质是约束集合，符合约束才带来特定属性，而约束一旦采纳，包里每项战术的收益与副作用同时生效，且通常不只作用于一项质量属性；其二，同一风格在不同子域、不同负载形态与不同规模下，收益与代价可能整体反转，故不存在放之四海皆准的答案，只能就事论事地评估；其三，落锤前必须把代价显性化，说清放松哪条约束换取哪项属性。 |
| MTH-G-04 | 领域驱动战略设计 | 方法 | methodology | G | 高级 advanced | GL-METHOD | 以限界上下文显式划定模型适用边界、以通用语言在单个上下文内统一团队与代码的表达，并通过上下文映射管理跨上下文关系的领域建模战略方法。 |
| MTH-H-01 | 重构手法族 | 方法 | methodology | H | 进阶 intermediate | GL-METHOD | 在不改变可观察行为的前提下，按命名的小步手法持续改善代码内部结构的方法族；以代码坏味道为信号、以测试为安全网，把结构调整为可验证的小步而非大重写。 |
| MTH-H-02 | 信息隐藏模块化分解 | 方法 | methodology | H | 进阶 intermediate | GL-METHOD | 以「隐藏困难或可能变化的设计决策（secret）」为判据，把同一 secret 相关行为归入一个模块、仅经最小接口交互的分解方法，使变更局部化。 |