AI 寫程式碼越快，專案失控也可能越快。真正的問題不是模型會不會生成函式，而是它是否理解需求、是否遵守團隊語言、是否能在既有架構裡小步推進。
Matt Pocock 開源的 mattpocock/skills 倉庫，給了一個和 vibe coding 相反的方向：不要讓 AI 接管整個開發流程，而是把 AI 放進成熟的軟體工程約束裡。
專案地址：https://github.com/mattpocock/skills
這套方法的重點不是某個神奇 prompt，而是一組可以組合的 agent skills。它們把需求澄清、領域建模、測試驅動、問題診斷、架構審查這些工程實踐，重新包裝成適合 AI 編程工具調用的工作流。
先解決對齊失敗
AI 編程最常見的失敗，是你以為它懂了，其實它只是順著你的模糊描述開始猜。
grill-me 的思路是反過來：寫程式碼之前，先讓 AI 變成會追問的審稿人。它不會立刻開始實作，而是持續追問計畫裡的分支、邊界和未決問題。
例如你說「做一個登入頁」，它應該先問：
- 忘記密碼怎麼處理？
- 是否支援第三方登入？
- 登入失敗時要顯示什麼錯誤？
- 帳號鎖定、驗證碼、風控是否在本期範圍內？
- 成功後跳轉到哪裡？
這一步看起來慢，但它減少的是後面返工的時間。AI 生成程式碼的成本越低，需求沒想清楚帶來的浪費就越大。
把領域語言寫進上下文
第二個問題是 AI 的通用詞彙病。它不了解團隊內部的業務叫法，只能用常見詞來猜，於是變數名、函式名、文件描述都開始漂移。
grill-with-docs 不只是追問需求，還會結合專案裡的 CONTEXT.md、ADR 或領域文件，檢查使用者表達是否和既有術語衝突。確認後的術語、邊界和決策，可以繼續沉澱回上下文文件。
這和領域驅動設計裡的「統一語言」很接近。假設團隊把 user 稱為 customer，把 order 稱為 transaction，AI 在寫程式碼時也應該繼承這些叫法。
上下文文件的價值不在於堆資料，而在於讓 AI 少猜一點。
用 TDD 限制生成速度
AI 的危險之處在於它太快了。過去寫出一大段壞程式碼需要時間，現在幾秒鐘就能生成幾百行。速度本身不是問題，缺少回饋循環才是問題。
tdd skill 把經典的紅綠重構流程放回 AI 編程裡：
- 先為一個行為寫失敗測試。
- 再實作剛好讓測試通過的程式碼。
- 然後重構。
- 按垂直切片繼續推進。
重點是「一次一個行為」，而不是讓 AI 一口氣寫完所有測試和所有實作。AI 負責執行，人類負責確認方向和邊界。
用診斷循環處理複雜問題
遇到 bug 時，很多 AI 會直接猜答案，然後連續改幾輪，把問題越修越亂。
diagnose 的價值在於要求 AI 先建立回饋循環：
- 重現問題
- 最小化場景
- 提出假設
- 增加觀測或日誌
- 修復
- 補回歸測試
這套流程不新，但在 AI 編程裡尤其重要。AI 很擅長快速嘗試，但不一定擅長判斷哪次嘗試真正接近根因。診斷流程相當於給它加了一條軌道。
定期審查架構
單次任務跑通，不代表程式碼庫變好了。AI 反覆提交小改動後，最容易出現模組邊界模糊、介面越來越複雜、測試越來越難寫。
improve-codebase-architecture 這類 skill 的意義，是讓 AI 定期跳出當前任務，從更高層看程式碼庫：
- 哪些模組職責開始混在一起？
- 哪些介面太複雜？
- 哪些路徑難以測試？
- 哪些命名和領域語言不一致？
- 哪些重複邏輯應該收斂？
這不是讓 AI 自動大重構，而是讓它先給出結構化觀察和改進方向。真正要不要改、改到什麼程度，仍然需要開發者判斷。
真正該限制的是自由度
這套方法論的核心可以壓縮成一句話：AI 編程不是放任模型自由發揮，而是給它清楚的目標、上下文、測試和停止條件。
人類更適合負責問題定義、架構邊界、業務取捨和驗收標準；AI 更適合負責程式碼生成、測試補全、重複修改和局部重構。
所以，軟體工程基礎沒有因為 AI 變強而過時。需求澄清、領域語言、TDD、診斷、架構審查這些能力，在 AI 時代反而更關鍵。
會寫程式碼的人會越來越多。真正拉開差距的，是誰能把 AI 放進可維護、可驗證、可長期演進的工程體系裡。