PlayGround：组件的试衣间
简化版 Storybook 思路：先做独立 demo 调好再集成，demo 只增不删
本页解决的问题
先给结论「PlayGround：组件的试衣间」要解决的关键问题是什么？
简化版 Storybook 思路：先做独立 demo 调好再集成，demo 只增不删
把品味变成产品可重复的行为。 有用的结果不是一句“我觉得更好”。它应该是一条看得见的规则、一个小例子，以及判断体验何时低于标准的方法。
记录一个前后对比，让别人不用听解释也能看懂质量线。
表面更精致了，却没有减少用户的不确定感。
下面就是一个最小的 PlayGround：左边是组件的实时预览，右边是参数控制。随便调，这里怎么改都不会影响页面上任何其他东西，这就是「隔离调试」。
在 PlayGround 里调
刚才的每一次调整，影响范围只有这一个 demo。样式和业务逻辑互不干扰，调好的参数直接抄进正式组件，集成时它已经是成品。
直接写进页面会怎样
同样是调这个按钮：先把整个页面跑起来，登录、拉数据、切到目标状态，才能看到它一眼。样式和业务逻辑纠缠在一起，圆角改大了可能挤歪旁边的布局，牵一发动全身。
思路一致，成本不同。Storybook 是行业标准方案，但配置太重，对 AI 辅助的快速原型项目属于 overkill。PlayGround 取其思路：用一个静态页面把所有组件 demo 排在一起，改组件不影响业务逻辑，调业务逻辑不搞乱组件样式，成本几乎为零。
涉及动效必须先建
涉及页面动效时，必须先创建静态页面 PlayGround，用于自由调整和测试组件，之后才允许写进正式页面。
需求变了 demo 跟着变
需求变化后必须同步更新 PlayGround，保证 demo 始终反映组件的最新形态，别让它变成过期的摆设。
取消的需求 demo 也保留
demo 组件只增改、不删除。功能需求取消了，对应 demo 也要留着，它是设计过程的历史存档，未来复活需求时直接捡回来用。
三个真实情景，点选你认为正确的做法，看判定和理由。
必须有对话测试页
项目涉及 AI 对话功能时，PlayGround 中必须实现简单的对话测试页面，脱离完整业务流程也能单独调一轮对话。
列出所有提示词
页面上必须列出项目用到的所有 Prompt。提示词是 AI 产品的核心资产，藏在代码字符串里没法调试，摊开在页面上才能快速对比和调整。
组件先在试衣间里调好，再走上台。PlayGround 用一个静态页面的成本，换来组件与业务逻辑的双向隔离。
试衣间解决的是「新组件怎么调」。如果项目里已经攒了八个长得差不多的按钮，那要先做一次清理才有东西往试衣间里摆——下一节讲样式收敛：样式为什么会增殖，怎么分批收进 token。
素材来源：对应 rule-opensource.mdc 第三章「PlayGround 组件页规范」，仓库 itshen/xs_vibe_rules。
从「交互演示一 · 现场体验一个迷你 PlayGround」把感觉变成判断
「下面就是一个最小的 PlayGround：左边是组件的实时预览，右边是参数控制。随便调，这里怎么改都不会影响页面上任何其他东西，这就是「隔离调试」」指出，AI 降低了做出“能用”成品的门槛，读者真正需要练的是看出哪里不对，并把感觉说成可以执行的要求。
观察用户的下一步，而不是只看表面
「刚才的每一次调整，影响范围只有这一个 demo。样式和业务逻辑互不干扰，调好的参数直接抄进正式组件，集成时它已经是成品」可以转成几个可观察的问题：用户是否知道现在发生了什么，是否知道下一步做什么，出错或空白时能否恢复，以及信息层级是否让重要内容先被看见。
漂亮不等于容易用
把「试衣间解决的是「新组件怎么调」。如果项目里已经攒了八个长得差不多的按钮，那要先做一次清理才有东西往试衣间里摆—— 下一节讲样式收敛 ：样式为什么会增殖，怎么分批收进 token」用在第二个页面或流程上，记录一个具体犹豫点和一个改动后的用户动作；能被观察到的变化，才是体验改善。
从「交互演示一 · 现场体验一个迷你 PlayGround」走到「在 PlayGround 里调」
「交互演示一 · 现场体验一个迷你 PlayGround」先把问题落在「下面就是一个最小的 PlayGround：左边是组件的实时预览，右边是参数控制。随便调，这里怎么改都不会影响页面上任何其他东西，这就是「隔离调试」」上；到了「在 PlayGround 里调」，讨论继续推进到「刚才的每一次调整，影响范围只有这一个 demo。样式和业务逻辑互不干扰，调好的参数直接抄进正式组件，集成时它已经是成品」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
评估体验时，把抽象的“好看”或“顺手”换成用户动作：他是否看懂状态、找到了下一步、能从错误中恢复，并且愿意继续使用。
- 「交互演示一 · 现场体验一个迷你 PlayGround」：下面就是一个最小的 PlayGround：左边是组件的实时预览，右边是参数控制。随便调，这里怎么改都不会影响页面上任何其他东西，这就是「隔离调试」
- 「在 PlayGround 里调」：刚才的每一次调整，影响范围只有这一个 demo。样式和业务逻辑互不干扰，调好的参数直接抄进正式组件，集成时它已经是成品
- 「列出所有提示词」：页面上必须列出项目用到的所有 Prompt。提示词是 AI 产品的核心资产，藏在代码字符串里没法调试，摊开在页面上才能快速对比和调整
最后的「列出所有提示词」把讨论落到「页面上必须列出项目用到的所有 Prompt。提示词是 AI 产品的核心资产，藏在代码字符串里没法调试，摊开在页面上才能快速对比和调整」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。