Claude Team 的 Projects 與連接器：把公司 SOP 變成全員共用 AI 助理

Claude Projects 企業用法講白了就一句：把公司的 SOP、範本、禁忌寫進一個容器，讓每個同事打開就能用，不必每次重新教 AI 一遍。很多公司買了 Claude Team，席次發下去，三個月後發現大家還是各自開新對話、各自貼 SOP、各自得到不一樣的答案。問題不在工具，在於沒有人把知識「放進去」。這篇從 Projects 是什麼講起，手把手建一個客服回覆 Project，再談連接器、Cowork，最後給你 SOP 轉 Project 的五個原則和一個多數文章不會講的維護現實。

本文的方案內容、價格、席次、功能與介面名稱，均以 2026 年 8 月 22 日 Anthropic 官方頁面查證為準。這類資訊 Anthropic 隨時可能調整，購買與設定時請以結帳頁、Help Center 與登入後畫面為準；本文會持續更新，更新日期見文末。

Claude Projects 企業導入的第一課：它是知識加指令的容器，Team 可以共用

先把名詞釐清。在 claude.ai 裡，一個 Project 有三層東西：一段「專案指令」（Project instructions），告訴 Claude 在這個 Project 裡要扮演什麼角色、遵守什麼規則；一組「知識檔」（Project knowledge），可以上傳 PDF、Word、文字檔、試算表（實際支援格式以上傳畫面為準），Claude 回答時會參考；以及在這個 Project 底下開的所有對話。指令與知識檔會自動套用到 Project 裡每一次新對話，你不必再貼一次。

個人 Pro 方案也有 Projects，差別在 Team 方案可以把 Project 設成「組織內共用」，同事打開就看到同一份指令、同一批檔案。依 Anthropic 官方的 Team 方案說明，Help Center 列出 Team 包含 Projects、Cowork、Claude Code、Enterprise search、連接器與 200k context window，加上集中計費與 admin 控制台，這幾樣加起來才是「全員共用 AI 助理」的底層（功能名稱以登入後畫面為準）。

共用 Project 解決的是「答案一致性」問題：十個業務問同一件事，得到的是同一套公司立場，而不是十種 AI 即興發揮。

換個角度想，Project 就是把「那位什麼都知道的資深同事」的腦袋，拆成可以上傳的檔案和可以寫下來的規則。資深同事離職，Project 還在；新人報到第一天，打開 Project 就能用公司的語氣回信。這跟你以前把 SOP 放在共用雲端硬碟最大的不同是：雲端硬碟的 SOP 要人去讀，Project 裡的 SOP 會主動參與每一次回答。

Projects 在 Team 方案的定位、跟其他功能怎麼搭配，可以先看Claude Team 完整指南有全貌；如果你還在評估 Team 與 Pro 差在哪裡，方案比較那篇有逐項對照。這篇只專注一件事：怎麼把 SOP 變成 Project。

逐步示範：建立一個「客服回覆 Project」

我拿客服回覆當範例，因為這是台灣中小企業最常見、SOP 最成熟、也最容易驗收的場景。一間賣保健食品的電商，客服每天回三十到八十封信，內容八成重複：出貨進度、退換貨、過敏成分、發票問題。這種工作最適合先搬進 Project。

第一步：指令怎麼寫

建立 Project 後，先填「專案指令」。指令不是寫「你是一位專業客服」就完事，那種指令跟沒寫一樣。我建議的結構是五段，每段都要有具體內容：

1. 角色與對象：「你是 XX 公司的客服，對象是已購買或準備購買的消費者，多數是 30 到 55 歲女性，用 LINE 或 Email 聯絡我們。」
2. 語氣規範：「稱呼用『您』，開頭不要說『親愛的顧客』，結尾固定一句『有任何問題都可以再回覆這封信』。不用驚嘆號，不用表情符號。」
3. 必查資料：「回答退換貨問題前，先讀知識檔裡的《退換貨政策 v3》；回答成分問題前，讀《產品成分與過敏原表》。找不到就說找不到，不要猜。」
4. 反例與禁區：「不可承諾任何療效。不可說『一定會改善』。遇到投訴要求賠償，一律回『已為您轉交專員，24 小時內回覆』，不自行答應金額。」
5. 輸出格式：「輸出一封可以直接貼上的回信，不要加『以下是建議回覆』這類前言。回信控制在 150 字以內，除非顧客問了三個以上問題。」

