我們公司還沒開 Team Plan,這篇 owner 視角寫的東西有意義嗎?

有,這篇可以當決策框架用。讀完你會知道:Team Plan 真正值錢的能力是 Skills 集中派送(把 SOP 變工具),不是「多人共用 billing」。如果你只是想分擔費用、不想管組織級設定,Team Plan 對你 overkill;如果你想把公司工程規範變預設行為、收斂 Claude Code 風險,Team Plan 是 self-serve 級唯一選項,再上就是 Enterprise。

Claude Code Teams 怎麼管?Owner 視角 4 個後台動作完整指南

Q: Primary Owner 離職了怎麼辦?

官網沒明寫流程,治理上必須離職前先轉移 Primary Owner 角色給接任者。如果已經離職沒轉,要聯絡 Anthropic support 協助轉移,流程會比較麻煩 — 你需要證明組織所有權(domain 驗證、billing 帳戶等)。所以這條我會列在公司 IT offboarding checklist 強制項目,不是離職當天才想到。

TL;DR:Claude Code Teams 比個人 Pro 貴 7.5 倍($150/seat/月 vs $20/月),願意付這筆錢的公司一定有「多人管理」需求。這篇從 owner 視角盤點後台 4 個會真的拿來用的管理動作:座位管理、Skills 集中派送、Tool/MCP 權限收斂、ZDR 法遵開關。每條能力背後引官網原文,告訴你什麼時候用、不適用什麼場景、踩到會痛的地方。

📌 目錄

為什麼會想寫這篇 — 給正在評估 / 剛上手 Teams 的 owner
動作 1:座位管理 — 開帳、關帳、Primary Owner 指派
動作 2:Skills 集中派送 — 把公司 SOP 變成所有人 day1 就有的工具
動作 3:Tool permission 與 MCP enforce — 收斂風險邊界
動作 4:ZDR — 對話不存,法遵情境的核選項
順便講:Data Export 我不會用、但你該知道存在
🔗 延伸資源
❓ FAQ

🧠 為什麼會想寫這篇 — 給正在評估 / 剛上手 Teams 的 owner

我自己跑 Claude Code 跑了一陣子,身邊開始有人問:「公司要不要開 Team Plan 給所有工程師用?」我自己一開始也以為差別主要在 billing 集中、座位多開幾個,直到把官網文件翻過一輪才發現:Anthropic 在 2025 年底把 Claude Code Teams 重新定位成組織級工具,owner 後台多了一票實際在「管理」的功能。

這篇寫給兩種人:

正在評估要不要從個人版升級到 Teams 的 owner — 想知道除了 seat 折扣,後台還能幹嘛、值不值得多付幾倍的錢

剛開好 Teams、第一次進後台的 owner — 想知道這幾個功能分別怎麼設、實務上怎麼配權限

我從文件挑出 4 個會真的拿來用的動作 — 不是「能做」,是「日常會去點」。Anthropic Console 後台 UI 我沒實際登入過(我用 Pro plan),所以這篇講「能力地圖 + 對應的管理判斷」,實際 click flow 以你自己後台為準。每條能力背後對到的官網原文 URL 全列在文末。

⚡ 動作 1:座位管理 — 開帳、關帳、Primary Owner 指派

最基本但最常被忽略的一塊。Team Plan 支援 5-200 seats,owner 可以 invite、移除、變更 role。這層不稀奇,所有 SaaS 都有。

真正要管的是 Primary Owner 這個角色。

根據官網 Who owns and manages the data of my team:

"Your organization's designated Primary Owner... has the ability to request access to your user data through data exports, which may contain your conversations with Claude, uploaded files, and usage patterns."

翻譯一下:Primary Owner 是組織內唯一能 export 全公司對話內容、上傳檔案、使用記錄的人。普通 Owner 跟 Member 都不行,只有 Primary Owner 這位有此權限。

我會怎麼指派 Primary Owner

不是給老闆,不是給 CTO,看你公司治理結構。我會這樣分:

公司類型	建議 Primary Owner 給誰
10 人以下新創	創辦人本人(治理權威 = 資料權威)
10-50 人 SaaS / 軟體公司	IT Lead 或資安主管,不是 CTO
50 人以上有法遵需求	法遵長 / 資安長,經 BoD 任命
醫療 / 金融 / 政府標案	法遵長,且必須有書面授權與審計 trail

為什麼不是 CTO? CTO 自己也在寫 code、自己也是被管理對象。「能 export 全公司對話」這條權限放在被管理對象身上,治理上有衝突。

我會怎麼處理離職

Primary Owner 離職前必須先轉移角色給接任者,不是離職當天才處理。這條官網沒明寫流程,但治理上是基本動作。

反模式我看過的:

全公司只有 1 個 Owner — 這個人請假 / 出差 / 帳號被盜時沒人能管
Primary Owner 是離職員工沒交接 — 那個 export 權限就懸著沒人接
Primary Owner 跟一般 Owner 混在一起發 — 沒人意識到那位有特權

