為什麼需要 CT

記憶交給檔案，細節交給 Worker，判斷留給你。

這一頁不講 CT 怎麼用，講它為什麼長這個樣子：它要擋住的是哪一種生產力流失，背後的思維模型是什麼，它刻意不做哪些事，以及還有哪些問題沒有答案。

起點：生產力流失在哪裡

用 AI 開發一陣子之後，很多人會同時開好幾個 session、顧好幾個專案。出事的原因多半不是 AI 不夠聰明，而是人的工作記憶裝不下那些「關於工作的工作」：

貼錯脈絡。替 A 專案寫好的 prompt 被貼進 B 專案的 session。好一點的情況，AI 帶著 A 的假設在 B 裡找檔案，燒了一堆 token 才回你「找不到」；更糟的是沒人發現貼錯，它就照 A 的邏輯改了 B 的程式。
對話越聊越長。從需求聊到實作再聊到除錯，兩小時後一開始說好的規則被擠出 context，改 A 壞 B，你只好從頭再解釋一次。
換個 session 就失憶。昨天決定了什麼、為什麼這樣決定，散在已經關掉的聊天視窗裡。
好幾個 Agent 互相踩。為了快讓它們同時開工，合併時才發現兩個都改了同一個檔案。
「做完了」不知道做到哪一層。測試跑了嗎？跑的是哪些？有沒有順手改了不該改的東西？

這些代價是乘法：每多一個進行中的專案、多一個 Agent，你要記住的元資訊就多一份，交錯切換時出錯的機率跟著往上衝。CT 的出發點只有一條：能移出腦袋的，都移出去。

CT 不是 workflow 工具，是一個小型認知作業系統

CT 的設計可以從一個同構關係推出來。它面對的限制，和作業系統面對的限制是同一組：

作業系統與 CT 的對應
作業系統	CT 對應物	共同的限制
磁碟（Disk）	檔案：工單、學習紀錄、FIELDGUIDE	跨 session 唯一可靠的共享介面
記憶體（RAM）	Context window	有上限，放滿了就會擠掉別的東西
無狀態行程（stateless process）	每一次 LLM 呼叫、每一個 Worker	結束就什麼都不記得
行程間通訊（IPC）	Worker 之間透過產出檔交接	不讀對方的推理過程，只讀結果
記憶體階層（cache 分層）	CT 的三層資料：發行版、全域、專案	依序載入，越貼近專案的層優先權越高

磁碟（Disk）
CT 對應物
檔案：工單、學習紀錄、FIELDGUIDE
共同的限制
跨 session 唯一可靠的共享介面
記憶體（RAM）
CT 對應物
Context window
共同的限制
有上限，放滿了就會擠掉別的東西
無狀態行程（stateless process）
CT 對應物
每一次 LLM 呼叫、每一個 Worker
共同的限制
結束就什麼都不記得
行程間通訊（IPC）
CT 對應物
Worker 之間透過產出檔交接
共同的限制
不讀對方的推理過程，只讀結果
記憶體階層（cache 分層）
CT 對應物
CT 的三層資料：發行版、全域、專案
共同的限制
依序載入，越貼近專案的層優先權越高

這不只是比喻。兩邊都要處理三件事：容量和速度要取捨（context window 和 RAM 都有上限）；執行單元是無狀態的，狀態只能靠外部持久化（每次 LLM 呼叫都是獨立的行程）；共享資源要協調（多個 Worker 同時寫同一區檔案，跟多個行程搶同一個資源一樣會衝突）。

從這裡出發，CT 的幾個關鍵決定就不是憑直覺，而是在這組限制下幾乎必然的選擇：

設計決定的同構解讀
CT 的設計	同構解讀
Worker 無狀態、塔台有狀態	無狀態行程配一個持久的排程者
工單是 .md 檔，不是對話	磁碟上的產出檔是跨行程唯一可靠的介面
塔台狀態寫進 _tower-state.md	情節記憶要外部化，否則清空 RAM 就沒了
塔台不寫程式、只派工	kernel 不做 user space 的事，只做排程與資源配置
Worker 回報只帶結構化摘要	syscall 回傳結果碼，不回傳整份記憶體傾印