第四段「反例」是多數人漏掉的。Claude 很會寫，寫得太順反而出事，客服最怕的就是 AI 熱心過頭替公司答應了不該答應的東西。反例寫得愈具體，出包機率愈低。我常用的做法是把過去三個月客服被主管糾正過的回覆抓出來，每一條都變成一句「不可以」。

第二步：放哪些檔

知識檔不是愈多愈好。200k context window 聽起來很大，但檔案塞太多，Claude 找資料的精準度會下降，回答也會變慢。我的經驗是一個客服 Project 放 5 到 8 個檔案就夠：

格式上有一個實務提醒：Word 檔裡的表格、圖片、浮水印都會干擾，能轉純文字就轉純文字。試算表先刪掉隱藏欄位、合併儲存格，再另存 CSV。上傳前用肉眼看一次，確定裡面沒有客戶個資，Project 是全組織共用，放進去的東西等於全公司都看得到。

第三步：怎麼測

指令寫完、檔案放好，先不要開放給同事。自己先測。測法是準備 20 封真實的客訴與詢問信（去識別化），分成三類：簡單問題 10 封、需要查資料的 7 封、地雷問題 3 封（要求賠償、問療效、問競品）。逐封丟進 Project，拿結果跟資深客服的回覆並排比較。

驗收標準我建議這樣訂：簡單問題 10 封要有 9 封可以直接寄；查資料的 7 封要全部引用到正確檔案、沒有編造；地雷 3 封必須全部按反例處理，一封都不能答應賠償或暗示療效。地雷題只要錯一題，回去改指令，改完再測一輪。通常要改兩到三輪才會穩。

測試用的 20 封信不要丟掉，存成一份「驗收題庫」。以後每次改指令、換模型版本，都用同一套題庫跑一次，你才知道是變好還是變壞。

測完才開放。開放時在 Project 描述欄寫清楚「適用：客服信件回覆；不適用：LINE 即時對話、投訴處理」，讓同事知道邊界在哪。用量方面，Team 標準席約 Pro 的 1.25 倍、每人獨立、每週重置，客服一天跑幾十封通常夠用；真的不夠，Owner 可以依 官方額外用量說明在 Organization settings 啟用 usage credits 並設上限。

Claude 連接器清單與用法：讓 Project 讀到公司的即時資料

Project 的知識檔是「靜態」的，你上傳什麼它就知道什麼。連接器（connectors）補的是「動態」這一塊：讓 Claude 直接去 Google Drive 找最新版報價單、讀 Gmail 裡客戶剛寄來的信、查行事曆有沒有空檔。依官方說明，連接器含 Drive/Gmail/Calendar/GitHub/M365/Slack，另可透過 custom connectors 接 remote MCP 伺服器（以下為 2026 年 8 月官方列出的項目，隨時可能調整）：

實際功能以連接後畫面為準。

用法上，依我實際使用，連接器是掛在帳號層級，由每位使用者自己授權，然後在 Project 裡的對話就能呼叫。回到客服 Project 的例子：掛上 Gmail 之後，客服可以直接說「讀取今天標題含『退貨』的信，依退換貨政策各擬一封回覆草稿」，Claude 會去讀信、比對知識檔、寫草稿。人只要看一遍、按寄出。

Remote MCP 這項值得多講兩句。MCP（Model Context Protocol）是 Anthropic 推的開放協定，意思是任何服務只要做了 MCP server，Claude 就能接。我自己最常接的是 Google Search Console，後面經驗段會講。對中小企業來說，第一年通常用不到 remote MCP，先把 Drive 跟 Gmail 用熟比較實際。

連接器牽涉到公司資料進出，資安問題老闆一定會問。Anthropic 官方明確寫 Team 方案的資料 預設不用於模型訓練。對話則依 官方保留期說明，保留到使用者刪除為止。但 Team 沒有 audit log、沒有自訂保留期，那是 Enterprise 才有的功能。細節我在Claude Team 資安那篇整理過，掛連接器前先看一次。

Cowork：不會寫程式的人也能叫 Claude 跑檔案任務

