开场：新组件先试衣，老样式再收敛

UI 功能直接写进页面，改一处影响一片，调一个按钮要把整个页面跑起来。解法是先做独立的组件 PlayGround；而项目里已经攒了八个长得差不多的按钮时，则要先做一轮样式收敛。两件套一起，前端才算治理干净。

一句话速览：简化版 Storybook 思路 + 样式收敛四步，让新组件有试衣间、老样式有 token。

一、PlayGround：组件的试衣间

思路： 每个 UI 元素有单独的 demo，调好了再集成进正式页面。用一个静态页面把所有组件 demo 排在一起，改组件不影响业务逻辑，调业务逻辑不搞乱组件样式。

为什么不能直接写进页面

直接调一个按钮，得先把整个页面跑起来——登录、拉数据、切到目标状态，才能看到它一眼。样式和业务逻辑纠缠在一起，圆角改大了可能挤歪旁边的布局，牵一发动全身。

和 Storybook 的关系

思路一致，成本不同。Storybook 是行业标准方案，但配置太重，对 AI 辅助的快速原型项目属于 overkill。PlayGround 取其思路，成本几乎为零。

三条维护规则

1. 何时创建——涉及动效必须先建： 涉及页面动效时，必须先创建静态页面 PlayGround，用于自由调整和测试组件，之后才允许写进正式页面。
2. 同步更新——需求变了 demo 跟着变： 需求变化后必须同步更新 PlayGround，保证 demo 始终反映组件的最新形态，别让它变成过期的摆设。
3. 只增不删——取消的需求 demo 也保留： demo 组件只增改、不删除。功能需求取消了，对应 demo 也要留着，它是设计过程的历史存档，未来复活需求时直接捡回来用。

AI 对话项目的特殊要求

• 必须有对话测试页： 项目涉及 AI 对话功能时，PlayGround 中必须实现简单的对话测试页面，脱离完整业务流程也能单独调一轮对话。
• 列出所有提示词： 页面上必须列出项目用到的所有 Prompt。提示词是 AI 产品的核心资产，藏在代码字符串里没法调试，摊开在页面上才能快速对比和调整。

二、样式收敛：一个按钮不要八套 CSS

让 AI 连着做十个功能，你会攒出八个长得差不多的按钮类。它不是不会复用，是每轮对话都不知道你已经有什么。

别急着骂 AI，它是被环境逼的

重复造样式不是模型偷懒，是三个结构性原因叠出来的：

1. 看不见： 新开一轮对话，上下文里只有你这次给的几个文件。项目里已经有 .btn-primary 这件事它无从得知，于是按需求现写一个。
2. 更省事： 读懂一套现有样式要把相关文件全看一遍，还得担心改了影响别处。新起一个类名零风险、零阅读成本，这是它的最优解，不是你的。
3. 不敢碰： 需要一个带阴影的按钮时，它宁可写 .btn-primary-new 也不改原来那个——改动别人在用的样式属于高风险操作，它选择了安全但会增殖的做法。

三个原因都指向同一件事：**它缺一份「我们已经有什么」的清单。**把这份清单写进项目规则文件，它每轮都能看见，增殖才会停。

收敛四步：先盘点，再合并，最后设闸

1. 盘点，先只看不改： 让 AI 扫全项目的样式，产出一张重复清单：哪几个类在实现同一种控件、散落着多少个颜色值和圆角值。这一步不许动代码，你先看清欠了多少债。
2. 定 token，把魔法数字收成档位： 从盘点结果里挑出真正在用的值，定成一小套变量：主色、语义色、圆角两三档、间距四档、控件高度。档位要少，少才守得住。
3. 分批合并，一次一种控件： 先按钮，验证；再卡片，验证；再输入框。每批单独提交，出问题能单独回滚。收敛是等价替换，视觉上应该看不出变化——真需要改样子，那是另一个任务。
4. 设闸，防它明天再长出来： 把「写新样式前先搜 token 和公共组件，搜到就复用，搜不到才新建并说明搜过什么」写进规则文件。不设这道闸，你三个月后还得再收一遍。

结语

试衣间解决的是「新组件怎么调」，样式收敛解决的是「旧样式怎么收」。 新组件先在 PlayGround 里调好再上台，老样式分批收进 token 再设闸防增殖——两件套配合，前端才能在 AI 协作下保持干净。