跳到主要内容

多视角评审框架与评审角色库

本文范围：业界成熟的"多视角 / 多角色评审"框架综述——每个评审视角专门发现哪类别的视角发现不了的问题（正交性），以及适配开发生命周期的哪个阶段。目的是为跨生命周期（需求讨论 → 设计 spec → 实现 plan → code review）可复用的"评审角色库"提供选型依据。 不包含：具体评审流程的项目落地实现（→ docs/specs/）、单个测试范式的展开（→ 02-测试与验证方法论）。

评审的价值不在"多评几遍"，而在视角正交——同一份产物被两个共享假设的人各看一遍，发现的是同一类问题；被两个视角正交的角色各看一遍，才覆盖到不同的失败模式。本文把业界 9 类成熟框架拆成可复用的评审角色，对每个角色提取三件事：独占问题类别、适配阶段、来源。

名词定义​

本文专属新名词（01-总览 已定义的不重复）。

名词定义
评审视角（review perspective）一组共享的关注点与假设，决定评审者会问什么问题、忽略什么问题
独占问题类别（orthogonal problem class）某视角能发现、而其他视角因关注点不同而发现不了的一类问题
正交性（orthogonality）两个视角覆盖的问题集合几乎不重叠的性质；正交是评审角色库价值的来源
生命周期阶段本文采用四段划分：需求讨论 / 设计 spec / 实现 plan / code review
STRIDEMicrosoft 威胁建模框架，按 6 类被违反的安全属性拆分威胁视角
PRR（Production Readiness Review）Google SRE 的生产就绪评审，上线前检查可观测性 / 告警 / 回滚 / 容量 / on-call
FMEA（Failure Mode and Effects Analysis）失效模式与影响分析，按 RPN = 严重度 × 发生率 × 可检测性量化排序失效模式
PR/FAQAmazon working-backwards 的产物：先写面向用户的新闻稿 + 内部 FAQ，再决定是否开发
INVEST用户故事质量的 6 条判据：Independent / Negotiable / Valuable / Estimable / Small / Testable
abuse case / misuse case用例的反面：描述 mis-actor（含已认证用户）如何滥用合法功能

设计文档评审：从局部正确到组织一致​

设计文档评审（Google design doc / IETF RFC / 架构评审委员会 ARB）的共同特点是在写代码前评审，且按"评审半径"分层：从单文档的局部正确，到跨团队的架构一致，再到整个组合的治理。

Google design doc 评审：四种正交评审者​

Google 的 design doc 是写代码前的非正式文档，记录高层实现策略和关键设计决策（侧重已考虑的取舍）。其评审模板用横切章节强制作者在评审前就回答安全、隐私、可扩展、可观测等问题（Malte Ubl, 2020）。评审拆出四种正交角色：

  • 同行 / 团队评审者（通才）：独占问题类别是局部设计自洽与方案最简性——这是不是解决问题的最简方案？取舍分析是否充分？专项评审者（安全 / 隐私）按定义不问这个。适配设计 spec 阶段。
  • 隐私评审者（专职隐私团队）：独占问题类别是数据最小化、同意、留存与删除路径、跨境数据流。Google 将隐私设计文档列为单独的强制产物——功能正确性评审者结构上看不到这类问题。适配设计 spec（最佳实践是需求讨论阶段就介入）。
  • 资深 / TL 评审者（正式评审会）：独占问题类别是跨团队的组织与架构一致性——局部最优但与更大架构方向冲突的决策、与既有系统重叠的初创、扩到下一个数量级会失效的选择。适配设计 spec。
  • 安全评审者（Chrome 模式）：独占问题类别是攻击面与威胁模型完备性——系统化追问"对手能用这个设计做什么"，区别于通才评审的"设计是否正确"。适配设计 spec 与实现 plan；放到 code review 才做代价高，架构级安全漏洞无法靠改代码补救（Google Security Blog, 2023）。

IETF RFC 评审：领域共识 + 专家董事会 + 跨域协调​

