改版不是重写：redesign-skill 的审计清单与七步修复优先级

2026-08-09

本文所有仓库信息核对日为 2026-08-09，以上游仓库最新内容为准。

taste-skill 里绝大多数 skill 默认你在从零写一个页面。redesign-skill（install name redesign-existing-projects，178 行）不一样：它默认你已经有一套跑着的代码，而你不能推倒重来。这个前提一变，规则的性质也跟着变了——它不再是”该怎么做”，而是”先看什么、后改什么、哪些绝对别碰”。

先把两个名字分清楚：文件夹叫 redesign-skill，装的时候要填的 install name 是 redesign-existing-projects。这个仓库里文件夹名与 install name 不一致的情况相当普遍，我们另有一篇专门做对照表。

一、三步工作方式，重点在第三步那半句

它的 description 写得很直白：把既有网站和应用升级到高级质量，审计当前设计、识别通用 AI 模式、在不破坏功能的前提下应用高端设计标准，适配任何 CSS 框架或原生 CSS。

工作方式是三步：

Scan：读代码库，识别框架、样式方式（Tailwind、原生 CSS、styled-components）、当前的设计模式
Diagnose：跑审计清单，列出发现的每一个通用模式、弱点和缺失状态
Fix：配合既有技术栈做定点升级

第三步后面还跟着半句，是整份文件里最该记住的一句：不要从零重写，改进已有的。

这半句决定了这份 skill 的用法边界。你如果本来就打算把项目推翻重做，那该用的是默认的 taste-skill（install name design-taste-frontend，当前默认版本是 v2，1206 行）那一套完整设计流程，而不是这份。反过来，如果你的处境是”页面能用，但一眼就能看出是 AI 生成的”，改版又不能动业务逻辑，那 178 行这份才是对着你的问题写的。

二、审计清单是九类，不是一张流水账

redesign-skill 的主体是一份很长的设计审计清单，按类目组织，每一条的写法都是”发现这个问题就修它”。九个类目分别是：

类目	它在管什么
排版	字体选择、字重层级、行宽、字距、孤字
颜色与表面	纯黑背景、强调色数量、灰色家族、阴影、纹理
布局	对称、卡片行、视口单位、容器宽度、对齐节奏
交互与状态	悬停、按压、聚焦环、加载态、空态、错误态
内容	假人名、假整数、占位公司名、文案陈词滥调
组件模式	通用卡片、按钮组合、徽章、手风琴、定价表、模态
图标	图标库选择、隐喻、描边一致性、favicon
代码质量	div 汤、内联样式、硬编码宽度、alt 文本、z-index、导入幻觉
战略性遗漏	法务链接、返回路径、404、表单校验、skip to content

这张表本身没什么信息量，有信息量的是怎么读每一条。清单里的条目大致分三种性质，混在一起排，你得自己分开：

第一种是可机械核验的硬项。 比如”图片缺 alt 文本”，原文的措辞是绝不给有意义的图片留 alt="" 或 alt="image"；比如”缺聚焦环”，原文专门标了这是无障碍要求、不是可选项；比如 “skip to content” 链接，原文标的是键盘用户必需；再比如导入幻觉——核实每个 import 真的存在于 package.json 或项目依赖里。这几条不涉及审美，谁来审结论都一样，而且能在自己的构建链或 review 流程里落成检查。

第二种是有明确技术理由的项。 典型是全屏区块用 height: 100vh，原文给的替换是 min-height: 100dvh，理由写的是防移动端浏览器布局跳动、iOS Safari 视口 bug。这类条目你能顺着理由判断它在你的项目里成不成立——如果你的页面根本没有全屏区块，跳过就是了。

第三种才是纯审美偏好。 比如”所有元素统一圆角”要求做出变化、“仪表盘总是左侧栏”建议试试顶部导航或浮动命令菜单。这些是这份文件的立场，不是普适规范。

清单里有三条被原文自己点名为”AI 指纹”，值得单独拎出来：紫/蓝的 “AI 渐变” 审美被称作最常见的 AI 设计指纹，替换方案是中性底加单个考究强调色；三等宽卡片作功能行被称作最通用的 AI 布局，替换方案是 2 列锯齿、非对称网格、横向滚动或砌体；只用 Lucide 或 Feather 图标被称作**“默认”的 AI 图标选择**，建议换 Phosphor、Heroicons 或自定义集。如果你只想从这份 178 行里挑三条改，这三条是它自己标出来的高频项。

三、七步修复优先级：顺序本身就是判断依据

清单末尾给了一个 Fix Priority，原文的排序理由是”按此顺序改，视觉影响最大、风险最小”：

换字体（原文：瞬时提升最大、风险最低）
配色清理（去掉冲突或过饱和的颜色）
悬停与激活态（让界面活起来）
布局与间距（正确的网格、max-width、一致内边距）
替换通用组件（把陈词滥调换成现代替代）
加载 / 空 / 错误态（让它感觉做完了）
打磨排版刻度与间距（高级感的最后一笔）

这个排序对做改版的人比清单本身更有用，因为它同时是一条风险梯度。前三步动的基本是样式层：换字体栈、删掉一个多余的强调色、给按钮补上悬停和 :active 反馈——这些改动几乎不碰 DOM 结构，出问题也容易回滚。第 4 步开始动布局，第 5 步开始换组件，这两步是真会改结构、可能碰到业务逻辑的地方。第 6 步补加载、空、错误三种状态，性质又不同了：那不是”改”，是”补没写的东西”，工作量和前面几步不是一个量级。

所以拿这份优先级去排你自己的迭代时，有几个判断可以直接下：

