Boris Cherny 已經不再自己寫 prompt 給 Claude 了。
這不是什麼誇大的轉述。這是他本人公開說過的話：「我已經不再自己 prompt Claude 了。我有一堆迴圈（loop）在跑，它們會去 prompt Claude、判斷接下來該怎麼做。我的工作是寫那些迴圈。」他在多個公開場合講過這件事，包括 Sequoia 的演講、Acquired 的訪談、Y Combinator 的 Startup School，而這些言論背後的那套模式，才是這篇文章真正要探討的主題。不是技巧清單，不是功能列表，而是打造出 Claude Code 的那個人，實際上每天是怎麼使用它的——而且是根據他自己公開說過的話來驗證，不是靠二手轉述。
這是一份完整的拆解，以 Cherny 確實說過的話為基礎，再加上 Anthropic 官方文件對他親手打造的這套工具的最佳實踐。
Claude Code 從來就不是為了成為產品而誕生的
要理解 Cherny 如何使用這套工具，首先要理解它的起源，因為起源解釋了背後的哲學，而這個故事比今天大多數使用者所知道的還要更有趣。
Claude Code 始於 2021 年，當時是 AI 安全對齊（alignment）的研究專案，不是產品。一開始是粗糙的 VS Code 擴充套件，然後變成一個內部 CLI 工具，叫做 clide，在 Anthropic 內部用了好幾年，外界根本沒聽過。Cherny 在 2024 年 9 月加入這個專案，並在當年 12 月用兩週衝刺重新打造了核心。2025 年 2 月的公開發布很低調，沒有太多宣傳，反應與其說是興奮，不如說是聳聳肩。接著 Claude 4 推出，採用率幾乎一夜之間暴增。
他自己對這套工具現況的評估，說得非常直接：「我們才完成了 1%。」
這個說法對你應該如何看待和使用它，至關重要。Cherny 不是在描述一個已經完成、有固定正確使用方式的產品。他描述的是一個仍在被積極重寫的東西，而且是由一支用這套工具來打造這套工具本身的團隊在進行。Claude Code 已經多次用 Claude Code 本身重寫，這是一個自我改進的迴圈，比「loop engineering」這個詞出現在公眾討論中還要早得多。這點值得停下來想一想，因為它解釋了一件困擾很多新使用者的問題：為什麼這套工具的「正確」用法好像一直在變。這不是不一致，而是一個連創造者自己都還在用這套工具即時探索它真正能力的東西。
在被變成產品之前，作為內部研究工具多年的經歷，也解釋了為什麼底下的這些哲學讀起來對一個開發者工具來說異常地有主見。大多數工具從第一天開始，為了滿足廣大外部使用者彼此競爭的需求，就會不斷累積功能。Claude Code 則是先在一支解決自身問題的小團隊內部累積了它的哲學，然後才需要去迎合任何其他人的工作流程。這段歷史正是為什麼理解 Cherny 的具體使用模式（而不是泛泛的「AI 程式工具」建議）值得你花時間真正吸收。
核心轉變：從寫 prompt 到設計迴圈
Cherny 公開談論使用 Claude Code 時，最重要的一句話就是上面那段關於迴圈的話，而它實際上的意義值得仔細拆解，而不只是當作一句可以引用的金句。
Prompt 是單一指令，送出一次、回答一次。迴圈則是一個系統：它會 prompt Claude、評估回傳的結果、決定下一步要做什麼、然後重複，整個過程中不需要有人在每個循環中間介入。Cherny 對自己工作的描述是「我的工作是寫迴圈」，意思是他的時間花在設計那些產生和評估 prompt 的系統上，而不是自己一個一個地輸入 prompt。
他確認過的日常工作流程也直接反映了這件事。手機是他主要的操作介面，而不是筆電鍵盤。同時有五到十個活躍 session 在跑，每個都能產生子 agent（sub-agent），有時一次幾百個，有時在深入工作時一個晚上跑到幾千個。數十個迴圈在背景持續運作，照看 pull request、維持持續整合（CI）的健康、按固定排程把回饋分群。這些例行程序即使在筆電闔上時，也持續在伺服器端運行。
對每天使用 Claude Code 的人來說，實際的啟示是：這套工具能達到什麼高度，不是由單一 prompt 寫得多好決定的，而是由你如何設計一套圍繞著「重複、自動化的 prompt、檢查、重試」循環的系統來決定的。
系統提示詞（System Prompt）到底改了些什麼，為什麼重要
Cherny 也直接談過一個具體的技術決策，這顯示了他對「如何指示 Claude」的根本思考方式：「我們從最新的模型中移除了 Claude Code 系統提示詞約 80% 的內容，這是我們學到關於撰寫系統提示詞的經驗。」
那次大幅刪減發生在 Opus 4.8 這一代，系統提示詞從大約 15,000 個字元縮減到約 4,500 個字元，而在程式評估上沒有觀察到任何可測量的損失。根據 Anthropic 自家的上下文工程（context engineering）指南，這背後的教訓是：一旦模型的能力足夠強、可以行使真正的判斷力，那些僵化而詳盡的規則清單就不再必要了。規則變成了判斷事項。工具使用範例被設計成自我文件化的介面取代。預先塞入的完整上下文則被漸進式揭露取代——資訊只有在特定情境真正需要時才會浮現，而不是預設在每一次 session 中都完整載入。
有一個細節值得誠實提出來，因為它讓這個故事的簡單版本變得複雜：當 Opus 5 推出時，獨立開發者的測試發現它的實際系統提示詞比 Opus 4.8 的長了約 72%。這並不與上面的教訓矛盾，而是它更深一層的版本。提示詞在僵化指令的量上縮小了，然後又在更豐富、更具體的參考資料、實際範例、測試套件、評估標準上增長了回來——這些是一個真正更有能力的模型確實能好好利用的上下文類型。重點不在於「越短永遠越好」，而在於指令的量應該配合特定模型實際行使良好判斷所需的事物，而不是追求任何一個方向的固定目標。
用 Anthropic 自家團隊的方式撰寫 CLAUDE.md
這直接連接到你應該如何建構專案層級的指令。Anthropic 官方文件對應有的心智模型講得非常清楚：把 Claude 想像成一個非常聰明但非常資淺的新進員工，而且有失憶症，需要明確的指令。
這個框架的實際含義如下。「聰明」代表你不需要過度解釋一般性的能力，那些本來就有。「資淺」代表它對你專案的歷史或慣例沒有任何累積知識。「失憶」代表每一次 session 都是從零開始，CLAUDE.md 是唯一可靠地在 session 之間傳遞上下文的東西。
Anthropic 文件建議把這個檔案控制在 200 行以內，而最有紀律的團隊有些甚至壓到 60 行。判斷某個東西該不該放進這個檔案的標準是：這對幾乎每一次 session 都真的相關，還是只對某一小塊特定情境的工作有用？通用的事物——建置指令、不可妥協的風格規則、測試期望、真正的護欄——應該放在根目錄的檔案裡。任何比較特定的事物則應該放進被匯入的檔案，只有在 session 的實際工作真的需要時，才用工具直接支援的 @path/to/file 匯入語法把內容拉進上下文。
對於那些真的不能跳過的指令，Anthropic 內部的做法是使用明確的強調標記——「IMPORTANT」或「YOU MUST」——而且只保留給少數「如果 Claude 漏掉、代價會非常高」的規則。如果每個東西都這樣標記，就完全失去了意義，因為一旦不加區別地使用，它就失去了作為訊號的功能。
Plan Mode：先理解，再行動
有一個具體的行為模式值得加入你實際操作這套工具的方式：讓 Claude 在執行之前先做計畫，而不是直接跳進修改。
這不只是功能開關，它反映了 Anthropic 自家文件中描述的一個真實轉變：較新的模型不需像早期版本那樣大量的前期引導，就能正確地規劃，甚至有些團隊回報已經不需要在每個任務上都強制加上明確的 plan mode 步驟，因為模型自己的預設推理在行動之前就會先產生連貫的計畫。話雖如此，對於真正複雜、跨多檔案的工作，明確要求先給計畫、然後在批准執行之前先審視它，仍然是一個有意義的檢查點——可以在誤解的規格蔓延到十幾個檔案修改之前先攔截，而不是事後才發現。
子 Agent 與平行工作
Cherny 確認過的工作流程——在單一 session 中跑數百個、有時數千個子 agent——指向一個結構性的能力，值得理解並有意識地使用，而不是偶然為之。
主 agent 可以把複雜任務拆解成較小的部分，部署子 agent 來獨立執行，每個子 agent 在自己的上下文中作業，而不是全部擠在同一個連續對話中搶空間。這同時達到兩個目的。第一，它讓原本會溢位單一上下文視窗的工作，改由許多較小的視窗來執行。第二，它增加了真正的驗證層，因為子 agent 在審查另一個 agent 的輸出時，檢查的是不是自己產生的東西，這在結構上比 agent 剛產出作業就自己打分數要可靠得多。
針對平行工作，git worktree 可以讓多個 session 同時在各自的 branch 或目錄上作業，不會因為某個 session 進行中的修改去干擾另一個。這就是 Cherny 描述的那種大量並行迴圈背後的機械基礎設施——不是單一 agent 跑得更快，而是許多 agent 同時在真正各自獨立的工作上作業。
Grep 的決定：以簡馭繁的案例研究
Cherny 團隊一個具體且廣為記載的技術決策，說明了一個值得內化的更廣泛哲學。Claude Code 放棄了用向量搜尋和嵌入（embeddings）來做程式碼庫搜尋，改用純粹的 grep 和 glob。他對結果的原話是：「表現勝過一切。而且贏很多。」
這個教訓可以推廣到這個單一決策之外。看起來更複雜的解決方案（語意向量搜尋）並不一定自動優於比較簡單的方案（grep），如果簡單方案其實更匹配問題的話。程式碼庫有精確的語法、精確的函式名稱、精確的匯入路徑——這種精確、字面上的比對正是 grep 擅長的，而模糊的語意比對反而可能因為找出「看似合理但實際錯誤」的結果而破壞事情。
在你自己配置工作流程時的實際啟示：不要基於「複雜就代表有能力」的假設，就去預設採用聽起來更複雜的工具或架構。先針對你的實際使用情境測試簡單的選項。通常它會贏；就算沒有贏，你也確認了更複雜的做法是靠實力贏得位置，而不是白拿的。
永遠不要讓 Agent 替自己的工作打分數
另一個來自 Anthropic 自家 harness engineering 實務、且經確認的原則，直接關係到你應該如何在 Claude Code 工作流程中建構任何驗證步驟：生成和評估應該發生在真正分離的角色中，因為模型剛產出結果就回頭審查自己的輸出時，傾向於給出偏正面的評價，即使人類審查者一眼就能看出問題。
實際上，這意味著撰寫程式碼的 agent，不應該是同一個決定那段程式碼是否夠格上線的關卡。分離的評估步驟——理想上能取得生成 agent 沒有的資訊，例如實際的測試套件輸出、原始需求文件——可以抓到自我評估會漏掉的問題。這就是前面子 agent 驗證模式背後的同一原則，被應用成一種通用的紀律，而不是某一項特定功能。
Effort 與上下文管理
如果你要跑比較長、比較 demanding 的 session，理解如何直接標示投入程度（effort level）很重要。在 prompt 中加入「ultrathink」代表要求該次回應使用最深入的理由推演，而不改變整個 session 的設定。若要進行 session 層級的自動工作流編排，把 effort level 設到最高檔，會在整個 session 中結合深度推理與自動任務拆解，不過這需要一個真正支援該 effort 層級的模型——不是每個同系列中的模型都支援。
上下文管理本身在長時間 session 中也值得刻意關注。Session 跑得越久，累積的上下文就會開始稀釋「現在什麼事情真正重要」的訊號——這跟 CLAUDE.md 檔案臃腫造成的問題一樣，只是發生在單一對話內部的動態過程，而不是靜態地存在於檔案中。為了一個真正的新工作階段而定期開一個全新的 session，而不是讓同一段對話無限延長，是一個真實且務實的紀律，值得應用，而不是假設「更多上下文永遠更好」。
實際範例：把這些套用到一個真實任務上
為了讓以上內容具體而不是抽象，這裡示範這些原則如何在一個真實且常見的任務上組合起來：在一個已有一定複雜度的既有程式碼庫中新增功能——數個互相關聯的檔案、一些既有測試、一個不算簡單但也稱不上特別的變更。
首先，CLAUDE.md 已經就位，簡短、通用，包含建置和測試指令、不可妥協的風格規則，沒有任何情境性的東西來干擾。這代表 session 一開始就自動載入了真實且相關的上下文，你不需要從頭重新解釋專案的慣例。
與其寫一個又長又滿懷希望的 prompt、鉅細靡遺地描述整個功能，不如描述目標，讓模型自己的規劃能力去處理拆解——信任前面系統提示詞討論中提到的「減少鷹架」哲學。對這種規模的任務，明確要求先給計畫是值得多花的一步，因為在這裡攔截一個被誤解的需求，成本只是兩分鐘的修正，而不是事後花一個小時去拆解散落在多個檔案中的變更。
一旦計畫看起來對了，就讓執行繼續下去。如果任務自然分成真正獨立的部分——例如更新資料模型，和另外更新使用該模型的 UI——那就是子 agent 拆解的自然候選，每個部分在自己的上下文中作業，而不是全部擠在同一段連續對話中。
在把結果當作完成之前，跑一個獨立的驗證流程，而不是相信執行 agent 自己說「一切正常」。這可以簡單到開一個全新的 session，或是用一個唯讀的子 agent，檢查實際的測試輸出，以及 diff 是否符合原始計畫，而不是單純接受同一個寫出那些程式碼的上下文所說的那句自信的「完成了」。
注意這個示範裡沒有什麼：沒有奇特的外部工具，沒有不尋常的設定。只是老老實實地把「對真正複雜的工作先做計畫」「對真正獨立的部分用子 agent 拆解」「用分離的驗證取代自我評估」這三個原則，應用在一個具體任務上，而不是停留在抽象描述。
把這個擴展到一整個團隊
以上描述的都是單一個人如何有意識地使用 Claude Code。Cherny 自己確認過的工作流程——每天數百個子 agent、隔夜數千個——本身就是一種擴展的形式：一個人指揮著真正大量的平行自動化工作。但同樣的原則也能延伸到一個團隊一起採用這些做法，只是有幾個特定的考量值得直接點出來。
一旦團隊裡不只一個人用 Claude Code 在維護同一個程式碼庫，CLAUDE.md 就不再只是個人的偏好檔案了。對它的修改，要比照任何會影響整個團隊工作流程的共用設定，採用同樣的審查紀律。一個團隊成員在一次受挫的 session 之後，未經審查就加入一條一次性的「hotfix」指令——這正是產生那些臃腫、自相矛盾、最後不再被確實遵守的檔案的機制。一個輕量的審查步驟，哪怕只是第二個人在 merge 前瞄一眼 diff，就能在問題累積成大麻煩之前攔截掉相當大一部分。
驗證紀律在團隊規模下比單人使用還要重要。一個人同時撰寫和審查自己 agent 輔助的工作時，至少還有機會親自抓到 agent 漏掉的東西。當整個團隊依賴 Claude Code 的輸出流經一個共用的審查流程時，前面提到的「分離評估」原則就不再是選配了——它就是保護程式碼庫、防止 agent 自信但錯誤的自我評估進入 production 的實際機制。因為如果不這樣，唯一的選擇就是相信某個人，在繁忙團隊流程中的某個時間點，碰巧會抓到 agent 自己沒有標記出來的問題。
另外也值得為「定期審視 CLAUDE.md」建立明確的負責人——這是任何會持續累積的共用文件都適用的維護紀律。如果沒有明確指派的負責人，這種工作在實務上很容易被遺漏，因為它不像壞掉的 build 那樣會擋住任何單一的眼前任務，而六個月無人負責的累積，正好會產生那種臃腫、矛盾的檔案——也就是「普遍適用性」原則本來就是要防止的東西。
這些原則常被誤用的地方
底下幾個對上述想法特定的誤讀，一再出現，值得直接點名，因為每一種都有簡單而具體的修正方法。
把「用迴圈取代 prompt」當作可以完全跳過理解任務的藉口。 Cherny 的原話是說他的工作是寫迴圈，而不是說他不再思考那些迴圈實際上應該做什麼。設計一個好的迴圈——好的成功定義、好的停止條件——仍然需要像寫一個好的單一 prompt 那樣清楚地理解問題。迴圈取代的是重複的手動輸入，而不是前置的思考。
把系統提示詞縮減解讀成「永遠給模型越少上下文越好」。 前面文章中的 Opus 5 反例就是專門用來修正這個誤讀的。真正的教訓是：指令的量應該配合特定模型實際行使良好判斷所需的事物，有時代表要減少僵化的規則列表，有時代表要增加豐富、具體的參考資料。因為「最新的模型需要比較少」就不加區別地刪減上下文，是把一個細膩、因模型而異的發現，誤用成一條通則。
出於習慣把簡單任務過度拆解成子 agent。 子 agent 拆解的好處，是在真正龐大、真正獨立的工作上才值得付出那些複雜度。把一個小而緊密耦合的變更硬切成人工的子 agent 片段，只是為了用這個模式，只會增加協調的開銷，卻沒有在大任務上那種足以合理的效益。前面文章的實際範例，刻意只在部分真正自然獨立時才使用子 agent，而不是不管任務大小、一律當作預設。
基於「新型號已經不需要了」的假設而跳過驗證。 分離評估原則不是針對較弱模型所設計的權宜之計，不會因為能力提升就變得不需要。它是自我評估的結構性事實：在同一個產生內容的上下文裡檢查自己工作的模型，永遠會比獨立檢查更難抓到自己的盲點——無論底層模型變得有多強。這對人類審查者也一樣成立，而且不會因為審查者變聰明就改變。
真正值得養成的每日習慣
把以上所有內容收斂成具體、務實的每日實踐，以下是真正跟隨 Cherny 示範做法會是什麼樣子。
不要再把所有任務當作「一次就要寫對的單一 prompt」。改為設計一個迴圈：一個嘗試執行任務的 agent、一個檢查嘗試是否成功的方法、以及一條根據檢查結果（通過、重試、或直接轉交給你）定義下一步怎麼走的路徑。
保持 CLAUDE.md 簡短，把它當作「給一位有能力但完全沒有背景知識的新人」的 onboarding 教材，而不是一本包山包海的手冊。把任何情境性的東西移到匯入的檔案中，不要讓根目錄文件變得臃腫。
在真正複雜、跨多檔案的工作上有意識地使用 plan mode；對比較簡單、範圍明確的任務，相信模型自己的預設規劃，不要出於習慣每個地方都強加一個額外步驟。
把大型任務拆解成在不同上下文中作業的子 agent，而不是試圖把整個複雜任務塞進一段連續對話。用一個分離的流程驗證重要工作，而不是相信單一 agent 的自我評估。
預設採用最能合理解決你特定問題的簡單工具——就像 grep 在這種特定使用情境下打敗向量搜尋一樣——只有在簡單的選項真的被測試過、發現不夠用之後，才去碰更複雜的東西。
用 git worktree 為真正獨立的工作建立實際的平行處理能力，而不是因為「這就是預設的工作方式」，就把一切放在同一個循序的 session 裡跑。
這一切實際要走向哪裡
Cherny 自己那句「我們才完成 1%」值得認真對待，把它當作一句實際的陳述，而不只是一個聽起來很謙虛的說法。上面描述的具體模式——用迴圈設計取代單次 prompt、隨著模型能力增強而激進地刪減系統提示詞、子 agent 拆解、分離驗證——都不是固定不變的最終方法論。它們是一個連創造者自己都說還在早期的工具與實踐的現狀。
真正值得培養的技能，不是背誦今天這套特定的最佳實踐配置，而是對底層原則理解到足以在工具本身持續演進時不斷調整——就像 Cherny 自己的團隊用 Claude Code 反覆重寫 Claude Code 一樣，不斷優化迴圈，而不是把任何一個版本當作已經完成。
這就是串起這整篇文章的真正主線：不是一張靜態的技巧清單，而是一套實際運作的哲學——設計系統，而不是輸入單一指令；保持指令精簡，讓模型能力在進步的過程中承擔更多工作；獨立驗證，而不是相信自我評估；預設簡單，直到複雜真的證明自己的必要性。這一切，直接來自打造這套工具的人自己實際使用它的方式。
追蹤 @cyrilXBT 取得更多以經查證、有公開紀錄的素材為基礎的 Claude Code 深度拆解。
