Zack Redesign Audit

---
name: zack-redesign-audit
description: "改版与评审的完整流程：读代码 → 出诊断表 → 最小化定点修复 → 三宽度验收 → 交付报告。包含只读评审模式、改动范围控制、回归检查和面向客户的诊断话术。当要改一个已存在的网站/项目、评审现有界面、或交付前需要自检时使用。"
license: MIT
metadata:
  author: Zack
  homepage: https://github.com/yckonnnnn/zack-design-skills
  version: "1.0.0"
---

# 改版与评审流程

改版和新建是两件事。新建可以从零决定一切；改版**只能在既有约束里做局部最优**。

改版失败只有两种方式：**改得不够**（没解决问题）和**改得太多**（用户不敢合、或者合了别的地方坏了）。这个流程同时防这两种。

---

## 阶段 0 · 定范围（不写代码）

动手前先说清三件事，写下来，让用户确认：

```
1. 我要改哪几个文件 / 哪几屏：<列出具体路径或 section>
2. 我不改什么：<动效、架构、依赖、后端、i18n…>
3. 我假设的成功标准：<例如「首屏 1440px 下标题 ≤ 2 行，价格页出现真实数字」>
```

**这一步是整条流程里最省钱的一步。** 改版最大的成本不是改错，是改了用户没让你改的地方，然后花更多时间解释和回滚。

---

## 阶段 1 · 扫描（只读）

### 1.1 技术环境

```
框架与版本        <Next / Vue / Svelte / 原生 / 小程序…>
样式方案          <Tailwind / CSS Modules / styled-components / 原生 CSS / SCSS>
设计令牌          是否存在？在哪定义？（tokens.css / tailwind.config / theme.ts）
组件库           自建 / shadcn / Ant / MUI / Element…
响应式策略        断点、容器宽度、流体单位
字体加载         自托管 / CDN / 系统栈
已有的动效方案    CSS / Framer Motion / GSAP / 无
```

### 1.2 视觉现状

按顺序看，每个宽度都看：

- 1440px（桌面主场景）
- 1024px（笔记本）
- 390px（手机）

抓三件事：

1. **首屏**在三个宽度下各占几行标题、能不能看懂是干嘛的。
2. **页面节奏**：把 section 缩略图排成一列，看是否每屏都一样。
3. **状态覆盖**：hover / focus / disabled / loading / empty / error 各存在几个。

### 1.3 令牌审计

```
实际用到的颜色值 → 有几个？（> 8 个游离色值 = 没有色彩系统）
实际用到的字号   → 有几个？（> 6 个 = 没有字号系统）
实际用到的间距   → 有几个不在尺度里？
```

一次性把游离值列出来，这是后面「建系统」的输入。

---

## 阶段 2 · 诊断（出表，不改）

用这张表输出，**不改任何文件**：

```
## 诊断

| 位置 | 问题 | 依据 | 严重度 | 预计改动量 |
|---|---|---|---|---|
| src/app/page.tsx:42 首屏 | 渐变文字标题 | anti-ai-look B2 | P0 | 1 行 |
| src/app/page.tsx:60 | 三张等宽卡片 | layout C3 | P1 | 1 个区块 |
| components/Pricing.tsx:12 | 价格全是「—」 | hero-and-pricing 2.1 | P0 | 需客户提供价格 |
| ... |

## 建议的修复顺序
1. （P0，零成本）文案与默认值清理
2. （P0）首屏结构
3. （P1）字号/色彩系统
4. （P1）节奏与版式形式
5. （P2）动效与状态

## 不建议改的
<明确写出：例如「整站换框架收益远小于风险」「这套动效库没问题，问题在时长参数」>

## 需要客户决定的事
<例如价格数字、真实客户名、是否保留某个功能入口>
```

**严重度定义**

| 级别 | 含义 | 判断标准 |
|---|---|---|
| **P0** | 直接劝退 | 访客 3 秒内会判定「这是个模板站」或「看不出是干嘛的」 |
| **P1** | 明显廉价 | 单看能接受，叠加起来就露馅 |
| **P2** | 可以更好 | 打磨项 |

**诊断里必须包含「不建议改的」。** 只会挑错的评审没有可信度；能说出「这里别动，动了不划算」的人才是专业的。

