为啥 Codex 还不推出类似 Codex Design 的产品？

📌 【深度解析】為什麼 AI 畫得出 UI，卻做不出「可交互的原型」？

很多人在用 Claude Design 時會驚訝：為什麼它生成的 App 感覺像真的？點擊、跳轉、狀態切換竟然如此流暢，而其他模型（如 GPT-5.5/Codex）做出來的東西卻像個「半成品」？

這背後其實揭露了 AI Agent 的一個核心真相：能畫 UI 很容易，但能設計「系統狀態」極難。

🤔 把 AI 拆成兩層：廚房 (Harness) 與 廚師 (Model)

要理解這個差距，首先得區分兩個概念。很多人把 Claude Design 與 Claude Opus 4.8 混為一談，但實際上它們分屬於不同的層級：

1. Harness 層（產品層）：像是「廚房」。包含提示詞 (Prompt)、工具鏈、UI 交互流程。這部分在工程上並沒有太高的門檻，甚至可以被逆向工程。
2. Model 層（模型層）：像是「廚師」。這是真正負責思考與產出的腦袋（如 Claude Opus 4.8 或 GPT-5.5）。

結論是：即便你把 Claude Design 的「廚房」搬給其他模型用，如果「廚師」的能力不夠，做出來的菜依然沒味道。

🧪 從「畫圖」到「系統設計」的維度差異

為什麼 Codex 或 GPT-5.5 在這方面顯得吃力？因為「高精度可交互原型」與「靜態設計圖」有本質區別。

如果你要求 AI 畫一個 X (Twitter) 的界面，大多數模型都能交出好看的靜態圖。但要讓它「可交互」，模型必須在動筆前完成一套系統架構設計：

• 定義數據結構（Tweet 的格式是什麼？）
• 管理狀態聯動（點讚後紅心如何變色？刪除後列表如何即時更新？）
• 處理導航邏輯（從列表進入詳情頁，返回時狀態是否還在？）

這不再是 UI/UX 的美學問題，而是系統架構設計的問題。Claude Design 的強大在於其背後的模型在設計與架構場景中經過了大量優化，能同時兼顧「視覺設計」與「邏輯架構」。

💡 設計產物即代碼：徹底消除設計與開發的溝通損耗

Claude Design 最核心的突破在於它的交付物不是 Figma 或 PSD 檔案，而是直接產出 React、CSS 與 JSON。

透過分析其產出的 data.jsx 文件可以發現，它先定義清晰的數據結構，再用 React 在這套數據上構建 UI。這帶來了極大的工程優勢：

• 精準度高：開發者能直接看到圓角、主色、間距，無需猜測。
• 版本管理：設計變更直接透過 git diff 就能看出改了什麼。
• 低損耗：設計 Agent 與開發 Agent 之間的溝通損耗被降到最低，人只需要指揮兩個 Agent 協作。

⚠️ 工程實現非門檻，真正的差距在於模型訓練

正如作者寶玉在 baoyu-design 的開源實踐中所展示的，Harness 層的邏輯是可以複刻的。但即便使用了相同的工具鏈，不同模型的表現依然有顯著差異。

這證明了：目前的差距不在於誰的 Prompt 寫得更好，而是在於模型是否具備處理複雜狀態管理 (State Management) 的能力。

🎯 給開發者的啟示：關注「狀態」而非僅僅是「界面」

如果你在開發 AI 輔助工具或使用設計 Agent，請記住：

• 拒絕純 HTML 靜態稿：沒有交互邏輯的設計稿只是「皮」，缺乏 UX 的靈魂。
• 重視數據結構定義：AI 能否做出好產品，取決於它是否先想清楚數據結構，而非直接開始寫 CSS。

🔗 參考來源 📝 為什麼 Codex 還不推出類似 Design 的產品？ 👤 寶玉 (baoyu.io) 🔗 文章：https://baoyu.io/blog/2026-06-13/codex-design-gap 💻 相關開源實踐：https://github.com/JimLiu/baoyu-design

你認為 AI 最終會取代 Figma 成為設計師的主流工具嗎？還是它僅僅是一個高效的原型工具？歡迎在評論區分享你的看法 👇

#AI #ClaudeDesign #LLM #SystemDesign #UX #React #AIagent #技術分析