审查现有 UI 的缺陷与可访问性问题时…

适用于对现有界面做 UI 审计、设计 QA、前端/可访问性审查、一致性检查，或找出并安全修复视觉缺陷；不用于从零创建新 UI。

适用场景

解决思路

1. 把确定性缺陷与主观设计建议分开。
2. 阅读 `.21st/design.json`、项目说明和相关源码。
3. 先运行确定性审查：`21st review <path>`；需要结构化输出时运行 `21st review <path> --json`。
4. 检查实际组件组合和运行时状态；用代码验证结论，不要仅凭命名推断行为。
5. 将发现分组为：确定性缺陷；设计系统漂移；可访问性与交互缺陷；响应式风险；主观产品/设计建议。
6. 按用户影响排序，并附精确文件和行号归属。
7. 仅对确定性、低歧义修复使用 `21st review <path> --fix`；绝不静默重设计、更改品牌标识或改变产品行为。
8. 修复后运行相关项目测试，并重新运行审查以证明问题已解决。
9. 检查语义化控件和可访问名称。
10. 检查键盘访问、焦点可见性以及对话框/菜单行为。
11. 检查图像替代文本和有意义的标签。
12. 检查触控目标尺寸以及禁用/加载状态。
13. 检查响应式溢出和固定宽度假设。
14. 检查减少动态效果（reduced-motion）处理。
15. 检查与项目 token 冲突的硬编码视觉值。
16. 检查是否使用重复原语而不是既有组件。
17. 检查排版、圆角、间距、阴影和图标是否不一致。
18. 检查假数据、占位文案或缺失空/错误状态。
19. 先给出按严重程度排序的可操作发现。
20. 保持主观建议有清晰标注。
21. 如果没有被证实的问题，说明没有发现问题，并说明检查了什么。

适用边界 · 注意事项

• 请求主要是创建新 UI 时不适用；应使用 `21st-ui-build`。
• 项目缺少 `.21st/design.json` 或无法使用 `21st` 工具链时不适用。