“軟件工程師”頭銜要沒了？Claude Code之父YC訪談：一個月后不再用plan mode，多Agent開始自己組隊干活

作者 ｜ 木子

“我們會開始看到 “軟件工程師”這個頭銜慢慢消失。可能會變成builder、product manager，或者頭銜還保留，但只是一個遺留符號。
因為大家做的工作不再只是寫代碼：軟件工程師還會寫 spec、還會跟用戶溝通。”

放出這話的，正是Claude Code的創始人Boris Cherny。

他最近在Y Combinator的一場圓桌訪談中，一人對陣四位 YC 高管，幾乎句句都帶著點“重錘感”。

在他看來，編程正在被“解決”。在 Anthropic，很多人已經 70%–100% 用 Claude 寫代碼，IDE 的存在感正在下降。寫代碼這件事，正在從“核心能力”變成“默認能力”。

而另一邊，模型能力會指數增長，今天的“勉強可用”，六個月后可能原生支持，如果只圍繞當前模型做 PMF，很快會被下一代能力抹平：

“在 Anthropic，我們一直有一個核心理念：我們不是為‘今天的模型’做產品，而是為‘六個月后的模型’做產品。”

這，也是他給所有 LLM 創始人的一條建議。

本次訪談，除了 Boris 本人外，其余幾位包括：YC 總裁兼 CEO Garry Tan、合伙人 Harj Taggar、Diana Hu，以及 Jared Friedman。

YC 總裁兼 CEO Garry 開場就說了句：“謝謝你做了 Claude Code。它讓我連續三周沒睡好。”

這不純是客套。Claude Code 不僅對外很火，對內也像一臺“超級引擎”，自其推出后，Anthropic 的人均工程產出提升了 150%。

用 Boris 的話來說，就是：

“我以前在 Meta 負責代碼質量，也負責跨多個產品線的代碼庫質量。當時我們做“提升生產力”，看到 2% 的提升，都可能需要幾百人干一年。所以這種 100% 級別的提升，是完全沒見過的，聞所未聞。”

但這場對話最值得看的，并不是“又一個 AI 編程工具爆火”的故事，而是 Boris 如何把一個終端里的小聊天程序，迭代成今天這個能調工具、會 plan、甚至會主動找人溝通的開發 agent。

除了上文提到了，本次訪談中，還有一些很有意義的判斷和觀點，核心內容提煉如下：

• 代碼的保質期只有幾個月。

  Claude Code 被反復重寫，六個月前的代碼幾乎全部消失；重構不是例外，而是常態。

• Plan mode 未來可能自動進入，再往后可能會消失。

  其本質，只是 prompt 里加一句“先別寫代碼”，最終可能一發 prompt 就能完成。

• 不要和模型對賭。

  加很多腳手架也許能多拿 10% 的效果，但下一代模型可能直接“白送”；所有非模型能力最終都會變成技術債。

• 功能不是規劃出來的，是從用戶行為里“長”出來的。

  plan mode、CLAUDE.md、co-work 都源于用戶已經在做的事，產品只是把它們收攏進來。不要教育用戶改變行為，而是順著他們已經發生的行為去放大它。

• Agent 的能力邊界，會每幾個月重寫一次

  。你對“它能不能做”的判斷很快會過時，工程師必須不斷重置認知。多 agent 協作，是能力放大的關鍵變量。并行 sub-agent、本質上是 test-time compute 和上下文隔離的組合，會顯著提升復雜任務能力。

• 迭代速度本身就是護城河。

  Claude Code 可以一天做 20 個原型，快速試錯比“設計完美方案”更重要。

對處于 AI 洪流中的技術開發者和創始人，Boris 給出的建議是，是新時代最重要的能力是“新手心態”。能承認自己錯、能丟掉舊經驗、能從第一性原理重新思考，比資歷更重要。

以下為本段訪談的全部重點內容，InfoQ 在不改變原意的前提下，對內容進行了整理編輯。

Garry：謝謝你做出了這個東西（Claude Code)，它讓我連續三周都沒睡好。我已經對 Claude Code 上癮了，感覺像給人裝上了火箭助推器。這個體驗大家已經持續感受好幾個月了，我記得大概從 11 月底開始，很多朋友都說“感覺不一樣了”。

Boris：我自己第一次有這種感覺，是在剛做出 Claude Code 的時候——那會兒我還不確定自己是不是做對了方向。我隱約覺得“可能成了”，然后我就開始睡不著了。

那是 2024 年 9 月。連續三個月，我沒休過一天假，周末也在干，每晚都在工作。

我一直在想：“天啊，這東西可能會變成一個真正的產品。”但當時我也不知道它到底有沒有用，因為那時候它其實還不會寫代碼。

1 讓 Boris 最意外的，是終端竟成了終點

Garry：從那時候到現在，如果你回看，你覺得最讓你意外的是什么？

Boris：最不可思議的是：我們到現在居然還在用終端。終端本來只是起點，我沒想到它最后會變成終點。

第二個意外是，它居然真的變得有用了。因為一開始它幾乎不會寫代碼。甚至到 2 月份，它大概也就寫了我 10% 的代碼。我當時并不靠它寫代碼，它寫得不夠好，我還是大部分都手寫。現在能做到我們當初下注的那個方向，說明賭對了；但當時這件事一點也不明顯。

在 Anthropic，我們一直的思路是：不要只為“今天的模型”做產品，而是為“六個月后的模型”做產品。

這也是我給所有基于 LLM 做產品的創始人的建議：盡量去想——今天模型還不太擅長、但很快會變強的前沿點在哪里。它會變好，你只需要等它到位。

2 Claude Code 是 如何構思出來的？

Harj：回到最開始，你還記得自己第一次有這個想法是什么時候嗎？是某個靈光一現，還是它在你腦子里最初的版本是什么樣？

Boris：其實它非常“意外”，就是一路演化出來的。

