最終我們要教模型的，和我們教孩子的是同一件事。

文章作者、來源：機器之心

很多人說，在 AI 時代，品味是人類最後的護城河。但 Boris Cherny 不這麼認為。

他是 Anthropic 的技術成員，也是 Claude Code 的核心建設者之一。他每天都在使用模型編寫代碼，並用模型研究模型。而他觀察到的趨勢是：所謂「品味」，也正在被模型快速學會。

如果連「該做什麼」都能被模型掌握，那人類還剩下什麼？

在最近的一次訪談中，Boris 聊到了這個話題。

Claude Code 如何根本性地改變公司的體系；

當模型能夠撰寫絕大部分程式碼後，工程師還值得招聘嗎？如果值得，那要看什麼？

為何 Anthropic 內部很多人都是 Member of Technical Staff，沒有明確的職級和分工？

給所有創業者的一個反直覺建議：為何是「少招人，多給 token」？

……

這些問題表面上是關於一個產品的誕生與迭代，但每一層的答案，都在指向同一個更根本的變化：組織的運作方式，正在被模型本身重新定義。

而 Boris 給出的答案，非常值得冷靜思考。

Claude Code 是如何誕生的？

當主持人問起 Boris Claude Code 的起源時，他給出的答案有些出人意料。

在他的講述中，Claude Code 並不是 Anthropic 從一開始就規劃的核心產品，甚至某種程度上可以說是意外的產物。

在 2024 年底，Boris 加入了 Anthropic 的 Labs Team。這個團隊的職責不是維護現有產品，而是探索未來產品的形態。一方面，他們需要不斷推動模型能力的邊界；另一方面，他們也在尋找能夠真正釋放這些能力的新產品。

當時團隊有一種非常強烈的感受：模型已經具備了遠超現有產品的能力，但市場上還沒有出現能夠充分利用這些能力的產品。在編程領域尤其如此。

當時市面上的 AI 編程工具大多還停留在兩個方向。一個方向是自動補全，幫助開發者完成下一行代碼；另一個方向是問答助手，開發者可以詢問某段代碼的含義或者某個報錯的解決方案。但 Boris 認為，當時還沒有真正意義上的 Coding Agent。

於是團隊決定做一次更激進的嘗試：不再把模型當作輔助工具，而是直接將其變為開發主體。他們想看看，如果從零開始構建一個完全圍繞 Agent 展開的編程產品，會發生什麼。

不過 Boris 也坦率地承認，最初的 Claude Code 並不很好用。

在很長一段時間裡，它只能完成他大約 10% 到 20% 的工作。大部分程式碼仍然需要他親自編寫。今天人們看到的 Claude Code 與那個時期的產品相比，已經完全不是同一個東西。

為什麼 Anthropic 會如此重視 Coding？

很多人會認為 Anthropic 重視 Coding 的原因很簡單——編程市場足夠大，商業價值足夠高。但 Boris 給出的解釋完全不同。

他說，如果你在 Anthropic 的辦公室裡隨機攔下一名員工，問他為什麼來到這裡，大概率得到的答案都會是同一個：AI Safety。

在 Boris 看來，Anthropic 從成立之初最核心的使命一直是 AI 安全。無論是可解釋性研究、對齊研究還是其他各種安全方向，本質上都在試圖理解模型的行為。但這些研究最終都面臨同一個問題：僅僅在實驗室裡觀察模型是不夠的，研究者還必須觀察模型進入真實世界之後會發生什麼。

而 Coding 恰好是一個近乎理想的實驗場。

與寫作、繪畫或其他開放性任務不同，編程具有極其清晰的反饋機制。代碼能否運行、程序能否通過測試、編譯能否成功或失敗，答案往往非常明確。同時，互聯網提供了海量代碼作為訓練數據。與詩歌創作這種可能存在無數優秀答案的任務相比，編程問題的正確解空間要收斂得多，因此也更容易驗證模型能力。

正因如此，Anthropic 從很早開始就高度關注 Coding、Tool Use 和 Computer Use。這些方向不僅具有商業價值，更重要的是，它們為研究模型如何與真實世界互動提供了一個天然的實驗環境。

從這個角度來看，Claude Code 從來不只是面向程式設計師的生產力工具。在 Boris 的敘述中，它同時也是 Anthropic 用來理解未來 AI 系統的重要實驗平台。

為什麼 Claude Code 突然變強了？