Worker 無狀態、塔台有狀態
同構解讀
無狀態行程配一個持久的排程者
工單是 .md 檔，不是對話
同構解讀
磁碟上的產出檔是跨行程唯一可靠的介面
塔台狀態寫進 _tower-state.md
同構解讀
情節記憶要外部化，否則清空 RAM 就沒了
塔台不寫程式、只派工
同構解讀
kernel 不做 user space 的事，只做排程與資源配置
Worker 回報只帶結構化摘要
同構解讀
syscall 回傳結果碼，不回傳整份記憶體傾印

所以 CT 的重點不是「把步驟串起來自動跑」，而是管理誰記得什麼、誰讀什麼、東西放在哪裡。完整論述見認知作業系統。

三種認知負擔分別落在哪裡

認知負荷理論（Cognitive Load Theory，CLT）把工作時的心智負擔分成三種。後來的修正版本指出，第三種不是獨立的一類，而是把外在負擔清掉之後空出來、可以拿去處理真正難題的那部分。換句話說，腦力是一個總量固定的池子：花在追蹤 Agent 細節上的每一分，都是從架構判斷那裡扣下來的。

三種負擔與 CT 的處理方式
負擔	在 AI 協作開發裡是什麼	CT 怎麼處理
內在負擔（intrinsic）	工作本身的難度：這個功能要怎麼設計、規則有哪些例外	拆成一張張範圍明確的工單；實作細節交給每張工單一個全新的 Worker
外在負擔（extraneous）	跟工作無關、卻要你扛的事：現在在哪個專案、prompt 該貼到哪、誰做到哪	寫進檔案（工單、塔台狀態、決策日誌），由塔台讀；搭配 BAT 時連派工與回報都不必手動搬
增生負擔（germane）	真正花在理解與判斷上的心力	外在負擔清掉之後空出來的腦力，留給判斷：要做什麼、哪個取捨可以接受、結果算不算數

內在負擔（intrinsic）
在 AI 協作開發裡是什麼
工作本身的難度：這個功能要怎麼設計、規則有哪些例外
CT 怎麼處理
拆成一張張範圍明確的工單；實作細節交給每張工單一個全新的 Worker
外在負擔（extraneous）
在 AI 協作開發裡是什麼
跟工作無關、卻要你扛的事：現在在哪個專案、prompt 該貼到哪、誰做到哪
CT 怎麼處理
寫進檔案（工單、塔台狀態、決策日誌），由塔台讀；搭配 BAT 時連派工與回報都不必手動搬
增生負擔（germane）
在 AI 協作開發裡是什麼
真正花在理解與判斷上的心力
CT 怎麼處理
外在負擔清掉之後空出來的腦力，留給判斷：要做什麼、哪個取捨可以接受、結果算不算數

一個推論很實用：如果你覺得同時管四個 Agent 很累，多半不是因為數量太多，而是切錯了層級。在「這個 API 設計合不合理」「這兩份 schema 有沒有衝突」這種審查與決策的層級切換很便宜；在「Agent A 寫到第幾行」這種實作層級切換才貴。CT 讓你只在前者切換：你跟塔台談決定，塔台讀 Worker 的結構化回報，不讀它的推理過程。

每個設計都先問：這份負擔去哪了？

要記住、要處理的事不會憑空消失，只會換個地方放。CT 的每個設計決定都先過這一題：

負擔的去處
去處	評價	理由
你的工作記憶	最不該去	裝得不多，切一次專案就漏，也沒人能幫你檢查
檔案系統	加分	空間夠，能進版控、能 review，換 session 讀檔就接上
塔台的 context	酌情	有成本但負擔得起；所以塔台只放進度與決定，不放程式碼
skill 與模板	大加分	設計一次，之後每張工單都受益

你的工作記憶
評價
最不該去
理由
裝得不多，切一次專案就漏，也沒人能幫你檢查
檔案系統
評價
加分
理由
空間夠，能進版控、能 review，換 session 讀檔就接上
塔台的 context
評價
酌情
理由
有成本但負擔得起；所以塔台只放進度與決定，不放程式碼
skill 與模板
評價
大加分
理由
設計一次，之後每張工單都受益

這也是塔台刻意不讀程式碼的原因：程式碼一旦進了塔台的 context，就會一直佔著位置，擠掉專案目標、進度與已經做過的決定。塔台派人去看程式碼，只收結論。