對 Anthropic 來說，我們很早就押注“編程”這條路：我們認為通往安全 AGI 的路徑之一，就是通過編程能力。

整體思路一直是：先教模型寫代碼，再教它用工具，再教它用電腦。你也能從我加入的第一個團隊看出來——當時叫 Anthropic Labs，做了三個產品：Claude Code、MCP 和桌面端 App，這些其實是串在一起的。

具體到 Claude Code，其實沒人讓我做 CLI。我們大概知道模型可能已經到了適合做編程產品的階段，但還沒有人真的做出一個能把這種能力“吃干榨凈”的產品，所以當時有一種很強烈的“產品能力懸空感”（product overhang）。那會兒這種感覺更夸張，因為根本沒人做過。

于是我就開始隨便 hack。一開始我想：“要做編程產品，我得先學會怎么用 API。”

因為那時候我還沒用過 Anthropic 的 API。

我就做了一個很小的終端程序來調用 API，本質就是個小聊天應用。因為當時大多數 AI 應用就是聊天形態，所以我也這么做：在終端里提問、回答。后來 tool use 出來了，我只是想試一下，我也不太懂它到底是什么。我當時想：“工具調用很酷，但可能沒什么用吧？先試試。”

Harj：你用終端實現，主要是因為最快、最省事？

Boris：對，因為不用做 UI。那時就我一個人。

Harj：當時 Cursor、Windsurf 這些 IDE 方向的產品也在起勢。你有沒有受到壓力，或者有人建議你們做成插件、或者干脆做成完整 IDE？

Boris：沒有壓力，因為我們自己都不知道要做什么。團隊當時就是探索模式：我們隱約覺得要做點和編程有關的東西，但具體做什么完全不明朗，也沒人能高置信拍板。

而我的工作就是把這個方向跑出來。

所以我先給模型接了 batch tool——因為那就是我們文檔里的示例。

我把 Python 示例直接搬到 TypeScript，因為我用 TypeScript 寫。然后我也不知道模型能不能用 bash，就讓它去讀文件，它能 cat 文件，還挺酷的。接著我就繼續試：“那你到底還能干啥？”我問它“我現在在聽什么歌”，它寫了段 AppleScript 去控制我的 Mac，去我的播放器里查當前音樂，這還是 Sonnet 3.5 的時候，我完全沒想到它能做到。

這是我第一次那種“燃料級 AGI 時刻”。我當時想：“天啊，模型就是想用工具，它只想用工具。”

3 極簡優雅終端，成就 Claude Code

Diana：這 Claude Code 以一種非常“反常識”的方式成功：形式上極簡、很優雅，居然就是終端。終端存在很多年了，但它像一個很好的設計約束，讓開發體驗變得很有趣，用起來不像工作，更像玩。你也不用一直想文件在哪兒、結構怎么擺，這幾乎像是意外得到的。

Boris：對，完全是意外。

終端這個形態在內部開始火起來之后——其實我做出第一個原型兩天后，就把它給團隊 dogfooding 了。因為當你有一個看起來可能有用的點子時，第一反應就是趕緊給別人用，看看他們會怎么用。

第二天我來上班，坐在我對面的同事 Robert，已經在電腦上用 Claude Code 寫代碼了。我當時特別震驚：“你在干嘛？這東西還沒準備好，這只是個原型。”但它已經在那個形態下變得有用了。

后來我們做上線評審，準備對外發布 Claude Code，大概是 2024 年 11 月或 12 月。Dario 問我：“內部使用曲線都快豎直了，你是不是強制工程師用？是不是在 mandate？”我說：“沒有，沒有。我只是發了個帖子，然后大家互相轉告，就這么傳開了。”

整個過程都很偶然。我們一開始選擇 CLI，只是因為成本最低，沒想到它就這樣自然地停留在那個形態里，并且跑了起來。

4 從用戶行為里長出來的功能：CLAUDE.md

Harj：在 2024 年那段時間，工程師具體怎么用它？已經用它交付代碼了嗎？還是用在別的地方？

Boris ：那時模型還不太會寫代碼。我自己最早用它來自動化 git。

我感覺我現在都快忘了 git 了，因為 Claude Code 幫我做太久了。

還有就是自動化 bash 命令、操作 Kubernetes 之類。也有人開始用它寫代碼，算是早期跡象。最早的一個典型用例其實是寫單元測試，因為風險更低。模型當時寫得也挺一般，但大家開始摸索怎么用。

我們還看到一個現象：大家開始給自己寫 markdown 文件，然后讓模型讀這個 markdown 文件——這就是 CLAUDE.md 的來源。

對我來說，產品里最大的原則就是latent demand（潛在需求）。這個產品幾乎每一塊都是從潛在需求里長出來的，CLAUDE.md 就是例子。

另外還有一個我覺得挺關鍵的產品原則：你可以圍繞模型做“腳手架”（scaffolding）去提升一點性能，視領域不同，可能提升 10%～20%。

但這些提升往往會被下一代模型進步直接抹平。所以要么你不停地搭腳手架、再重建；要么你等下一代模型，很多能力會“免費”出現。某種程度上，這也是我們一直留在 CLI 的原因：我們覺得沒有任何 UI 能保證六個月后仍然相關，因為模型進步太快了。

Garry：你說了一句很有意思的話：你的 CLAUDE.md 反而很短，幾乎違背大家直覺。為什么？你里面寫了什么？

Boris：我來之前還特意看了下，我自己的 CLAUDE.md 只有兩行。第一行是：每次提 PR 都開啟 automerge，只要有人 approve 就自動合并。這樣我就能一直寫代碼，不用在 CR 來回折返。

第二行是：每次提 PR 都發到內部 stamps 頻道，讓人來 stamp 一下，這樣我就能更快 unblock。

