Claude Code 上手指南：從問答案到敢交辦

有一種工作每天都在辦公室裡重複：門市的銷售數字在 POS 系統、網路訂單在電商後台，各是一份檔案，月底想看一張按品類的毛利彙總，全靠人工慢慢剪貼；官網要改一句按鈕文字，得排工程師的時段，等排到才上線。這些事沒有一件稱得上難，卡的都是同一個地方：需要有人動手。聽過 Claude Code 的人會直覺想到它，於是裝了、打開，然後把聊天視窗裡的習慣整套搬進來，問一句，等答案，複製，貼上，再問一句。

問題就出在這個搬運的動作。把聊天視窗的習慣原樣帶進來，等於只用到它最表層的能力：要一段產出，自己拿去執行，成敗與它無關。Claude Code 的工作場所是專案本身，讀得到現況、改得了檔案、執行得了指令、看得到結果，據此一路修正到可以交付檢查的程度。它的價值不在「會寫程式」，而在「接得住一件事」；接得住的前提，是任務、邊界與驗收標準都先講清楚。成效的上限，由交辦與驗收的紀律決定。

新手與熟手的分野也在這裡：熟手把力氣花在講明範圍、想清驗收；措辭漂不漂亮，排在最後順位。

先把定義收乾：Claude Code 是 Anthropic 推出的代理式開發工具。接下來不糾結它「是什麼」，把篇幅留給更實際的問題：什麼該交給它、怎麼交代、交代之後你怎麼把關。後續照一條決策旅程走，從判斷任務、備妥現場、寫規範、開權限、盯節奏，一路到擴張自動化與看懂帳單。跟著走一遍，這些判斷會內化成工作習慣。

快速重點：Claude Code 是能讀寫檔案、執行指令的代理工具，入口有終端機、IDE、桌面 App 與網頁版。任務能不能交辦，看三個條件：講得清楚、驗得了好壞、回得了頭。權限照影響範圍與復原條件給，部署另立程序把關；登入身分決定計費走訂閱額度還是 API 用量。

第一道判斷：這件事需要誰動手

先分辨任務形態，再選工具。查一個語法、要一段草稿、問一個概念，對話視窗裡就能滿足，而且滿足得很快；就算要處理素材，網頁版的 Claude 也能動手，它能在自己的環境裡分析上傳的檔案、執行程式、產出結果，只是被處理的是交給它的那份素材，你的專案原地不動。換掉專案裡一批舊字串、把測試跑起來看到底過不過、把好幾份來源檔整併成一張總表，這類工作的對象是活的專案：目錄結構、版本狀態、跑得起來的環境，需要工具實際走進那個現場。差別不在聰明程度，在工作發生在哪裡、碰得到哪些東西。

代理工具靠繞圈前進：讀脈絡、定行動、執行、把結果讀回來，再決定下一步。改完的程式跑不跑得動、測試過不過關，它自己看得到，看到就修，後果當場現形，這是代理工具的分水嶺。也因為這個迴圈，成效取決於你交代了什麼、邊界畫在哪裡。同時記住一件事：迴圈每一圈都在消耗額度，繞的圈數愈多，成本愈高，這件事先記著，帳單診斷那一節會接上。

最常見的卡關，是把它用成一段一段的手工接力：要一段腳本，複製出去執行，失敗了回來描述錯誤，再要下一段。迴圈明明就在手上，卻被拆回人工搬運。交辦的範圍劃到哪裡，後果就現形在哪裡：只交一段產出，問題要等你自己執行時才冒出來；連同邊界一起交代，它繞圈修正的每一步都留在工作紀錄裡，多數錯誤在當場就被攔下處理，攔不攔得住，還看邊界畫得多細、驗收排得多密。

入門前，把出處與能力範圍弄清楚。官方文件列出的入口，常見有終端機、IDE、桌面 App 與網頁四種，並說明這個代理可以讀取程式碼、編輯檔案、執行指令，能力的完整描述整理在官方 overview 文件。

