從草圖到實作：Claude Design 與 Claude Code 的雙向對齊

在這一次的預約系統開發中，我和另一位夥伴先在 Figma gam 討論頁面大致的樣子，並隨手拉出很草的草圖，然後匯入到 Claude Design 嘗試把系統的頁面設計與 template 產出來，後續再匯出給 Claude Code 接手實作。

當我正式把設計稿匯入 Claude Code 時，立刻碰到了第一件事：Claude Design 所採用的視覺規範與套件樣式，跟既有專案程式碼裡的樣式設定完全不一致。

如果不做雙向對齊，直接套用設計稿的原始樣式，專案的設定只會散落各處，介面風格也會失去統一管理的基準。

從原子化拆分到 Skill 約束

在持續導入頁面的過程中，我們遇到了排程日曆（Calendar）這個模組。它並不包含在初始的設計規範中，但又涉及極為複雜的介面互動與狀態變化。

當時我的第一個動作，是先請 Claude Design 將日曆以「原子化」的概念進行拆分，一口氣切出時間軸、事件區塊、日期標頭等 8 個原子組件，再匯入到 Claude Code 裡面實作。

但這也讓我意識到一個問題：如果日後又遇到設計規範沒涵蓋的新組件，AI 在缺乏約束的情況下，很容易隨意切分元件、重複造輪子，或是把檔案隨意擺放。

為此，我請 AI 建立一份 UI 組件規範 Skill，明確定義專案的元件開發原則：

  • 元件歸屬原則：只在單一頁面使用的元件，必須收納在該頁面的目錄下；唯有確定跨頁共用的原子組件，才能提升至全域組件庫。
  • 優先使用既有套件：拒絕重複造輪子，能用既有元件庫解決的就不手刻。
  • 單一資料來源：全專案統一使用 dayjs 處理日期計算，星期標籤等常數統一收進單一檔案，移除寫死字串與重複定義。

建立了這個規範後，等於替 AI 與自己建立清楚的開發邊界。未來無論遇到多複雜的新組件，AI 自然能自動遵循相同的架構邏輯。

邊實作邊異動再寫回 Design 與專案文件

有了組件規範作為後盾，我們開始在 Claude Code 裡面對排程日曆進行深度實作。

由於日曆涉及許多真實的商業邏輯（例如時段綁定、公休標示與既有預約的畫面疊加），很多互動細節無法單靠前期的設計稿憑空想像。我們選擇在程式碼裡邊實作邊調整介面與細節，一邊驗證邏輯，一邊收斂規格。

當排程日曆在 Claude Code 端實作完成、邏輯與介面都調整到符合預期後，我做的下一步是：將這個最終結果寫回同步到 Claude Design，確保設計原型與實際程式碼保持單一來源（Single Source of Truth）。

同時，我也把這段期間產生的資料結構變動與組件規範，寫回專案的核心文件（CLAUDE.md 與 .github/copilot-instructions.md）。這樣做能讓 AI 助手在後續的開發視窗中，持續保有最新的 Context，不會因為跨工具切換而遺失先前的規格決策。

  • 設計與開發是雙向滾動的：比起單向的設計交付，邊實作邊修正、最後寫回設計原型的雙向迭代，能讓規格更貼近真實邏輯。
  • 邊界規則勝過每次提醒：把開發習慣寫成 SKILL 檔，是讓 AI 在面對未知組件時依然保持程式碼品質最省力的方式。
  • 維持單一來源：將實作異動寫回 Design 與專案文件，是確保跨工具協作時不掉球的關鍵。