改版与评审流程
改版和新建是两件事。新建可以从零决定一切；改版只能在既有约束里做局部最优。
改版失败只有两种方式：改得不够（没解决问题）和改得太多（用户不敢合、或者合了别的地方坏了）。这个流程同时防这两种。
阶段 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（手机）
抓三件事：
- 首屏在三个宽度下各占几行标题、能不能看懂是干嘛的。
- 页面节奏：把 section 缩略图排成一列，看是否每屏都一样。
- 状态覆盖：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 · 修复（最小改动）
铁律
- 按严重度顺序改，一次一个主题。 不要「顺手」改别的。
- 改动要可单独回滚。 一个主题一组改动，方便 bisect。
- 不动依赖、不动架构、不动构建配置，除非用户明确要求。
- 不引入新的颜色/字号/间距值，除非同时在令牌里登记。
- 不确定的一律不改，列进「需要确认」。
- 每完成一个主题，跑一次构建/类型检查，不要攒到最后。
优先动「零成本高收益」的
| 手段 | 成本 | 收益 |
|---|---|---|
| 改文案（空话 → 具体） | 极低 | 极高 |
| 删渐变、重阴影、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 条问题把客户压垮。
「不用重做」这四个字最值钱。 它同时传达了专业度和诚意。