入口真正的差異在工作階段跑在哪裡，這是使用上的第一個環境決策。終端機與 IDE 直接開在本機：以你在這台機器上的登入身分，依你授予的權限讀寫硬碟上的專案。網頁版的任務在雲端環境執行，讀不到你的硬碟，要處理的程式與檔案得先交給那個環境。桌面 App 居中：可以操作本機專案，也能建立雲端工作階段，或透過 SSH 連上遠端機器，一個入口涵蓋三種現場。判斷方法很樸素：專案與檔案在哪裡，就從對得上的入口進去。同一個任務換了現場，行為細節會跟著環境變：路徑怎麼寫、權限怎麼給、哪些工具可用，都要重新對應，這是入口選擇不能隨便的原因。

分流還可以更具體。查概念、要草稿，留在對話介面，Claude 對話版的基本認識先補齊，功能的完整使用指南當地圖。對象是專案與檔案的工作，才升級到 Claude Code：批次改檔、跑流程、整理資料都算。如果你同時在考慮協作取向的工具，它與 Cowork 的分工比較把界線畫得清楚；想深究「代理」這個概念的人，再往AI 代理的運作原理走。

能不能交辦，先過三個條件

不是所有任務都值得交出去。判斷的對象是任務本身的特徵，不是你的職稱，也不是你會不會寫程式：講得清楚、驗得了好壞、出事回得了頭，三個條件都過，才交辦；缺哪個，先補哪個。

講得清楚，是範圍與產出都描述得出來：輸入是哪些檔案、要做什麼轉換、輸出長什麼樣子。一個講不清楚的任務交出去，它只能用猜的填滿空白，猜錯方向，之後每一圈都是時間與額度的浪費。把話講清楚的成本，遠低於事後重做的成本，這筆帳很好算。

驗得了好壞，是結果你自己或你的團隊看得出來對不對。報表的數字可以對帳，程式的行為可以測試，文案的好壞至少可以讀出來。完全無法判斷好壞的領域，交辦等於把品質的決定權一起交出去；這不是效率問題，是風險問題，而且風險在你身上，不在它身上。

回得了頭，是出錯時有退路。分支、副本、備份，任何能讓你還原狀態的機制都算。有退路，你才敢讓它放手試；沒有退路，它每一次嘗試都是賭注。工程師日常依賴的版本控制，本質上就是這件事的制度化，不懂技術的人用「先複製一份」也能達到同樣效果。

三個條件同時給出反向訊號。不可逆的正式環境操作，例如直接動線上資料庫，回不了頭，不交。你完全外行、身邊也無人可審的領域，驗不了好壞，不交。不必碰專案、只要一段參考內容的需求，對話介面回得更快，不必動用代理。把三個訊號記住，大多數「該不該交」的猶豫會直接消失，剩下的只是怎麼交的技術問題。

拿兩個任務練習判斷。把舊網站的文章批次搬進新網站，輸入輸出都明確，原始內容留在舊站、匯入對應留有紀錄，出錯時照紀錄清理重來，退路具體存在，三個條件全過，適合交辦。替公司決定下一季的投放策略，好壞要用市場結果與商業脈絡判斷，你若無法評估它的建議，第二個條件就不成立；這種任務可以交「整理資料、列出選項與依據」，不能交「下決定」。同一件工作裡，能交的切出來交，不能交的留在自己手上，這是三個條件最實際的用法。

有一種做法把「講清楚」推到極致：開發全程用自然語言驅動，程式碼由它生成、由它修改。這條路的完整討論在自然語言開發的入門說明，這裡先記住結論：自然語言主導，不免除檢查與測試，交辦的三個條件一條都不能少。

第一份交辦：把月底毛利表交給它

第一個任務選什麼，決定你對它的第一印象。選一個太難的，挫折來得比成就感快；選一個要碰正式環境的，風險不對等。低風險、有標準答案的資料整理，是最安全的起點：全程不碰正式環境，結果對不對一眼看得出來，出錯也只是錯在副本上。

