自我學習、Playbook 與 Workflow
一句話：塔台把每次收單的觀察寫進檔案、派工前拿出來比對，讓同樣的錯不犯第二次；反覆被驗證的做法一路晉升成 Playbook 和 Skill；而 Workflow 只是 Worker 在單張工單裡的執行方式，要有明文授權才能用，目前還在驗證中。
_learnings.md：三個區、一個用途
學習紀錄存在 _ct-workorders/_learnings.md，塔台啟動時讀取、運作中更新。這套機制零相依：只要 AI 能讀寫 Markdown 就能完整運作；有外部增強工具時會自動加強，沒有時這份檔案就是完整的學習系統。
v4.4.0 起，新產出的條目分進三個區：
| 區 | 放什麼 | 判斷方式 |
|---|---|---|
| 🧭 Strategic | 跨技術棧的決策原則，供塔台做架構決策時查閱 | 五年後換了技術棧仍適用 |
| 🔧 Tactical | 具體的技術操作 know-how，供 Worker 遇到具體問題時查閱 | 綁定某個語言、工具或指令 |
| 📜 Episodic | 事件日誌，還沒提煉成原則的觀察暫存在這裡 | 還沒通過提煉檢查 |
另外還有「工作流程序列」（跨技術棧的流程資產，一律視為 Strategic）和「估時校準」（每種流程的樣本數、平均時間與建議預估）兩個獨立區段。分區的理由是兩種知識的讀者不同：Strategic 給塔台做判斷，Tactical 給 Worker 解問題，混在一起時兩邊都要翻過一堆和自己無關的條目。舊格式的歷史條目以摺疊區保留，不回頭改寫。
收單後靜默記錄，派工前比對
學習有三個觸發時機：
- 每次收單後（靜默）：塔台處理完回報，自動在觀察紀錄加一行；這一輪對話中有你的糾正，就記成反模式，能歸納成規則的記成決策模式（🟡）；同時更新估時校準。這一步不顯示過程，也不問你存哪裡，一律寫進專案層。
*evolve（塔台內建精簡版）：在塔台 session 裡順手萃取最近工單的學習，可帶主題（例如*evolve estimation）。/ct-evolve（完整版）：獨立 skill，在任何 session 執行完整流程，包括模式偵測、Playbook 候選建議與全局規則評估。萃取模式只建議候選，不自己寫 playbook，寫入要另跑--playbook。塔台會在 Sprint 結束（你說「Sprint 結束」「Epic 完成」「回顧」，或累積 10 筆以上觀察紀錄還沒萃取）時主動提議；專案結案時提議全量萃取，並對 🟢 以上的候選跑--playbook，先給你看草稿，你確認後才寫 playbook。
後兩者在你確認萃取出的模式之後，會問這個模式的適用範圍：通用的存進全局層（~/.claude/control-tower-data/learnings/），只適用本專案的存進 _learnings.md，不確定的先放專案層並加 candidate: global 標記，日後再決定。
學到的東西要用得上才有意義。塔台準備派工前，會靜默比對 _learnings.md：決策模式的觸發條件和這張工單吻合時，🟢 以上的模式直接套用到工單設計並告訴你，🟡 的在工單摘要附上建議；估時校準拿來填工作量預估；吻合已知的工作流程序列時主動推薦。
每條模式都帶置信度。條件分專案層（本專案的 _learnings.md）與全域層（晉升到全域的 learnings 與規則），權威定義在 self-learning-core.md § 置信度系統：
| 符號 | 狀態 | 專案層條件 | 全域層條件 | 塔台怎麼用 |
|---|---|---|---|---|
| 🔵 | 觀察 | 首次記錄 | 同專案層 | 靜默記錄，不主動推薦 |
| 🟡 | 初步 | 一次驗證，或你確認過 | 同專案層 | 遇到匹配時建議 |
| 🟢 | 可靠 | 同一模式在兩張以上工單重複出現 | 兩個以上專案驗證 | 主動套用到決策 |
| ⭐ | 規則 | 三次以上驗證，加上你的認可 | 同專案層 | 成為塔台的預設行為 |
專案層每在新工單再次驗證、全域層每在新專案成功套用，就照上表的條件升級；你說「這個不適用」就標記廢棄，但保留歷史；連續三個專案沒觸發就進入休眠。
Playbook 引擎與 GP 編號
學習紀錄是「觀察」，Playbook 是「可執行的知識」。知識成熟度管線把兩者接起來：
Level 0：觀察（_learnings.md）
↓ *evolve 萃取＋你確認
Level 1：驗證過的規則（🟢）
↓ *evolve --playbook 晉升
Level 2：Playbook（_playbooks/*.md）
↓ *evolve --skill → /skill-creator 永久化
Level 3：Skill（~/.claude/skills/）同一模式在兩張以上工單重複出現，*evolve 就標記為驗證過（這是專案層的 🟢；全域要兩個以上專案）；驗證過的模式加上你的確認可以晉升為 Playbook；Playbook 在三個以上專案用過，由你決定要不要做成永久的 Skill。*evolve --status 顯示目前的成熟度統計。
Playbook 本身是一份工單序列：適用與不適用場景、每張工單的名稱與預估時間、品質關卡、工單模板和驗證歷史。塔台派工前會掃描 Playbook，依工單類型、技術棧與工作流程模式比對；命中時建議你套用，你可以套用、不套用或修改後套用。套用時塔台照序列逐一產生工單、加上品質關卡，並在工單標記 Playbook 來源，之後回頭更新它的驗證歷史。
全局 Playbook 的編號用命名空間前綴：GP-<PREFIX>-###，PREFIX 由設定 gp-prefix 決定，流水號只在同一個命名空間內遞增。原因是好幾座塔台共用同一個使用者環境時，舊的「全域最大值加一」規則會撞號，這已經實際發生過。改成各塔台各自的命名空間後，不需要任何同步就不會衝突。舊規則下產生的 GP001～GP094 完全凍結，不改名也不重新晉升。
三分法：Skill、Playbook、Workflow
v5.10.0 加入了 Claude Code 的 Workflow 工具（用腳本編排多個子 agent 的背景執行）之後，CT 把三種可重用產物分清楚：
| 產物 | 封裝的是 | 作用範圍 | 判斷問句 |
|---|---|---|---|
| Skill | 怎麼做（知識、規範） | 單一 agent | 每個執行者都需要這份知識嗎？ |
| Playbook | 工單序列 | 跨工單、跨 session，中間有人把關 | 這是一連串要依序完成、中途要人確認的工作嗎？ |
| Workflow | 單張工單內的編排形狀（扇出、驗證、彙整） | 單張工單之內，由 Worker 決定 | 這張工單裡有事先就能列出、彼此獨立的同形子任務嗎？ |
三者可以疊加：Playbook 裡的某張工單用 Workflow 執行，Workflow 的每個子 agent 載入 Skill。定位的關鍵一句是：Workflow 是 Worker 在單張工單內的執行方式，不是 CT 的編排層。CT 仍然只用檔案驅動的工單來編排工作，所以「CT 不是 workflow 工具」這句話仍然成立。
分界有三條提醒：重複發生在工單之間的是 Playbook，不是 Workflow；單張工單很小（約 15 分鐘內）時扇出的收益很低，只有獨立複核這類驗證值得考慮；工作量大不等於適合 Workflow，一支腳本或一條指令就能跑完的事不需要它。
設計規則 R1–R5
| # | 規則 | 為什麼 |
|---|---|---|
| R1 | 回傳格式必須能直接對應工單回報的區段 | Worker 直接拿結果填回報，不另做轉換；轉換容易漏項 |
| R2 | 有界覆蓋（取前 N、取樣、不重試）時，一律記下被略過的項目，禁止靜默截斷 | 沒被記下的遺漏，看起來就像「全部看過」 |
| R3 | 不使用 Workflow 內建的 worktree 隔離；目前只做唯讀或分析形狀 | BAT 偵測不到 Workflow 自建的 worktree，CT 的合併流程也沒有對接 |
| R4 | 子 agent 只能用唯讀工具 | 寫入集中在 Worker，才對得上 affects_files 與 commit |
| R5 | 腳本不得用當下時間或亂數；時間戳由呼叫端傳入 | 這兩個值會破壞續跑，時間戳也必須可追溯 |
R4 有一個已知的殘餘風險：唯讀型的子 agent 雖然拿掉了編輯工具，仍然有 shell。所以唯讀只能靠 prompt 明文禁止寫入，再由 Worker 收尾時用 git status 確認沒有意外改動，沒有技術上的強制手段。
要有工單明文授權
Worker 只有在工單裡有一段 Workflow 使用授權，而且寫明每一次執行的名稱或腳本、資料、目的，以及 agent 數上限與 token 事後上限時，才可以呼叫 Workflow 工具。沒有這段授權，不論在哪種模式、工作看起來多適合，都不准用，只能把想法寫進後續建議給塔台。授權以外的任何事，例如重跑、換資料、超過 agent 上限，都要先停下來問塔台。token 用量在執行中讀不到，只能每次跑完後和上限對照；超過了要記錄，下一次執行前先問塔台。
塔台寫不寫授權，看設定 workflow_integration：off 不寫；ask 每次都先問你；on 在知識卡到 ⭐ 之前也先問你。目前沒有 ⭐ 的卡，所以實際上都是「每次都問」。Worker 不讀這個設定，塔台在派工時就把結果寫進工單。Workflow 是 Claude Code 的能力，Codex 不支援，所以有授權的工單只能派給 Claude Code Worker。
Worker 自己用一般 Agent 工具開的唯讀子代理不是 Workflow，不需要授權，但必須在回報區記下用了幾個、做什麼、怎麼確保唯讀、大約多少 token，以及主 agent 抽查了什麼。
現況：G2 未通過
閘門 G2 的條件是「至少一個具名 workflow 回測達標、升到 🟡」，它沒有通過。兩張知識卡（一張工具型、一張派工型）經過三次回測，仍停在 🔵。回測留下三個教訓：
- 對抗式複核不是保險：負責反駁的子 agent 確認了一個錯誤的發現，是 Worker 回頭查證才推翻。主 agent 的抽查不能只抽「推翻前單」的發現，和前單一致的高嚴重度結論也要抽。
- 成本被低估兩到三倍：每組讀取子 agent 實際用量是卡片預估的兩到三倍，其中一次超過事後上限。
- 真正成立的扇出，多半是 Worker 自發的：沒有證據顯示具名 workflow 比單一 Worker 划算。所以 v5.11.0 改為記錄 Worker 自發的子代理用量，先累積證據。
因此具名 workflow 的派發與執行、相關的工單欄位，都「待卡片達 🟡 後再定」。這是用證據擋下升級的例子：沒過閘門，就縮小範圍、維持 🔵，而不是先上線再說。
命令範例
本頁的命令與表格都是摘要，完整參數以 reference 為準。
延伸閱讀
control-tower/references/self-learning-core.md§ _learnings.md 格式、§ 置信度系統（分專案層／全域層）、§ Global/Project 分流寫入、§ 學習觸發時機、§ 學習應用（派發前匹配）control-tower/references/playbook-engine.md§ 管線總覽、§*evolve擴展子命令、§ GP 編號規則、§ 塔台自動建議（派發匹配）control-tower/references/workflow-engine.md§ 定位、§ 三分法：Skill／Playbook／Workflow、§ 設計規則 R1–R5、§workflow_integration的行為（v5.11.0+）、§ 同意治理（v5.11.0 起落到工單授權）、§ 現況：G2 未通過（v5.11.0）ct-evolve/SKILL.md（/ct-evolve的完整流程）ct-exec/SKILL.md§ Workflow And Sub-Agents (v5.11.0+)- 本站：會學習的系統
摘要不具權威
Portal 是摘要，不具權威，與 reference 有出入時以 reference 為準。