Claude 使用指南：模型選擇、費用與實戰方法解析

想像一個場景：週一早上，行銷部門的主管同時被三件事壓著。一份幾十頁的競品報告躺在信箱裡沒空讀，官網內容的產能追不上對手每週更新，會議上老闆問了一句「我們的 AI 到底用了沒」。於是有人開了 Claude 帳號，介面幾分鐘就摸熟，難題卻從交出第一件任務才開始：摘要讀完不敢直接用，草稿回鍋重改，額度與費用的問題接著浮上來。

多數人把 Claude 用壞，不是指令下得不夠漂亮，而是沒先判斷這件任務值不值得交、該從哪裡交進去、交了以後怎麼驗收。Claude 是 Anthropic 開發的模型家族與工作產品線，能讀資料、寫內容、做成品、改程式碼，產品全貌可另看站內的Claude 完整介紹。工具不難學，難的是交辦的判斷：體檢任務、分流入口、定義交辦講法、分級驗收，再用樣本與成本訊號決定模型與付費時點，收尾用一場對照實驗讓結論落地。

快速重點：模型不接工具時，答案靠生成不靠查證；接了搜尋，關鍵數字與專名仍要回原始來源核對。先用三道關卡體檢任務值不值得交，五種入口對號入座；中文 token 沒有固定倍數，額度看實測不背係數；驗收責任留在人身上。

任務體檢：三道關卡先過，再決定交不交

先別急著開帳號，也先別急著寫指令。判斷的順序是：任務本體是不是可以餵進去的資料、成果能不能事先說清楚、出錯的代價有多高。三道關卡依序過，三關都過的任務才值得交；卡在第二關，就先回頭把驗收條件寫清楚，再談交辦。

第一關看資料密度。任務本體如果是文字資料，例如報告、會議記錄、訪談稿、客訴摘要、程式碼，這些都餵得進去。但如果任務的核心是當事人的判斷，例如面試者要不要進到下一關、這筆預算該不該砍，資料只是配角，交出去換到的只是一段看起來完整的意見，不是判斷。

第二關看可驗收性。交辦之前，先問自己能不能一句話說出「做完長什麼樣」。說得出「把這場兩小時的會議逐字稿壓成一頁決議：誰負責、期限哪天、尚未定案的三個爭議點各列一行」，就有得驗；說不出來，代表需求還沒想清楚，來回修改的次數會替你證明這件事。

第三關看風險等級。同樣是摘要，給內部同事看的草稿，與掛上公司名稱對外發布的內容，覆核深度不同；牽涉醫療、法律或金流這些出錯代價高的領域，又是另一個等級。風險越高，驗收越貴，交辦前越要算清楚值不值得。

三關之外，有幾類工作建議直接留在自己手上：

• 需要當事人判斷的決定：報價要讓到哪裡、人事怎麼定，這類問題它給不了答案，只會給一段看起來像答案的文字。
• 對外發言的收尾關卡：範本它模仿得再像，掛上品牌名稱之前，真人逐句讀過、點頭放行的動作不能省。
• 含個資的原始資料：客戶名單、會員資料、未公開財報，先去識別或依組織規範處理，再談交辦。

邊界案例怎麼辦？多數真實任務是混合體：競品報告的摘要可以交，報告裡「我們該怎麼反應」的裁決要留給人。處理方法是拆解，把混合任務切成「資料整理」與「判斷裁決」兩段，前段交辦，後段自己來，中間放一個驗收點。拆開之後，交辦的部分變單純，留下的部分也因為資料先整理好而變快，兩邊都受益。

想快一點，用半小時盤點法：把上週的工作列出十項，逐項標三道關卡的通過與否，三關全過的放進可交辦清單，卡關的註明卡在哪一關。這張表從你自己的工作長出來，比通用建議貼近實況；每季重盤一次，清單會跟著職務內容演化。

盤點還有一個附帶收穫：看見自己工作的結構。十項裡如果只有兩項過關，問題可能不在工具，在工作的資料化程度；管理與溝通的本質是判斷，本來就不該交。十項裡如果七八項都過關，你面對的其實是產能問題，導入的優先順序自然不同（示意：比例因職務而異，重點在自己算一次）。

五種工作入口：你的任務該從哪裡進去