想像一個場景：公司同時有門市與網路商店，POS 系統月底匯出一份銷售檔，網路訂單由電商後台再給一份，商品成本則記在一份人工維護的試算表裡。主管要看的是按品類彙總的毛利表，而你每月的工作是把三份來源接起來：先讓每筆銷售都帶上成本，再依品類做樞紐分析。這件事可以交辦。開一個交辦專用的資料夾放這批檔案，用平常講話的方式把任務說清楚，寫腳本、跑流程、接欄位對應，都由它一手做到產出彙總表，你打開來檢查就好。品類與成本的對應如果你手上已有一張對照表，直接給它，比讓它自己猜準得多。

交代要包含三個要素：現有檔案的長相（幾份、什麼格式、各有哪些欄位）、要做什麼轉換（兩邊的品類代號怎麼對、成本怎麼帶入、金額用什麼單位）、輸出的約定（什麼格式、哪些欄位、要不要依品類分頁）。三件事講清楚，來回就少；講不清楚，它做的每一個假設你都得事後檢查，等於把驗收往後拖。把需求講清楚本身是可以練的功夫，系統性的方法整理在提示詞的基本功。

交付之後，驗收做三件事，一件不省：

• 筆數對帳：兩份銷售檔的原始列數加總，與彙總表引用的明細核對，對不上代表有資料被吃掉或重複計入。
• 欄位對照：逐欄確認來源與單位，品類代號的對應關係抽樣複查。
• 抽樣手算：挑幾列自己重算一遍毛利與占比，機器算的帳由人抽驗；抽驗壓低漏網機率，不等於全查。

先對總量，再對結構，然後抽細節，這三個動作是之後所有任務的驗收原型，從資料表到程式碼都適用。資料工作有個殘酷的特性：錯誤會安靜地藏在數字裡，報表看起來完整，數字錯了照樣上得了主管的桌面。這是驗收不能省的原因。

同一套思路可以搬進行銷日常的其他資料工作。關鍵字排名表的自動整理與追蹤，做法整理在Claude Code 用於 SEO 的工作流；內容資產的盤點與可信度檢核，原則可以對照E-E-A-T 的評估架構。行銷人把 AI 助手放進日常工作，在產業調查裡已是常見做法，HubSpot 的行銷現況報告也記錄到同樣的走向。調查歸調查，你的第一份交辦，仍應從自己驗得了的那批檔案開始。

工作現場準備：裝好、走對資料夾、認清身分

開工前的準備只有三件事：裝好、走對資料夾、認清身分。裝機這一步不是主角；真正影響之後每一次執行的，是你在哪個資料夾啟動它、用什麼身分登入。

安裝有兩條路。官方原生安裝器是建議路線，不必先裝 Node.js；已經在管理 Node 環境的人可以走 npm，官方安裝說明列出的條件是 Node.js 22 以上，並提醒避免用 sudo 安裝。不同作業系統的安裝細節、完整命令與常見錯誤的排除，照官方 Quickstart 走一遍最穩，安裝指令會隨版本更新，永遠以文件為準。

Windows 與 VS Code 的安裝條件，官方文件也有現況可查。Windows 不必再繞 WSL：Windows 10 1809 以上可原生安裝，在 PowerShell 執行 irm https://claude.ai/install.ps1 | iex 即可，不必用系統管理員身分；沒裝 Git for Windows 時，指令由 PowerShell 工具執行，裝了才會改用 Git Bash。偏好圖形介面的人，VS Code 有官方擴充功能，條件是 VS Code 1.94.0 以上，以任一付費 Claude 訂閱或 Console 帳號登入，不需要 API 金鑰，擴充功能並自帶一份 CLI（見官方 VS Code 說明）。

裝好之後，啟動前先 cd 到這次要動的專案目錄。這一步決定它的預設工作範圍：相對路徑從哪裡算起、哪些檔案最容易被看見，都跟著啟動位置走。在家目錄裡出發，任務檔案淹在家目錄的一整片內容裡，無關的文件、設定、歷史資料都進得了視線，讀錯東西與資料外露的面積一起變大。不過要把話說準：啟動目錄便於聚焦，卻不是讀取的硬邊界，預設情況下它仍可能讀到目錄外的路徑，真正圈住讀取範圍的，是後面會談到的權限與沙盒設定。走進專案目錄再啟動，先把注意力收窄到本次任務；讀取範圍要收緊，就按最小必要原則核對權限，這次要讀什麼、改什麼、執行什麼，逐項看過，多給的收回來。

