近日，Claude Code 負責人 Boris Cherny 與 Meta Dev Infra 團隊產品總監進行了一場爐邊對談，本次對話圍繞 AI 編程工具的現狀與演進、ROI 評估框架、Loops 自動化范式、Cowork 的非編碼場景應用、模型選擇策略，以及 AI 時代工程師的角色轉型等話題展開。

Boris Cherny表示，現在他的100% 代碼由 Claude 生成，并且大部分代碼都是在手機上寫的，僅從今年 3 月份算起，已經消耗了 80 億個 Token。他指出，Anthropic 內部今年每位工程師的代碼產出量增長了8倍，當代碼100%由 AI 生成后，真正的瓶頸轉移至好點子的生成速度，繼而延伸至產品經理、市場推廣等上下游環節。

關于 Loops，他表示，Loops 是 AI Agent 提示 AI Agent 持續循環運行的自動化范式，他認為，當前 Loops所處階段與一年半前的 AI Agent 領域相當，目前他約30%的代碼通過 Loops 生成，代碼審查、用戶反饋處理、架構優化、測試清理等維護任務已全部納入 Loop持續執行，他僅在事后審查。

關于測試時計算，他指出，Transformer 以及大語言模型的能力擴展方式，本質上是數據量、神經網絡規模以及用于訓練網絡的計算量的函數。除數據量、神經網絡規模、訓練計算量三個傳統擴展因子外，測試時計算是近年引入的第四個關鍵因子。他表示，測試時計算用來描述模型在推理階段生成了多少個 Token，可以通過一些機制，讓模型高效地生成更多的 Token，從而實現更優的輸出結果。目前有兩種實現路徑：一是算力投入設置，通過配置模型輸出 Token 數量調節推理深度；二是動態工作流，由 Claude 編寫在虛擬機中運行的編排程序，動態調度數十至數千個子 AI Agent 協同解決問題，兩者在機制與適用場景上存在本質差異。

此外他表示，Fable 編寫的代碼與前端設計已超過他本人水平，但在產品感以及分布式系統設計方面仍有較大提升空間，預計年底前 AI 在這一領域將變得相當出色。

01

80 億 Token以及一部手機

今年你寫了多少行代碼，這些代碼是你自己寫的還是 Claude Code 寫的？現在寫代碼主要用手機還是筆記本電腦？

Boris Cherny：為了準備這次訪談我特意查了數據。我大概提交了 1700 個 PR，增加了 40 萬行代碼，刪除了 25 萬行代碼。去年我刪掉的代碼比增加的還要多，今年增加的略多一些。我也試著統計了 Token 消耗量，遺憾的是由于數據保留期限等原因部分數據已被清理，但僅從今年 3 月份算起，我已經消耗了 80 億個 Token。

自從 Opus 4.5 模型發布以來，我 100% 的代碼都是由 Claude Code 編寫的。

至于在哪里寫代碼，如果是半年前你問我，我絕對想不到現在的答案。現在我大部分代碼都是在手機上寫的。半年前要是有人這么跟我說，我肯定覺得他瘋了，但現在事實確實如此。

公司應該如何在性能更強但成本更高的模型與必須證明 Token 效率之間取得平衡？

Boris Cherny：我每天都能和許多作為我們客戶和潛在客戶的公司交流。總的來說大家的關注點分為兩類，有些公司看重成本，有些則看重 ROI。從 ROI 的角度思考絕對是正確的框架，因為不能只盯著成本看，所有的投入最終都是為了獲得回報。在考慮 ROI 和整體部署 Claude Code 時，思考如何進行高質量部署非常有價值。

我認為最成功的公司會向所有人發放 Token，不僅僅是工程師，還包括產品經理、設計師和數據科學家。他們讓所有人都有機會使用并鼓勵全公司進行探索，因為好主意往往來自你意想不到的人。很多時候改進流程或開發新產品的絕佳創意可能來自于公司某個角落的會計，或是 CEO 從未聽說過的營銷人員。這就是很多創新想法的源泉，它不一定總是出自最資深的工程師之手。