別記產品名，記動作姿態。同樣是「用 Claude」，動作可分成五種：問答與討論、做出可編輯的成品、直接動程式碼庫、遠端執行多步驟任務、把重複做法固定成可重跑的流程。任務屬於哪種動作，就從哪個入口進去，介面叫什麼反而次要。

拿一件真實任務走一遍分流。假設手上有一份競品資料要整理成分析：第一問成品形態，只在對話裡問答、讀長文、查資料，對話介面（Claude.ai）本身就是終點；需要一份能交給同事繼續編輯的文件或表格，就往成品輸出走，把格式與用途講清楚，它直接建檔。第二問要不要動你的環境：要它讀寫程式碼庫、在本機執行指令，入口是 Claude Code，權限先設好；要它在應用之間自己連續操作好幾步，入口是代理模式（Cowork），交辦前先劃出授權範圍。第三問這套做法還會不會再用：會重來，才把輸入、步驟與輸出格式寫成流程層的說明（Skills），要接站外工具或內部系統時搭配 MCP；只做一次，不值得建流程。

分流由淺入深：停在對話介面能解決就停留，要動環境才升級，確定會重來才做規格。

成品輸出值得多講兩句。要的東西如果會反覆修改，直接要一份可編輯的成品，比在對話流裡貼來貼去有效率：成品獨立成面板或檔案，改哪一段看得到、拿得到，版本也乾淨，簡報、表格、文件這類交付物尤其明顯。內容只有三兩句、用完即丟的回覆，留在對話裡就好，開檔案反而多一道工。

流程層的適用條件很樸素：做法寫得出來，而且工作會重來，兩個都成立才值得做。寫不出來，代表這件事你還沒想透，先在對話裡跑順再說；會重來但每次題目差很多，硬寫規格反而綁手綁腳。頭一次用說明文件交辦，拿一件做過的舊案驗收：它照說明做出的成果與你原本的成果差在哪裡，逐項比對，改到可用為止；改了幾輪還是不對，退回原本的做法，問題多半出在說明本身，不在執行。

Code 與 Cowork 的取捨一句話：改的是程式碼庫，還是一般文件與跨工具流程。前者是開發者的主場，Claude Code 官方頁有完整的定位說明，兩者的邊界與適用對象，可再讀Code 與 Cowork 的比較分析。決定走 Code，跟著Code 的安裝與設定教學把權限設好；要讓 Cowork 跑知識型任務，先讀Cowork 的操作與授權須知再交辦，授權範圍想清楚，遠端執行才不會變成風險。

分流之前，一個機制要先講清楚：對話裡的網路搜尋、檔案產出、成品面板，都屬於工具呼叫，它並非隨時自動在查網路。模型的訓練資料有知識截止，問它最新資訊要靠搜尋工具輔助，查到的內容也要回原始頁面核對。入口的外觀會改版，Chat 與 Cowork 正逐步整併成同一個介面；分流依任務的動作類型判斷，不要綁在按鈕位置上。多數文件、分析與內容工作，包括把常用做法寫成交辦說明這件事，都在對話介面裡完成；要它跨工具自己跑、或無人值守接進系統，才動用到代理模式與 API 類入口。

交辦的方式，決定你來回修正幾次

同一句「幫我處理」，有人一次拿到可用成果，有人來回五趟還在改。差別不在運氣，在交辦的方式。來回次數是隱形成本，比模型等級更影響總時間；把每次來回當錢看，四個做法多數能把趟數壓下來，至少讓每一趟都有明確的修改目標。

1. 脈絡與目的先講：這份東西給誰看、用在哪裡、判斷標準是什麼，開頭就交代。中文任務把用語慣例講明，指定繁體寫法與在地用詞、排除中國慣用語，能省掉整篇改用語的來回。
2. 範例當規格給：說「大概就那個調性」，它只能照字面猜，猜錯你再解釋一輪；一篇你認可的舊作放進指令，長度、語氣、結構當場有依據。形容詞給不了規格，成品給得了。
3. 長任務分段放行：動筆前先要一份預定結構，你刪改到同意為止；展開後每完成一個段落停一下，偏離當場拉回，別等整份交齊才發現開頭就走歪。
4. 修改意見沉澱成規則：每次改完，把「以後都要這樣」的意見寫進脈絡或專案設定，同樣的問題不值得改第二次。