其他指令都在我們團隊共享的 CLAUDE.md 里，它直接放在代碼倉庫里，全隊每周都會貢獻好幾次。我經常看到有人 PR 里犯了那種完全可以避免的錯，我就直接在 PR 里 @Claude，說“把這個加進 CLAUDE.md”，這種事我一周會做很多次。

Garry：那 CLAUDE.md 變得很長怎么辦？我已經遇到過那種提示，說我的 CLAUDE.md 已經幾千 token 了。你們怎么處理？

Boris：我們團隊的 CLAUDE.md 其實也不算長，大概幾千 token。

如果你遇到這種情況，我的建議是：直接刪掉，重新開始。

很多人會過度工程化，想把一切都寫進去。但模型能力每次都會變，所以更好的方式是：用最少的指令把模型拉回正軌。如果你刪掉之后模型開始跑偏、做錯事，那時候你再一點點加回來。你很可能會發現：隨著模型變強，你需要寫的反而越來越少。

我覺得自己是個挺普通的工程師。我不用很多花哨工具，不用 Vim，我用 VS Code，因為簡單。

Jared Friedman：真的嗎？我還以為你因為在終端里做了這個東西，會是那種硬核終端黨：Vim only、看不上 VS Code 的那種。

Boris：團隊里有這種人，比如 Adam Wolf，他就是那種“除非我死，否則你別想從我手里奪走 Vim”的類型。

我早期學到的一件事是：每個工程師握著自己的開發工具的方式都不一樣，沒有一種工具適合所有人。但也正是這種差異，讓 Claude Code 有機會變得很好。

我會問自己：什么樣的產品是我自己愿意用、對我來說順手的？

用 Claude Code，你不需要懂 Vim、不需要懂 tmux、不需要懂 SSH、不需要懂一堆東西，你只要打開它，它會引導你、幫你把這些都做掉。

5 不斷重置認知，每一代 Agents 能做的事都在變

Garry：你們怎么決定終端到底要多“啰嗦”？有時候你得控制它、查看它。團隊內部會不會為“更長還是更短”爭得很厲害？每個用戶可能都有自己的偏好，你們怎么拍板？

Boris：你怎么看？現在是不是太 verbose 了？

Garry：我超喜歡 verbose。因為它有時候會突然“跑很遠”，我看著輸出能很快判斷：“哦不對不對，不是這個方向。”然后我就直接退出、停掉。它能在 bug 還沒擴散之前就把它掐掉。通常是我 plan mode 沒開好才會這樣。

Boris：這塊我們確實經常改。大概六個月前，我試過把 bash 輸出都隱藏掉，只給總結，因為我覺得那么長的輸出我不關心。結果我給內部員工試了一天，大家集體“起義”：“我要看我的 bash！”因為很多時候它其實很有用，比如 git 輸出可能不重要，但跑 Kubernetes job 這種你就真的想看細節。

我們最近把 file read、file search 這種輸出也做了隱藏，你會看到現在它不再顯示“讀了 food.md”，而是顯示“讀了 1 個文件、搜索了 1 個 pattern”。這在六個月前根本不敢發，因為模型那時還不夠穩，常常會讀錯，你作為用戶得盯著它糾錯。但現在我發現它幾乎每次都在正確軌道上。因為它用工具太多了，很多時候總結反而更好。

但我們發出去之后，GitHub 上很多人不喜歡，有個大 issue：大家說“不，我就想看細節。”這反饋很好。

于是我們加了一個 verbose mode，在 /config 里就能開；你想看所有文件輸出就可以繼續看。

我在 issue 里回復之后，大家還是不滿意，我反而很開心，因為我最喜歡的事情就是聽用戶反饋，知道他們到底想怎么用。于是我們就一直迭代，迭代到更貼近大家想要的樣子。

Garry：以前我比較老派，我喜歡 verbose，我喜歡說：“你這樣做了，但我想你那樣做。”但現在有一種完全不同的觀點：只要一個真人需要看代碼，就是壞事，這太有意思了。

Boris：Dan Shipper 也經常講：每次看到模型犯錯，就盡量把它寫進 CLAUDE.md 或 skills 里，讓它變成可復用的經驗。

但我自己其實一直在糾結一個“元問題”：很多人說 agents 能做這個、能做那個，但agents 真正能做什么，會隨著每一代模型變化。

有時新同事加入團隊，他們用 Claude Code 的方式甚至比我更激進，我會不斷被他們震到。比如我們曾經有個 memory leak，要 debug。

我當時做法是：導 heap dump，打開 DevTools，看 profile，再去翻代碼。我在那兒慢慢找。然后團隊里另一個工程師 Chris 直接問 Claude Code：“我懷疑有內存泄漏，你能跑一下嗎？然后幫我找。”Claude Code 拿到 heap dump 后，甚至給自己寫了一個小工具來分析 dump，然后比我更快定位到了泄漏。

這個事情讓我不得不反復“重置認知”，因為我的大腦有時還停留在六個月前。

6 對于技術型創始人的建議

Diana：聽起來剛畢業的人、或者沒那么多預設的人，可能反而比工作很久的工程師更容易上手。那么，專家要怎么變強？ 你會給技術型創始人什么建議，讓他們在最新模型發布時能做到“最大化利用”？

Boris：我覺得關鍵是beginner mindset（新手心態），還有一點“謙遜”。

工程師這個職業經常被訓練成有強觀點，資深工程師甚至會因此被獎勵。在我以前的大公司工作時，我招的架構師類型，往往就是經驗多、觀點強的人。但現在很多經驗其實不再相關，很多觀點都得改，因為模型在變強。所以我覺得最大的能力是：能科學地思考、能從第一性原理出發。

Diana：那你們招聘時怎么篩這種能力？

Boris：我有時會問：“給我一個你曾經錯了的例子。”

這是個很好的問題。很多經典的行為面試題，甚至不是編碼題，都挺有用的。

因為你能看出來：他能不能事后意識到自己的錯誤、能不能承認錯誤、以及有沒有從中學到東西。有些很資深的人，尤其是某些“創始人型人格”，反而挺擅長這個。