⭐ 動作 2:Skills 集中派送 — 把公司 SOP 變成所有人 day1 就有的工具

這條是 2025 年 12 月才推出的功能,也是 Team Plan 最值得花錢的單一理由。

根據官網 Use skills in Claude:

"Owners of Team and Enterprise organizations can provision skills for all users."

操作路徑:Organization settings > Skills > upload。Owner 上傳一個 skill,team 所有成員自動拿到,可以 toggle on/off,不用各自 install。

我會把什麼東西做成 skill 推給全員

不是工程相關的小工具,是公司怎麼做事的 SOP。具體例子:

Skill 名稱	用途	取代什麼
`commit-style`	公司 commit message 規範(prefix、emoji、JIRA ID 格式)	onboarding 文件第 3 頁那條沒人記得的規則
`pr-description`	PR description 範本(背景、改動、測試、reviewer)	「請參考團隊範例 PR」連結
`api-internal`	內部 API 怎麼接(auth header、retry、錯誤碼)	工程師 onboarding 第二週才學會的事
`db-naming`	資料表 / 欄位命名規範	那份沒人在看的 wiki page
`code-review-checklist`	code review 必檢查的 5 條	資深工程師腦袋裡的 implicit knowledge

為什麼比寫 onboarding doc 有用 10 倍:doc 是「需要時要去查」,skill 是「寫 code 時自動觸發」。

工程師寫 commit 時 Claude 自動套你公司的 prefix 規則,工程師寫 PR 時 Claude 自動填你公司的 description 範本。規範從「希望大家遵守」變成「預設就遵守了」。

Skill 派送的流程圖

反模式

把私密內部知識塞進去 — skill 上 Organization settings 等於組織內全員看得到,不是 Primary Owner only。公司核心演算法 / 客戶資料 / 業務機密不要塞 skill,該開私有文件管理工具
派下去就不管 — skill 寫得爛沒人用,反而被 toggle off。要有人定期收集 feedback 維護
想派 .claude/settings.json / CLAUDE.md / private plugin marketplace — 官網沒寫這幾條能集中派送。Skills 是目前唯一明文支援的「組織級派送」單位

⚠️ 最後這條是踩過的坑,我前面三輪自己研究的時候,以為 Team Plan 什麼都不能派。實際是 skill 可以,但其他幾個檔案 / config 找不到官方派送機制。要派 CLAUDE.md 給全員目前還是得走 git repo + 內部宣導,不是後台 toggle。

💰 動作 3:Tool permission 與 MCP enforce — 收斂風險邊界

根據官網 Claude Code on Team and Enterprise:

"Deploy and enforce settings across all Claude Code users to match internal policies, including tool permissions, file access restrictions, and MCP server configurations."

這條對應到 3 個收斂方向:

3-1. Tool permission(能用哪些工具)

Claude Code 預設可以跑 Bash、Read、Write、Edit 等內建工具。Team Plan owner 可以集中設定黑白名單,例如:

