Claude Code — 從「如何安全使用」到「如何真正用進工作流」下篇

接續上篇關於 vibe coding 的探討，本文將聚焦在 Claude Code 創始人 Boris Cherny 對於如何將其真正融入工程團隊工作流的見解。

Boris Cherny 談 Claude Code：真正厲害的不是幫你寫 code，而是把整個工程工作流接進來

如果說很多人對 Claude Code 的第一印象，是「一個很會寫 code 的 AI」，那 Boris Cherny 這場分享的價值就在於，他把這個理解往前推進了一大步。他不是把 Claude Code 講成一個 autocomplete 工具，也不是把它包裝成一個神奇黑箱，而是很直接地把它放回工程現場，當成一個真正會影響 onboarding、規劃、寫碼、測試、權限、團隊協作與工具整合的生產力系統。

Boris 的身份本身就讓這場分享很值得看。他是 Claude Code 的創始人，也是 Anthropic 的 technical staff。換句話說，他不是在外部評論 Claude Code，而是在講他們自己到底怎麼把這個東西做出來、又怎麼在內部真的用起來。這也讓整場內容很少空話，幾乎每一段都偏 practical，像是直接把一個 power user 的腦內工作流攤開來給你看。

他一開場就先定義 Claude Code 的定位。過去幾代 coding assistant，大多是在做局部補全，幫你補一行、幾行、或某一小段 code。但 Boris 認為 Claude Code 不是為這個場景設計的。它的本質是 fully agentic。你不是拿它來補字，而是拿它來做 feature、寫完整 function、改整個 file、修整個 bug。這個定義很重要，因為一旦你把它當成 agentic coding tool，而不是單純 completion tool，你對它的期待、操作方式、風險管理方式都會跟著改變。

但真正讓我覺得這場分享有料的，不是他說 Claude Code 很強，而是他說明了怎麼開始用，才能真的把它用對。Boris 最推薦的起手式不是直接把一個大功能丟給 Claude Code，而是先拿它做 codebase Q&A。這點非常值得記住。因為多數人在第一次用這類工具時，很容易一上來就想測極限，直接說「幫我做這個 feature」或「幫我修這個 bug」。但 Boris 的建議剛好相反。他說最好的第一步，是問它：這段 code 怎麼用、這個 class 怎麼 instantiate、這個奇怪的參數為什麼會存在、這個 function 為什麼會長成現在這樣，甚至讓它去查 Git history、issue context，幫你整理這週到底 ship 了什麼。

這個建議很強，因為它讓 Claude Code 不只是 code generator，而是 repo interface。你不是先把它當 junior engineer 叫去寫東西，而是先把它當一個可以快速探索 codebase、讀 commit 脈絡、整理知識的入口。Boris 還提到，Anthropic 內部 technical onboarding 過去大概要 2 到 3 週，現在大概縮到 2 到 3 天。這個數字如果接近真實，就不是單點提效，而是整個團隊知識傳遞速度被重做了。

另一個很重要的點，是 Claude Code 的工作方式並不依賴先做大規模 indexing。Boris 特別強調，它不需要先建遠端索引，不需要把 code 丟進某個遠端資料庫，也不需要等 setup 很久。你的 code stays local，而且不拿來訓練生成模型。這個設計其實很關鍵，因為很多 code assistant 雖然能力不錯，但前置 setup、資料治理疑慮、索引更新延遲，本身就是摩擦。Claude Code 這條路更像是讓 model 現場探索 repo，而不是先建立一個厚重的預處理層。這會直接影響使用門檻和團隊接受度。

影片中另一個我很認同的觀點，是他反覆強調「先規劃，再動手」。Boris 說，很多人會拿 Claude Code 去做一個巨大改動，希望它第一 shot 就把幾千行功能寫對。有時候它真的會做對，但也常常會做出一個技術上能跑、方向上卻不是你要的東西。最簡單的解法，不是更用力 prompt，而是先叫它 brainstorm、先叫它 make a plan、先 run it by me、先 ask for approval，然後再開始寫 code。這其實跟前面另一支 Erik Schluntz 說的「be Claude’s PM」非常一致。重點不是讓模型立刻輸出，而是先讓模型把問題理解對、把任務拆對、把方向跟你對齊。

