正確的工作流程
你不會跟建築師說「幫我蓋房子」就等交屋。你會先看樣品屋、討論格局、看設計圖，最後才動工。跟 AI 做專案也一樣。
新手的做法 vs 正確的做法
絕大多數新手拿到 AI 工具，第一件事就是打一段話：「幫我做一個 XXX。」然後 AI 噴出 50 個檔案，你看不懂、改不動，最後砍掉重練。
AI：（生成 50 個檔案、3 個資料表、
用了你沒聽過的框架、
加了你不需要的功能）
你：「等等，這不是我要的......」
你：「這個拿掉、那個改掉」
你：「為什麼改了 A 功能，B 壞了？」
你：「算了，砍掉重練。」
花了 3 小時 + 大量 Token = 什麼都沒得到
Step 2：確認邊界（10 分鐘）
Step 3：規劃架構（20 分鐘）
Step 4：正式開始寫（省時省 Token）
花了 40 分鐘 + 少量 Token = 方向正確
接下來我們一步一步看，正確的流程到底怎麼做。
第一步：先做 Demo（10 分鐘）
任何專案的第一步，不是「開始做」，而是「先看個樣子」。
你要買房子，不會直接在設計圖上簽約。你會先去看樣品屋——走進去感受空間大小、看看動線、摸摸建材。看完之後你才有「感覺」：客廳太小、廚房要開放式、浴室要乾濕分離。
Demo 就是你的樣品屋。它不需要完美，甚至不需要能用。它只需要讓你「看到」一個大概的樣子，這樣你才能開始說出具體的意見。
怎麼跟 AI 要一個 Demo：
幫我做一個最簡單的 Demo：
- 一個頁面就好
- 有一個客戶列表（假資料）
- 可以點進去看客戶詳情
- 用最簡單的方式做，不用資料庫，假資料寫在程式碼裡就好
目的是讓我看到畫面，確認方向對不對。」
10 分鐘後，你就有一個可以看、可以點的東西。這時候你才能真正開始思考：「這個跟我想的一不一樣？」
第二步：看著 Demo 確認邊界
有了 Demo，你現在可以做第二章講的「邊界確認」了。因為你有東西可以指著說：
- 「這個列表要加搜尋功能」
- 「客戶詳情頁不需要編輯功能，只看就好」
- 「不要做刪除客戶，怕誤刪」
- 「列表要能按日期排序」
- 「手機上也要能看，RWD 是必須的」
這些需求在看到 Demo 之前，你可能根本想不到。因為人類是視覺動物——看到東西才能反應。
看樣品屋之前：「我想要一個舒服的家。」（模糊到不行）
看樣品屋之後：「客廳太小要加大、廚房要做開放式、主臥的窗戶方向不對，冬天會西曬、浴室要有浴缸不要淋浴間。」
看了之後你才知道自己要什麼、不要什麼。
把你看完 Demo 的所有想法整理成一份清單，分成「要加的」和「不要的」。這份清單就是你的邊界文件。
第三步：規劃架構（最重要的一步）
確認了要做什麼、不做什麼之後，接下來不是直接開始寫程式，而是先把架構規劃好。
地基是房子最先做、也最不起眼的部分。但地基歪了，上面蓋得再漂亮都沒用——整棟樓都是歪的。
軟體的「地基」就是資料庫設計和架構決策。這些東西一旦確定了，後面要改的成本非常高。
在這一步，你需要跟 AI 討論（不是直接叫它寫程式）的事情：
3-1. 資料庫欄位設計
資料庫就像你的檔案櫃。每一格抽屜放什麼、怎麼分類，一開始就要決定好。後面要改抽屜的格局，等於把所有文件搬出來重新分類。
必要欄位：姓名、電話、Email、公司名稱
可選欄位：備註、標籤
系統欄位：建立時間、最後更新時間
問題：
1. 一個客戶可以有多個聯絡人嗎？（如果可以，要拆成兩個表）
2. 標籤是固定選項還是自由輸入？
3. 需要記錄誰建立的嗎？（多人使用的話需要）」
3-2. 計算邏輯放哪裡
如果你的系統有計算功能（例如：訂單總金額、庫存數量），你需要決定計算邏輯放在前端（使用者的瀏覽器）還是後端（伺服器）。
| 放前端 | 放後端 |
|---|---|
| 速度快、體驗好 | 資料準確、安全 |
| 但使用者可以「竄改」 | 但每次都要等網路 |
| 適合：顯示用途（即時預覽價格） | 適合：金流相關（實際扣款金額） |
3-3. 耦合預告：哪些東西會互相影響
耦合的意思是「A 和 B 綁在一起，動了 A 就會影響 B」。在規劃階段，你需要先知道哪些功能是「綁在一起」的，這樣做的時候才不會一改就壞。
你在房間靠牆放了一個大衣櫃，結果衣櫃後面剛好是電線的接線盒。現在要修電線，得先把 50 公斤的衣櫃搬開。
如果一開始就知道接線盒在這裡，衣櫃就不會放這個位置。
耦合預告就是先標出「接線盒在哪」，避免以後搬衣櫃的痛苦。
常見的耦合範例：
- 使用者權限 ↔ 頁面顯示（改了權限規則，每個頁面都要跟著改）
- 商品價格 ↔ 訂單計算（價格欄位改了，訂單那邊也要改）
- 上傳功能 ↔ 儲存空間（檔案格式改了，儲存的邏輯也要改）
3-4. SSOT：單一真理來源在哪裡
SSOT（Single Source of Truth）翻譯成白話就是：同一筆資料只存在一個地方。
公司有一份通訊錄。如果每個部門都各自維護一份，A 部門改了電話，B 部門不知道，就會打到舊號碼。
正確做法：只有一份「正式通訊錄」放在公司系統上，所有部門都看這一份。誰改了，大家都看得到。
那份「正式通訊錄」就是 SSOT。在軟體裡，某筆資料應該只存在一個地方（通常是資料庫），其他地方需要用就去那裡查，不要各自存一份。
在規劃架構時問 AI：
客戶資料的唯一來源是 Supabase 的 customers 表？
還是有些資料會另外存在 localStorage？
我想確認不會出現資料不同步的問題。」
第四步：正式開始寫
做完前三步，你現在有了：
- 一個看得到的 Demo（知道長什麼樣）
- 一份邊界清單（知道要什麼、不要什麼）
- 一份架構規劃（知道資料結構、技術選擇、耦合風險）
現在才是正式開始寫程式的時候。而且因為前面的功課做足了，你下指令的品質會好很多：
先做第一個功能：客戶列表頁
- 資料從 Supabase 的 customers 表讀取
- 欄位：姓名、公司、電話、最後聯絡日期
- 預設按最後聯絡日期排序（最近的在上面）
- 頂部有搜尋框，即時過濾（前端過濾）
- RWD，手機版用卡片式而不是表格
- 不要做分頁，先用無限滾動
- 不要做刪除功能
做完這個再做下一個，一次做一個功能。」
為什麼不能跳過第二步和第三步
因為你省掉的不是「時間」，而是「思考」。那些你沒想清楚的問題，不會消失——它們只會在你做到一半的時候爆出來，而且修起來的成本是事先想清楚的 5-10 倍。
改設計圖只要擦掉一條線重畫。改已經蓋好的牆，要拆、要補、要重新粉刷。
常見的「跳過就會後悔」的情境：
| 跳過了什麼 | 後果 | 修復成本 |
|---|---|---|
| 沒確認要不要多語言 | 做完才加 i18n，30 個檔案全部要改 | 是一開始就做的 10 倍 |
| 沒確認權限設計 | 做到一半才發現「管理員跟一般使用者看到的頁面不同」，整個路由要重寫 | 是一開始就規劃的 5 倍 |
| 沒設計好資料庫 | 做到第三個功能才發現表格結構不對，要 migrate 還可能丟資料 | 是一開始就設計好的 8 倍 |
| 沒確認手機版需求 | 整個 UI 做完才說要 RWD，每個元件都要調整 | 是一開始就考慮 RWD 的 3 倍 |
本章小結：蓋房子的完整流程
Step 1 看樣品屋（Demo）
你走進建商的樣品屋，感受空間大小、看看格局、摸摸建材。這讓你從「我想要一個家」變成「我想要這種感覺的家」。
Step 2 跟建築師討論格局（確認邊界）
你指著樣品屋說：「客廳要再大一點、廚房要開放式、不要浴缸要淋浴間、這個儲藏室不需要。」你說出了「要什麼」和「不要什麼」。
Step 3 看設計圖（規劃架構）
建築師畫出設計圖、結構圖、水電配置圖。你確認地基怎麼打、管線怎麼走、承重牆在哪裡。這些一旦動工就很難改。
Step 4 動工（正式開始寫）
一切確認完畢，才開始打地基、灌漿、砌牆。一層一層蓋，每層驗收。
你不會跟建築師說「幫我蓋房子」就等交屋。跟 AI 做專案也一樣。
記住這個流程：Demo → 確認 → 規劃 → 執行。看起來多花了時間，但實際上省下的是來回修改的 Token、砍掉重練的時間、以及抓不到 bug 的挫折感。
「幫我做一個 XXX 的最簡單 Demo，先不用完整功能，讓我看看大概的樣子。」
光是這一句話的改變，就能省你好幾個小時。