再多走一步：把驗收標準直接寫進指令。「每個數字附出處」「結論不超過三點」這種可檢查的條款，讓它在交付前先自我檢查一遍，你驗收時對照清單勾選，不必從頭讀起。

脈絡給什麼，用一件行銷任務想一遍（示意）：請它寫產品頁文案，至少交代產品賣給誰、解決什麼問題、跟誰競爭、文案放在哪個版位、長度上限，以及品牌不用的詞。這些背景你腦子裡都有，不寫下來，它就只能猜；猜錯的代價不是它笨，是你再花一輪時間解釋本來一次就能講清楚的事。

一個對照例（示意）：八千字的訪談逐字稿要萃取觀點，只說「幫我整理」，成品常在主題選擇上來回三次，一下子太廣、一下子漏掉重點；換成「給刊物編輯看，抽出六句可直接引用的原文、每句標時間戳，另附三個受訪者立場反覆的地方」，一次可用的機會高得多。差別不在模型變聰明，在第二次交辦把驗收條款寫死了。

把指令拆解得更細的手法，站內另有prompt 結構的完整拆解可以延伸。

驗收不能外包：風險分級的覆核方法

產出可以交辦，查證不能。覆核深度依出錯代價分三級：內部草稿抽看就好；對外發布的內容，數字、專名、引用逐項核對；醫療、法律、財務全查原始來源，沒有例外。分級的理由來自它的運作方式：答案是從語言模式生成出來的，背後沒有一個可以翻查的答案庫，流暢與正確是兩件事，語氣自信從來不是可靠度的指標。官方文件也如實說明了模型可能出錯或誤導的情境，可對照Anthropic 的說明中心。

生成式回答有個容易讓人誤判的特性：錯的句子看起來跟對的句子一模一樣，語氣不會心虛。重新排列原文的工作也不例外，逐字稿整理、表格化、語氣改寫的輸出同樣是生成出來的，不是原文的鏡像，數字、人名與前後因果可能在你沒盯著的段落裡被悄悄換掉。核對因此要挑重點欄位：統計、引文與專名所在的句子，回原文比對過才算數。成因與防範的完整討論，可以接著讀AI 幻覺的機制與應對。

• 內部草稿：抽看結構與語氣，數字暫記待查，上稿前補核。
• 對外發布：數字、人名、日期、統計來源逐項核對，責任人確認。
• 高風險領域：每一條主張找到原始文獻或官方文件，找不到就不寫。

引用的查法有先後：先查它給的來源存不存在，再查來源是否真的支持那句話。錯誤的引用有兩種，一種是連結或書目是編出來的，另一種更隱蔽，來源存在、斷章取義。第二種只能靠人打開原文讀前後文，工具再強也替代不了這一步；把這一步寫進流程，比期待模型不犯錯可靠。

驗收條款要寫在交辦時，不是做完才想。什麼算完成、什麼不算，交辦單上寫清楚，事後才有得驗；條款越具體，覆核越接近勾選，越不像重讀一遍。最終的判斷與署名責任留給人，工具承擔產出，不承擔後果。

模型怎麼挑？用你自己的樣本說話

挑等級這件事，先排除三種常見動機：聽說旗艦比較強、網路評測說讚、單純想省等待時間。這三個理由有個共同點：都跟你的任務無關。能拿來定案的依據只有一種，你自己的驗收條款下的分數。

產出品質類的任務用盲測定案：最近真正做過的一批工作，讓目前的方案跑一遍，成果放到平常的驗收條款下打分數。分數過了，不必動換等級的腦筋；每次都卡在同一種問題上，才是換等級的訊號。批次雜事走另一種算法：歸檔、貼標籤、格式轉換不必比品質，抽一小批人工核對正確率，乘上每月件數與費用，划算的等級一目了然，帳面單價在這種算法裡只是一欄（示意：抽樣只當初步估計，出錯代價高或錯誤頻率低的任務，把觀察期拉長、查核比例提高，別靠一次抽樣定案；樣本不用多，幾十件通常夠做初步判斷）。做完這一步，要不要升級從感覺變成算術。