IETF 通过工作组（WG）共识、Last Call、IESG 评审和并行的董事会（directorate）专家评审产出标准。三类角色问的问题互不重叠：

  • 工作组共识 / WG 主席：独占问题类别是领域协议正确性与章程契合——协议是否在其领域（路由 / 传输 / 安全）内正确解决了既定问题。WG 成员对该问题域有深度上下文，靠 rough consensus 运作。
  • 安全董事会（SECDIR）评审者：独占问题类别是威胁模型完备性与 Security Considerations 充分性。每份 I-D 在 Last Call 自动分配 SECDIR 评审，专门追问：假设的威胁环境是否匹配 RFC 3552 的 Internet 威胁模型？安全考量是否枚举了哪些威胁被处理、哪些遗留？密码学原语用法是否正确？2019 年 DLEP pause 扩展的一份真实 SECDIR 评审标出了三点 WG 评审者未抓到的问题：主要动机与范围聚焦不清（仅限排队场景）、术语不精确（"威胁"与"漏洞"混用）、措辞与安全考量章节的表达质量（评审结论为 "Has nits"，属轻量修订）。
  • 领域主管（Area Director）：独占问题类别是跨工作组的架构一致性——发现两个 WG 为同一问题定义了不兼容机制、战略错位或重复。AD 维持的是整个领域组合的广度，区别于 WG / 董事会评审者在单文档里的深度。

公司内部 RFC 流程补充两类角色。Squarespace 的具名 Approver 做的是 go/no-go 门控——不是技术正确性，而是"这个问题现在值不值得解、有没有更简单的办法"，用 "Yes, if"（条件批准）机制让作者带着记录在案的条件继续推进。Uber 的全员广播评审捕捉团队级隧道视野看不到的未声明假设：一个美国团队做的功能被印度团队指出漏了本地化 / 法务 / GDPR 合规（Pragmatic Engineer）。

架构评审委员会（ARB）：组合级治理​

ARB 是 TOGAF 定义的跨组织治理体，评审半径覆盖整个项目组合——这是它区别于 design doc（项目级）和 RFC（标准级）的关键。ARB 的常设关注点：标准合规、战略对齐、风险管理、重复投资防范、build-vs-buy 治理，以及对"代价高 / 不可逆决策"（技术栈、数据架构、集成契约）的显式门控。四类成员角色：

  • 首席 / 企业架构师：独占问题类别是组合级错位与技术蔓延——局部合理但在企业范围造成问题的决策（不兼容的技术选型、软件蔓延、重复投资）。项目级评审一次只看一个项目，看不到这些组合效应。
  • 领域 / 技术架构师：独占问题类别是集成失败与跨系统耦合——未记录的依赖、耦合到即将下线的系统、集成反模式。
  • 业务干系人：独占问题类别是业务能力缺口与战略错位——技术上正确但交付不了所需业务能力的架构。问的是"这个架构是否使能正确的业务结果"。
  • 合规 / 安全官：独占问题类别是组合级监管与横切 NFR 合规——区别于项目级安全评审（只看单个设计的威胁模型）。捕捉由各自单独通过评审的组件交互导致的合规失败（数据驻留、PCI-DSS、HIPAA）。

对抗式评审：站在攻击者视角​

对抗式评审让一部分人主动扮演攻击者，发现"防御方按自己的假设永远想不到"的失败路径。

红队 / 蓝队 / 紫队​

  • 红队：扮演有动机的攻击者，执行完整 kill-chain（侦察 → 初始访问 → 横向移动 → 提权 → 持久化）。独占问题类别是攻击链组合失败——多个单独看低危的弱点串成端到端的完整入侵路径。常规 code review 与静态分析逐组件审计，红队找的是组合：暴露的 API（低危）+ 配错的 IAM 角色（中危）+ 弱审计日志（低危）合成系统级失陷。CISA 的 SILENTSHIELD 评估（2023–2024）是公开案例。主要落点在上线后与发布前 code review。
  • 蓝队：运营 SOC，监控遥测、写检测规则、做事件响应。独占问题类别是检测覆盖缺口——现有监控规则与工具是否真的对真实攻击行为告警。一个系统可以零已知 CVE，却对提权或横向移动零告警。落点在实现 plan（埋点要求）与上线后。
  • 紫队：红蓝集成反馈回路。独占问题类别是安全反馈回路失败——红队发现存在于报告里但蓝队从未实现，或蓝队修了检测但红队从未复测确认闭环。红蓝单独都暴露不了"改进过程本身断裂"。

