样式收敛：一个按钮不要八套 CSS
让 AI 连着做十个功能，你会攒出八个长得差不多的按钮类。它不是不会复用，是每轮对话都不知道你已经有什么。这一节讲样式为什么会增殖、怎么收干净，以及哪些差异该留着。
下面模拟一个真实项目的迭代。每点一次「再加个功能」，就是你开一轮新对话让 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 中「新功能先查重」一条，本节把它从功能层面延伸到样式层面。