PlayGround：组件的试衣间
UI 功能直接写进页面，改一处影响一片，调一个按钮要把整个页面跑起来。解法是先做独立的组件 PlayGround：每个 UI 元素有单独的 demo，调好了再集成进正式页面。
下面就是一个最小的 PlayGround：左边是组件的实时预览，右边是参数控制。随便调，这里怎么改都不会影响页面上任何其他东西，这就是「隔离调试」。
在 PlayGround 里调
刚才的每一次调整，影响范围只有这一个 demo。样式和业务逻辑互不干扰，调好的参数直接抄进正式组件，集成时它已经是成品。
直接写进页面会怎样
同样是调这个按钮：先把整个页面跑起来，登录、拉数据、切到目标状态，才能看到它一眼。样式和业务逻辑纠缠在一起，圆角改大了可能挤歪旁边的布局，牵一发动全身。
思路一致，成本不同。Storybook 是行业标准方案，但配置太重，对 AI 辅助的快速原型项目属于 overkill。PlayGround 取其思路：用一个静态页面把所有组件 demo 排在一起，改组件不影响业务逻辑，调业务逻辑不搞乱组件样式，成本几乎为零。
涉及动效必须先建
涉及页面动效时，必须先创建静态页面 PlayGround，用于自由调整和测试组件，之后才允许写进正式页面。
需求变了 demo 跟着变
需求变化后必须同步更新 PlayGround，保证 demo 始终反映组件的最新形态，别让它变成过期的摆设。
取消的需求 demo 也保留
demo 组件只增改、不删除。功能需求取消了，对应 demo 也要留着，它是设计过程的历史存档，未来复活需求时直接捡回来用。
三个真实情景，点选你认为正确的做法，看判定和理由。
必须有对话测试页
项目涉及 AI 对话功能时，PlayGround 中必须实现简单的对话测试页面，脱离完整业务流程也能单独调一轮对话。
列出所有提示词
页面上必须列出项目用到的所有 Prompt。提示词是 AI 产品的核心资产，藏在代码字符串里没法调试，摊开在页面上才能快速对比和调整。
组件先在试衣间里调好，再走上台。PlayGround 用一个静态页面的成本，换来组件与业务逻辑的双向隔离。
素材来源：对应 rule-opensource.mdc 第三章「PlayGround 组件页规范」，仓库 itshen/xs_vibe_rules。