過去輔導企業團隊進行軟體開發時，我其實不太鼓勵團隊花費大量時間撰寫詳細文件。
以往常見的做法是：專案經理認為必須先完成完整的需求文件，開發人員才能開始寫碼。但需求文件與實際開發之間，往往相隔數週甚至數月。等到真正進入實作時，需求、限制條件與技術判斷可能早已改變，文件內容也逐漸失真。
問題不在於文件本身，而在於把文件視為一次完成、後續只需要照表實作的規格。
當需求分析、系統設計與程式開發被切割成前後相接的階段，就容易落入典型的 Waterfall 思維。相較之下，Agile 強調 Iteration & Increment（迭代與漸增），讓需求分析、設計、Coding 與驗證快速形成循環，盡早取得回饋，再逐步補足功能與設計細節。
在沒有 AI Agent 的年代，我比較常使用 UML 或架構圖作為設計草稿：
- 使用案例圖：表達使用者的操作目的。
- 類別圖：表達軟體結構與責任分配。
- 循序圖：表達物件之間的互動流程。
- 架構圖：表達分層、微服務、部署與系統邊界。
這些設計圖主要是溝通與思考工具，不是追求精確與完整的規格文件。很多時候，簡單草圖甚至手繪就已經足夠。
當時的開發核心仍然是程式碼。
界定一項系統功能後，應該在幾天內完成一次可執行的 Iteration，而不是持續等待文件變得「完整」。
但 AI Agent 的出現，改變了文件在開發流程中的角色。
現在我所謂的「撰寫文件」，並不是由開發人員投入大量時間逐字編寫，而是將自己的想法、討論結果與技術調研交給 AI Agent，協助整理成結構化文檔。
這些文件主要是給誰閱讀？
首先是 AI Agent。
開發人員、使用者與利益關係人（Stackholder）當然也會閱讀，但主要用於審閱、參考與掌握重點。因此，採用 AI 與人員都容易閱讀及編輯的 Markdown，會是相當實用的文件交換格式。
開發人員也不再需要完全依照文件自行寫碼。AI Agent 可以讀取需求、架構與技術規格，據此生成：
- 應用程式碼
- 測試程式碼
- 部署腳本
- 組態設定
- 專案文件
我目前會依專案需求，逐步建立幾類文件：
- Research：技術調研與參考資料。
- Requirements：需求範圍、功能點、業務邏輯與驗收條件。
- Architecture：系統結構、模組邊界與設計決策。
- Specification：技術框架、分層規範與實作限制。
- Backlog：每次開發迭代預定完成的工作項目。
- DevLog：實際完成內容、問題處理與版本變更紀錄。
每次準備進入開發迭代前，我會先要求 Agent 整理 Backlog。完成工作後，再由 Agent 將實際結果整理為 DevLog，最後 Commit 並 Push 至 GitHub，形成可追蹤的版本與專案紀錄。
這件事其實有些諷刺。
以前我最反對開發人員花時間填寫各種 Worksheet；現在卻建立了比以前更多的文件。
差別在於：以前的文件經常是一項需要人工維護、卻很快失真的交付物；現在的文件則可以直接成為 AI Agent 執行工作的上下文、限制條件與判斷依據。
那麼，是否應該先建立完整的文件目錄與所有規格，再開始生成程式碼？
當然不是。
若堅持先完成所有文件，再開始實作，本質上仍然是 Waterfall 思維。
文件與程式碼之間沒有絕對的先後順序。真正重要的是，兩者必須隨著開發持續同步演進。
這在過去很難實現，因為文件與程式碼通常由不同人員、在不同時間分別維護。但 AI Agent 具備同時讀取規格、修改實作並回寫工作紀錄的能力，反而有機會降低兩者長期分離的問題。
我目前採用的開發循環大致如下：
最小規格／文件
⇄ AI Agent 實作
⇄ 驗證實作結果
⇄ 修訂並補充規格文件AI Agent 帶來的改變，不只是更快地生成程式碼。
更重要的是，它讓文件從靜態交付物，逐漸轉變為可以參與開發、約束實作，並隨程式碼共同演進的工程資產。