本文為《AI 輔助維運工程:從 Claude Code 機制到企業落地》系列第 7 篇。前兩篇分別處理了 token 成本(第 5 篇,如何在一個方案內省錢)和 SSDLC 工具選擇(第 6 篇,不同階段該用哪個入口)。這一篇處理最上層的商務決策:**該選哪個方案?**對我而言,選對方案的一次性決策,常常比後續一連串的技術優化更值得提早花時間想清楚。

開場:選型可能是你最容易忽略的省錢決定

我想先請你回想一件你可能做過的事。

你換手機資費方案的時候,應該有那種經驗——某天你靜下心來,把家裡三支手機的每月帳單加起來,發現一年竟然多花了好幾千塊,只因為當初沒仔細比較方案。後來你花一個下午研究、比較、換方案,從此每月省下兩千元。一個下午的研究,換來全年兩萬四的節省。

你省下的錢不是因為你講電話講得變少,而是因為選對了方案。

這個觀察對於 AI 服務的使用一樣成立。我自己在 POC 初期花了大量心力優化 CLAUDE.md、精調 MCP 設定、學習 /compact 的時機——這些都有價值。但我也看過(包括我自己)用錯方案的情境:一個個人 Pro 帳號,可能其實多花了錢,也少了 SSO、費用控管,預設還讓對話被拿去訓練模型。這些問題不是技術優化能解決的,只能透過選對方案來解決。

所以這一篇我們先不談技術,先談商務決策。Anthropic 目前提供四種 Claude 服務管道,每一種的計費方式、功能範圍、資料處理政策都不同。我希望這篇可以幫你比較容易判斷自己的情境屬於哪一類、適合什麼選擇,以及背後的理由。

四種方案的全景地圖

先建立整體感。Anthropic 的四種服務管道是這樣的架構:

個人版(Pro / MAX)。針對單一使用者的方案,Pro 每月大約二十美元(寫這篇時的公開定價),MAX 則依使用量分為每月一百或兩百美元。這通常也是初次接觸 Claude 時最常被使用的方案——你在瀏覽器打開 claude.ai,登入你的個人帳號,就是在用 Pro 或 MAX。

團隊版(Team Plan)。針對五到一百五十人的小中型組織。Standard seat 每人每月二十美元(年繳)或二十五美元(月繳),Premium seat 每人每月一百美元(年繳)。相較於個人版,它加入了 SSO、管理者後台、費用控管、M365/Slack/Google 整合等組織管理功能。2026 年以來 Anthropic 對這個方案做了大量功能強化,現在它已經是一個相當完整的組織級方案。

Enterprise。針對更大規模的組織,分為自助版(二十人起)和業務協助版(五十人起)。計費結構不同——每人每月二十美元的平台存取費,加上實際用量按 API 費率另計。這個結構意味著你的總成本取決於實際使用量,不是固定值。Enterprise 比團隊版多出的關鍵功能是稽核合規類——audit logs、Compliance API、IP allowlisting、自訂資料保留政策。

API。針對開發者與系統整合。這裡沒有「座位費」,完全按 token 使用量計費。你拿到一組 API Key,放進你的應用程式或自動化腳本,每一次呼叫按實際消耗計算。這是 Claude Code 在命令列背後用的機制,也是所有「把 Claude 整合進自家產品」的團隊在用的方式。

這四種方案看起來是「由小到大、由簡到繁」的漸進線,但實際上它們解決的是不同的問題——不是「買不起大的就買小的」那種關係。我用一個比喻讓你感受這個差別。

想像你是經營餐飲業的。個人版像是家用廚房——你一個人在家做菜給自己吃,不需要考慮食品安全、不需要記錄哪道菜賣給誰、只要你吃得開心就好。團隊版像是小餐廳——你有幾個員工,需要基本的分工、需要管理庫存、需要控制成本,但規模還沒大到要做 HACCP 認證。Enterprise 像是連鎖餐飲集團——你必須能追溯每一道菜的原料來源、每一位員工的工作記錄、所有流程都要能通過食品稽核。API 則像是中央廚房——你專門生產食材,賣給其他餐廳,你的成本是「產出了多少」,不是「雇了幾個人」。

