會學習的系統：Double-loop 與知識成熟度

CT 的學習不只是「下次做得更好」，還要定期回頭問「我們的假設是不是錯了」。經驗要一級一級往上長：先記成觀察，驗證過才升級，成熟了才寫成 Playbook 或 Skill，而且每一步都要有證據。

single-loop 和 double-loop 的差別

組織學習分兩種迴路：

	Single-loop	Double-loop
修正的對象	行動	目標或假設本身
例子	「spec 寫得太模糊，下次寫清楚」	「我們對 agent 分工的假設錯了，工作邊界要重新定義」

大多數團隊做到 single-loop 就停了。double-loop 難在它要質疑系統本身的設計假設，而不只是「我這次做得好不好」。

拿 CT 來說，single-loop 是「這類工單下次估時要多抓一點」；double-loop 是「塔台／Worker 這種分工，對純文件專案是不是根本不適用？」前者改做法，後者改前提。

`*evolve` 是正式的觸發器

如果只靠偶爾的反省，double-loop 很少真的發生。CT 用 *evolve 把它變成一個定期的正式流程：

text

執行工單 ──▶ *evolve 萃取模式 ──▶ 更新模板或 skill ──▶ 下次執行更好
   ▲                                                    │
   └────────────────────────────────────────────────────┘

這個迴圈本身還只是 single-loop，因為它改的是「怎麼做」。要進入 double-loop，*evolve 的產出必須回答更深的問題，例如：

塔台／Worker 的分工，對某類專案是不是不適用？
某些既有專案，是不是根本不適合工單制？
_tower-state.md 的格式，在一天幾十次狀態變化的場景下夠不夠用？

為了讓這類問題不被日常的小調整淹沒，_learnings.md 拆成三區：Strategic（跨技術棧仍成立的決策原則）、Tactical（工具或技術棧相關的操作經驗）、Episodic（還沒蒸餾的事件紀錄）。新條目要寫成「觸發、模式、行動、例子」的四欄格式，還要通過幾個語意自問（例如換一張工單，觸發條件還用得上嗎？），才能進主區；做不到的就先放 Episodic。這是用檔案結構強迫蒸餾發生，而不是等它自然出現。分流的細節見三層資料與記憶。

學習的觸發點有三個：每張工單回報後，塔台靜默記一筆觀察（使用者糾正過的，追加成反模式）；塔台內用 *evolve 快速萃取最近的工單；sprint 結束或專案結案時，用 /ct-evolve 跑完整流程。學到的東西也會被用上：塔台派工前，會拿手上的工單去比對已知的模式。

置信度：🔵 → 🟡 → 🟢 → ⭐

每一條學到的模式都有置信度，決定塔台怎麼用它。條件分兩層：專案層是本專案的 _learnings.md，全域層是晉升到使用者全域資料的 learnings 與全域規則。

符號	狀態	專案層條件	全域層條件	塔台的行為
🔵	觀察	第一次記錄	同專案層	靜默記錄，不主動推薦
🟡	初步	驗證過 1 次，或使用者確認	同專案層	遇到符合的情境時建議
🟢	可靠	同一個模式在 2 張以上工單重複出現	2 個以上專案驗證	主動用在決策上
⭐	規則	3 次以上驗證，且使用者認可	同專案層	成為塔台的預設行為

v5.12.3 之前這張表只有一欄，🟢 寫「2 個以上專案驗證」，和管線的「2 張以上工單」看起來互相衝突；其實兩者分屬專案層與全域層，現在並列。各級條件的權威定義在 self-learning-core.md § 置信度系統。

置信度會動：

升級：專案層每在一張新工單再次驗證、全域層每在一個新專案成功套用，就照上表的條件升級。
降級：使用者說「這個不適用」，標記為廢棄，但保留歷史。
休眠：連續 3 個專案都沒觸發，標記為休眠。

派工前的比對也照置信度分級：🟢 以上自動套用到工單設計並告知使用者；🟡 只在工單摘要裡附上建議。估時校準和已驗證的工單序列，也會在這時一起帶上。

保留廢棄紀錄、讓不用的模式休眠，是為了不讓學習紀錄只增不減。一條錯的規則如果只能被刪除，日後就沒人知道它曾經錯過、為什麼錯。

知識成熟度管線：觀察 → Playbook → Skill

從工單學到的經驗，不該永遠停在零散的筆記。CT 定義了四級成長：

