Claude Code 怎麼用才對？作者 Boris Cherny 的實戰心法

🗺️ 先看整張地圖：五個階段

這場分享的講者是 Boris Cherny —— Claude Code 的作者，Anthropic 的技術成員。他開場就說這場「非常實務，不談歷史也不談理論」，然後把一件事講得很清楚：Claude Code 不是那種幫你補完一行程式的助手，它是 agentic 的，目標是整個功能、整個檔案、整隻 bug。

而正因為它什麼都能做，第一次打開只看到一個輸入框的人常常會愣住 —— 我要打什麼？整場演講其實就是在回答這件事，順序是這樣的：

🔧 開場先做的五件事

這幾件都很小，但會讓後面順很多。演講裡是當場叫聽眾打開筆電跟著做的 —— 前提只有一個：機器上有 Node.js。

• /terminal-setup —— 讓 Shift+Enter 可以換行，不用再打反斜線。
• /theme —— 亮色、暗色，或色盲友善的配色。
• /install-github-app —— 裝好之後，可以在任何 GitHub issue 或 pull request 裡 @mention Claude。
• 把常用的工具設成自動允許 —— 不然同一件事每次都要按一次同意。講者說他自己「被問到煩的那些一定會設掉」。
• 用講話代替打字（macOS）—— 系統設定 → 輔助使用 → 語音輸入打開之後，按兩下就能直接講。他說他很多提示詞根本不是打的：「你就像跟另一個工程師講話那樣跟它講就好。」

💬 第一步：先問你的專案，別急著叫它改

如果只能記一件事，講者說就是這件：從「問你的程式庫」開始，不要從改程式開始，也不要從花俏的工具開始。

這是 Anthropic 教新人的第一課。技術新人報到第一天就裝好 Claude Code，然後直接開始問專案的問題。

另外一個常被忽略的點：Claude Code 不做索引。沒有遠端資料庫存你的程式、不會上傳到任何地方、不拿你的程式訓練生成模型。對使用者來說最直接的好處是沒有等待：裝好、打開、直接問，不用先跑一輪建索引。

幾個真的會用到的問法

• 「這個東西怎麼被用的？我要怎麼建出一個？」—— 它不會只做文字搜尋，通常會再深一層去找「這個 class 實際上在哪裡被 instantiate、怎麼被用」，答案會比翻 wiki 或 Ctrl+F 深得多。
• 「為什麼這個函式有 15 個參數，而且名字取得這麼奇怪？」—— 每個專案都有這種函式。它會去翻 git history，看這些參數是誰、什麼時候、在什麼情況下加進來的，那些 commit 又連到哪些 issue，然後整理給你。
• 問 GitHub issue —— 它會去抓 issue 的內容當背景資料。
• 「我這週出了什麼？」—— 講者說這是他每個星期一開會前都在做的事：它認得他的使用者名稱，翻一下 log，就給他一份可以直接貼進文件的清單。

為什麼要從問答開始？因為這一步在教人「怎麼開口」。你會慢慢摸出那條界線：什麼事一句話就能成、什麼事要分兩三次講、什麼事得你在旁邊帶著它做。帶團隊上手 Claude Code 的時候，這一步比什麼都重要。

✍️ 第二步：讓它改程式 —— 動手前先讓它想

問答問得順了，就可以讓它改東西。這裡有個反直覺的地方：Claude Code 的工具其實很少。改檔案、跑 bash、搜檔案，大致就這些。它厲害的地方是自己會把這幾樣串起來 —— 先探索、再想、最後才動手。你不需要指定「用這個工具、再用那個工具」，你只要說要做什麼。

解法比想像中簡單得多：叫它先想。不需要特別的模式、不需要什麼工具，就是在前面加一句話。

後面那句 commit push PR 是講者常用的固定咒語 —— 沒什麼特別的，但它讀得懂：開分支、commit、推上去、在 GitHub 上開一個 pull request。你不用跟它解釋 commit 訊息要怎麼寫，它會自己去翻 git log 抓出這個專案的格式。這件事同樣不是 system prompt 教的。

🔌 第三步：把你團隊的工具接上去

講者說這是 Claude Code 真正開始發光的地方。工具分兩種：

• bash 工具 —— 你團隊自己寫的那些 CLI。做法很土但很有效：叫它用 --help 自己摸。如果某支你常用，就寫進 CLAUDE.md，讓它跨 session 都記得。
• MCP 工具 —— 加進來，告訴它怎麼用，它就會開始用。

他強調這件事的價值：接一個新專案的時候，你可以把這個專案原本就在用的那一整套工具全部交給它，然後它就能代替你操作。這是 Anthropic 內部的常見做法，外部客戶也是這樣用。

🔁 關鍵心法：給它一個能自己驗收的方法

這是整場分享裡最值得抄走的一段。當 Claude Code 有辦法自己檢查成果的時候 —— 寫單元測試、用 Puppeteer 截圖、截 iOS 模擬器的畫面 —— 它就會自己迭代。

