Open Design 實測：用本地 CLI 快速做出作品集首頁

前言

這次我在做作品集首頁時，主體畫面大多是用 Open Design 完成的。它不是那種只會吐幾張靜態稿的工具，而是把「需求對齊、視覺方向、設計稿生成、交付給本地開發工具」串成一條比較完整的流程。

先講清楚一點：影片開頭那段麥金塔風格動畫不是用 Open Design 做的。那段我之後有機會再單獨寫一篇，分享實際製作方式。這篇先聚焦在 Open Design 本身的工作流。

下面先放這次的成果錄影：

我這次不是拿它來做單純 landing page 草稿，而是直接拿來整理作品集首頁的骨架與視覺方向。實際操作下來，流程大概分成四步。

Open Design 一開始就不是只問你要不要輸入 prompt，它先問的是怎麼執行。你可以接本地 Coding Agent，也可以改走自己的模型 Key。

我這次走的是本地 CLI 模式。介面裡可以直接看到多種本機代理工具，像是 Claude Code、Codex CLI、Gemini CLI、Hermes、Cursor Agent、GitHub Copilot CLI 等。

這個設計我很喜歡，因為它代表 Open Design 不是把設計和實作完全切開，而是從一開始就把「後面誰要接手」考慮進流程。

先決定是走本地 Coding Agent，還是改用自己的模型服務憑證

建立新專案時，Open Design 不是只給你一個空白輸入框，而是先讓你挑設計系統。從截圖可以看到裡面有一整排風格分類，像是 Neutral Modern、Vibrant、Artistic、Cafe、Cosmic、Editorial、Fantasy 等。

這一步很關鍵。很多 AI 工具會在「風格」這件事上講得很空，但 Open Design 是先把風格層級收斂，再往下走內容生成。對做品牌頁、作品集、提案頁的人來說，這比從零開始瞎試 prompt 有效率得多。

建立新專案時先選設計系統，能大幅降低後續視覺發散的成本

我這次做的是個人作品集首頁，所以在 brief 裡我直接把頁面形式、重點連結、素材策略、作品排序和整體氣質都先講清楚。

從畫面來看，這個 brief 區不是單行 prompt，而是偏向結構化需求收集。像是：

這種做法的好處是，它會逼你先把需求整理到一個不那麼模糊的程度。對我來說，這一步其實比生成本身更重要。

不是一句 prompt 丟出去就結束，而是先把需求與網站方向收斂清楚

當需求確認完成後，右側是設計稿工作區，左側則會顯示 agent 的實際執行過程。從我這次的畫面可以看到，它不是只回一段「我幫你做好了」的文字，而是會列出執行紀錄、讀了哪些檔案、怎麼整理內容，最後再把結果交付出去。

右上角還能直接看到 交付給 VS Code，這點我覺得非常實用。因為很多時候設計稿不是終點，真正有價值的是後面接回你自己的開發環境，繼續調整、重構、換真實資料。

左邊看 agent 執行過程，右邊看設計稿輸出，最後再接回 VS Code

我自己最在意的，不是它能不能一次生成超漂亮畫面，而是它能不能幫我把空白頁到可修改版本的距離縮短。

這次用下來，Open Design 比較像是一個會先理解工作上下文，再開始動手的設計代理。它把幾件原本分散的事整合得不錯：

這類工具最怕的就是只會做出「看起來有設計感，但完全接不上實際專案」的產物。Open Design 至少在流程設計上，已經明顯比單純聊天式生 UI 更往前一步。

如果你符合下面這幾種情境，我覺得 Open Design 會很好用：

如果你本來就習慣自己手切每個 section、每個間距、每個字級，那 Open Design 不一定會完全取代你的設計流程。但它很適合當第一輪的加速器。

這次作品集首頁的大部分內容，我確實是靠 Open Design 先把骨架與視覺方向拉起來。它幫我省掉了不少從空白頁開始試錯的時間，也讓設計和本地 CLI 工作流之間的銜接變得更自然。

至於影片最前面那段麥金塔風格動畫，這篇先不展開。下次有機會我再單獨寫，分享那一段到底怎麼做。

相關連結：