当产品积累了大量设计不一致时…

适用于产品迭代久了出现视觉、结构、无障碍、文档、实现等设计债务，需要系统审计并产出可执行修复计划的场景。

适用场景

解决思路

1. 明确审计范围：整个产品、某个功能区域或某个平台。
2. 对范围内每个屏幕/状态截图。
3. 按屏幕类型、组件类型或用户流程编目。
4. 对每个屏幕或组件打标签：严重度（Critical：无障碍违规、重大不一致 / Moderate：视觉不一致、过时模式 / Minor：细节打磨、边缘情况）。
5. 对每个屏幕或组件打标签：类别（Visual / Structural / Accessibility / Documentation / Implementation）。
6. 对每个屏幕或组件打标签：出现频率（该问题出现多少次）。
7. 对每个屏幕或组件打标签：修复工作量（Low / Medium / High，粗略工程估算）。
8. 量化：统计每种问题类型的总实例数。
9. 量化：估算用户触达（多少用户会遇到每个债务项）。
10. 量化：评估业务风险（该债务是否带来合规、法律或信任风险）。
11. 按 严重度 × 频率 / 工作量 对债务项打分。
12. 输出一小份高优先级清单——即单位修复工作量造成最大危害的债务。
13. 制定修复计划中的 Quick wins：低工作量、高频的不一致（token 修复、文案更新）。
14. 制定修复计划中的 Structural projects：需要设计和工程投入，排入路线图。
15. 制定修复计划中的 Accessibility fixes：优先处理 Critical 违规；为 Moderate 建立滚动修复待办。
16. 制定修复计划中的 Write-off items：存在于低流量区域且会被计划中的重设计解决的债务——记录并推迟。
17. 维护一份活的债务登记册（不是一次性审计），跟踪：问题描述、类别与严重度、受影响屏幕/组件、状态（open、in progress、resolved、deferred）、负责人、目标解决时间（sprint 或里程碑）。
18. 每季度审查登记册；随产品变化更新严重度。
19. 在启动重大重设计之前先做设计债务审计——它定义了实际工作范围。
20. 把审计与修复分开；审计是研究，不是修复冲刺。
21. 让工程参与严重度和工作量估算——设计师常低估实现复杂度。
22. 把债务减少作为指标跟踪；用它来争取路线图中专门的清理容量。
23. 预防积累：在设计评审清单中加入“这会不会产生设计债务？”这一问题。

适用边界 · 注意事项

• 仅需审计设计 token 覆盖时，应使用 design-token-audit（designer-toolkit）。
• 仅需排查 WCAG 无障碍缺口时，应使用 accessibility-audit（design-systems）。