樣式收斂：一個按鈕不要八套 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 中「新功能先查重」一條，本節把它從功能層面延伸到樣式層面。