STRIDE：六类威胁视角，各违反一条安全属性​

STRIDE（Kohnfelder & Garg, 1999）把威胁空间拆成 6 个互斥类别，每类对应一条被违反的安全属性。在设计阶段画数据流图（DFD），对每条数据流和信任边界逐一追问哪类威胁适用。六个视角彼此正交（Microsoft Azure Security 文档）：

视角违反属性独占问题类别主要适配阶段
Spoofing（伪造）认证信任边界处的身份混淆——含开发者默认可信的服务间调用设计 spec
Tampering（篡改）完整性数据全生命周期的完整性——含被当作"可信内部"忽略的内部管道设计 spec、code review
Repudiation（抵赖）不可否认审计完备性与防篡改——唯一追问"系统留了什么证据、证据本身能否被篡改"的视角需求讨论、设计 spec
Information Disclosure（信息泄露）机密性全通道机密性——错误消息 / 日志 / 备份 / 服务间 header，不止请求-响应路径设计 spec、code review
Denial of Service（拒绝服务）可用性对抗性负载下的可用性——攻击者蓄意耗尽 CPU / 内存 / 连接，正确性评审看不到设计 spec、实现 plan
Elevation of Privilege（提权）授权全层授权边界完备性——授权检查存在但放错层（只在 UI 不在 API）设计 spec、code review

攻击树与 abuse case​

  • 攻击树（Schneier, 1999）：根节点 = 攻击者目标，叶节点 = 具体攻击方法，AND/OR 关系可标注成本 / 可行性 / 可检测性并向上传播打分。独占问题类别是目标导向的多路径枚举——STRIDE 枚举的是施加到各组件的威胁类别，攻击树枚举的是达成某个目标的所有可行路径。它发现：补掉"显而易见"那条路后仍可行的替代路径；以及加固哪个 AND 子节点能抬高整条分支的成本。适配需求讨论（定义根节点 = 攻击者目标）与设计 spec。
  • abuse case / misuse case（Sindre & Opdahl 2000；McDermott & Fox 1999；OWASP）：用例的反面，描述 mis-actor 如何用系统功能造成危害。mis-actor 不只是外部人——可以是已认证用户、合法 API 消费者或内部员工。独占问题类别是授权主体对合法功能的蓄意滥用——已有访问权的主体提交构造输入绕过业务逻辑（不是认证）、合法消费者滥用无限流端点批量抓数据。这对 STRIDE（聚焦技术控制）、攻击树（建模外部入侵）、红队（聚焦周界突破与横向移动）都是盲区。主要适配需求讨论：每个 abuse case 变成一条与功能需求同notation 的安全需求。

产品 / 用户视角：从"用户要什么"倒推​

产品视角问的是工程视角默认跳过的问题："该不该做"和"是否用用户结果说清了要做什么"。

  • Amazon Working Backwards / PR-FAQ：先写一页面向用户的（未来日期）新闻稿 + 内部 FAQ，再决定是否开发。独占问题类别是**"用对的方式做错的东西"——这是不是值得解的问题？用户会切换吗？价值主张能否用用户语言（非工程语言）讲清？写新闻稿是一个 forcing function：用代码把一个能力包装成产品，比用高管可见的朴实散文包装容易得多。规避的标志性失败是 Amazon Fire Phone（工程惊艳、零用户价值）。这是软件生命周期里唯一**问"该不该做"的评审，落点在需求讨论（设计之前）。
  • 用户故事 / INVEST：在 backlog 精化时对每个故事过 6 条判据，每条捕捉一类需求质量缺陷——缺可测性（无验收标准 → "完成"无定义）、隐藏依赖（Independent 失败 → 被迫人为排期）、伪装成故事的纯技术子任务（Valuable 失败）。落点在需求讨论，是 PR/FAQ 意图与可实现工作之间的桥。

