Claude Code之父最新訪談揭秘：Claude Code 迭代靠的是直覺「附個人獨家使用秘笈」

Claude Code 項目負責人Boris Cherny內部最新訪談，和最頂級的大佬學習Claude Code，比你看多少碎片化的信息都強

Boris Cherny 作為Claude Code 創造者 和 Alex Albert (Claude Relations 負責人) 深入詳細的討論智能體編程的實用化、背后模型的演進過程、直覺驅動的Claude Code 迭代，以及 Claude Code 的設計哲學

其中Boris首次揭秘的直覺驅動的Claude Code 迭代非常有意思，原來Claude Code這個神器開發并不是依靠什么基準測試而是內部構建的“直覺系統”

Boris認為如果你未來要當軟件工程師，基本的計算機編程知識和coding技能仍然是必須的，只有懂“手藝 ”的人，才能更好地駕馭和指導 AI 這個強大的工具！軟件工程師的未來將向更高層次的抽象演進，更側重于目標設定、系統設計和創意實現

訪談最后Boris 還給出了如何高效使用 Claude Code獨家秘笈和最佳實踐

整個訪談20分鐘，以下是訪談的核心內容

僅一年時間Agentic Coding (智能體編程)走向實用

在探討智能體編程的未來之前，我們有必要先回顧一下它在短時間內所經歷的劇烈演變。僅僅在一年多以前，AI 在編程領域的應用還相當初級和分散。開發者的工作流通常是這樣的：在一個集成開發環境 (IDE) 中編寫代碼，IDE 自帶一些基礎的自動補全功能，旁邊可能還會開著一個獨立的聊天應用。當遇到問題時，開發者會向聊天機器人提問，然后手動復制、粘貼代碼片段，再進行修改和整合。這在當時，就是 AI 輔助編程的最高水平。

然而，在過去的一年里，整個范式發生了根本性的轉變。AI 不再僅僅是一個被動提供代碼片段的工具，而是進化成了一個主動的、能夠深度參與開發流程的agent。如今，使用智能體進行編程已經從一個新奇的概念或原型功能，轉變為許多開發者日常工作循環 (inner loop) 中不可或缺的一部分

這場變革的核心在于，開發者與代碼的交互方式從直接操作文本演變為指導智能體為你操作文本。過去，我們逐行逐字地編寫、修改和調試代碼；現在，我們更多地是向一個智能體下達指令，描述我們想要實現的功能或修復的 Bug，然后信任它去分析、修改甚至創建大量文件和代碼。智能體能夠獨立完成過去需要開發者手動執行的大量編輯工作，有時甚至能從零開始構建一個完整的應用程序。

這一飛躍之所以能在今天實現，Boris 認為主要歸功于兩個關鍵因素的成熟：

模型的進化：首先，底層語言模型的能力得到了質的提升。早期的模型或許能完成一些簡單的任務，但往往缺乏長期規劃和復雜邏輯推理的能力。隨著像 Claude 3.7、Claude 4.0 乃至 Opus 4.1 這樣更強大的模型問世，它們在理解復雜指令、保持任務連貫性以及執行多步操作方面的能力越來越強

“鞍具”的完善：其次，僅僅有強大的模型是不夠的，還需要一個高效的“鞍具”來駕馭它。Boris 用了一個例子：模型就像一匹強大的馬，而“鞍具”就是駕馭這匹馬所需的全套裝備，比如馬鞍和韁繩。對于 Claude Code 而言，這個“鞍具”就是整個產品本身。它包含了所有模型之外的、用于交互和控制的系統組件，例如：

a.系統提示 (System Prompt)：用于設定模型的角色、行為準則和目標

b.上下文管理 (Context Management)：智能地決定在與模型交互時提供哪些相關的代碼文件和信息

c.工具集 (Tools)：賦予模型執行具體操作的能力，比如讀寫文件、運行命令、搜索代碼庫等

d.擴展協議：例如 MCP (Meta-Context Protocol)，允許模型接入外部信息源，如 Sentry 的錯誤日志或 Slack 消息

