適用時期： 2026 年上半年 核心理念： 規格永遠是最重要的。一開始規格列得好，後面監督 AI 能節省更多時間。 開發者角色： 從「代碼執行者」→「架構指揮官」
- 專案資料夾結構規範
- 第一階段：明確功能與需求文件
- 第二階段：技術選型
- 第三階段：系統架構與介面規劃
- 第四階段：前端頁面與設計稿生成
- 第五階段：設計整合與導出
- 第六階段：AI 代理人開發實踐
- 規格文件命名規範與模板
在開始任何開發工作之前，先建立以下標準資料夾結構。這個結構讓 AI 代理人能夠跨檔案梳理邏輯，是「上下文工程（Context Engineering）」的基礎。
my-project/
├── specs/ ← 所有規格文件放這裡
│ ├── requirements.md ← 需求文件（做什麼＋驗收標準）
│ ├── SPEC.md ← 技術規格（數據模型、API 設計）
│ ├── AGENTS.md ← AI 代理人角色指令與行為約束
│ └── tasks.md ← AI 規劃後產生的任務清單（待確認）
├── designs/ ← 所有設計資產放這裡
│ ├── DESIGN.md ← 設計系統規格（色彩、字體、間距）
│ ├── wireframes/ ← 線框圖描述文字檔
│ └── stitches/ ← Stitches 導出的 HTML/CSS/JS 檔案
├── figma/ ← Figma 相關資源（專業流程使用）
└── src/ ← 源代碼
在寫下任何一行代碼之前，讓 AI 完全理解專案的靈魂與邊界。文件是「可執行的活資產」，而非靜態溝通工具。
步驟 1.1 — 反覆討論，聚焦需求
透過與 AI 或他人討論，慢慢收斂你的想法。這個階段的關鍵不是列功能清單，而是定義產品的影響力與核心價值：
- 這個服務解決什麼問題？
- 主要使用者是誰？
- 最重要的 3 個功能是什麼？
- 哪些事情是這個產品絕對不做的？（邊界定義）
範例提問方式： 「我想打造一個充滿正向交流的社群平台，請幫我釐清：什麼樣的機制能引導良性互動、減少負面情緒擴散？」
步驟 1.2 — 選擇 AI 工具整理想法
| 情境 | 推薦工具 | 原因 |
|---|---|---|
| 快速發散、腦力激盪 | ChatGPT、Gemini | 通用型 LLM，回應速度快 |
| 複雜文件整理、長上下文 | Claude (Anthropic) | 上下文窗口達 1M tokens，Markdown 編輯能力卓越 |
| 大型專案、跨檔案梳理 | Cursor / Google Antigravity | AI 原生 Editor，支援代理人跨檔案推理 |
步驟 1.3 — 產出 requirements.md
將討論結果交給 AI 整理成結構化文件，儲存至 specs/requirements.md。
使用以下 Prompt 範本：
請根據我們的討論，幫我整理一份完整的需求文件（requirements.md）。
格式要求：
- 產品背景與核心價值（為什麼要做這個？）
- 目標使用者描述
- 核心功能清單（按優先級排序）
- 各功能的驗收標準（Acceptance Criteria）
- 邊界情況與錯誤處理方式
- 明確的「不做清單」（Out of Scope）
請使用 Markdown 格式，確保邏輯嚴謹。
技術選型不是個人偏好，而是基於需求文件的數據導向決策。
步驟 2.1 — 請 AI 推薦技術架構
將 requirements.md 丟給 AI，使用以下 Prompt：
請根據 specs/requirements.md 中的需求，推薦最適合的技術架構。
請說明：
1. 前端框架選擇及原因
2. 後端方案選擇及原因（含至少兩個方案的比較）
3. 資料庫選型及原因
4. 第三方服務建議（身份驗證、儲存等）
5. 每個選擇的優缺點與取捨
請特別考量：開發速度、維護成本、團隊學習曲線。
步驟 2.2 — 後端方案參考對照
| 方案 | 特點 | 2026 預估月費（10萬用戶） | 適用場景 |
|---|---|---|---|
| Supabase (PostgreSQL) | 關係型、可自託管、定額收費 | $25–$90 | SaaS、Web 應用、複雜關係數據 |
| Firebase (NoSQL) | 文檔型、Google 生態整合、按操作收費 | $500–$2,000 | 行動 App、快速原型、即時同步 |
| Custom (K8s/Go) | 完全控制、高維護成本 | $1,500+ | 企業核心系統、極高性能需求 |
2026 年建議： 在高頻操作的應用中，Supabase 通常比 Firebase 便宜 80%–95%。初學者與小型專案優先考慮 Supabase。
步驟 2.3 — 將技術選型結果更新至 SPEC.md
確認技術選型後，請 AI 根據 requirements.md 擴充產生 specs/SPEC.md，內容包含：
- 技術堆疊清單（Tech Stack）
- API 路由設計（API Path Design）
- 資料庫 Schema 草稿
- 第三方服務整合清單
建立系統骨架，包含後端架構圖與前端元件拆分設計。
步驟 3.1 — 啟動計畫模式（Plan Mode）
在支援的 IDE（如 Google Antigravity 或 Cursor）中，將完整的需求文件交給 AI，要求其產生架構規劃：
請根據 specs/requirements.md 和 specs/SPEC.md，幫我規劃完整的系統架構。
請包含：
1. 系統架構圖（以文字或 Mermaid 圖描述）
2. 前端頁面清單與路由規劃
3. 後端服務區塊劃分
4. 資料流規劃（前端 ↔ API ↔ 資料庫）
5. 需要的外部服務與串接方式
請指出架構中任何潛在的風險或不合理之處。
步驟 3.2 — 架構規模選型指引
| 規模 | 建議架構 | 技術清單 |
|---|---|---|
| 輕量/敏捷專案 | 前端直接接 BaaS | React/Vue + Supabase/Firebase |
| 中型專案 | 有輕量後端 | Next.js + Supabase + Edge Functions |
| 重型企業系統 | 完整微服務 | Kubernetes + Kafka + 自定義後端服務 |
步驟 3.3 — 前端元件拆分（原子設計原則）
請 AI 依照「原子設計（Atomic Design）」概念拆分前端結構：
請根據架構規劃，使用原子設計（Atomic Design）原則，拆分前端元件：
1. Atoms（基本元件）：Button、Input、Badge、Icon 等
2. Molecules（組合元件）：SearchBar、UserCard、PostItem 等
3. Organisms（複合區塊）：Header、Sidebar、PostList 等
4. Pages（頁面）：各頁面的路由與對應元件
請以清單形式輸出，並說明各元件的功能與複用範圍。
請將結果整合進 specs/SPEC.md 的「前端架構」章節。
將規格轉化為視覺設計稿，作為後續 AI 代碼生成的視覺參考。
官方連結： https://stitch.withgoogle.com（Google Labs 產品）
Stitch 是 2026 年最具代表性的 AI 介面生成工具，採用 AI 原生的無限畫布，支援文字、圖片與語音指令生成高保真 UI 佈局。
四種模式說明：
| 模式 | 底層模型 | 適用情境 |
|---|---|---|
| Thinking | Gemini Pro | 追求精細排版、複雜頁面 |
| 3 Flash | Gemini Flash | 追求速度、快速原型 |
| Redesign | 圖像反向工程 | 上傳設計圖仿照風格 |
| Ideate | 解決方案導向 | 有問題、尚未有視覺概念時 |
直接將以下資訊整理成一段描述，丟入 Stitch：
產品名稱：[產品名]
頁面：[頁面名稱，如 Dashboard]
功能：[這個頁面要完成什麼任務]
目標用戶：[誰會使用]
風格關鍵字：[clean, modern, dark mode, card-based...]
需要的元件：[列出主要 UI 區塊]
步驟 4B.1 — 從 Dribbble 尋找靈感
前往 https://dribbble.com 搜尋目標風格，找到心儀的設計稿截圖。
步驟 4B.2 — 兩種做法可選：
做法 B1（直接上傳）： 將截圖直接上傳到 Stitch，選擇 Redesign 模式，輸入：
請生成一個風格相似的 [頁面名稱]，
功能需求：[描述功能]
保留原設計的：色彩系統、卡片佈局、排版比例
調整為：[你需要的功能變化]
做法 B2（先解析風格，再生成）： 先將截圖丟給 Gemini 或 ChatGPT，使用以下 Prompt：
請分析這張設計稿的設計系統，輸出以下參數：
- 主色 / 輔助色 / 背景色（以 HEX 值標示）
- 字體系統（標題字重、內文字重、字級比例）
- 圓角大小（px）
- 間距系統（基礎單位）
- 陰影風格
- 整體設計語言關鍵字（如：minimalist, glassmorphism, neo-brutalism）
將解析結果整合成描述，存入 designs/DESIGN.md，再把這份設計規格交給 Stitch 作為生成約束。
針對多頁面應用，只需生成 1–3 個最複雜的核心頁面（如 Dashboard），以此確立全站設計語言。其餘簡單頁面交由後續的 AI 代碼代理人依照風格延展，避免設計不一致。
Stitch 目前仍在 Beta 階段，生成頁面過多時設計一致性可能下降。最佳策略：少量高質量的設計稿 > 大量不一致的設計稿。
確保設計系統文件包含：
# DESIGN.md — 設計系統規格
## 色彩系統
- Primary: #[hex]
- Secondary: #[hex]
- Background: #[hex]
- Surface: #[hex]
- Error: #[hex]
## 字體系統
- Font Family: [字體名]
- H1: [字號] / [字重]
- H2: [字號] / [字重]
- Body: [字號] / [字重]
## 間距系統
- Base unit: [4px or 8px]
- Spacing scale: [4, 8, 12, 16, 24, 32, 48, 64]
## 圓角
- Small: [px]
- Medium: [px]
- Large: [px]
## 陰影
- Card shadow: [CSS value]
- Modal shadow: [CSS value]有了 Stitch 的設計稿，根據專案規模選擇以下兩種導出方式。
適合：中大型專案、需長期維護、有設計師協作
步驟 5A.1 — 導出至 Figma
從 Stitch 將設計稿導出，匯入 Figma（https://figma.com）。
步驟 5A.2 — 設定 Figma MCP Server
Figma MCP（Model Context Protocol）允許 AI 代碼代理人直接讀取 Figma 檔案中的圖層數據、設計 Token 與排版約束。
設定說明文件：https://help.figma.com/hc/en-us/articles/35280968300439
MCP 的核心優勢：
- AI 不再是看著截圖瞎猜，而是精準抓取設計數據
- 透過 Code Connect 確保生成的代碼始終使用已有的設計系統元件
- 支援雙向更新：可將渲染後的 UI 回傳至 Figma 作為可編輯圖層
步驟 5A.3 — 在 IDE 中連接 Figma MCP
在 Cursor 或 Google Antigravity 中，設定 MCP 連接後，AI 可以直接讀取 Figma 檔案並生成對應代碼。
適合：小型專案、課堂練習、快速原型
從 Stitch 直接下載專案，會得到一個包含 HTML、JavaScript 和 CSS 的靜態包。
操作步驟：
- 在 Stitch 中點選「Export」→「Download as HTML」
- 將檔案解壓縮，放入
designs/stitches/資料夾 - 這些檔案將作為 AI 代理人生成代碼的「視覺規格參考」
注意：這些 HTML/CSS 檔案不是生產級元件，而是視覺規格參考。後續 AI 代理人會根據這些參考重構為正式的 React 或 Vue 元件。
是否需要用 Figma 細修？
視需求決定。若設計的一致性可以接受，可以直接進入第六階段。若需要細修（如調整間距、色彩），可以先在 Figma 中細調，再導出為更新的設計 Token。
以整理好的規格與設計稿為基礎，讓 AI 代理人完成實作。
| 功能 | Cursor (2026) | Google Antigravity (2026) |
|---|---|---|
| 核心技術 | VS Code Fork + Deep Indexing | Agent-first + Gemini 3 |
| 特色模式 | Composer（多檔案編輯） | Plan Mode + Artifacts |
| 異步處理 | 支援背景代理任務 | 專用 Manager 視圖監控多代理 |
| 定價 | $20/月（Pro） | 預覽期免費（含額度） |
| 官方連結 | https://cursor.com | https://antigravity.google |
課堂統一使用：Google Antigravity（因為同學都有 Google 學生帳號 Pro 權限）
確認資料夾結構完整，並做好分類（參考第一節的結構規範）。
最終確認清單：
-
specs/requirements.md— 需求文件 -
specs/SPEC.md— 技術規格（含技術選型與 API 設計） -
specs/AGENTS.md— 代理人角色指令（如有） -
designs/DESIGN.md— 設計系統規格 -
designs/wireframes/— 線框圖描述 -
designs/stitches/— Stitch 導出的視覺參考檔案
在 Google Antigravity 或 Cursor 中，先讓 AI 進行深度推演，產生「計畫產出物（Plan Artifacts）」再開始寫代碼。
終極 Prompt 範本：
請你參考以下資料夾內的所有文件，協助打造這項產品：
📁 specs/requirements.md — 產品需求與驗收標準
📁 specs/SPEC.md — 技術規格，包含技術選型與 API 設計
📁 designs/DESIGN.md — 設計系統（色彩、字體、間距規則）
📁 designs/stitches/ — 代表性頁面的視覺參考（HTML/CSS）
📁 designs/wireframes/ — 各頁面線框圖規格
請嚴格按照以下順序進行：
1. 先仔細閱讀所有文件，理解整體系統
2. 規劃所有頁面清單、Component 設計、資料庫資料流安排，
以及後端服務的區塊劃分與串接整合
3. 將規劃結果輸出為 specs/tasks.md（任務清單），
等待我確認後再開始撰寫程式碼
4. 確認後，依照 designs/stitches/ 中的代表性頁面建立設計語言，
其餘頁面請參考 designs/wireframes/ 的規格一起生成
由於這是一個大型工作，請仔細規劃，完成規劃後即可立即開始。
AI 產出 specs/tasks.md 後，務必人工審查：
- 確認任務順序是否合理
- 確認沒有遺漏的功能點
- 確認技術選型與 SPEC.md 一致
- 如有問題，直接在對話中批注修正
確認無誤後，指示 AI 開始執行：
計畫確認，請開始執行。依照 tasks.md 的順序逐步完成，
每完成一個主要功能模塊請告知進度，遇到不確定的部分請先詢問。
當 AI 代理具備自主調用 API 的能力時，請在 specs/AGENTS.md 中定義以下規則：
# AGENTS.md — AI 代理人行為規範
## 最小權限原則
- 資料讀取代理：僅具備 read 權限
- 資料寫入代理：僅具備特定資料表的 write 權限
- 禁止任何代理具備 admin 或全局刪除權限
## 決策邊界
- 資料庫 Schema 修改：必須人工確認
- 外部 API 調用：需列出將使用的 endpoints
- 環境變數：禁止在代碼中硬編碼，使用 .env 檔案
## 授權框架
- 使用 OAuth 2.1 構建代理人授權
- 每個操作使用細粒度的 Scope（如 read:transactions，而非 admin）| 文件 | 路徑 | 說明 |
|---|---|---|
| 需求文件 | specs/requirements.md |
定義「做什麼」與驗收標準 |
| 技術規格 | specs/SPEC.md |
技術選型、API 設計、資料模型 |
| 代理人規範 | specs/AGENTS.md |
代理人角色指令與行為約束 |
| 任務清單 | specs/tasks.md |
AI 生成的任務規劃（待人工確認） |
| 設計系統 | designs/DESIGN.md |
色彩、字體、間距、元件規則 |
# [產品名稱] 需求文件
## 產品背景
[為什麼要做這個？解決什麼問題？]
## 目標使用者
- 主要用戶：[描述]
- 次要用戶：[描述]
## 核心功能（按優先級）
### 🔴 P0 — 必須有（MVP）
- [ ] 功能一：[說明] | 驗收標準：[如何確認完成]
- [ ] 功能二：[說明] | 驗收標準：[如何確認完成]
### 🟡 P1 — 應該有
- [ ] 功能三：[說明]
### 🟢 P2 — 有更好（未來規劃）
- [ ] 功能四：[說明]
## 邊界情況與錯誤處理
- 情境一：用戶輸入無效資料時 → [預期行為]
- 情境二：網路中斷時 → [預期行為]
## 不做清單（Out of Scope）
- 不做：[功能名] — 原因：[說明]# [產品名稱] 技術規格
## 技術堆疊
| 層級 | 技術 | 版本 | 選用原因 |
|------|------|------|----------|
| 前端 | React | 19.x | [原因] |
| 後端 | Supabase | - | [原因] |
| 資料庫 | PostgreSQL | 16 | [原因] |
## API 路由設計
| Method | Path | 說明 | 權限 |
|--------|------|------|------|
| GET | /api/v1/posts | 取得文章列表 | Public |
| POST | /api/v1/posts | 新增文章 | Auth |
| DELETE | /api/v1/posts/:id | 刪除文章 | Owner |
## 資料庫 Schema（草稿）
\```sql
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
email TEXT UNIQUE NOT NULL,
created_at TIMESTAMPTZ DEFAULT NOW()
);
\```
## 前端架構（原子設計）
### Atoms
- Button, Input, Badge, Avatar, Icon
### Molecules
- SearchBar, UserCard, PostItem, TagList
### Pages
| 路由 | 頁面名稱 | 主要元件 |
|------|----------|----------|
| / | 首頁 | HeroSection, FeatureList |
| /dashboard | 儀表板 | StatsCards, ActivityFeed |在進入下一個階段之前，確認以下項目：
第一階段完成標準：
-
specs/requirements.md存在且包含驗收標準 - 核心功能清單已按優先級排序
- 邊界情況與錯誤處理已定義
第二階段完成標準：
- 技術選型已確認並記錄理由
-
specs/SPEC.md包含 API 路由設計
第三階段完成標準：
- 系統架構圖已產生（文字或圖形）
- 前端元件清單已按原子設計拆分
第四階段完成標準：
- 至少 1 個核心頁面的設計稿已生成
-
designs/DESIGN.md包含完整設計系統參數
第五階段完成標準：
- 設計稿已導出（Stitch 靜態包 或 Figma 檔案）
- 已放入
designs/stitches/或連接 Figma MCP
第六階段完成標準：
-
specs/tasks.md已由 AI 產生並人工確認 - AI 代碼代理人已開始按計畫執行
「沒有任何時間比現在更早開始。即使不是完美的方法，我們也必須努力應用在專案上，畢竟改善世界才是專案的目標。」
本指南適用於 2026 年上半年。工具與最佳實踐可能持續演進。