在介紹完 Claude Code 的起源之後，主持人提出了一個很多人都想知道的問題。既然 Claude Code 剛誕生的時候只能完成 Boris 大約 10% 到 20% 的工作，那麼後來究竟發生了什麼？畢竟今天 Boris 已經公開表示，自己已經有半年時間沒有親手寫過代碼了。從只能完成一小部分任務，到幾乎完全接管開發工作，中間顯然發生了巨大的變化。

對於這個問題，Boris 的回答反而異常簡單。他說，外界往往會把注意力放在產品功能上，但如果讓他回顧那些真正帶來能力躍遷的時刻，最重要的原因其實只有一個：模型變強了。

在過去一年裡，Anthropic 團隊確實持續改進 Claude Code 本身。他們進行了大量工程工作，增加了各種新的互動方式和產品形態。最初 Claude Code 只是一個命令列工具，後來逐漸擴展到桌面端、行動端、Slack、GitHub 等不同場景。團隊也不斷嘗試新功能，例如規劃模式（Plan Mode）等各種協助開發者與 Agent 協作的機制。但在 Boris 看來，這些都屬於增量改進。

真正決定 Claude Code 上限的，是底層模型本身。

他提到了幾個關鍵節點。從 Sonnet 4、Opus 4，到後來的 Opus 4.5，每一次模型能力提升，都會直接反映在 Claude Code 的表現上。

主持人隨後問到，使用 Claude Code 的經驗是否會反過來影響模型研發。Boris 的回答是，Anthropic 內部幾乎所有人每天都在使用 Claude Code，包括研發模型的人、開發產品的人…… 整個公司都在用。

因此並不存在一條專門的反饋通道。反饋本身就是公司日常工作的一部分。

研究人員在使用過程中發現問題，模型團隊就會看到這些問題；模型能力提升之後，大家又會立刻在實際工作中感受到變化。產品和模型並不是兩條平行的線，而是在同一個循環裡共同演化。

Claude Code 為 Anthropic 帶來了多少生產力提升？

Boris 表示，在 AI 實驗室工作久了以後，大家會習慣以指數增長的方式思考問題。許多內部指標——無論是收入、使用量還是模型能力——看起來都更像指數曲線，因此他們甚至習慣使用對數座標來觀察變化。

而代碼產出也呈現出類似趨勢。

根據 Anthropic 曾經公開披露的數據，自 Claude Code 在公司內部廣泛使用以來，每位工程師產出的程式碼量增長了大約 3 倍。但 Boris 特別強調，這已是過時的數據，實際增長遠遠超過這個數字。

更有意思的是，這種增長發生在公司規模快速擴張的過程中。

根據傳統經驗，一家公司的工程師人數越多，平均生產力往往越低。新人需要學習系統，資深員工需要回答問題，組織溝通成本會不斷上升。

但 Boris 觀察到的情況恰好相反。過去，一名新工程師加入公司，可能需要數週時間才能真正熟悉內部系統；現在這個過程往往只需兩天。

原因並非培訓體系發生了革命性的變化，而是因為大家已經習慣直接詢問 Claude。新人不需要知道如何查詢資料庫，甚至不需要知道該向誰請教。在 Anthropic 內部，當有人問「資料庫怎麼查」時，常得到的回答是：「打開 Claude，讓 Claude 去查資料庫。」許多原本需要資深工程師掌握的隱性知識，開始轉移到 Agent 身上。在 Boris 看來，這或許才是最重要的變化。

Claude Code 提升的並不僅僅是程式碼生成速度，而是在逐漸壓縮組織內部知識傳遞的成本。過去企業依賴層層傳幫帶來完成知識流動。而現在，越來越多知識正在被直接封裝進模型。

從打孔紙帶到 Vibe Coding，人類只是再次提升了程式設計的抽象層級

既然 Claude Code 如此強大，Anthropic 新招聘的工程師還需要寫代碼嗎？當主持人提出這個問題後，討論的焦點隨即轉向：你如何定義「寫代碼」？

In Boris's view, the history of software engineering is essentially a history of continuously raising the level of abstraction.

他的祖父在蘇聯時代使用穿孔卡編程。那個時代，程式設計師需要在紙卡上打孔，再將紙卡送入電腦等待結果。後來出現了組合語言。再後來出現了 Fortran、Cobol。然後是 Java、Python、JavaScript。每一次抽象層級的提升，都會有人認為：這已經不是真正的編程了。寫組合語言的人會看不起寫高階語言的人，寫 C 的人會覺得 Python 太簡單。而 Boris 認為，今天發生的事情本質上沒有區別。人類只是再次提升了編程的抽象層級。

