組織如何架構 AI 工作的參考模型
Jose Martinez · 2026 年 10 月 1 日 · v1.8.1（於 Claude Code 中實測；並於 2026 年 10 月 1 日對照 Anthropic 文件重新驗證）
五句話摘要。
- 組織是樹狀結構：公司、業務線、專案、任務。但 Claude 的專案是扁平的：聊天介面只有一個 3,000 字元的組織區塊，聊天與 Cowork 中的專案無法巢狀化或繼承，而且在專案裡，connector 帳號要嘛屬於個人、要嘛屬於整個組織，絕不會屬於某個分支。
- 於是每個專案都拿到一份手動複製的業務線規則，副本之間逐漸產生分歧，也沒人看得出哪個答案是由哪條規則產出的。
- Anthropic 其實已經把這棵樹建過兩次了。Claude Code 依資料夾巢狀載入指令，而且從 2026 年 10 月 1 日起，組織的 mod 會優先於個人的 mod 執行。Slack 裡的 Claude Tag 則能從組織、工作區一路繼承指令與憑證到頻道。但兩者都還沒延伸到「專案」。同樣的模式其實做得到：加一層業務線、讓專案從對應資料夾生成、為任務加上型別、用編譯器在模型看到之前就擋掉衝突，並為每個節點設定能在 Team 方案上運作的權限。
- 我在 Claude Code 裡實測了兩次。當一條組織規則與一條專案規則互相矛盾，分別放在不同層級的 CLAUDE.md 且都沒有標記為強制時：專案規則 20 次全贏。把同一條組織規則用文字標記為強制執行後：它 20 次全贏。優先順序是靠任何編輯任一層級的人都能改掉的措辭決定的，而不是靠結構。
- 這套做法今天就能跑。我寫了一個桌面應用程式，讓 Claude Code 在這棵樹狀結構裡運作。它把每一層掛載成一個 CLAUDE.md，限制 Claude 只能做該使用者在這個節點上被允許的事，在寫入當下就擋掉衝突，並記錄每個答案對應的規則、token 數與審核者。實測下來，樹狀結構載入的指令 token 比扁平副本少了 20–34%。
組織是樹狀的。公司制定政策，業務線訂定標準，專案把標準套用在一件工作上，而任務交付一項成果。我待過的每一套品質系統都是這樣建的，幾乎每家公司的檔案伺服器資料夾樹也是：公司、業務線、年份，接著每件工作一個資料夾，用一個把所有資訊都編碼進去的工號命名。
AI 專案卻是扁平的。我以 Claude 為例，因為它是我每天工作的產品，也因為它已經在自己的兩個介面裡交出了答案。在 Claude 聊天介面中，專案不能巢狀化，而組織指令是一個最多 3,000 字元、對所有人一體適用的單一區塊。在 Enterprise 方案上，管理員可以依群組劃分權限範圍。在 Team 方案上，角色適用於整個組織。聊天或 Cowork 的文件裡，沒有任何機制能把指令往下傳到部門或業務線，再傳進它的專案。在 Enterprise 上，skills 和專案可以分享給群組，但那是「散發」，不是「繼承」。
這就是缺掉的那一層：介於組織與專案之間的那一層。本文要說明缺了什麼、為什麼重要、實際代價有多高，以及一套任何平台都能實作的參考模型，包含它的權限與資料結構。
1. 目前有什麼
於 2026 年 9 月 29 日至 10 月 1 日對照 Anthropic 文件查核。Claude 有四個團隊工作會用到的介面，各自有不同的指令模型：
權限取決於方案：
Anthropic 已經為權限建好了半棵樹。在 Enterprise 上，自訂角色會指派給群組；「自訂角色也能控制該角色可以使用哪些 connector，以及這些 connector 上的哪些工具」；在整個平台上，組織、角色與使用者三個層級「以最嚴格的層級為準」，而一位成員的多個角色會疊加；管理員可以「檢視有效角色」，並附上「授權來源」標籤；群組也可以有自己的支出上限。但這些是扁平的群組，不是樹，而且沒有一項延伸到指令。最接近的是 plugin：在 Enterprise 上，擁有者可以讓某個 plugin 及其 skills 對特定群組成為必要或預設安裝，並有明確的順序（「先群組設定，再全組織設定，最後是 marketplace 預設值」）。但這針對的是一群「人」，不是專案；專案之間沒有繼承，而且 skill 仍然只在 Claude 判斷相關時才會載入。Team 的角色適用於整個組織，分享也只能逐人進行；用文件的話來說，它的 plugin 設定「沒有群組設定」。而 Team 正是為中小型企業打造的方案。
Anthropic 已經在專案之外，把整棵樹建過兩次了。
在 Claude Code 裡，依資料夾。 Claude Code 會從四個層級載入 CLAUDE.md 檔案；「所有找到的檔案會串接成 context，而不是互相覆蓋」，順序是「從檔案系統根目錄往下到你的工作目錄」，而子目錄中的檔案「按需載入」。組織的區塊可以用受控檔案的形式送到每台機器，或從管理主控台以文字形式下發（claudeMd 鍵）。文件對限制說得很坦白：Claude 把這些檔案「當作 context，而非強制執行的設定」，而且「如果兩條指令互相矛盾，Claude 可能會任意挑選其中一條。」
在 Claude Tag 裡，依 Slack 頻道。 Claude Tag 就是團隊 Slack 裡的 Claude，目前在 Team 與 Enterprise 上處於公開測試階段。它的設定會綁定到一個 scope，而「scope 是指 bundle 適用的地方：Default Slack access（全組織的根）、工作區，或單一頻道。」本文後面要求的三件事，這裡都已經有了：
• 指令會繼承。「各 scope 的自訂指令會串接起來，先是 Default Slack access，再來是工作區，最後是頻道。頻道的指令是『累加』在上層設定之上，而不是取代。」
• 憑證屬於分支。在頻道裡，Claude 是用管理員綁定到 scope 的服務帳號來動作，而且「會使用範圍最窄的憑證：頻道勝過工作區，工作區勝過 Default Slack access。」
• 你可以看出權限來自哪裡。每一列 connector、repository 與 plugin 都會標示「繼承自」較大的 scope，或「附加自」某個 bundle。支出上限可設在全組織與各頻道，報表也依頻道產出。
限制同樣寫在文件裡。這棵樹長得跟 Slack 一樣：三個固定層級，而 Slack 頻道不能巢狀化。指令是「指引，不是強制護欄」，文件也沒有描述任何跨 scope 的衝突檢查機制。「沒有每項任務與提出者的逐動作紀錄」。而且它在專案邊界就停了：「claude.ai 裡的專案不適用；Claude 在 Slack 裡不會讀取 Project 的指令或知識，頻道也不能指向 Project。」
2026 年 10 月 1 日改變了什麼。 Claude Code 2.1.287 啟用了原本處於搶先體驗階段的 mod：它是 plugin 裡的函式，在 Claude Code 內部執行，可以改寫 prompt 或 system prompt 的某一段、阻擋或改寫 tool call、核准或拒絕權限請求，還能在介面裡繪製窗格。其中有三點與本文相關：
• 它們有宣告好的順序。內建的 guard 與組織自己的 mod 先執行，接著才是個人安裝的 mod。「第一個 mod 在最外層：它比其他 mod 更早看到事件、更晚看到結果，並決定其他 mod 到底要不要跑。」在 guard 載入的地方（一台有受控設定的機器，或 Team／Enterprise 登入），個人的 mod 無法更改「system prompt、你受控的 CLAUDE.md 以及其他受控指令」，也無法核准被 deny 規則擋下的 tool call。這就是由結構決定的優先順序，也正是本文所要求的。但它是預設值，不是鎖：用 --safe-mode 啟動 Claude Code 的人會在不安裝任何 mod（包含組織的 mod）的情況下執行，不過受控 hook 與 deny 規則依然生效。
• 順序有兩個主人。組織的 mod 預設在個人的 mod 之前執行，但如果組織選擇，也可以排在後面。這裡沒有「業務線」這一層。從管理主控台下發的設定「會一致套用到組織內所有使用者。尚不支援依群組設定。」想為不同群組制定不同政策的組織只有兩條路，都得透過 IT：為各群組的機器部署不同的設定檔，或跑一個自架 gateway「依 IdP 群組下發受控設定」。
• 它們進不了聊天介面，對 Cowork 的支援也不一致。「mod 可在 Claude Code CLI 與 Claude Desktop app 的 Code 分頁中運作。」mod 是隨 plugin 的 hooks/hooks.json 一起出貨的，而 Anthropic 的 plugin 支援表把這個檔案在聊天介面標記為「Ignored」。同一張表在 Cowork 標記為「Loads」，因為「Claude Desktop app 裡的 Cowork 是在 Claude Code 上執行 session」；但 mod 的頁面並沒有列出 Cowork，我也還沒測試過。組織在那裡能控制的東西更少：在 Cowork session 裡，Claude Code「絕不會從 claude.ai 管理主控台抓取伺服器端受控設定，即使使用者用 Team 或 Enterprise 帳號登入也一樣」，而遠端 Cowork session 根本沒有裝置政策可讀。
正在 rollout 的部分。 Cowork 正併入 Claude：說明中心現在寫著「Claude Cowork 現在就是 Claude」，先在 Pro 與 Max 上實施，而 Team 與 Enterprise「維持聊天與 Claude Cowork 現有的樣子」。2026 年 10 月 6 日，Pro 與 Max 上新的 Cowork 任務會移到雲端。新版的專案也在 Pro 與 Max 上進入公開測試，從 Claude Code 開始，聊天、Cowork、Team 與 Enterprise 隨後跟上；在其中，「一個專案就是一段對話」，由 Claude 拆成平行 thread。但它仍然是單層的：「一個專案屬於一位使用者」，而且「在測試期間，專案沒有組織層級的控制項。」
所以樹狀結構對 Anthropic 來說並不是新概念。它在程式碼裡以資料夾存在、在 Slack 裡以頻道存在，而且兩者都是組織優先。但公司真正存放工作的地方——專案——既沒有父節點，上面也沒有業務線。另外兩項 Anthropic 產品也指向同一個方向，但不在本文範圍內：Claude for Government 透過租戶、群組與組織鏈來解析設定，而第三方供應商上的 Claude Desktop 已在測試依群組的政策。
2. 為什麼重要
專案不是容器。一件真實的工作才是容器。它有 key（工號）、parent（所屬業務線）、生命週期（開啟、結案、按年歸檔）、資料夾、客戶、人員、規則與交付物。而一個 Claude 專案只有一個自由文字名稱，沒有 key、沒有 parent、沒有 children，文件記載的生命週期只有歸檔與刪除。Cowork 可以把專案綁定到本機資料夾，但只能手動、一次一個專案，沒有 key 格式，也沒有 parent。一條業務線一年可能開幾百件工作。這就只剩兩個爛選項：每件工作做一個手動的 Claude 專案，各自帶一份規則副本；或者每條業務線做一個專案，讓不同客戶的 context 擠在一起。
載重路徑斷了。在結構工程裡，每一道載重都需要一條連續通往基礎的路徑。抽掉一根構件，上面的力就傳不下去。規則也是一樣。當組織與專案之間沒有中間層，業務線的標準、範本與簽核規則就無處安放。於是每個專案都拿到一份手動複製的副本。
副本會漂移。你在一個專案裡修好一條規則，其他專案還留著舊版。每個專案依然能通過自己的本地檢查。這種落差只有在有人把專案攤開來比對時才會浮現，而在受監管的工作中，那個人通常是稽核員。基礎架構團隊對這種失敗模式再熟悉不過。在 Firefly 2026 年的研究中，約三分之一的受訪者把設定漂移與昂貴的線上事故連結起來，約五分之一的人沒有任何偵測或修復流程。
身分也是扁平的。很多人同時在多個組織工作，而每個組織都需要自己封裝好的 context。在其中任何一個組織裡，無論是聊天還是 Cowork，connector 帳號都屬於個人，而不屬於分支。Enterprise 的角色可以決定群組能用哪些 connector，管理員也能一次為整個組織授權某個 connector；自訂 connector 甚至可以為所有人共用同一組憑證（測試中）。但無論如何，帳號要嘛是個人的、要嘛是組織的，絕不會是分支的：一位服務兩個客戶的顧問，沒辦法把每個客戶的 Drive 綁到該客戶的專案上。共享專案讓問題更尖銳：「connector 只能在私人專案中使用。」Claude Tag 證明了另一種設計是可行的——把服務帳號綁定到 Slack 頻道——同時也顯示它在哪裡停下來：專案。Anthropic 的 Google connector 頁面只描述了一個已連結的 Google 帳號，文件記載的更換方式是中斷再重新連結；下面三個 open issue 都在要求支援多個帳號。這條界線存在於人的腦海裡，而這正是那種會悄悄失效的手動界線。
沒人看得出套用的是哪條規則。Claude Enterprise 會讓管理員看到權限的「檢視有效角色」，Claude Code 的 /context 會列出載入了哪些 memory 檔案。現在的 Claude Code mod 可以繪製自己的窗格，所以任何人都能在那裡做出一個「有效指令檢視」。Claude Tag 會為每個 connector 與 repository 標註繼承自哪個 scope，但對於指令，它的文件只說要「請 Claude 複述它的管理員指令」。沒有任何介面能針對某個答案，指出哪條指令來自哪一層。沒有來源追溯就沒有稽核軌跡，沒有稽核軌跡就沒有品質系統。
大家已經在要求其中的片段了。以下是 Anthropic 公開 issue tracker（github.com/anthropics/claude-code）中的 open issue，查核日期 2026-10-01：
第七個 #47741 要求提供由組織管理的 CLAUDE.md，但因為 Claude Code 已經有了而被關閉。重點就在這裡：這些層級在 Code 與 Slack 裡都存在，而這些 issue 要求的是把它們放到「專案所在的地方」。
3. 代價是什麼，以及 token 數字背後的真相
3.1 Token 不是障礙
層級變多可能意味著每則訊息都要帶更多 context，而 AI 是按 token 計費的。這個說法只對了一半。在依用量計費的 Enterprise 方案上，用量按 API 費率計價，所以 context 愈多代表營收愈多，而不是愈少。在 Team 上，席次是固定費用，除非啟用額外用量，而額外的 token 只會讓成員更快撞到每週上限。至於同樣按 token 計費的 Claude Code，早就出貨了四層串接。如果 token 真的是障礙，它就不會存在。如 3.2 節所實測，在加入我們任何指令之前，Claude Code 自己的 system prompt 與工具大約佔了 30,200 個 token；一個專案的完整指令只增加了 3.5–5.2%。
3.2 一個試算範例
每張圖上的標籤：REAL = 於 2026 年 9 月 29 日至 10 月 1 日間實測，或對照 Anthropic 文件查核；EST = 模擬；IND = 示意。
先看實測。我用同一個問題在 Claude Code（claude -p、Claude Sonnet 5.5）中對一個示範專案執行，每種條件跑五次，並採用 Claude Code 自己回報的 input token。我在 9 月 30 日用 Claude Code 2.1.286 跑了一次，10 月 1 日又用 2.1.287 跑了一次；指令數量完全相同。減去完全不帶專案指令的那一組，剩下的就是每種佈局的成本：
下面的模擬有兩件事呈現不出來。第一，對同一組規則而言，串接方式比編譯成單一檔案多出 224 個 token：每多一個檔案就有額外負擔，在這裡是應用程式自己在每一層檔案加的標記與標題，加上 Claude Code 為每個載入檔案包上的框架。層級愈多，負擔愈大。第二，即使乘上 × 1.30，Claude Code 實際載入的量仍比公開 tokenizer 估算的高出 21–26%；部分差距就來自同樣的逐檔負擔。比例不受影響，但絕對金額會失真，所以請把模擬裡的美元數字視為低估。
再看公司規模的模擬。我模擬了一家示意公司一個月的指令 token：3 條業務線共 40 人、250 個進行中的專案、每條線 6 種報告類型、每人每個工作日 35 則訊息（每段 session 5 則），總計 29,400 則訊息。Token 數量是用 Anthropic 公開的舊版 tokenizer 對範例指令文字計算（Anthropic 自己稱它對 Claude 3 及之後版本只是「非常粗略的近似值」），再乘上 1.30 換算成 Claude 4.7+ tokenizer 的數值。組織區塊是從 597 字元的樣本外推到 3,000 字元上限，業務線手冊則是 953 字元樣本的三倍。價格採用 Claude Sonnet 5.5 定價（input 每百萬 token $2、5 分鐘快取寫入 $2.50、快取讀取 $0.20）。Prompt 快取有效期五分鐘，每次命中都會刷新。
• 扁平（目前的變通做法）：組織區塊，接著是每個專案自己那份業務線手冊副本、全部六份報告範本，以及專案專屬內容。
• 樹狀：組織、業務線、只用到的那份報告範本，再到專案專屬內容，並把最常共用的部分編譯在最前面。
表格背後的數字：組織區塊 830 token（3,000 字元）、業務線手冊 729、一份報告範本 147、專案專屬內容 98（取整數；總計是在取整前算出的）。模擬未計入 Claude 自己的 system prompt，它會出現在組織區塊之前。
兩個誠實的提醒。第一，樹狀結構本身並不省 token。−29% 來自具型別的任務：只載入正在撰寫的那份報告範本，而不是六份全載。−62% 主要來自把最常共用的層級編譯在最前面，讓幾百個專案共用一段 byte 完全相同的前綴：光是調整順序（六份範本仍全數載入），就能把共享快取的成本從 $36 降到 $18（−51%），剩下的降幅才來自具型別的任務。但第二項節省只有在快取能跨使用者共享時才成立。在 Claude API 上，快取在組織之間是隔離的，在同一組織內則依工作區隔離，因此相同前綴可以在工作區內的請求間重複使用；claude.ai 則沒有相關文件。在目前出貨的 Claude Code 裡這也做不到：那裡「快取實際上被限定在單一機器與目錄」，所以兩個人在兩個專案資料夾裡會錯過彼此的快取。請把最後一欄解讀為「聊天介面若原生支援這一層能省下多少」，而不是今天就能拿到的東西。一個合理的反駁是：Skills 本來就是按需載入，所以只要把範本搬進 Skills，扁平的工作區今天就能拿到 −29% 的一部分。但 Skills 在聊天與 Cowork 裡缺的是 scope 與繼承：一個 skill 不能只屬於某條業務線，再往下流到該線的專案。（在 Claude Code 裡，子資料夾中的 skill 確實會為在該層或以下啟動的 session 載入。）第二，這些都只是指令 token，在這個規模下，依快取狀況每月落在 $14 到 $149 之間。真正帳單的大宗是對話歷史與 output。支持樹狀結構的有力理由是正確性，以及在 Team 上的容量，而不是發票。
上述實測在真實的樹狀結構（於 Claude Code 中）重現了具型別任務的效果，而不是用假設的數字：串接方式 −20%、編譯方式 −34%，對照模擬的 −29%。如果一條業務線只有一種任務類型，具型別任務就省不到任何東西。
3.3 同一個答案，出自真實的 Claude
我把同一個問題問了 Claude Code 四十次：四種條件下各十個獨立答案，分兩批、相隔一天、每批五次。問題是：路基的現場密度試驗是否合格，實測 112.3 pcf，最大乾密度 115.8 pcf，要求 98%。指令要嘛是公司那六條規則，要嘛是一行「helpful assistant」prompt；語言則是英文或西班牙文。四十個答案全都得出相同結論：97.0%，不合格。
Claude Code 會回報兩個 output 數字：計費的 token 數，以及其中有多少是讀者永遠看不見的 thinking。
四個發現：
• 公司的規則讓畫面上的答案變長 1.4 倍，帳單上的長度則是 1.8–1.9 倍。多出來的可見內容是規則要求的旗標、標準與限制段落。在品質系統裡，那才是有價值的部分。
• 在公司規則下，超過三分之一的計費 output 是看不見的。計費的 output token 中有 37% 是 thinking，而單純 prompt 下只有 16%。英文版的情況是：讀者看到 447 個 token，卻要付 711 個 token 的錢。
• 西班牙文的可見 token 是英文的 1.2 倍，而兩者的字數差距不到 4%。用同樣方式測量，公司規則以西班牙文撰寫時，input token 是英文的 1.53 倍。
• 同一個結論的計費量從 317 到 953 個 token 不等，最長的答案是最短的三倍。按 token 計費分不出嚴謹與灌水，驗收標準才分得出來。
這些比例在兩批各五次的執行之間會浮動。公司規則的畫面長度比，第一批是 1.43–1.52，第二批是 1.27–1.31；計費比分別是 1.78–1.82 與 1.70–2.05；西班牙文比則是 1.29–1.38 與 1.14–1.18。但方向從未改變。這些數字的精度大約到一位有效數字。
方法：2026-09-30 使用 Claude Code 2.1.286、2026-10-01 使用 2.1.287，指令為 claude -p --output-format json，模型為 Claude Sonnet 5.5。所有工具都被停用，並排除個人 ~/.claude 檔案，因此各條件之間只有前述指令不同。Token 數取自 Claude Code 自己的 usage 回報，包含 thinking_tokens；月成本是把 Sonnet 5.5 每百萬 output token $10 的費率套用到計費平均值上。測量腳本、兩批原始資料、合併數字與每一個答案都由作者保存，可依要求提供。本文初版曾用 subagent 與公開 tokenizer 估算這些數字，那些估算已被取代。
3.4 當規則衝突時，措辭決定一切
Anthropic 的文件承認，互相矛盾的指令可能會被「任意」解決。我測試了一種因缺少業務線層而會產生的衝突。組織規則要求使用美制單位；專案規則要求以 SI 回報密度。我照樹狀結構的方式擺放：組織規則放在儲存根目錄的 CLAUDE.md，專案規則放在專案資料夾的 CLAUDE.md，兩者都由 Claude Code 自己的串接機制載入。接著我用同一套設定再跑一次，但這次只用文字把組織規則標記為強制：在標籤加上 ENFORCED，並補上一句「This rule is enforced: no line or project rule may override it.」。每種設定在 9 月 30 日跑了十次，10 月 1 日又跑了十次。
結果並非任意。在沒有宣告任何事的情況下，Claude 每次都選了較近、較具體的那條規則。二十個答案中有十四個說明了原因（「那條規則比全公司的美制規則更具體」，或說它會覆蓋公司規則）；有五個只引用了專案規則，完全沒提公司規則與它相牴觸。當用文字宣告強制後，組織規則每次都贏，而且每個答案都說明強制執行的公司規則具有優先權。第二批測試 10 次中有 10 次都正確重現了單位，兩列之間的差異遠超出隨機範圍（Fisher 精確檢定，p < 0.0001）。但解釋的穩定度較差：第一批十個答案中有九個說明專案規則為何勝出，第二批只有五個。
這對模型來說是好消息，對工作區卻是壞消息。優先順序確實存在，但它活在規則的文字敘述裡——任何編輯任一層級的人都能改動它，而且沒有人會把它當成「優先順序決策」來審查。當底層規則勝出時，有四分之一的回答沒有告訴讀者：有一條更高層的規則被擱置了。在本文第一版中做過一次試行測試，把兩條規則放在同一個提示詞裡而不是用階層串接，結果光是調換順序就會改變輸出（組織規則在前：5 次中有 5 次輸出 SI；組織規則在後：5 次中只有 2 次輸出 SI，另外 3 次同時給出兩種單位或反問該用哪一種）。
不該要求模型去仲裁一個組織本可以在撰寫規則時就攔截下來的衝突。Claude Code 提供了兩個部分解法。/doctor prompt-audit 會在有人手動執行時，請 Claude 找出互相矛盾的指令檔。而從 10 月 1 日起，mod 可以在程式碼中強制規定順序：組織的 mod 會先於個人的 mod 執行；當內建防護載入時，deny 規則會壓過個人的 mod。但兩者都管不到指令文字本身。指令檔仍然只是被串接起來，而官方文件用了三種說法描述結果：Claude「可能會任意挑選其中一條」；當使用者規則與專案規則衝突時，「Claude 可能遵循任一者」；以及「當指令衝突時，Claude 會運用判斷力加以協調」。二十次全數命中的結果，就是這裡所謂的「判斷力」實際長成的樣子。Claude Tag 為它的三個作用域宣告了一套順序，並稱其結果是「指引，而非強制執行的護欄」。參考實作的檢查機制會在任何內容送到 Claude 之前就擋下這種確切變更——「R-22 設定 units.density=SI；R-01（org:firm）強制使用 US」——而且 enforced 是規則上的一個欄位，不是規則裡的一句話。
指令密度會讓情況更糟。在 IFScale 基準測試（2025）中，Claude Sonnet 4 的準確率從同時執行 10 條指令時的 100%，掉到 500 條時的 42.9%。
3.5 用運算量或能源作為單位會更公平嗎？
在同一個模型內，token 是運算量的合理代理指標：token 越多，硬體要做的事確實越多。這也正是為什麼改用運算量或能源計價不會解決語言懲罰的問題。西班牙文比較貴，是因為 tokenizer 對它的壓縮率較低，而那些多出來的 token 就是實實在在的運算量。真正的解法是更好的 tokenizer，或是依內容正規化後的計量方式。
不過，正規化的運算單位仍能在三方面帶來幫助。它讓不同模型與供應商之間可以相互比較。它是具體且可申報的，例如用於永續報告書。而且如果係數是相對於參考硬體固定下來的，供應商就能保留自己提升效率所帶來的紅利，這才是正確的誘因。這有前例可循：雲端供應商曾經販售正規化單位，例如 EC2 Compute Unit。
但它也有實際問題。沒有標準與稽核方，客戶無法驗證它。真實能耗取決於硬體、資料中心效率、批次處理與電網。而且 Anthropic 並未公布每次請求的能耗；我只找到第三方的估算值。最重要的是，運算量仍然是投入項，它無法告訴你答案到底對不對。
我的結論是需要分成三個獨立層級：
- 計費以 token 或正規化運算單位為準。
- 揭露每項任務與每個節點的能耗。
- 管理依據每項已驗證成果的成本。
對 Team 方案而言，最基本的做法是用明確的單位公布每週上限。目前單次對話的額度只寫成「Pro 方案單次使用額度的 1.25 倍」；每週上限則完全沒有公布數字。兩者都無法編列預算。
正如 FinOps Foundation 所說：「token 是計費單位，不是價值單位。」唯有透過階層結構，價值才能被明確定義，因為驗收標準必須有地方存放。
3.6 還沒做出來的其他更可能原因
- 隱含的優先順序。 Anthropic 自己的文件也承認，直接矛盾的指令會產生不一致的行為，而第 3.4 節顯示，優先順序完全跟著規則的文字敘述走。層級堆疊越多，衝突就越多，而指令遵循能力會隨密度下降：在 IFScale 基準測試（2025）中，即使是受測表現最好的模型，在同時執行 500 條關鍵字指令時準確率也只有 68%（即第 3.4 節引用的基準測試）。
- 權限繼承。 如果知識會沿著樹狀結構向下繼承，存取權也必須跟著繼承。這意味著要在每一層底下重建權限模型。
- 偏好記憶與檢索，而非靜態層級。
- 消費者優先的簡潔性。 程式碼工具可以直接從檔案系統免費繼承一棵樹。聊天產品卻得自己發明一棵。
Anthropic 尚未公開說明為什麼 Claude 聊天與 Cowork 缺乏階層結構。本節所有內容都是根據已推出功能所做的推論。
4. 參考模型
這套設計借鏡了已經解決此問題的系統：雲端資源階層（AWS Organizations、Google Cloud Org Policy、Azure 管理群組）、目錄原則（Active Directory 群組原則），以及 Claude Code 自身的 CLAUDE.md 階層串接。節點之間的關係只用五個詞描述：contains（包含）、inherits（繼承）、uses（使用）、sealed（密封）與 shared（共用）。
4.1 掛載組織現有的樹狀結構
別讓人們在 AI 工作區裡重新打造一次組織架構。檔案伺服器或文件系統本身就是唯一事實來源。只要採用一條路徑：
工作編號 26GT301 本身就已經編碼了樹狀結構：年份、業務線、序號。工作區應該掛載這個結構，而不是複製它。
4.2 承載規則的節點、分組節點、專案與任務
• 承載規則的節點：組織、業務線、專案、任務。每一個都帶著相同的三樣東西：情境（指令與知識）、原則（允許使用哪些工具、資料與連接器），以及身分識別（綁定到該節點的連接器帳號）。
• 分組節點：系列、年份、區域。它們不帶任何規則，存在的目的是為了導覽、保留與生命週期管理。把它們分開，可以讓規則樹維持在三到四層的淺層結構，正如 Microsoft 自身對管理群組的建議（「不超過三到四層」）。
• 專案是一個帶鍵值的容器。 它會自動建立：當出現符合業務線鍵值模式的資料夾時（例如業務線根目錄下的 {YY}GT{NNN}_{Name}），就會建立一個專案節點，從其所屬業務線繼承，並取得僅限於該資料夾範圍的連接器存取權。它只保存與業務線不同的內容：成員、客戶、規格。它會從開啟、關閉一路走到封存（圖表 2）。
• 任務是有類型的。 它的類型來自業務線的目錄（一份密度報告、一份鑽探紀錄）。類型會附帶範本與驗收標準。產出物會依照公司的命名慣例歸檔回專案資料夾，並由審查者驗收。技能（Skills）是目前 Claude 最接近任務類型的東西。在 Enterprise 方案上，技能可以與群組共用，但那只是分發，不是繼承：沒有任何東西會沿著分支往下流動。
這種遞迴是刻意設計的。Stafford Beer 的可行系統模型（Viable System Model）直接指出：「在遞迴式組織結構中，任何可行系統都包含另一個可行系統，同時也包含於另一個可行系統之中。」
4.3 一個主要父節點，加上覆疊
Christopher Alexander 在 1965 年主張「城市不是一棵樹」。真實的結構會彼此重疊。一個客戶、一份機構規格或一種任務類型，可能橫跨多條業務線。因此每個節點都有一個主要父節點，而跨領域的規則集則以覆疊（uses）的形式附加上去。衝突的解決方式每次都一樣：deny 優先，否則由最近的節點勝出。
4.4 兩個通道，兩種語意
這是整套設計的核心，也是多數階層結構出錯的地方。
• 情境是串接的。 指令與知識會像 CLAUDE.md 那樣，從根節點往下合併。
• 原則是預設拒絕。 只有在從根節點開始的整條路徑上都存在 allow 時，才允許使用某個工具或連接器；而上層任何一處出現明確的 deny 都會勝出，就像 AWS Service Control Policies 的做法。父節點可以把某條規則標記為 enforced，這樣任何子節點都無法阻擋它，如同群組原則的運作方式。
把兩者混在一起是典型的錯誤。建議性的情境應該融合，但強制執行不該如此。
4.5 在模型讀取之前先編譯
今天，衝突的指令是由模型在生成回答時解決的。解法是做一個有效指令編譯器，在模型看到任何東西之前就先執行：
- 從根到葉合併情境。
- 套用原則：deny 優先，且 allow 必須在整條路徑上都成立。
- 遵守來自父節點的 enforced 規則。
- 為每條規則蓋上 ID 與所屬層級的戳記。
- 依照各部分的共用範圍大小排列區塊，並為每一層套用 token 預算。
衝突永遠不會走到這一步：它們在更早階段、也就是規則被寫下時就會被擋下，而且核准者不能是作者本人（圖表 3，下方泳道）。
因為衝突是在編譯期解決的，所以輸出可以依照各部分的共用範圍排序，而不必嚴格依照深度：組織、業務線、任務類型範本，最後才是專案細節。這樣的順序能最大化快取命中率（第 3.2 節）。它可以對應到 Anthropic 的四個快取斷點，並為每一層設定 token 預算，不過實務上可能需要保留一個斷點給對話本身。
4.6 身分識別綁定到分支，而不是人
連接器身分識別（帳號、租戶、範圍）是附加在節點上，而不是人身上。Claude Tag 在 Slack 頻道上已經是這樣運作的：管理員把服務帳號附加到某個作用域，範圍最窄的作用域憑證勝出。這裡的模型只是在下一層提出同樣的要求，也就是作用在業務線及其專案上。一個同時在兩個組織工作的人會有兩棵密封的樹；他切換的是樹，而不是帳號。除非雙方的擁有者明確共用，否則兩邊不會有任何東西互通。技術上的基本元件已經存在：MCP 授權規範使用受眾綁定的 OAuth token（RFC 8707 資源指示符、RFC 9728 受保護資源中繼資料），並要求伺服器「不得接受或轉送任何其他 token」（規範版本 2026-07-28）。
4.7 權限跟著樹狀結構走
主體： 人員、群組、服務帳號、外部訪客（例如客戶），以及 agent 本身。
Agent 的權限絕不超過人或節點。 Claude 是以呼叫者的權限與節點原則的交集來行動。它不能修改規則或權限，只能提出變更建議。（今天，Claude 可以自行更新 Cowork 資料夾的指令。在這套模型中，這會變成需要有人核准的提案。）
評估。 授權只能向下流動，絕不向上或橫向。某個節點的有效權限，是其路徑上各角色所授予的權限、受限於整條路徑上原則所允許的範圍，再扣除上層任何 deny 之後的結果。覆疊只會授予對其自身內容的存取權：讀取一份規格，並不會打開使用該規格的專案。
生命週期。
• 開啟： 角色依授予內容生效。
• 關閉： 不接受新任務，但待處理的審查可以完成。
• 封存： 所有人皆為唯讀；只有擁有者可以還原，且還原動作會被記錄。
• 密封樹： 未經明確共用，任何東西都無法跨越。
例外與委派。 例外都有時間限制與正當理由，且須由申請人以外的人核准。它們會自行到期並被計數，因為每一次覆寫都會形成一座永久的維護孤島；SharePoint 中斷繼承的限制就是前車之鑑。委派所能授予的權限，絕不能超過委派者本身擁有的。擁有者的緊急存取（break-glass）權限確實存在，但一定會被記錄，並在事後接受審查。
在 Team 方案上， 即使沒有群組也能運作：授權存在於節點上，因此一個只有四個角色的組織依然能取得按分支劃分的權限。
4.8 各層如何互動
只有當變更能在樹中流動時，這棵樹才值得建立。有三種互動承擔了大部分工作（圖表 5）：
• 向下推送。 業務線主管發布規則的新版本。該業務線下的每個專案都會在下一次編譯時讀取它。已獲核准的例外會繼續使用舊版直到到期，而已歸檔的產出物則保留製作時所用的版本。
• 向上拉取。 某位成員在一個專案內改良了範本並提出建議。由業務線主管（而非提案人）核准，接著同層的其他專案便會繼承它。而在今天，這種改良只會留在發生的那個專案裡。
• 橫向擴散。 某份機構規格只需修改一次。三條業務線中的專案會用它重新編譯，而業務線本身不必變動。若與業務線規則發生衝突，會在寫入更新時就被擋下。
單一次請求就能同時展現所有層級（圖表 6）：樹會檢查成員的授權與專案狀態，編譯器建構區塊，Claude 透過限定在該專案資料夾範圍的身分識別讀取欄位資料，將帶有類型的產出物歸檔回資料夾，再由一位非撰寫者的審查者驗收。每一步都會落入日誌，成本則記入專案鍵值。
4.9 資料結構
佈建是事件驅動的：當業務線的 storage_root 下出現符合 key_pattern 的新資料夾時，就會建立專案節點。answer_log 會提供每個回答的來源追溯，以及每個節點的成本。
4.10 衡量成果，而不是 token
每種任務類型都帶有驗收標準：也就是「完成」的定義。有了這些，就能衡量更好的 AI 工作單位：
每項已驗證成果的成本 =（token 成本 + 審查時間）÷ 已驗收的交付物
因為每個回答都會記錄到特定節點，AI 成本就能像人工與材料一樣記入專案鍵值。部分元素已經存在：Claude Tag 可以報告並限制每個頻道的支出，而 Claude Code 的遙測資料也可以手動依部門、成本中心或儲存庫加上標籤。但沒有一項是鍵結到專案的，也沒有一項會除以已驗收的交付物。對按工作編號計費的公司來說，AI 會從間接費用變成直接工作成本。在工程界，你付錢買的是經過檢查、密封的交付物，而不是筆芯。AI 工作也應該用同樣的方式衡量。
4.11 常見質疑與回應
「技能和外掛已經做到這些了。」 技能是在 Claude 判斷相關時才載入，這只是相關性，不是保證。佈建會把技能發給所有人；在 Enterprise 上，可以要求某個群組必須安裝攜帶該技能的外掛。這是目前聊天與 Cowork 中最接近業務線的東西，但它在三方面有所不足：僅限 Enterprise、針對的是人而不是專案，而且沒有任何東西會從業務線流向其專案。一條在某業務線中必須永遠適用的規則，不能依賴相關性偵測。
「Mods 已經做到這些了。」 在 Claude Code 中算是部分做到，自 2026 年 10 月 1 日起。mod 可以改寫系統提示詞、拒絕工具呼叫並繪製面板，而且組織的 mod 會先於個人的 mod 執行。因此本文提到的編譯器、寫入時檢查與有效指令檢視，今天都可以做成 mod，第 6 節也會這麼說。但仍存在三個限制。mod 不會在 Claude 聊天中執行，而在 Cowork 裡組織的主控台設定並不適用。它們的順序有兩個擁有者——組織與個人——中間沒有業務線這一層；在 Enterprise 上，某個群組必要的外掛可以把 mod 帶進該群組，但它會以個人自身 mod 之一的身分執行，沒有優先順序可言。而且 mod 是未沙箱化的程式碼：要跑在個人 mod 前面，組織的 mod 必須放在每台機器的目錄裡，而從管理主控台下發的設定「無法把目錄放到機器上」。沒有裝置管理機制的公司可以把 mod 推給所有人，但它會混在個人的 mod 之間執行，而不是跑在前面。一家公司不該為了聲明某個部門要用不同單位回報，就得去寫 TypeScript。
「記憶會學會這些規則。」 記憶大多由 Claude 為單一使用者或單一專案寫入，而且擁有者無法讀取或編輯成員的記憶。稽核人員需要的是由人撰寫、有版本、經核准且可追溯到每個回答的規則。Anthropic 其實已經做過三次了：在權限方面，有「檢視有效角色」及其「授權來源」標籤；在技能與外掛方面，有版本歷史與「你不能核准自己提交的內容」的審查步驟；在 Claude Tag 的存取控制方面，有「繼承自」標籤。而專案裡的指令，這三者都沒有。
「Claude Tag 已經做到這些了。」 對 Slack 頻道來說大致沒錯，第 1 節也提過。但仍缺三樣東西。頻道不是專案：它沒有資料夾、沒有鍵值、沒有生命週期，而且「頻道無法指向 Project」。樹狀結構固定只有三層，因此擁有業務線與上百個工作的公司，只能把其中兩層壓扁塞進頻道名稱裡。此外，文件也沒有描述在寫入指令時檢查衝突的機制；各作用域只是被串接起來，留給模型自己去協調。真要說的話，Claude Tag 反而是本文設計最強而有力的佐證：同一家公司在為團隊打造產品時，選擇了繼承、作用域綁定憑證與來源標籤。
「階層會增加複雜度。」 只有在深度不受限時才會。Microsoft 自身對管理群組的建議就是「不超過三到四層」。這套模型固定了四個承載規則的層級，而像系列與年份這類分組資料夾根本不帶任何規則。
「繼承是安全風險。」 如果存取權被草率地繼承，那確實是。雲端的答案在這裡同樣適用：每一層都必須存在 allow、任何地方的 deny 都會勝出、Claude 是以使用者權限與節點的交集來行動，而 Claude 自己對規則的編輯會變成提案。
「更多層會消耗更多 token。」 第 3.2 節在 Claude Code 中量到的結果正好相反：相較於扁平複製，階層串接省下 20% 的指令 token，編譯後省下 34%。每多一個檔案確實會增加一點開銷，所以編譯勝過串接。具類型的任務會捨棄未使用的範本，而編譯後的前綴在不同專案間是位元組完全一致的，因此提示詞快取可以重複使用它們。在 Claude API 上，快取是按工作區隔離的，所以每個組織一個工作區正好對應到樹的根節點。今天的 Claude Code 還做不到這點：它的快取範圍限定在單一機器與目錄。
「團隊自己維護專案就好。」 那是今天的變通做法，而第 5 節的原型量出了它的結果：在一場小型示範中，六份貼上的副本裡有兩份已經過時。
5. 今天就能跑：參考實作
為了證明這套模型真的做得出來，而不只是紙上談兵，我打造了 Worktree，一款小型桌面應用程式（Node 加 Electron，在 Windows 與 Linux 上通過 24 項測試），介面配置類似 Claude Desktop。上面的影片是真實執行過程，只在 Claude 運算時做了剪輯。它是一個獨立的應用程式，從外部驅動 Claude Code，而不是 mod。它不會自己呼叫模型。每一次對話都是執行電腦上已安裝的 Claude Code（claude -p），並沿用 Claude Code 目前的登入狀態：Claude 訂閱或 API 金鑰。我用一家虛構的公司進行測試，該公司有三條業務線與六個專案。當有人傳送訊息時：
• 許可。 操作者需要在該專案或其上層擁有授權，且專案必須處於開啟狀態。一位在該業務線上沒有授權的管理員，在 Claude 啟動前就被擋下了。
• 檢查。 寫入時檢查會先執行。第 3.4 節的 SI 規則因為與一條 enforced 的公司規則衝突而被拒絕，所以它永遠不會進入任何 CLAUDE.md。
• 掛載。 樹狀結構會寫入真實的專案資料夾，每一層產生一個 CLAUDE.md（組織在儲存根目錄，接著是業務線，然後是專案），並由 Claude Code 自身的階層串接機制載入。編譯模式則改為每個專案只寫入一個檔案。沒有本應用程式標記的檔案絕不會被覆寫。
• 執行。 任務範本會放進 --append-system-prompt-file。Claude 能做什麼是由 Claude Code 強制執行，而不是靠 CLAUDE.md：--allowedTools 是該人員的角色與每一層原則的交集，寫入被限制在專案資料夾內，而 --permission-mode dontAsk 會拒絕其他所有操作。在實際執行中，一次網路搜尋被拒絕了，因為該業務線的原則不允許使用網路；一次寫入專案資料夾外的嘗試也被拒絕並記錄下來。
• 記錄與審查。 每個回答都會記錄操作者、節點、所有規則標籤、Claude 引用的規則，以及 Claude Code 回報的輸入、快取與輸出 token。由一位非撰寫者的審查者決定驗收或退回。在示範中實際執行一次密度報告大約花了 30 秒；三次執行下來，Claude Code 按定價回報每次回答花費 0.08–0.22 美元。Claude 引用了它所套用的規則，標記了接近驗收極限的結果，並把工程師欄位留空。
• 偏移。 每個掛載的 CLAUDE.md 都會與樹狀結構比對，手動編輯會被標記出來。較早的命令列原型曾在貼入扁平專案的副本上執行相同比對，發現六份中有兩份過時：一份還停在 R-07 v3，另一份則有一條規則被人手動刪除了。
打造過程中有三個發現，對任何想在 Claude Code 上分層管理指令的人都有參考價值：
- 你的個人指令會洩漏到組織的執行中。 預設情況下，每次執行也會載入我個人的
~/.claude/CLAUDE.md、規則、agents 與 MCP 伺服器。現在應用程式會透過claudeMdExcludes設定加上--strict-mcp-config排除它們。在我的機器上，這把一次執行的情境從 29.6k token 降到 21.4k token。直覺上的替代方案--setting-sources project,local，在 Windows 上的 Claude Code 2.1.284 中做出了完全相反的事：它保留了個人檔案，卻丟掉了承載組織與業務線的父資料夾 CLAUDE.md 檔案。
- 個人的 mod 也會洩漏進來。 mod 是在應用程式完成隔天推出的，所以我測試了一下。我在自己的使用者範圍內安裝了一個單掛鉤的 mod，會在每個提示詞加上一行。它成功進入了應用程式的執行：組織的三條規則被載入，我個人的那一行也被載入，而回答確實遵循了它。在執行設定中加入
disableAllHooks就能把它擋在外面，同時讓三層 CLAUDE.md 保持完整；應用程式現在就是這麼做的。--safe-mode不是替代品：它會把 mod 連同整個 CLAUDE.md 階層串接一起移除。根據文件，在個人設定中使用disableAllHooks會讓組織管理的部分繼續執行。
- CLAUDE.md 是情境，強制執行是組態。 Anthropic 的文件正是這麼說的：「無論 Claude 決定怎麼做，設定規則都會由用戶端強制執行。CLAUDE.md 指令會形塑 Claude 的行為，但不是硬性強制層。」應用程式正是依賴這一點。規則必須保證的一切都會映射到工具權限；CLAUDE.md 裡的一切都只是帶有標籤的指引。
它能在今天的 Claude Code 上運作，而編譯後的文字可以貼進任何方案的聊天或 Cowork 專案指令中。有一個相依項目是有期限的：應用程式依賴 claude -p 載入 CLAUDE.md 檔案，而 Anthropic 文件指出會跳過這些檔案的 --bare「將在未來版本中成為 -p 的預設行為」。等那天到來，應用程式就得用其他方式傳遞樹狀結構；編譯模式與 --append-system-prompt-file 已經能做到。它是原生版本的可行規格，而不是安全邊界：「扮演為」只是示範用的開關，不是登入機制。
6. 從現有產品出發的路徑
現在，在 Claude Code 裡。 自 10 月 1 日起，這棵樹可以作為 mod 發布：把節點的規則編譯成系統提示詞的一個段落、拒絕該節點策略所禁止的工具呼叫，並在面板中繪製出實際生效的指令。組織可以讓這個 mod 優先於個人安裝的任何東西執行。我還沒有做出來；這是參考實作路線圖上的第一項。它會涵蓋 Claude Code，也可能涵蓋使用者本機上基於同一引擎運行的 Cowork 工作階段，但不會涵蓋聊天功能。
30 天版本，適用於聊天與 Cowork。 Anthropic 已經具備所有零件。讓一個專案指定它所繼承指令的上層專案，就像 Slack 頻道在 Claude Tag 中繼承其工作區的設定一樣。依序編譯兩者，為每條規則加上標籤，並在現有的「檢視實際角色」旁邊新增一個「檢視實際生效指令」面板。光是這樣，就能讓每個業務線都有一個統一的地方來存放自己的規則。
接下來，每一步本身都有價值，先從對 Team 方案有幫助的部分開始：
- 業務線節點與關鍵模式佈建，複用已在程式碼中生效的 CLAUDE.md 語意。在 Claude Code 本身，匹配步驟是介於組織 mod 與個人 mod 之間、供群組使用的一層，以及按群組管理的設定。
- 任務類型，作為限定在特定業務線範圍內的技能，並附上驗收標準。
- 寫入時的衝突檢查，讓矛盾由樹結構直接拒絕，而不是交給模型去仲裁。
- 節點上的授權，在沒有群組的 Team 方案上也能運作，並擴充 Enterprise 的自訂角色。
- 綁定分支的連接器身分識別（用於專案），就像 Claude Tag 已經把服務帳號綁定到 Slack 頻道那樣。
- 以專案為鍵值的逐節點計費，如同 Claude Tag 已支援的按頻道報告；以明確單位公布的每週上限；以及每個任務的能源揭露。
7. 限制
• 覆蓋範圍。 2026 年 10 月 1 日，code.claude.com/docs 與 claude.com/docs 的完整頁面索引依標題進行了分類（共 466 頁），並閱讀了約 150 頁，同時引用了此處提到的說明中心文章。本文較早的版本完全漏掉了 Claude Tag；這一版可能也漏掉了其他東西。Claude for Government 以及在第三方供應商上運行的 Claude Desktop 僅被提及，未做分析。
• 平台功能每月都會變動，而在撰寫本文的過程中就有一項發生了改變。本文中所有的產品聲明皆標示為 2026 年 9 月 29 日至 10 月 1 日，依賴前應重新查證。Mods 才推出一天；我讀過它們的文件並測試了一個案例，但尚未在生產環境中使用。
• 第 3.1–3.4 節中的測量數據來自 Claude Code 自身的使用量報告，分為兩批：2026-09-30 的 Claude Code 2.1.286 與 2026-10-01 的 2.1.287，兩者皆使用 Claude Sonnet 5.5。腳本、兩批資料與所有回答均由作者保存，可應要求提供。這些資料包含 Claude Code 自身的提示詞（約 30,200 個 token），而 claude.ai 與 Cowork 並不共用這部分；且僅涵蓋一個模型、一個示範專案與一個問題。樣本很小：回答長度測試每種條件十個回答，衝突測試每種條件二十個。兩批資料之間的回答長度比例有所變動（第 3.3 節）；相隔一天的兩批資料同時也因 Claude Code 版本不同而有差異，我無法將這點與隨機波動區分開來。
• 第 5 節中的執行時間、成本與上下文大小，來自應用程式自身對三次示範執行與一次手動隔離測試的回答紀錄，皆為作者本人的記錄。
• 衝突測試的回答由作者在未盲測的情況下編碼，逐一閱讀每個回答（是否回報單位；回答是否指出哪條規則勝出及原因；是否主動提問）。全部四十筆資料可應要求提供以供重新編碼。測試僅使用了一種「強制執行」的措辭；其他措辭、模型與規則組合的表現可能不同。
• 第 5 節的 mod 測試是在一台 Linux 機器上，使用一個帶有一個 hook 的 mod、搭配 Claude Haiku，以訂閱帳號登入且無受管設定進行的。我並未測試組織的策略 mod、Team 或 Enterprise 登入下的內建防護機制，也沒有測試桌面版應用程式。
• 第 3.2 節的成本模型是對一家示意公司的模擬，而非實際計費測量。它只涵蓋指令 token；在真實帳單中，對話歷史、輸出與思考通常佔據大頭。其 token 數量採用 Anthropic 公開的舊版 tokenizer × 1.30；在實際測量中，Claude Code 載入的量比該估算多出 21–26%，因此其美元數字偏低。其中的百分比為比率，依然成立。工作階段模式與快取共用則屬於假設。
• Enterprise 上的聊天使用量是否適用 API 快取定價，以及 claude.ai 上的快取是否跨使用者共用，目前並無文件說明。Cowork 的工作階段運行在 Claude Code 上，外掛 hook 也在那裡載入，但 mods 頁面並未列出 Cowork，我也沒有測試；截至 10 月 1 日，桌面應用程式仍內建 Claude Code 2.1.286，也就是啟用 mods 的前一個版本。裝置的受管策略會套用到使用者本機的 Cowork 工作階段，除非組織將其放在完整的虛擬機沙箱中運行。有兩個頁面對於使用者自己的 ~/.claude 檔案是否會進入 Cowork 說法不一，因此本文對此不做任何主張。我也沒有測試上層資料夾中的 CLAUDE.md 檔案是否會在 Cowork 工作階段中載入；如果會，那麼參考實作的掛載樹狀結構今天就能觸及使用者本機上的 Cowork。在 Pro 與 Max 方案上，這個窗口將在 2026 年 10 月 6 日縮小，屆時新的 Cowork 任務會移至雲端。
• 動機純屬推論。Anthropic 尚未公開說明為何 Claude 聊天與 Cowork 採用扁平結構。
• 程式碼與原始資料未隨本文發布。 讀者無法僅憑本文重現測量結果；影片展示的是應用程式的運作方式，而非它的建構方式。
• 參考實作運行在一家虛構的公司上。它並未與 claude.ai 或 Cowork 整合，「扮演為」只是一個示範用的切換開關，並非登入。權限由 Claude Code 的工具清單強制執行，而非由應用程式本身執行。隔離功能會在該次執行期間關閉使用者自己的 hook 與 mod；內建於 Claude Code 的 mod 仍會繼續運行，且個人 Agent 的名稱仍可能出現在上下文中。該應用程式依賴 claude -p 載入 CLAUDE.md，而 Anthropic 表示這將不再是預設行為。個人檔案洩漏與 --setting-sources 的結果是在 Windows 上測試的；測量與 mod 測試則在 Linux 上進行。
來源
• Anthropic，設定組織指令
• Anthropic，角色與權限
• Anthropic，什麼是 Team 方案？ · 方案與定價
• Anthropic，在 Enterprise 方案上管理自訂角色
• Anthropic，在 Claude Cowork 中使用專案整理你的任務
• Anthropic，使用 Google Workspace 連接器
• Anthropic，在 Enterprise 方案上管理群組與群組支出上限
• Anthropic，什麼是專案？（新版專案，Beta 版）
• Anthropic，開始使用 Claude Cowork（全域與資料夾指令）
• Anthropic，Claude 如何記住你的專案 (CLAUDE.md) · 所有設定（claudeMdExcludes、disableAllHooks）
• Anthropic，使用 mods 自訂 Claude Code（2026 年 10 月 1 日） · Mods 總覽 · 為你的組織管理 mods · 使用 mod 回應事件 · Mods 參考文件
• Anthropic，Claude Tag：什麼是 Claude Tag？ · 設定各頻道的存取權限 · 自訂 Claude Tag · Agent 身分識別的運作方式 · 稽核 · 設定支出上限
• Anthropic，Claude Code 中的專案（新專案 Beta 版） · Cowork 中的專案 · Claude Code 如何使用提示詞快取 · 以程式化方式執行 Claude Code（--bare） · 擴充 Claude Code · 管理專案的可見度與分享 · 使用連接器 · 為整個組織授權 MCP 連接器 · 佈建與管理技能
• Anthropic，設定伺服器端受管設定（不支援按群組設定） · 為你的組織管理外掛（Enterprise 上依群組控管外掛可用性） · 各平台的外掛功能支援狀況（聊天中會忽略 hook，Cowork 中會載入） · 部署受管設定（Cowork 的工作階段運行在 Claude Code 上）
• Anthropic，定價（Sonnet 5.5 費率、tokenizer 備註） · 提示詞快取（API 上的快取依組織與工作區隔離）
• Anthropic，@anthropic-ai/tokenizer（用於計算數量的公開 tokenizer）
• Microsoft，管理群組 · Landing-zone 管理群組設計
• AWS，SCP 評估 · Google Cloud，階層評估
• Microsoft，群組原則處理 · SharePoint 細微權限
• FinOps Foundation，Token 經濟學
• Jaroslawicz 等人，LLM 一次能遵循多少指令？(IFScale)
• Firefly，2026 年 IaC 現況研究
• MCP，授權規範，2026-07-28 版本
• GitHub，anthropics/claude-code issues #68262、#14467、#30554、#27567、#30250、#27302、#47741
• Beer, S. (1979)，The Heart of Enterprise；Alexander, C. (1965)，〈A City is Not a Tree〉，Architectural Forum；Simon, H. (1962)，〈The Architecture of Complexity〉，Proc. Am. Phil. Soc. 106(6)
• 參考實作與資料：Worktree 應用程式、其測試、測量腳本、兩批結果與所有回答均由作者保存，可應要求提供。
