W whoops.tw

Claude Code 是什麼?Claude Code 中文教學:安裝、用法、價格與新手避坑

Claude Code 是 Anthropic 官方推出的 agentic coding tool,它能直接進到你的專案讀檔、改檔、跑測試、整理 PR,而不只是回答你貼上去的程式碼…

Claude Code 是 Anthropic 官方推出的 agentic coding tool,它能直接進到你的專案讀檔、改檔、跑測試、整理 PR,而不只是回答你貼上去的程式碼片段。個人月費約 US$20 起,可用 Pro 訂閱方案額度,也能走 Console API 按 token 計費 [來源:官方產品頁 https://claude.com/product/claude-code]。它跟一般聊天 AI 最大的差別,在於它會真的動手碰你的檔案。真正的門檻其實不在安裝,關鍵在於你能不能用 Git、diff、測試、權限這套工程方法駕馭它。

重點先看:Claude Code 的價值在於你能不能決定什麼時候讓它改、什麼時候只讓它讀,「AI 幫你寫完程式」只是表象;Pro 月費約 US$20 起 [來源:官方產品頁 https://claude.com/product/claude-code],但設了 API key 可能悄悄切換成按 token 計費。

Claude Code 的定位:會動手的代理式工具

Claude Code 是 Anthropic 官方的 agentic coding tool,跟 Claude 聊天助理 最大的差別是:它能真的進到你的專案裡讀檔、改檔、跑測試、用 Git,而不是只回答你貼上去的程式碼片段。所謂 agentic,指的是它能使用工具(讀檔、執行 command、改檔)完成多步驟的開發任務,不只產生一段文字。

根據官方說明,Claude Code 可以整合在 terminal、IDE、桌面應用程式、Web、Slack 等環境使用 [來源:官方 Overview https://code.claude.com/docs/en/overview]。這代表它是一個能掛在你開發流程裡、實際碰檔案的助理,而不是一個只能聊天的視窗。對 AI Agent 運作原理 有基本概念,會比較好理解為什麼它需要權限與邊界。

打個比方,聊天 AI 像你問問題的助教,Claude Code 像會自己開檔案改東西的工讀生。助教只給答案,工讀生會真的動手,也因為這個差別,它才需要 Git 與權限這套保險機制。想把 AI 帶進開發流程的工程師、技術 PM,或是正在評估 Vibe Coding 該怎麼落地的人,是它最對口的受眾。

Claude Code 最實用的姿態是協助你理解陌生專案、修 Bug、補測試、整理 PR,「替你寫完一整個功能」反而要放最後再說,因為它「偷偷改壞東西」的風險一直都在。連 命令列 CLI 與基本的 Git 都還沒摸過的人,建議先把這兩項補起來,再回頭用它。

Claude Code 怎麼安裝與啟動

macOS、Linux、WSL 用一條 curl 指令,Windows PowerShell 用 irm 指令,裝完在專案資料夾輸入 claude 啟動並登入帳號。新手建議先從 terminal 或 IDE 開始,因為最容易看清楚它到底改了哪些檔案。安裝方式會隨版本更新調整,以下指令屬於高更新風險內容,實際請以官方 Quickstart 為準 [來源:官方 Quickstart https://code.claude.com/docs/en/quickstart]。

  • macOS / Linux / WSL:curl -fsSL https://claude.ai/install.sh | bash
  • Windows PowerShell:irm https://claude.ai/install.ps1 | iex
  • 啟動:進入專案資料夾後輸入 claude,第一次要登入 Claude 帳號
  • 可用帳號:Pro、Max、Team、Enterprise,或 Anthropic Console

對完全沒接觸過終端機的人來說,啟動前有一個容易踩的坑。如果你的環境變數設定了 ANTHROPIC_API_KEY,Claude Code 可能會改走 API 計費,直接跳過你的訂閱方案額度 [來源:官方 support article https://support.anthropic.com/en/articles/11145838]。這在你想用 Pro 月費卻收到一張 token 帳單時特別痛。第一次啟動時,務必先確認現在是訂閱額度還是 API 計費,再開始丟任務。需要一份從安裝到實作的完整路徑,把上面「安裝與啟動」一節接著後面的「第一次上手:5 步安全流程」順著讀一遍,基礎流程就串得起來。

啟動之後,你會發現它跟你熟悉的 AI 提示詞 prompt 互動不太一樣。它會主動列出要讀哪些檔、要跑什麼指令,然後等你確認。這個「先問再做」的節奏,就是 agentic 與聊天最大的分野。之前只玩過 ChatGPTGemini 的人,需要花點時間適應這種工作模式。

看懂 Claude Code 之前,得先把它放回 Anthropic 的產品線裡定位。同一個 Claude 模型,被裝進三種執行環境:Claude Chat 是瀏覽器裡的問答助理,要動檔案得手動上傳;Claude Cowork 在桌面 App 的虛擬沙盒裡協作,只能碰你授權的資料夾,不能跑終端機指令;Claude Code 則直接住在你電腦的終端機裡,授權後能讀寫本機檔案、執行指令、安裝套件。差別只有一行值得記住:能不能執行終端機指令、能不能操控本機檔案。只想發想點子、寫文案,留在聊天視窗就夠;要跟同事在文件上協作,Claude Cowork 比較順;只有當你想把「打開電腦、跑一套固定流程、關掉」這件事交給 AI 自己完成,Code 才真正發揮價值。

比較項目Claude ChatClaude CoworkClaude Code
運作環境瀏覽器 / App桌面 App 虛擬沙盒本機終端機
檔案權限需手動上傳僅限授權資料夾授權後可操控本機檔案
能否執行終端機指令不能不能能,含安裝套件
互動模式問答式協作式代理人模式
適合對象所有人跨工具協作者追求全自動代理者

除了寫程式,Claude Code 也適合不會寫程式的人。它的設計就是讓你用白話文下指令,非工程師最能受惠的是規則明確、重複性高的工作:批次整理檔案改名(例如把資料夾裡所有照片依拍攝日期重新命名成「年-月-日-編號」)、把多份 Excel 合併依部門分類算出加總與平均產出報表、描述功能與風格就能產出簡單網頁或小工具,以及把每天重複的電腦工作(信件分類、週報產出、客戶資料更新)寫成一鍵自動化流程。只要把需求拆成「做什麼、對哪些檔案、照什麼規則、輸出什麼結果」幾個要素講清楚即可。牽動 SEO 策略或內容行銷方向這類需要專業判斷的決策,它給的是草稿與選項,最終決定權還在你手上。

這條使用路徑與整體市場走向一致。根據 HubSpot 的《State of Marketing》報告,受訪行銷人中多數計畫在 2026 年將 AI 納入內容產製流程(含部落格文章),同時已有相當比例實際用 AI 做內容創作 [來源:〈HubSpot State of Marketing Report〉〈https://www.hubspot.com/state-of-marketing〉〈2026〉]。把像 Claude Code 這類會動手的工具用在內容與重複性工作上,已經從實驗變成主流。差別在於多數人只停在「產生文字」,而 Claude Code 多了「操作檔案、跑指令、串自動化」這一層。

訂閱額度與 API 計費的切換邏輯

Claude Code 可以吃 Claude 訂閱方案額度,也可以走 Console API 按 token 計費,差別取決於你有沒有在環境變數設 API key。設了 ANTHROPIC_API_KEY 就可能改用 API 計費,這是新手最容易被帳單嚇到的地方。同一個工具、兩種計費邏輯,你不主動確認,就不知道現在燒的是哪一邊。

依照官方產品頁,個人常見方案大致如下,價格、模型與用量限制都屬高更新風險,實際費用以官方頁面與你帳號顯示為準 [來源:官方產品頁 https://claude.com/product/claude-code]:

方案月費適合誰計費來源
ProUS$20 起短時間 coding sprint、小型 codebase訂閱額度
Max 5x約 US$100每天使用、中型專案訂閱額度
Max 20x約 US$200高頻率、重度使用者訂閱額度
Team / Enterprise另計公司團隊,需管理與權限訂閱額度
Console API按 token 用量有 API key、用量浮動API 計費

訂閱 vs API 的選擇,其實取決於你的用量形狀。穩定每天寫 code、專案規模可控,訂閱方案划算;用量忽大忽小、或要接進自動化流程,API 反而彈性。但不論選哪邊,使用前先確認計費來源,是省錢的第一步。Max 5x、Max 20x 的倍率命名與實際用量上限屬於高更新風險資訊,會隨官方調整變動,不宜寫死成固定數字。設了 ANTHROPIC_API_KEY 後,即使付了 Pro 月費,Claude Code 還是可能改走 Console API 按 token 算錢 [來源:官方 support article https://support.anthropic.com/en/articles/11145838]。對 AI Token 計費單位 沒概念的人,建議先讀一下 token 怎麼算。訂閱與 API 之間那條界線,決定權在你的環境變數,跟方案等級幾乎無關;很多人以為付了月費就一定吃訂閱額度,這個假設在設了 key 的瞬間就失效了。

給一個具體的判斷門檻,比反覆糾結方案更實用。把「每日平均使用小時 × 一個月工作天」當成粗估基準:每天使用不到兩小時、週末不開機的人,Pro 月費綽綽有餘,硬升 Max 只是讓額度閒置;每天四到六小時、且常在大型 codebase 上跑測試的人,通常會在月中就撞到 Pro 上限,這時升到 Max 5x 反而比動不動卡住划算;至於把 Claude Code 接進 CI 或夜間批次自動化、用量完全不可預測的情境,直接走 API 並在 Console 設 monthly spend limit,比任何訂閱方案都更能控制風險。真正的成本殺手往往出在「以為在吃訂閱額度、其實在燒 API」這個靜默切換,模型選錯反而是次要,所以養成習慣,每週花十秒看一次目前是訂閱還是 API 計費,是性價比最高的防護。

第一次上手:5 步安全流程

選一個已經放進 Git、可回復的小專案,先確認 git status 乾淨、開新分支,再請 Claude Code 先讀專案不要改檔,接著用 /init 建 CLAUDE.md,最後從一個小任務開始。核心原則是先要計畫、再允許改檔。這個順序聽起來囉嗦,但它能幫你把「AI 改壞」的風險壓到最低。

  1. 確認 Git 狀態:先跑 git status,未提交的修改先 commit 或 stash,確保工作區乾淨。
  2. 開新分支:git checkout -b test-claude-code,確保改錯能 rollback。
  3. 先讀不改:明確告訴它「請閱讀專案,整理主要資料夾用途、啟動方式、測試方式,先不要修改任何檔案」。
  4. /init 建檔:用 /init 建立 CLAUDE.md,記錄 build、測試指令與開發慣例 [來源:官方 memory 文件 https://code.claude.com/docs/en/memory]。
  5. 小任務開始:從修一個 Bug 或補一個測試切入,要求它先說會改哪些檔再動手。

這五步裡,第三步「先讀不改」最容易被新手跳過。你會想,既然工具會動手,幹嘛不直接讓它改?原因是你得先確認它真的理解專案。如果它連資料流都講錯,你還放它改檔,那就是把方向盤交給一個看錯地圖的駕駛。先讀、先提計畫,再決定要不要授權,這是工程方法,不是膽小。

第四步的 CLAUDE.md 是 Claude Code 的專案記憶檔,可以放 build 指令、測試方式、開發慣例與注意事項 [來源:官方 memory 文件 https://code.claude.com/docs/en/memory]。它跟 MCP 模型上下文協定 解決的問題方向類似,都是幫 AI 取得專案脈絡,只是 CLAUDE.md 偏向你手寫的慣例。寫的時候把握一個原則:具體、可執行,不要寫一堆形容詞。

Ask、Edit、Plan 三種模式怎麼挑

跑任務時,Claude Code 讓你在三種模式間切換(部分環境可用 Shift + Tab 快速切換):Ask 是每步操作前先告知、等你確認;Edit 是自動連續執行所有步驟;Plan 是先討論並產出計畫書列步驟,確認後再執行。風險低的任務用 Edit,複雜或高風險任務用 Plan 先確認。新手不確定就用 Ask,它最安全,頂多慢一點。

模式行為適合場景
Ask(預設)每次操作前先告知,等你確認新手、陌生專案、高風險任務
Edit自動連續執行所有步驟重複低風險任務,建議先 Ask 測一次再切
Plan先出計畫書列步驟,確認後再執行複雜專案、跨檔案操作

實務上的搭配是這樣:第一次跑某個任務一定用 Ask,看它每一步想做什麼、會動到哪些檔;確認邏輯沒問題後,第二次跑同樣任務就切 Edit 讓它自動連續執行;遇到牽動多個檔案、會刪除或覆蓋的複雜任務,就用 Plan 先看計畫書。三個模式對應三種控制力度:Ask 把每一步交回你手上,Edit 把節奏交給它,Plan 則在動手前先攤開整段路徑讓你審。

CLAUDE.md 怎麼寫才有效:專案記憶檔的深度寫法

CLAUDE.md 是 Claude Code 在專案根目錄讀取的記憶檔,它決定了 AI 對你的 codebase 第一印象。把它當裝飾、隨便寫兩行專案簡介就交差,結果是 AI 每次都要重新摸索 build 指令、測試跑法、目錄結構,浪費的不只是 token,還有你來回修正的時間。一份好的 CLAUDE.md 能讓它更快進入狀況、更少做假設、更不容易改錯地方。

它支援放在三個層級:根目錄的 CLAUDE.md 給整個專案用;子目錄裡的 CLAUDE.md 只在處理該資料夾時生效;使用者家目錄的 ~/.claude/CLAUDE.md 則是你跨專案的個人慣例。三層疊起來,等同於一份會被自動載入的、活的開發手冊。寫的時候要想清楚哪一層該放什麼:跨專案都通用的個人習慣(例如 commit message 格式)放家目錄;專案特有的 build 與測試指令放根目錄;某個子系統的特殊規矩放對應子目錄。

該寫進去的五類資訊

判斷一條資訊該不該進 CLAUDE.md,可以從兩個軸看:它是「AI 沒有就會做錯假設」的執行細節,還是只是背景知識。前者必寫,後者可省。下表把五類常見內容對照寫法要點。

資訊類型為什麼要寫寫法要點
環境與啟動AI 不會猜到你要的 Node/Python 版本與環境變數寫具體指令,不要寫「請參考 README」
build 與測試跑錯指令會得到誤導性的失敗結論精確指令如 npm run test:unit,並標明快測與慢測
目錄與架構避免它把過時資料夾當現況標明入口與地雷,例如「新功能加到 src/v2」
開發慣例命名與風格不一致會產出需大量修正的程式碼寫成可執行規則,如 camelCase、測試放 __tests__
地雷與禁忌某些指令會破壞鎖定版本或資料明確列出不能跑的指令,如「勿跑 npm audit fix」

判斷該不該寫進 CLAUDE.md 的準則很簡單:這條資訊 AI 沒有它就會做錯假設嗎?會,就寫;只是背景知識,就不必。它不是文件大全,是給 AI 看的工作守則。寫得太長反而會佔掉 context window,稀釋掉真正重要的指令。實務上抓在 50 到 150 行之間最平衡,把最常踩的雷放在最前面。

常見的寫法錯誤

最常見的錯誤是把 CLAUDE.md 當成權限規則來寫,例如寫「禁止讀取 .env 檔」。前面提過,它沒有任何強制力,AI 可以無視。真正要擋,得靠 permission 與 settings。第二個錯誤是寫一堆形容詞卻沒有可執行的指令,例如「我們重視程式碼品質」這種話對 AI 沒有任何指引作用,要寫就寫成「所有 PR 必須通過 npm run lint 與 npm run test,未通過不得合併」。第三個錯誤是寫了就忘記更新,當 build 指令換了、目錄重構了,CLAUDE.md 還停在半年前的版本,AI 就會照著過時資訊做出錯誤假設。養成習慣,每次動到專案結構就同步更新這份檔案。

進階能力:subagents、hooks、MCP 與 slash commands

跑順基本流程之後,Claude Code 還有四個進階能力可以大幅提升產能與安全性。這些功能預設不一定開啟,需要你主動設定,但設定好之後,它會從「會改檔的助理」升級成「會自己分工、自動把關的開發夥伴」。熟悉 AI Agent 運作原理 的人會比較快上手這一層,因為背後都是工具使用與多步驟規劃的概念。

subagents:把大任務拆成專精角色

subagents 讓你定義具備專屬 system prompt、專屬工具權限、獨立 context 的子代理。例如你可以設定一個「code reviewer」subagent 只負責讀 diff 並挑出問題,一個「test writer」只負責補測試,一個「docs updater」只負責同步文件。主代理把任務分派下去,各自在自己的 context 裡執行,再把結果回報。這種做法的好處有兩個:一是每個 subagent 的 context 乾淨,不會被主對話的雜訊污染,產出品質更穩;二是權限可以收得很緊,例如 reviewer 只給讀取權限、不給寫檔,從結構上就擋掉越權修改。

判斷什麼任務適合拆成 subagent 的準則是:這個任務有沒有明確的輸入、輸出與獨立判斷空間?有,就適合拆。例如「審查這個 diff 有沒有安全問題」輸入是 diff、輸出是問題清單、判斷空間獨立,很適合。反過來「幫我寫完這個功能」牽動太多上下文,硬拆反而會失真。

hooks:在固定時機自動執行檢查

hooks 是 Claude Code 在特定事件發生時自動觸發的腳本,例如每次它準備執行 Bash 指令前、每次它改完檔案後、每次對話結束時。最實用的兩種是 PreToolUse 與 PostToolUse。PreToolUse 可以攔截指令,例如擋掉任何 rm -rf 開頭的命令、擋掉對特定資料夾的寫入;PostToolUse 可以在改檔後自動跑 lint 或格式化,確保產出符合規範。把團隊共用的規範寫成 hooks,比寫在 CLAUDE.md 裡有效得多,因為 hooks 是真的會執行、會擋下來,AI 無法無視。

MCP:把外部資料與工具接進來

MCP(Model Context Protocol)是讓 Claude Code 連接外部資料來源與工具的標準協定,概念上接近 MCP 模型上下文協定 介紹的通用框架。接上之後,它可以讀你的資料庫、查你的 issue tracker、操作你的 CMS。對內容團隊來說,把 MCP 接到 WordPress 可以讓它直接讀寫文章草稿、分類、標籤,Claude Code 搭配 WordPress 的設定範例就是這類應用的起點。接 MCP 時要特別注意權限範圍,只給它需要的那個 endpoint,不要一次開整個系統的寫入權限。

slash commands:把重複流程變成一鍵指令

slash commands 讓你把常用的工作流程封裝成一個指令,例如 /review-pr、/fix-tests、/update-deps。輸入之後,它會自動展開成一段預先寫好的 prompt,包含步驟、注意事項、輸出格式。好處是團隊每個人跑同一個流程都拿到一致的結果,不會因為當下手寫的 prompt 不同而產出參差。把公司內部的 code review checklist、deploy 流程、on-call 排查步驟都封裝成 slash commands,是讓 Claude Code 真正融入團隊工作流的關鍵一步。

成本控制:context window 與 token 用量的管理

不論你走訂閱還是 API,token 用量都直接影響成本與速度。Claude Code 每次對話都會把目前 context window 裡的內容(你的指令、它讀過的檔案、之前的回覆)一起送給模型,context 累積越多,每次回應越慢、越貴。對 AI Token 計費單位 有基本概念,是控制成本的第一步。

  • 用 /clear 重置 context:切換到全新任務時,先把舊對話清掉,避免不相關的歷史佔著額度。
  • 精準指名要讀的檔案:直接指名「讀 src/auth/login.ts 與它的測試」,縮小範圍就縮小 token,避免讓它掃整個專案。
  • 大檔案分段處理:遇到幾千行的檔案,先請它讀特定區段或函式,不要一次餵整份。
  • API 用戶設用量上限:在 Console 設定 monthly spend limit,超出就停止,防止跑出意外的天價帳單。
  • 追蹤每次任務的花費:養成習慣看每個任務用了多少 token,找出哪些工作流程最燒錢,再想辦法優化。

訂閱方案用戶面對的是另一種成本:額度耗盡。當你在 sprint 期間密集使用,可能會在月中就撞到方案上限,這時 Claude Code 會降速或暫停,工作被迫中斷。判斷自己該不該升級方案的方法是連續觀察兩週的用量:如果你幾乎每天都撞上限,升到高一級的方案會比動不動就卡住更划算;如果只是偶爾爆量,維持原方案、把密集任務分散到不同時段即可。對用量忽大忽小的人,API 的彈性反而比訂閱適合,因為你只為實際用到的部分付費。

以這類中型專案的典型用量為例,可以把成本行為抓出一個大概的輪廓,避免月底才被帳單嚇到。依這類站或情境的常見表現幅度,一個每天使用約 2 到 4 小時、codebase 規模中等的開發者,單日 token 消耗大約落在幾百萬到一千多萬之間,落在這個區間時 Pro 訂閱額度通常會在工作天接近尾聲被吃滿,而不是整天順順地用。常見的狀況是,月初前幾天額度看起來很寬鬆,到了月中密集跑大型重構或多檔案改動時突然降速,這正是 context 累積與大檔案讀取疊加起來的典型瓶頸。若把 Claude Code 接進 CI 或夜間批次,API 模式下單月花費依任務密度大約落在 US$30 到 US$150 之間,浮動幅度比訂閱大得多,好處是沒用就不付錢,風險則是沒設 monthly spend limit 時很容易失控。

這裡有一個常被低估的失敗點要誠實點出:很多人把成本控制的重心放在「選哪個方案」,卻忽略 context window 的累積才是真正的隱性開銷。依典型表現幅度,同一個任務在累積了完整對話歷史後,每次回應的 token 用量大約是任務剛開始時的 2 到 4 倍,這代表你拖著一條越來越長的對話不放,等於每講一句話都在為整段歷史重新付費。決策角度因此很清楚:與其糾結升級方案,不如養成切換任務就 /clear、指名讀特定檔案、把大檔案分段處理的紀律。這幾個動作的降本效果,依這類使用模式的常見幅度,往往比從 Pro 升到 Max 5x 更有感。當然這些只是典型情境的粗略輪廓,每個專案的程式碼規模、任務型態與使用頻率都不同,實際數字仍以你自己帳號顯示的用量為準,不宜照單全收。

最適合交給 Claude Code 的工作類型

Claude Code 最實用的情境涵蓋理解陌生專案、修 Bug、補單元測試、小型重構、更新 README、解釋看不懂的程式、修 CI 或測試錯誤、整理 PR 描述。共同點是都從「先讀、先提計畫」開始,把動手修改留到你確認計畫之後。

其中性價比最高的是修 Bug 跟補測試。修 Bug 時,先要求「不要動檔,給 3 個可能方向」再讓它動手,這個順序逼它把推理過程攤開,避免它塞一個看起來合理卻走錯方向的 patch。AI 給出一個 patch 的成本很低,但一個錯誤方向被接受後,後續 debug 的成本會很高;要求它先講方向、再講原因、最後才動手,等於把推理鏈強制可見化,你才能在中間攔截錯誤。補測試則要小心 happy path 偏誤:AI 寫出來的測試常只測順利情境,錯誤輸入與邊界條件要你自己點名,它才會補。

整理 PR 與修 CI 這類情境,共同特徵是你已經有具體素材(diff 或 log)可以餵給它,這時候它的價值在於把你不想手寫的摘要、風險說明整理出來。但摘要可以交給 AI,內容判斷不能,Perplexity 這類工具強調要附來源,道理類似:有出處才好驗證。把它想成 RAG 檢索增強生成 的工程版,先抓對脈絡,再產出。

權限與安全:permission、sandbox 與 bypass 的界線

Claude Code 在改檔或執行指令前會詢問權限,你可以用 permission rules 限制它能讀寫哪些檔案、用 sandbox 限制 Bash 能碰到的資源。新手絕對不要在正式專案用 bypass permissions 跳過確認,那等於把操作權全交給 AI。安全不是裝飾品,當工具能改檔、能跑指令,邊界就必須是硬規則。

機制控制什麼官方出處
Permission允許它做哪些事(讀寫哪些檔、跑哪些指令) settings
Sandbox限制 Bash 能碰到的檔案與網路資源 sandboxing
Bypass permissions跳過所有確認(僅限乾淨測試環境)風險極高,正式專案嚴禁

Permission 是第一道門,控制 Claude Code 能做哪些事。例如你可以允許它讀取專案檔案,但不讓它碰敏感資料夾;允許它跑測試,但不讓它任意執行部署指令 [來源:官方 settings 文件 https://code.claude.com/docs/en/settings]。Sandbox 是第二道門,限制 Bash command 能碰到的檔案與網路資源 [來源:官方 sandboxing 文件 https://code.claude.com/docs/en/sandboxing]。兩者疊起來,才構成比較完整的操作圍欄。

有一點容易被忽略:Windows 原生環境不支援同樣的 sandbox,使用者通常要透過 WSL2 才能用上相關能力 [來源:官方 sandboxing 文件 https://code.claude.com/docs/en/sandboxing]。在 Windows 上直接跑,等於少了第二道門。至於 bypass permissions,唯一合理的情境是乾淨的、可丟棄的測試專案;正式專案跳過確認,等於把房子鑰匙交給一個你還不確定會不會亂翻抽屜的人。

另一個常被誤解的地方:CLAUDE.md 不是安全門禁。它像專案說明與協作規範,是給 AI 看的慣例提示,沒有任何強制力,AI 可以無視你寫在裡面的任何「禁止」。真正要擋住它讀某個資料夾、跑某個指令,得靠 permission、settings、sandbox 或公司管理設定。講到機密,這跟 品牌成為 AI 推薦答案 的邏輯相通:你愈能控制 AI 接觸到什麼,就愈能掌握風險。不要把 API key、資料庫密碼、客戶個資、公司機密直接貼進 prompt,也不要讓 Claude Code 任意讀取敏感資料夾。

Claude Code vs Cursor vs GitHub Copilot 怎麼選

Claude Code 偏 agentic coding,適合熟悉 Git 與 terminal、想讓 AI 直接處理整個專案任務的人;Cursor IDE 體驗好,適合邊寫邊問;GitHub Copilot 跟 GitHub 生態整合深,適合補全與 PR workflow。喜歡 terminal 與測試流程選 Claude Code,完全不熟命令列先從 Cursor 類工具入手。

工具定位較適合誰核心強項
Claude CodeAgentic,可讀 codebase、跨檔改、跑指令熟悉 Git 與 terminal 的工程師多步驟任務、整個專案層級的處理
CursorIDE 體驗好,邊寫邊問邊改想在編輯器裡自然使用 AI 的人即時互動、視覺化 diff
GitHub CopilotGitHub 生態整合深重度用 VS Code、PR workflow 的團隊補全、聊天、PR 任務
OpenAI Codex雲端 coding agent已在 OpenAI 生態的人任務交給雲端再回來檢查

挑選時與其糾結「哪個最強」,更實用的問題是:現在的工作流是 terminal 主導,還是 IDE 主導?習慣在終端機裡跑測試、看 diff、切分支的人,Claude Code 會很順手;大部分時間待在編輯器裡寫程式的人,Cursor 類工具的上手成本更低。可以對照 OpenAI Codex 程式助理Google AI Mode 的思路,把工具放進實際流程看。

工具會換,判斷力不會。今天的 Claude Code、明天的某個新工具,底層都需要你會 Git、會看 diff、會跑測試。這三項基本功才是安全使用 AI coding tool 的地基。

不該交給 Claude Code 的情境

多數文章只講什麼時候該用,卻很少講什麼時候該收手。把 Claude Code 用在錯的地方,輕則浪費時間,重則把好好的專案改壞。下列幾種情境,建議改用其他工具或乾脆自己動手。

  • 沒有版本控制的專案:連 Git 都沒有的資料夾,等於沒有安全網。先 git init、先 commit 一次乾淨狀態,再考慮讓 AI 進來。
  • 涉及核心商業邏輯的關鍵修改:計費、權限、加密這類改錯代價極大的程式碼,建議由人類主導,AI 最多只做草稿或審查,不放手讓它直接改。
  • 需要高度確定性的生產部署:deploy 到正式環境的動作,永遠由人類按下最後一步,不要讓 AI 自動連續執行到上線。
  • 需要深度領域知識的判斷:牽涉稅務、法規、醫療、金融合規的邏輯,AI 的通用知識不足以取代專家判斷,產出只能當參考。
  • 專案結構你完全不熟悉:連自己都看不懂的 codebase,你無法判斷 AI 改得對不對。這時該先花時間自己理解,把理解的工作留在自己手上。

決策矩陣:該不該交給它,四個象限一次看

判斷一個任務適不適合交給 Claude Code,可以用兩個維度來分:修改風險(低或高)與規則明確度(明確或模糊)。這會切出四個象限,每個象限對應不同的授權程度。

規則明確規則模糊
風險低放心交給它,可用 Edit 模式自動跑(例如補測試、改文案、格式化)先讓它出草稿,你來挑選與收斂(例如發想命名、列重構方案)
風險高用 Plan 模式先看計畫,逐步確認再執行(例如改 API 結構、調資料 schema)避免交給它,由人類主導,AI 只做查資料或解釋(例如核心計費邏輯、合規判斷)

這個矩陣的核心訊息是:風險越高、規則越模糊的任務,你該保留越多控制權。落在右下象限的工作,自己做或找專家更穩當,把 AI 留給它真正擅長的左上與右上象限。

疑難排解:常見問題與排除步驟

實際使用時會遇到幾類反覆出現的問題,把排除步驟記下來,能省下大量摸索時間。底下整理最常見的五種狀況與對應的處理方式。

  • 它一直改錯地方:先檢查 CLAUDE.md 有沒有講清楚目錄結構與禁忌,再確認你給的任務描述夠不夠具體。把「幫我修這個 Bug」改成「修 src/auth/login.ts 第 42 行的 null check 問題」,產出會精準很多。
  • 它跑出過時的指令或 API:模型知識有截止日期,新建的函式庫或近期改版的 API 它可能不知道。把官方文件貼給它當參考,或要求它先查最新文件再動手。
  • context 太長導致回應變慢或出錯:用 /clear 重置,把任務拆小,指名要讀的特定檔案,避免讓它掃整個專案。
  • 測試一直失敗但它說改好了:要求它在回報完成前先實際跑一次測試,並把測試輸出貼給你看。把「跑測試」寫進 hooks 強制執行,效果更好。
  • 它產生的程式碼風格跟專案不一致:把風格規範寫進 CLAUDE.md,並設定 PostToolUse hook 在改檔後自動跑 prettier 或 eslint --fix。

處理這些問題時有一個共通原則:把你的期待從模糊變具體。多數「AI 做不好」的情況,根源是輸入不夠清楚。把任務描述、檔案範圍、驗收標準都講明白,產出的穩定度會明顯上升。這跟寫好 AI 提示詞 prompt 是同一件事:清楚的需求永遠是最好的成本控制。

團隊導入:企業與多人協作的設定要點

一個人用 Claude Code 與一個團隊用,是兩回事。多人協作時,最重要的是把個人習慣升級成團隊規範,讓每個人跑出來的結果趨於一致,並集中管控風險。Team 與 Enterprise 方案提供了組織層級的管理能力,包含集中計費、成員權限、共用設定與審計紀錄 [來源:官方產品頁 https://claude.com/product/claude-code]。

  • 共用 CLAUDE.md:把團隊一致的 build 指令、測試跑法、命名規範、禁忌清單寫進版控裡的 CLAUDE.md,每個人 pull 下來就自動套用,不用各自維護。
  • 集中 permission 與 settings:用企業管理設定統一規範能讀寫哪些路徑、能跑哪些指令,避免有人為了方便開了過大權限。
  • 把規範寫成 hooks 與 slash commands:code review checklist、deploy 前置檢查都封裝成可重複執行的指令,落實流程一致性。
  • 機密與合規審查:涉及客戶個資或商業機密的專案,先確認公司資安規範允不允許 AI 接觸這些程式碼,不允許就只在可丟棄的測試環境使用。
  • 審計與可追溯:要求所有 AI 產生的修改都走 PR 流程、留下 diff 與審查紀錄,方便事後追溯誰授權了什麼改動。

企業導入時還要面對一個文化問題:工程師會不會把 AI 產出的程式碼直接合併,跳過審查。這在 E-E-A-T 精神與 E-E-A-T 談的「信任來自可追溯」是同一個道理:過程可被檢視,結果才值得信任。制訂明確的 AI 程式碼審查規範,例如「所有 AI 修改必須附上原始 prompt 與 diff,並由至少一位人類審查」,是把工具引進團隊時不可省的一步。

新手最常踩的坑

新手最大地雷是沒開 Git 分支就讓它改檔、一次丟大型需求、不看 diff 就接受結果、沒跑測試、把機密貼給 AI,以及沒搞清楚是訂閱額度還是 API 計費。記住一條鐵律:先開分支、先看計畫、看完 diff、跑過測試,再說完成。AI 寫的程式看起來合理,不等於它能跑。

這幾個坑裡,最常翻車的是「不看 diff」。Claude Code 回你一句「已完成」,語氣篤定到讓人以為真的沒問題,結果 git diff 一看,它順手改了一個根本沒被要求的地方。常見的幅度是:一次中型任務裡,diff 出現一兩處與主訴求無關的改動,比例不高但足以埋下後續 bug。只要它動過檔案,先看 diff 再說好,這個動作省下的是事後 debug 的好幾個小時。

把這幾條濃縮成一份開工前掃一遍的清單:確認 git status 乾淨、開新分支、先讀不改、要計畫再授權、一次只做一個小任務、重要修改看 diff、能跑測試就跑、不貼機密、正式專案不用 bypass、確認計費來源、AI 的 PR 仍要人類 review。它能在手忙腳亂時擋下最貴的錯誤。如果你正在評估 代理式搜尋AXO 全搜尋體驗優化 這類趨勢,會發現它們指向同一件事:AI 愈能動手,人愈要把關。

結語:用工程方法駕馭,避免迷信產能

Claude Code 是目前很值得工程師學習的 AI coding tool,它能進到專案讀檔、改檔、跑指令、整理任務,讓 AI 更接近真實的開發工作流程。但越是強大的工具,越需要使用邊界。新手別追求一次完成巨大任務,而是學會切小任務、先看計畫、檢查 diff、跑測試、保護機密。先建立工作流,再談產能。

剛開始學的人,建議從三件事切入:請它解釋專案、幫你修一個小 Bug、補一個測試。熟悉之後再慢慢嘗試重構、PR、CI 修復與更進階的自動化。它跟 Claude DesignAgentic Browsing 一樣,都是同一波 AI 落地的不同切面,把握工程紀律,工具換了你也跟得上。

Claude Code 可以讓你寫程式更快,但真正決定產出的,是你能不能判斷它寫得對不對。工具會換,這個判斷能力不會過期。相關的延伸閱讀,可以順著 內部連結架構搜尋意圖結構化資料 這幾個方向繼續挖。

Claude Code 常見問題

Claude Code 是什麼?跟一般 AI 聊天有什麼不一樣?

Anthropic 出品的 agentic coding tool,能實際進入你的 codebase 動手,不像聊天助理只回覆你貼上的片段。它會讀檔、改檔、跑指令、操作 Git,是會做事的那一種。

Claude Code 怎麼計費?Pro 訂閱會被算成 API 費用嗎?

看你有沒有設 ANTHROPIC_API_KEY。沒設就走 Pro、Max 的訂閱額度;設了就可能被導去 Console API 按 token 收費,即使你已付月費也一樣。開工前先確認現在吃的是哪一邊。

Claude Code 的 permission 跟 sandbox 是什麼?

Permission 管它「能做什麼」(讀寫哪些檔、執行哪些指令),sandbox 管它「能碰什麼」(檔案與網路資源範圍)。正式專案別開 bypass;Windows 要靠 WSL2 才有完整 sandbox。

Claude Code 會不會把我機密資料外洩?

有風險,要自己設防。API key、密碼、個資、商業機密都別丟進 prompt,敏感目錄也要擋住它讀取。真正的存取控制來自 permission、settings 與 sandbox,CLAUDE.md 擋不住任何事。

相關文章