SRE / 运维视角：能不能在生产被运维​

运维视角捕捉"staging 能跑、生产运维失败"这一类——架构评审和 code review 结构上都验证不了。

  • Google SRE 生产就绪评审（PRR）：上线前检查服务能否被观测（SLI 已埋点、SLO 已文档化）、能否正确告警（症状型而非指标型告警；Google 的硬门是 ≤2 个可操作告警 / 12 小时 on-call 班次）、能否恢复（回滚流程已测试，"先回滚后诊断"为强制原则）、有没有人值守（on-call owner + 已验证 runbook）、能否扛负载、依赖能否故障转移。Google CRE 的"landmine"分类还包括：未关闭的 postmortem 行动项、单点故障、告警风暴、人工 toil、SLO 与告警错位。落点在实现 plan → 上线前（高风险服务建议设计阶段早介入）。
  • FMEA / AWS Well-Architected 运维评审：FMEA 给每个失效模式打 RPN = 严重度 × 发生率 × 可检测性，强制排序（不是所有失效等价）。AWS 把它分成应用层 / 软件栈 / 基础设施 / 运维可观测四类 FMEA。独占问题类别是失效模式的系统化量化枚举——设计评审在概念上识别了风险，FMEA 把爆炸半径和级联失败定量列出来，成为 PRR 检查项的验证输入。落点在设计 spec → 实现 plan。

数据 / 领域正确性视角：不变量、契约、量纲​

领域正确性评审验证软件忠实地强制了问题域的不变量、契约和语义约束——区别于"能编译""API 返回 200"。独占问题类别是没有领域知识的通才检测不到的违例：

  • 类不变量违反：每次操作前后都必须成立的业务规则。如银行 aggregate 里 account.balance >= 0 必须在每次 debit() 后仍成立，含并发状态转移。通才看到 debit 逻辑，领域评审者检查不变量在所有状态转移下成立。
  • 前置 / 后置条件违反：按 Bertrand Meyer 的 Design by Contract（1986），每个方法携带调用方须满足的前置条件、供给方保证的后置条件、约束一致状态的类不变量。正确性评审检查整条契约链而非孤立函数。
  • 量纲 / 单位不匹配：标志案例是 NASA 火星气候轨道器（1999，损失 $327M）——Lockheed Martin 的软件输出磅力·秒，NASA 的软件消费牛顿·秒，两份代码各自孤立"工作"。只有检查软件接口规格中接口边界物理单位的领域评审者能抓到。
  • aggregate 边界违反：DDD（Eric Evans, 2003）中不变量跨整个 aggregate，根负责对整簇强制一致性。领域评审者检查没有操作绕过根直接改 aggregate 内部状态。

落点：需求讨论捕捉不变量（DDD ubiquitous language）；设计 spec 编码为契约；code review 验证 aggregate 根访问控制与边界单位标注。

测试 / 质量视角：边界、等价类、回归​

测试视角把系统化的测试设计思维当作评审镜用——在写一行测试前就评估实现是否可充分验证、已知易错模式（边界 / 等价类 / 状态转移）是否被考虑。独占问题类别是设计评审看不到的几类：

  • 边界 off-by-one：Myers（The Art of Software Testing, 1979）确立"探索边界条件的测试用例回报高于不探索的"。通才写 if age >= 18，测试评审者立刻问"恰好 18 怎样、17 怎样"——off-by-one 在设计评审里不可见。
  • 缺失等价类：等价划分把输入域分成行为应相同的类。设计者想"有效 / 无效"，测试评审者枚举 < min、= min、min+1、= max、> max、空、null、unicode、注入串——揭示 spec 里多数类未被处理。
  • 不可测设计：有隐藏副作用、全局状态或无依赖注入的函数无法孤立测试。测试视角在设计期抓到，重构成本最低。
  • 回归盲点：测试评审者问"这段代码改动后，哪些既有行为可能坏"，检查回归覆盖是否存在；设计评审者只看孤立的新功能。