他描述了自己過去一年工作方式的變化。最開始的時候，他和大多數開發者一樣：打開 IDE、編寫代碼、偶爾使用自動補全，這是傳統的軟體開發方式。

後來 Claude Code 出現之後，他的工作方式變成了：向 Claude 描述需求、讓 Claude 寫代碼、自己負責檢查和修正。在這個階段，人依然在直接指揮模型，只是代碼由模型生成。但 Boris 認為，這其實只是一個過渡階段。

最近出現了真正有趣的變化。他說：「現在我甚至不再直接提示 Claude 了。」他的工作已經變成了另一種形式。他會編寫各種自動運行的流程和迴圈。這些迴圈負責向 Claude 提出問題、拆解任務、管理上下文，以及協調多個 Claude 實例之間的工作。

換句話說：過去是人向 Claude 下達指令，現在則是程式為他向 Claude 下達指令，而他的工作變成了設計這些自動運行的系統。他用一句非常簡潔的話概括：我的工作已經變成寫 Loops。

看來，Boris 不只是把程式碼外包給 Claude，而是在將「與 Claude 溝通」這件事本身也自動化。這已不再是大家熟悉的 Copilot 模式，更接近於一個由多個 Agent 持續運行的系統。

Boris 提到，去年十一月時，他甚至卸載了自己的 IDE。這並非一種象徵性的表態，而是因為他發現自己已經一個月沒有打開過 IDE。既然完全不用，自然就卸載了。那段时间裡，他通常同時運行五到十個 Claude 實例，不同的 Claude 負責不同任務，而他主要負責監督整個過程。

工程師不寫程式了，招聘看什麼？

這時主持人提出了一個有趣的問題：如果今天一名工程師想加入 Anthropic，Anthropic 會如何評估他？或者說：在一個越來越少親自寫代碼的世界裡，公司究竟在尋找什麼樣的人？

Boris 的回答幾乎直接引出了後面關於組織形態的討論。他說，Claude Code 團隊最喜歡的一類人其實是：Generalist（通才）。

原因很簡單：過去的軟體組織有著非常明確的分工——用戶研究員負責理解用戶，設計師負責設計產品，產品經理負責規劃需求，工程師負責實現功能，每個人都在自己的環節裡工作，像一條流水線。

但 Claude Code 團隊在過去半年發現，這種分工正在迅速瓦解。團隊中的每一位工程師，幾乎每天都在做各種原本不屬於「工程師」職責範圍的事。有人直接與用戶溝通，有人在設計互動，有人在拉取數據、進行數據分析、搭建儀表板。沒有人只專注於一個狹窄的環節。

Boris 更舉了一個極端的例子：Anthropic 的設計師也在寫代碼，財務同事也在寫代碼。Satya Nadella 將這種角色稱為「Builder」。這個說法可能比「工程師」更準確，因為真正的界線已不再是「你會不會寫代碼」，而是「你能不能把一件事從想法變成現實」。

從 Boris 的角度看，AI 並沒有簡單地取代程式設計師，它真正改變的是知識與執行之間的關係。過去一個人之所以無法同時承擔多個角色，很大程度上是因為學習成本過高。而現在，模型正不斷降低這些能力之間的遷移成本。因此，未來最有優勢的人，未必是某個領域最深的專家，而可能是那些能夠快速跨越不同領域、不斷整合資源的人。

這也是為什麼 Boris 認為：我們正進入一個屬於 Generalist 的黃金時代。對於那些願意做很多事情的人來說，現在可能是歷史上最好的時代。

Member of Technical Staff 不是噱頭，是對未來的預演

主持人將話題從產品轉向文化和組織設計。他注意到，Boris 的頭銜並非「產品總監」或「工程總監」，而是 Member of Technical Staff，而且 Anthropic 的很多人都是這個頭銜。他想知道：這有什麼好處？有沒有壞處？

Boris 非常坦誠。他說最糟糕的一點是：你在 Slack 上給人發消息，對方的頭銜是 MTS，你根本不知道他是設計師、工程師還是經理，也不知道他到底在做什麼項目。但他非常喜歡這個頭銜。

他回憶起在 Meta 的經歷。Meta 的所有軟體工程師都只有一個頭銜：Software Engineer，沒有 senior、principal 這種等級。一開始他不太理解，後來發現這其實是一種文化上的設計。如果你給人一個「高級」的頭銜，別人會因為 deference（禮貌性服從）而不好意思反駁他的壞主意。而把所有人放在一個看上去平等的場域裡，反而會迫使大家用想法本身去競爭，而不是用資歷。