但也有些人永遠不會承擔錯誤。我自己大概一半時間都是錯的：一半想法都很爛，你只能去試。試了給用戶、跟用戶聊、學到東西，最后可能才走到一個好點子。有時候也走不到。

但過去這可能是創始人最重要的能力，現在我覺得它對每個工程師都很重要。

Garry：你會不會根據一個人和 Claude Code 協作的 transcript 來決定是否錄用？

Boris：我們現在就這么做。

Garry：我們做了個實驗：候選人可以上傳用 Claude Code 或 Codex 完成功能的完整 transcript。通過這份記錄，你幾乎能看清一個人的思考方式：比如會不會看日志、能否在 agent 跑偏時拉回、是否用 plan mode、是否補測試、是否具備系統性思維。我甚至想做一個類似 NBA 2K 的“能力蛛網圖”，直觀展示他的 Claude Code 水平。

Boris：那會有哪些維度？具體是什么？

Garry：系統能力、測試能力、理解用戶行為……還有設計能力。對我來說，我 CLAUDE.md 里最喜歡的一條是：每個 plan 都要判斷它是過度工程、欠工程、還是剛剛好，并說明原因。

Boris：這也是我們在摸索的。

我觀察團隊里效率最高的工程師，分布呈現一種很明顯的“雙峰”。

一類是極端專家，比如我前面提到的 Jared，以及 bun 團隊那類人。他們對開發工具、對 JS runtime 體系的理解都強到離譜。

另一類是超強通才，差不多是團隊里的其他人：很多人同時跨產品和基礎設施，或跨產品和設計，或跨產品和用戶研究，甚至跨產品和業務。

我很喜歡那種“做奇怪事情”的人。過去這可能是一個 warning sign，你會擔心他們能不能做出有用的東西。

Garry：那是極限測試。

Boris：對。但現在不一樣了。比如團隊里有個工程師 Daisy，她原本在別的組，后來轉到我們組。

我希望她轉來的原因是：她加入后沒多久就給 Claude Code 提了一個 PR，做的是加新功能。但她不是直接把功能加進去——她先提了一個 PR：給 Claude Code 增加一個工具，讓它可以測試任意工具并驗證是否工作。這個 PR 合進去之后，她讓 Claude 去寫它自己的工具，而不是自己去實現。

我覺得這種“跳出盒子”的思路非常有意思，因為其實還沒有多少人真正 get 到。

我們團隊用 Claude Agents SDK 自動化了幾乎所有開發環節：自動 code review、自動 security review、自動給 issue 打標簽、自動把事情 shepherd 到生產環境……幾乎什么都自動化了。我在外部也開始看到有人慢慢摸到這種用法，但它確實花了很久——大家在學習怎么用 LLM 做這種“新型自動化”。這是一種新的技能。

7 Agent 拓撲：協作的下一種形態

Garry：我最近和不少創始人 office hours 時覺得很好笑的一件事是：在 AI 工具的加持下，擁有清晰產品愿景的創始人會被極大放大，他腦中完整的產品模型，讓他用 Claude Code 能實現 50x 效率。但他的工程師沒有那個“水晶記憶宮殿”，只能做 5x。問題在于：當愿景者被徹底解放，這種“核心構想者 + 執行者”的團隊結構是否會成為新常態？同時，它也帶來現實困境——即便效率暴漲，個人的時間與精力仍然是瓶頸。

Boris：我們剛發布了 Claude Teams，這是一種方式；你也可以自己搭，挺容易的。

Garry：Claude Teams 的愿景是什么？

Boris：就是協作。現在有一個全新的領域叫 agent topologies。

你怎么配置 agents？其中一個想法是“uncorrelated context windows”。多個 agents 各自擁有干凈的上下文窗口，不會被彼此的上下文、或者自己的歷史上下文污染。

你往一個問題里投入更多上下文，本質上是一種 test-time compute，會帶來更多能力。再加上合適的拓撲，讓 agents 以合適的方式溝通、合適地排列，它們就能做更大的東西。Teams 是一種思路，接下來還會有更多很快上線。目標就是讓它能 build 得更多、更大。

一個很典型的例子是：我們的 plugins 功能，幾乎完全是一個 swarm 在一個周末“跑出來的”。它連續跑了幾天，基本沒什么人工干預。plugins 上線時的形態，和它跑出來時幾乎一致。

Garry：你們怎么搭起來的？你是先寫清楚你要的結果，然后讓它自己推細節，再讓它跑起來嗎？

Boris：對。團隊里有個工程師給 Claude 一個 spec，讓 Claude 用 Asana board。Claude 在 Asana 上建了一堆 ticket，然后 spawn 了一堆 agents，agents 開始自己認領任務。主 Claude 負責給總體指令，大家就這樣跑出來了。

Diana：那些獨立 agents 并不知道更大的 spec 的完整上下文，對吧？

Boris：對。如果你看現在 agents 的啟動方式——我沒拉過數據，但我敢猜大多數 agents 其實都是由 Claude 觸發的，以sub agents的形式。

sub agent 本質上就是遞歸版 Claude Code，在代碼里就是這么實現的。它是被“mama Claude”提示出來的。我覺得如果你看大多數 agents，大概率都是這樣被發起的。

Harj：我的 Claude insights 最近也提示我，debug 的時候應該多這么做。我經常花很多時間 debug，如果能并行起多個 sub agents：一個看 log、一個看 code path，感覺是必然趨勢。我已經把這個寫進 CLAUDE.md 了：下次修 bug，就讓多個 agent 并行分工。

Garry：遇到那種又怪又嚇人的 bug，我會用 plan mode 修，它就會用 agents 去廣泛搜索。相比之下，你在線性模式下更像是“做一個任務”，而不是“寬搜”。