練習從拋棄式的資料夾開始：開一個測試目錄，放幾份無關緊要的檔案，跑完就整個刪掉，用低代價養成分界的工作感。對命令列完全不熟的人，先讀命令列的基本操作再回來；習慣圖形介面的人，桌面 App 的定位與邊界另有一篇完整分析，看懂入口的差異再選不遲。

第一週的練習內容可以很具體：找一份自己的資料，開一個資料夾放副本，交代一件很快能驗收的小事，例如重新排序、篩選、加總。跑完看結果，對了，你體驗到一次完整的交辦與驗收循環；錯了，更好，練的就是修正的來回。練的重點不是指令，是你自己的交代與驗收節奏。

登入身分也要在此刻確認。用訂閱帳號登入，用量計在方案額度裡；環境變數 ANTHROPIC_API_KEY 一旦設定，計費就改走 API 路線，跟你想不想無關，是機制決定的。完整的影響留給帳單診斷那一節，這裡先記住一句：身分決定路線，開工前看一眼。

把口頭交代寫成可核對的規範

同樣一個任務，有人交代一次就到位，有人來回十次還在原地，問題常常出在雙方對現場的理解沒有對齊；把共識寫下來，是縮短距離最直接的手段。Claude Code 的慣例，是把這份規範寫進專案根目錄的 CLAUDE.md，它每次啟動都讀得到，不用再用猜的；口頭交代靠記憶與默契，每次都要重講一遍。定位也要先講清楚：CLAUDE.md 是工作說明，不是安全邊界，這兩件事後面會分開處理。

好規範與壞規範，差在可不可核對

拿一個網店維護專案示範。壞版的 CLAUDE.md 只有一句「幫我顧好這家店」：訂單資料哪些碰得、版面哪裡動得，全部留給它猜，每次的產出隨每次的猜測漂移。好版把模糊要求換成可核對的規範，例如：這家店以 WooCommerce 接單，可以查改的對象是 staging 網站，正式站的資料庫不做實驗；版面客製全放在子佈景，不能散進佈景原始檔裡被升級蓋掉；凡是會寄信給客戶的流程，測試收件人一律換成內部信箱；購物車的計價與折扣規則集中在一支自訂外掛，調整之前先讀那支外掛開頭的說明。每一條都講得出「有做」跟「沒做」的差別，它照著做，你照著驗，模糊地帶被一條條消除。

規範不是寫完就結束。專案長大、慣例改變、踩到新的地雷，都該回頭更新；每一次它做錯而你必須重講的事，就是下一條該補的規範。示範用的是網店，換成一個 Astro 官網或一支內部工具，原則一條不變。判斷一份 CLAUDE.md 好不好，標準很簡單：需要重講的次數有沒有隨時間減少。

分層結構也要知道。使用者層級的指示放在 ~/.claude/CLAUDE.md，專案根目錄再放一份，兩邊會一起載入；寫了不一致的要求時，哪一邊勝出沒有保證，與其依賴覆蓋順序，不如把衝突消掉。行為跟預期不合，第一步是檢查實際載入了哪些指示，不是懷疑工具壞了；用 /context 指令展開 Memory files 清單，比口頭詢問可靠。分層的完整規則見官方 memory 文件。定位再講一次：CLAUDE.md 給的是脈絡，不是門禁，把「不可以」寫進去，擋不住任何實際的讀取，真正的管制在權限那裡。

兩個補充讓規範愈用愈省力。第一次進到新專案，可以請它掃過資料夾、草擬指示檔初稿，再由你逐條修訂；草稿終究是草稿，規範的最終責任在你。做得對的做法往往會反覆出現，值得沉澱成可重用的技能，封裝方式整理在Skills 的設計與封裝。

權限開到哪裡，由後果決定

