跟 AI 一起寫程式：從一份 CLAUDE.md 到 Skills 跟規範
2025 年初 AI 對我來說還是拿來問問題的工具，到了 2026 年幾乎所有程式都是 Claude Code 寫、我做 review。這一年多我經手的幾個專案，給 AI 的設定也一路演變：先是把所有東西塞進一份上千行的 CLAUDE.md，再把固定流程拆成 Skills，最後連領域知識、規格流程跟測試閘門都做進去。這篇整理這三個階段、每個階段的做法，還有為什麼會這樣改。
領域知識太重的案子：工程師怎麼邊做邊學
約 5 分鐘2026 年我大半年都在做一套給電力調度員練習跟考試用的模擬系統。它模擬的是變電所的圖控畫面，開關會動、電驛會跳、警報會叫，但一切都在軟體裡。技術架構很快就定了，真正難的是領域知識：規格書的文字跟實際系統對不上、每一條畫面規則背後都有電力的道理，工程師不懂就只能邊做邊學。這篇是這個案子的回顧，講我們怎麼從會議、錄影跟驗收回饋裡把領域知識一點一點補起來，還有下次再遇到這種案子我會怎麼做。
一個人做專案，也要寫給下一個人看的文件
九月我把做了大半年的 EMS 前端交接給新同事。交接能順利，靠的不是最後一週惡補，而是從一個人做 Starter Kit 的時候就持續留下的東西：README、資料夾結構說明、架構圖、決策紀錄、Commit 規範、任務紀錄。這篇整理一個專案該留下哪些文件、各自是寫給誰看的，還有實際交接時怎麼用它們。
需求先講清楚：User Story 與驗收標準怎麼幫團隊少走冤枉路
約 5 分鐘2025 年我主要在開發一套能源管理系統（EMS）。半年多下來最有感的不是技術，而是「需求規劃」這件事：畫面改了兩三次、時程一度很趕，後來把需求確認的順序補起來，並引入 User Story 與驗收標準之後，整個團隊才開始順。這篇整理我們怎麼做，還有我從中學到的事。
設計稿還沒定案，開發可以先做什麼
約 4 分鐘2025 年初我接下一個新專案的前端，目標是三月的能源展 Demo。結果放假前需求與畫面重新規劃，進度退回一成，設計師又同時兼顧好幾個案子。這篇記錄我怎麼在設計稿只有一成的情況下，照著線稿先把頁面蓋到三到五成，哪些東西先鎖定、哪些留到最後，還有「給客戶看的 Demo」跟「要上線的 MVP」為什麼應該分開。
小步合併，讓 CI 早一點說話：一次 Semgrep 掃描教我的事
收尾一個 Next.js 專案時，把 dev 合併到 main 的那一刻，CI 的 Semgrep 掃描跳出了 SSRF 弱點。追下去才發現被標記的那層 API Routes 其實只是在轉送 Mock 資料。這篇記錄當時怎麼判斷、怎麼處理，還有我從這件事學到的幾個習慣：掃描結果其實是在講架構、Mock 資料該放在哪一層，以及為什麼要小步合併。