用代理式建置迴圈設計 Slack 風格介面

我最近完成了一個專案：在單次 Codex session 裡，把一個 Slack 風格介面重新設計並實作出來，過程受到五小時使用限制與 GPT-5.5 的約束。

真正重要的不是限制本身，而是整個順序：

1. 從一個用 placeholder block 做出的舊式模擬介面開始
2. 先把 app 視為傳統的 header、sidebar、main view 版面
3. 用 planning skills 設計較新的 sidebar rails、workspace list 與主要視圖
4. 在碰實作之前，先反覆調整視覺計畫
5. 等形狀足夠清楚，再讓建置工作開始

舊式外殼

起點刻意保持樸素。我希望舊結構一眼就能看懂，這樣新版面就能被拿來和既有框架比較，而不是和一張空白畫布比較。

這代表我保留了熟悉的產品骨架：

• 頂部 header
• 導覽 sidebar
• 主要內容視圖

從這裡開始，問題就不是「模型能不能產生 UI？」而是「如果設計意圖已經足夠明確，模型能不能建出正確的 UI？」

先規劃，再寫程式

在實作之前，我用 Superpowers workflow 做了幾輪視覺規劃。

這讓我先固定住幾個第一版最容易漂移的細節：

• sidebar rails 應該如何框住 workspace list
• workspace list 的密度應該要有多高
• main view 應該如何平衡結構感與內容空間
• 哪些部分應該看起來是刻意設計，而不是 placeholder

這一步比程式生成本身更重要。計畫越強，實作要猜的東西就越少。

第一版輸出

第一版已經足夠有用。

它抓到了整體方向，但仍然有一些小的 UI 瑕疵，特別是 tabs 和 buttons 沒有乾淨對齊。即使大方向正確，這類細節也很難在第一輪完全消掉。

我會把第一輪評為 7 分，滿分 10 分。

迭代之後

經過幾次調整後，介面達到了我想要的大部分 UI 功能。

到了這個階段，成果比較接近 8 分：形狀是對的，互動表面可讀，計畫也被轉換成一個大致連貫的介面。

這已經足夠進入下一層 review。

為什麼這屬於 systems

這裡的教訓不是一次生成就夠了。

真正的教訓是，介面設計可以被視為系統表面的一部分：

• 先規劃 layout
• 把結構明確化
• 接受第一版仍然需要 cleanup
• 用下一輪迭代縮小「能運作」與「設計良好」之間的差距

這正是我想保存在這個網站上的工程判斷。