Open Design 這次丟出的訊號很明確：AI 設計工具真正難的，不是讓模型生出一張漂亮畫面，而是讓設計意圖在反覆修改、交接到程式碼、甚至做成動態輸出時都還活著。它現在把這條路徑接進 Codex，讓 agent 不只看文字需求，也能在畫布、原型與本地檔案之間來回工作。
這次原作者到底說了什麼？
原始 X 貼文來自 @nexudotio。主貼在 2026 年 5 月 18 日發布，核心說法是「Open Design now works inside Codex」，並把問題定義成：AI design 最難的不是生成單一畫面，而是迭代、建置與發布時，如何保留 design intent。
比較重要的是留言串裡的原作者補充。這串不是只有一則貼文，而是原作者在回覆裡拆成幾個步驟與答覆。我這次只採用 @nexudotio 自己的貼文，避開廣告與其他人的留言。
| 原作者貼文 | 重點 |
|---|---|
| 主貼 | Open Design 可以在 Codex 裡工作；設計、程式碼、motion 進入同一個工作流。 |
| 1/ | 先請 Codex 協助把 Open Design clone、install、啟動本地 app，並在內建瀏覽器打開。 |
| 2/ | 描述你要設計的產品、貼上上下文、上傳參考，或選 design system / template 作為起點。 |
| 3/ | 接著持續和 agent 對話：建立畫面、修改 layout、產生 variants，或把設計轉成 code / motion。 |
| 補充答覆 | 這不只是瀏覽器視覺互動；Open Design 也會產生本地 artifacts/files，Codex 可以讀取、檢查與繼續修改。 |
原作者影片與圖文串
下面保留原作者的影片與分段圖文貼文。這些嵌入比較適合呈現 demo 與畫面上下文，文章本身則負責整理脈絡。
為什麼這不是「多一個設計頁面」而已？
如果只把它理解成「在 Codex 旁邊開一個設計工具」，會錯過真正的重點。原作者在回覆裡特別補充：瀏覽器提供的是即時視覺上下文，但 Open Design 還會在同一個 workspace 產生本地 artifacts/files，讓 Codex 可以檢查輸出、引用 prototype，並繼續往 code 或 motion 推進。
這和 GitHub 官方 README / architecture 文件裡的描述也對得上。Open Design 採用 web app 加 local daemon 的架構；daemon 會偵測本地 agent CLI，建立 artifact store，讓設計輸出以檔案形式留在本機，而不是只停在一次性的瀏覽器畫面。
| 傳統 AI 產圖/產 UI | Open Design 想做的事 |
|---|---|
| 輸入 prompt，得到一張圖或一段 UI | 把 prompt、design system、artifact、修改紀錄放進可追蹤流程 |
| 設計交給工程師時常變成截圖或描述 | 設計結果落在本地 artifacts/files，agent 可以繼續讀取與修改 |
| 改版時容易失去原本意圖 | 讓 design intent 在迭代、code、motion 之間被反覆檢查 |
| 工具多半綁定單一雲端服務 | local-first、BYOK，並支援多種 agent CLI |
從官方資料看，它目前能做什麼？
Open Design 的 GitHub README 把它定位成 Claude Design / Figma 的 open-source、agent-native 替代方案。它強調 local-first、web-deployable、BYOK，並且可以接 Claude Code、Codex、Cursor Agent、Gemini CLI、OpenCode、Qwen 等本地或相容 agent CLI。
- 本地設計工作台：預設走本機 web app + daemon，agent 在本機被啟動，artifact 也落在本機。
- 設計系統與 skills：官方 README 提到內建大量 design systems 與 composable skills，用來控制原型、deck、template、design system 等輸出模式。
- 多格式輸出：官方文件與 release note 提到 HTML、PDF、PPTX、ZIP、Markdown，以及 image / video / audio / HyperFrames 這類媒體流程。
- Codex 工作流：原作者貼文的重點，是讓 Codex 能在內建瀏覽器看到畫布，也能從同一 workspace 接續 artifacts/files。
- 快速啟動：Quickstart 提到 Node.js 24、pnpm 10.33.x，也提供 Docker 模式，Docker 預設可在
http://localhost:7456打開。
下載與專案連結
原作者在 1/ 貼文裡直接給了 GitHub repo，這類連結應該保留給讀者，不要只寫文字介紹。
如果你想試，先注意這幾件事
- 先決定要用 Docker 還是 source mode。 Docker 模式比較像快速試跑；source mode 則需要 Node 24 與 pnpm。
- 確認你的 agent CLI 在 PATH 裡。 Open Design 會掃描本機 CLI；如果 GUI 抓不到，通常是 PATH 環境不同。
- 不要只看畫面，要看 artifact。 真正值得測的是 Codex 能不能理解產出的檔案、改得動、接得進你的專案。
- 把它當設計迭代工具，不要當一次性產圖工具。 它的重點是 design intent、review、handoff、artifact，而不是炫技式生成。
- 留意版本節奏。 這個 repo 更新很快，README 已經在推 0.8.0 preview，而 GitHub latest release 查到的是 0.7.0。正式導入前要看 release note 與 breaking changes。
我的觀察：Codex 需要的是「可接續的設計上下文」
這件事最有意思的地方，不是 Codex 可以看到一個漂亮畫布，而是設計結果有機會變成 Codex 能讀、能改、能繼續工作的上下文。對開發者來說，真正痛的不是「我能不能生一個 UI」，而是「我改了三輪之後，原本的產品意圖還在不在」。
Open Design 如果做得好，會比較像一個設計與工程之間的中介層：設計不是外部截圖，程式碼不是事後重寫，agent 也不是盲猜 UI。它把畫布、檔案、檢查與修改放在同一個 loop 裡，這對未來的 AI 開發工具會很關鍵。
但我也會先保持一點保留。這類工具很容易 demo 看起來很順，實務上會卡在 design system 管理、專案檔案結構、agent 改動邊界、以及人類如何 review。真正值得觀察的不是第一版生成速度，而是它能不能在第四次、第五次修改時，還能保留同一個設計方向。