技術文件自動生成
從程式碼註解到 API 文件到架構圖 —— 寫完程式碼文件就出來了
文件這個坑，誰踩誰知道
文件永遠跟不上程式碼
程式碼改了 20 遍，README 還是三個月前的版本。新人入職看文件，照著跑一遍全是報錯，問了才知道"那個文件過時了"。
沒人願意寫文件。開發說"程式碼就是文件"，產品說"你先寫我再看"，最後誰也沒寫，靠口口相傳。
好不容易寫了一份 API 文件，上線改了兩個欄位忘了同步，前端同事對著舊文件調了一下午，過來找你算賬。
讓 OpenClaw 幫你把文件這事給辦了
讀程式碼，寫文件，保持同步
OpenClaw 直接讀你的源程式碼 —— 函式簽名、參數型別、返回值、註解、呼叫關係，全部分析清楚，然後生成結構化的文件。
不是那種"這個函式接收一個參數"的廢話文件。它會寫清楚每個介面的用途、參數說明、返回示例、錯誤碼，該有的都有。
程式碼改了？再跑一次 Prompt，文件自動更新。再也不用擔心文件和程式碼脫節了。
文件生成 Prompt，直接用
從 README 到 API 文件到架構圖，三條 Prompt 全搞定。
專案 README 一鍵生成
新手友善
分析這個專案的完整程式碼結構，生成一份專業的 README.md。
包含以下章節：
1. 專案簡介：一兩句話說清楚這個專案幹嘛的
2. 功能特性：用 bullet points 列出核心功能
3. 快速開始：安裝、配置、執行的步驟（要能直接複製粘貼）
4. 專案結構：目錄樹 + 每個目錄的簡要說明
5. 配置說明：環境變數、配置檔案的說明
6. API 簡要說明（如果有的話）
7. 常見問題
風格要求：簡潔清晰，別寫廢話。示例程式碼要完整可執行。這條最適合新專案。跑一次就有一份像樣的 README，比自己從空白開始寫快了十倍不止。老專案也能用，生成後再微調。
API 介面文件生成
黃金指令
讀取專案中所有的 API 路由/控制器檔案。
為每個介面生成標準的 API 文件（Markdown 格式），包含：
1. 介面路徑和請求方法（GET/POST/PUT/DELETE）
2. 功能描述：這個介面幹什麼用的
3. 請求參數：參數名、型別、是否必填、說明、示例值
4. 請求體示例（JSON 格式）
5. 響應示例：成功和失敗的返回值
6. 錯誤碼說明
7. 認證要求（如果需要 token）
按模組分組，加上目錄導航。後端開發必備。一個 Prompt 把所有介面文件都生成了，前端同事再也不用追著你問"這個介面參數是什麼"了。
專案架構圖（Mermaid）
進階技巧
分析這個專案的完整程式碼結構和模組依賴關係。
生成以下 Mermaid 圖表：
1. 系統架構圖（flowchart）：
- 展示主要模組和它們的交互關係
- 標註資料流方向
- 區分前端、後端、資料庫、第三方服務
2. 模組依賴圖（flowchart）：
- 展示程式碼模組之間的 import/依賴關係
- 標註核心模組和工具模組
3. 資料流圖（sequenceDiagram）：
- 展示一個核心業務的完整請求鏈路
- 從使用者操作到資料庫再到返回
每張圖附帶文字說明，解釋關鍵的設計決策。架構圖是最難手畫的文件。這條 Prompt 生成的 Mermaid 圖可以直接貼到 Notion、GitHub Wiki 或者飛書文件裡渲染。
文件生成：OpenClaw vs ChatGPT
都能生成文件，但方式完全不一樣。
OpenClaw
- 直接讀專案源程式碼，文件基於真實程式碼生成
- 理解檔案之間的引用關係，API 文件準確完整
- 程式碼更新後重新生成，文件自動同步
- 支援生成 Mermaid 架構圖、時序圖
VS
ChatGPT
- 需要手動複製粘貼程式碼，上下文有限
- 看不到完整專案結構，容易遺漏介面
- 生成的文件是一次性的，程式碼改了得重新貼
- 大專案程式碼超出 token 限制，沒法一次處理
文件生成的幾個竅門
生成 API 文件時，讓 OpenClaw 同時生成 Postman/Insomnia 的導入檔案，前端同事可以直接導入測試。
如果程式碼裡有 JSDoc、docstring 或 Swagger 註解，在 Prompt 裡提一句，AI 會基於這些註解生成更準確的文件。
README 和簡單文件用 GPT-4o 就夠了，速度快、格式穩。架構分析和複雜依賴關係的文件上 Claude Opus 4.6，理解更深。