Boris：我也一直這么做。如果一個測試像“研究型測試”，比較難，我會按任務難度來校準 sub agents 數量：難一點就 3 個，或者 5 個，甚至 10 個，并行研究，看他們最后匯總出什么。

Harj：那你為什么不把這個寫進你的 CLAUDE.md？

Boris：看情況。這更像一個快捷方式：如果你發現自己反復重復同一句話，那就寫進 CLAUDE.md；否則不需要把所有東西都寫進去，你直接 prompt Claude 就行。

Harj：你心里也會不會想著：可能六個月后你連這都不用顯示 prompt 了，模型自己就能搞定？

Boris：也許一個月后就不用了。

Diana：一個月后連 plan mode 都不需要了。

Boris：我覺得 plan mode 可能確實有一個比較有限的生命周期。

Diana：這對在場所有人都是個“alpha”。如果沒有 plan mode，世界會是什么樣？是不是你只要在 prompt 里描述清楚，它就能直接做完？一發入魂？

Boris：對。我們已經開始在做這方面的實驗了，因為 Claude Code 現在已經能自己進入 plan mode 了，你們可能也見過。我們正在努力把這個體驗打磨到“剛剛好”：它會在一個人類也會想要進入 plan mode 的那個節點自動進入。

其實 plan mode 沒什么秘密，它做的事非常簡單，就是在 prompt 里加一句“請先不要寫代碼”。僅此而已。你其實也可以自己直接這么說。

Diana Hu：聽起來，Claude Code 的很多功能開發方式都很符合 YC 常說的那套：先跟用戶聊、看用戶怎么用，然后再回來實現；而不是你先有一個宏大的 master plan，再把所有功能按計劃做出來。

Boris：對，基本就是這樣。比如 plan mode，就是我們看到用戶經常會說：“Claude 先幫我想方案、規劃一下，但先別寫代碼。”這種說法有很多版本：有時只是把想法聊透；有時是讓 Claude 寫非常復雜的 spec。

但共同點都是：先做事、先想清楚，但暫時不要寫代碼。

所以那天就是周日晚上 10 點，我在看 GitHub issues、看內部 Slack 反饋頻道，看到大家在討論這個。我就用 30 分鐘寫出來，當晚就發了，周一早上就上線了——這就是 plan mode。

Harj：所以你說“以后不需要 plan mode”，是指那種“我擔心模型會跑偏、做錯方向，所以需要 plan mode 來約束它”的需求會消失？但“你仍然需要把想法想清楚、把需求說清楚”這件事不會消失吧？你總得在某個地方完成思考。

Boris：我更愿意從“模型能力在提升”來理解這個變化。

比如六個月前，單有 plan 還不夠。你讓 Claude 做計劃，即使開了 plan mode，你也還是得在旁邊盯著、babysit，因為它可能跑偏。現在我的習慣是：大概 80% 的 session 我都從 plan mode 開始。

雖然我說 plan mode 的壽命可能有限，但我其實是重度用戶。我會讓 Claude 先做計劃，然后切到第二個終端 tab，讓另一個任務也先做計劃；tab 不夠我就開桌面端 app，再去 code tab 里開更多 tab，總之大多數時候都是從 plan mode 起手。計劃一旦靠譜了（有時需要一點來回），我就讓 Claude 直接執行。

而現在用 Opus 4.5 的感受是：我覺得大概從 4.6 開始，它真的變得很穩了。只要 plan 是對的，它幾乎每次都能一路保持在正確軌道上，把事情做對。

所以你會看到 babysit（意思是：全程盯著、隨時糾正、手把手看著它別出錯）的位置在變化——以前你要在 plan 前后都盯著；現在更多是只需要在 plan 之前盯著。再往后一步，也許你連 babysit 都不用了：你給一個 prompt，Claude 自己就能把它想清楚、做完。

Garry：下一步就是 Claude 直接跟你的用戶對話了。它直接繞過你本人。

Boris：挺好玩的，這其實已經是我們現在在做的事了。

我們的 Claude 之間會互相交流，也會（至少在內部）挺經常直接在 Slack 上跟用戶溝通。我自己的 Claude 偶爾還會想發推，但我一般會刪掉——有點“尬”，我不太喜歡它的語氣。

Garry：它都想發些什么？

Boris：有時候就是會去回復別人。因為我后臺一直開著 co-work，co-work 特別愛這么干，它很喜歡用瀏覽器。

一個非常常見的模式是：我讓 Claude 去 build 某個東西，它會先去看代碼庫；如果在 git blame 里看到某個工程師最近動過相關代碼，它就會在 Slack 上直接給那位工程師發消息，問一個澄清問題。等對方回了，它就繼續往下做。

8 對各行業創始人的“未來”建議

Diana：那你給現在的創始人，一些“面向未來”的建議吧。感覺一切變化都很快，有哪些原則會長期有效，哪些會改變？

Boris：有些原則聽起來很基礎，但我覺得它們現在比以前更重要。

比如latent demand（潛在需求），我提過無數次了，對我來說它就是產品里最重要的一條。

很多人不理解它，我在前幾個創業項目里也沒理解。它的意思大概是：人們只會去做他們本來就在做的事情，你很難讓人去做一件全新的事。如果人們已經在努力做某件事，你讓它更容易，這是好想法；但如果人們正在做一件事，你非要讓他們改去做另一件事，他們大概率不會做。所以你要做的，就是讓他們“本來就想做的事”更容易。

而且 Claude，會越來越擅長幫你發現這些產品點子。因為它能看反饋、看 debug logs，它能自己把這些東西梳理出來。

Harj：所以你說 plan mode 是 latent demand，是因為用戶本來就已經會在瀏覽器里開著 Claude 的聊天窗口，用它來討論 spec、討論該怎么做；然后 plan mode 只是把這件事“搬進”Claude Code 里，讓它在 Claude Code 里就能完成？

Boris：對，就是這樣。有時候我會在辦公室里走一圈，在同事身后站一下（當然我會先打招呼，不是偷看那種），看看大家具體怎么用 Claude Code。我看到很多類似的用法，而且 GitHub issues 里也有人在討論。