接下來 Boris 講的，才是 Claude Code 真正開始拉開差距的地方。他說，真正會用的人，不只是會 prompt，而是會把工具和上下文接進來。這裡有兩個層次。第一個是工具。Claude Code 可以接 bash tools、MCP tools、團隊自己的 internal CLI，也可以接 puppeteer、screenshot、simulator、tests 這些讓它能檢查結果的能力。第二個是上下文。像 CLAUDE.md、nested CLAUDE.md、local 設定、slash commands、enterprise policies、shared MCP config，這些其實都在做同一件事：把原本只存在工程師腦中的 repo 習慣、常用命令、架構知識、權限規則、團隊規範，抽取成 agent 可讀的 context layer。

這一點非常重要。因為很多人把 agent 的能力想成是模型本身有多強，但 Boris 其實在講另一件更成熟的事：模型再強，如果沒有工具、沒有 context、沒有 workflow，它也只是個很聰明但不熟環境的人。真正讓 Claude Code 變成團隊級生產力工具的，不是 prompt trick，而是你有沒有把工程環境中的可重用知識整理好，然後系統化地餵進去。

而且 Boris 不是只講「讓 Claude Code 寫」，他更強調「讓 Claude Code 驗」。這也是我覺得很值得注意的地方。影片裡他提到，如果你要它做 UI 或比較複雜的功能，最好的方式不是要求一次做完，而是給它某種 feedback loop。像是 unit tests、integration tests、screenshots、puppeteer、iOS simulator 截圖，這些都可以成為 Claude Code 自我修正的依據。它不是單次生成，而是根據這些回饋多迭代 2 到 3 輪，最後結果通常會好很多。這其實就把 Claude Code 從「輸出器」變成了一個會在驗證環裡調整自己的 agent。這種工作模式，比一次命中更重要，也更接近真實工程流程。

在 Q&A 裡，有兩段我覺得特別值得記。第一段是有人問，為什麼 Claude Code 選擇做 CLI，而不是 IDE 產品。Boris 的回答很直接，一方面是 Anthropic 內部使用的 IDE 非常分散，terminal 是最穩定的共同交集；另一方面，他認為模型進步很快，未來甚至可能弱化傳統 IDE 的重要性，所以他們不想過早把產品重心綁死在 GUI 層。你不一定要完全同意他對未來的預測，但這個回答很清楚地說明了 Claude Code 的產品哲學：它想待在一個更底層、更通用、更容易被組裝的位置。

第二段是 Boris 提到，真正的 power users 幾乎都不是只開一個 Claude Code session。他們會同時跑多個 terminal tabs、多個 repo checkout、多個 worktrees，甚至透過 tmux 去管理並行 session。這個畫面很有意思，因為它暗示了 Claude Code 的成熟用法，不是把它當成單一聊天視窗，而是當成一組可以平行工作的 agent workers。真正的工程師角色，就會從「我自己一個一個做」，慢慢轉向「我怎麼編排、怎麼分工、怎麼讓多個 agent 在不同工作區裡一起推進」。

如果把 Boris 這支影片濃縮成一條最重要的訊息，我會說：Claude Code 真正厲害的地方，不是它單次幫你寫出多少 code，而是它能不能被接進你原本的工程工作流，變成 codebase Q&A、planning、execution、feedback、context sharing、team tooling 和 parallel sessions 的一部分。當它只是一個 prompt box 時，它只是個很強的工具；當它接上工具、上下文與團隊規則後，它才會開始變成真正的工程生產力系統。

這也是為什麼我覺得這支分享很值得看。它沒有停留在「Claude Code 很神」這種表層結論，而是給出了一條很實際的 adoption path。先問問題，不要急著改碼。先做規劃，不要直接衝。把測試、截圖、CLI、MCP、權限、記憶檔案接進來。把個人習慣升級成團隊共享的 context。最後，再讓 Claude Code 從一個你偶爾會用的 AI 工具，變成你每天真的離不開的工程夥伴。