演講裡的例子是：給它一張設計稿叫它做網頁，一次做完會「相當接近」，但讓它自己迭代兩三輪，常常就「幾乎完美」了。所以訣竅是把回饋的管道給它，剩下的它自己來。

🧠 第四步：餵 context —— CLAUDE.md 與設定階層

工具接完之後，再往上就是 context。道理很直白：你在一個專案裡待久了，腦袋裡裝著一堆歷史與脈絡；你給它多少，它的判斷就有多準。

最簡單的做法就是 CLAUDE.md。放在專案根目錄（也就是你啟動它的那個目錄），每個 session 開頭會自動讀進 context —— 實際上就是接在第一輪對話裡。

裡面該放什麼

• 常用的 bash 指令、常用的 MCP 工具
• 架構決策
• 重要的檔案在哪
• 簡單說：任何一個新人要在這個專案裡動手前，得先知道的事

除了專案根目錄那一份，還有幾個層次，而且不只 CLAUDE.md，slash 指令、權限、MCP 設定都吃同一套階層：

另外還有一份本機版的 CLAUDE.md 不要進版控 —— 那是你自己的。進版控的那一份是寫給全隊的，寫一次大家都受用。

不只 CLAUDE.md

• slash 指令放在 .claude/commands，可以放在家目錄，也可以進版控跟著專案走。Claude Code 自己的 repo 就有一支「幫 GitHub issue 貼標籤」的 slash 指令，配一個 GitHub action 定時跑，標籤就不用人去貼了。
• 權限可以整批管。全公司都會跑的那支測試指令，寫進企業政策就自動核准，不用每個人各自同意；反過來，某個網址永遠不准抓，也可以鎖成員工無法覆寫。既能解開卡住的地方，也能守住不該碰的地方。
• .mcp.json 進版控，任何人在這個專案裡開 Claude Code 都會被提示安裝那些 MCP 伺服器。Anthropic 放網頁與 App 程式的那個 repo 就是這樣共用一台 Puppeteer MCP 伺服器 —— 每個工程師都能拿它跑端對端測試、自動截圖然後迭代，不用各自裝一次。
• /memory 會列出目前到底載入了哪些記憶檔（企業政策、你的、專案的、子目錄的），也可以直接挑一個來編輯。用 # 叫它記東西的時候，也能挑要寫進哪一份。

⌨️ 快捷鍵速查

講者花了一小段專門講這個，理由很實在：終端機這種介面極度精簡，快捷鍵很難被發現。

🧩 把它當成一個很聰明的 Unix 工具

如果你用過 -p 這個參數，那你已經在用 SDK 了 —— 講者說那就是同一個東西，Claude Code 自己也是跑在上面。給它提示詞，它回你資料（可以要 JSON，也可以要串流的 JSON），前後都能接管線。

🚀 再往上：同時開好幾個，以及現場問答

最進階的用法其實不複雜，就是同時跑很多個。講者說他自己是「Claude 普通人」，一次開一個，最多幾個終端機分頁對著幾個專案。但他觀察到的重度使用者 —— 不管在不在 Anthropic —— 幾乎都是這樣：

• SSH 連線、tmux 開一堆 session
• 同一個 repo 拉好幾份 checkout，讓好幾個 Claude 在同一個專案裡平行跑
• 或者用 git worktree 做隔離

他也說這塊他們正在讓它變好用，「目前這些算是一些想法」。要開幾個 session 都可以，平行做完的事會非常多。

現場問答裡的四個重點

• 最難做的是什麼？—— 「讓 bash 指令變安全」。bash 本身就危險，會用你想不到的方式改變系統狀態；但如果每一條都要人工同意，工程師根本沒辦法做事。他們的做法是：判斷哪些指令是唯讀的、用靜態分析找出哪些指令可以安全地合併，再加上一套分層的權限系統，讓你在不同層級設允許與封鎖清單。（這也是為什麼上面那張階層圖會長那樣。）
• 它看得懂圖嗎？—— 完全多模態，而且從第一天就是。因為在終端機裡所以不好發現，但你可以把圖直接拖進去、給它檔案路徑，或者複製貼上。講者的做法是把設計稿拖進去、給它一台 Puppeteer 伺服器，然後叫它自己做到像。
• 為什麼做成 CLI 而不是 IDE？—— 兩個原因。一是 Anthropic 內部用的 IDE 太雜（VS Code、Zed、Xcode、Vim、Emacs 都有人用），要做一個大家都合用的太難，終端機是最大公約數。二是他們近距離看著模型進步的速度，「今年底很可能大家就不用 IDE 了」，所以不想把力氣過度投在 UI 這一層 —— 那些工可能很快就白做了。
• 研究和機器學習也用嗎？—— 用得很兇。工程師和研究員都是每天在用，Anthropic 大約 80% 的技術人員每天用 Claude Code；研究員還會用它編輯和執行 notebook。