Codex + 一個秘密工具，就是我們在工作室裡一直使用的設計工作流程……而且成果真的完全不在同一個檔次。
我已經說了幾個月了。如果你的 App 看起來像 AI 垃圾，那不是 Codex 的問題，是工作流程的問題。
大多數開發者都卡在同一個循環裡。他們用 AI 推出功能。後端能運作。邏輯也很扎實。但介面看起來就跟其他每個用 vibe coding 做的 App 一模一樣。使用者在兩秒內就能決定這東西看起來真不真實。
過去的解決方法是僱用設計師。等好幾週拿到 Figma 檔案。然後看你的開發者解讀那些設計，再用程式碼重寫一遍。等到設計實際上線時，你已經失去了動力，還燒掉了根本不需要燒的錢。
整個流程現在已經變成 optional 了。
為了這次的教學，我建立了 Haven，一個房地產行動 App 的概念。完整的設計系統只花了 20 分鐘。每個畫面在不到一小時內設計完成。透過 Codex 輸出正式程式碼，完全不需要重寫任何一行 CSS。
這就是我現在正在跑的工作流程。每個用 AI 開發產品的開發者都需要了解它如何運作。
Moonchild 到底是什麼
秘密工具就是 Moonchild。
我測試過過去一年幾乎所有推出的 AI 設計工具。大多數第一個畫面看起來還不錯，但當你開始建立第二個頁面時就崩潰了。一致性是問題所在。Moonchild 用其他工具都沒做到的方式解決了這個問題。
它是一個以聊天為基礎的設計畫布，從你的設計系統開始。不是從空白提示開始。不是從截圖開始。而是從你的實際系統開始。你可以透過三種方式帶入你的系統：
→ 從 Figma、GitHub 或即時 URL 匯入
→ 把你的品牌描述給它的 Agentic 設計系統建構器
→ 從 Dribbble 或其他地方放入設計靈感
一旦系統就位，你不再用老方法提示設計。你貼上一個 PRD。它會根據你的系統生成完整的畫面。然後你再從那裡進行美術指導。
而匯出路徑就是閉環的關鍵。Moonchild 提供一個 MCP 連接器，將你的設計以結構化輸出直接傳遞給 Codex。不是讓 Codex 解讀的截圖。而是實際的設計資料。元件、token、佈局，一切都在裡面。
這就是工作流程。現在來看看如何實際使用它。
大多數開發者用 AI 做設計的問題
以下是大多數開發者的做法。
他們提示 Codex 建立一個新功能。它產生了。看起來還行。然後他們提示下一個功能。看起來稍微不同。到了第五個功能時，App 看起來就像五個不同的產品拼湊在一起。
這就是人們說 AI 設計很爛時的意思。
模型本身不爛。是工作流程爛。
Codex 完全不知道你的設計語言是什麼。每次提示都是一個全新的上下文。每個畫面都是猜測。每個元件都跟上次的偏移一些。顏色偏移。字體排版偏移。一切都在累積。
解決方法很簡單。給 Codex 一個系統來遵循。然後給它實際的設計來建構。
大多數工作流程只給其中之一。Moonchild 加上 MCP 連接則同時給了兩者。
步驟 1：先建立你的設計系統。永遠如此。
這是每個人都跳過的步驟。也是最重要的步驟。
在 @ignytlabs，我們在觸及任何畫面之前，會先為每個客戶建立一個設計系統。過去這需要設計師花兩天時間。Moonchild 大約 20 分鐘就搞定。
為了這次教學，我建立了 Haven，一個房地產行動 App 的概念。有幾種方法可以將設計系統導入 Moonchild。你可以從 Figma、GitHub 或即時 URL 匯入。你可以向 Agentic 設計系統建構器描述你的品牌。對於 Haven，我做了我通常在從 vibe 開始時會做的事。從 Dribbble 找設計靈感。我放入了三張房地產行動 App 的截圖，這些 App 完美抓住了我想要的感覺，並附上一段簡短的描述，說明 Haven 是什麼以及目標對象是誰。該工具提取了設計語言並從頭建立了系統。
讓我驚訝的是所有東西都可以預覽。大多數 AI 工具，包括我在上一篇文章中寫到的 Google Stitch 工作流程，只會給你一個平面的 token 檔案。顏色。字體。也許還有間距。但這個工具不同。它建立了一個完整的元件庫和一個圖庫。每個徽章、按鈕、卡片和標籤都按照在 App 中實際呈現的樣子渲染。點擊任何元件，你都可以看到它的即時樣貌，並附有控制項來測試變體和尺寸。預覽下方直接提供該元件的實際 JavaScript、CSS、範例和依賴項。準備好直接拉進程式碼庫。
圖庫是真正改變你設計方式的部分。你不需要猜測「品牌徽章」或「評分徽章」在實際情境中該長什麼樣，而是可以並排看到它們。正在出售。正在出租。精選。整個系列一次呈現。在生成任何單一畫面之前，你就能做出明智的設計決策。
這就是樣式表和真實系統之間的差異。
步驟 2：PRD 到 UI
一旦你的設計系統就位，你不再用老方法提示設計。
你貼上一個 PRD。
一份一頁的功能簡報。一份產品規格。一份目標陳述。你手上有什麼就用什麼。
對於 Haven，我貼上了一份結構化的 PRD，內容涵蓋了產品介紹、目標、目標使用者與角色、關鍵功能與 MVP 範圍、完整的用戶旅程、技術堆疊以及設計方向。大約一頁。具體到足以給工具真實的上下文。結構化到足以將正確的細節拉入正確的畫面。
然後我做了一件大多數人都跳過的事。
在生成任何畫面之前，我先跟它進行腦力激盪。
這是大多數開發者都錯過的關鍵。聊天模式保留了完整的 PRD 上下文。你不是直接丟出 PRD 然後按下生成，而是先討論產品。確認畫面清單。鎖定導航模式。在任何像素存在之前，就先預先定義好關鍵畫面的層級。
對於 Haven，我問了：
→ 「根據這個 PRD，你建議我們先建立哪些畫面？對於一個房地產 App，我有遺漏什麼嗎？」
→ 「主要導航應該是用包含首頁、搜尋、收藏、個人資料的底部標籤嗎？還是別的？」
→ 「在生成之前，請幫我走一遍房源詳情畫面的優先順序。照片先，然後名稱和價格，然後規格，然後設施，然後經紀人。確認或改進。」
→ 「好了，現在請繼續生成這些畫面，包括淺色模式和深色模式，同時堅持我目前所附上的設計系統。確保完成整個用戶旅程並建立所有畫面。」
當我按下生成時，工具對產品的了解已經比大多數設計師在第一次客戶電話後還要深入。
現在快速談一下變體。請仔細閱讀。
一個很酷的功能：你可以為畫面建立不同的變體。你只需要明確告訴 Moonchild，它就會處理。對於 Haven，我想要三種不同的美學方向，然後再決定用哪一種。以下是我用的確切提示：
「我希望你為 Haven 生成 3 個完整的行動 UI 設計概念：
概念 1 - 溫暖編輯風：奶油色背景、寬敞的間距、房產名稱使用襯線字體標題、柔和陰影、雜誌風格的圖片處理。
概念 2 - 大膽現代風：深色模式、高對比、全無襯線字體、銳利邊角、以照片為主且邊到邊的圖片。
概念 3 - 高級極簡風：中性色調（米白、炭灰、單一強調色）、精緻字體排版、大量留白、細微的微互動。
以已連接的設計系統為基礎，但讓每個概念將系統引導到不同的美學方向。生成完整的畫面，而不只是區塊。你會怎麼做？」
注意結尾的「你會怎麼做？」。這是讓它奏效的小細節。工具不是盲目地全部生成，而是先回傳一個計畫。
它說它會先為每個概念建立 5 個代表性畫面。我會並排檢視三個方向。一旦我選定我想要的那個，它就會去為整個 App 設計那個方向。
這完全改變了成本方程式。你不是在支付三套完整建構的費用。你是在支付三個快速樣本的費用，然後再支付一次你實際選定方向的完整建構。
我選了溫暖編輯風。接著整套畫面就回來了。
現在，真正讓我驚訝的部分來了。
Moonchild 生成的每個畫面在預覽模式下都是可互動的。不是靜態的模型。是真正可互動的。
你可以點擊輸入欄位。按按鈕。在畫面之間移動，就像真正的使用者在任何程式碼被寫出來之前測試原型一樣。對於 Haven，我在預覽中發現了兩個流程問題，否則它們就會被送到 Codex。房源詳情畫面沒有明顯的方式返回瀏覽。聯繫經紀人的 CTA 按鈕太偏下方了。如果我直接把設計交給 Codex 而沒有先點擊瀏覽一遍，這兩個問題都會被帶進產品。
這就是關鍵。你在任何程式碼被寫出來之前就先測試產品。
完善循環是最後一塊拼圖。
當一個畫面需要調整時，你不需要從頭開始重新提示。你選取那個畫面，告訴工具要改什麼，它就會在原地生成 v2。想要更電影感的 Hero 區塊？v2。想把卡片佈局換成列表檢視？v3。變體會堆疊起來，讓你可以比較並選出最強的版本。
對於 Haven 的房源詳情畫面，我經歷了三次迭代。v1 把經紀人區塊放得太高了。v2 修正了層級，但照片畫廊感覺太小了。v3 兩者都完美了。大約 8 分鐘的來回調整。
你不是從一片空白開始策劃。你是在完善一個真實的方向。這是最接近與資深設計師合作的部分。
步驟 3：透過 MCP 將 Moonchild 連接到 Codex
這就是工作流程變得超強的地方。
設計系統給了 Codex 規則。MCP 連接給了 Codex 更強大的東西：直接存取實際的設計輸出。不是截圖。不是設計的文字描述。而是 Codex 可以讀取並重建的結構化設計資料。
設定方式如下：
→ 前往 Moonchild 設定，然後選擇 MCP
→ 複製適用於你設定的安裝指令
→ 打開 Codex CLI
→ 貼上安裝指令
→ 使用你的 Moonchild 帳號進行驗證
→ 完成
一旦連接成功，Codex 就能看到你的設計系統以及你設計好的特定 Haven 畫面。
步驟 4：Codex 輸出程式碼
現在你像這樣提示 Codex：
使用 Moonchild MCP 獲取 Haven 房地產行動 App 專案，並告訴我裡面有哪些畫面。
這個第一個提示有兩個作用。它確認 MCP 正確連接。它也讓 Codex 完全掌握你所設計的每一個畫面。
在讓 Codex 執行更重的任務之前，有一個小秘訣。保持在計畫模式。Codex 在執行之前會顯示它即將要做的事。每次都閱讀計畫。確保它理解你想要哪些畫面、以什麼順序、以及什麼精確度。這就是 Codex 寫出你實際需要的程式碼和 Codex 寫出它認為你需要的程式碼之間的差異。
一旦你審查了計畫並將它指向你想要的畫面，Codex 就會直接從 Moonchild 拉取設計資料，參考你的設計系統，然後寫出程式碼。它甚至會加入 hover 狀態、過場效果和邊緣情況處理，因為它使用的是真實的設計資料，而不是從提示中猜測。
結果就是：在你的實際程式碼庫中，幾分鐘內就能得到與設計完全匹配的正式 UI。
在 @ignytlabs，我們過去每個客戶的 MVP 都會為設計預留兩週的時間。設計師會建立 Figma 檔案。開發者會解讀它。解讀會產生偏差。我們再修正。循環往復。有了這個工作流程，整個循環壓縮成一個下午的工作。同樣的品質。更高的利潤。更少的上下文切換。
何時使用這個工作流程
這不是適合每個團隊的工作流程。請誠實判斷何時適用。
當以下情況時使用它：
→ 你是獨自開發者或小團隊，正在推出 MVP
→ 畫面之間的設計一致性一直無法維持
→ 你不想維護一個獨立的 Figma → 設計師 → 開發者管線
→ 你已經有一個設計系統，並希望它在所有地方都被強制執行
當以下情況時跳過它：
→ 你處於規模化階段，擁有完整的內部設計團隊和成熟的 Figma 庫
→ 你需要針對行銷網站或品牌工作進行像素完美的交接，其中每個陰影都很重要
→ 你的程式碼庫具有高度客製化的 UI 模式，需要專屬的設計工作
對於 80% 正在推出 MVP 和 SaaS 產品的開發者來說，這個工作流程涵蓋了你所需要的一切。
需要注意的事項
在你開始執行之前，有幾個誠實的警訊。
你的設計系統品質決定了你的輸出品質。垃圾進，垃圾出。一個只包含三個顏色 token、半完成的 Figma 檔案會產生平庸的畫面。先把時間花在系統上。它會在每個畫面上回報你。
PRD 品質很重要。模糊的簡報會產生通用的畫面。具體的 PRD，包含用戶流程、邊緣情況和清晰的層級，才能得到有用的設計。這不是工具的限制。這是思考上的限制。
你仍然需要品味。工具負責產出。你負責指導。選擇正確的變體並進行完善，這就是你判斷力的所在。如果你跳過策劃的步驟，你就回到了 vibe 設計的狀態。
有些元件需要手動調整。複雜的動畫狀態、客製化的互動模式，任何超出設計系統的東西都需要在 Codex 中進行人工調整。MCP 可以帶你到 90%。剩下的 10% 取決於你的品味。
這實際上意味著什麼
這是我誠實的看法。
用 AI 建立的產品，其瓶頸從來都不是程式碼。AI 可以寫程式碼。瓶頸一直都在設計層面。一致性、品味、將所有東西串聯起來的系統。
那個瓶頸剛剛崩潰了。
在我們的工作室，過去我們每個客戶的 MVP 都會為設計預留兩週的時間。僱用設計師。等待 Figma 檔案。看著開發者解讀它。循環往復。過去需要兩週的事情，現在只需要兩天。同樣的品質。更快的交付。更高的利潤。
這個工作流程就是資金充足的團隊透過他們的 Figma 加設計師加開發者管線已經擁有的。差別在於，現在獨立開發者、獨立工作室和小型工作室也能獲得同樣的槓桿，而不需要增加人力。
2026 年對於那些先搞清楚這一點的工作室和開發者來說，將會是毫不公平的。
TLDR
→ 停止把糟糕的 UI 怪罪到 Codex 頭上。Codex 不是問題。你的工作流程才是。
→ 步驟 1：在 Moonchild 內部建立你的設計系統。從 Figma、GitHub 或即時 URL 匯入。或者描述你的品牌。或者像我對 Haven 所做的那樣，放入 Dribbble 靈感。
→ 步驟 2：貼上你的 PRD。在生成之前先用聊天模式進行腦力激盪。先鎖定畫面清單和導航模式。
→ 預設生成一個變體。明確要求為英雄畫面生成多個不同氛圍的變體。
→ 使用互動式預覽，在任何程式碼寫出來之前測試流程。用 v2、v3 迭代在原地完善畫面。
→ 步驟 3：透過 MCP 將 Moonchild 連接到 Codex。這讓 Codex 獲得真實的設計資料，而不是截圖。
→ 步驟 4：提示 Codex 使用 MCP 建立每個畫面。幾分鐘內就能輸出正式 UI。
→ 你的設計系統品質決定了你的輸出品質。在那裡投資。
→ Figma 到交接給開發者的循環已經死了。現在一個工作流程就能同時處理設計和程式碼。
衝吧。
