怎么用这份清单
这份清单用于两类场合：架构评审会与季度健康检查。区别在深度：评审会聚焦本次变更涉及的组，健康检查覆盖全部十组。
每一题要求四个字段：
| 字段 | 含义 | 反例 |
|---|---|---|
| 现状 | 当前实际做法，一句话 | 「大概做了」 |
| 证据 | 可打开的文档、代码、监控或测试 | 「大家都清楚」 |
| 缺口 | 与判据的差距，可执行 | 「有待完善」 |
| owner | 负责收敛的人或角色 | 「团队」 |
四个字段填不满，说明这一题还没到可评审的状态。主持人应记录「未验证」，不要用讨论代替证据。
第一组：承诺与边界
- 五个端的核心功能是否有一张承诺矩阵？每格等级是否写明？
- 哪些行为被定为
identical？验收方式是否可执行？ - 是否存在「未声明」的格子？未声明时默认按什么处理？
- 共享内核的依赖图是否无环、无越层？
core层是否真的没有平台 API 依赖？- 共享代码的所有权是否明确？谁有权修改公共契约？
- 新增一个端时，需要改哪些共享模块？是否有清单？
判据：承诺矩阵能回答「为什么这一格是这个等级」；依赖图能自动检测越界。
常见缺口：矩阵存在但无人维护；依赖检查只在文档里；新增端没有接入清单。
第二组：设计系统与组件
- token 是否分三层（primitive / semantic / component）？业务代码是否绕过 token？
- 主题覆盖顺序是否固定？多品牌冲突如何检测？
- 组件契约是否包含属性、事件、插槽与可访问性语义？
- 破坏性变更是否有判定规则与版本递增策略？
- 是否存在 fork 组件？fork 是否有回流计划？
- 组件库的采用率是否可度量？未采用的原因是什么？
判据：同一组件的计算样式在各端一致；契约变更能自动分类为破坏性/兼容。
常见缺口：token 命名按视觉值；fork 无登记；采用率靠感觉。
第三组：插件化与动态化
- 插件协议是否声明宿主 API 版本区间与所需能力？
- 插件权限是否最小化？越权请求如何处理？
- 单个插件失败是否隔离？是否影响宿主主流程？
- 动态配置是否有 schema 校验与版本兼容检查？
- 热更新是否有灰度比例、观察窗口与停止条件？
- 是否存在「只能热更、无法回滚」的路径？
判据：任一插件崩溃不影响宿主；任一配置下发前经过校验；热更新可在一分钟内停止。
常见缺口：权限一次授予全部；配置直接透传；回滚依赖人工重发。
第四组：性能
- 是否有分端、分阶段的性能预算？阈值谁定、谁复核？
- 预算超限是否在合并前被拦截？还是上线后才发现？
- 性能退化能否归因到具体阶段与具体提交？
- 基线多久更新一次？更新是否记录原因？
- 是否只关注平均值，忽略尾部与弱网？
判据：每个阶段有独立阈值；回归能在 CI 中复现；基线变更有记录。
常见缺口：预算只有总数；归因靠人肉；基线半年未更新。
第五组：稳定性
- 关键依赖是否画出故障域？单点是否识别？
- 每个故障域能否估算爆炸半径（影响功能/用户比例）？
- 降级路径是否被测试？是否有可用兜底内容？
- 开关是否有 owner、默认值、过期时间？
- 最近一次故障演练是什么时候？恢复断言是什么？
- 演练未通过的项是否进入台账并有人跟进？
判据：任一依赖故障能说出影响范围；降级路径有测试；开关有生命周期。
常见缺口：开关只增不减；演练只看报错；降级从未触发过。
第六组：构建与交付
- 包边界是否显式？是否存在深层隐式导入？
- 依赖图是否无环？跨包引用是否经过评审？
- 产物缓存键是否包含源码、依赖与构建配置？
- 缓存失效策略是否验证过？是否出现「该更新没更新」？
- 发布流水线有哪些门禁？门禁失败是否真的阻断？
- 灰度是否有分批比例、观察指标与自动停止？
- 回滚是否演练过？回滚后的数据是否兼容？
判据：缓存可复现；门禁失败无法合并；回滚在十分钟内完成。
常见缺口：缓存键缺配置；门禁可人工跳过；回滚脚本过期。
第七组：可观测性
- 每条关键事件是否满足最小字段契约？
- 字段命名是否统一？能否按功能聚合？
- 错误与阻塞事件是否全量采集？采样策略是否分层？
- PII 是否在采集端脱敏？下游是否还有原始数据？
- 告警是否绑定 owner 与 runbook？是否有去重与聚合？
- 从告警到定位的平均时间是多少？最近一次超时原因是什么？
判据：用一条事件能回答「谁、在哪、做了什么、结果如何」；告警有人接。
常见缺口：字段随人命名；错误被采样；告警发群无人认领。
第八组：安全与隐私
- 数据是否分级？每级的采集、存储、传输规则是否不同？
- 第三方 SDK 是否有清单、版本、权限与 owner？
- SDK 初始化是否在用户同意之后？是否有证据？
- 权限申请是否与功能使用时机一致？拒绝后是否有降级？
- 是否存在「一次同意、永久采集」的路径？
- 下线 SDK 的残留代码与权限是否清理？
判据：任一类数据能追到授权记录；任一 SDK 能说出采集字段与用途。
常见缺口：分级只在文档；SDK 清单过期；同意状态不可追溯。
第九组：国际化与无障碍
- 文案是否全部外置？是否支持复数与参数化？
- 金额是否用整数最小单位？小数位与舍入是否按币种配置？
- 时间是否存 UTC、按区域展示？跨时区边界是否测试？
- RTL 是否镜像布局、图标与方向语义？
- 区域能力差异（支付、物流、地图）是否有降级路径？
- 控件是否有角色、名称与状态？焦点顺序是否与视觉一致？
- 是否支持减少动效、放大字体、高对比？状态变化是否有播报？
- 无障碍是否进入组件契约与发布验收？
判据：同一功能在目标区域语义等价；主流程可用读屏完成。
常见缺口：金额用浮点；RTL 只镜像容器；无障碍只在专项时检查。
第十组：治理与迁移
- 重大决策是否有 ADR？是否记录被放弃的选项与后果？
- 每个包/模块是否有 owner 与备份 owner？
- 技术债是否有台账、分级与偿还节奏？
- 架构规则有多少条被自动化？失败是否阻断？
- 当前是否有进行中的迁移？退出条件是什么？
- 双写是否有一致性校验？差异率是多少？
- 旧路径何时删除？谁有权宣布迁移结束？
- 过去一个季度，治理动作带来了什么可度量变化？
判据：决策可追溯；owner 可点名；迁移有终点。
常见缺口：ADR 只写结论；owner 挂团队；迁移无退出条件。
快速十问
时间只有十分钟时，问这十个：
- 哪三个行为必须跨端逐字一致？验收在哪？
- 共享内核最底层依赖了什么？有没有环？
- 某功能在某端不可用时，用户看到什么？
- 性能预算按端怎么分？超了谁负责？
- 最近一次故障演练是什么时候？结论是什么？
- 产物缓存的键包含什么？怎么证明没命中旧包？
- 一条线上事件能回答哪些问题？缺什么字段？
- 哪类数据最敏感？谁授权采集？证据在哪？
- 主流程能用读屏走完吗？谁最近验证过？
- 下一次迁移什么时候算结束？旧代码何时删？
十个问题里答不上三个以上，本轮评审的重点就确定了。
评审记录模板
评审对象：
日期 / 参与人：
本次范围：第 X 组 ~ 第 Y 组
| # | 问题 | 现状 | 证据 | 缺口 | owner | 截止 |
|---|------|------|------|------|-------|------|
| 1 | | | | | | |
未验证项：
- 问题编号 / 原因 / 补证计划
结论：
- 通过项：
- 有条件通过项（附条件与期限）：
- 阻断项（附修复要求）：
下次复核：
模板的重点是「未验证项」单独列出。评审最容易犯的错，是把「没人反对」当成「没有问题」。
评审中的常见分歧
清单本身不会产生分歧，分歧通常出现在「什么算证据」和「谁该负责」上。三种常见分歧与处理方式：
分歧一：这个不一致是历史原因，改不了。 不要求立即改。要求把它写进承诺矩阵，标注 allowed-diff 并写明理由与复审时间。历史原因可以成为理由，但不能成为空白。
分歧二：这个指标我们没测过，先按经验估。 估值可以写，但必须标「未验证」，并指定补测计划。评审记录里「未验证」比「大约」更有价值，因为它会产生下一步动作。
分歧三：这个问题属于另一个团队。 记录 owner 时写到具体人或角色，不写团队名。跨团队的问题由主持人当场确认接收方，否则默认留在原团队。
分歧不是坏事。它说明清单问到了真实边界。真正危险的是所有问题都「没问题」，那通常意味着没有人认真回答。
评审的边界
清单不是打分表。答完所有问题不代表架构健康，只代表已知问题被记录。反过来，几道题答不上来也不代表架构失败，可能只是还没到需要它的阶段。
判断是否需要完整评审，看三个信号：
- 端从两个扩到三个以上。
- 团队从两个扩到三个以上。
- 同一类问题第二次以不同形式出现。
出现任一信号，做一次完整评审；否则按变更范围选组即可。
结语
评审的目的不是证明架构正确，而是让判断留下痕迹。半年后再看这份记录，能知道当时为什么这样决定、放弃了什么、哪些风险被接受。
没有痕迹的评审，只是一次会议。
清单可以裁剪。团队只有三个端、两个小组时，不必一次问完六十五题；先做第一组、第四组、第五组与第十组，已经能覆盖大多数真实风险。随着端和团队增加，再逐步展开其余组。
清单也可以扩展。每个团队都应该在通用题之外，补三到五道本地题：本产品最敏感的资产是什么、最近一次线上事故的根因是否已消除、哪些规则只能靠人记而不能靠工具查。本地题往往比通用题更早暴露问题。
最后提醒一句：评审的价值不在会议当天，而在下一次同类决策时，有人能翻出上次的记录说「我们当时考虑过这个选项，放弃的原因是……」。能支撑这句话的记录，才算合格。
如果只能带走一页，带走「快速十问」；如果只能改一件事，先把「未验证项」单独列出来。这两件事的成本最低，收益最长。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。