這四種業態都是餐飲業,但經營邏輯完全不同。你不會拿家用廚房的思維去管理連鎖餐飲集團,也不會用中央廚房的計費方式去開一家小餐廳。選擇哪一種,取決於你真正在做的事情是什麼。

接下來我會一層一層打開每種方案,讓你能判斷自己屬於哪一種。

一個我自己一開始也不知道的嚴肅問題:訓練政策

在進入每種方案的細節之前,我必須先把一件事拉到台前來講。這件事我自己一開始也沒注意到,後來才意識到它的影響範圍——而且 Anthropic 並沒有很大聲地宣傳這件事,所以很多人(包括我自己)曾經在毫不知情的情況下,正面對一個可控但需要主動管理的風險。

這件事是:個人版(Free / Pro / MAX)從 2025 年 8 月起,採用 opt-out 模式的訓練政策。

讓我慢慢拆解這句話的意思,因為每個詞都很關鍵。

Opt-out 的意思是「預設開啟,除非你主動關閉」。對應到這個情境:預設上,你在個人版 Claude 的對話,可能會被拿去訓練模型。如果你不特別進去帳號設定裡關閉這個選項,你跟 Claude 說過的每一句話,理論上都可能成為未來版本的訓練材料。

這還不是最嚴重的部分。更值得注意的是:如果你允許訓練(也就是沒 opt-out),你的對話資料保留期會從預設的 30 天延長到 5 年。

讓我換一個方式讓你感受這件事的量級。你過去三個月用個人版 Claude 討論過的所有事情——工作上的 debug、規格書草稿、團隊內部討論、你寫到一半的簡報草稿、你向 AI 吐槽主管的抱怨——如果你沒有 opt-out,這些資料會在 Anthropic 的系統裡保留到 2030 年左右,而且可能出現在未來模型的訓練集裡。

這不是假設性的風險,這是 Anthropic 公開的政策。你可以在他們的 Privacy Center 找到原文。問題在於,我自己一開始也沒主動去讀那些政策文件,我猜很多人跟我一樣——預設行為就是「點選註冊、開始用」,完全不知道這個設定存在。

作為一個 infra 工程師,我用過公司內部相關的資料跟 Claude 討論過,我第一次知道這件事的時候也覺得很震驚。我當下立刻做了兩件事:第一,登入個人帳號把這個設定關掉;第二,開始推動公司內部禁止用個人版處理任何組織資料。

那這件事在不同方案上的處理差異是什麼?

個人版(Free / Pro / MAX)如前所述,採用 opt-out,風險由使用者自己管理。

團隊版預設就不用於訓練,而且這是 Anthropic 的商業條款承諾,不是單純的隱私政策——具有法律約束力。

Enterprise 完全不用於訓練,連「可以開啟訓練」的選項都沒有。

API 完全不用於訓練,受商業 API 條款和 Data Processing Addendum 保障。

看到這個差異,我自己對於「團隊使用」的場景就比較清楚:團隊版以上幾乎變成預設選擇。不是因為功能更多,而是因為資料保障的合約等級完全不同。

這個訓練政策議題,是這一整篇裡我自己最希望先講清楚的一件事。如果這篇你只先記一件事,我會建議是這個:如果你用個人版處理過任何一絲工作內容,我建議現在就去關掉那個訓練設定。這件事五秒鐘可以完成,但影響範圍是五年。

資料處理的兩條路徑:claude.ai 介面 vs API

講完訓練政策這個敏感議題,接著我們看資料處理的另一個維度——你的對話是透過什麼路徑送到 Anthropic 的。

粗略分成兩條路徑:一條是 claude.ai 網頁介面(以及對應的桌面、手機 App),另一條是 API(包含 Claude Code 在背後的呼叫)。這兩條路徑看起來都是「把資料送到 Anthropic」,但合約層級和保留政策差很多。

claude.ai 介面下,你的對話紀錄是以「使用者對話歷史」的形式儲存。後端日誌保留約 30 天,你可以自己刪除對話。個人版如前所述有 opt-out 訓練問題,團隊版/Enterprise 則無此問題。

API 的處理方式完全不同。API 呼叫不以「對話歷史」形式留存,而是以「請求日誌」形式。保留政策方面——這裡有一個很有趣、也很值得你學習的觀察——Anthropic 官方資料自己就存在不一致。

