name: code-to-doc-generator description: "從程式碼和 UI 逆向提取業務邏輯，生成不同型別的專案文件（BRD/MRD、PRD、HLD概要設計、DDD領域設計、LLD詳細設計、編碼指南、測試文件BDD/SIT/E2E/UAT、運營手冊、SLI/SLO監控文件、CI/CD文件）。約束文件的寫作維度、分析視角和格式規範。適用於任意專案型別（Web、後端服務、移動端、桌面應用等）。觸發詞：生成文件、業務文件、運營手冊、操作指南、需求文件、PRD、BRD、MRD、概要設計、HLD、詳細設計、LLD、DDD、領域設計、測試文件、編碼指南、逆向分析、完善文件、更新手冊、同步文件、文件漂移、反向同步。" argument-hint: "文件型別（運營手冊/PRD/HLD/LLD/測試文件/反向同步）+ 可選模組範圍；留空則先詢問"

業務文件生成器

核心定位：文件漂移是熵增，不是疏忽。程式碼有 CI/lint/編譯錯誤作為反饋迴路，文件沒有——它必然腐爛。此 skill 是解法：以程式碼為真相源，持續生成或校準文件，把文件維護從"事後補救"變成"程式碼變更不可分割的一部分"。

操作角色：本 skill 以技術專家身份工作，服務於以下使用者（根據所生成的文件型別匹配）：開發者/架構師（LLD/HLD/DDD/編碼指南）、產品經理（PRD/BRD/MRD）、QA 工程師（測試文件）、SRE/運維（SLI/SLO/監控文件）、DevOps（CI/CD 文件）、運營/管理人員（運營手冊）。與使用者的互動語言保持技術精確性；輸出文件的語言和深度根據各文件型別的目標受眾獨立調整。

小蔥技能7w4.net持續更新中。

第零步：確定模式與文件型別

在做任何事之前，先明確兩件事。

模式選擇

A. 生成模式：文件不存在或需要從頭建立，從程式碼逆向提煉後生成。
B. 反向同步模式：文件已存在但可能與程式碼漂移，以程式碼為真相源校準文件。

按以下步驟確定模式：

1. 使用者提到以下任一關鍵詞 → 進入模式 B（反向同步），立即轉至 references/reverse-sync.md 按其流程工作，停止閱讀本檔案，不執行下方四輪工作流：

2. "更新文件"、"同步文件"、"程式碼改了文件沒跟上"、"文件和程式碼對不上"、"文件漂移"、"反向同步"

3. 其他情況（"生成文件"、"寫文件"、"沒有文件"、"幫我寫個 HLD/PRD/LLD"、"整理架構文件"、"出測試用例"等）→ 進入模式 A（生成），繼續下方流程。

文件型別選擇（模式 A 必須確認）

⛔ 硬阻斷規則：文件型別必須來自使用者的明確表述，不得從上下文推斷或自主選擇。 分析或生成步驟在型別確認前禁止啟動。

按以下順序判斷：

1. 使用者已明確寫出文件型別（如"幫我寫 HLD"、"生成 PRD"）→ 直接確認並繼續，無需提問。
2. 使用者未明確說明文件型別 → 立即向用戶提問並等待回答，不得根據上下文猜測後自行開始：

要生成哪種文件？（對應軟體交付鏈路的哪個階段）

立項階段
  A. BRD/MRD — 商業需求/市場需求文件，面向決策層，說明做這件事的價值與邊界

需求階段
  B. PRD — 產品需求文件，面向產品/研發，描述功能需求與驗收標準

架構階段
  C. HLD — 概要設計，面向架構師/技術負責人，描述模組劃分與關鍵設計決策
  D. DDD/領域設計 — 領域模型文件，描述核心域、聚合、領域事件

實現階段
  E. LLD — 詳細設計，面向開發者，描述介面、資料結構、流程邏輯
  F. 編碼指南 — 面向貢獻者，描述實現約定、禁忌、常見陷阱

