三個月前，我抱著「又一個 AI 工具試試看」的心態打開 Claude Code CLI。三個月後，它已經成為我每天工作流程的核心。不是因為它完美，而是因為它改變了我思考「人機協作」的方式。

這篇文章不是功能介紹，是我真實踩過的坑和摸索出的工作節奏。如果你在考慮要不要花時間深入學 Claude Code，希望這些心得能讓你少走一些彎路。

它不是更聰明的 Copilot

第一個要搞清楚的事：Claude Code 和 GitHub Copilot、Cursor 不是同一種東西。

Copilot 是補全工具，你寫，它預測下一行。Cursor 是 AI 增強版 IDE，聰明的自動補全加上 Chat 視窗。這兩者的核心假設是「你在主導，AI 在輔助」。

Claude Code 的核心假設是不同的：你在導演，AI 在執行。

你給它一個目標，它會讀懂整個 repo、寫計畫、執行程式碼、跑測試、修錯誤，然後回報結果。你的角色從「打字員」變成「技術主管」。

這聽起來很美好，但這也是很多人一開始用不對的原因——他們把 Claude Code 當成更貴的 Copilot 在用，然後覺得「也還好嘛」。

為什麼選 CLI 而不是 IDE 整合？

Cursor 有 Claude 整合，VS Code 也有 GitHub Copilot。為什麼要跑去用 CLI？

老實說，我一開始也覺得很反直覺。但用了一段時間後，我理解了 CLI 的核心優勢：它可以在任何地方跑，不依賴 UI。

我現在的工作方式是：在遠端伺服器上跑 Claude Code，透過 SSH 操作。這讓我可以在任意機器、任意環境下發派任務，關掉 terminal 它還在跑。Cursor 做不到這件事。

另外，CLI 的腳本化能力也是 IDE 整合版本沒有的。你可以把 Claude Code 嵌進 cron job、CI/CD pipeline、Slack Bot 的觸發流程裡。這是一種完全不同的擴展維度。

CLAUDE.md：你和 AI 之間的說明書

開始一個新專案，第一件事我現在一定會做的就是寫 CLAUDE.md。

這個檔案放在專案根目錄，Claude Code 每次啟動 session 都會讀它。你可以在裡面寫：

  • 這個專案是做什麼的
  • 技術棧和版本限制
  • 命名規範和程式碼風格
  • 禁止動哪些目錄（例如 PROD 環境設定絕對不能改）
  • 慣用的工作流程（例如「寫完記得跑 lint」）

我有一條規則叫做 1-Minute Rule：「任何預期超過 60 秒的操作，一律派給 Subagent 執行。」這條規則寫進 CLAUDE.md 之後，Claude Code 就會自動遵守，不用我每次提醒。

CLAUDE.md 是你和 AI 協作契約的物化形式。花一個小時把它寫好，之後每一個 session 都會更順。

Plan Mode：先想清楚再動手

這是我覺得最被低估的功能。

預設情況下，你給 Claude Code 一個任務，它會直接開始執行。但對於複雜任務，這樣很危險——它可能走錯方向，等你發現問題已經改了二十個檔案。

Plan Mode 的做法是：先讓 AI 提交一份執行計畫，等你確認之後再開始動。

實際操作是這樣：

你：幫我把這個 Python API 重構成 async，先給我計畫不要動程式碼
Claude：好的，我計畫做以下這些事：
  1. 把 sync 的 requests 改成 aiohttp
  2. 所有 def 函數加上 async/await
  3. 更新 tests
  請確認後我再執行。
你：第 3 點先不用，其他可以
Claude：了解，開始執行步驟 1 和 2...

這個流程讓我減少了很多「AI 做到一半發現走錯了」的情況。現在遇到複雜任務，我的標準開頭是：「先給我計畫，不要執行。」

Subagent：並行任務的正確姿勢

這是 Claude Code 和所有 IDE 整合版本最大的架構差異。

Claude Code 可以派生子代理（Subagent），讓多個任務同時進行。舉個例子：

你在做一個功能，需要同時：

  • 寫後端 API
  • 更新前端介面
  • 補充單元測試
  • 更新文件

在 Cursor 裡，你只能一件事一件事做。在 Claude Code 裡，你可以說「這四件事同時進行」，它會把任務分發給四個子代理並行執行。

我現在的工作節奏是：每當有一個可以拆解成獨立子任務的需求，我就會明確說「這些可以並行」。節省下來的時間相當可觀。

不過要注意：Subagent 也會消耗更多 token，而且並行任務之間如果有資源競爭（例如同時修改同一個檔案），可能會衝突。我的原則是：確定沒有依賴關係的任務才並行。

Hooks：自動化你的工作儀式

Hooks 讓你可以在 session 開始或結束時自動執行腳本。

我設定的常用 hook 範例：

Session 開始時：

  • 自動 git pull 拉最新 code
  • 檢查 lint 是否有現有問題
  • 顯示今天有哪些 open PR