因此需要鼓勵公司和團隊大膽嘗試。最好的方法就是給大家發放 Token 并提供一個安全的試錯環境，讓他們可以放心大膽去嘗試，不用擔心因為試錯受到懲罰。一旦發現了行之有效的內部應用場景，再去考慮如何控制成本，而這種控制應該在后端進行而不是前端。如果某個應用場景大受歡迎且消耗了大量 Token，你就可以考慮如何進行優化。其實有很多方法可以做到這一點，在 Claude Code 中我們提供了基于席位的成本控制，你還可以使用顧問模型，或者為整個公司更換模型，控制整體的工作量上限，甚至可以根據部門或基于角色的訪問控制來設定預算。控制成本的方法非常多。

第二種思考方式是在部署初期如何將工具推廣開來。當公司使用 Claude Code 一段時間后就必須開始認真考慮 ROI 了。ROI 包含投入和回報兩部分。在過去投入很容易衡量，就是 Token 的消耗量。而對于回報，我們以前通常看 AI 編寫代碼的比例或是代碼行數的增長百分比等。但剛才我們看到很多人舉手表示他們 100% 的代碼都是 AI 寫的。當這個比例達到 100% 時你又該如何衡量回報呢？

這就是難題所在。以前做 Dev Infra 時如果一年的生產力能提升 2% 到 3% 就已經非常了不起了。但現在我們看到的是成百上千倍的生產力提升。在 Anthropic，從今年年初開始我們看到每位工程師的代碼產出量增長了 8 倍。在這種情況下我們該如何看待回報？我認為首先要實現 100% 的代碼由 Claude 編寫，然后觀察人均代碼量的提升幅度，最后要思考的是還有哪些瓶頸阻礙了發展。因為當工程師能夠快速產出大量代碼時，瓶頸就會變成好點子。所以如何打破這些瓶頸讓公司能更快地孕育出好想法？這可能意味著需要引入更多的產品經理或用戶研究員。緊接著還需要思考如何將這些想法更快地推向市場。這需要在市場推廣和營銷端打破瓶頸。這就是我思考這些問題的基本順序。當我觀察客戶時發現每家公司都處于這條采用曲線的不同階段。

02

Loops是否是炒作

Loops 是下一個炒作周期，還是真實存在的趨勢？能先解釋一下什么是 Loops，以及你自己平時是如何使用它的？

Boris Cherny：對于在座的工程師來說，兩年前我們還是手動編寫源代碼。后來我們開始向 AI Agent 寫代碼過渡，而現在我們正朝著 AI Agent 提示 AI Agent 來編寫代碼的階段邁進。從更技術的角度來看，如果源代碼是最基礎的層面，相當于編程中的一個語句，那么編寫代碼的 AI Agent 就像是編程中的一個函數，而 Loops 就是高階函數。這就是抽象層級的不斷提升，它又向上邁進了一步。就像從源代碼到 AI Agent 是一次巨大的飛躍一樣，從 AI Agent 到 Loops 的演進也是同等重要且規模相當的一大步。

對我來說現在的 Loops 領域就像是一年半以前的 AI Agent 領域一樣。雖然尚處于早期階段，但我們已經初步看到了它的成效。舉個例子，假設作為一名工程師，我的很大一部分工作是進行代碼審查。我可以選擇手動審查，也可以設置一個 AI Agent 通過提示讓它幫我審查。而 Loops 版本的做法是，我讓一個 AI Agent 在循環中持續運行，包攬所有的代碼審查工作。再舉個例子，我會閱讀 Threads 上的用戶反饋。我可以自己手動看，也可以讓 AI Agent 幫我看，或者我可以設置一個不斷循環的 AI Agent，每隔五到十分鐘讀取一次反饋并自動提交修復問題的 PR。一年半以前我們還在第一階段。現在我們已經邁入了第三階段。當你思考工程師的日常工作以及設計師、數據科學家、營銷人員等非技術人員的工作時，我覺得很多任務都可以被拆解成這樣的 Loops。我認為目前的行業趨勢是，越來越多的代碼和工作將被轉化為 Loops 的形式。就我個人而言，在普通的工作日里我大概有 30% 的代碼是通過 Loops 生成的。如果我刻意嘗試，某些天甚至能達到 100%，但這還需要一個適應過程。

03

Cowork 定位是與 Claude Code 同一底層架構的產品

Anthropic 最近在 Cowork 上投入了大量精力，能否告訴大家為什么應該嘗試使用 Cowork？你最興奮的一些應用場景有哪些，特別是在非編碼領域？