很多老闆聽過 Claude Code，知道那是工程師用的。但公司裡九成的人不是工程師，他們的痛點是「有 80 個 PDF 要抓出裡面的金額填進 Excel」「這 30 份合約要比對哪幾份沒有簽名頁」這種檔案苦工。Cowork 就是給這群人的。

Cowork 是 Claude 桌面版 App 裡的一種模式。你指定一個本機資料夾給它，用白話交代任務，它會在那個資料夾裡讀檔、處理、寫出結果。不用開終端機、不用打指令。一個行政人員可以說「把這個資料夾裡所有發票 PDF 的日期、品項、金額抓出來，存成一個 Excel」，然後去倒杯咖啡。

Cowork 跟 Project 怎麼搭？Cowork 可搭配 Project 的指令與檔案使用（介面名稱與操作方式以登入後畫面為準，2026 年 8 月查證）。把「每月客訴彙整」這件事做成一個 Project，指令寫清楚分類標準，每月月初讓行政用 Cowork 指向客服紀錄資料夾跑一次，產出分類統計表。這就是一個不需要工程師的自動化流程。

桌面版 App 在 claude.com/download 可以下載，macOS、Windows 都有。安裝與開通的完整步驟，Claude Team 安裝指南有截圖對照。

補充：Claude Code 的 skills

工程團隊或比較進階的使用者會用 Claude Code，它有一個「skills」功能：把一套重複流程寫成一個資料夾裡的說明檔與腳本，之後一句話就能觸發整套流程。我自己把「文章寫好、上傳 WordPress、提交 Search Console」做成一個 skill，每篇文章省下大約二十分鐘的手動操作。Skills 在 claude.com/pricing 的 Team 功能表中有列出，並有組織層級的 skills 部署（Organization wide skills deployment），實際可用範圍請以你登入後看到的為準。Claude Code 本身 Team 所有席次都能用，不限 Premium 席，這點官方在 Claude Code on Team 說明寫得很清楚。

Claude Projects 企業落地：SOP 轉 Project 的 5 個原則

客服只是一個例子。業務報價、人資回覆應徵者、行銷寫貼文、採購比價，每一個有 SOP 的工作都能搬進 Project。搬的時候守五個原則，少走很多冤枉路。

原則一：一個 Project 只做一件事

最常見的錯誤是做一個「公司萬用助理」Project，指令寫了三千字，知識檔塞了四十個，結果什麼都會一點、什麼都不準。Project 要切細：「客服信件回覆」一個、「LINE 即時回覆」一個、「客訴升級處理」一個。切細的好處是指令短、檔案少、測試容易、出錯好找。切到什麼程度？一個判斷方法：如果這個 Project 的驗收題庫沒辦法在 20 題內涵蓋，就表示該拆了。

原則二：指令一定要寫反例

前面客服範例講過了，再強調一次是因為這點在每個部門都成立。業務報價 Project 的反例是「不可在未確認庫存前給交期」；人資 Project 的反例是「不可詢問或推論應徵者的婚育狀況」；行銷 Project 的反例是「不可使用『最』『第一』『保證』等廣告法禁語」。反例來源就是你們過去犯過的錯，把它們寫成句子，比任何正面描述都有效。

原則三：版本管理

Project 的指令和知識檔會改，而且改得比你想像的頻繁。政策調整、新品上市、老闆換了語氣偏好，都要改。問題是目前我沒看到版本紀錄功能，改過就蓋掉。我的做法是指令的正本放在一份 Google Doc，Project 裡只貼複本，Doc 開啟版本歷程；知識檔檔名一律帶日期。改動前先在 Doc 記一行「為什麼改」。三個月後你想回頭看為什麼當初這樣寫，會感謝自己。

原則四：每個 Project 要有名字在上面

誰維護？這個問題沒有答案的 Project，就是沒人維護的 Project。在 Project 描述欄直接寫「維護：王小明（客服主管），每月 1 日檢查」。不用成立什麼 AI 委員會，就是一個人、一個日期。下一個 H2 會講為什麼這件事這麼重要。

原則五：怎麼驗收要先講好

「大家覺得好用」不是驗收標準。驗收標準要可數：客服 Project 是「20 題驗收題庫通過率 90% 以上、地雷題零失誤」；報價 Project 是「10 張歷史報價單重跑，金額誤差為零」；行銷 Project 是「10 篇貼文有 7 篇主管不需修改」。訂不出數字的 Project，多半是任務還沒想清楚，先回去拆任務。

