前一天我們完成了 my-refrigerator 的專案初始化、Git 整合與 GitHub Pages 部署。現在網站已經有了基本的開發環境，但如果接下來要加入「我的冰箱」、「採買清單」、「最愛食譜」、「特價食材」以及 AI 食材辨識等功能，就不能把所有程式碼都塞在同一個檔案裡。

因此，今天的目標就是建立一個清楚、容易維護，而且方便 Claude Code 持續開發的 Vue 專案架構。

傳統開發時，工程師通常會先思考資料夾怎麼分、元件放在哪裡、頁面如何管理，以及不同功能之間應該如何溝通。這些工作現在也可以交給 Claude Code 協助，但重點不是叫 AI「幫我建立一個 Vue 專案」，而是要先把需求與規則說清楚。

例如可以對 Claude Code 提出：

「請閱讀目前的 CLAUDE.md 與 Frontend Skill，分析 my-refrigerator 的需求，規劃 Vue 專案架構。請先提出方案，不要修改檔案。」

這個步驟非常重要。先讓 AI 思考，再由開發者確認架構，可以避免 Claude Code 一開始就建立大量不符合需求的檔案。

針對 my-refrigerator，目前可以先規劃成類似以下的結構：

src/
├── assets/
├── components/
├── layouts/
├── views/
├── router/
├── stores/
├── services/
├── types/
├── utils/
├── App.vue
└── main.ts

其中，views 可以放主要頁面，例如「我的冰箱」、「採買清單」、「食譜」等；components 則放可以重複使用的 UI 元件，例如食材卡片、食譜卡片、按鈕與表單。

router 負責頁面路由，未來可以規劃：

/                 → 首頁
/refrigerator     → 我的冰箱
/shopping-list    → 採買清單
/recipes          → 食譜
/favorites        → 最愛食譜
/promotions       → 特價食材

stores 則可以使用 Pinia 管理需要跨頁面共享的狀態，例如目前的使用者資訊、冰箱食材或購物清單。

另外，services 可以集中處理 API 或資料庫相關操作。這一點對後續整合 Supabase 非常重要，因為我們不希望每個 Vue Component 都直接處理資料庫操作。透過清楚的分層，可以讓 UI 與資料存取邏輯保持分離。

而 types 則可以放 TypeScript 型別，例如：

Food
Recipe
ShoppingItem
User

如此一來，當 Claude Code 後續建立功能時，就能有一致的資料結構可以依循。

這時候，前面建立的 SKILL.md 就派上用場了。如果 Skill 已經規定 Vue 使用 Composition API、TypeScript、元件命名方式與資料夾規則，那麼 Claude Code 就可以按照這些規範建立專案，而不是每次都重新決定架構。

完成初步規劃後，再請 Claude Code 實際建立檔案，並要求它遵守既有 Skill。例如：

「確認這個架構後，請依照 Frontend Skill 建立必要的資料夾、Router、Layout 與基礎頁面，先不要加入實際商業邏輯。」

這樣的做法可以把開發流程拆成：

需求 → 架構規劃 → 人工確認 → Claude Code 實作 → Git Review。

這比直接叫 AI「幫我把整個網站寫出來」更加可靠，也更符合 AI Native Developer 的工作方式。

今天完成後，my-refrigerator 已經不再只是單純的 Vue 專案，而是有了一套可以持續擴充的前端骨架。接下來每增加一項功能，都可以放進既定的架構中，而 Claude Code 也能根據 Context 與 Skill 持續遵循相同的開發規範。

下一步，就要處理一個非常重要的問題：

冰箱裡的雞蛋、牛奶、蔬菜，到底要怎麼存進資料庫？

Day20，我們將開始設計 my-refrigerator 的資料模型與資料庫 Schema。