Boris Cherny：試用 Cowork 的方法很簡單，只需要下載 Claude 桌面應用即可。也就是包含了聊天功能和 Claude Code 的同一個應用，它里面也集成了 Cowork。你只需下載就能直接使用，支持 macOS 和 Windows 系統。簡單來說，Cowork 就是為非工程師準備的 Claude Code。它的底層邏輯依然是 Claude Code，并且同樣使用了構建 Claude Code 的 Claude AI Agent SDK。基礎架構是一樣的，你甚至可以自己在這個 SDK 上進行構建。它們完全是同一套東西。

我們之所以說它是為非工程師準備的，是因為里面內置了更多的安全護欄。Cowork 擁有一個完整的虛擬機，具備相當復雜的隔離機制。我們接入了操作系統以防你誤刪重要文件。它還在防范提示詞注入方面做了大量保護，并通過種種設計最大限度地避免用戶誤操作帶來的損失。

說到我自己怎么用 Cowork，其實除了寫代碼，我把它用在了所有非技術工作上。舉個項目管理的例子。以前我們每天早上都要開站會，大家挨個匯報各自的工作進展。現在我利用 Cowork 在瀏覽器里打開一個電子表格，里面記錄了本周所有的工作流。它會自動幫我在 Slack 上給每一位工程師發消息詢問最新進展。有趣的是通常是工程師們的 Claude 代替他們回復。這就變成了 Claude 之間在對話。有時工程師也會親自回復，Cowork 讀取這些信息后會自動更新到表格的進度欄里。這一切都是 Cowork 完成的，完全不需要你進行繁雜的設置。你只需要擁有 Cowork 和 Claude 的 Google Chrome 瀏覽器插件，它們就會自動協同工作。這就是組合工具帶來的奇妙化學反應。我認為當人們使用 Cowork 時，最能讓他們感到驚艷的神奇時刻就在于此，這東西居然能用我的工具，還能像我一樣把所有工具組合起來協同工作！這種感覺太不可思議了，就像第一次使用 AI 聊天應用一樣，絕對是一種啟示。

還有一種更高級的用法。我以前會讓 Cowork 幫我預訂所有的行程。我會對它說這是我的行程安排，我需要哪天到這里哪天到那里，你能幫我把機票定了嗎？同樣它會打開瀏覽器進入我們在 Anthropic 用來預訂行程的旅游網站，自動填寫信息并預訂機票。現在我把這個流程進一步自動化了。現在的 Cowork 包含一個定時任務，它每天都會查看我的郵件，并檢查我在 Google 日歷上接受的所有活動邀請。如果活動地點不在舊金山，它就會去自動幫我預訂機票。預訂好后會把信息發送給我。不僅是機票，它還知道預訂酒店，甚至掌握了我對航班和酒店的所有偏好設置，然后自動完成所有操作。我前段時間參加了多個跨城市的活動，所有的多段往返機票和酒店住宿全是它自動幫我訂好的，我全程根本不需要操心，完全沒有干預，它直接從我的郵件里提取信息并在我確認后完成了預訂。

04

Fable、模型選擇

你是如何根據不同的軟件工程應用場景來選擇不同模型的？Fable 在編程方面的表現如何？

Boris Cherny：關于 Fable 在編程方面的表現，可以回溯到去年 11 月，當時所有人都在感嘆模型在編程方面變得多么強大，那正是 Opus 4.5 發布的時刻。從上一代模型到 Opus 4.5 的能力跨度極大，很多人第一次開始完全依賴 Claude 來編寫所有的代碼。對我個人而言，那是我決定卸載 IDE 的時刻，因為我不再需要它了。那是 Claude 開始接管所有編碼工作的轉折點。

從 Opus 4.8 到 Fable 的技術跨越給我感覺至少與那次同樣震撼，這可能是模型能力上一次更為巨大的飛躍。Fable 具備對細節的洞察力和多維度的思考方式，這種思維模式與我身邊最聰明的同事非常相似。它不再像以前的模型那樣只是一個不懂變通的生硬工具，它真正具備了深入剖析和解決問題的能力。這種能力在數據分析等諸多場景中都極具價值，數據背后隱藏著許多微妙之處，你必須連續追問多次為什么才能觸及問題的本質，Fable 自然而然就能做到這一點。它在代碼調試中也大顯身手，調試需要你先建立假設，然后順藤摸瓜尋找證據，Fable 能夠出色地完成這些任務。至于編程，我感覺自己已經把所有的難題都拋給它了，實在想不出更難的問題。我交給它的每一個挑戰，它基本上都能做到單樣本解決，或者只需要提供少量提示詞就能通過少樣本的方式搞定。我已經沒有難題可以難倒它了，我們團隊里很多人也有同感，這確實是一次巨大的跨越。