---

## 阶段 3 · 修复（最小改动）

### 铁律

1. **按严重度顺序改，一次一个主题。** 不要「顺手」改别的。
2. **改动要可单独回滚。** 一个主题一组改动，方便 bisect。
3. **不动依赖、不动架构、不动构建配置**，除非用户明确要求。
4. **不引入新的颜色/字号/间距值**，除非同时在令牌里登记。
5. **不确定的一律不改，列进「需要确认」。**
6. 每完成一个主题，跑一次构建/类型检查，不要攒到最后。

### 优先动「零成本高收益」的

| 手段 | 成本 | 收益 |
|---|---|---|
| 改文案（空话 → 具体） | 极低 | 极高 |
| 删渐变、重阴影、emoji、元标签 | 极低 | 高 |
| 首屏标题容器收窄、断行 | 低 | 高 |
| 换掉默认字体栈 | 低 | 高 |
| 建字号/色阶令牌并替换游离值 | 中 | 高 |
| 重排 section 节奏与版式形式 | 中高 | 高 |
| 补状态与 `:focus-visible` | 中 | 中高 |
| 调动效时长与曲线 | 低 | 中 |
| 重写整个 section 结构 | 高 | 视情况 |

**先做上面四行。** 它们占 20% 的工作量，出 60% 的效果。

---

## 阶段 4 · 验收

### 4.1 三宽度截图对比

```
同一页面、同一宽度，改前 vs 改后
1440 / 1024 / 390
首屏 + 至少 3 个关键 section
```

### 4.2 回归清单

- [ ] 原有功能还能用吗？（表单、导航、链接、搜索）
- [ ] 构建和类型检查通过吗？
- [ ] 控制台有没有新增报错/警告？
- [ ] 键盘 Tab 一遍，焦点顺序合理吗？看得见吗？
- [ ] 390px 下有没有横向滚动？
- [ ] 深色/浅色主题（如果有）都正常吗？
- [ ] `prefers-reduced-motion` 下内容完整吗？
- [ ] 有没有把用户没让改的地方也改了？

### 4.3 量化改动

```
文件数    N 个
净行数    +X / -Y
新增令牌  Z 个
游离色值  从 A 个降到 B 个
字号种类  从 C 个降到 D 个
```

**「净行数减少」通常是好改版的标志。** 因为它意味着删默认值多于加新东西。

---

## 阶段 5 · 交付报告

```
## 改了什么
| 文件:行 | 改前 | 改后 | 依据 |

## 怎么验证的
<实际跑的命令 + 实际看过的截图说明>

## 没改的 / 没验证的
<诚实列出，包含原因>

## 需要你决定的事
<价格数字、真实客户名等>
```

**不要写「我提升了整体视觉体验」这种交付语。** 要么给出可指认的改动，要么说没改。

---

## 只读评审模式

如果用户只要评审、不要改代码：

- **不要写任何文件。** 一个字符都不写。
- 输出顺序：**先给结论（通过 / 有问题 / 未通过），再给证据表，最后给建议。**
- 先看首屏（3 秒判断），再看价格页，最后看其余。
- 结论必须能被表格里的某一行支持。
- 明确写出「我看到了什么」和「我是基于什么判断的」——例如「我按 1440px 截图判断，390px 未验证」。
- 每一条建议给出：位置、问题、改法、成本。
- 不要一次给 40 条建议。**按 ROI 排序取前 10 条**，其余归入「次要」。

---

## 面向客户的诊断话术

改版服务的价值往往不在「改得好」，在「说得清」。诊断结论给客户时：

**要做**：具体到某一屏、给出理由、给出工作量感受。

```
看完了，三个问题：

1. 首屏第一句话是「赋能企业级智能体」，客户看不懂你是干嘛的
2. 导航 11 个栏目，其中 5 个点进去只有一句介绍，属于废栏目
3. 价格页全是「—」，客户到这一步不敢下单

这几个不用重做，改完效果能出一大半。
```

**不要做**：说「整体设计风格不够现代」这类无法指认的话；不要承诺绝对结果（「保证不像 AI」）；不要一次列 20 条问题把客户压垮。

**「不用重做」这四个字最值钱。** 它同时传达了专业度和诚意。