根據 Anthropic Developer Docs 和多個第三方分析的記載,自 2025 年 9 月 14 日起,API 資料保留期已從 30 天縮短至 7 天。但 Anthropic Privacy Center 的「組織資料保留」頁面,在本文撰寫時仍記載「30 天內自動刪除」。兩個 Anthropic 官方頁面對同一件事的描述不一致。

這個觀察有兩個層次的意義。

第一層是實用意義。你實際上需要知道自己的資料留多久。這個差異(7 天 vs 30 天)在合規稽核上可能是重要的。如果你準備採購這個服務,建議在決策前直接聯繫 Anthropic 確認目前實際適用之保留天數,而不是相信任何一個單獨的頁面。

第二層是工程意義,而且是這個觀察真正有價值的地方。即使是 Anthropic 這樣規模的公司,他們的官方資料之間也會出現不一致。這不是在酸他們,任何大型組織都會遇到這個挑戰——文件版本更新不同步、團隊之間的資訊傳遞延遲、甚至不同法務認知的差異。對你作為一個工程師或決策者的啟示是:不要盲目相信任何單一資料來源,即使它是官方的。重要決策前,交叉驗證、直接詢問、留下紀錄。這個工程紀律在 AI 時代格外重要,因為服務條款變動的速度遠超過傳統軟體。

Zero Data Retention:零保留的選項

不論 7 天還是 30 天,有些組織的合規要求可能是「零保留」——資料處理完就必須刪除,不能留存任何備份。Anthropic 對這個需求提供了一個選項:Zero Data Retention(ZDR)。

ZDR 的意思是:你的 API 請求資料,在處理完後立即刪除,不留存任何副本。這個選項不是預設的,必須向 Anthropic 申請,而且需要企業客戶資格才可申請——這意味著個人版使用者不能使用這個選項,必須是團隊版以上。

ZDR 對哪些場景特別重要?

處理真正敏感資料的應用。如果你的 Claude 呼叫內容包含個資、醫療資料、金融交易明細等,ZDR 讓你可以對合規稽核員說「這些資料在傳輸到 AI 服務時不會被留存,風險已消除」。

受嚴格法規管轄的產業。例如醫療業的 HIPAA、金融業的某些資料保護要求、政府專案的特定合規條款——很多時候這些規範明確要求「第三方處理敏感資料不得留存」。

高敏感度的軍事 / 政府 / 情報應用。這些場景下,即使 30 天也太長。

對於大多數一般企業而言,ZDR 不是必要的,因為 7 天或 30 天的保留期已經在合規可接受範圍內。但如果你在評估時發現「保留一天都不行」的場景,這個選項存在、而且可以申請。

每種使用者該怎麼選?一個決策指引

到這裡我們把四種方案的差異、訓練政策、資料保留、ZDR 都講完了。現在我把這些資訊整合起來,分享我自己怎麼根據情境思考。我把使用者分成五種典型情境,每一種給一個我會選的路徑,你可以對照看看自己接近哪一種。

情境一:個人工作者,用 AI 幫自己做事。你是自由接案者、獨立開發者、或公司內的單獨使用者,用 Claude 處理的都是自己的工作內容,沒有跨多人的管理需求。

這個情境下,個人 Pro 是合理選擇(每月二十美元)。但我會強烈建議馬上做一件事——登入設定,關閉訓練資料使用的選項。這五秒鐘的操作,把資料保留期從「最長五年」降到「預設 30 天」。對於要處理工作或客戶資料的使用者,我覺得這個設定不該被跳過。

如果你的使用量很大(每天密集使用超過四小時),MAX 可能比較划算。MAX 的用量上限是 Pro 的 5 倍或 20 倍,對重度使用者 ROI 更好。

情境二:小團隊(5-15 人),無嚴格合規要求。你和幾位同事共用 AI,可能是一個新創團隊、一個顧問小組、一個部門內的專案團隊。沒有強制性的 ISO 認證或 HIPAA 要求,但希望有基本的組織管理能力。

這個情境,團隊版 Standard seat 對我來說是很自然的選擇。每人每月二十美元(年繳)跟個人 Pro 同價,但多了 SSO、管理者後台、費用控管、Slack/Google 整合——對我而言最關鍵的是,資料不會被用於訓練,不需要逐一提醒每個成員記得去關設定。

