Boris 的 9 條 Claude Code 實戰技巧：原來高手的配置這麼“樸素” Boris Cherny 在 Anthropic 內部有個綽號：Claude Code 之父。他最近在 X 上很活躍，於是很多人問 Boris：你自己到底怎麼用 Claude Code？他剛在 X 上分享了 9 條實戰技巧。 沒有你想象的那麼多技巧，每一條都樸實無華。 【1】核心理念：Claude Code 的最佳實踐並沒有標準答案 Boris 開場就說： > My setup might be surprisingly vanilla! Claude Code works great out of the box, so I personally don't customize it much. > 我的配置可能出乎你意料地“原裝”。Claude Code 開箱即用效果就很好，我個人沒做太多定製。 也能理解，那些最佳實踐，比如 Skills、Plugins，作為 Claude Code 開發者，他們早就把這些最佳實踐作為功能內置了。 使用 Claude Code 沒有唯一正確的方式。團隊故意把它設計成可以隨便折騰的樣子，你想怎麼用、怎麼改、怎麼魔改都行。Claude Code 團隊內部每個人的用法都完全不同。 所以沒必要去費力找“最佳實踐”，適合自己的節奏最重要。 【2】多 Agent 任務並行：同時開十幾個 Claude Boris 的日常是這樣的：終端裡開 5 個 Claude Code 實例，標籤頁編號 1 到 5，開著系統通知，哪個需要輸入就跳過去處理。 同時，他還在 網頁版上跑 5 到 10 個任務。終端和網頁可以互相“交接”：用&符號把本地會話轉到網頁，或者用--teleport 在兩邊來回切換。 他每天早上和白天會從手機 Claude 應用上啟動幾個任務，晚點再回來看結果。 這種“多線程”工作方式的核心邏輯是：Claude Code 擅長自主執行，很多任務不需要你盯著。你啟動任務、給個方向，讓它跑著，自己去忙別的。等它需要你確認的時候再切回來。 這跟傳統的“人敲一行代碼、AI 補幾行”完全是兩種節奏。但這也對使用者有更高的要求，你需要擅長給 Agent 分配任務，並且能隨時在多個任務之間切換。對於習慣了自己開發，同時只有一個任務進行的傳統開發模式來說，是個很大挑戰。 慚愧的說，雖然我也常用 Coding Agent，還是不習慣太多任務同時運行，今年要加強這方面的練習。 【3】模型選擇：為什麼用 Opus 而不是更快的 Sonnet Boris 說他所有任務都用 Opus 4.5 加上 thinking 模式。這是他用過最好的編程模型。 有人會問：Opus 不是比 Sonnet 更大、更慢嗎？Boris 的回答是：雖然單次響應慢一點，但你需要糾正它的次數少得多，工具調用也更準確，最終算下來反而更快。 這點其實我一直很認同，寫代碼這種事不能求快，還是得質量高，如果一個快模型需要你來回糾正三次，不如用個慢模型一次搞定。時間不只是模型響應時間，還有你的注意力和精力成本。 唯一的問題就是 Opus 成本更高。 【4】 是 Claude Code 的一個特殊配置文件，放在項目根目錄。每次啟動 Claude Code，它會自動讀取這個文件，把裡面的內容當作“背景知識”。你可以理解為：這是你給 AI 寫的項目說明書，告訴它這個項目的架構、規範、注意事項。 Boris 團隊的做法是：整個 Claude Code 倉庫共用一個 Git 裡，所有人一起維護。每週都有人往里加東西。規則很簡單：每次看到 Claude 做錯了什麼，就把“別這樣做”寫進去，下次它就知道了。 更有意思的是，他們在代碼審查時也會用到這個機制。Boris 會在同事的 PR 裡@.claude，讓 Claude 把某條新規則加到 裡。這是通過 Claude Code 的 GitHub Action 實現的。 Dan Shipper 管這種做法叫“複利工程”：每一次糾錯都變成團隊資產，讓 AI 越來越懂你們的項目。 如果你還沒用過 命令，Claude 會自動分析項目結構，生成一個初始版本。然後你邊用邊補充，看到不對的地方就加進去。 【5】Plan 模式：先想清楚再動手 Boris 說，他大多數會話都從 Plan 模式開始。在 Claude Code 中按兩下 Shift+Tab 就能切換。 Plan 模式下，Claude 不會直接改代碼，而是先給你一個執行計劃。你可以來回討論、修改計劃，直到滿意為止。然後切到自動接受模式，Claude 通常能一次性完成。 “好的計劃真的很重要”，這個習慣其實是把軟件開發的經典智慧搬到了 AI 協作裡：先設計再編碼。很多人用 AI 寫代碼的問題是直接開幹，結果方向錯了返工成本很高。花幾分鐘對齊計劃，能省幾小時的返工。 【6】自動化重複工作：斜槓命令和子 Agent Boris 有幾個每天要用幾十次的操作，他把它們做成了斜槓命令。比如"/commit-push-pr"，一鍵完成提交、推送、創建 PR。 斜槓命令本質上是 Markdown 文件，放在.claude/commands/目錄下。你可以用自然語言寫指令，還能嵌入 bash 腳本預先獲取一些信息，減少模型來回調用的次數。這些命令可以提交到 Git，整個團隊共享。 除了斜槓命令，他還用子 Agent（ Agent 是獨立的 Claude 實例，專門幹某類活。比如他有個 code-simplifier 子 Agent，在主 Claude 完成工作後自動簡化代碼；還有個 verify-app 子 Agent，專門負責端到端測試。 這兩個功能的共同點是：把你反覆做的事情固化下來，讓 Claude 自己調用。你不用每次都重複解釋，也不用記住各種命令細節。 使用 PostToolUse Hook 來格式化 Claude 生成的代碼。Claude 通常能自動生成格式良好的代碼，而這個 Hook 會處理最後 10% 的代碼，以避免後續在持續集成 (CI) 過程中出現格式錯誤。 【7】安全與集成：權限配置和外部工具 Boris 不用--dangerously-skip-permissions 這個“危險”選項。相反，他用/permissions 命令預先批准一些常用的安全命令，避免每次都彈確認框。這些配置保存在.claude/settings.json 裡，團隊共享。 更強大的是 MCP 服務器集成。MCP 是 Model Context Protocol 的縮寫，是 Anthropic 推出的讓 AI 連接外部工具的標準協議。通過 MCP，Claude Code 可以直接： - 搜索和發送 Slack 消息 - 跑 BigQuery 查詢回答數據問題 - 從 Sentry 拉錯誤日誌 Boris 團隊把 Slack 的 MCP 配置也提交到了倉庫，所有人開箱即用。 這意味著 Claude Code 不只是個編程工具，而是能調用你整個工具鏈的“全能助手”。 【8】長任務處理：讓 Claude 自己驗證 對於跑很久的任務，Boris 有幾個策略： 一是讓 Claude 完成後自動用後臺 Agent 驗證結果。你可以在提示詞裡要求，也可以用 Stop Hook 更確定性地觸發。 > 注：Hooks 是 Claude Code 的"鉤子"機制，讓你在 Claude 執行操作的特定時刻插入自定義邏輯。你可以把它理解為"觸發器"：當某個事件發生時，自動執行你預設的命令或腳本。 > Stop Hook 就是在 Claude 完成響應、準備交還控制權時。 > 相關文檔： 二是用 ralph-wiggum 插件 本質上就是一個 Bash 循環”：想象一個簡單的死循環（while true），它不停地把同一個任務說明書（提示詞文件）餵給 AI 智能體，讓它一遍又一遍地改進工作，直到徹底完成。 三是在沙箱環境裡用--permission-mode=dontAsk 或--dangerously-skip-permissions，讓 Claude 不被權限確認打斷，自己跑到底。 核心思路是：既然是長任務，就別讓它等你。給它足夠的自主權和自我糾錯能力。 【9】最重要的一條：給 Claude 驗證能力 Boris 把這條放在最後，說這可能是獲得好結果最重要的因素。 如果 Claude 能驗證自己的工作，最終產出質量能提升 2 到 3 倍。 他舉了個例子：他們提交到 的每一個改動，Claude 都會用 Chrome 擴展自己測試：打開瀏覽器、測試 UI、發現問題就迭代，直到功能正常、體驗合理。 驗證方式因場景而異。可能是跑一個 bash 命令，可能是跑測試套件，可能是在瀏覽器或手機模擬器裡測試應用。形式不重要，重要的是：讓 AI 有反饋闘環。 這個道理其實很樸素。人類工程師也是靠“寫代碼—測試—看結果—修改”這個循環來保證質量的。AI 也一樣。如果它只能寫不能測，就像閉著眼睛做事，質量全靠運氣。 Boris 的建議是：投入精力把驗證機制做紮實。這是回報率最高的投資。 【10】高手用劍無招勝有招 武俠小說裡面，高手用劍沒有那麼多花裏胡哨的招式，無招勝有招。Boris 沒有炫耀複雜的定製配置，沒有神秘的私藏提示詞，用的就是官方功能。區別在於：他真正理解這些功能背後的邏輯，然後把它們組合成高效的工作流。 並行工作是因為 Claude 能自主執行；用 Opus 是因為綜合效率更高； 是把糾錯變成資產；Plan 模式是先想清楚再動手；斜槓命令和子 Agent 是自動化重複勞動；驗證機制是給 AI 反饋閉環。 如果你剛開始用 Claude Code，不必急著研究各種高級配置。先把基礎用好：學會並行，學會規劃，學會積累 AI 驗證手段。 等你真正遇到瓶頸了，再去折騰那些花活不遲。