工單迴圈：重複的交給流程，不同的留給判斷

每張工單走的步驟都一樣：開單、派工、執行與回報、收單、記下經驗。這一圈交給塔台與 Worker；圈裡面每次都不一樣的東西，才是你該花心思的地方。

外圈：每張工單都走的五步，交給塔台與 Worker。內圈：每張工單不同的內容，留給判斷。

只把判斷留給人：塔台代決的邊界

CT 的目標不是讓你什麼都不用管，而是讓你只管該由人判斷的事。在最自主的 yolo 模式下，Worker 有問題時不會停下來問你，而是寫進工單問塔台。塔台依一條固定的邊界決定自己答還是轉給你：

工單範圍內的技術或實作選擇：塔台依工單、決策日誌與專案慣例直接回答，並記下理由。
範圍變更、刪除或其他不可逆的操作、對外發布、需要你的偏好才能決定的選擇：塔台先問你，你回答之後才答覆 Worker。

除此之外，yolo 還有五個一定會停下來的斷點（回報異常、重試太多、超出規劃範圍、Worker 在等你、合併前），你也可以隨時輸入 停 中斷。即使不用 yolo，push、刪分支、改寫歷史這類不可逆的動作，也要工單或你明文授權才會做。細節見 yolo 與斷點與可逆與不可逆的界線。

CT 不是什麼

不寫程式碼的那一方是塔台。塔台不實作、不讀原始碼、不看原始 log，也不用背景 agent 偷偷代勞；這些都開成工單，讓你看得見。寫程式的是 Worker，而且一次只做一張工單。
不取代 BMad-Method。CT 不內嵌任何 BMad 內容。你另外裝了 bmad-guide skill，塔台才會依專案階段查出該走哪一套 BMad 流程；沒有它，塔台照常運作，流程欄位改成你手動指定，也不會自己編造 BMad 的行為。
不是全自動。auto-session 預設是 ask：每次派工前先問你。全自動的 yolo 要你自己打開，打開了也有斷點。
不是 BAT。CT 只負責編排：工單、規則、記憶與學習。開分頁、派工通知、偵測 Worker 狀態這些執行環境的事，由 BAT 負責；沒有 BAT，CT 改給你剪貼簿或一行指令。
不綁特定 Agent。核心只靠讀寫 Markdown 檔；Worker 可以是 Claude Code（/ct-exec）或 Codex（$ct-exec；用 plugin 安裝時 $ct:ct-exec），同一張工單兩邊都能執行。

還沒解決的事

CT 的設計文件會公開列出自己還沒有答案的假設，讓「這個假設可能錯了」有正式的地方放。目前包括：

Claude Code Workflow 還停在候選。Workflow 在 CT 裡的定位是 Worker 在單張工單內的執行方式，不是 CT 的編排層。實際回測沒有通過升級閘門：對抗式複核會跟著確認錯誤的發現，讀取成本也被低估了兩三倍，而真正划算的扇出多半是 Worker 自己決定開的唯讀子代理。所以目前只記錄 Worker 自發的子代理用量、累積證據，具名 workflow 先不派發。見自我學習、Playbook 與 Workflow。
塔台狀態檔扛不扛得住高頻更新。一天幾十次狀態變化時，純文字檔的成本會不會超過結構化儲存，還沒有定論。
整串都是放手執行的工單，還需要塔台中轉嗎。yolo 朝這個方向走了一段，但還沒有放棄塔台這一站。
有些既有專案可能根本不適合工單制。高度耦合、需要反覆探索的逆向工程，硬走工單反而增加負擔；CT 目前沒有「退出工單制」的正式做法。
語意上的相依還靠人工標記。派工前的重疊檢查只比對檔案路徑，「API 合約改了會影響前端流程」這種相依，目前只能靠人寫進工單。

為什麼需要 CT ​

起點：生產力流失在哪裡 ​

CT 不是 workflow 工具，是一個小型認知作業系統 ​

三種認知負擔分別落在哪裡 ​

每個設計都先問：這份負擔去哪了？ ​

工單迴圈：重複的交給流程，不同的留給判斷 ​

只把判斷留給人：塔台代決的邊界 ​

CT 不是什麼 ​

還沒解決的事 ​

延伸閱讀 ​