五人起購是個門檻,如果你們只有三到四人,短期可以先各用個人 Pro 並確認每個人都關了訓練,等團隊擴充到五人再轉團隊版。

情境三:中型組織(15-150 人),需要組織管理。你是中小型企業、政府部門、或大公司的某個事業群。人員流動正常,需要帳號管理、需要費用控管、可能有基本的稽核要求但還沒到嚴格的外部認證層級。

團隊版 Standard/Premium 搭配使用是常見的實作。一般使用者用 Standard seat,重度使用者(例如工程師每天大量用 Claude Code)升級為 Premium seat。如果整個組織對 AI 的使用還在試水溫,全部先用 Standard 也沒問題,之後再看使用量調整。

一百五十人是團隊版的硬性上限。接近這個人數時開始評估是否需要升級到 Enterprise。

情境四:大型企業(150+ 人)或有嚴格合規要求。你是大型企業、金融機構、受嚴格法規管轄的產業、或需要外部 ISO 27001 / SOC 2 稽核的組織。

這個情境下,Enterprise 通常是繞不過去的選擇,不是因為團隊版功能不夠,而是因為這裡需要的一些功能只有 Enterprise 提供:audit logs、Compliance API、IP allowlisting、SCIM 自動佈建。稽核員會要求看這些東西,團隊版的基本管理後台不容易交差。

Enterprise 分自助版(20+ 人,可線上自助建立)和業務協助版(50+ 人,需聯繫 Anthropic 業務團隊)。大部分大型企業會選業務協助版,因為會有合約細節要談,也會享受業務團隊的採購支援。

有一個重要的實務提醒:目前團隊版無法自助升級到 Enterprise。如果你從團隊版起步,之後要升級,需要聯繫 Anthropic 業務團隊做遷移。這個過程可能需要一些時間,採購規劃時要預留。

情境五:有 AI 整合開發需求。你不只是「使用」Claude,你還要把 Claude 整合進自家產品、自動化腳本、後端服務。例如一個 SaaS 應用在背後呼叫 Claude 做內容生成、一個客服系統用 Claude 處理用戶問題、或一個企業內部工具用 Claude 做文件分析。

這種場景需要 API。API 完全按 token 使用量計費,沒有座位費。適合「用量不規律、由系統自動發起、而非由個人互動」的場景。

API 還有一個特殊價值——它可以跟你的其他服務管理方案並存。你的團隊成員各自用團隊版做日常互動(受座位費保護的用量),同時你的後端系統用 API 做自動化處理(按實際用量付費)。這兩條路徑的帳單是分開的。

一個進階的工程設計:去識別化閘道

到目前為止我們講的都是「選方案」,這是第一層的決策。但對於真正敏感的場景,有一個更進階的設計值得介紹——不論你選哪個方案,都可以加上這一層額外保障。

這個設計叫做去識別化閘道(de-identification gateway)。概念其實不複雜:在你的組織內部、資料離開你的環境送到 AI 服務之前,先把敏感資訊替換成假名。

舉個例子讓你感受這個設計的精神。

假設你有一個自動化流程,每天讓 Claude 幫你分析上百台伺服器的日誌。如果你直接把原始日誌餵給 Claude,Claude 看到的會是:「伺服器 prod-web-01(IP 10.0.1.23)在 2026-04-20 14:30 發生錯誤…」。這段內容送到 Anthropic 就進入他們的系統(保留 7 天或 30 天)。

去識別化閘道的做法是:在這段內容離開你的組織之前,先透過一個中介服務做替換。伺服器名稱 prod-web-01 被替換成 HOST_001、IP 10.0.1.23 被替換成 IP_042、時間被保持(時間通常不敏感)。Claude 看到的變成:「伺服器 HOST_001(IP IP_042)在 2026-04-20 14:30 發生錯誤…」。這段內容送到 Anthropic 時,已經不包含你的真實 infrastructure 資訊。

Claude 根據這些假名化的資料做分析、給出建議。它的回應回到你的閘道時,閘道再把假名替換回原始值,你看到的就是正確的伺服器名稱。整個過程對使用者透明。

這個設計的精妙之處在於:它把「資料保護」從『相信第三方』改成『不需要相信第三方』。即使 Anthropic 的保留期政策、訓練政策、甚至未來的條款變更,都不會影響你的敏感資料——因為那些資料根本沒離開你的組織,離開的只是一些無意義的假名。