e.設置與權限系統：讓用戶可以精細地控制智能體的行為邊界。

這個“鞍具”和模型之間是一種共同進化的關系。在 Anthropic 內部，包括模型研究員在內的所有員工都在日常工作中使用 Claude Code。當他們在實際開發中遇到模型的局限，比如模型在執行某個特定類型的代碼編輯時頻繁失敗，或者在長時間自主運行時會跑偏，這些第一手的使用體驗會直接反饋給模型團隊。團隊可以根據這些具體的失敗案例，針對性地進行數據收集和模型微調，從而教會模型如何更好地完成這些任務。這個有機的、持續的反饋循環，使得模型本身越來越擅長智能體式的工作，而“鞍具”系統也在不斷迭代，以便更好地發揮出新模型的能力。正是這種模型與產品之間的協同進化，共同推動了智能體編程從理論走向了實用

直覺驅動迭代Claude Code

當 AI 模型的能力越來越強大，一個核心問題也隨之而來：我們如何準確地評估一個編碼模型是否真的更好了？傳統的做法是依賴于標準化的基準測試集 (benchmark)，例如 SWE-bench 或更新的 T-bench。這些測試集包含了一系列預設的編程問題，通過模型解決問題的成功率來對其性能進行打分。雖然這些測試在一定程度上可以量化模型的進步，但 Boris 指出，它們正面臨越來越大的局限性。軟件工程的真實世界充滿了復雜性、模糊性和多變性，這些是任何合成的、標準化的測試集都難以完全捕捉的

因此，在 Claude Code 團隊的實踐中，他們更依賴一種看似不科學但卻更有效的方法：直覺測試，或者說是“氛圍檢查 (Vibe Check)”。當一個新模型版本或一個產品新功能需要評估時，Boris 的做法非常直接：他會用這個新版本來完成自己當天的日常開發工作。他不會去運行一套預設的測試用例，而是將新工具無縫地融入到真實的工作流中——無論是編寫新功能、修復一個緊急的 Bug，還是為了回復一個 GitHub issue 而去閱讀和理解既有代碼。

這種評估方式的核心在于，它能真實地反映出工具在實際應用場景中的表現。一個在基準測試上得分很高的模型，在實際使用中可能會感覺很笨拙；反之，一個模型可能在某些指標上不突出，但用起來卻異常聰明和順手。真正的衡量標準變成了：它是否讓我感覺更有效率？它是否能更好地理解我的意圖？它是否讓我的開發過程更流暢？這種基于真實使用體驗的直覺，成為了判斷模型和產品是否進步的最重要信號

為了系統性地收集和利用這種直覺，Claude Code 團隊在 Anthropic 內部建立了一個極其高效的反饋循環

中心化的反饋渠道：團隊設立了一個專門的 Slack 頻道，作為所有內部用戶提供反饋的唯一入口。任何人在使用中遇到問題、有新想法或感到困惑，都可以直接在頻道里發布。

超快速的響應與閉環：這個反饋循環成功的關鍵在于 Boris 和團隊成員的積極參與。每當有新的反饋出現，Boris 都會第一時間用 emoji 回應表示收到，并主動追問更多細節以厘清問題。最重要的是，他會以極快的速度修復 Bug 或實現簡單的功能改進。有時他會花上幾個小時，集中處理頻道里積壓的反饋，并且每解決一個問題，都會回到原帖下回復用戶，告知問題已經修復

激勵與正向循環：這種有問必應、有求必應的文化，打破了許多組織中反饋石沉大海的困境。當用戶看到自己的意見被認真傾聽并迅速得到解決時，他們會受到極大的鼓舞，從而更愿意在未來提供更多、更高質量的反饋。久而久之，這個 Slack 頻道變成了一個信息量巨大的消防水管 ，源源不斷地為團隊提供最真實的、來自一線的用戶信號。

