从「读完」到「用上」：把 UI 设计圣经《Refactoring UI》做成随叫随到的 Skill
1. 从「读完」到「用上」：把 UI 设计圣经《Refactoring UI》做成随叫随到的 Skill
[!abstract] 速览
- 这两天重读《Refactoring UI》，收获不小。
- 思来想去，做成 Skill 应该是个可行的出路。
- 这五样是项目的设计底座，在后续的页面开发、迭代时，可以作为约束规范，确保 AI 设计工具往「正确」的方向跑。
- 覆盖矩阵打满 151/151 时，很容易会觉得这个 Skill 已经做完了。
- 这个 Skill 不是干这事儿的，它更像是随身带的一本规则书，外加一个不看脸、只认规则号的评审员，管「对不对」，不管「好不好看」。
- 只要它也满足「规则型、可验证」这两条，都值得试试看做成类似的东西。
之前我写过一篇文章，介绍过一些基本的 UI 设计规则，引入了“人人都是 UI 设计师”的理念。
10月3日
互联网时代，大家都在说人人都是产品经理，但实现一个产品，依然需要一个技术团队。 十几年过去了，LLM 和 AI 编程工具消除了这个壁垒，每个人都能做产品，但默认 UI 丑陋依旧是硬伤。 我从《Refactoring UI》书中精选了 20 条设计军规，希望可以启发你做出非常漂亮的产品。
我在文章中也写到，这些规则来源于《Refactoring UI》这本书。这本书由 Tailwind CSS 的创始人 Adam Wathan 和资深设计师 Steve Schoger 共同撰写，专门教没有设计背景的开发者如何通过可落地的实战技巧做出专业级的用户界面，**在前端开发与 UI 设计圈被广泛誉为“UI 设计圣经”。**在上篇文章最后，我介绍过有人基于这本书做了个 Skill，这次推荐给这个 Skill 带来了 400+ 的 star，作者也感叹，幸亏我之前推荐给了大家，不然这么好的东西还躲在角落吃灰呢。
GitHub 上 400+ star 啦
最近做产品的过程中，发现自己非常密集在使用 refactoring-ui-skill，并且做出来的产品我也觉得很舒服，说明这个 Skill 对非专业人士做产品是真的有帮助的。
几乎每次有界面改动，我都会用这个 Skill 来把关
原作者其实在墨问上写了一篇长文，介绍了这个 Skill 的制作过程，我觉得读来很有启发。在征得原作者同意的情况下，我把这篇介绍文章转载到我的 X 账号，希望能够帮助到正在阅读的你。最后，如果有兴趣，去 GitHub 点上一个 star，权当支持。
[
GitHub - edisonmbli/refactoring-ui-skill: Unofficial Claude Skill derived from the book Refactoring…
](https://github.com/edisonmbli/refactoring-ui-skill)
以下是墨问上的创作者老李的原文。
知识这东西，读过不记得用，等于没学。在需要的时候能随手翻出、用上，才是关键。
1.1. 读过和用上，这么近那么远
这两天重读《Refactoring UI》，收获不小。可搞笑的是，这本书我明明去年才读过，这次重读还是经常会出现恍然大悟的情况，像是第一次看到的 “新知识” 一样，给我自己也整无语了😳
[!note] 读过的书，为什么记不住
书里面有很多偏实操建议的细节，我都记不住了。这说明，当时读这本书的时候，它只是轻轻滑过我的脑袋，并没有真正内化为自己的知识。但是啊，「读书一遍其义自见」这个事情本来就挺难的，再者我又不是设计背景出身，这些有用的知识，怎样才能真正为我所用呢？
思来想去，做成 Skill 应该是个可行的出路。把它作为知识库挂载到 Agent 上，即便有时候我想不起来某个知识点了，起码它能跳出来给我提醒呀，甚至直接动手把活干了！于是花了点时间，把这本书做成了一个 Skill，这个过程我感觉有一定的通用性，就作为笔记记录下来了
Norske Lov… Skill ?
1.2. 动手前先判断：是否真值得做成 Skill ？
Claude 官方有一份专门的文档（详见 Skill 设计最佳实践文档），里面提了一个思路是「评估驱动」，具体说就是别在脑子里空想一套 Skill，建议先挑两三个真实场景，拿 Claude 去跑一遍，看它在哪儿卡住，再照着那些具体的坑决定要不要做、做成什么样的。适合封装成 Skill 的东西，官方给的范围看似挺宽：程序化的流程知识、组织背景、领域专业知识、带代码带指令的复杂工作流 等等。Refactoring-UI 这本书算是落在「领域专业知识」这个范畴里。
但这套框架本身是挺宽泛的，没有给出细节规范，也没有给出一条明确的反面清单说「什么时候别做」。真要落到某一本书、某一份文档能否做成 Skill，还是得自己思考判断。经过一顿折腾，我觉得能让「评估驱动」这件事成立的，好像有两点。
第一点，这本书是规则型的，而不是灵感驱动 。做个不恰当的比喻，规则型像菜谱，一步一步来，调料放多少都写清楚了；灵感型更像「多放点爱」，没法量化，全凭感觉。而这本书翻开随便一页，都是「症状 → 机制 → 做法 → 数值」这个套路。比如它讲间距阶，没说「留点呼吸感」这种虚话，直接给了可量化的标准：往上加一档，数值至少要比上一档大 25%，差距小了人眼根本分不出来。这条可以直接写成一行判断：下一个值够不够上一个值的 1.25 倍，够就是够，不够就是不够，没有中间地带。如果换成一本讲设计品味的书，再好也没法这么处理，因为都不知道该拿什么用例去测它。
第二点，它自带可验证的输出 。间距阶、字号阶、色阶生成算法，都是确定性的计算，同样的输入，永远出同样的结果。这意味着有一部分活可以直接甩给脚本，不用依赖模型状态好不好、「感觉」对不对。
1.3. 构建过程记录
1.3.1. 先把 PDF 变成一座能自由探索的知识库
把这本书变成 Skill 的第一步，是「知识提取」：我手上的是 PDF 版本，要把整本 PDF 喂进去，让它转成 markdown，图片单独存成链接。
第一版的效果其实不太行。页码、书名、每章的标题，反反复复出现在正文里，跟真正的内容混在一起，这样会影响后续环节的模型产出，因为它分不清哪些是版式噪音，哪些是要吃进去的知识。
处理起来倒也不复杂，就是自己先把模型的输出过一遍，识别到问题后，再把共性问题提炼成一句清楚的描述，配上1～2 张 badcase 截图丢回去。这个动作某种意义上也是 Reflection 的一种延伸：检查产出 → 定位问题 → 及时纠正，只是人工介入替换了纯模型自醒。
第二版基本就可用了，一份完整的 md 文件，章节已经按主题切好。图片也从 PDF 里单独提取出来，存进同目录下的 images/，正文里需要用图的地方用链接关联回去。这样模型理解一条规则时，能连着看文字和配图，按图索骥，而不是干巴巴地读一段脱离图示的描述。
这一步做完，我们就拿到一个轻量级的「知识库」，模型能在它的基础上进行自由查阅、按章节按主题索引。后面所有的工作，也都是在这个地基上盖起来的。
[!tip] 不一定要上 RAG
这套"严格切分的文本结构 + markdown + 索引"的轻量做法，在企业知识库、经验沉淀的场景也能复用，很多时候也不一定非得上 RAG 这么重的武器。
1.3.2. 提炼核心要点：怎么不丢失重要内容、不空喊口号
如何确保书中大量的观点/实践Tips「不丢失」，是下一个要解决的问题。动笔之前，把整本书拆到比较细的颗粒度：50 条主规则、101 个子要点，逐条编号，落成一张表，标注每条归属哪个章节、有没有硬数值、有没有对应的 Tailwind 写法。后面每写完一个章节的 reference 文档，就回来对着表逐条打勾。
这样做起来费力不讨好，但前期花点时间把细节抠到位，还是有价值的。譬如，书的目录只暴露了 92 个子要点，另外 9 条只写在正文段落里，比如「三种文字颜色」「两种字重」「三级按钮的三种处理」，这类藏在段落里的具体规定，在产出 reference 细节时容易被漏掉，因此先把每个要点都单独编号、整理成列表，后面就不会被含糊带过了。
「不丢失」解决后，「不空喊」就是另一件事。如果每条规则只留一句结论，模型在陌生场景里会乱套。举个例子，书里说彩色背景上别用灰字。如果只写这一句，模型会以为问题出在「灰」这个颜色本身。真正的机制是对比度降下来了，灰字在白底上管用，恰好是因为它往背景色靠近、对比度足够低；换到蓝底，灰和蓝在对比度上没有天然联系，问题立刻暴露。只有讲清楚这层机制，模型才会知道正确做法是取背景色的色相、调饱和度和明度，而不是随便找个灰色去套。
所以我把每条规则最后定成六段式：规则 → 为什么 → 怎么做 → 具体数值 → Tailwind 写法 → 失败长什么样 。现在的模型已经足够聪明了，给它一句规则，虽然它也能照虎画猫，但给出的很可能不是最合适的解法；如果能进一步给它更多，譬如把背后的机制和边界条件等等也作为上下文输入进去，它大概率能作更深刻的思考和推演。「为什么」和「失败长什么样」这两段，就是把一条规则从「背下来的知识」变成「能推理的判据」的关键。
[!important] 别把规则压成一句口号
把书压缩成一段更短的摘要不难，关键是要给每一条观点留出空间，让模型能根据实际场景走一遍逻辑推演，而不是只背下一句空喊的口号。
1.3.3. 设计渐进式加载：按需索取，每次只让模型看最关键的
Refactoring-UI 虽然是一本小书，但其实内容也不算少了，50 条主设计规则、还有很多的落地细节，十几份引用文件加起来有四千多行。如果把这些一股脑都塞进上下文，虽然也能装下，但会带来很多副作用 - 又慢、又占地方，注意力还会被稀释。模型一次要同时兼顾七八件事，判断往往容易变粗糙。
所以设计成三层：
| 层 | 放什么 | 规模与加载方式 |
|---|---|---|
| 1. 入口文件 | 只放路由规则和一组通用规范（比如「层级优先于装饰」「任何取值都要来自既定的阶」），不放任何章节细节 | 控制在 400 行以内 |
| 2. 引用文件 | 十几份，按主题拆开 | 按需加载，用到哪个视角才读哪个 |
| 3. 脚本和模板 | 放最底层 | 需要算色阶、查对比度的时候才调 |
这套三层设计，其实是渐进式加载（progressive disclosure） 的实践，符合 Claude 官方给 Skill 设计推荐的做法。它在内容颗粒度和高效加载使用之间拿平衡，以具体的设计任务为例：如果只是想调一个页面的排版和布局，那根本用不上字体相关的引用材料，不用为了「保险」把用不上的内容也读一遍，这样做更精准、也更省时间。
而在做全面审查时，七个视角的顺序也不能乱来：层级 → 间距 → 排版 → 色彩 → 深度 → 图像 → 点睛细节 。这个顺序背后是有因果关系的，层级没理顺，「间距是否合理」这件事的判断标准会跟着变；间距一旦调整到位，「这里要不要加一条边框」这个问题往往自己就没了。顺序如果搞错，前面下的结论很容易被后面的调整推翻，等于白忙一轮。
Skill Index
1.4. 搭建评测：写完不等于能用
覆盖矩阵打满 151/151 时，很容易会觉得这个 Skill 已经做完了。但长征路还没走完呢，要点覆盖完整只证明「写全了」，不代表「长期稳定可用」
这就牵扯到 Evaluations，为此我加了一组测试集，专门用来检查 Skill 唤醒、以及在特定的 UI 问题场景下它是否能稳定地捕捉到、并给出针对性的优化建议 。具体来说，是做了几个虚构的界面，比如一个叫 Lumen 的产品，每个页面预埋了已知的 UI 问题，然后拿这几个界面在干净的上下文里跑一遍 Skill 走查，再对照事先写好的答案进行打分
每道题配三档标签：
| 标签 | 规则 |
|---|---|
| must | 必须抓到的问题，漏一条，这题就算不过 |
| should | 允许漏，只作为参考，不计入及格线 |
| forbidden | 不该报却报了，同样算不过 |
must 全中、forbidden 为零，所有题都过，才算这一轮真的过关。should 不进门槛，如果把门槛降成「大部分过了就行」，等于承认标准可以随便改，这套测试集也就没什么意义了。
[!warning] 评测只是兜底护栏
这里需要说明的是，跑完这轮测试，能确认的只是「这套规则在当前测过的这几个场景里是可靠的」。但 Skill 要适配的场景其实是动态多变的，书里没覆盖到的新情况也会持续冒出来，因此 Evaluation 也只是兜底护栏。而持续打磨 Skill 这件事大概率是没有终点的，得跟着实际用出来的反馈继续往前迭代。
1/2 Evaluations
1.5. 它能做什么：几个用得上的场景
现在市面上一堆 AI 设计工具在干的事，可以粗暴归类为「生成」，你说一句要什么样的界面，它给你吐一个出来。这个 Skill 不是干这事儿的，它更像是随身带的一本规则书，外加一个不看脸、只认规则号的评审员，管「对不对」，不管「好不好看」。跟生成工具并不冲突（甚至挺互补的），一个负责造，一个负责挑毛病。
最常用的，是这三种场景：
1.5.1. 审查一个已有页面
正常说一句「帮我看看这个设置页，总觉得哪里不对但说不上来」就行。它会先摸清技术栈（这样渲染出来的东西才准），桌面和移动两个宽度都看一遍，再按 Refactoring-UI 里的知识点，一个视角接一个视角地扫，层级、间距、排版、色彩……交回来的每一条都得对上规则号：
对不上规则号的，一律不算问题，它不会提。这也是它跟「再让 AI 瞅一眼」的主要区别，这个 Skill 的工作依赖于具体条文的评审，每一条问题识别&建议都要有章可循。
另外，针对页面的某一个维度进行审查也是ok 的，譬如字体、排版，渐进式加载确保具体问题只查证具体的 reference 文档。
1.5.2. 从零建一套设计系统
它也可以在项目启动前，先跟你聊两句：产品类型、想要的调性（严肃还是活泼、经典还是现代、密集还是宽松）、用的什么技术栈，然后一口气给五样东西：
- Design Tokens 的 JSON
- 对应的 Tailwind 主题
- 框架无关的 CSS 变量
- 一份写给人看的说明书
- 能直接甩给同事看的可视化预览页
这五样是项目的设计底座，在后续的页面开发、迭代时，可以作为约束规范，确保 AI 设计工具往「正确」的方向跑。
1.5.3. 问一个为什么
它也是学习设计基础知识的好帮手。比如「为什么这张卡片的阴影这么重，看着有点廉价」。它这时候只会加载一份对应的引用文件，把机制掰开讲给你听：阴影表达的是层级高低，不是这个元素重不重要，一张本该平铺在页面上的卡片给了重阴影，视觉上就像浮在半空，跟旁边元素的关系全乱了。
这个场景看着很小，但对于我这个没有很强设计背景的产品经理而言，还是挺有帮助的。一个页面为什么好、为什么不好，通过多次反复的咨询和讨论，也许慢慢地就能把一些基础的设计知识植入我的意识中，从而提高下限，不至于每次看着页面，脑袋里却是一片空白。
1.6. 把书读薄，不止是这一本书
以前人们常说把书读薄 ，是把书浓缩成几条自己能记得住的心法，塞进脑子里揣着。今天多了一种做法，还可以把更完整的内容细节，做成一份模型能随时能翻的 Skill，需要派上用场的那一刻，它就在场。
[!success] 换一本书也一样
这次做的只是一本设计书，换成别的，譬如某个领域的操作手册、一份反复踩过坑总结出来的经验文档、团队沉淀下来但没人愿意再翻的 wiki，道理应该是相通的。只要它也满足「规则型、可验证」这两条，都值得试试看做成类似的东西。
Skill 已经开源在 GitHub：refactoring-ui-skill。有条件的朋友，原书也强烈建议买一本 https://www.refactoringui.com/，这个 Skill 替代不了你去认真读原书，只是让读过的东西，在需要的时候还在场。
整理完文章，我突然想起来，我可以在全局规则中，让这个 Skill 成为以后修改界面必须使用的Skill呀，于是让 ChatGPT 加上：
