设计系统评审不是检查页面“像不像规范”，而是验证设计决定能否从基础变量传到组件、文档、代码和真实页面，并且在异常状态、主题切换和版本升级时仍然成立。一场有效评审应按“变量 → 组件 → 文档 → 代码映射 → 页面抽样”逐层检查，每个问题都要记录证据、影响范围、负责人和上线结论。
评审前应已有可用的变量、组件和文档。还在起步阶段，可先完成设计系统搭建流程；涉及版本、废弃与迁移规则时，可结合组件库治理方法确定检查范围。
评审前先锁定范围、版本和通过标准
没有范围的评审很容易变成审美讨论。会前应写清本轮对象：哪些变量集合、哪些组件、哪个代码包、哪些业务页面，以及明确不评的内容。评审链接和代码版本必须冻结，不能一边评一边覆盖基线。
- 评审范围：变量、组件、文档、代码包和抽样页面的版本号。
- 目标场景：新系统首次上线、主题升级、组件大版本或季度巡检。
- 通过标准：阻塞问题为零，高优先问题有负责人和完成时间。
- 角色分工：设计负责语义与体验，研发负责实现，测试负责状态与回归，业务确认场景边界。
用五层模型组织设计系统评审
评审顺序不能倒置。基础变量决定颜色、字号和间距；组件引用变量并封装结构与行为；文档解释选用边界；代码实现承接属性和状态；真实页面检验系统是否真的可用。上层问题常由下层错误引起，应先定位根因再改页面。
基础变量：检查语义、覆盖与主题切换
变量评审先看命名是否描述语义，再看引用是否完整。基础色值可以叫 blue-500，组件不应直接依赖它，而应引用 action-primary 等语义变量。切换明暗主题或品牌主题时，语义保持稳定，取值随模式变化。
- 颜色、字号、行高、间距、圆角和阴影是否有明确层级？
- 组件是否绕过语义层，直接写死基础值或十六进制颜色？
- 主题切换后，对比度、层级和状态辨识是否仍成立？
- 同义变量、孤儿变量和未使用变量是否有合并或清理计划？
变量分层不清时，可按Design Token 的基础值、语义和组件三层重新定位；评审只记录问题和处理责任，不在会议现场批量重命名。
组件质量：检查结构、属性和组合边界
组件评审要回答三个问题：结构是否稳定，属性能否表达真实差异，组合是否允许错误用法。按钮把颜色做成属性而没有用途语义，或表单组件允许互相冲突的状态同时开启，都会把错误扩散到页面。
| 检查项 | 通过信号 | 常见失败 |
|---|---|---|
| 结构 | 必选与可选区域明确 | 实例靠手工删图层适配 |
| 属性 | 用途、尺寸、状态分离 | 每种组合复制成新组件 |
| 嵌套 | 依赖关系清楚且可替换 | 深层嵌套导致实例不可改 |
| 约束 | 错误组合被限制或说明 | 冲突属性可以同时开启 |
状态覆盖：从正常路径走到失败与恢复
状态评审不能只看默认和悬停。可交互组件至少按实际责任检查聚焦、禁用、加载、空、错误和成功反馈，并写清触发条件、用户能否操作、如何恢复。不同组件需要的状态不同，不追求机械齐全。
检查时用一个真实任务串起状态，例如提交表单：输入校验失败、按钮加载、防重复提交、接口失败、重试成功。需要建立完整状态清单时，可继续使用组件状态与变体检查方法。
文档契约：验证成员能否独立选用和实现
文档评审不以字段数量为终点，而以陌生成员能否独立完成任务为标准。给设计师一个页面，让他判断用哪个组件和变体；让研发从文档找到代码对象与参数；让测试生成状态用例。若仍依赖作者口头补充，说明文档契约不完整。
- 用途与禁用场景是否成对出现？
- 结构、属性、默认值和冲突规则是否明确？
- 状态是否包含触发、表现、操作与恢复？
- 负责人、版本、替代项和变更记录是否可追踪？
团队可直接沿用组件文档模板统一字段顺序，但复杂度应随风险增加，不要求简单组件写成同样长的说明。
设计与代码：逐项核对对象、属性和变量
设计和代码不必使用完全相同的字符串，但要有唯一映射。评审表应连接设计组件、设计属性、代码组件、代码参数、变量、实现版本和负责人。一对多通常意味着边界过宽，多对一可能意味着设计侧只是重复建立了变体。
抽查变更链路：设计侧修改主组件或变量后，代码包、文档、测试和业务页面分别如何感知？如果只能靠群消息通知，系统仍缺少可追踪的发布契约。
真实页面抽样：验证系统不是只在组件页成立
选择三类页面抽样：高频核心页面、状态复杂页面和历史遗留页面。检查组件替换率、局部覆盖、写死样式、长文案、多语言、窄屏和异常数据。组件展示页通过不代表业务页面就能落地。
每个问题都要区分“系统缺陷”和“页面误用”。系统缺陷应回到变量、组件或文档修复；页面误用则修正实例并补充规范示例。不要为了让一个页面通过而给公共组件增加只服务单场景的属性。
问题如何分级：阻塞、高、中、建议
- 阻塞：关键任务不可完成、无恢复路径、严重无障碍或设计代码完全不一致，上线前必须清零。
- 高优先：高频组件规则错误、主题切换失败、版本不兼容，应在本轮关闭。
- 中优先：低频场景缺口、示例不足或迁移信息不完整，明确负责人和截止时间。
- 建议：不影响当前任务的体验优化，进入后续计划，不能占用本轮上线判断。
同类问题应合并到根因，不要把 20 个页面中的同一变量错误记录成 20 条独立缺陷。问题单至少包含证据、影响对象、根因层级、负责人、修复版本和复核人。
在墨刀中组织评审材料与协作
团队可以在墨刀设计中整理组件、变量和真实页面，将评审说明放在同一项目的独立页面，并通过共享链接让设计、产品和研发围绕同一版本讨论。评审结束后，保留问题编号与变更记录，避免结论只存在于会议或聊天中。
- 评审前冻结版本，并标注本轮包含与不包含的范围。
- 评审中按五层顺序记录问题，不直接在现场改动公共组件。
- 评审后创建修复版本，由原问题提出者或指定复核人验收。
一次 60 分钟评审怎么安排
- 5 分钟：确认范围、版本、角色和通过标准。
- 10 分钟：抽查基础变量、主题和引用覆盖。
- 15 分钟：检查高频组件的结构、属性和状态。
- 10 分钟：让设计、研发和测试分别执行一个文档任务。
- 10 分钟：核对设计代码映射和变更链路。
- 10 分钟：抽样真实页面，完成问题分级与上线结论。
设计系统上线评审清单
- 范围、版本、评审对象和不评内容已经冻结。
- 变量有语义层，组件没有大量写死基础值。
- 高频组件结构稳定，属性与组合限制明确。
- 关键状态包含触发、反馈、操作与恢复规则。
- 组件文档支持设计、研发和测试独立完成任务。
- 设计对象、代码组件、参数、变量和负责人可追踪。
- 真实页面完成高频、复杂和遗留三类抽样。
- 阻塞问题为零，其余问题有负责人、版本和复核人。
常见问题
设计系统多久评审一次？
首次上线和大版本升级必须评审；稳定运行后可按季度抽查。高频组件、主题或代码包发生破坏性变更时，应触发专项评审，不必等待固定周期。
评审需要把所有组件逐个检查吗？
首次上线应覆盖基础组件和高风险业务组件；周期复核可按使用频率、变更量和问题历史抽样。变量和公共依赖仍需全量扫描，因为它们影响面最大。
设计稿和代码不一致时以哪边为准？
不要默认任何一边天然正确。先根据当前发布版本、业务规则和变更记录确认有效契约，再修正偏离的一方；同时补上缺失的映射和责任人，避免再次分叉。
总结
设计系统评审要验证的是传递链，而不是单张组件页。按变量、组件、文档、代码和真实页面逐层检查，用任务验证规则是否可执行，再把问题按阻塞程度形成负责人、版本与复核闭环，才能让设计系统在真实交付中持续成立。
