样式收敛：一个按钮不要八套 CSS
样式为什么会增殖、怎么分批收进 token，以及哪些差异该留着
本页解决的问题
先给结论「样式收敛：一个按钮不要八套 CSS」要解决的关键问题是什么？
样式为什么会增殖、怎么分批收进 token，以及哪些差异该留着
把品味变成产品可重复的行为。 有用的结果不是一句“我觉得更好”。它应该是一条看得见的规则、一个小例子，以及判断体验何时低于标准的方法。
记录一个前后对比，让别人不用听解释也能看懂质量线。
表面更精致了，却没有减少用户的不确定感。
下面模拟一个真实项目的迭代。每点一次「再加个功能」，就是你开一轮新对话让 AI 做一个页面。注意看它每次是怎么处理按钮的，以及底下四个数字怎么涨。
项目还是空的。点下面的按钮开始迭代。
八轮之后再看这堆按钮，你分不清该改哪个——这就是「散装」的手感。
重复造样式不是模型偷懒，是三个结构性原因叠出来的。看懂原因，才知道该在哪儿设闸。
你的 CSS 不在它眼前
新开一轮对话，上下文里只有你这次给的几个文件。项目里已经有 .btn-primary 这件事，它无从得知，于是按需求现写一个。
新写比读懂旧的便宜
读懂一套现有样式要把相关文件全看一遍，还得担心改了影响别处。新起一个类名零风险、零阅读成本，这是它的最优解，不是你的。
怕改坏，于是并列一份
需要一个带阴影的按钮时，它宁可写 .btn-primary-new 也不改原来那个——改动别人在用的样式属于高风险操作，它选择了安全但会增殖的做法。
三个原因都指向同一件事：它缺一份「我们已经有什么」的清单。把这份清单写进项目规则文件，它每轮都能看见，增殖才会停。这也是第 8 节把环境事实写进 Rule 的同一个道理，只不过这次写进去的是样式资产。
已经乱掉的项目不要指望一把重构收干净。按下面四步走，每一步都能单独停下来验证。
盘点，先只看不改
让 AI 扫全项目的样式，产出一张重复清单：哪几个类在实现同一种控件、散落着多少个颜色值和圆角值。这一步不许动代码，你先看清欠了多少债。
定 token，把魔法数字收成档位
从盘点结果里挑出真正在用的值，定成一小套变量：主色、语义色、圆角两三档、间距四档、控件高度。档位要少，少才守得住。
分批合并，一次一种控件
先按钮，验证；再卡片，验证；再输入框。每批单独提交，出问题能单独回滚。收敛是等价替换，视觉上应该看不出变化——真需要改样子，那是另一个任务。
设闸，防它明天再长出来
把「写新样式前先搜 token 和公共组件，搜到就复用，搜不到才新建并说明搜过什么」写进规则文件。不设这道闸，你三个月后还得再收一遍。
收敛最容易过头的地方是把该有的区别也抹平了。五组真实的样式差异，你判断哪些是手滑攒出来的、哪些是有理由的。
判断该不该合并，只问一句：这个差异叫什么？叫得出名字的留着——「次要按钮」「危险操作」「触摸目标下限」「弹层比卡片高一档」，这些是设计决策，理由写进注释就行。叫不出名字的合掉——两个差 2px 的圆角、两个肉眼分不出的蓝，它们不叫什么，它们是当时随手写的。
审美篇讲一致性那节有句话是一个意思：差异不是罪，没理由才是。那一节从设计侧讲怎么定变量表，这一节从代码侧讲已经散了怎么收回来。两节配着看，一节给你标准，一节给你手术方案。
配套阅读：审美工程 · 一致性：系统感从哪来（token 该怎么定）· 上一节 PlayGround（收敛完的组件放哪儿调）
一把梭全量重构
让 AI「把全站样式统一一下」，它会给你一个改了 60 个文件的 diff，你审不完也不敢发。永远按控件分批。
顺手改视觉
收敛过程中它常「顺便优化」一下圆角和配色。这会让你分不清页面变样是合并出的 bug 还是它的审美发挥。收敛只做等价替换。
token 定太细
定出 12 档圆角、9 种灰，等于没定——下次它还是要挑，挑就会挑错。档位少到「几乎没得选」才有约束力。
AI 不会复用你没告诉它存在的东西。样式增殖的根因是它每轮都失忆，所以解法有两半：已经乱的按控件分批收进 token，往后的用一条规则挡住——先搜再写。顶上那份 Skill 就是这两半的可执行版本，复制给你的 Agent，它会先给你一张欠债清单，而不是直接开始改。
配套规则可参考仓库 itshen/xs_vibe_rules 中「新功能先查重」一条，本节把它从功能层面延伸到样式层面。
从「交互演示一 · 亲手攒一堆按钮」把感觉变成判断
「下面模拟一个真实项目的迭代。每点一次「再加个功能」，就是你开一轮新对话让 AI 做一个页面。注意看它每次是怎么处理按钮的，以及底下四个数字怎么涨」指出，AI 降低了做出“能用”成品的门槛，读者真正需要练的是看出哪里不对，并把感觉说成可以执行的要求。
观察用户的下一步，而不是只看表面
「重复造样式不是模型偷懒，是三个结构性原因叠出来的。看懂原因，才知道该在哪儿设闸」可以转成几个可观察的问题：用户是否知道现在发生了什么，是否知道下一步做什么，出错或空白时能否恢复，以及信息层级是否让重要内容先被看见。
漂亮不等于容易用
把「配套规则可参考仓库 itshen/xs_vibe_rules 中「新功能先查重」一条，本节把它从功能层面延伸到样式层面」用在第二个页面或流程上，记录一个具体犹豫点和一个改动后的用户动作；能被观察到的变化，才是体验改善。
从「交互演示一 · 亲手攒一堆按钮」走到「别急着骂 AI，它是被环境逼的」
「交互演示一 · 亲手攒一堆按钮」先把问题落在「下面模拟一个真实项目的迭代。每点一次「再加个功能」，就是你开一轮新对话让 AI 做一个页面。注意看它每次是怎么处理按钮的，以及底下四个数字怎么涨」上；到了「别急着骂 AI，它是被环境逼的」，讨论继续推进到「重复造样式不是模型偷懒，是三个结构性原因叠出来的。看懂原因，才知道该在哪儿设闸」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
评估体验时，把抽象的“好看”或“顺手”换成用户动作：他是否看懂状态、找到了下一步、能从错误中恢复，并且愿意继续使用。
- 「交互演示一 · 亲手攒一堆按钮」：下面模拟一个真实项目的迭代。每点一次「再加个功能」，就是你开一轮新对话让 AI 做一个页面。注意看它每次是怎么处理按钮的，以及底下四个数字怎么涨
- 「别急着骂 AI，它是被环境逼的」：重复造样式不是模型偷懒，是三个结构性原因叠出来的。看懂原因，才知道该在哪儿设闸
- 「最后的要点」：三个原因都指向同一件事：它缺一份「我们已经有什么」的清单。 把这份清单写进项目规则文件，它每轮都能看见，增殖才会停。这也是 第 8 节把环境事实写进 Rule 的同一个道理，只不过这次写进去的是样式资产
最后的「最后的要点」把讨论落到「三个原因都指向同一件事：它缺一份「我们已经有什么」的清单。 把这份清单写进项目规则文件，它每轮都能看见，增殖才会停。这也是 第 8 节把环境事实写进 Rule 的同一个道理，只不过这次写进去的是样式资产」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。