Myers 的关键洞见：边界值分析"更多是一种心态"——作为设计与 code review 的镜，它不跑一行测试就能发现缺陷。落点贯穿设计 spec（可测性要求）、实现 plan（边界枚举进验收标准）、code review（条件边界 + 回归覆盖）。测试范式本身的展开见 02-测试与验证方法论。

可维护性 / 可读性视角：未来维护者​

可维护性评审者扮演没写过这段代码的未来工程师，问"半年后无原作者上下文，我能不能理解、安全修改、扩展它"。独占问题类别：

  • 认知复杂度过载：Ousterhout（A Philosophy of Software Design, 2018）定义复杂度为"任何使系统难以理解或修改的东西"，主要表现是认知负荷——读懂一个函数 / 模块要在工作记忆里装多少东西。设计评审者评估功能完整性，可维护性评审者评估认知负荷。
  • 注释腐烂与缺失的 why：Google eng-practices 规定注释应解释 why 而非 what。描述 what 的注释随代码演化变陈旧误导。
  • 隐性技术债：Fowler 的技术债象限（2009）按 鲁莽/审慎 × 蓄意/无意 分类，最危险的是鲁莽-无意——不了解设计原则的开发者制造的债。可维护性评审者标出"现在能跑，半年后无法维护"。
  • 误导性命名 / 过度工程：Google eng-practices 明确警告"为假设的未来需求构建通用方案"——解决尚不存在问题的代码给未来维护者制造不必要复杂度。

Google 把这制度化为按语言的独立 readability 认证（独立于功能 LGTM），等于正式承认可维护性评审是区别于功能正确性评审的独立技能。落点主要在 code review，少量在设计 spec（高复杂度分解）与实现 plan（审慎-蓄意债的记录）。

经典思维框架：系统化换视角​

前面的角色是"按领域分工"，经典思维框架是"按思维模式分工"——它们本身不绑定某个领域，而是提供系统化切换视角的脚手架。

de Bono 六顶思考帽​

六顶帽（de Bono, 1985）是平行思考框架：所有参与者同时戴同一顶帽、朝同一方向想，避免无结构争论。每顶帽是一个正交视角：

帽关注独占问题类别
白帽事实缺失数据、未验证假设、未采集的指标
红帽直觉真实但难以逻辑表述的担忧、隐藏的抵触
黑帽审慎逻辑缺陷、风险、设计失效的边界情形
黄帽乐观被低估的收益、设计运作良好但被忽视的情形
绿帽创意未被考虑的更优替代方案、未探索的设计空间
蓝帽流程流程缺口、缺失的评审环节、决策归属不清

关键机制：让所有人同时戴同一顶帽，把自我与地位从对话中移除——黑帽让批评合法化而无人身冲突，红帽让直觉担忧合法化而无需逻辑背书（Ministry of Testing, 2023）。技术评审常用 白+黑+黄 子集，检视 / 代码评审用全六顶并由蓝帽主持。

魔鬼代言人 / 辩证探询​

  • 魔鬼代言人（DA）：指派一人 / 一组论证反对当前推荐，生成批评文档，群体再防御或修改提案。
  • 辩证探询（DI）：更结构化的变体——群体生成带完整假设的反提案（antithesis），再辩论 thesis vs antithesis。

Schwenk 的元分析（1984）比较 DA、DI 与专家共识：两者都产出比未受挑战的专家共识更高的决策质量；DA 通常更实用（只需一名指定异见者，不需整个反提案团队）。独占问题类别是群体思维产物——看似可靠只因群内无人挑战、而非真的可靠。共享上下文与假设的通才评审会强化既有偏见，DA/DI 引入对抗压力，逼出隐藏假设、被忽视的风险、原作者认知锚定而排斥考虑的替代方案。DA/DI 可用于全部四个阶段（需求挑战前提 → code review 的"对抗式 LGTM"）。辩证 bootstrapping（Herzog & Hertwig, 2009）是其个体级变体——单个评审者内部采取对抗立场，组不起 DA 小组时可用。

产物 A：角色 × 生命周期阶段适配矩阵​

每格标"高 / 低 / 无"信号：高 = 该阶段是此角色的主战场，漏掉它会放过其独占问题类别；低 = 有边际价值但非主战场；无 = 该阶段此视角无信号。阶段列：讨论 = 需求讨论，spec = 设计 spec，plan = 实现 plan，review = code review。

