📊 页面导航
适用角色与上手难度
🎯 学习产出: 掌握设计评审的系统化方法,能用 Claude Code 自动检查设计一致性、交互逻辑和无障碍问题
🚀 AI 能力提升: 设计审查、一致性检查、无障碍审计
设计评审与走查
预计阅读时间: 11 分钟
好的设计不是做出来的,是审出来的。这章教你怎么用 Claude Code 像专业设计师一样做设计走查——而且是自动化的。
设计评审为什么重要
在设计评审中发现问题,修复成本假设是 1。到了开发阶段再发现,成本变成 10。上线后发现,成本是 100。更可怕的是一致性问题在设计评审阶段很难被人工发现——一个人脑看 20 个页面,很难记住第 1 页按钮的圆角和第 20 页的是否一致。
Claude Code 干不了"创造好看的设计",但它能干的比任何人类都强的是:记住规则,在所有页面上执行一致性检查。
本章流程
准备评审素材 → 一致性检查 → 交互逻辑验证 → 无障碍审计 → 生成评审报告
3min 5min 5min 3min 4min
以 TaskBoard 原型为例(上一章产出的 prototype.html)。
Step 1:准备工作:告诉 Claude 你的设计规范
设计评审的前提是——你告诉 Claude 什么是对的。如果你不定义规范,它只能靠常识判断,但常识不等于你的设计意图。
创建一份设计规范文件,或者直接用自然语言描述:
> 我要对 docs/taskboard/prototype.html 做设计评审。
> 这是我们的设计规范:
>
> 颜色:主色 #3B82F6(蓝),危险 #EF4444(红),警告 #F59E0B(黄),成功 #10B981(绿)
> 圆角:按钮 6px,卡片 8px,输入框 4px
> 间距:元素间最小间距 8px,区块间距 16px
> 字体:所有文字 14px,标题 18px,标签 12px
> 优先级颜色:高=#EF4444,中=#F59E0B,低=#9CA3AF
>
> 请逐一检查原型是否遵守这些规范,给出不符合项和修复建议。
Claude Code 会逐条验证,输出类似:
Claude: 设计规范检查结果:
✅ 主色 #3B82F6 —— 按钮和链接使用了正确颜色
✅ 优先级颜色 —— 三个优先级标签颜色正确
⚠️ 圆角不一致 —— 创建按钮使用了 4px 圆角,规范要求 6px
⚠️ 字体大小 —— 卡片描述使用了 13px,规范要求 14px
❌ 间距 —— 看板列之间间距为 12px,规范要求 16px
共 3 个不符合项,建议修复。
Step 2:一致性检查 —— 设计系统的魔鬼在细节
一致性是最容易出问题、也最容易被人工遗漏的方面。Claude Code 擅长这类机械但全面的检查:
> 对原型做更深入的一致性检查:
> 1. 所有按钮的 hover/active/disabled 状态是否一致
> 2. 所有输入框的 placeholder 颜色是否统一
> 3. 所有卡片的阴影是否一致
> 4. 空状态的展示是否统一(没有卡片的列怎么显示)
> 5. 颜色对比度是否满足 WCAG AA 标准
Claude Code 会逐项检查并给出报告。
高级技巧:多页面一致性检查
如果你有多个原型页面,可以让 Claude Code 跨页面检查:
> 检查 docs/taskboard/ 目录下所有 HTML 文件之间的一致性:
> - 导航栏位置和样式是否统一
> - 相同组件的实现是否一致(比如所有页面的「创建」按钮)
> - 错误状态和加载状态的展示方式是否统一
Step 3:交互逻辑验证
设计不只是长得好看,交互逻辑对不对同样重要:
> 检查原型的交互逻辑:
>
> 预期行为:
> 1. 卡片只能在相邻列之间拖拽(不能跳列)
> 2. 拖到「待审核」时需要填写审核人
> 3. 优先级为「高」的卡片在列中永远排在最上面
> 4. 删除卡片前需要二次确认
> 5. 已完成的卡片不应可以编辑
>
> 逐条验证这些行为是否在原型中正确实现。
如果原型的交互逻辑有缺漏,Claude Code 会指出具体问题:
Claude: 交互逻辑检查结果:
❌ 问题 1:卡片可以在任意列之间拖拽,没有限制相邻列
→ 位置:拖拽处理函数 dragEnd() 中没有列限制条件
→ 修复:添加 `canMoveToColumn(from, to)` 校验函数
❌ 问题 3:优先级排序未实现
→ 位置:卡片渲染时没有按优先级排序
→ 修复:在 renderColumn() 前对 cards 数组按 priority 排序
⚠️ 问题 5:已完成的卡片仍可编辑
→ 位置:编辑按钮在所有卡片上都显示
→ 修复:column === 'done' 时隐藏编辑按钮
Step 4:无障碍审计
无障碍(Accessibility)经常被忽略,但它影响约 15% 的用户体验。Claude Code 能做基本的无障碍检查:
> 对原型做无障碍审计,重点检查:
> 1. 所有交互元素是否可通过键盘操作(Tab/Enter/Space)
> 2. 是否有合适的 ARIA 标签
> 3. 颜色是否不只是唯一的信息传达方式
> 4. 拖拽功能是否有键盘替代方案
> 5. 表单元素是否有正确的 label 关联
Tip
无障碍是功能,不是附加项。早期审计的成本远低于后期重构。而且很多无障碍要求(如键盘操作、语义化标签)恰好也能提高 SEO 和移动端兼容性。
Step 5:生成评审报告
让 Claude Code 把所有检查结果汇总成一份报告:
> 把前面所有检查结果汇总成一份设计评审报告,写入 docs/taskboard/design-review-report.md。
> 按严重程度排序(严重 → 主要 → 次要),每个问题包含:
> - 问题描述
> - 出现位置
> - 严重程度
> - 修复建议
> - 预估修复时间
生成的报告可以直接发给团队,也可以作为后续开发的检查清单。
报告示例:
# TaskBoard 设计评审报告
评审日期:2026-07-10
评审范围:prototype.html
## 问题汇总
| 严重 | 主要 | 次要 | 总计 |
|------|------|------|------|
| 2 | 5 | 3 | 10 |
## 严重问题
### 1. 键盘操作缺失
- **位置**:全局
- **问题**:所有拖拽操作无法通过键盘完成,依赖鼠标
- **建议**:添加 Ctrl+← → 快捷键移动卡片,或添加「移动」下拉菜单
- **预估时间**:2h
### 2. 删除操作无撤销
- **位置**:deleteCard() 函数
- **问题**:删除卡片后没有撤销机制,数据不可恢复
- **建议**:添加 toast 通知 + 5 秒内撤销按钮
- **预估时间**:1h
## 主要问题
### 3. 颜色对比度不足
- **位置**:低优先级标签(灰色 #9CA3AF on 白色背景)
- **问题**:对比度 2.8:1,不满足 WCAG AA 标准(4.5:1)
- **建议**:使用 #6B7280 或深色背景
- **预估时间**:5min
...(省略后续)
用 Claude Code 做持续设计评审
设计评审不应该是一次性事件。把它集成到日常流程:
方式 1:每次改原型后自动评审
> 每次我让你改 prototype.html 后,自动跑一遍设计规范检查。
> 如果有新的不符合项,先提示我再改代码。
方式 2:用 Hook 做 Git 提交前检查
在 .claude/settings.json 中添加 hook,提交涉及设计文件时自动评审:
{
"hooks": {
"PreCommit": [
{
"matcher": "design/**",
"command": "claude '检查改动是否违反设计规范,如果有给出警告'"
}
]
}
}
常见问题
Claude Code 能替代设计师做评审吗?
不能。Claude Code 擅长的是机械性检查:一致性、规范遵守、逻辑漏洞。它替代不了设计师的判断力——"这个设计好不好看"、"这个交互是否直觉"、"这个方案的取舍是否合理"——这些仍然是人的判断。
把它理解为设计师的助理:它帮你干排查性工作,你干决策性工作。
原型太简单,检查没意义?
越简单的原型越该检查。复杂的正式产品有设计系统框架兜底,一致性反而不容易出问题。原型阶段一致性容易失控——快速迭代中不经意地用了不同颜色、不同间距、不同交互模式。
无障碍检查需要多深入?
原型阶段做到 WCAG A 级别就够:语义化标签、键盘可达、颜色对比度、表单 label。AA/AAA 级别在正式实现时再细查。
下一章: 从设计到代码 —— 原型通过评审后,怎么高质量地把它变成前端代码?