觀察
L0 · 塔台記下 · 🔵
工單執行中發現的模式，先記成 _learnings.md 裡的一條觀察（🔵 new）。
驗證
L1 · 兩張以上工單之後 · 🟢
同一個模式在兩張以上工單重複出現，*evolve 把它標成 validated（專案層的 🟢；全域層的 🟢 要兩個以上專案）；之後派發前比對到類似情境，塔台會主動帶上。
Playbook
L2 · 你決定
已驗證、且你確認之後，用 *evolve --playbook 寫成 _playbooks/ 裡的標準操作程序。
Skill
L3 · 你決定
Playbook 在三個以上專案用過，*evolve --skill 只產出 skill brief；要不要真的安裝成 skill，由你決定。

晉升	條件	由誰觸發
L0 觀察 → L1 驗證	同一個模式在 2 張以上工單重複出現（也就是專案層的 🟢；全域層的 🟢 要 2 個以上專案）	`*evolve` 自動標記
L1 驗證 → L2 Playbook	已驗證，且使用者確認	`*evolve --playbook`
L2 Playbook → L3 Skill	Playbook 在 3 個以上專案用過，且使用者決定	`*evolve --skill` 產出 brief，再由使用者執行 skill-creator

設計理念是：知識不該一步到位。 觀察先沉澱、驗證，再逐步提煉成正式形式；太早寫成規範，只會得到僵化的規則。

L3 刻意停在 brief、不自動安裝，是因為已安裝的 skill 會被所有 session 載入，那是使用者的決定，不是塔台的。這也呼應可逆與不可逆的界線：影響所有 session 的改動，需要人明確點頭。

v5.10.0 之後，管線多了一條分支。有些經驗的形狀不是「一串工單」，而是「一張工單之內的平行讀取或複核」。這類候選不走 Playbook，改寫成 Workflow 知識卡，成熟度同樣分 🔵 → 🟡 → 🟢 → ⭐，但多了依指標降級。判斷方式是：重複發生在工單之間的，是 Playbook；發生在單張工單之內的，才考慮 Workflow。

用證據決定升不升級

晉升條件之所以寫成「幾張工單、幾個專案、使用者確認」，是為了讓「升不升級」由證據決定，而不是由熱情決定。CT 自己就照這條規則否決過自己的提案。

稽核或審查型的 Workflow 知識卡要升到 🟡，必須先回測：拿已結案工單的已知發現對照，召回率至少 80%、誤報率不超過 20%。v5.10.0 寫好規則後，CT 真的拿兩張卡去回測，花了大約 1.8M tokens，兩張都沒有達標。回測還留下三個教訓：

對抗式複核不是保險。 負責唱反調的子 agent 也確認了一個錯誤的結論，最後是 Worker 回到程式碼快照親自查證才推翻。
成本被低估 2 到 3 倍，而且執行中讀不到用量，上限只能事後對照。
真正有效的平行讀取，多半是 Worker 自己決定的，不是具名 workflow 帶來的。

所以 v5.11.0 沒有做「自動派發 workflow」，改做幾件便宜的事：Workflow 要有工單授權才能用、Worker 自己開的子代理要在回報區記帳，先把證據累積起來。一個沒有通過驗證的機制，不會因為「看起來很有用」就上線。

案例頁收錄了這類「用證據決定」的實例，見實戰案例。

讓系統公開質疑自己

doctrine.md 的最後一節叫「開放問題」，公開列出 CT 自己還沒解決的設計假設：狀態檔格式撐不撐得住高頻更新、全部是 fire-and-forget 的工單串還需不需要塔台、某些專案是不是不適合工單制、語意依賴能自動化到哪裡（詳見認知作業系統）。

一份工具的官方設計文件，公開寫出自己的不確定，很不尋常。但這不是謙虛，而是替 double-loop 留一個正式的歸檔位置。如果設計文件只展示「做對的事」，使用者就沒有地方貢獻「這個假設可能錯了」的觀察；開放問題等於宣告「這些地方我們還不確定，歡迎挑戰」。

任何聲稱會「自我學習」的工具，都應該有類似的結構。沒有的話，所謂的學習，只會停在 single-loop。

會學習的系統：Double-loop 與知識成熟度 ​

single-loop 和 double-loop 的差別 ​

*evolve 是正式的觸發器 ​

置信度：🔵 → 🟡 → 🟢 → ⭐ ​

知識成熟度管線：觀察 → Playbook → Skill ​

用證據決定升不升級 ​

讓系統公開質疑自己 ​

延伸閱讀 ​