蓋 /playgrounds/ 的時候，常有人（含山姆鍋自己）下意識以為：專業前端場地，怎麼能沒有 transpile、沒有 bundler？TypeScript、JSX、打包壓縮——倉庫裡天天在跑，瀏覽器裡的遊樂場少一套，總覺得少半截。
後來山姆鍋把這套默認建置刻意拿掉。不是做不出來，是對不上遊樂場真正要守的那一口：開發單頁小程式（SAM），而且場裡已經有 coding agent 在改檔、重載、看輸出。
目錄
傳統建置本來很合理
先講公道話。Transpile 把較嚴的語法或型別降成瀏覽器吃得下的 JavaScript；bundling 處理套件、拆塊、體積與兼容。對倉庫＋CI＋上線，這條路仍成立。本篇不是要宣布 Vite／esbuild 退休。
問題只在：那套假設搬進遊樂場當默認中介時，還合不合身。
場地在做單頁小程式
遊樂場的主軸不是「瀏覽器裡的完整前端工程站」，而是在沙盒裡編、存、跑一個 SAM：固定 index.html 入口，靜態資產加一點可選的 Workers 形 /api，畫布上像從網路開站一樣驗證——這點山姆鍋在畫布不是預覽稿寫過。
單頁小程式的甜區，本來就可以是瀏覽器原生 ESM：相對路徑的模組與 CSS，寫進去就能跑。驗證單位是「這棵原始碼樹能不能直接跑」，不是「產線打包後的最佳化結果」。SAM 也不強制短小——大一點的前端仍算合法——但成長痛點是怎麼找到檔、怎麼跟人與代理交代地圖，不是先上型別編譯器與打包器。
遊樂場不是部署環境。真要優化體積、鎖套件、走完整 TS 專案，那是離開場地之後、倉庫與 CI 的事。場地若內建同一套 transpile／bundle，等於暗示「來這裡做完整前端工程管線」——和輕量遊樂場的形狀打架。
場裡已經有 coding agent
另一個前提不能裝沒看到：coding agent 已經在閉環裡。總管這類角色會高頻讀檔、改多檔、重載畫布、讀 console——觀察迴圈要穩，靠的是「改完看不看得見」，不是再疊一層工具鏈。
傳統管線假設比較像：人手寫 source → 機器產 dist → 人再預覽。有 agent 之後，同一輪會重複很多次。若中間再插 transpile／bundle：
- 雙重真相：改的是 A，跑的是 B（或
.ts與 emit）。人還勉強靠 IDE；agent 更容易改錯層，或把 bundler 的錯當成業務邏輯的錯。 - 建置變成迴圈的稅：人手可以忍「存檔等 compile」；agent 一輪改十幾次時，等待、快取、半成品會變成場地的主節奏——那是 CI 節奏，不是遊樂場節奏。
- 設定變成第二專案：
tsconfig、bundler 設定、別名路徑，agent 會「順手改」。場地若官方提供建置，等於承諾養半套前端工具鏈。
瀏覽器裡的 OPFS 也沒有舒服的 npm install 與可重現 lock 故事。硬做不是不行，只是又養一隻怪物——山姆鍋差點做成瀏覽器裡的 Linux時，已經付過「完整感很貴」的學費。
Agent 就是最好的 transpiler
那轉換誰做？
在遊樂場這個問題域裡，山姆鍋的答案有點刺耳：agent 就是最好的 transpiler。
傳統 transpile 假設 source 與 emit 長期並存，工具鏈穩定、可重現。遊樂場要的往往不是中間表示，而是畫布上立刻能驗證的單頁小程式。Coding agent 本來就在生成與改寫檔案——要可跑的 JS，就請它直接寫成可跑的 JS；要拆模組，就改相對 ESM；實驗寫法要收斂，就重寫那幾份檔。轉換發生在改檔那一刻，沒有藏在背後的 dist/，觀察迴圈仍是：改 → 重載 → 看 console。
機械編譯器擅長確定性與可重現（發版、簽章、lockfile）——那仍該留給場外的 CI。Agent 會幻覺、會漏改，所以場地才更要守「跑的就是寫的」，用畫布與 console 當驗收，而不是再用 bundler log 當第二裁判。
「最好」是對遊樂場而言，不是工程宇宙真理。
結語
單頁小程式值得守一棵可直接跑的樹；coding agent 已在場時，更不該把傳統 transpile／bundling 塞進默認路徑。需要轉換時，優先讓 agent 寫出可執行形態；需要上線／倉庫那套建置時，離開遊樂場再交給 CI。
場地在遊樂場，免費亂試。你覺得遊樂場該不該內建 Vite，或「agent 當 transpile」太過偷懶——下面留言區歡迎打臉。