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 用一個靜態頁面的成本，換來組件與業務邏輯的雙向隔離。
試衣間解決的是「新組件怎麼調」。如果項目裏已經攢了八個長得差不多的按鈕，那要先做一次清理才有東西往試衣間裏擺——下一節講樣式收斂：樣式為什麼會增殖，怎麼分批收進 token。
素材來源：對應 rule-opensource.mdc 第三章「PlayGround 組件頁規範」，倉庫 itshen/xs_vibe_rules。