當然，他承認，等級並不會因為頭銜消失而真的消失。你知道某人是 L7，只是頭銜沒寫出來。但有意思的是，很多時候你真的不知道。

他講了一個自己在 Facebook 做 L4 工程師時的故事。他有了一個想法，直接去找了負責 connectivity 的 VP，說：這是我的想法，我們一起做吧。那個 VP 根本不知道他是什麼級別。他又去找了另一個 VP，又失敗了。第三次，成功了。他們組了團隊，開始做產品。

Boris 說，現在他在 Claude Code 團隊裡每天都在看到同樣的事。那些有 20 年、30 年經驗的資深工程師，反而要花好幾個月「unlearn」—— 放棄那些已經不再適用的舊習慣。而一個新畢業的大學生加入團隊，反而能教他怎麼更好地用 Claude Code，因為年輕人天然就用模型思維去思考。

每次新模型推出，所有人都需要重新校準。經驗在這個時代不是線性累積的，有時甚至是負債。

因此，在 Boris 看來，「Member of Technical Staff」這個看似模糊的頭銜，正是對即將到來的現實的預演：到年底，工程師、PM、設計師和用戶研究員之間的界限將基本消失。與其被動接受這一變化，不如透過頭銜主動將所有人推向同一個角色：Builder。

給所有創始人的建議：少招人，多發 tokens

主持人請 Boris 從 Anthropic 的角度，向在場的創始人和公司提供一個更通用的建議：在 2026 年底之前，組織應如何調整心態？

Boris 的第一句話就帶有笑點：「給所有人盡可能多的 tokens。」就像黃仁勳那句著名的話：「你買得越多，省得越多。」

這不是玩笑。他是認真的。他提出的具體建議有兩件事：

首先，盡量多提供 tokens，讓大家瘋狂實驗。

第二，每個項目都故意「少給一點人」。如果你覺得一個項目需要四個工程師，就只派兩個人上去，然後給他們大量 token，讓他們自己想辦法。你會發現，他們極有可能真的能做到。他們會把所有能自動化的事情全部自動化，而且因為自動化了，下次再做會更快、更便宜。這是一個複利效應。

主持人對這個建議做了一個非常精煉的總結：用更少的人，把預算從人工薪資轉移到 tokens 上。這會提高你的 upfront cost（前期成本），但會大幅降低 ongoing cost（持續成本）。就像 pre‑compiling 一樣——你一次性把髒活累活做完了，後面每一次重複執行都幾乎免費。

Boris 表示完全同意。主持人接著問了一個更尖銳的問題：過去人們非常以自己的 discipline（專業領域）為傲。PM 以自己寫的產品文章為傲，設計師以自己精美的作品集為傲。難道在 12 個月內，所有人都要放棄「我是某某某」這種身份認同，變成一個「靈活的、會消耗 tokens 的袋子」嗎？

Boris 說：「我可能會用稍微不同的措辭，但……對的，差不多就是這樣。」

品味也會被模型侵蝕？最終剩下的只有「價值觀」

主持人提到之前曾與 Anthropic 的另一位成員 Jared 討論過這個話題，想聽聽 Boris 的看法：你們如何理解「taste」（品味）？

Boris 的回答非常坦誠。他說，每一次他覺得自己在編程這件事上有什麼「特殊的品味」時，最後都被證明是錯的。

他曾經非常喜愛函數式編程，喜歡 Haskell、Scala 這類語言。在 Claude Code 的早期程式碼庫中，他定下了一條規矩：不准使用 class，只能使用 function。週末工程師們偷偷提交帶有 class 的程式碼，週一被他 reject 掉。後來模型開始大規模撰寫程式碼，模型直接寫出 class。他看了半天，最後說：好吧，也許模型是對的。我的這個執念可能本來就沒有什麼意義，業務成果達到了，而且更快，程式碼也不差。

然後他做了一個更大膽的推演。現在大家總說「產品品味是最後的 alpha」。但他認為，這種 alpha 也在快速消失。

他現在已經有數百個 Claude 實例在同時運行。有些在刷 Twitter 反饋，有些在查看 GitHub issues，有些在查看 Slack，然後自行分析下一階段應該開發什麼功能。目前大部分想法還是不好的，大約 20% 是好的。但等到下一個模型，再等 3 到 6 個月——大部分想法可能會都是好的。

主持人追問：那人類最終還有什麼獨特的東西？有沒有什麼東西是模型永遠做不到的？

Boris 想了一下，說：價值觀。

他說，我們最終要教模型的，和我們教孩子的是一回事：如何成為一個好的存在，如何做對的事情，而不僅僅是把事情做對。