1. CLAUDE.md 當作「常駐系統提示」

每個 session 開始 AI 自動讀入專案規則，不用每次重講。重點不是寫了什麼，而是寫的方式：

- 指令化而非描述化：「Push 後到 Vercel 確認 Ready 而非 Blocked，別假設 push = 上線」

- 規則附上日期和事故緣由（「2026-07-24 事故後訂」），AI 知道這是血淚規則不會擅自放寬

- 用「READ FIRST before UI or feature work」這種觸發條件，告訴 AI 什麼時機該讀哪份文件

2. 自足式執行計畫（最核心的一招）

docs/開發實作計畫.md 開頭就寫明定位：「這份是給執行的 AI 照著做的單一來源，寫成不需額外背景就能執行」。具體手法：

- 每個 Phase 有逐步清單 + 明確檔案路徑 + 驗收指令（gradlew test / npm run lint && build 全綠才算完成）

- 文件內建「如何使用這份文件」四步驟——連使用方式都寫給 AI 看

- 已定案的決策標明不要重問，避免每個新 session 重新開會

3. 規劃與執行拆到不同模型／session

分工是：高階模型寫計畫，執行 session 照計畫做。計畫核准後規劃端不動工，把計畫檔交給執行端。好處：規劃時的長篇討論脈絡不佔用執行 session 的 context，執行端拿到的是蒸餾過的乾淨指令；也省成本。

4. 把「決策準則」寫進計畫，不只寫任務

計畫開頭那段「🧍 一人店營運前提」是精華：告訴 AI 評估任何功能的標準是幫她省時間還是多一件事要顧，並給了「低遺憾優先」原則（不做的代價可逆、做錯的代價是幫倒忙）。這讓 AI 在遇到計畫沒寫到的選擇時，能自己做出和你一致的判斷——這比列一百條規則有效。

5. 硬需求寫成「不過＝沒做完」

「手機優先 RWD 是硬需求……這條沒過＝該頁沒做完」+ 具體驗證方法（375px、無橫向捲動、按鈕點得到）。把品質標準寫成完成定義的一部分，AI 就不會交出「功能對但手機破版」的半成品。

6. 反模式用「範例檔案指路」

不只說「別做 X」，還附正確範例的路徑：「新增外部輸入一律建 DTO，範例見 dto/RegisterRequest.java」「圖片一律用 resolveImageUrl()，別直接用 product.image」。AI 照著現有範例寫，風格自動一致——等於免費的 few-shot。

7. 單一事實來源（Single Source of Truth）

- 店家資訊全部集中 src/config/site.js，註解寫明「所有 CTA 從這裡讀」

- 「怎麼做」看開發實作計畫、「長什麼樣」看網頁設計方向——兩份文件各管一件事，AI 不會拿到互相矛盾的指示

8. 事故 → 規則的回饋迴圈

每次踩雷就地轉成永久規則，寫進對的層級：

- 影響全專案的 → CLAUDE.md（Vercel committer email 事故）

- 跨專案的技術陷阱 → AI 長期記憶（Postgres lower(bytea) 陷阱、H2 測試抓不到的問題）

- 當天脈絡 → docs/work_log/工作日誌*.md，下個 session 接得上

9. 版本地圖控制範圍蔓延

v1/v2/v3 地圖明寫「每一版都能獨立上線」，並在 v1 直接寫「把自助結帳先隱藏」。AI 天生愛把功能做好做滿，用版本邊界明確告訴它什麼是「現在故意不做」，程式碼保留但不接線（CartContext 留著給 v2）。

---

一句話總結：技巧的共通點是——把脈絡從對話搬進檔案。對話會結束、context 會爆掉，但 CLAUDE.md、計畫文件、工作日誌、記憶會留下來；每個新 session 的 AI 都像一個「失憶但很聰明的同事」，這套文件體系就是讓它 30 秒內接手上工的交接手冊。

如果分享時想要現場演示，最有說服力的兩個檔案是 docs/開發實作計畫.md（開頭 30 行）和 CLAUDE.md 最上面那段 git 事故規則。需要的話我可以把這份整理成投影片大綱或一頁式講義。