權限的問題，從來不是「要不要信任它」，而是「這個任務的後果你扛到哪裡」。動手之前先攤開三個變數：影響範圍，這次要碰的檔案與系統有多大；外部副作用，會不會寄信、扣款、對外發佈；復原條件，出錯時有沒有分支、備份、可以照著走的還原程序。三個變數都輕，授權可以寬；任何一個變重，把關就要跟著升級。配套的手段各管一段：權限規則管工具呼叫，沙盒在作業系統層攔子程序，機密交給指定的安全機制。

用影響範圍把常見現場粗分三種。練習與資料整理，關在拋棄式的資料夾裡做，錯了整區刪掉重來；但資料夾可刪，不代表指令讀不到外面的檔案、碰不到外面的服務，授權要寬，前提是裡面沒有機密、沒有對外副作用，而且刪掉重來這條退路真的驗證過。日常開發與批次作業，對象是版本控制下的專案，改動落在分支或副本，沙盒同時限縮寫入範圍與對外連線，多數任務在這種現場就能收工。正式環境是另一種世界：資料庫、金流、對外服務都在這一側，人工審查、事前備份、復原演練三者補齊，才輪得到動作發生；這一側靠的是程序，不是「這次小心點」。

↔ 左右捲動檢視完整表格

現場	典型動作	復原與把關
拋棄式練習區	資料整理、流程演練	整區可刪重來；無機密、無對外效果，授權才從寬
版本內的專案	改檔、跑測試、批次作業	分支或副本隔離；沙盒限縮寫入與連線
正式環境	部署、資料變更、對外通知	人工審查、備份、復原演練齊備才動

兩種管制手段的分工要分清。權限規則管理工具呼叫：Read、Edit 這類工具能不能用、用在哪些範圍，由規則逐條決定。沙盒管理 Bash 子程序：指令執行時能寫入哪些路徑、能不能對外連線，在作業系統層被攔截。規則擋工具，沙盒擋指令，兩層疊起來，缺口才補得齊。

權限還有「模式」這個總開關，現行官方文件列出六種：default（在 CLI 顯示為 Manual，多數動作先問你）、acceptEdits（自動接受檔案編輯與常用檔案操作）、plan（只讀探索、不改原始檔）、auto（由背景分類器代你把關）、dontAsk（會觸發詢問的呼叫一律拒絕）與 bypassPermissions（跳過提示，官方建議只用於容器或 VM 等隔離環境）。CLI 裡用 Shift+Tab 切換模式，出發模式可用設定檔的 defaultMode 指定（見官方權限模式說明）。

沙盒的邊界，官方文件說得明白：它對 Bash 子程序提供檔案系統與網路的隔離，但預設仍可讀取多數路徑；機密檔案要另行設定拒讀，不能假設沙盒自動會擋（完整說明見官方 sandboxing 文件）。權限規則的完整設定選項，則整理在官方 settings 文件。

機密的管理，要把三件常被混為一談的事拆開：工作指示、Git 追蹤、工具權限。CLAUDE.md 是工作說明，寫了「不可讀取 .env」也不會產生任何強制力；.gitignore 只決定 Git 要不要追蹤某個檔案，擋不了任何讀取；真正的存取控制，是權限規則與沙盒。所以 API 金鑰與資料庫連線密碼，放專責的密鑰存放服務最穩；用環境變數攜帶時要留意，子程序預設可能繼承這些變數，遮罩、剔除或隔離要另行設好。客戶個資不是金鑰，原則是最小暴露，任務用不到的，放在代理讀不到的位置。再把可讀範圍限縮到任務所需，暴露面才壓得下來；把東西「收好」的動作本身，擋不了任何實際讀取。

執行節奏：隔離、證據、分段收

交辦之後的節奏，靠三件事壓低走山的機率：改動關在隔離區、交付附上證據、大任務切成小段。三件事互相撐著，少掉任何一個，前面的努力都會從後面的縫隙漏光；都顧到了仍不保證零失誤，差別在於失誤會在小的、看得見的地方現形，而不是一路滾到收尾。

