Tim Deschryver 的 AI 開發流程
Tim Deschryver 用 AGENTS.md、skills 和 spec，把 coding agent 變成更穩定的寫碼助手，重點是少靠大 prompt，多靠專案規則。
Tim Deschryver 用 AGENTS.md、skills 和 spec，把 coding agent 變成更穩定的寫碼助手。
說真的，這篇不是在吹 AI。Tim Deschryver 是在講一套很務實的工作流。Tim Deschryver 說，他在過去一個月用 agentic AI 重寫一個專案。速度夠快，但還是得靠人做判斷。
他核心觀點很直接。你不需要一大包 prompt 才能用 AI 寫軟體。你需要的是規則、結構，還有清楚的任務拆法。講白了，就是先把專案管好，再讓 agent 幫你搬磚。
這篇文章也很適合台灣開發者。因為很多團隊現在都在玩 GitHub Copilot、Claude、GPT，但常常卡在同一件事：AI 會寫，卻不一定寫得像團隊的人。Tim 的方法，就是在解這題。
| Workflow piece | 功能 | Tim 為什麼用 |
|---|---|---|
| AGENTS.md | 放專案規則、命令、慣例 | 讓每次 agent 工作都對齊同一套標準 |
| Skills | 針對任務的 markdown 指南 | 只在需要時載入，減少上下文噪音 |
| OpenSpec | 產生 proposal.md、design.md、tasks.md | 把需求變成可執行計畫 |
他先定架構，不先丟 prompt
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
Tim 的做法很像老鳥帶新人。先把架構搭好，再讓 agent 開工。他的例子用的是 ASP.NET Core API 當後端，Angular 當前端，還有 .NET Aspire 來串整個系統。
這裡的重點不是技術棧多炫，而是邊界夠清楚。Tim 偏好 vertical slices，因為每個切片都能獨立改、獨立砍。這對 AI 很重要，因為 agent 最怕那種邊界模糊的老專案，寫兩段 code 就開始亂接。
他還提到 Angular Signals。這代表前端狀態管理也不是隨便亂塞。你先把系統設計好，AI 才有地方發揮。否則你只是讓它在一團混亂裡加速製造混亂。
- 後端：ASP.NET Core API
- 前端：Angular + Signals
- 協調層：.NET Aspire
- 架構：vertical slices
AGENTS.md 是他最先要放進 repo 的檔案
Tim 把 AGENTS.md 當成 coding agent 的預設說明書。裡面放專案規則、建置指令、測試指令、資料夾結構，還有任何 agent 每次進 repo 都該知道的事。
這招很實在。因為 AI 最常出包的地方，不是語法，而是上下文不一致。今天一個 prompt 說要跑測試，明天另一個 prompt 又忘了專案慣例。把規則集中在一個檔案，至少能少掉很多廢話。
他也提到不同工具有不同命名。GitHub Copilot 可能用 instructions.md，Claude 會看 CLAUDE.md，Claude Code 也能透過連結讀 AGENTS.md。名字不是重點，重點是你有沒有養成把規則寫下來的習慣。
“The use of the term dates back to 1911, although such riders had existed before then.”
這句引述來自 Tim 用來解釋 domestique 的段落。很貼切。開發者還是領隊，agent 只是那個在前面拉車的人。
他還建議，在資料模型複雜時，把 Mermaid 圖放進 AGENTS.md。這點我覺得很聰明。因為圖比長篇文字更容易讓 agent 抓到關係，也比口頭描述更不容易走鐘。
- AGENTS.md 要常駐在上下文
- 可放命令、慣例、架構說明
- 複雜資料模型可加 Mermaid 圖
- 專案變動後要同步更新
Skills 讓上下文更小，輸出更準
Tim 的下一層是 skills。這些是 markdown 檔，也能帶 script。和 AGENTS.md 不同，skills 只有在 agent 判斷相關時才載入。這讓它很適合處理單一任務，例如產生 component、補 test、寫文件。
這種設計很像把工具箱分格。你不會把所有工具倒在桌上，再叫人自己找。你會把螺絲起子、扳手、電鑽分開放。AI 也一樣。上下文越乾淨，結果通常越穩。
Tim 會用官方 skills 來處理 Angular、.NET、測試、TypeScript 這些主題。這表示他不是把所有知識塞進一個超長 prompt，而是讓 agent 需要什麼就拿什麼。
- skills 是任務型知識包
- 只在需要時載入
- 適合框架、測試、文件工作
- 比長 prompt 更容易維護
OpenSpec 把需求變成可執行計畫
Tim 還提到 OpenSpec。這套流程會先產出 proposal.md，再來是 design.md，最後是 tasks.md。你可以把它想成先寫提案，再寫設計，最後拆工作。
這對 agent 工作流很重要。因為很多 AI 寫 code 的失敗，不是寫不出來，而是根本沒搞懂要做什麼。OpenSpec 逼你先把需求說清楚，然後把設計和任務拆開。這樣 agent 比較不會一邊寫一邊猜。
Tim 的做法也很符合真實團隊節奏。先有提案，才有設計。先有設計，才有任務。你如果直接叫 AI「幫我做功能」，十之八九會得到一坨看起來能跑、其實很難維護的東西。
- proposal.md：先定需求
- design.md：再定方案
- tasks.md：最後拆成工作項
- 適合新功能或重構
這套方法跟其他 AI 流程差在哪
如果拿這套流程跟常見的 AI coding 方式比，差異其實很明顯。很多人現在還在用單次 prompt，丟一句「幫我改這段」就結束。這種方式快是快，但很吃運氣。只要專案一複雜，結果就開始飄。
Tim 的方法比較像工程化。AGENTS.md 負責固定規則，skills 負責局部知識，OpenSpec 負責需求拆解。三層分工之後，agent 比較像工具，不像亂猜答案的實習生。這點對大型 repo 特別有用。
你也可以把它跟 Cursor、JetBrains AI、Windsurf 這類工具的使用方式對照一下。工具再強，還是要靠專案內部的規則。沒有規則，AI 只是在更快地犯錯。
- 單次 prompt：快，但不穩
- AGENTS.md：固定規則
- skills：局部知識
- OpenSpec：需求拆解
這其實是在補 AI 的短板
AI 寫 code 最麻煩的地方，不是語法。是它不會自己知道你們團隊怎麼維護 codebase。它不知道測試要跑哪個指令，也不知道哪些檔案不能亂動，更不知道你們是不是偏好 vertical slices。
所以 Tim 的方法，本質上是在補這些短板。你把規則寫進 repo，讓 agent 每次都讀得到。你把知識切成小塊，讓它只在需要時載入。你把需求先拆成文件，再進到實作。這樣 AI 才比較像協作工具。
我覺得這也是台灣團隊很該學的地方。很多公司已經買了 AI 工具，但流程還停在手動時代。結果就是大家都很忙，AI 也很忙，最後沒人知道為什麼 code review 還是這麼痛苦。
結論：先整理 repo，再叫 AI 幹活
Tim Deschryver 這篇最實用的地方，就是它沒有把 AI 講成神。它只是把 agent 放回工程流程裡。先有架構，再有規則，再有任務拆解，最後才是寫 code。
如果你現在也在用 coding agent，我會建議你先做三件事：補 AGENTS.md、拆一個 skills、把下一個功能寫成 proposal/design/tasks。你不用一次做完，但只要開始做，AI 的輸出通常就會穩很多。
說白了，問題從來不是 AI 夠不夠強。問題是你的 repo 有沒有準備好讓它工作。