禁用 Bash 的特定指令(rm -rf、sudo、curl <非白名單域名>)
強制所有 Write 必須經過 approval(不是 yes-to-all)
限制 Edit 不可改 .env / .git/config / ~/.ssh/*

典型場景:工程師習慣 --dangerously-skip-permissions(俗稱 yolo mode)跑 Claude Code 加速,結果 Claude 自己 rm -rf 某個資料夾。一次就出事。Owner 端 enforce 後,個人 settings 蓋不過去。

3-2. File access restrictions(能讀寫哪些路徑)

預設 Claude Code 在 cwd 有完整讀寫權,但可以白名單限制:

醫療業:禁讀 /var/log/* 含 PHI 的目錄
金融業:禁讀 ~/.aws/credentials、~/.kube/config 等 credential 檔案
一般 SaaS:禁寫 node_modules、.git/objects(避免 Claude 不小心破壞 git state)

3-3. MCP server configurations(能連哪些 MCP)

這條最關鍵,也是大公司最該管的一塊。

MCP(Model Context Protocol)是 Claude Code 連外部資源的協定。工程師可以自己裝任何 MCP server,連到 Notion、Slack、GitHub、外部 SaaS。問題是:

工程師裝了個野生 MCP server,把公司資料庫 schema 透過 MCP 送到第三方 LLM API
工程師連到 ChatGPT MCP wrapper,把公司 prompt + 上下文也傳給 OpenAI
工程師裝了個 MCP server 自己沒看清楚 permission,結果開了個後門

Team Plan owner 可以強制 MCP server 白名單,只允許公司內部 MCP(Slack 公司 workspace 的、GitHub 公司 org 的、內部 wiki 的)。外部 MCP 一律擋下。

MCP enforce 流程

我會這樣設

公司類型	tool 收斂	file access	MCP 白名單
新創 / 個人專案	不收斂(信任度高)	預設	不限制
一般軟體公司	禁 `rm -rf` / `sudo`	禁 `~/.ssh` `~/.aws`	公司 GitHub + Slack
醫療 / 金融 / 政府	全部 approval required	嚴格白名單	僅內部 MCP

🔒 動作 4:ZDR — 對話不存,法遵情境的核選項

ZDR(Zero Data Retention)只有 Enterprise plan 有,Claude Code Teams plan 沒這選項。但 ZDR 是評估是否升 Enterprise 的關鍵指標之一,所以放進來講。

根據官網 Zero data retention:

"Zero Data Retention (ZDR) is available for Claude Code when used through Claude for Enterprise. ZDR is enabled on a per-organization basis. Each new organization requires ZDR to be enabled separately by your Anthropic account team."

意思是 ZDR 不是 console 後台 toggle,要直接找 Anthropic account team 申請開通,per-org 一次性設定。

ZDR 開了之後變什麼

開 ZDR = Claude Code 的 inference(prompt + output)在 Anthropic 端不留存。但有 4 個地方不適用 ZDR(官網明寫):

claude.ai web chat — 還是會存
Cowork — 還是會存
Claude Code Analytics — token 用量、成本統計還是會留(這是 metadata,不是內容)
User and seat management — 帳號 email 等管理資料還是存

為什麼 ZDR 重要 — 反向解釋:沒開會怎樣

順便講一下動作 1 提到的「Primary Owner 能 export 全公司對話」這條的閉環。

官網 Export your organization's data 寫:

"If you use Claude Code from a Team or Max workspace seat, your prompts and outputs are treated as workspace data and could appear in a Primary Owner export."

翻譯:工程師用 Claude Code 跑的 prompt 跟 output 都算組織資料,Primary Owner 能 export 出來看。

沒開 ZDR,你公司技術機密就放在 Anthropic 那邊,Primary Owner 一個 export request 全公司對話拿到手。這是 ZDR 真正要解的問題 — 不是「防 Anthropic 看」,是「連 Primary Owner 都不該看」的法遵需求。

該不該開 ZDR

不是每家都該開。Trade-off:

情境	該開?	為什麼
HIPAA 醫療資料	✅ 該開	法律強制,沒得選
SOX 金融上市公司	✅ 該開	法遵稽核要求
政府 / 軍工標案	✅ 該開	合約條款
客戶合約有 data residency 條款	✅ 該開	違約風險
一般 SaaS / 新創	❌ 不該開	犧牲 Cowork 不划算
教學 / 內容公司	❌ 不該開	Analytics 功能損失太大

⚖️ 順便講:Data Export 我不會用、但你該知道存在

Data Export 是 Primary Owner 唯一專屬權限,但它不是日常管理工具。我把它列在「該知道存在」的能力,不是「會去用」。

什麼時候會真的用到:

離職交接 — 工程師離職前,Primary Owner export 該成員的 Claude Code 對話作為交接資料的一部分
法律調查 — 公司涉訟、被監管調查時依法令調出對話內容
法遵稽核 — 年度 SOC 2 / ISO 27001 audit 時抽查樣本

日常我不會 export 看任何人的對話 — 這是治理上的硬規矩。Primary Owner 有權力 ≠ 有正當理由用。

但反過來說,你成員應該知道這權力存在,這是透明度問題。我會在公司 README 寫一句:「公司使用 Claude Code Teams plan,Primary Owner(具名)依法令需要時可 export 對話內容,日常不主動存取。」

🔗 延伸資源

官方來源(本文每條 claim 對到的原文):

❓ FAQ

Q1: Claude Code Teams 跟 Enterprise plan 差在哪?

Claude Code Teams plan 有 4 個管理動作中的前 3 個(座位、Skills 派送、tool/MCP 收斂),沒有 ZDR。Enterprise 加上 ZDR、audit log、SCIM、SSO 等 enterprise grade 功能,需要直接找 Anthropic sales 報價,不是 self-serve。一般軟體公司 50 人以下基本上 Team plan 就夠,有法遵需求才升 Enterprise。

Q2: 沒開 ZDR,我們公司對話會被 Anthropic 拿去訓練嗎?

不會,Team 跟 Enterprise plan 預設都不用商業客戶資料訓練模型,這條官網 data usage 有寫。ZDR 解的是「Anthropic 端是否留存對話內容」這條,跟訓練是兩件事。即使沒開 ZDR,Anthropic 也不會拿你公司資料訓練。

Q3: Skills 派送下去,成員可以拒絕嗎?

可以 toggle on/off。Owner upload 後成員端會自動看到,但每個成員可以在自己 client 端關掉某個 skill。這是「派送 ≠ 強制」的設計,但實務上 90% 工程師看到自動出現的 skill 不會去關,所以 owner 派下去基本上會被用。

Q4: Primary Owner 離職了怎麼辦?

官網沒明寫流程,治理上必須離職前先轉移 Primary Owner 角色給接任者。如果已經離職沒轉,要聯絡 Anthropic support 協助轉移,流程會比較麻煩 — 你需要證明組織所有權(domain 驗證、billing 帳戶等)。所以這條我會列在公司 IT offboarding checklist 強制項目,不是「離職當天才想到」。