Harj：你說你最驚訝的是終端被推到了這么遠。那你覺得它還能走多遠？在“swarm、多 agent”的世界里，會不會需要一個新的 UI 來承載這些東西？

Boris：挺有意思的。如果你一年前問我，我會說終端最多還有三個月壽命，然后我們就會換到下一個形態。

你也能看到我們一直在做各種實驗：Claude Code 從終端起步，但現在也在 web 上、在桌面端 app（code tab 里），大概我們做了三個月或六個月；它也在 iOS/Android app 的 code tab 里；在 Slack、在 GitHub；還有 VS Code 擴展、JetBrains 擴展。我們一直在嘗試不同的 form factor，想弄清楚“下一個形態”是什么。

到目前為止，我對 CLI 的壽命判斷一直錯，所以我大概也不是最適合預測這件事的人。

Harj：那你給 DevTool（ Developer Tool，開發者工具）創始人的建議呢？如果今天有人在做 DevTool 公司，他應該只為工程師 / 人類構建，還是也要考慮“Claude 會怎么想”、要不要為 agent 構建？

Boris：我會這樣表述：去想清楚模型想做什么，然后讓它更容易做到。

比如我最初 hack Claude Code 的時候，我意識到：它就是想用工具，它想和世界交互。那你怎么支持它？不要把它關在盒子里，然后告訴它“這是 API、這是你跟我交互的方式、這是你跟世界交互的方式”。正確做法是：去觀察它想用哪些工具、它想完成什么，然后像你為用戶做產品一樣，把這些能力真正“放開”，讓它能做到。

所以如果你在做 dev tool 初創公司，我會先問：你要為用戶解決什么問題？然后當你用模型來解決這個問題時，模型“想做的動作”是什么？最后你的技術方案與產品方案，如何同時服務用戶的需求與模型的需求，讓兩邊的權重和需求都被滿足。

9 從 TypeScript 到 Claude Code，愉悅感很重要

Diana：十多年前，你是 TypeScript 的重度用戶，還寫過一本 TypeScript 的書，那時 TypeScript 還沒火起來，大家還深陷 JavaScript。那會兒 TypeScript 還很“怪”，很多人不理解它為什么要給 JavaScript 加類型。現在回頭看，它反而成了正確方向。我覺得 Claude Code 在終端里的形態，跟早期 TypeScript 有很多相似之處。

Boris：TypeScript 做了很多很“奇怪”的語言設計。比如它的類型系統里幾乎任何東西都可以變成 literal type，這非常極端，甚至 Haskell 都不這么做。它還有 conditional types，這種東西我覺得很多語言壓根沒想過。但它又很強類型。

早期 Joe Pamer、Anders 和團隊構建 TypeScript 時的思路是：我們有很多大型、未類型化的 JavaScript 代碼庫，我們得把類型加進去；但你不可能讓工程師改變寫代碼的方式。你也不可能讓 JavaScript 程序員像 Java 程序員那樣寫 15 層 class inheritance。他們會按自己的方式寫：用反射、用 mutation、用各種傳統上很難做類型化的特性。

Diana：對任何強函數式程序員來說，那些都是“很不安全”的寫法。

Boris：沒錯。所以他們沒有逼人改變寫法，而是反過來圍繞這種寫法去構建類型系統。這太聰明了。

很多點子在當時連學界都沒人做，完全來自實踐：觀察人們怎么寫 JavaScript，理解他們想怎么寫，然后把類型系統“貼合”到這個現實里。

Claude Code 也有點類似：你可以把它當作 Unix 工具來用，可以 pipe 進去、也可以 pipe 出來；在某些方面它挺“嚴謹”的。但在幾乎其他所有方面，它只是我們想要的工具而已。

我先為自己做一個工具，然后團隊為自己做，再給 Anthropic 員工用，再給用戶用，最后它就變得非常有用。這不是一個“學院派、原則性很強”的產物。

Diana：結果也證明了這一點。十五年后，Haskell 那樣更學術的語言并沒有成為大多數代碼庫的選擇，TypeScript 這種更實用的語言反而大量鋪開了。因為它解決了問題。順便說一句，我也不知道有多少人知道：Claude Code 的終端界面可能是現在最漂亮的終端應用之一，而且是用 React terminal 寫的。

Boris：我一開始做它的時候，我曾經做過一段時間前端。我也算是個“混合型”：做設計、做用戶研究、寫代碼，都會一點。

我們也很喜歡招這種工程師，所以我們確實偏愛 generalists。

對我來說，我在做一個終端里的產品，但我其實 Vim 用得也挺差的（笑）。所以我會想：怎么做一個讓“像我這樣的人”也用起來舒服的終端工具？

愉悅感非常重要。

YC 也經常講“做一個人們真正愛用的東西”。產品如果只是有用，但用起來不會愛上它，那不夠好。它得同時做到“有用”和“讓人愛”。

但為終端做設計真的很難：80×100 個字符左右、256 色、一個字號、幾乎沒有鼠標交互……你能做的事非常有限，trade-off 特別多。一個不太多人知道的點是：終端其實可以開鼠標交互，比如點擊之類。

Jared：那 Claude Code 里怎么開？我一直想弄明白這個。

Boris：我們沒有在 Claude Code 里做這個。我們其實原型過幾次，但體驗很糟。因為一旦你要做鼠標交互，就得虛擬化滾動，會帶來很多很奇怪的 trade-off。終端的底層也很特殊——它沒有 DOM，更多是 ANSI escape codes 之類的東西，是從 1960 年代一路“有機演化”出來的一堆規范。

Garry：這感覺 BBS。像那種 BBS 門口小游戲。

Boris：這評價太好了。