這個緊密的、由直覺驅動的內部 dogfooding (內部試用) 循環，讓 Claude Code 團隊能夠在沒有復雜評估框架的情況下，依然能快速、準確地迭代產品，確保每一次更新都真正解決了用戶的痛點，提升了實際的開發體驗。在這個過程中，所有用戶的集體直覺匯聚成了比任何硬性指標都更寶貴的導航信號。

Claude Code 的設計哲學：保持簡單，可擴展性

從誕生之初，Claude Code 的核心設計哲學之一就是保持簡單，并使其盡可能地具有可擴展性 ”。團隊深知，每個開發者、每個團隊、每個代碼庫都有其獨特的工作流程和上下文需求，一個封閉的、一成不變的工具是無法滿足所有人的。因此，Claude Code 被設計成一個開放的平臺，提供了一系列由淺入深的擴展點，讓用戶可以根據自己的需求對其進行定制和改造。

這種可擴展性的設計經歷了持續的演進，從最初簡單的配置文件，發展到如今復雜的命令和子智能體系統

1.CLAUDE.md：這是最早也是最基礎的擴展方式。用戶可以在項目的根目錄或任何子目錄中創建一個名為 CLAUDE.md 的 Markdown 文件。這個文件的內容會被 Claude Code 自動讀取，作為與模型交互時的額外上下文。開發者可以在里面寫下項目的架構概述、編碼規范、常用庫的說明，或者任何希望 AI 在工作時了解的背景信息。由于這個文件是項目的一部分，可以被簽入代碼版本控制系統 (如 Git)，因此它能隨著代碼庫的演進而同步更新，確保 AI 掌握的信息始終是最新、最準確的

2.設置與權限系統：隨著功能的增加，團隊引入了更精細的設置和權限系統。用戶可以配置智能體的行為，例如限制它可以訪問的文件路徑、可以執行的命令類型等，從而在賦予其強大能力的同時，確保安全性和可控性

3.Hooks (鉤子)：為了滿足更高級的定制需求，團隊工程師 Dixon 構建了一套強大的鉤子系統。它允許用戶在 Claude Code 工作流的特定節點（例如，在執行一個命令之前或之后）注入自定義的邏輯。這為實現復雜的自動化流程和與其他工具的深度集成打開了大門

4.模型上下文協議 (Model Context Protocol)：這是一個重要的擴展點，它讓 Claude Code 能夠超越本地代碼庫，接入外部數據源。通過實現 MCP 服務器，開發者可以讓 Claude Code 讀取來自公司內部文檔、任務管理系統、錯誤監控平臺（如 Sentry 日志）或通信工具（如 Slack 消息）的信息，從而在解決問題時獲得更全面的上下文

5.Slash Commands (斜杠命令) 與 Subagents (子智能體)：這是目前最新的、也是功能最強大的擴展方式。用戶可以自定義斜杠命令，它本質上是一個預先定義好的、可復用的工作流，通常以 Markdown 文件的形式存在于代碼庫中

Boris 舉了一個他自己的例子：他創建了一個 /commit 命令。這個命令對應的文件中包含了他對如何編寫一條高質量 Git commit message 的所有要求和格式說明，并且預先授權了 git commit 這個 Bash 命令。這樣，當他需要提交代碼時，只需輸入 /commit，Claude 就會自動按照預設的規范生成提交信息并執行提交操作，無需他每次都手動確認權限

子智能體可以看作是斜杠命令的另一種形式，它的特殊之處在于擁有一個“分叉的上下文窗口 (forked context window)”。這意味著它可以像一個獨立的、專注于特定任務的智能體一樣工作，而不會干擾主對話的上下文

這些豐富的擴展點共同構成了 Claude Code 的可擴展性生態。它們將 Claude Code 從一個單純的編碼工具，提升為一個可以被深度定制和集成的開發平臺。展望未來，Boris 表示團隊將繼續沿著這個方向努力，讓 SDK 變得更加強大和通用，不僅能用于構建編碼智能體，還能支持任何需要智能體能力的場景，真正賦能開發者在 Claude Code 之上構建自己的創新應用

軟件工程師的未來