理由是一組交換關係：能力、等待與費用綁在一起，更強的模型通常更慢也更貴，最貴的選項不保證更好。換模型之前先確認瓶頸在哪一端；瓶頸是需求沒講清楚，換到最強的模型照樣來回修改。

等待也是成本的一部分。同樣的任務，等強力模型慢慢算，有時不如讓目前的模型先出一版、你邊看邊改，總工時反而更短；把等待算進去，模型之間才比得準。升級之後要回測：同一批樣本重跑一次，確認升級買到的改善真的落在卡關的環節，沒有就退回原級，預算花在刀口上。

升級走階梯，不走跳階。現有等級起步，出現觸發訊號再升一級重測：複雜推理反覆卡關、長文結構與論證明顯不足、高風險段落的錯誤壓不下來，這些算訊號；新奇感與行銷頁的宣傳文案不算。

型號、價格與供應狀態持續更新，逐項背誦沒有意義，挑選時以官方模型總覽的現況為準。各產品線的定位，站內另有兩篇可以對照：中階主力的現行定位與旗艦這條線的最新進展。

中文字數換不到固定額度：token 成本的真實算法

沒有固定倍數可背。模型計量用 token，中文一個字未必對應一個單位，同一份稿子換個模型，帳面用量跟著移動，網路上流傳的字數換算係數，換個模型常常失效。要估自己的成本，從實測出發，但先分清楚兩種帳：訂閱方案的用量頁呈現的是各時段與每週額度的消耗進度，不是逐件任務的 token 帳單，實測的做法是挑一件代表性任務完整跑完，觀察前後額度掉了多少、連做幾件之後節奏如何；走 API 或自建流程，開發平台的用量紀錄才會列出逐筆請求的數字，拿單批實測成本乘上預計量級，就是最貼近的估算。兩條路都以自己的數字為底，不背網路係數。

對額度的實際意義：與其記「幾個字等於幾次」，不如觀察消耗節奏。同樣的任務做幾天、用掉多少，心裡有數之後，排任務的先後就有依據；估成本這件事，從背係數變成看自己的帳。

自己架的流程要算單位成本，預算的做法是先小批試跑：拿一小批真實資料走完整流程，算出單批成本，再乘上預計的量級，得到預算區間後設上限上線。上線之後定期看帳，用量異常暴增，通常是流程裡混進了沒預期的長文件，早發現早處理，別等月底帳單才知道。

想減少不必要的用量，可以先從三個動作試起：

• 刪無關背景：要摘要就只給目標內容，整串信件往來一起貼，只是讓離題資料占掉資源。
• 任務開新對話：不同主題續聊同一個對話，先前的內容一路墊在後面，同一對話裡用量大致向上累積（快取等機制會影響實際計費，依官方說明為準）。
• 長期資料收進專案知識庫：品牌指引與常用範例放專案，不必每次對話都附上一遍。

機制上，脈絡空間有限：對話越長、貼的資料越多，可用空間越少，離題內容一樣占位，而且占得安靜。token 的切分機制與計價細節，站內另有token 的完整解析可以深讀。

付費時點：出現哪些訊號才值得升級

讓訊號說話，別讓焦慮刷卡。免費方案先用起來，出現訊號再逐級升級，四種訊號最常見：額度在正常工作天反覆撞頂、尖峰時段的等待打斷節奏、團隊要共用資料與流程、要把模型接進自動化。付費調整的是可用量與處理的優先程度，不是無限量供應；這層預期建立在刷卡之前，帳單出現之後就不必補課。

• 額度反覆撞頂：算一下省下的時間值不值得月費，值得再升個人方案。
• 尖峰等待拖慢交付：升級換取處理的優先程度。
• 團隊要協作：資料與流程要共用，評估團隊方案的管理功能。
• 要無人值守的批次與系統整合：這才需要 API 類的按用量接入，先設成本上限再上線；對話內的重複工作，流程層就夠。

團隊方案的判斷多一個維度：要共用的是資料，還是只是工具。大家各自用，個人方案各自買可能就夠；要共用專案知識庫、統一流程與權限管理，團隊方案的管理功能才有價值。先盤點要共用的東西，再對照方案功能，順序不要反，免得為了用不到的管理功能，多付一輪按人頭計費的月費。方案內容與價格隨政策調整，編列預算以Anthropic 定價頁的現況為準，第三方轉述的數字別拿來做決定。