要做到這一點,有幾個關鍵的技術細節:

同一個值必須對應到同一個假名。如果 prod-web-01 在某次呼叫被替換成 HOST_001、下次呼叫被替換成 HOST_042,Claude 會以為是兩台不同的伺服器,分析品質會崩盤。所以閘道必須維護一個「session 內一致性」的對應表。

某些類型的值不能替換。時間戳、錯誤代碼、架構類型、技術術語——這些不是敏感資料,替換掉反而讓 Claude 失去分析需要的語境。只有明確定義為「敏感」的類型(IP、hostname、人名、帳號、專案代號)才走替換流程。

還原要嚴格控制。假名還原到原始值這個動作,必須在你的組織內部完成,且有嚴格的日誌。如果假名對應表外洩,整個保護就瓦解。

這個設計不是每個場景都需要。對多數內部工具、寫程式輔助、一般文件處理,直接用 API 或 claude.ai 就夠了。但如果你的場景涉及真正敏感的資料(客戶個資、財務資料、醫療記錄、國家機敏資訊),這一層閘道可以讓 AI 使用更接近多數合規框架可以接受的範圍。

更重要的是,這個設計是跨 AI 服務可攜的。你的閘道不綁定 Claude、也可以用在其他 AI 服務上。未來如果需要同時用多家 AI 服務做比較或備援,同一套閘道可以支援。

合規與稽核的決策節點

講到這裡你可能想問:我怎麼知道我的場景算不算「需要嚴格合規」?

這個問題沒有標準答案,但有一些判斷點可以幫你。

是否受外部法規管轄。你的組織是否要遵守 ISO 27001、SOC 2、HIPAA、PCI-DSS、GDPR、或當地類似法規?如果是,這些法規通常會要求「第三方服務的稽核能力」。這是 Enterprise 的 audit logs 和 Compliance API 的主要價值——它們提供給稽核員直接可用的證據。

是否處理客戶的個資或資料。你的 Claude 使用是否涉及客戶的姓名、聯絡方式、交易紀錄、健康資料?處理客戶資料的標準通常比處理內部資料嚴格。如果是,去識別化閘道應該是基本配備。

資料的「保留風險」能不能接受。想像最壞情況:你的對話資料被保留 30 天(或 7 天),在這期間 Anthropic 遭到資料外洩事件(雖然機率極低)。這會造成什麼損害?如果答案是「會讓公司陷入法律糾紛」,那你需要 ZDR 或去識別化閘道。如果答案是「影響有限、可控」,那你的風險容忍度在標準保留期內就夠了。

有沒有「證明合規」的需求。這跟實際安全性是兩回事。你可能在實際操作上已經很安全,但稽核員要的是可以被審視的記錄。Enterprise 的 audit logs 不是加強你的實際安全性,是讓你有東西可以拿給稽核員看。沒有這個需求的組織,可以用團隊版;有這個需求的組織,很難繞過 Enterprise。

分階段採用策略:從小到大的路徑

如果你的組織正在評估導入 Claude,但還不確定要從哪裡起步,我給一個經過實務驗證的分階段路徑。

短期(0-3 個月):團隊版 Standard 起步。以團隊版 Standard seat 導入五到二十個核心使用者,建立基本使用慣例。這個階段的目標是「驗證 AI 工具能在我們的工作中創造價值」,不是「做到完美合規」。成本可控、功能完整、資料保障已達商業合約等級。

中期(3-6 個月):評估進階需求。隨著使用普及,你會看到某些使用情境需要更強的保障——可能是某個團隊處理客戶個資、可能是某個自動化流程處理機敏資料、可能是稽核開始詢問日誌。這時候我自己的做法是讓實際的使用情境驅動決策,而不是預設「我們以後一定需要 Enterprise」就超前部署。

長期(6 個月以上):確認最終架構。經過半年的實際使用,你會對自己的需求有比較清楚的認知——哪些團隊用哪種方案、需不需要去識別化閘道、要不要申請 ZDR。這個時候做的升級決策,是建立在真實資料上的,不是猜測。