範圍大的改動，先對齊影響面：這次會碰到哪些檔案、哪些系統、有沒有外部效果，開工前雙方看同一張清單。這張清單不是公文，是驗收時的對照基準：交付的時候，實際變更攤開來跟清單比，多改了什麼、漏了什麼、哪個風險沒處理，對得起來。少了這張底，事後只能逐檔翻找，審查全靠苦功；有了這張底，審查是對帳，不是抽獎。

隔離紀律只有一句話：改動發生在分支或副本，併回主線的時點由證據決定。證據看三樣：變更清單是不是落在約定範圍內、驗證輸出符不符合預期（測試紀錄、對帳結果都算）、有沒有帶著說不清的副作用。缺任何一樣，它就還在隔離區裡，不進主線；把沒驗過的東西先推出去，等於把品質關卡搬到傷害發生之後。審閱有個省力的訣竅：先看它自己寫的變更摘要，再挑修改最集中的檔案細讀，平均用力反而容易漏。

分段驗收的道理，用複利來想最明白：錯誤也會滾利息。錯誤發生在一個小階段裡，被這一段的驗收攔下，成本就停在這一段；沒有驗收點，錯誤往後段滾，後段又在錯誤上繼續蓋，成本一段墊過一段，直到大到收拾不了。所以大任務要切成邊界清楚的小階段，每一段都要能獨立說清楚「做什麼、產出什麼、怎樣算過關」，過關才進下一段。錯誤被逐段截斷，複利就長不起來。

真正左右穩定度的，通常是這一套執行環境的設計：計畫、隔離、驗收、回滾，四條路徑都要事先存在，模型等級帶來的差距反而有限。這個主題的完整討論，見執行環境的工程化設計。

平行與自動化的兩個前提

用順之後，下一個念頭多半是「能不能更省事」：開子代理平行做、接排程全自動跑。兩個方向各有一個前提，前提不成立，擴張只會放大混亂。

平行的前提是任務分界清楚、輸出可以獨立合併。子代理適合的場合，是工作能切成互不依賴的區塊，各自產出合回主線時不需要大量人工協調，例如把互不重疊的研究範圍分頭進行，再由主代理彙整。分界不清就平行，各做各的，合併時互相衝突，協調與重做的成本常常吃掉平行省下的時間；每個子代理各自的脈絡與來回，也全都要計入額度。平行是分工手段，不是省額度手段。開子代理之後，主代理的角色從執行者變成整合者：分派、彙整、把關一致性；這個角色沒做好，子代理再拚，也只是增加你事後收拾的面積。

自動化的前提是流程能事先描述、結果可供後續程式讀取使用。無頭模式把互動介面整個拿掉：任務由腳本、排程或 CI 觸發，受控執行，跑完直接把結果交給下游流程接手，例如每晚彙整當日數據並產生隔天要用的報表。上這種用法之前，三件事必須預先設定：權限（它能做什麼，事先限定）、停止條件（什麼情況必須停）、錯誤處理（失敗時誰接到通知、接下來做什麼）。非互動執行的完整指令與參數，見官方 CLI 參考文件。

兩個延伸讓擴張更平順。重複出現的流程，封裝成一鍵啟動的快捷指令，做法見常用流程的封裝思路。若偏好讓任務在雲端機器上跑、事後收回結果，責任邊界會整個移位：環境不是你的機器，權限由平台控管，審查的位置也換了。起手的概念差異見Codex 的入門介紹，遠端工作的接手、備份與復原，再往進階操作深入。

接上外部系統之前，先畫授權邊界

MCP 負責對外：讓它使用外部工具與資料源。Hooks 負責設關卡：在每個動作的前後掛上自動檢查，事前那道（PreToolUse）能拒絕還沒執行的工具呼叫，事後那道（PostToolUse）改變不了已經發生的操作，但能跑檢查、把結果回饋給它，也能對外發通知。兩者都把它的手伸得更遠，所以邊界要在接上之前畫好，不是出事之後補。