如果这次改版只有一两天窗口，做完前三步就停，第 4 步之后另开一轮。前三步的收益比在原文的排序里就是最高的。
如果你的项目有 UI 回归测试或视觉快照，第 4、5 步才有做的底气；没有的话，这两步得配合原文 Rules 里那句”每次改动后测试”人工过一遍。
第 6 步的空状态、错误态往往牵到接口层。原文对错误态的要求是加清晰的内联错误信息，并明确写了不要用 window.alert()；对加载态的要求是把通用圆形 spinner 换成匹配布局形状的骨架屏。这两件事都不是纯前端样式改动，别混进”顺手改一下”的批次里。
第 7 步是收尾打磨，它排在最后不是因为不重要，而是因为在布局和组件定下来之前调排版刻度，前面一动就得重调。

四、哪些条目该走 override

这份清单是有立场的，而它的立场未必等于你项目的约束。有两处特别需要你自己判断。

一是 Inter。 redesign-skill 的排版类目里，“浏览器默认字体或到处 Inter”被当成要修的问题，建议换成有性格的字体：Geist、Outfit、Cabinet Grotesk、Satoshi。但同一个仓库里对 Inter 的口径并不统一：gpt-tasteskill（install name gpt-taste）的排版栈明写 NEVER Inter；brutalist-skill（install name industrial-brutalist-ui）的宏观排版最佳字体里列了 Inter (Extra Bold/Black)；而默认的 taste-skill v2 §4.1 的说法是 Inter “不建议作默认”，但留了 override 路径——用户明确要中性 / Linear 风格时，或者公共部门、无障碍优先的站点，可以接受。三处口径不同，这是仓库当前状态下可核实的客观事实，我们不推断哪个更对。你要做的判断很清楚：如果你的站点属于 v2 §4.1 点名的那两种情况，“到处 Inter”就不是一条需要修的审计项。

二是深色区块那条。 原文说浅色页面里随机出现的深色区块（或反过来）看起来像复制粘贴事故，要么全面承诺深色模式，要么保持一致背景调；需要对比就用同色板更深的一档，不要在奶油色页面中段突然跳到 #111。这条在营销页上很成立，但如果你的深色区块是产品里一个有明确语义的分区（比如一个终端 / 日志视图），它就不是”事故”。清单没法替你区分这两种情况，你得自己区分。

五、Rules 那几条才是改版的闸门

比审计清单更容易被跳过、但对改版风险影响更大的，是文件末尾的 Rules：

配合既有技术栈，不要迁移框架或样式库
不要破坏既有功能，每次改动后测试
引入任何新库前先看项目依赖文件
项目用 Tailwind 就**先查版本（v3 还是 v4）**再改配置
项目没框架就用原生 CSS
改动要可评审、聚焦，小而定向的改进优于大重写

第四条尤其实在。Tailwind v3 与 v4 的配置方式不一样，让一个 agent 在没确认版本的情况下动配置，是这类改版任务里很容易踩的一脚。这条规则的作用是把”先确认版本”变成动手前的固定动作。

最后一条则是整份 skill 的收口：小而定向的改进优于大重写。它和三步工作方式里”不要从零重写”是同一件事的两次强调。

六、和 taste-skill v2 §11 的分工

需要知道的是，改版这件事在这个仓库里出现了两处。除了独立的 redesign-skill，默认的 taste-skill v2 也新增了 §11 Redesign Protocol，据 CHANGELOG 记载，那一节包含模式检测（Greenfield / Preserve / Overhaul）、动手前先审计、按优先级排序的现代化杠杆，以及一份”绝不悄悄改动”的东西：URL 结构、导航标签、表单字段名、品牌字标、法务文案。

那份”绝不悄悄改动”清单是 redesign-skill 的审计清单里没有的一层保护，性质也不一样——审计清单管的是”该改什么”，这份管的是”改版时哪些东西不许顺手动”。做真实项目的改版，后者的价值往往不比前者低：改一个表单字段名可能打掉后端对接，动一次 URL 结构可能打掉外链和收录。

两处并存是仓库当前的状态，我们只陈述这个事实，不推断分工意图。v2 的完整章节结构我们另有一篇专门讲。

七、最后回到规则的性质

这一点每篇都要说一次，因为它决定了你该抱什么期待：redesign-skill 就是一份 178 行的 Markdown，它本身不包含任何可执行的东西——没有 lint 规则、没有脚本，不会有任何程序替你在项目里跑这份清单。它是写给模型看的提示词约束，作用是让 agent 在改你的代码时倾向于看这些地方、按这个顺序动手。

所以正确的用法不是”装上它然后交给 agent”，而是把它当成一份改版评审清单：让模型按它扫一遍产出诊断，人来筛哪些条目在你的项目里成立、哪些走 override，再决定这一轮做到第几步。那些可机械核验的硬项——alt 文本、聚焦环、导入是否真实存在——想要确定性，还是得落到你自己的构建链或 review 流程里。

顺带一提，默认 skill 当前自标 v2 (experimental)，CHANGELOG 原文写着 This is a pre-release，仍在迭代。采纳这一套的时候，按这个前提评估就对了。

本文依据 taste-skill 官方仓库（github.com/Leonxlnx/taste-skill）的 README、CHANGELOG、 skills/ 下的 SKILL.md 与 .claude-plugin/ 清单整理，核对日 2026-08-09。本文内容为仓库文档口径，我们没有安装或运行过其中任何一个 skill，文中所有规则均为写给模型的提示词约束，不构成对输出结果的保证。 skill 内容随上游更新而变动，默认 skill 当前自标为 v2 (experimental) 且仍在迭代，请以仓库最新内容为准。