界面设计质量评分

解决什么问题

界面审查最大的问题是主观：/ss-review 能告诉你「哪里不对」，但说不清整体到底几分、先修哪一处。这份技能把设计审查变成可量化的数字——像追踪单元测试覆盖率一样追踪 UI 质量，而不是每轮迭代凭感觉重说一遍。

评分如何运作

流程很直接：每个类目从满分开始，逐条读取代码发现问题后扣分，且必须引用具体行号作为依据，不允许凭空猜测。各类目权重合计 100 分，最终按字母分级输出：90+ A、80-89 B、70-79 C、60-69 D、<60 F。

扣分维度与典型问题：

• Color discipline（18）：#000 纯黑文本、装饰性多色相、把 emoji 当 UI 图标（−5）、普通状态误用状态色、仅靠颜色传达状态
• Hierarchy & typography（18）：字号偏离 Font Size 表、全文同字重无明确主次、正文行高不当
• States & a11y（18）：数据区缺少空/加载/错误态（每个 −5）、对比度不足、触摸目标小于 44px、outline:none
• Layout & rhythm（14）：内容裸奔在背景上而非卡片内、间距未按 space-y-6 节奏、同类区块在一行重复
• Cards & elevation（12）：用 1px 边框代替色调+阴影的分层工作
• Coherence（12）：圆角性格混杂、多个强调色互相竞争——这类系统性不一致正是「AI 生成感」的主要来源
• Motion & interaction（8）：随机淡入、动画阻塞内容或操作、缺少 prefers-reduced-motion 处理、视差滚动

Gate 模式：评分不是一次性动作。低于 80 分就按「提分最多优先」的顺序修复并重新评分，最多循环约 3 轮，直到 ≥ 80 再展示给用户。80 是地板不是天花板——干净的 85 分，好过为追 100 分而迟迟不交付。

适用边界

• 需要快速 pass/fail → 用 /ss-lint
• 需要带修复建议的完整散文审计 → 用 /ss-review
• 逻辑、配置文件等非 UI 文件打分没有意义
• /ss-score 只负责测量，改代码交给 /ss-review 和 /ss-motion（Gate 模式除外）