@tbl-review-matrix 角色 × 生命周期阶段适配矩阵

角色讨论specplanreview独占问题类别（一句话）
通才同行评审者（Google peer）低高低高方案最简性与局部自洽
隐私评审者高高无低数据最小化 / 留存 / 跨境流
资深 / TL 评审者低高无无跨团队架构一致性
安全评审者（Chrome）低高高低攻击面与威胁模型完备性
WG 共识 / 领域专家低高高无领域协议正确性
SECDIR / 安全董事会低高低无威胁模型 + 安全考量充分性
领域主管（AD）低高无无跨工作组架构协调
RFC Approver（go/no-go）高高无无该不该解 / 有无更简办法
全员广播评审（Uber）低高无无未声明的地理 / 法务假设
企业 / 首席架构师（ARB）高高无无组合级错位与技术蔓延
领域 / 技术架构师（ARB）无高低无集成失败与跨系统耦合
业务干系人（ARB）高高无无业务能力缺口
合规 / 安全官（ARB）低高无低组合级监管合规
红队无低高高攻击链组合失败
蓝队无低高低检测覆盖缺口
紫队无低低低安全反馈回路失败
STRIDE-Spoofing低高高低信任边界身份混淆
STRIDE-Tampering低高低高全生命周期数据完整性
STRIDE-Repudiation高高无低审计完备 + 防篡改
STRIDE-Info Disclosure低高低高全通道机密性
STRIDE-DoS低高高低对抗性负载可用性
STRIDE-EoP低高高高全层授权边界完备
攻击树高高低无目标导向多路径枚举
abuse / misuse case高高低低授权主体滥用合法功能
Working Backwards / PR-FAQ高无无无该不该做（用户价值）
用户故事 / INVEST高低低无需求质量（可测 / 独立 / 有值）
SRE PRR无低高高生产可运维性
FMEA / 运维评审无高高低失效模式量化枚举
领域正确性 / 不变量高高低高不变量 / 契约 / 量纲
测试 / QA低高高高边界 / 等价类 / 回归
可维护性 / 可读性无低低高认知负荷 / 注释腐烂 / 技术债
六顶思考帽高高高高系统化覆盖六类思维模式
魔鬼代言人 / DI高高高高群体思维产物

矩阵读法：

  • 需求讨论列的高信号角色集中在产品 / 治理 / 该不该做：PR-FAQ、INVEST、Approver、业务干系人、企业架构师、abuse case、攻击树根节点、领域不变量捕捉。这一列工程视角（红队、PRR、可维护性）几乎全是"无"——印证产品视角在最早阶段不可替代。
  • 设计 spec 列几乎全员高信号——这是评审密度最高的阶段，绝大多数独占问题类别在此可被最低成本拦截。
  • code review 列的高信号收缩到代码级可见的视角：可维护性、测试边界、STRIDE 中可在代码确认的几类、领域不变量实现、红队定向。架构 / 产品 / 治理类在此基本"无"——它们的问题在 review 阶段已冻结，改不动。
  • 六顶帽与 DA/DI 全列高信号——它们不绑定领域，是"换视角"的元工具，任何阶段都能套。

产物 B：正交性分析​

正交性是评审角色库的价值来源。下面区分"该合并的重叠角色"和"真正正交的独立视角"。