還有一種訊號常被忽略：有人開始問「這個結果是怎麼做出來的」。留在個人對話裡的產出，來龍去脈只有一路跟著聊的人看得懂；當成果要對團隊或客戶交代，做法與資料來源就需要一個說得出、指得到的位置。下一節談這個位置怎麼安排。

退場也納入流程：每月回看訊號還在不在。額度不再撞頂、等待不再影響工作，就降一級再觀察。升級要有理由，降級要有紀律，訂閱閒置的月份，就是判斷流程斷線的證據。

團隊要共用，先分清楚脈絡與規則

多人一起用，問題從「會不會用」變成「大家看到的是不是同一份資料」。背景收攏以專案為單位（Projects）：資料、對話與規範放在同一處，專案內的對話取得到，引用時指得到出處。共用之前先約定什麼該放、什麼不放：界線不清的知識庫，很快就會變成誰都不敢引用的大雜燴，放了等於沒放。

Projects 的定位見官方說明：對話、文件與專案設定收在同一處。放資料之前，記憶的邊界要先弄清楚：無痕對話不會進入聊天紀錄與記憶，但內容仍可能依官方政策保留一段期間，組織方案另有管理設定，別因為「無痕」兩個字就把敏感內容放心輸入；專案層級與帳號層級的記憶互不相通，跨對話記憶與聊天紀錄搜尋也各有明確範圍。

放什麼進去，先分級再動手：可公開的背景與規範直接放；客戶個資、未公開財務與合約內容，先做去識別化，或按公司內部規範評估，並確認方案條款與保留政策再決定。這是偏保守的分級建議，不是產品的硬性規則，重點是全團隊用同一套標準，一頁寫完，比出事後補救便宜。

做法的共用走 Skills：把步驟與判斷標準寫成它讀得到的文件，官方說明在Agent Skills。共用的價值在討論有對象：成員對做法有不同意見，指著同一份文件逐條修，比各自做完再互相比對省事；它不保證每次執行分毫不差，驗收條款仍然要留。從零打造一個 Skill 的細節，站內有Skills 的完整指南。

共用的資料要有更新節奏。放進專案的舊報告、去年的價格、改版過的介面截圖，容易被之後的對話當成現況引用；每隔一陣子清點一次，過期的換新或標上時間，需要做決定的段落才不會拿舊世界推出新結論。

SEO 與內容產線上的分工界面

做內容與 SEO 的團隊，界線要畫得更細。AI 進入內容產線已是產業常態（HubSpot 的行銷現況報告可當佐證；採用普遍是現況描述，不代表成效高下），所以差距不在用不用，在界線畫在哪。可以交的是讀料與整理：意圖歸納、競品內容盤點、大綱選項；必須留給人的是觀點與署名責任：立場、第一手經驗、最終查證。每個交接點都寫下驗收條款，分工才不會變成失責。

↔ 左右捲動檢視完整表格

產線段落	可交辦程度	交接點驗收條款
搜尋意圖研究	交整理，人裁決	意圖判讀清單逐條人工複核
大綱發想	交選項產出	每個小標對應一個讀者問題才算過
初稿撰寫	交段落草稿	結構與觀點由作者定案
事實查證	不交辦	統計與引用找到原始出處才寫
文字潤飾	交字句層次	品牌語氣由真人把關

意圖研究段的做法：把同主題排名前面的文章、讀者留言與討論串一起餵進去，請它做分類統計，哪些問題被回答過很多次、哪些提問至今沒有得到滿意的答案。它交回來的是一份觀察筆記，哪些算趨勢、哪些只是少數人的偏好，由你判斷；搜尋意圖的判斷方法可以對照著用，避免把它的歸納直接當結論。

在地商業的內容也適用同一條界線。商家介紹、服務頁、顧客評論的整理，資料面的結構化可以交；「這家店的特色是什麼」「哪種說法在地顧客會買單」，需要真實接觸與現場經驗，這是內容做出差異的地方。交辦整理、保留觀點，產線才會又快又像你們自己。

查證段沒有妥協空間。初稿裡出現「研究指出」「數據顯示」而後面沒有出處時，不要叫它把出處補上；這一補，拿到的可能是一個格式完整、點開卻對不上的引用。正確的動作是退回：哪句話帶數字，就要求附原始文件，附不出來的整句刪掉。轉述鏈越長，數字漂移越遠，你拿到的版本可能已經過了好幾手轉述，源頭文件的作者未必說過那句話。