不僅是 Claude Code，Cowork 也是如此，Anthropic 越來越多的產品都是這樣。放眼整個 Anthropic，平均有 80% 到 90% 的代碼是由 Claude Code 編寫的，對于越來越多的內部團隊來說這個比例已經達到了 100%。

關于模型選擇，我用 Fable 處理所有事情。

是因為 Anthropic 沒有預算限制嗎？

Boris Cherny：在 Anthropic 我們確實會考慮 Token 的使用量。雖然我們本身就是 Token 的生產者，但它們對我們來說也不是免費的，因為我們每消耗一個 Token 就意味著無法將這個 Token 提供給客戶，這其中存在機會成本。當我考慮這個問題時核心其實還是投資回報率。考慮到 Fable 帶來的投資回報率，你可以通過結合顧問模型來使用 Fable，或者默認使用 Opus 并在需要時再調用 Fable，這樣也許能減少 50% 的投入。我們有各種方法來優化資源的使用率，隨著新模型的推出你需要持續調整這些優化策略。要跟上這種節奏實際上需要做大量的工作。你必須運行評估來確保系統運作良好，盡管你可以使用顧問模型，這也是我們推薦的開箱即用的方法。

實際上我認為從投資回報率的角度來看，雖然你可能有 50% 的機會降低投入，但你同時也面臨著一千倍、一萬倍甚至十萬倍提升回報的機會。因此我的思路是直接使用最昂貴的模型，然后專注于思考如何從中挖掘更大的價值以最大化收益。不要把眼光局限在削減成本上，這項技術的普及還處于非常早期的階段，現在過多糾結成本為時尚早。你可以花些精力優化成本，也必須確保預算可控且治理完善，但我建議將絕大部分精力投入到提升產出回報上。當前技術帶來的上升潛力遠遠超過了削減成本所能省下的那點空間。

05

團隊協作瓶頸、工程師角色轉型

Claude Code 在優化團隊協作方面采取了哪些舉措？目前它給人感覺像是一款單機工作產品，只能依賴 GitHub 這類工具與他人合作。既然 AI Agent 現在已經能包攬大部分的編碼工作，工程師應該把精力集中在哪里？

Boris Cherny：關于團隊協作，我們目前正在緊鑼密鼓地研發一系列新功能，希望很快能帶來好消息。在此期間我的建議是利用模型上下文協議 MCP 將 Claude Code 接入到 Slack、Teams、Google Chat 或正在使用的任何協作平臺中。

關于工程師的精力方向，我們可以審視一下工程師的日常工作，寫代碼只是其中一部分，還要處理大量非編碼任務。比如與客戶溝通、構思創意、與設計師和產品經理碰撞想法、進行數據分析、規劃產品方向以及與其他部門協調對齊，工程師要做的事情不勝枚舉。隨著時間的推移，AI 未來能比我們更出色地完成所有這些任務，但目前還沒到那個階段。現階段 AI 負責編寫代碼，人類負責向 AI 下達指令。如何下達準確的提示指令大有學問，你需要明確下一步要做什么，進行市場調研并與團隊深入溝通。你必須完成所有外圍工作，焦點在于這些編碼之外的任務。

寫代碼占用的時間比例其實一直都是少數。有時親手敲代碼確實樂在其中，但有時卻像是艱難跋涉讓人不想手動去做。在我看來 Claude Code 就像是一個噴氣背包，隨著 AI 的不斷進化，我的背包里好像裝配了越來越多的推進器讓我飛得越來越快。到了現階段我唯一的瓶頸就是給出提示指令的速度，現在大部分指令下達都是通過語音直接跟 Claude 交流完成的。真正的瓶頸在于能否想出好點子，寫代碼本身已經不再是瓶頸了。

06

代碼審查、安全審查