Session 結束時：

  • 自動跑 git status 確認沒有意外的修改
  • 把工作日誌寫到指定目錄

這些聽起來很小，但當你每天開很多 session 的時候，這些儀式確保了你不會漏掉重要步驟。Hook 的設定檔是 settings.json，學習成本很低。

Permission Mode：給 AI 多少自主權？

這是一個需要根據情境判斷的問題。Claude Code 有三種模式：

Default（預設）：每次要對檔案做修改或執行命令，都會問你確認。最安全，但也最打斷流程。適合剛開始用、或在陌生 codebase 裡工作的時候。

acceptEdits / dontAsk（不問模式）：對常見的低風險操作（讀檔、寫程式碼）不再詢問，但對危險操作（刪檔、執行 shell 命令）還是會問。這是我大部分時間的設定。（注意：確切名稱依 CLI 版本不同可能有差異，建議用 claude --help 確認）

bypassPermissions（完全授權）：AI 可以做任何事，不問確認。我只在跑自動化腳本、或者我很確定任務範圍很小的時候用。

我的原則：新任務從 Default 開始，熟悉了降到 dontAsk，永遠不要在不熟悉的 repo 上用 bypassPermissions。

還有一個很有用的設定：在 CLAUDE.md 裡寫清楚哪些目錄是禁區。我有一個規則：PROD 環境的設定檔目錄只能讀取，不能修改。這個規則寫進去之後，就算用 bypassPermissions 也不會誤改到 PROD。

最大的坑：上下文管理

說了這麼多優點，現在說最大的問題。

Claude Code 最難的地方不是學習，是上下文管理。

每個 session 有 token 上限。當你在一個複雜的大型 repo 裡工作，Claude Code 需要讀很多檔案來理解 context，這會消耗大量 token。當 token 快用完，AI 會開始「忘事」——它可能忘記你稍早說過的限制、或者對程式碼結構的理解開始出錯。

我踩過最嚴重的坑是：一個超長的 session 裡，我在前半段說了「這個功能暫時不要改」，但到後半段 AI 忘了，在其他地方的改動中意外影響了那個功能。

避免這個問題的方法：

  1. 任務拆小：不要把一個大型重構放在一個 session 裡做完。拆成多個小任務，每個 session 有明確的開始和結束狀態。
  2. 重要限制寫在 CLAUDE.md：不要只靠對話傳遞約束，要把關鍵規則寫成永久性的 instruction。
  3. Session 開始時主動提醒：對於真的很重要的限制，每次 session 開頭我會再說一次「記住：XXX 不能動」。
  4. 善用 git：每個小里程碑 commit 一次。這樣就算 AI 做出了奇怪的事，你可以快速 rollback。

適合什麼樣的開發者？

老實說，Claude Code 不是對所有人都最佳解。

最適合的情境：

  • 你需要在多個專案間切換，每個專案的 context 很重
  • 你做的任務有很多「重複但不完全一樣」的工作（API 設計、測試補充、文件更新）
  • 你習慣思考架構，而不是逐行寫程式碼
  • 你在遠端伺服器工作，需要 CLI-first 的工具

說實話，這些情況 Cursor 更適合你：

  • 你主要工作是前端 UI，需要即時看到 UI 變化（Cursor 的 inline 預覽體驗目前還是更好）
  • 你的任務非常短小，問答式就夠了（直接用 claude.ai 就好，不值得開 CLI）
  • 你剛入門程式設計，還在建立基礎（你需要先有辨識 AI 錯誤的能力，才能真正用好它）

對我來說，Claude Code 最大的價值不是它能代替我寫程式碼，而是它讓我可以用更高的抽象層次工作。我花更少時間在「怎麼寫」，花更多時間在「要做什麼」和「為什麼這樣設計」。

這種轉變需要時間適應。前兩週你可能會覺得它很難用、很慢。但過了那個坎之後，你會很難回到純手動寫程式碼的方式。

從哪裡開始？

如果你想試試看，我建議的入門順序：

  1. 選一個你熟悉的專案：不要用 Claude Code 探索陌生 codebase，先在你了解的地方建立信任感
  2. 先寫 CLAUDE.md：花半小時把專案說明書寫好，這是值得的投資
  3. 從小任務開始：「幫我補這個函數的 unit test」比「幫我重構整個模組」更容易建立正確的使用習慣
  4. 用 Plan Mode 看 AI 怎麼想：即使你不需要它的計畫，看它的計畫過程會幫你理解它的推理方式
  5. 出問題時先看 session 長度：很多奇怪行為的根本原因是上下文太長

三個月後回頭看，Claude Code 改變的不只是我的開發效率，而是我對「軟體開發是什麼」這件事的理解。程式設計的核心技能，正在從「能不能打出正確的程式碼」轉向「能不能把問題描述清楚、把約束說明白、把結果驗證確實」。

這個轉變讓很多人不安，但我覺得這讓軟體開發變得更接近它本來應該是的樣子：思考問題本身，而不是和語法搏鬥。