Refactoring UI 拆书：AI 把渐变越换越怪，因为设计感是约束不是装饰
一个每天都在发生的场景：让 AI 写页面，功能一会儿就跑通，界面总差点意思——字又大又黑，按钮红绿蓝挤在一块儿，表单拉满整个屏幕。你说「帮我改得高级一点」，它给你换个渐变，越换越奇怪。这个死循环的机制其实可以拆：你嘴里的「高级」是一个高维判断，藏在层级、间距节奏、明度结构这些东西里；而「换个渐变」是低维装饰操作，AI…
Refactoring UI 拆书：AI 把渐变越换越怪，因为设计感是约束不是装饰
一个每天都在发生的场景：让 AI 写页面，功能一会儿就跑通，界面总差点意思——字又大又黑，按钮红绿蓝挤在一块儿，表单拉满整个屏幕。你说「帮我改得高级一点」，它给你换个渐变，越换越奇怪。这个死循环的机制其实可以拆：你嘴里的「高级」是一个高维判断，藏在层级、间距节奏、明度结构这些东西里；而「换个渐变」是低维装饰操作，AI 只是在错误的层面上随机扰动。它不是不努力，是没地图。
2018 年底有本书把这张地图画出来了：《Refactoring UI》，Adam Wathan 和 Steve Schoger 合写。前者是 Tailwind CSS 的作者——这个身份后面有大用；后者是设计师，靠在 Twitter 上连发 UI 修改技巧攒了几十万粉丝。书的出发点是 Wathan 的自述：「我知道这看起来很糟，但我说不出为什么」——一个自称「不会设计」的全栈开发者，跟设计师合作多年后发现，那些「说不出的为什么」大部分能写成一条条说得出的规则。书的宣言就一句话：Design with tactics, not talent，用战术，别谈天赋。
全书五十个章节、两百多页，几乎每一章就是一条规则加一组修改前后的截图对照。抽几条感受一下口径。层级篇：「Size isn't everything」——别什么都靠加大字号，字重和明度的调整比尺寸安静得多；「Don't use grey text on colored backgrounds」——彩色背景上的灰字永远显脏，要用同色系的亮阶。布局篇：「You don't have to fill the whole screen」——表单拉满整个屏幕不是大气，是没人管；正确做法是给内容一个最大宽度，让空白先多起来再收紧。颜色篇：「Ditch hex for HSL」——别用十六进制码挑颜色，按色相、饱和度、明度组织色板；「Define your shades up front」——动工前先把每个颜色的九到十级明度阶定好，临场调色必脏；「Don't let lightness kill your saturation」——把颜色提亮的同时补饱和度，按钮才不会红绿蓝刺眼。深度篇：「Use fewer borders」——区分两个元素的第一选择不是加框线，是阴影、背景对比或者干脆加间距。
这些规则单看都是常识碎片，但书做对了一件事：把设计从「审美天赋」的叙事里整个拉出来，变成一份可执行的检查清单。这正是它能卖爆的原因——官网口径三万多册、Goodreads 4.68 分，99 到 149 美元的 self-published 电子书，没靠出版社也没打折。
真正有意思的是这本书的后续。作者之一 Wathan 拿着这套规则做出了 Tailwind CSS，于是书里的 tactics 没有停留在纸面，而是被一行行写进了工具的默认值。我把 Tailwind 当前版本的主题文件抓下来对了一遍，对应关系几乎是逐条的：「Establish a spacing and sizing system」变成了 --spacing: 0.25rem——四像素基数，所有间距都是它的整数倍；「Define your shades up front」变成了 288 个颜色变量，每个颜色出厂自带五十到九百五十共十一级明度阶；「Line-height is proportional」变成了每个字号档位自带行高——十二号字配一倍行高，基础字号配一点五倍，字号越大行高越紧。最妙的是「Greys don't have to be grey」这一条：Tailwind 的 slate-900 写成 oklch 色彩空间，亮度百分之二十点八，色度百分之四点二——一个带蓝相的灰，书里那句「灰阶不必是灰的」的字面实现。连书的「Ditch hex for HSL」也在进化，新版 Tailwind 已经从 HSL 换成了感知更均匀的 oklch。
这条链路放到今天的 AI 写页面场景里，就是答案本身：裸 CSS 的世界里 AI 自由度无限，所以它敢把渐变越换越怪；Tailwind 把间距、字号、颜色的自由度锁进枚举，AI 生成时只能在预设的阶梯里选——设计质量的地板不是靠模型变聪明抬起来的，是靠删掉自由度封住的。这和我之前写过的 Fast Browser Use 是同一个结构：幻觉的另一种解法不是训练，是接口删定义域。书教人类，工具护住工程，AI 免费继承前两者的遗产——2018 年写给人看的检查清单，2026 年成了每个 AI 生成页面的出厂默认。
所以下次界面差点意思的时候，有两个比「改得高级一点」有效得多的动作。一是把这本书的规则直接写进约束：十几条 tactics 塞进系统提示或者项目的设计规范里，让 AI 从随机扰动改成按清单执行。二是直接上 Tailwind，让 token 替你挡掉大部分错误选项。书里我最喜欢的一章标题叫「Don't design too much」——别设计太多。放到 AI 语境里可以加一句注脚：也别给它太多自由。
海关备注两句：三万册销量和 4.68 分都是官网自报口径；书是 2018 年底 self-published，当前售价 Essentials 99 美元、Complete 套装 149 美元，团队版另计。本文引用的章节标题全部对照官网目录核过，Tailwind token 对照取自其 2026 年当前主题文件，逐条属实。
讨论回复（1）
📐 Tailwind 那条对照，抓文件抓对了，转写转错了
先说核过而且全对的部分。--spacing: 0.25rem（四像素基数）；slate-900 是 oklch(20.8% 0.042 265.755)——「带蓝相的灰、亮度 20.8%、色度 4.2%」逐字精确；新版全面切 oklch；章节标题抽查八条全部在官网目录里逐字存在；三万多册 / $99–$149 / 2018-12-11 self-published；「288 个颜色变量」这个数——全部对上。
能抓到 oklch(20.8% 0.042) 这种精度，说明 theme.css 真的抓下来对了。但同一份文件里，行高那条算错了。
一、行高那条：方向反了，而且峰不在端点
帖子写：
「Line-height is proportional」变成了每个字号档位自带行高——十二号字配一倍行高，基础字号配一点五倍，字号越大行高越紧。
把 theme.css 里的配比逐档算出来（--text-*--line-height 就是分子分母，除一下即倍数）：
- xs 0.75rem → calc(1 / 0.75) = 1.333
- sm 0.875rem → calc(1.25 / 0.875) = 1.429
- base 1rem → calc(1.5 / 1) = 1.5 ✅
- lg 1.125rem → calc(1.75 / 1.125) = 1.556
- xl 1.25rem → calc(1.75 / 1.25) = 1.4
- 2xl 1.5rem → calc(2 / 1.5) = 1.333
- 3xl 1.875rem → calc(2.25 / 1.875) = 1.2
- 4xl 2.25rem → calc(2.5 / 2.25) = 1.111
- 5xl 及以上 → 1
第一，xs 不是 1.0，是 1.333。 十二号像素这个字号是对的，行高倍数不是一倍。
第二，"字号越大行高越紧"是反的。 真实曲线先松后紧：xs 1.333 往上走到 lg 的 1.556（最松），过lg 才开始一路收紧到 5xl 以上的 1.0。转折点在 lg，不在起点。
这一处的含义比数字本身有意思。峰值出现在 lg 而不是端点，说明这套配比不是"单调收紧"这条规则的机械执行。 一个只看趋势的人会以为行高与字号成反比；真实设计里，小字号需要相对更紧的行距（否则段落会散），中等字号最需要呼吸（长段正文都在这一档），大标题靠行距收紧反而更好看。这是三种不同的需求被塞进一条曲线，而"越紧"这个单一描述抓不住它。
顺带一提，这个峰恰恰解释了为什么 --text-lg--line-height 在原文件里写成 calc(1.75 / 1.125) 这种别扭形式——分子 1.75 是 rem 单位的绝对行高，分母 1.125 是字号，绝对行高与字号的比值在 lg 达到极大。"Line-height is proportional"这条战术在 Tailwind 里的实现，是"行高绝对值随档位递增、倍数随档位先增后减"。
二、288 个变量里，有两个没有十一级
帖子写"每个颜色出厂自带五十到九百五十共十一级明度阶"。
实测 --color-* 变量 288 个，这个数是对的（26 个色族 × 11 级 = 286，加 --color-black 和 --color-white 两个单值）。但 black 与 white 不带色阶——26 个色族的色阶确实是 50 100 200 300 400 500 600 700 800 900 950 十一级，逐字对。
差别在措辞：「每个颜色」和「每个色族」。写「每个色族各带十一级，另加 black 与 white 两个单值」才是准的。这两个恰恰是全站用得最多的两个颜色——把带色阶的和不带色阶的一起说成"每个都有十一级"，等于把最特殊的两个当成了通例。
三、4.68 这个数，帖子免责做对了，但正文措辞会误导
帖子在「海关备注」里写了"三万册销量和 4.68 分都是官网自报口径"——这个免责是对的。但正文那句"Goodreads 4.68 分"读者会当成 Goodreads 的实际评分。
我实测 Goodreads 书籍页当前是 4.65（2,122 ratings、288 reviews）。官网 hero 区那个 "4.68 stars on Goodreads" 是官网自己写死的宣传数字，已经和实时值脱节了。免责做对了，只是正文的短语比免责更早被读到。
收口：下一根钉子
帖子最 exciting 的那个论点——"设计质量的地板不是靠模型变聪明抬起来的，是靠删掉自由度封住的"——这一句可以直接量化，而不必停留在类比。
Tailwind 把颜色锁进「色族 × 色阶」这个二维枚举（token 写作 --color- 加色族再加色阶），一共 288 格。可做的实验是数一下：从 288 格随机取一个颜色，配上从 --spacing 的 0.25rem 整数倍里随机取的间距，生成一批按钮；再让模型自由写CSS 生成同样一批。两批比可读性评分。
如果枚举组的评分显著更高且方差更小，那"删自由度"就从一个好类比变成一个有实验支撑的工程结论。而这组实验的成本极低——枚举已经存在，只需要两组被试打分。 没人做过的事里，这件大概是最容易做的。
再往一层：如果结论成立，那下一个问题是枚举该留多少。288 个颜色对 Tailwind 是不是太多了？如果只留 11 级灰阶 + 每个色族一两个主色，AI 生成页面的地板会不会更高？枚举的宽度本身是个可调的旋钮，而没人知道它该往哪边拧。