MCP 的能力邊界由三層共同決定：連接器本身提供什麼功能、你用哪個帳號授權、這邊的工具權限開到哪裡。以兩種常見連接為例：接 WordPress，它可以被授權讀寫內容、管理文章；接 Figma，它可以讀設計稿、協助把畫面轉成可用介面。連上不等於全開，它實際能讀寫什麼，由那個帳號被授權的範圍與你這邊的權限設定共同決定，兩邊任何一邊收緊，能力就縮小。協定的基礎概念見MCP 入門；兩個實戰案例，分別整理在WordPress 串接流程與Figma 設計稿轉畫面。

Hooks 的設計關鍵是時點。想攔下動作，檢查掛在事前：執行前看即將寫入的路徑有沒有超出專案範圍，超出就拒絕，動作根本不發生。想糾正與追蹤，掛在事後：執行後核對這次修改的檔案清單，發到協作頻道，發現的問題同時回給它，下一圈就修。事後的檢查再厲害，也撤銷不了已發生的操作，高風險的規則一律放事前；這個分寸拿捏好，Hooks 就設計對了大半。

設計類的分工也照這條邊界思考。視覺方向的探索交給生成工具，確定方向後再由 Claude Code 做工程化實作，兩段式流程的細節可以看Midjourney 出圖加上程式實作與畫面草稿的工程化上線兩篇；各自階段給出的權限，同樣照最小必要原則畫。

帳單診斷：訂閱額度還是 API 用量

同樣用它做事，兩個人的花費邏輯可能完全不同，原因通常只有一個：登入身分不同。身分決定計費路線，路線決定帳單長相，先診斷路線，再談成本控制。

路線一是訂閱額度：用 Pro 或 Max 方案登入，Claude Code 的用量與對話共用方案額度，包含在方案內；額度見底，選項是等重置、升級方案或加購用量，只有加購的部分才會分開計費。路線二是 API 計費：以 API 身分驗證，按 token 實際用量逐筆計費，沒有月費封頂的保護傘，用量波動直接反映在帳單上。兩條路線沒有絕對優劣，只有適不適合你的用量形態。看懂帳單的前提，是先看懂 token 這個計量單位，基礎概念見token 的入門說明。迴圈與帳單的關係在此接上：每一圈讀檔、行動、看結果，都是 token 用量。任務範圍畫得愈準、指示檔寫得愈清楚，繞的圈數就愈少，這是從機制著手的成本控制。

用量形態怎麼看？每天固定時段、任務大小相近，額度容易被預估，訂閱的確定性划算；任務大小忽大忽小、又有排程在背景跑，API 的彈性換來的是你要自己盯用量。混合用法也存在：互動工作走訂閱，自動化流程用獨立的 API 身分，帳目分開，診斷也乾淨。

這套計費規則的依據，是官方支援文章的說明：Pro 與 Max 方案的 Claude Code 用量與對話共用額度，達到上限後，可以等待額度重置、升級方案，或另行加購；以 API key 驗證時，用量則改按 API 計費。方案細節與額度規則會調整，購買前以官方文件的最新版本為準。

額度見底的處理順序，比選哪個方案重要。順序對了，常常不用多花錢：先收斂任務範圍，把大任務切小；再補齊指示檔，減少它試錯的圈數；這兩步做完仍然不夠，才談升級或加購。順序顛倒，等於用錢解決紀律問題，下個月同樣的壓力會再來一次。監控本身就是紀律：方案額度看得到重置時間，API 用量則要自己設提醒；等帳單到了才發現異常，通常已經太晚。想橫向比較的人，兩家方案的限額對照整理了 ChatGPT 與 Claude 各方案的邏輯差異。

走完這條旅程回頭看，每一節練的都是同一個動作：判斷任務、備妥現場、寫清楚規範、開對權限、盯住節奏、畫好邊界、看懂帳單。這些判斷多數不靠技術背景，靠的是紀律，以及對「可驗收」三個字的尊重；權限細節、部署與資安設定遇到拿不準的地方，該找技術支援就找，決定權照樣在你手上。

它把「動手」的門檻降了下來，於是「交代什麼、怎麼驗收」變成新的稀缺能力。任務可以交給它，決定權始終在你手上：交不交、交多少、什麼時候收回，每一步都是你的判斷。把這條決策流程走成習慣，工具再換幾輪，習慣都跟著你。