隨著智能體編程能力的飛速發展，一個所有工程師都關心的問題浮出水面：我的工作在未來會變成什么樣？我應該如何提升自己以適應這個新時代？

Boris 認為未來人類軟件工程師并非無事可做，整天只審核 AI 生成的拉取請求 (Pull Request)，而是一種工作重心的戰略性轉移，即從具體的代碼實現細節，上升到更高層次的抽象

短期未來 (6-12 個月內) 的工作模式：

人機協作模式的演變：傳統的手工編碼并不會消失，但其形式會發生改變。開發者將越來越少地直接編輯文本，而是更多地通過與 Claude 的對話來指導它完成代碼的修改、重構和生成

主動與被動工作的結合：工作流將包含兩種模式。一種是開發者主動發起任務，指導 Claude 完成；另一種是 Claude 會變得更加主動，它可能會根據代碼庫的靜態分析、或新出現的 issue，主動地提出改進建議、修復 Bug，甚至自己完成代碼修改并提交。在這種模式下，工程師的角色更像是最終的決策者和質量把關人，決定是否接納 AI 提出的變更

長期愿景 (12-24 個月及以后) 的工作模式：

從任務導向到目標導向：工程師與 AI 的交互將進一步抽象化。屆時，你可能不再需要告訴 AI “請修改這個文件里的這個函數”，而是直接給它設定一個高級別的目標，例如：“為我們的應用增加一個用戶認證系統”，或者“將這個服務的平均響應時間優化 20%”。AI 智能體將能夠自己分解這個宏大目標，規劃出詳細的執行步驟，并自主完成所有必要的編碼、測試和部署工作

工程師成為架構師和產品經理：隨著 AI 接管越來越多的底層實現工作，工程師將能夠將更多的精力投入到更具創造性和戰略性的任務上，例如系統設計、技術選型、定義產品目標和用戶體驗。工作的核心將從如何實現轉變為應該實現什么和為什么這樣實現

**開發者如何為未來做好準備

面對這一趨勢，Boris 提供了兩條核心建議：

打好堅實的基礎功底：AI 的出現并沒有讓基礎知識變得不重要，反而可能要求更高。你仍然需要深入學習編程語言、編譯器原理、運行時環境、網絡協議、系統設計等核心計算機科學知識。因為當 AI 犯錯或無法解決復雜問題時，最終還是需要具備深刻理解的工程師來介入、診斷和糾正。只有懂“手藝 ”的人，才能更好地駕馭和指導 AI 這個強大的工具。

擁抱創造力，將想法快速落地：Boris 回憶起自己中學時用 TI-83 Plus 計算器學習編程的經歷。那時，編程的魅力在于能快速將一個想法（比如編寫一個能計算數學題答案的程序）變成現實，這種即時反饋的樂趣是巨大的。然而，現代軟件開發的棧變得異常復雜（例如 React, Next.js, Webpack 等），大大提高了從想法到產品的門檻。智能體編程正在改變這一點，它讓開發者能夠像當年使用計算器一樣，快速地將創意原型化并構建出來

Boris 強調，在這個新時代，代碼本身不再那么珍貴了。因為 AI 可以輕松地重寫和重構代碼，所以代碼的完美性不再是唯一的追求。更重要的是你想要構建的“東西 (the thing you make)”——你的產品、你的創意

因此，給開發者的建議是：在打好基礎的同時，要變得更有創造力。如果你有一個創業點子或一個產品想法，現在就可以借助 AI 智能體立即動手去實現它。這個時代解鎖了前所未有的潛力，讓個人能夠以過去無法想象的速度和規模進行創造。

總而言之，未來的工程師將是AI 增強型的創造者，他們利用 AI 處理繁瑣的實現細節，從而能更專注于那些真正需要人類智慧、洞察力和創造力的領域。

Boris 的獨家秘笈：如何高效使用 Claude Code

作為 Claude Code 的創造者，Boris 分享了他個人在使用這款工具時總結出的一些最佳實踐和技巧。這些建議旨在幫助用戶，無論是新手還是老手，都能更高效、更智能地與 AI 編程智能體協作。