驗證階段
  G. 測試文件（BDD/TDD/SIT/E2E/UAT）— 面向 QA/開發，描述測試場景與驗收標準

運維階段
  H. 運營手冊 — 面向操作/管理人員，說明如何使用與配置系統
  I. SLI/SLO/監控文件 — 面向 SRE/運維，描述可觀測性指標與告警策略

其他
  J. CI/CD 流水線文件 — 面向 DevOps/開發，描述釋出流程與自動化配置
  K. 管理員速查手冊 — 面向系統管理員，Q&A 格式，覆蓋所有管理功能的操作步驟與業務影響，支援按章節獨立速查

需要說明的模組範圍或特別關注點？（留空則覆蓋整個專案）

⛔ 收到使用者回答後，才能進入第一輪。在此之前：不讀程式碼、不分析結構、不建 todo 列表。

四輪工作流（模式 A 通用骨架）

每輪的關注重點由文件型別決定。
references/ 中的檔案均為按需擴充套件材料，不是必讀——只在需要完整模板或指令碼片段時才打開。

第一輪：識別專案型別與入口

1. 讀根目錄（不遞迴），識別技術棧：
2. package.json / bun.lock → Web 前端或 Node 服務
3. go.mod / Cargo.toml / pom.xml / *.csproj / requirements.txt → 後端服務
4. *.xcodeproj / AndroidManifest.xml / pubspec.yaml → 移動端
5. *.sln + XAML → 桌面（WPF/WinForms）；CMakeLists.txt / *.pro → Qt/C++
6. electron.js / main.js + renderer/ → Electron 桌面

7. 多種並存 → 多端專案，分別處理

8. 找程式入口（main.* / index.* / App.* / Program.*）。

9. 先讀現有文件（README.md、docs/、wiki/）——最快的模組清單來源。

10. 輸出：專案型別 + 技術棧摘要 + 初始模組清單，寫入 todo 工具。

第二輪：結構掃描與資訊骨架提取

按文件型別關注不同的高資訊密度位置：

可寫指令碼加速（指令碼模板見 references/exploration-strategy.md）： - 批次提取路由/選單列表 → 功能清單骨架 - 搜尋中文字串 → UI 實際文案 - 統計目錄程式碼量 → 定位核心模組

第三輪：逐模組深度分析

按文件型別決定分析重點：

• 運營手冊：對每個功能點逐一提煉七個維度——
• 操作基礎：功能入口、許可權要求、操作步驟、表單欄位含義
• 狀態影響：操作後哪些資料變化、生效時機（立即/下次請求/下次同步）、是否可撤銷
• 危險等級：不可逆操作 → ⚠️ 危險；影響範圍廣 → 📌 注意；可隨時撤銷 → 不標註
• 設計背景：為什麼有這個功能？沒有它會遇到什麼真實問題？（推斷不出則省略）
• 業務規則：公式、條件判斷、上下限；觸發的底層策略必須命名（如"負載均衡路由演算法"），不能只寫"影響路由"
• 關聯影響：改此配置後哪些其他模組/使用者受影響（表格：影響範圍 | 具體變化）
• 已知侷限：當前版本做不到的事，有無 workaround（每章 3-5 條）

每章開頭還須收集兩個固定節的素材（質檢會核查）： - 🔗 前置依賴鏈路：完整的 上游模組 ➔ 上游模組 ➔ **當前** ➔ 下游模組 鏈路（數清楚深度N），以及每個前置條件的兩種情況（有/無、開/關） - 📊 影響追蹤矩陣：本模組每個配置項 → 影響的物件 → 影響的功能 → 觸發的策略（必須命名+說機制）

