來源：YouTube | 8 分 26 秒 | 2026-07-13 | Why QQ
AI 編程品質低落的根本原因不在於模型不夠聰明，而在於它缺乏長期記憶與上下文，因此必須透過可重複、可組合的嚴格流程（如 Skills 倉庫）來引導與馴服 AI。
- 問題本質：AI 在商業專案中表現不佳，主因是「沒有記憶」，而非能力不足。
- 核心解法：Matt Pocock 提出「Skills 倉庫」，將軟體開發生命週期拆解為數十個可組合的技能，取代一次性「神 Prompt」。
- 溝通反轉：
/grill-with-docs或/grill-me透過「設計樹」概念，逐步提問以釐清需求，避免 AI 自行假設。 - 共識優先：
/to-spec與/to-tickets將共識轉化為規範與垂直切片任務，確保實作前已達成明確共識。 - 迭代實作：
/implement階段採用 TDD 模式，/tdd僅專注於 red-green 循環，重構延至/code-review。 - 程式碼審查：
/code-review透過 Spec 軸與 Standards 軸雙線檢查，注入程式碼異味檢測，但尊重開發者決策。 - 大專案導航：
/wayfinder引入「戰爭迷霧」概念，只規劃視距內的可見任務，逐步清除未知區域。 - 架構關鍵：
/improve-codebase-architecture強調，混亂的程式碼庫只會產出混亂的 AI 輸出，模組邊界與領域語言是 AI 穩定工作的基石。
Matt 將 AI 在商業專案中的失敗歸因於「記憶不足」，這確實點出上下文長度與持續性學習的瓶頸。然而，此觀點可能低估了模型在推理與因果理解上的根本缺陷——即使給予完整記憶，AI 仍可能因缺乏領域直覺而做出荒謬決策。批判地看，記憶問題只是冰山一角，模型的「常識缺失」與「邏輯不一致」才是更深層的挑戰。
/grill 系列透過逐步提問來釐清需求，能有效避免 AI 的盲目假設，但這也意味著開發者必須投入大量時間回答數十個問題。對於簡單功能，這種「拷問式」流程可能過於繁重，反而降低效率。Matt 雖強調「共識優先」，但實務上，開發者往往期待快速原型，而非冗長的問答環節。
/to-tickets 強制使用垂直切片（如先完成「郵箱密碼註冊」），而非傳統的水平切片（先建完所有資料庫表）。此策略利於獨立驗證，但可能導致重複工作（如後續需回頭調整資料庫結構）。批判來看，垂直切片更適合功能迭代，而水平切片在大型基礎設施建置時仍有其價值，Matt 的「強制偏好」可能忽略專案類型的差異。
v1.1 將 /tdd 限縮為 red-green 循環，重構移至 /code-review，此舉減少實作階段的認知負荷，但也可能錯失「即時重構」的良機。重構延後可能讓程式碼累積更多技術債，尤其當開發者對審查階段的重構建議懶得執行時。批判地看，這套流程適合紀律嚴明的團隊，但對追求敏捷的個人開發者而言，可能過於僵化。
Wayfinder 引入遊戲機制處理大而模糊的專案，強調只規劃視距內的任務，避免過早設計。此方法能降低初期焦慮，但可能導致「短視近利」——忽略長期架構的影響。例如，若前期 Ticket 的設計未考慮後續擴展，後續「迷霧散去」時可能需大規模重構。批判視角下，Wayfinder 更適合探索型專案，而非已有明確架構的維護型專案。
| 論點 | 說明 | 批判視角 |
|---|---|---|
| AI 品質低源於無記憶 | AI 缺乏專案上下文，導致錯誤決策 | 記憶問題非唯一，模型推理缺陷更關鍵 |
| 設計樹提問反轉溝通 | 逐步提問釐清需求，避免 AI 假設 | 耗時且不適合簡單功能 |
| 垂直切片任務分解 | 每個 Ticket 貫穿相關層，可獨立驗證 | 可能重複工作，忽略水平基礎設施 |
| TDD 與重構分離 | red-green 循環後，重構移至審查 | 延後重構可能累積技術債 |
| 戰爭迷霧規劃法 | 只規劃可見任務，逐步清除未知 | 可能短視，忽略長期架構 |
| 程式碼異味注入 | Standards 軸檢查重複、特性嫉妒等 | 異味為啟發式，非硬性，需開發者判斷 |
| 架構是 AI 基礎 | 混亂程式碼庫導致混亂 AI 輸出 | 強調模組邊界，但重構成本可能高昂 |
這套工作流揭示了 AI 時代軟體工程的進化方向：從「寫 Prompt」轉向「設計流程」。Matt 的 Skills 倉庫本質上是一套「馴服 AI 的作業系統」，它將開發者的決策權從「讓 AI 自由發揮」拉回「人類定義問題、AI 執行細節」。對於團隊而言，導入此流程需付出的成本不僅是學習曲線，更是文化轉變——開發者必須習慣被 AI「拷問」需求，並接受更嚴格的階段劃分（如 TDD 與重構分離）。然而，這種紀律性正是 AI 穩定輸出的保障。
對個人開發者來說，最大的啟示是：不要迷信「神 Prompt」。與其花時間調校一次性的提示詞，不如建立可重複的技能組合，例如將常見的「需求釐清→規範撰寫→任務分解→TDD 實作→程式碼審查」流程模板化。這不僅提升與 AI 協作的效率，更強化了開發者自身的軟體工程素養——定義問題、設計邊界、管理技術債的能力，將成為 AI 時代的核心競爭力。
最後，Matt 的實踐也提醒我們：AI 不是取代工程師，而是放大工程師的價值。當 AI 能快速生成程式碼時，真正稀缺的是能定義「什麼是正確的程式碼」的人。因此，與其焦慮 AI 的威脅，不如將精力投入領域知識、架構設計與測試策略的深化——這些才是讓 AI 穩定工作的「隱形骨架」。
- 「AI 編程質量不高 根本不是因為它不夠聰明 而是因為AI沒有記憶」
- 「代碼應該是共識的副產品 共識才是目的」
- 「不， 軟體工程沒有死 比以往任何時候都更重要」
- 「AI降低的是生成代碼的成本 不是軟體工程的價值」
- 「真正的未來屬於懂得通過嚴格流程馴服AI的工程師」