隨著 AI 生成代碼的大爆發，代碼審查環節面臨巨大壓力，傳統的人工審查模式可能正在崩潰。Anthropic 是如何應對這些下游影響的？對你和團隊來說下一件具有顛覆意義的大事是什么，Claude Code 未來一年的發展藍圖是怎樣的？

Boris Cherny：編寫代碼的最終目的是將其部署到生產環境中，期望推動營收或活躍度等商業指標。回顧整個流程會發現存在各種瓶頸，過去最大的瓶頸無疑是寫代碼。如今我們已經跨過了這道坎，許多使用 Claude Code 的客戶也正邁入這個新階段，我們需要將目光投向下一個瓶頸。

下一個阻礙就是代碼審查，代碼產出海量增加總得有人審閱。我們的解法是打造一款專門應對此問題的產品，于是 Claude Code Review 應運而生。它對所有人開放，與 Anthropic 內部審查每一個代碼合并請求所使用的工具完全相同。它與市面上其他產品不同，因為它要昂貴得多，高昂的原因在于消耗了海量的 Token 來實現代碼審查的完全自動化。當我作為工程師打開一個合并請求時，基本可以確信所有的 Bug 已被排除。雖然無法做到 100% 完美，但它確實能攔截 98% 到 99% 的錯誤。當我審視代碼時不再充當找 Bug 的角色，因為 Claude 已經捕捉并修復了它們。我只需要關注核心問題，即這個合并請求有存在的必要嗎？這是一個好的設計方案嗎？

緊隨其后的瓶頸則是安全審查。大量代碼的合入必須以安全為前提，AI Agent 與人類一樣也會在無意間引入安全漏洞。確保代碼絕對安全的答案是 Claude Security，這同樣是我們為突破自身內部瓶頸而研發的利器。它的工作機制是每周定期運行，全面掃描所有的代碼庫，自主發現并修復安全隱患。我們每次發布重大新功能前都會進行紅藍對抗測試和滲透測試來確保系統安全。我們已經達到了這樣一個階段，Claude Security 甚至能捕捉到專業滲透測試人員漏掉的隱患。這款產品我們已經使用了一段時間，正是得益于 Opus 4.8 等模型能力的提升它才開始達到如此強悍的水平。這就是我們遭遇并攻克的又一個瓶頸。我們將這一能力開放給客戶，讓大家受益于同款安全產品，這就是 Claude Security。

如今我們在思考下一個瓶頸會出現在哪里，可能演變成如何高效地產出創意，也可能是如何進一步優化持續集成系統以實現更好的擴展性。舉個例子，我發現我們的持續集成跑得有些慢，于是啟動 Claude Code 并給出指令，要求使用工作流分析數據集，查看真實持續集成的耗時情況并進行提速優化。這就是我給它的完整提示詞，就這么多。它采用了一種動態工作流，這是我們幾周前剛發布的新特性，核心原理是讓 AI 動態協調和指揮幾十甚至幾千個子 AI Agent。這屬于一種全新形式的測試時計算技術。它大約消耗了幾百萬個 Token 并在后臺運行了幾個小時，直接生成了四個代碼合并請求，成功將持續集成時間縮短了一半。我隨后將這些代碼合并。放在過去要完成這些分析和優化恐怕得耗費幾周甚至幾個月的時間。這就是下一個需要突破的瓶頸，我們同樣可以用 Claude 來解決。

關于未來規劃，需要說明的是我們的規劃周期是以周或月為單位，根本沒有所謂的年度計劃。這個領域呈指數級發展的速度非常驚人，只能努力跟上節奏，每次只規劃眼前的一小步。從宏觀方向看我們未來的道路與過去一兩年相比并沒有偏離。目標始終是打造最強大的 AI Agent。我們希望打通所有工作場景邊界，無論團隊在什么平臺上工作 Claude 都能無縫融入。你不需要為了使用它而被迫遷移到我們的全棧生態中。此外我們致力于提供獨一無二的體驗，讓用戶能以其他產品無法實現的方式深度感受新 AI 帶來的能力。

