文件驅動AI工作流

👤 L2nYu2 📦 v1.0.0 ⭐ 4.5 ⬇️ 69 下載
💻 開發程式設計 免費

📖 技能介紹


name: doc-driven-ai-workflow description: 用"文件驅動"方法論管理所有 AI 輔助開發專案(新專案搭建、功能迭代、存量改造/重構/遷移等),通過 AGENTS.md 規則約束、工作分析文件、分期實施計劃、Memory.md 外接記憶四層文件解決 AI 程式設計的上下文丟失、改動失控、人機修改衝突三大痛點。所有 AI 程式設計專案都應呼叫本 skill 初始化文件體系,或當用戶提到"文件驅動"、"實施計劃"、"修改記錄"、"Memory.md"、"AI 工作流"、"AGENTS.md"、"專案初始化"時使用。


文件驅動 AI 程式設計工作流

適用於所有 AI 輔助開發專案——無論是從零搭建新專案、功能迭代,還是存量專案的漸進式改造(UI 改版、樣式升級、漸進重構、框架遷移等)。用四層文件讓跨會話的 AI 工作可控、可追溯、可回退。

觸發條件

本 skill 應在以下場景自動啟用——不僅是使用者顯式提到關鍵詞,還包括 AI 判斷當前任務滿足觸發條件時主動呼叫:

關鍵詞觸發(使用者明確提及)

  • 文件體系相關:文件驅動AGENTS.mdMemory.md四層文件鐵律
  • 工作計劃相關:實施計劃工作分析分期修改記錄改造策略
  • 工作流相關:AI 工作流AI 程式設計規範跨會話專案初始化

場景觸發(AI 應主動判斷並呼叫)

場景 說明
專案首次接入 AI 程式設計 當前專案缺少 AGENTS.md、Memory.md 等文件體系,應主動建議初始化
使用者提出多步驟開發任務 如"幫我做一個 XX 模組",需要分期拆解、上下文傳遞
跨會話的延續性工作 使用者說"繼續上次的 XX"或上下文明顯依賴前序會話
存量專案改造/重構 專案已有程式碼基礎,需要改造策略、改動範圍約束
使用者被重複問題困擾 如"上次改了又出問題了",說明缺少記憶層防重蹈覆轍
多人/多 agent 協作 需要共享上下文、統一風格和約束規則

觸發後行為

  1. 檢查文件體系是否存在:掃描專案根目錄的 AGENTS.md、Memory.md、*工作分析.md、*實施計劃.md

    小蔥技能站7w4.net發現了升級外掛。

  2. 缺失則初始化:按階段一建立缺失的文件
  3. 已有則按流程執行:按階段二的單次修改迴圈進行

核心思想

AI 會話沒有長期記憶、改動容易擴散、會覆蓋人工微調。對策:

AGENTS.md(約束) + 分析文件(上下文) + 實施計劃(分期任務)
        ↓ 每次 AI 會話
   小範圍修改 → 人工驗收/手動微調 → Memory.md 追加記錄
        ↓ 下次會話
   AI 讀 Memory.md 恢復上下文,且不覆蓋人工修改
文件 職責 一句話
規則層 AGENTS.md 每次會話自動注入的行為鐵律 限制 AI 的破壞半徑
分析層 <任務>工作分析.md 需求拆解、新舊對比、改動程度評級 改什麼
計劃層 <任務>實施計劃.md 分期任務、驗收標準、風險回退 怎麼改
記憶層 Memory.md 按日期倒序的修改流水 + 專案結構說明 改了什麼

工作流

階段一:初始化(專案首次接入 AI 程式設計時,新專案/存量專案均適用)

初始化清單:
- [ ] 建立 AGENTS.md:寫 3~5 條鐵律,不要多
- [ ] 建立工作分析文件:明確前提約束、逐區域新舊對比、改動程度評級
- [ ] 建立實施計劃文件:分期拆解,每期獨立可執行/可驗收/可回退
- [ ] 建立 Memory.md:開頭放專案目錄結構說明,正文留空待追加

各文件模板見 templates.md

AGENTS.md 鐵律的三個必備方向(按需增刪措辭):

  1. 人機衝突規則 — AI 修改後若使用者手動改過,下次修改必須保留使用者的改動
  2. 改動範圍規則 — 明確本次任務只允許動什麼(如"只改 template 和樣式,不動業務邏輯")
  3. 留痕規則 — 每次修改完必須在 Memory.md 追加記錄

實施計劃的關鍵要求

  • 分期粒度以"單次會話能完成 + 出錯可單檔案 git 回退"為準
  • 每期必須寫明:目標檔案(越少越好,第一期最好只動 1 個檔案)、改動點、驗收標準
  • 顯式寫"不在本次範圍內"清單,防止 AI 順手擴散改動
  • 預定義共享常量(如 CSS 變量表),保證多次會話產出風格一致

階段二:單次修改迴圈(每次會話執行)

會話迴圈:
- [ ] 1. 讀 AGENTS.md、Memory.md(最近幾條記錄 + 目錄結構)恢復上下文
- [ ] 2. 對照實施計劃,確認本次只做當前期內的一個小改動
- [ ] 3. 修改前檢查目的碼是否與 Memory.md 記錄不一致 → 不一致說明使用者手改過,保留使用者版本
- [ ] 4. 執行修改,嚴格遵守 AGENTS.md 改動範圍規則
- [ ] 5. 在 Memory.md 頂部追加記錄(格式見 templates.md)
- [ ] 6. 提示使用者驗收;驗收通過才進入計劃的下一步

Memory.md 記錄必須包含:日期 + 主題、修改檔案列表、修改內容逐條列出;如果是修 bug,還要寫問題原因(這是下次會話避免重蹈覆轍的關鍵)。

階段三:維護

  • 出現"改壞→修復→回退"的反覆時,每一步都記錄到 Memory.md,不要合併成一條——失敗路徑本身就是有價值的記憶
  • 專案結構變化時同步更新 Memory.md 開頭的目錄結構說明
  • 一期全部完成後,在實施計劃中標記該期狀態,再開啟下一期

反模式

  • ❌ AGENTS.md 寫成長篇規範 —— 鐵律超過 5 條就會被稀釋,細節放分析/計劃文件
  • ❌ 一次會話跨多期、動多個不相關檔案 —— 破壞"單檔案可回退"原則
  • ❌ Memory.md 只寫"優化了樣式" —— 無法恢復上下文,必須寫到檔案級和改動點級
  • ❌ 跳過分析和計劃直接讓 AI 動手 —— 多輪任務沒有共享上下文,風格和方案必然漂移
  • ❌ AI 發現程式碼與自己上次的產出不一致就"修正"回去 —— 那是使用者的手動修改,必須保留

附加資源

🤖 AI 評測

這是一套解決 AI 程式設計協作問題的實用方法論,通過四層文件讓 AI 工作更可控。文件體系設計完善,觸發條件明確,模板可直接使用。優點是思路清晰、步驟明確;不足是純文字說明缺少案例演示,對新手來說可能需要一定時間消化理解。整體質量良好,適合有一定 AI 程式設計經驗的使用者使用。

📊 多維度評分

適應性4.4
規範性4.3
有效性4.7
可靠性4.2
可信度5

📁 包含檔案 (2 個)

📄 SKILL.md 6.3 KB
📄 templates.md 4.2 KB