他提出了兩個核心建議，第一個是針對新手的入門心法，第二個是針對日常使用的分級策略

技巧一：入門時，先問而后寫

這個建議聽起來可能有些反直覺：當你第一次使用像 Claude Code 這樣的強大代碼生成工具時，先不要急著用它來寫代碼

從提問開始：你應該從把它當作一個代碼庫的專家問答系統開始。利用它來探索和理解你正在處理的代碼庫。你可以問一些問題，例如：

“如果我想在這個項目里新增一個日志記錄器 (logger)，我應該怎么做？涉及到哪些文件？”

“這個函數為什么被設計成現在這樣？能幫我追溯一下它的歷史背景嗎？”

“請幫我梳理一下用戶認證流程的核心邏輯，它分布在哪些模塊里？”

建立信任與心智模型：通過這種方式，你可以親身體驗 Claude Code 是如何為你進行代碼庫研究的。它會去閱讀文件、分析依賴關系，甚至能通過 git blame 查看代碼的歷史演變來回答你的問題。這個過程能幫助你建立對 AI 智能體能力的信任，并形成一個正確的心智模型——它是一個可以為你執行研究任務的伙伴，而不僅僅是一個代碼生成器。當你對它以這種方式輔助你的工作感到舒適后，再開始讓它為你編寫代碼，效果會好得多

技巧二：根據任務難度，采用分級協作策略

在實際編碼工作中，任務的復雜程度各不相同。Boris 建議將任務大致分為簡單、中等和困難三類，并針對每一類采取不同的協作模式。

簡單任務 ：

定義：這類任務通常很明確，Claude 基本上可以通過一次提示 (one shot) 就準確完成。例如，修復一個拼寫錯誤、為一個函數添加文檔字符串、或者實現一個簡單的 API 端點。

工作流：對于這類任務，Boris 會采用最放手的方式。他甚至不會在自己的本地終端里操作，而是直接在 GitHub 的 issue 頁面里 @Claude，然后簡單描述任務，讓 Claude 自動完成編碼、創建 Pull Request 并提交。這樣做的好處是完全不占用他本地的開發環境和注意力，可以并行處理其他更重要的事情

中等任務：

定義：這類任務比簡單任務更復雜，可能需要修改多個文件或包含一些邏輯判斷，AI 不一定能一次性完美搞定

工作流：對于中等任務，Boris 會在自己的終端里啟動 Claude Code，但會采用一種“先規劃，后執行”的模式。他會首先進入規劃模式 (plan mode)（通過快捷鍵 Shift + Tab），與 Claude 一起討論并確定一個清晰的執行計劃。這個計劃會列出所有需要進行的修改步驟。只有當他對這個計劃感到滿意，并確認 Claude 的理解與他一致后，他才會切換到自動接受模式 (auto-accept)，讓 Claude 按照既定計劃去執行。這個過程確保了 AI 的行動在可控的軌道上

困難任務 ：

定義：這是指那些高度復雜、充滿不確定性或需要深度架構思考的任務。例如，設計一個新系統、重構一個核心模塊，或者解決一個深層次的性能瓶頸

工作流：在處理這類任務時，人類開發者必須是主導者。Boris 強調，此時的他才是駕駛員，而 Claude 則扮演著一個強大的結對編程伙伴或輔助工具的角色。他會利用 Claude 來快速進行代碼庫研究、探索不同的實現思路、或者快速編寫一些原型代碼來驗證想法和理解系統邊界。但他會親自完成大部分核心的、關鍵的代碼實現工作。在這種模式下，AI 的角色是輔助思考和加速探索，而不是主導執行。最后，或許可以讓 Claude 來完成一些收尾工作，比如編寫單元測試

通過這種分級策略，開發者可以根據任務的性質靈活地調整與 AI 的協作深度，既能最大化地利用 AI 的效率優勢，又能確保在關鍵和復雜的環節中保持人類的控制力和洞察力

參考：

https://www.youtube.com/watch?v=iF9iV4xponk