想知道這五個原則落地後能省多少時間，Claude Team 效果與 ROI那篇有幾個部門的試算。

多數文章不會講的事：Project 沒人維護，三個月就死掉

這段是我在企業內訓現場看最多次的劇情。一間公司很有熱情，兩週內建了十幾個 Project，上線那天群組裡很熱鬧。第二個月，退換貨政策改了，Project 裡的檔案沒跟著改，客服按 Project 回了一封錯的信，被客戶抓到。客服主管說「AI 不準」，從此叫大家回去用舊範本。第三個月，那十幾個 Project 全部變成沒人打開的空殼。席次的錢照繳。

Project 不是建好就結束的專案，是需要有人餵的活東西；沒有 owner 的 Project，通常撐不過第三個月。

根本原因是公司把「建 Project」當成 IT 的事或老闆的事，沒有把它放進某個人的工作職責裡。解法只有一個：指定 owner，而且 owner 要是「實際用這個 SOP 工作的人」，不是 IT、不是老闆。客服 Project 的 owner 是客服主管，報價 Project 的 owner 是業務主管。他們每月花一小時做三件事：看一下這個月同事在 Project 裡問了什麼、有沒有答錯；把政策變動更新進知識檔；用驗收題庫跑一次。

Owner 從哪裡來？所以 Project 導入要跟內訓綁在一起。我帶過的內訓，效果最好的不是全員大班課，而是先挑每個部門一到兩位「會用且願意管」的人，花半天教他們寫指令、整理知識檔、做驗收題庫，回去各自建自己部門的 Project，兩週後回來檢討。這批人就是天然的 owner。之後全員課程由他們帶，不是由我帶，因為他們講的是自己部門的例子。這套分層做法在AI 內訓課程規劃那篇有完整的課程結構。

Anthropic 的 Economic Index 2026 年 6 月報告裡，受訪者回報工作速度提升的比例是 86%，品質提升是 69%，68% 的人說學到更多。數字很好看，但這些受訪者是「有在用」的人。沒人維護的 Project 不會出現在任何統計裡，它只會出現在你的帳單上。Owner 怎麼選、內訓怎麼排，可以LINE 我聊聊你們公司的部門結構，我會給你一個建議名單的挑法。

另一個可以用的工具是 Team 的 usage analytics，Owner 或 Primary Owner 看得到活躍成員數與各成員用量趨勢（可匯出每人 CSV），入口是左下角帳號縮寫 > Analytics（介面名稱以登入後畫面為準）。一個 Project 上線後，如果該部門成員用量連續兩週往下掉，那就是 Project 出了問題的早期訊號，不要等到有人抱怨才處理。至於導入失敗的其他常見原因，Claude Team 導入失敗那篇列了五種。

第一手經驗：我自己怎麼用 Project 做客戶文章和 GSC 報告

講別人的之前先講自己的。小店軍師是 SEO 顧問公司，每個月要替不同產業的客戶寫文章、做 Search Console 報告。這兩件事我都用 Project 在跑，跑了超過一年，中間改過很多次。

客戶文章 Project

每個客戶一個 Project，不共用。原因是每個客戶的語氣、禁語、產品知識差太多，混在一起會互相污染。一個典型的客戶 Project 裡放：品牌語氣說明（兩頁）、產品規格表、過去表現最好的五篇文章、客戶明確說過不要的寫法清單、以及一份「SEO 文章格式規範」。指令大約六百字，核心是「先讀關鍵字與目標讀者，再讀產品規格，輸出的文章每個 H2 都要有具體步驟或數字，不可有空泛收尾」。

改最多次的是「反例清單」那個檔案。一開始只有三條，現在二十幾條，每一條都是客戶退稿過的原因。有一個做工業設備的客戶，退過一篇稿，原因是文章裡寫了「業界領先」，他們法務說不能講。這句就進了反例清單，之後再也沒出現過。這種累積沒有捷徑，就是被退一次記一條。

GSC 報告 Project

Search Console 報告我是用 remote MCP 接的。Project 指令裡寫清楚報告結構：本月曝光與點擊變化、前二十名關鍵字的排名變動、掉出前十名的頁面清單、下個月建議的三個動作。知識檔放客戶的關鍵字策略表和上個月的報告。每月月初，我在這個 Project 裡一句「跑八月報告」，Claude 透過 MCP 抓資料、依指令寫成報告初稿，我花二十分鐘校對數字和調整建議。以前這件事要半天。