我們幾年前就意識到 Sonnet 3.5 在代碼生成領域邁出了一大步，但市面上沒有太多產品能讓用戶淋漓盡致地體驗這種跨越。因此 Claude Code 應運而生，拋棄傳統的源代碼交互方式，只需直接使喚一個 AI Agent 即可，這就是感受其強大能力的最佳途徑。展望未來幾個月甚至一年的發展，它在處理長時間運行的復雜任務方面將變得更加得心應手。目前 Claude 在處理長時任務領域已具備極大優勢，這種領先還會繼續擴大。它生成的代碼將更加安全可靠、質量更高，同時在目標對齊方面也會做得更完美。無論作為使用者、工程師、產品經理還是設計師，無論意圖是什么，AI 都會更精準地替你表達和實現這些想法。我們將繼續深耕核心能力，不斷探索并打造優秀的產品，讓每個人都能輕松享受到技術躍遷帶來的紅利。

07

用 Loops 做代碼維護，算力投入設置、動態工作流

在大型項目中，編寫代碼并不是最大的難題，維護才是。代碼在長期內應該如何進行維護？工作流和 Loops 之間有什么區別？

Boris Cherny：我最近一直在嘗試的一個方法，實際上是利用 Loops 來進行代碼維護。舉個例子，你可以讓 Claude Code 在一個 Loop 中持續運行，讓它去審視代碼庫并優化架構，或者讓它在代碼庫中找出測試套件不穩定的部分并加以改進，以消除這些不穩定因素。你也可以讓它尋找出無用的測試用例并直接刪除，再或者讓它審視代碼庫，尋找重復的抽象邏輯并將它們統一為單一的抽象。實際上這些都是我目前正在運行的 Loop 任務。流程上我只需直接審查 PR，在 AI 做出更改后才去檢查結果。對于這類提示詞，Claude 其實很容易理解這類結構性的問題。只要使用的是最新模型，效果通常會非常好。如果生成結果不夠理想，只需要對它說尋找機會來提升代碼庫的質量，然后再補上一句指令：使用工作流。

我以為核心指令會是"絕對不能犯錯"。

Boris Cherny：我之前也以為那才是核心指令。或許那句也有用，但基本上只要說"使用工作流"，模型就會分配更多的測試時計算資源，從而提供一個顯著提升的結果。

關于工作流和 Loops 的區別，兩者區別相當大。AI 領域存在傳統的 Scaling Law，之前有一篇關于 Scaling Law 的論文提出了一個觀點，即 Transformer 以及大語言模型的能力擴展方式，本質上是數據量、神經網絡規模以及用于訓練網絡的計算量的函數。這是模型能力呈指數級增長的內在屬性。正是由于這三個擴展因子的存在，AI 的智能水平才得以持續呈指數級爆發。

在過去幾年中，我們引入了第四個關鍵因子，即測試時計算。從本質上講，測試時計算只是一種學術說法，用來描述模型在推理階段生成了多少個 Token。我們可以通過一些機制，讓模型高效地生成更多的 Token，從而實現更優的輸出結果。目前有幾種方法可以做到這一點。第一種是算力投入設置。在 Claude 模型中，包含低投入、中等、高投入、超高投入以及最大投入等選項。這本質上是一種配置方式，用于設定希望模型輸出的 Token 數量，以此來調節測試時計算的行為，Token 越多，結果越好。我們剛剛引入的第二種方法則是動態工作流。它主要是利用 Claude 編寫一個在虛擬機中實際運行的小程序，并由它來編排其他 Claude 模型協同解決問題。這是我們目前仍在探索的一種測試時計算的新形式，本質上是讓 Claude 啟動數十、數百甚至上千個 AI Agent 來完成工作。

08

Fable 的兩塊短板

Fable 目前有哪些難以解決的難題？

Boris Cherny：我們的模型并非完美無缺，在很多方面仍需改進。其中之一就是產品感。目前我能構思出的產品創意依然優于 Fable，在創意生成方面它還沒達到理想的高度。

另一個領域是分布式系統設計。盡管 Fable 現在編寫的代碼已經比我寫的更好，前端設計也比我的設計出色，但在分布式系統設計方面我仍然遠勝于 Fable。比如梳理需要哪些服務、如何組織架構、數據如何流動、如何考量負載因素等。在這一領域 Fable 還有很大的提升空間。我不太喜歡做具體的預測，但估計大概到今年年底，AI 在這方面就會變得相當出色。

09

人工審批反而降低安全性

如何防止工程師變得懶惰并全盤接受 Claude 輸出的所有內容？