Google 的立場可以放心講：不會只因內容由 AI 製作就自動降權，處理濫用仍以品質與目的為準，官方說明在Google Search Central。信任評估裡最難代勞的一格是 E-E-A-T 的 Experience：素材可以代整理，涉及親身使用或現場觀察的主張，要能提出可核實的實測或採訪來源，這一段機器補不上；Google 也說明內容不必同時展現所有面向，量力而寫，別把沒有的經驗說成有。經營方法見E-E-A-T 的實務拆解。

試導入：用一場對照實驗定案

讀完判準，給一個收斂的方法：挑一件本週的真實任務做對照實驗，規劃上預留一段完整時間（以九十分鐘為規劃基準，實際長短依任務而定）。同一件事用原本的做法走一遍，再交給 Claude 走一遍，記下時間、品質與覆核成本，用數據代替「感覺好用」。

1. 選一件通過三道關卡的任務，先寫死驗收條款，兩種做法用同一條件驗收。
2. 兩種做法各計時（示意：以自己實測為準，別拿別人的數字）。
3. 評分有先決條件：品質先過驗收條款，過不了直接淘汰，時間再省也不採用。過了再算時間帳：原做法的總工時，對上 AI 路線的操作、等待、來回修改與覆核總工時，兩邊都換算成分鐘加總。

記錄用最簡單的格式就好：任務名稱、兩種做法各花的時間、覆核花的時間、一句品質評語。格式越簡單，越可能被真的填完；實驗的價值在持續比較，不在文件漂亮。

判讀規則很簡單。品質過關、時間帳又是正的，這件任務排進常規流程，下週再挑第二件；品質過關但覆核工時吃掉了省下的時間，先別下「不好用」的結論，回頭改交辦方式再試一輪，多數時候問題出在沒給脈絡與驗收條款，工具只是放大了交辦的模糊。

第二輪的設計跟著第一輪的結果走：敗在覆核成本，改掉交辦方式再測同一件任務；時間帳仍是正的，就把這件任務的交辦模板存下來，排進每週流程。實驗的產出不只是「值不值得用」的結論，還有第一份屬於你自己的交辦模板，那才是導入真正的資產。

工具會改版，模型會替換，介面會整併；體檢、分流、交辦、驗收的流程搬到任何工具上都成立。把流程練起來，換工具時要重學的只剩介面位置，這比記住任何一家的規格表都值得。

導入前的五個疑問

不會寫程式，需要用到 Claude Code 嗎？

通常不必。Code 的強項在直接讀寫程式碼庫、執行指令與批次處理本機檔案，非開發工作用到的機會不高；文件、分析與內容產出，對話介面加上成品輸出多半夠用。哪天需要它動到你的網站、系統程式或整批檔案，再評估不遲。

免費方案大概能做多少事？

日常問答、文件摘要、改寫潤飾都做得動，深度與速度會在額度與高峰限流上出現落差。額度隨方案政策浮動，能做幾次沒有標準答案，實測一週自己的任務量，數字會比任何轉述都準。

把客戶資料放進 Projects，該留意什麼？

先分級再放。可公開的背景與規範放進專案沒問題；客戶個資、未公開財務與合約內容，先做去識別化或按公司內部規範評估，並確認方案條款與保留政策。資料放入專案知識庫後，可供該專案內的後續對話取用，實際用到什麼仍應核對；放的範圍越大，管理責任越大。

用中文提問，效果會打折嗎？

可以直接用中文對話與產出，日常工作足夠應付，實際表現依模型、任務與資料而異。比較容易出落差的是用語慣例：不指定時，產出可能偏向通用語感；講明「繁體中文、在地用語」並附一篇你認可的範例，貼近度有機會改善，成果仍要自己讀過。語言本身別擔心，把用語要求講清楚就對了。

模型一直改版，現在學會不會白學？

型號會汰換，兩種能力不會：判斷任務該不該交、怎麼驗收的流程，以及把需求講清楚的交辦語言。這兩者跟著你換任何工具；追規格表的人才需要擔心改版，用流程工作的人把改版當例行更新。