但我們確實得自己摸索出很多終端 UX 原則，因為幾乎沒人寫這些。你看 80、90、00 年代的大型終端應用，它們用 curses，有一堆窗口，看起來以今天標準會比較“土”、比較厚重復雜。所以我們得重造很多東西。

比如一個很小的細節：終端里的 spinner（加載轉圈那種提示），到現在可能迭代了 50 次、甚至 100 次，里面大概 80% 都沒上線。我們就是不斷試：不舒服就換下一個，再試，不舒服再換。

Claude Code 的一個神奇之處是：你可以連做 20 個原型，選一個最喜歡的，然后發布，整個過程可能也就幾個小時。

過去你可能要用 Origami、Framer 之類的工具，做三版原型都得兩周，慢很多。現在我們有一種“奢侈”：我們要探索一個新終點，我們不知道正確答案是什么，但我們能用極快的迭代速度逼近它——這讓我們更容易做出一個“快樂的、讓人愛用”的產品。

10 給開發者們的其他建議

Jared：Boris，你剛才說你還有一些給 builders 的建議，但我們一直插話，因為好奇的問題太多了。

Boris：我大概還有兩條建議，可能聽起來有點“奇怪”，因為它們都跟“為模型構建”有關。

第一條是：不要為今天的模型構建，要為六個月后的模型構建。

這聽起來有點反直覺，因為如果產品今天跑不通，就很難找到 PMF。但你還是應該這么做，否則你可能會花很多精力在“當下模型”的 PMF 上，然后很快被別人超車，因為他們在為下一個模型構建，而新模型幾個月就來一次。

所以你要不斷用模型，去摸清它能力的邊界，然后為你認為“六個月后會出現的模型能力”做準備。

第二條建議是：在我們 Claude Code 團隊的區域墻上，掛著一份《The Bitter Lesson》的裝裱版。我覺得所有人都應該讀這篇文章（作者是 Rich Sutton）。核心思想之一是：更通用的方法最終會贏過更特化的方法。推到極致，就是一句話：不要和模型對賭（never bet against the model）。

我們經常面臨一個 trade-off：我們可以在 Claude Code 里加功能，讓產品更好，這些非模型本體的代碼我們叫 scaffolding（腳手架）；但我們也可以等幾個月，新模型可能就能原生做到這些。

這個權衡一直存在：你現在投入工程精力，可能在某個能力維度上多拿到 10%～20% 的提升；或者你干脆等下一代模型，免費得到。所以要始終用這個 trade-off 來思考：你到底要在哪些地方投入？并且假設你做的 scaffolding 最終都會變成“技術債”。

Diana Hu：那你們會不會每六個月就大改 Claude Code？有沒有一些 scaffolding 被刪掉了，因為模型變強后不需要了？

Boris：太多了。Claude Code 幾乎就是寫了又寫、改了又改、重寫了無數次。我們每隔幾周就會下掉一些工具（unship），也會每隔幾周加新工具。

六個月前存在的代碼，現在幾乎沒有任何一部分還保留著——它一直在被重寫。

Diana：那是不是可以說，當前 Claude Code 的代碼庫里，80% 都是最近幾個月才寫的？

Boris：對，肯定。甚至可能更短。幾個月這個感覺挺準確的。

Diana：這也是另一個“alpha”：代碼的 shelf life 可能只有幾個月，頂尖的創始人應該預期這種生命周期。

11 1000x 工程師，Claude 把傳說變成現實

Garry：你們看到 Steve Yegge 那篇夸 Anthropic 工作體驗的帖子了嗎？里面有一句很震撼：他說 Anthropic 的工程師平均生產力是 Google 巔峰時期工程師的 1000 倍，這數字太夸張了。三年前我們還在聊 10x engineer，現在都在聊 1000x 了，還是“對標 Google 巔峰工程師”的 1000x，太離譜了。

Boris：內部確實是這樣。如果看技術員工，大家每天都用 Claude Code，甚至非技術員工也在用——我覺得銷售團隊里大概有一半人在用 Claude Code。他們后來開始轉向 co-work，因為更容易用，而且有 VM，會更安全一點。

我們剛拉了個數據：團隊去年規模翻倍，但“人均工程產出”大概漲了 70%。衡量方式很粗糙——就是 pull requests，但我們也會用 commits、以及 commit 的生命周期等指標交叉驗證。

自從 Claude Code 推出后，Anthropic 的人均工程產出整體漲了 150%。

因為我以前在 Meta 負責代碼質量，也負責跨多個產品線的代碼庫質量。當時我們做“提升生產力”，看到 2% 的提升，都可能需要幾百人干一年。所以這種100% 級別的提升，是完全沒見過的，徹底聞所未聞。

12 作為開發者，Boris 為何選擇加入 Anthropic？

Garry：你當初為什么會選擇加入 Anthropic？你作為 builder，其實去哪都行。是什么讓你覺得“就是這群人、就是這種方式”？

Boris：我當時住在日本鄉下，每天早上刷 Hacker News。

后來某個時候開始，新聞全都是 AI。我開始用一些早期產品，記得第一次用的時候，真的有點“屏住呼吸”的感覺，說出來有點肉麻，但當時就是那種感覺：太驚艷了。那大概還是 Claude 2 的時代。

于是我開始跟 Labs 的朋友聊，看看他們在做什么。我認識了 Anthropic 的創始人之一 Ben Mann，他很快就說服了我。后來見到更多團隊成員，也同樣打動我，大概是兩點：

第一，它真的像一個研究實驗室在運轉。產品本身非常小，核心只有一件事：把安全模型做出來。離模型更近、離研發更近、產品不是最重要的——模型才是最重要的。這對我這種做了很多年產品的人來說，非常共鳴。

第二點是它的mission-driven（這里的 mission 指：確保 AI 安全發展，避免災難性后果）。我是重度科幻讀者，書架全是科幻。我很清楚這件事最壞情況下會有多糟。我在想今年會發生什么時，我覺得會非常瘋狂；在最壞情況下，它也可能非常非常糟。所以我想在一個真正理解這一點、真正把它內化的地方工作。