Boris 有一點沒提的就是基礎的 CI/代碼審查 workflow，這些事情可能對他們大廠做習慣了的來說是平常，默認就應該有的事情 比如說當他用 Claude Code 完成一個任務，不會說直接合併到主分支，而是提交一個 PR。 提交 PR 後，在 CI 服務器上會自動跑所有的 lint 和自動化測試，如果測試失敗 PR 是無法合併的。 一個 PR 通過了所有的自動化測試，還需要有人去做代碼審查（當然可以 AI 輔助，但還是需要人確認），如果代碼審查發現問題，是需要繼續修改的。 對於很多個人開發者並沒有習慣去搭建一個 CI/代碼審查的 工作流，甚至連 Git 代碼管理都沒有做，出問題都沒法回滾。

【10】 那些你看不見的東西 Boris 有一點沒提的就是基礎的 源代碼管理/ CI（持續集成） / 代碼審查 workflow，這些事情可能對他們大廠做習慣了的來說是平常，默認就應該有的事情 比如說當他用 Claude Code 完成一個任務，不會說直接合併到主分支，而是提交一個 PR。 提交 PR 後，在 CI 服務器上會自動跑所有的 lint 和自動化測試，如果測試失敗 PR 是無法合併的。 一個 PR 通過了所有的自動化測試，還需要有人去做代碼審查（當然可以 AI 輔助，但還是需要人確認），如果代碼審查發現問題，是需要繼續修改的。 這些也是他們能多任務並行的基礎，如果沒有做好這些基礎工作流，就無法做到多任務並行。 對於很多個人開發者並沒有習慣去搭建一個 CI/代碼審查的 工作流，甚至連 Git 代碼管理都沒有做，出問題都沒法回滾。