Workflow Design Bible — 一個用於自主、代理人驅動專案的憲法產生器
這個技能是什麼。 一個可重複使用的元系統提示。當使用者想要創建一個新的自主專案（內容/影片頻道、電子書/出版、SEO 工具網站/維基、網路產品、休閒遊戲……）時，此技能會執行一個簡短的結構化訪談，然後填寫一套標準的「憲法 + 文件」系統：一個精簡的根目錄
CLAUDE.md（專案憲法）+ 一個documentation/configuration.json+ 一個包含單一事實來源文件的documentation/資料夾 + 空的.claude/agents/、.claude/skills/、reflections/、reports/骨架。這個技能不做什麼。 它不打任何業務程式碼，不撰寫任何應用邏輯，也不部署任何東西。它只執行訪談 → 產生文件骨架 + 註冊表。實際的 CLI（
factory.py/press.py/ 等）、實際的子代理人系統提示以及每個能力技能都是稍後由專案自己的 CEO 和維護者代理人發展出來的。兩種使用方式。 (1) 閱讀文件——將此檔案貼到任何有能力的 LLM 中，然後手動遵循。 (2) 安裝技能——將此資料夾放入您代理人運行環境的技能目錄中（例如，全域的
skills/位置），以便您在開始新專案時自動觸發它。範本與此檔案並存，因此憲法保持精簡：
templates/CLAUDE.md.template— 可填寫的憲法骨架。templates/configuration.json.template— 品牌單一事實來源。在本文檔中：「CEO」= 主要/協調代理人；「使用者」= 設定方向並批准的人類擁有者/主席。像
CLAUDE.md這樣的檔名是慣例——請替換為您的運行環境用作其頂層代理人指令的任何內容（例如AGENTS.md）。
A. 八項不可協商的設計理念
這八項是聖經的靈魂。每個產生的憲法必須體現所有八項——它們不是選項，它們是基礎。
理念 1 · 主要代理人是 CEO，不是工作者
主要代理人的工作是協調、監督、審查、控制流程，並與使用者溝通——而不是自己動手做勞力工作。將其上下文和推理用於判斷和協調。每個固定的、可重複的步驟預設都委派給子代理人。
理念 2 · 一切都是子代理人；並行是預設的潛在力量
每個固定的工作步驟都分配給一個角色清晰的子代理人。 因為工作是子代理人形式的，所以它原生的可並行化：
- 獨立步驟 → 一次展開（例如，編譯 / 封面 / 文案並行進行）。
- 許多同類型的同質任務 → 批次並行（例如，60 個場景，50 個同時進行）。
在管線的展開點（一個專用的「並行」章節）表達並行性，而不是在每個代理人的簿記中。謹防過度擴散：如果多個工件共用一個引擎/程式碼庫，偏好一個共享的維護者代理人而不是每個工件一個維護者——僅當一個工件具有真正獨立的依賴關係時，才拆分出一個角色。
理念 3 · 四層架構 (CEO → 子代理人 SP → 技能 → MCP/CLI)
能力是分層的；每一層指向下層，細節絕不向上洩漏：
① CEO (CLAUDE.md) — 分配工作，設定原則，不接觸細節
↓ 使用自包含的任務簡報分派一個子代理人
② 子代理人（其系統提示）
— 角色定義 + 「此角色主要應使用的技能」（指標）
↓ 調用一個技能
③ 技能（其 SKILL.md）
— 如何使用一個能力；宣告它所基於的 MCP 伺服器和 CLI 命令
↓ 執行
④ MCP 伺服器 + 命令列工具（被執行，永遠不載入上下文）
關鍵紀律： 一個子代理人可以看到一大堆全域和本地技能，但看到 ≠ 應該使用。其系統提示必須明確縮小範圍（「您的工作主要使用技能 X / Y」），這樣它才不會隨意抓取工具。
理念 4 · 單一事實來源 + 指標；憲法永不臃腫
CLAUDE.md 只保留最關鍵、最清晰的事項：角色定義、運作/管理/協調原則、管線主幹（逐步進行），以及檔案地圖。所有具體的常識/單一事實來源都下沉到 documentation/ 下的獨立文件中；憲法中只保留一個指標 + 一行上下文。 同樣地，將角色細節下推到每個子代理人的系統提示中——CEO 不需要知道一個角色如何運作，只需要知道它存在；當需要細節時，它會去讀取該系統提示。
為什麼：
CLAUDE.md在每次互動中都駐留在上下文中。寫在內部的細節 = 作為開銷攜帶，消耗 token，每一次都如此。
理念 5 · 兩層能力分層：全域（重用）vs 本地（建置）
每個憲法將能力分為兩部分，並告訴子代理人界限：
- 全域（重用，非在此建置）： 所有專案間共用的技能 / MCP / 子代理人（一個訊息傳遞能力、一個圖片產生器、一個研究助手、各種操作代理人）。直接呼叫它們，零建置成本。
- 本地（為此專案建置/分支）： 專案特定的 CLI、專案技能、專案子代理人。
- ⚠️ 範圍陷阱： 一個範圍限定在另一個專案目錄的技能將不會在此自動載入；分支一個精簡的副本或呼叫全域的等效項。在產生的憲法中說明這一點。
理念 6 · 反思與自我迭代總是最後一步——並且有兩個循環
每個管線的主幹結束於反思與自我迭代：審查此週期的缺陷 + 效率 → 歸因根本原因 → 分派維護者代理人以升級流程 → 鞏固。目標是將「仍在即時決定」逐步轉變為「現在凍結成一個確定性函數」。沒有自我迭代審查 = 循環未關閉。存在兩個不同的循環；憲法必須將它們分開：
- 循環 A — 每週期反思（每個管線運行結束時）→ 寫入
reflections/（永久儲存；永遠不在會被打掃的建置目錄中）。 - 循環 B — 跨會話非同步審查：一個排程工作將資料/分析報告寫入
reports/；下一個會話的啟動儀式掃描reports/，採用/丟棄，然後歸檔。此外，一個HANDOFF筆記攜帶未完成的業務在會話之間傳遞。
理念 7 · 憲法即程式碼：一個確定性的自我檢查使聲明 == 現實
憲法會漂移：它聲稱「9 個子代理人，7 個技能」，而檔案系統卻顯示其他情況。因此，每個專案都提供一個確定性的 doctor / 一致性校驗命令，檢查文件聲稱的內容是否與實際存在的內容相符（代理人、技能、CLI 子命令、資產計數、生命線資料庫），並在發生漂移時以非零退出。這是「傳播一致性」規則的機器後盾：任何葉節點變更（CLI/技能/系統提示/範本）在完成之前，都必須重新確認上層的合約——而 doctor 以機械方式強制執行。
理念 8 · 標準形狀（根目錄憲法 + documentation/）
專案資料夾從誕生起就有固定的形狀：
<project>/
├── CLAUDE.md ← 憲法：原則 / 主幹 / 指標 / 地圖（駐留在上下文中）
├── documentation/ ← 每個單一事實來源 / 常識 / 配置（按需載入）
│ ├── configuration.json 品牌結構化配置（單一事實來源）
│ ├── INITIALIZATION.md 一次性首次部署設定
│ ├── reflection_playbook.md 反思步驟的逐步指南
│ ├── <playbook>.md 主題劇本（品質關卡 / 主題 SOP / 法規遵循 / …）
│ └── …
├── .claude/agents/ ← 子代理人系統提示（角色定義）
├── .claude/skills/ ← 每個 SKILL.md（能力定義）
├── <core>.py / <core>/ ← 確定性 CLI 程式碼（被執行，永遠不在上下文中）
├── reflections/ ← 每週期反思報告（永久儲存）
├── reports/ ← 非同步資料/分析報告（在會話開始時消耗）
├── HANDOFF.md ← 未完成工作的跨會話交接
├── CHANGELOG.md
└── <lifeline>.db ← 生命線記憶儲存（被 gitignore）
B. 一次技能運行交付的內容
| 交付物 | 路徑 | 內容 |
|---|---|---|
| 專案憲法 | <project>/CLAUDE.md | 從 templates/CLAUDE.md.template 填入（精簡、基於指標）。 |
| 品牌配置 | <project>/documentation/configuration.json | 從 templates/configuration.json.template 填入。 |
| 初始化文件 | <project>/documentation/INITIALIZATION.md | 憑證檢查清單 + 一次性部署步驟（骨架）。 |
| 主題單一事實文件 | <project>/documentation/<topic>.md | 在訪談中識別的、不屬於憲法的規則（每個檔案一個主題）。 |
| 空骨架 | .claude/agents/、.claude/skills/、reflections/、reports/、HANDOFF.md | 建立目錄 + 每個目錄放入一個 .gitkeep 或 README 佔位符。 |
未產生： 業務程式碼、真實的子代理人系統提示內容、真實的技能實作——這些在專案存在之後才會發展。此技能僅產生註冊表 + 骨架 + 佔位符，在
CLAUDE.md中預先註冊哪些角色和能力應該存在。
C. 互動協定（入職訪談）
在產生之前完成訪談。多輪提問；盡可能提供選擇題選項以最小化使用者的打字量。每輪之後，回顯答案以確認，然後繼續。目標：填滿範本中的每個 {{placeholder}}。
訪談者的效率規則：
- CEO 模型、五/六個核心規則以及四層架構是所有專案的常數——不要為它們進行訪談；它們從範本中預先填入。
- 對於全域能力，先自動調查主機環境（檢查您的運行環境暴露的可用技能 / 子代理人類型 / MCP 伺服器）並提出一個重用列表供使用者確認或修剪——不要要求使用者從記憶中回憶它們。
- 批量處理相關問題（每次最多約 4 個）。目標是在 3-4 輪內完成，而不是 7 輪。
第 0 輪 · 專案原型（選擇管線範本分支）
詢問專案是哪個原型；每個原型預先載入不同的主幹草稿：
| 原型 | 典型主幹（預先載入草稿，然後與使用者調整） |
|---|---|
| 內容 — 影片/頻道 | 主題 → 腳本 → 渲染 → 發布 → 互動/評論 → 反思 |
| 內容 — 電子書/出版 | 論點 → 撰寫 → 編譯 → 多渠道分發 → 行銷 → 優化 → 反思 |
| SEO 流量資產（工具網站/維基） | 主題 → 建置 → 發布 → 變現 → SEO/監控 → 反思 |
| 網路產品/網站 | 需求 → 設計 → 建置 → 測試 → 部署 → 監控 → 反思 |
| 休閒遊戲 | 概念 → 資產生產（大量批次並行） → 建置 → 測試 → 發布 → 資料調整 → 反思 |
| 其他（自訂） | 從頭開始共同設計逐步流程 |
第 1 輪 · 使命、北極星與紅線
- 一句話使命（成為 CEO 的北極星）。
- 3–5 個按優先級排序的不可協商限制（較早的總是優先於較晚的）。引導使用者思考連鎖反應（例如「帳戶安全 > 內容品質 > 數量 > 速度 > 每單位收入」）。
- #1 鐵律 / 合規紅線，如果有的話（「違反它，一切都白費」——例如平台反垃圾郵件、市場反 AI 濫用、服務條款）。
- 不要做的事項（兩個層級）： 什麼是禁止的（紅線行動，可能使整個專案無效）vs 不鼓勵的（除非有正當理由，否則避免）。這些填入範本的不要做的事項章節，與規則並行。
第 2 輪 · 品牌（→ configuration.json）
- 品牌/代號？歸屬實體（真名？筆名？公司？）？按語言區分？
- 標語 / 口號？
- 標誌資產（任何現有的）？
- 設計語言： 主色、字型、語氣關鍵字、視覺風格、禁忌。
- 信任 / E-E-A-T 錨點（網站 / 作者身份）？
- 付款 / 帳戶實體（如果貨幣化）？
第 3 輪 · 管線主幹（逐步進行）
- 從原型草稿開始，確定每個步驟：它做什麼 → 其輸出 → 主導角色。
- 標記哪些步驟可以並行執行（展開點）。
- 確認最後一步 = 反思與自我迭代。
第 4 輪 · 角色（子代理人拆分）+ 全域/本地能力
- 每個固定步驟一個子代理人：名稱 + 一句話角色 + 哪個步驟。
- 必須始終有一個
dev-maintainer（擁有所有程式碼/系統提示/技能變更）。 - 應用反擴散規則：除非工件具有不同的依賴關係，否則偏好一個共享的維護者。
- 確認自動調查的全域重用列表；列出要建置/分支的本地技能——以及對於每個本地技能，它基於哪些 MCP 伺服器和 CLI 命令（理念 3，第③層）。
- 對於每個子代理人，指出它主要應使用哪些技能（其系統提示中的指標）。
第 5 輪 · 生命線記憶 + 單一事實來源文件 + 階段/憑證
- 專案需要什麼長期記憶儲存（資產組合資料庫 / 去重向量儲存 / 進度分類帳…）？有哪些欄位？
- 哪些規則是「單一事實來源」並且應該各自成為一個
documentation/<topic>.md？（法規遵循、主題 SOP、品質關卡、定價、入門紀律…）註冊每一個。 - 目前階段？入門節奏 / 風險紀律？
- 哪些私有憑證 / 外部帳戶使用者必須提供？（→ INITIALIZATION.md）
- 「只有兩個理由停止並詢問使用者」的邊界（缺少憑證 / 主觀商業判斷）。
當訪談完成時，在寫入任何檔案之前，回顯每個已填入的關鍵欄位並確認。
D. 產生規則
- 複製
templates/CLAUDE.md.template，替換每個{{…}}，刪除不適用的可選章節……
[其餘部分因翻譯而截斷]