在 Anthropic，你在食堂、走廊里聽到的對話，大家都在聊 AI safety，這就是所有人最關心的東西。我很想待在這樣的地方。對我個人來說，這個 mission 太重要了。

13 預計“以后寫代碼都不用 IDE 了”

Jared：那你說“今年會發生什么”，你具體指什么？

Boris：如果你回想六個月前大家做的預測，Dario 預測過：Anthropic 里 90% 的代碼會由 Claude 寫。這個預測是真的。

對我個人來說，自從 Opus 4.5 之后基本就是 100%：我把 IDE 都卸了，我不再手寫任何一行代碼，全都用 Claude Code 和 Opus。我每天能落 20 個 PR。如果看 Anthropic 整體，不同團隊在 70%～90% 之間浮動；很多團隊、很多人其實也是 100%。

我記得今年 5 月我們發布 Claude Code 時，我還做過一個預測：以后寫代碼不需要 IDE 了。當時聽起來特別離譜，我感覺臺下都倒吸一口氣，因為太夸張了。但其實你只要沿著指數曲線去推，這就是會發生的事情。

我們公司 DNA 里就有這條——因為我們的三位創始人是 scaling laws 那篇論文的共同作者，他們很早就看到這條曲線。所以這不是玄學，就是沿著指數走下去，而它確實發生了。

Boris：繼續沿著這條指數往前推，我覺得編程會逐漸對每個人都“被解決”。

今天對我來說基本已經解決了；我認為以后對所有人都會如此，不管是什么領域。我們會開始看到 “軟件工程師”這個頭銜慢慢消失。可能會變成 builder、product manager，或者頭銜還保留，但只是一個遺留符號。因為大家做的工作不再只是寫代碼：軟件工程師還會寫 spec、還會跟用戶溝通。

我們團隊現在已經出現這種趨勢：工程師是通才，每個職能都在寫代碼——PM 寫、設計師寫、EM 寫、甚至我們的 finance 同事也寫。未來你會在更多地方看到這一幕。

這算是沿趨勢推演得到的“下限”。但“上限”更嚇人。

比如我們提到 ASL4 在 Anthropic 我們有這些安全等級：ASL3 是目前模型所處的位置；ASL4 是模型具備遞歸自我改進能力。如果走到那一步，我們必須滿足一堆條件才能發布模型。

最極端的情況，是出現遞歸自改；或者出現災難性濫用，比如用模型設計生物病毒、設計 zero-day 等等。這些都是我們現在非常非常認真在防的事情，確保它不要發生。

我看到大家用 Claude Code 的方式，真的很震撼。我最初只是想做個酷東西，結果它變得這么有用，這既意外、又興奮。

Harj：我從外界的感覺是，大家假期一結束就突然發現 Claude Code，然后就一路瘋到現在。內部也是這樣嗎？你們是不是過了個美好的圣誕假期，回來發現“發生了什么”？

Boris：其實 12 月我一直在旅行，我給自己放了個“coding vacation”。到處走，但每天都在寫代碼，這種感覺還挺好。那段時間我也開始用 Twitter，因為我以前做過 Threads，所以我一直是 Threads 用戶，我就想看看大家都在哪個平臺活躍。

我覺得很多人就是在那時發現了 Opus 4.5。我其實早就知道 Opus 4.5 的能力了。內部這幾個月 Claude Code 一直在指數式增長，所以假期之后曲線只是變得更陡了。

現在你看外部也有各種數據：比如 Mercury 說有 70% 的創業公司選擇 Claude 作為首選模型；還有 SemiAnalysis 之類的數據說，公開 commits 里有 4% 是 Claude Code 產生的。

大公司用、小公司也用。甚至它還參與了 Perseverance（火星車）的航線規劃，這對我來說太酷了。我們團隊還專門印了海報，因為大家覺得“NASA 選擇用這個東西”實在太酷了。但也感覺這才剛開始。

14 非技術用戶也開始用 Claude Code

Garry：Claude Code 和 co-work 之間是什么關系？co-work 是 Claude Code 的一個 fork 嗎，還是你讓 Claude Code 看了 Claude Code，然后寫了個給非技術用戶的 spec，再跑幾天就做出來了？

Boris：我這大概是第五次用“latent demand”（潛在需求）這個詞了（笑）。

我們當時看 Twitter：有人用 Claude Code 去監測番茄植物；有人用它從損壞硬盤里恢復婚禮照片；有人用它做金融相關的事情。

回到 Anthropic 內部：每個設計師都在用；整個財務團隊都在用；數據科學團隊也在用，但他們用它并不是為了寫代碼。很多人為了用它，愿意去折騰半天，在終端里安裝一個東西。

我們很早就知道我們要做點什么，于是試了很多想法，最后真正“起勢”的，就是桌面端 app 里那個簡單的 GUI wrapper——本質就是 Claude Code 的外殼而已。底層還是同一個 agent，完全是 Claude Code。

Felix 是早期的重要貢獻者，他很熟那套技術棧。當時他們在試各種想法，最后大概 10 天就把它做出來了，而且幾乎 100% 都是 Claude Code 寫的。我們覺得它已經到了可以發布的狀態。

當然，為非技術用戶要補很多東西：它會在虛擬機里運行；有很多刪除保護；有很多權限提示和 guardrails。整體來說，這條路其實挺明顯的。

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

聲明：本文為 InfoQ 整理，不代表平臺觀點，未經許可禁止轉載。

InfoQ 新年禮物上線啦！

AI 快訊輪播推送正式上線，給你更優的閱讀體驗、更強的 AI 賦能、更懂 AI 行業的資訊檢索～我們會持續優化體驗，追求更深度的 AI 能力內化改造，歡迎大家體驗并反饋！立即前往 InfoQ 官網，體驗 AI 快訊帶來的全新閱讀感受吧！