质量属性场景与ATAM
§1摘要与结论
质量属性场景是把「快」「稳」「可改」这类说法转成可验收需求的固定格式，共六个位置：谁发出刺激、刺激是什么、处于什么环境、作用于哪个制品、系统应给出什么响应、响应用什么度量判定。它的价值在于绕开两个常见麻烦——属性定义本身不可测，以及同一现象被不同属性社群各自认领。两个补充限定：六个位置在早期常被省略，但知道它们存在会迫使设计者逐项确认是否真的不相关；响应度量是整条场景能否被验收的关键，缺了它场景就退化为愿望。因此场景既不是模板填空的产物，也不是需求的替代物，而是把质量诉求推到可判定状态的载体。
别名：ATAM、架构权衡分析方法、QA scenario | 英文：Quality Attribute Scenarios and ATAM | 类型：方法 / process
§2局部关系图
§3原理 · 为什么
评估的输入是可比较的场景，而不是与会者的印象。方法要求以经优先化的质量属性场景为基础，再据此识别风险与非风险，把原本停留在个人脑子里的假设变成可讨论、可记录的对象。为降低单一来源的偏差，它还做了两处对照：效用树反映架构师认定的关键需求，干系人头脑风暴则反映更大人群对成功的理解，两者结果相互比对；若差异很大，这个差异本身就是风险信号，说明对目标的认知尚未对齐。其深层前提是把架构视为质量属性的首要载体，并承认质量属性彼此牵制，所以不追求所有属性同时最优，而是用结构化方法识别敏感点与权衡点，让取舍显式可见，而不是留给偶然或留给职位最高的人。还有一条不易遵守的前提：评估的独立性依赖于参与者能安全表达担忧，若结论早已内定，风险清单就会退化为对既有决定的背书，此时应改用更小的范围或换一批参与者。同时要明确评估只负责识别问题，不替代架构师做决定，因为权衡涉及成本、进度与组织约束，超出评估本身的权限。评估者也不应假定属性可以各自独立达标，恰恰相反，多数架构决策会同时牵动数项属性，这也是必须记录敏感点与权衡点的原因。与之配套的评估以经优先化的场景为输入，识别风险与非风险，并进一步把决策与质量响应之间的敏感点、权衡点标出来，让取舍从隐性判断变成可讨论的记录。补充两点：其一，场景应覆盖正常、降级与过载三类情形，只写正常路径会漏掉最关键的取舍，因为多数质量冲突只在资源紧张时才显形；其二，场景要能追溯到业务目标，否则它只是技术人员的偏好，无法用于判定优先级。度量的口径也需写明统计窗口与负载条件，否则同一个系统在不同条件下得到的数字无法比较，验收也就无从谈起。最后，场景清单应当是可增长的活文档，随系统演进与新风险出现而增补，而不是一次成型的定稿。
§4机制 · 如何运作
在组织上，这套评估分四个阶段：阶段0做合作与准备，阶段1、2合称评估并承载九步分析，阶段3做跟进并交付报告；九步中前六步由评估团队与项目决策者完成，后三步在扩大干系人参与后展开。步骤之间不是严格瀑布：真实案例中评估进行到一半才发现被评的架构已被替换，于是回退到第3步重新呈现架构，而此前已确认的业务目标、效用树与场景全部沿用。这条回退案例适合用来说明方法的重心在于分析质量，而不在于走完流程。效用树是自顶向下的细化结构：根节点写作整体合意程度，其下先列出主要质量属性作为中间占位，再按该系统真正关心的方向做属性细化，叶子放具体的质量属性场景，每个叶子按业务价值与技术风险两项判据打高、中、低。这样做的用意是让分析精力落在少量真正关键的场景上，同时暴露空白：某个分支下没有任何场景，通常意味着需要追问是否遗漏了需求。打分环节还有两处细节：业务价值与技术风险必须分别给出，不能因为某项场景业务价值高就默认它技术风险低，两者恰恰经常错位；当某项场景同时是高价值与高风险时，它通常就是最值得投入分析精力的位置。风险主题的归纳是另一个关键动作——把若干零散风险按共同成因分组后，修复少数根因即可同时消解多条风险，而逐条处理容易在相似问题上反复消耗。此外，敏感点需要逐条把架构决策与质量属性的响应关联起来，这个映射本身就是发现问题的过程，因为不少决策在设计时并未意识到它会牵动哪些属性。
§5工程 · 怎么落地
让评估结论真正起作用，靠的是回流动作：把分析得到的判断写回架构文档、更新受影响的视图，并把重要决策连同理由留痕，使下一轮设计或复核能接续使用。这一步属于常规活动而非额外负担；文档的目的应明确为分析、构建或培训之一，按风险取舍写多少。评估的产出可以按清单记：架构的简明呈现、被明确表述的业务目标、经优先化的质量属性场景、风险与非风险清单、按共同成因归纳的风险主题、架构决策与质量需求之间的对应关系，以及敏感点与权衡点集合。此外还有难以量化但同样重要的收获，例如干系人之间的共识感与更通畅的沟通，以及全体参与者对架构强项与弱项更完整的理解。要提醒的是这些产出是分析结论，并不自动带来修复，修复本身仍需按成本收益另行决策。落地时还有两点经验：产出应指定归属与责任人，否则风险清单最终会变成无人处理的文档；对敏感点与权衡点，评估通常给出可能的缓解方向，但不强制具体方案，把选择权留给架构师并注明理由。此外，评估不必等到全部场景齐备才开始，可以按主题分批推进，先覆盖与当前决策最相关的部分；反过来，若业务驱动尚未澄清就急于评估，得到的只会是一堆与技术无关的场景。最后，凡涉及安全、成本或合规的权衡，都需要相应领域的专业判断参与，而不能仅由架构团队闭门决定。
§6权衡卡
可行的折中是固定一个轻量节奏、按变化范围决定本次要不要扩大参与，并把结论与后续决策显式挂钩，使评估的价值可被回溯检验。
评估的代价由干系人的时间与领域知识偿付，质量取决于参与者，浅评可能遗漏深层权衡点，把非风险误判为安全——其依赖的隐含假设一变化即转为风险。
把架构评估当成项目末尾一次性的把关，是常见误读：该书明确评估可以在开发过程的不同阶段开展，参与者和执行方式都可以不同；评估的定位是一份保险，买多少取决于暴露程度与风险容忍度，而不是流程上的固定关卡。
边界在于反复评估不是免费的：评估成本必须小于它带来的价值，所以频次应由风险与不可逆程度决定。
进一步说，评估深度的选择本身也是权衡：覆盖越广、参与者越多，结论越可信，但协调成本与信息泄露面也随之上升；只邀核心成员则快而省，却容易漏掉运维、安全或合规视角的风险，这些视角的关切往往只在出事后才被想起。
另一个反例是在业务驱动尚未澄清时强行评估，得到的只是一堆与技术无关的场景。
另一个反例是把评估当成评分或排名，一旦参与者觉得会被追责，就会倾向于隐藏问题，风险清单随即失去价值。
- 可用的替代做法是项目内部的轻量评估，由同行定期进行，可只针对上次评审以来的变化，因而几小时到一天即可完成。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7学习路径条
§8案例带
去中心化聊天架构逆向
对一个仅有 58 份设计文档、尚未实现的开源去中心化聊天项目做架构逆向：从设计文本提炼 18 个模块及其依赖关系，重建模块依赖 DAG 与三条核心数据流 DAG，并输出全景理解与深度需求分析。
网申填写扩展逆向架构
对 Chrome MV3 网申自动填写扩展的逆向架构分析：梳理 popup、content、background、options 四模块职责，解剖 12 个站点适配器、双通道消息协议与隐私脱敏机制，并评估其零依赖零构建选型。
preset 通道耦合分析
对 harness「委派工具层→续用管理器→preset 服务→MCP 服务器」这条通道做耦合分析：识别契约、服务定位、数据契约、组合语义、路径与装配一致性六类耦合点，定位「静默丢弃特化」与「装配漂移」两处实质缝隙。
dsh-manager 插件深度分析
以「编译依赖、运行时注入、组合装配」三硬依据加源码行号，对第三方插件做依赖、功能、需求溯源与设计问题裁决，并复用上游 DAG 知识库节点标识，使分析结果可与主图互查。
harness 源码架构解析
对 deepseek-harness 官方源码做分层解析：镜像官方架构文档，按九个层与九十余模块建立文档集群，产出跨层联动矩阵与七条关键路径，并钉住「模型可见即已记录」、能力缝三角等设计不变量。
dsh 插件依赖增量定位
以官方插件 DAG 为蓝本，对一个官方清单之外的全新社区插件做功能定位与依赖位置增量分析，产出可下钻交互依赖图与多形态文档的源码级架构逆向案例。
Hermes 七层架构总览
对八千余文件的工业级 AI Agent 项目做七层架构总览逆向，揭示其「越用越聪明」的自进化闭环如何在层间传导的控制型架构案例。
MCP 四件套选型对比
对四个同类 MCP 服务器做源码级能力与成本对比，并以常驻 token 预算为轴给出分级接入策略的技术选型实战案例。
Claude Code 架构逆向
以社区逆向源码、系统提示词与官方文档三源交叉验证，还原一个商业 Agent 的查询引擎、子Agent、工具与权限体系的逆向分析案例。
Open Code Review 图谱
对阿里开源 AI 代码审查 CLI 做源码级解析并构建「知识 + 实践资产 + AI 索引」三合一知识图谱的工程案例。
控制理论⊗Agent 设计
将控制理论五维（负反馈 / 状态估计 / PID / 鲁棒 / 分层）系统映射到 Agent 工程环节，并以真实产品案例验证的跨学科方法论案例。
§9信源与核验
核验结论：ATAM 九步分为陈述/调查分析/测试/报告四组，但步骤非严格顺序、可迭代；架构评估应在里程碑处反复进行 [OFF-002]
核验结论：sensitivity point 针对单一质量属性；tradeoff point 同时是多个质量属性的敏感点、影响多个属性，二者须严格区分 [OFF-002]
§10原始关系清单
展开：本节点的全部原始关系边（7 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 依据推导 | → ESS-O-02 | 架构即权衡 E-202 | ATAM 以架构权衡为根本前提 |
| 促成 | ← MTH-G-05 | 架构文档化方法 E-727 | 架构文档是架构评估流程的输入 |
| 实现 | ← TEC-G-01 | AWS 良好架构框架 E-881 | AWS 支柱评审落地质量属性场景分析 |
| 实现 | ← TEC-G-02 | GCP 良好架构框架 E-882 | GCP 支柱原则承载质量属性场景分析 |
| 前置依赖 | → MTH-G-01 | 架构决策记录 E-208 | 识别敏感点与权衡点是记录架构决策的前提 |
| 前置依赖 | → MTH-G-03 | 架构风格选择方法 E-209 | 质量属性场景与评估是风格权衡选型的前置分析 |
| 细化 | ← MTH-G-06 | 效用树与敏感点权衡点分析 E-725 | 效用树构造与敏感点识别细化 ATAM 评估流程的分析环节 |