兩個 Project 共同的教訓是：指令一開始不要寫太長。我第一版客戶文章指令寫了兩千字，Claude 反而抓不到重點。後來砍到六百字，把細節移進知識檔，品質反而穩定。還有就是驗收題庫，我每個客戶 Project 都有五篇「標準答案文章」，每次改指令就重跑，看新版有沒有比舊版接近標準。這套做法放到任何部門都通用。

如果你對 Claude 整體的能力邊界還不熟，先看Claude AI 完整指南，再回來做 Project 會順很多。

從一個客服 Project 開始，三個月後再決定要不要擴

不要一次建十幾個。挑一個 SOP 最成熟、錯誤成本最低、最容易數的工作，建第一個 Project，指定 owner，做 20 題驗收題庫，跑一個月。一個月後看三個數字：同事有沒有在用（usage analytics）、驗收題庫通過率、owner 有沒有在更新。三個都及格，再建第二個。這個節奏比「全公司一起上」慢，但三個月後活著的 Project 會比較多。

費用上，Team 標準席年繳是每席每月 US$20（2026 年 8 月官方定價，隨時可能調整），用 1:32 概算一席一年約 NT$7,680（依台銀 2026-08-22 匯率概算，實際以結帳頁與信用卡結匯為準）。一個客服 Project 每天替一位客服省一小時，一個月就把席次費用賺回來了。定價細節以 Anthropic 官方定價頁為準，席次數與試算在Claude Team 費用那篇有完整對照。最低席次官方頁面說法不一，Help Center 寫 2 席、定價子頁寫 5 席，以 Help Center 為準、購買時以結帳頁顯示為準。

Project 建得好不好，一個月內看得出來；Project 能不能活，三個月後才知道。把 owner 和驗收題庫當成 Project 的一部分，不是附加項目。

工具的錢是小錢，同事不用才是最貴的成本。所以我把 Claude 企業內訓設計成「帶著各部門建自己的 Project」而不是「介紹 AI 有多厲害」。想知道講師怎麼帶、一天課程怎麼排，AI 企業內訓怎麼做那篇有流程；想直接談你們公司的情況，走聯絡頁或 LINE 都可以。

常見問題

以下答案依 2026 年 8 月官方資料整理，日後可能變動。

個人 Pro 方案也有 Projects，為什麼要買 Team？

差別在共用。Pro 的 Project 只有你自己看得到，Team 的 Project 可以設為組織共用，同事打開就是同一份指令與知識檔。另外 Team 有集中計費、admin 控制台、usage analytics，老闆可以看到誰有在用。如果公司只有一個人要用 AI，Pro 就夠；兩個人以上要用同一套 SOP，就是 Team 的事。

一個 Project 知識檔可以放多少？放愈多愈好嗎？

不是愈多愈好，5 到 8 個檔案通常最穩。Team 方案有 200k context window，容量本身不是問題，問題是檔案愈多 Claude 找資料的精準度愈容易下降、回應也變慢。放不下就代表這個 Project 該拆成兩個。上傳前把 Word 轉純文字、試算表轉 CSV，去掉圖片與合併儲存格，效果會好很多。

把公司 SOP 放進 Project，會不會被拿去訓練模型？

依 Anthropic 官方說明，Team 方案的資料預設不用於模型訓練，只有使用者主動按讚或倒讚的回饋例外，而且組織可以關閉。對話保留到使用者刪除為止，刪除後 30 天內自後端清除（見 官方保留期說明）。要留意的是 Team 沒有 audit log 與自訂保留期，那是 Enterprise 才有；上傳前自己先把客戶個資從檔案裡拿掉，是最基本的做法。

Project 的 owner 應該是誰？一定要懂技術嗎？

owner 應該是實際用這個 SOP 工作的主管或資深同事，不需要懂技術。客服 Project 的 owner 是客服主管，報價 Project 的 owner 是業務主管。他們每月花一小時檢查同事問了什麼、更新政策變動、跑一次驗收題庫。這個角色最好透過內訓先培養出來，每個部門挑一到兩位，教會他們寫指令與做驗收，再由他們帶自己部門的人。

最後更新：2026-08-22