格式模板見 references/document-structure.md，深度說明見 references/analysis-dimensions.md。 - BRD/MRD：提煉業務問題 + 市場背景 + 目標指標 + 範圍邊界 - PRD：提煉使用者故事 + 驗收標準（必須可測試）+ 業務規則 + 約束條件 - HLD / DDD：提煉模組/域職責 + 依賴關係 + 關鍵設計決策（含 trade-off）+ 領域事件 - LLD：提煉介面簽名 + 資料結構 + 流程邏輯（含異常路徑）+ 錯誤碼 - 編碼指南：提煉實現模式（正例+反例+原因）+ 約定規範 + 常見陷阱 - 測試文件：提煉輸入/輸出邊界 + 業務規則 + 狀態轉換 + 異常場景 - SLI/SLO：提煉服務目標 + 指標定義 + 告警閾值 + 降級策略 - CI/CD：提煉流水線階段 + 觸發條件 + 環境矩陣 + 回滾策略

• 管理員速查手冊：面向有系統許可權的管理員，Q&A 格式組織，分析重點：
• 系統定位：用一句話 + 一張 Mermaid 架構圖說明系統在業務中的角色（"使用者→閘道器→上游"鏈路）
• 設計理念：整理 3-7 條核心設計決策（分層許可權/預扣計費/路由策略等），每條說明"這樣設計解決了什麼問題"
• 讀者路徑圖：用 Mermaid flowchart 畫出「第一次部署 / 運營提升 / 遇到問題」三類讀者的推薦閱讀路徑
• 功能章節：每章以 🔗前置依賴鏈路 + 📊影響追蹤矩陣 開頭，正文全部以"如何…？"/"什麼是…？"/"為什麼…？"等問句作子標題，答案含操作步驟 + 危險等級 + 業務影響
• 附錄體系：根據專案的管理目的自行設計，不強制固定數量和名稱。常見附錄型別供參考（按需取用）：
  • 許可權快速對比表（各角色能做/不能做的矩陣）
  • 業務場景解決方案（按"我遇到的問題"索引到解決步驟）
  • 財務與計費精細化手冊（計費公式、倍率邏輯、對賬方法）
  • 運營最佳實踐（可分入門/進階/高階三級）
  • 配置速查索引、常見報錯排查、術語表等（視專案需要增減）
• 無技術術語（同運營手冊規則，完整替換表見 references/document-structure.md）

通用原則： - 遇到看不懂的邏輯，先搜尋呼叫方推斷語義 - 列舉值找定義處+使用處，理解每個值的含義 - 無法確定的細節標註 〔INFER〕，不猜測 - 每模組分析完立即整理，不攢到最後

第四輪：生成文件

按文件型別讀取 references/document-types.md 中對應型別的章節結構模板（定位到具體型別節，不需要讀整個檔案）。

通用生成策略： - 先生成骨架（所有章節標題），再填充內容，避免遺漏章節 - Mermaid 圖先用文字描述邏輯，再轉為圖語法 - 章節間交叉引用用"參見第X章"，不重複內容 - 所有 AI 推斷內容用 〔INFER〕 標註，直接從程式碼驗證的事實用 〔FACT｜檔案:行號〕 標註

完成後：儲存、同步檢查與彙報

1. 儲存：新建存到 docs/[專案名]/[文件全稱]-[系統名].md；檔名使用與使用者對話相同的語言，不使用縮寫。縮寫對應全稱：

更新則在原檔案增量修改 2. 文件同步鐵律（每次新建/更新文件後必須執行，不可跳過）：

完整反向同步任務（模式 B）額外執行六項收尾清單，詳見 references/reverse-sync.md §任務收尾強制清單。

1. 彙報：覆蓋了幾個模組、發現哪些關鍵資訊、哪些地方打了 〔INFER〕 標註

通用質量檢查

運營手冊額外檢查：

管理員速查手冊額外檢查：

這個 Skill 質量很高，專業度強。它能自動從程式碼逆向生成各種專案文件，模板規範、分析細緻，生成的文件既專業又符合實際。最有價值的特性是解決了文件與程式碼不同步的問題——程式碼改了，文件會自動校準。不過使用它需要一定技術背景，對完全不懂程式碼的普通使用者來說，配合人工指導效果會更好。