Boris Cherny：這個問題包含兩個層面。

第一部分是如何確保模型輸出的質量足夠高，并且工程師都在進行正確的操作。我們的思路是如何讓 Claude 替工程師做正確的事，從而讓人無需親自去操心。舉個例子，從一開始我們就為 Claude Code 設定了權限提示詞。任何時候只要 Claude 想要在電腦上執行命令，它都會詢問是否允許。比如詢問是否可以運行特定的 bash 命令，是否可以使用 MCP，或者是否可以在瀏覽器中抓取特定 URL。工程師必須坐在那里進行批準或拒絕。

但我們發現隨著時間推移，人會變得越來越懶。就我而言，后來只是在機械地點擊同意，根本沒有認真閱讀那些命令。我們的安全團隊注意到了這個現象，他們指出，雖然在流程中引入人工干預的初衷是為了提高安全性，但實際上卻在損害安全性。因為人們出現了提示詞疲勞，不看細節就直接通過。這一痛點促使我們開發了自動模式，這是 Claude Code 中的一種全新權限模式。Anthropic 內部正在使用它，目前絕大多數用戶也都在使用。它的工作原理是將每一個權限請求路由給一個專屬模型，由該模型根據對話上下文中的交流內容，自動判斷是批準還是拒絕。

這不僅大幅提升了安全性，數據表明，由于消除了提示詞疲勞，自動模式的安全性不僅優于危險模式，也優于默認的人工權限模式，更重要的是它切實為工程師減負了。它成功解鎖了讓 AI Agent 長時間運行的能力，因為工程師再也不用盯著屏幕進行人工審批。這意味著現在可以讓 Claude 連續運行幾個小時甚至幾天。各項基準測試也證明，Claude 在處理這類長時間運行的任務方面是業界頂尖的。自動模式的成功落地背后是多年的研究支撐。仔細研究 Claude 模型會發現，它們基本上已經不再容易受到提示詞注入的攻擊。如果查閱系統卡片，模型在 100 次攻擊嘗試中的成功率僅約為 1%，這絕對是業內最優水平。將這一優勢與目前大規模部署的提示詞注入分類器結合使用時，模型本質上已經對這類攻擊免疫了。這正是我們能夠自信推出自動模式的底氣，意味著作為工程師，無需再守在電腦前審批權限。這就是對問題第一部分的解答，放手讓 Claude 去做更多的事情，研究如何安全地為 Claude 解綁，而不是試圖通過人工去微觀控制它。

關于第二部分，當工程師不再親自編寫代碼時，日常的感受是怎樣的？該如何保持學習并讓自己不脫節？我發現 Claude Code 中的輸出風格功能對此非常有效。每當有新工程師加入團隊，我們都會讓他們使用探索式輸出風格。只需在 Claude Code 中配置此項，或者直接讓 Claude 協助設置。它的作用是，每當 Claude 做出更改時，都會主動向工程師解釋當前的架構是如何運作的，如果以前沒用過這種語言，它會講解該語言的機制，還會拆解代碼庫各部分的原理。它通過詳盡的解釋來輔助學習。此外還有一種教學式輸出風格，這主要是為非程序員準備的。它會在非常基礎的層面講解某種語言的運作方式，不會直接替用戶修改代碼，而是手把手教導如何去實現。比如它會解釋在 JavaScript 中某個功能的原理，并引導用戶一步步操作，從打開文件修改，到運行命令，再到執行后續操作。因此合理利用輸出風格并高頻度地使用 Claude，是一個極其強大的學習工具。它能幫助有經驗的工程師在技術棧和基礎設施發生迭代時，尤其是在接觸全新編程語言時，依然能清晰地掌控全局。

| 文章來源：數字開物

【AI技術與應用交流群｜僅限受邀加入】

AI算力領域TOP級從業者專屬圈層

√ 與頭部算力企業深度對話

√ 與AI上下游企業深度對話

√ 獲取一手全球AI與算力產業信息

√ 獲取AI熱點及前沿產業獨家信息

√ 隨時了解全球AI領域高管最新觀點及實錄全文

√ 有機會參與AI主題產業交流活動

掃碼驗證身份（需備注姓名/公司/職務

不止有 DeepSeek，更有 AI產業的未來！

? END ?

【專欄】精品再讀