应合并 / 收编的重叠角色​

  • Google 安全评审者 ≈ STRIDE 全家 ≈ SECDIR：三者都做"威胁模型完备性"。STRIDE 是把这一视角结构化成 6 个子检查项的工具，SECDIR 是协议语境下的同一视角。落地评审角色库时应合并为一个"安全 / 威胁建模"角色，内部用 STRIDE 6 类做 checklist，不设三个独立角色。
  • 黑帽 ⊂ 魔鬼代言人 ⊂ 红队（对抗强度递增）：黑帽（找风险）、DA（指派一人系统反对）、红队（有动机的真实攻击者）是同一"对抗"轴上强度递增的三档，不是三个正交视角。轻量评审用黑帽，决策评审用 DA，安全关键系统才上红队。
  • FMEA ≈ STRIDE-DoS ≈ 攻击树（失效枚举的三种 notation）：都做"系统化枚举失效 / 攻击路径"。FMEA 面向可靠性失效，STRIDE-DoS 与攻击树面向对抗失效。共享"穷举 + 排序"机制，落地时可统一为一个"失效 / 攻击路径枚举"角色，按安全 / 可靠分支选 notation。
  • 资深 TL 评审者 ≈ 领域主管 ≈ ARB 企业架构师（跨边界一致性，半径递增）：三者都管"局部最优但全局冲突"，区别只在评审半径（跨团队 → 跨工作组 → 跨组合）。小组织合并为一个"架构一致性"角色即可，大组织才按半径分层。

真正正交的独立视角​

下列视角覆盖的问题集合几乎不重叠，删掉任一就放过一整类失败，应在角色库中独立保留：

  • 产品视角（PR-FAQ）：唯一问"该不该做"的视角。所有工程 / 安全 / 运维视角都默认"做"为前提，无法回填这个问题。
  • 运维视角（PRR）：唯一验证"生产能否被人运维"的视角——告警率、回滚、on-call、容量。设计评审与 code review 结构上看不到运行时遥测与人因就绪。
  • 领域正确性视角（不变量 / 量纲）：唯一需要领域知识才能检测的视角。火星轨道器的磅·秒 vs 牛·秒，两份代码各自正确，只有领域评审者在接口边界能抓到。通用安全 / 测试 / 可维护视角全部漏过。
  • abuse case 视角：唯一聚焦"已授权主体滥用合法功能"的视角，是 STRIDE（技术控制）、攻击树（外部入侵）、红队（周界突破）共同的盲区。
  • 可维护性视角：唯一以"未来维护者"为时间基准的视角——认知负荷、注释腐烂、技术债，都是功能正确但未来昂贵的问题，正确性 / 安全 / 测试视角全部漏过（Google 把它单独认证正说明这点）。
  • 测试视角：唯一以"可验证性 / 边界"为镜的视角——off-by-one、缺失等价类、不可测设计，设计评审与功能评审看不到。

落地建议：6 个正交核心角色 + 2 个元工具​

把 33 个细分角色收敛成可操作的角色库：

  1. 产品 / 用户（PR-FAQ + INVEST）——该不该做 + 需求质量，主战场需求讨论
  2. 架构一致性（TL / AD / 企业架构师收编）——局部最优 vs 全局冲突，主战场设计 spec
  3. 安全 / 威胁建模（Google 安全 + STRIDE + SECDIR + 攻击树 + abuse case 收编）——内部按 STRIDE 6 类 + abuse case 展开
  4. 运维 / 可靠性（PRR + FMEA）——生产可运维 + 失效枚举，主战场实现 plan → 上线前
  5. 领域正确性（不变量 / 契约 / 量纲）——独立保留，主战场需求讨论 + code review
  6. 代码质量（测试 + 可维护性）——主战场 code review

两个元工具横跨所有阶段、所有角色：六顶思考帽（系统化轮换思维模式）和魔鬼代言人 / DI（对抗群体思维）。它们不替代上面 6 个领域角色，而是规定"怎么评"——确保每个领域角色既看风险（黑帽）也看替代方案（绿帽），且至少一人被指派为对抗立场。

开放问题​

  • 元工具如何嵌入流程：六顶帽 / DA 是会议引导技巧，落到异步的 spec / PR 评审（无同步会议）时如何制度化，业界缺成熟范式。
  • 角色触发的自动化判据：哪些 PR / spec 特征应自动触发哪个角色（如"碰数据流 → 触发安全 + 领域正确性"），未找到公开的成熟决策表。
  • AI 评审 agent 的角色映射：把这套角色库映射到 LLM 评审 agent（每个角色一个 system prompt）的有效性，2026 年仍是开放问题，无公开对照实测。

参考来源​

设计文档评审：

对抗式评审与威胁建模：

产品与运维视角：

数据正确性 / 测试 / 可维护性 / 思维框架：