這個分階段策略我自己摸索的精神是讓需求驅動採購,而不是讓採購驅動需求。我看過一些組織一開始就買 Enterprise,後來發現多數功能用不到,有點可惜。反過來,也有組織太晚升級,在被稽核員要求時手忙腳亂。我自己偏好從團隊版起步,讓實際使用告訴我下一步該往哪裡走。

我自己用的一個決策原則

這一篇的內容比較複雜,我想用一個我自己摸索出來的原則把它收起來。

我在選 Claude 方案時,問自己的不是「哪個功能最多」也不是「哪個最便宜」,而是:這個方案對我的『不能發生的事』提供什麼保障?

對一個個人工作者,「不能發生的事」可能是「我的工作對話被拿去訓練模型並保留五年」——所以選擇了個人 Pro,但立刻關閉訓練設定。

對一個小團隊,「不能發生的事」可能是「某個成員離職時,他的 AI 對話紀錄失控」——所以選擇了團隊版,有 SSO 和集中管理。

對一個受管的企業,「不能發生的事」可能是「被稽核時拿不出 AI 工具的使用證據」——所以選擇了 Enterprise,有 audit logs 和 Compliance API。

對一個處理高敏感資料的組織,「不能發生的事」可能是「客戶個資在未授權情況下離開組織」——所以在任何方案之上加了去識別化閘道。

對我自己而言,選型的關鍵不是正向的「我要什麼功能」,而是逆向的「我要避免什麼後果」。這個思考方式套用幾次之後,我發現自己的決策變得清晰一些——不是在功能清單裡打勾,而是在風險清單裡消除。

下一篇預告

這篇處理了「選對方案」這個商務決策,也提到了 Enterprise 的 audit logs、IP allowlisting、Compliance API 這些合規功能。但有一個更深層的議題還沒觸及——即使選對方案,你還需要在工具層級對 AI 施加技術性的約束。

設想這個情境:你給 Claude Code bash 權限,它在工作中決定執行一個 rm -rf 指令。這個行為在方案層級是合法的(方案允許 tool use),但這通常不是你希望它真的執行的事。

在 AI 可以執行真實指令的時代,光靠「選對方案」不夠,還需要「技術性的守門員」。這就是下一篇要談的主題:Hooks 與權限系統。我會用一個真實的維運事件當引子,告訴你為什麼這三道關卡是必要的、而且一道都不能少。

本篇收尾

對我而言,選對 Claude 方案,常常是這個工具使用過程中,影響範圍最大的一次性決策之一。

四種方案——個人、團隊、Enterprise、API——各自解決不同的問題,不是「由小到大的階梯」。個人版最便宜但訓練政策有 opt-out 風險,需要主動關閉。團隊版提供了組織管理的最小完整集合,我覺得是多數中小型組織比較自然的起點。Enterprise 的核心價值是合規稽核的證據提供,適合受法規管轄的大型組織。API 適合系統整合場景,按量計費、完全不用於訓練。

在方案之上,還有一層可以自己加的設計——去識別化閘道。這個設計讓你不必依賴第三方的資料保留政策,即使在最敏感的場景也能使用 AI 服務。

我自己摸索出來的核心原則不是「選最多功能」或「選最便宜」,而是「針對我不能發生的事,這個方案提供什麼保障?」用這個逆向思維做決策,我自己比較容易得到一個能說服自己的答案。

下一篇我們進入 Hooks 與權限系統,談技術層級如何讓 AI 真正聽話。

本文作者:鄧景仁 (Scott Teng) | 資訊服務業 infra 工程師,專注於 Azure / Linux / 安全維運。如需討論可聯繫 st333117@gmail.com。

本系列所有內容為個人學習與實務心得整理,不代表任職機構立場。文中所有 Claude 方案定價與政策資訊為 2026 年第二季的公開資料,Anthropic 保留隨時調整權利。重要採購決策前,請以 Anthropic 官方網站與直接聯繫確認之資訊為準。本文觀察到的官方資料不一致之處(7 天 vs 30 天 API 保留期),在撰寫時仍存在,讀者在做決策時建議再次驗證。

本文原刊於 https://eeit.github.io/ai-devops-blog/posts/07-plan-selection/，作者：鄧景仁 (Scott Teng)。
授權條款：CC BY-NC 4.0 · 禁止商業使用；分享請署名並註明原文 URL。
商業授權請聯絡：st333117@gmail.com