Claude Code，
是一場美麗的意外

沒人叫我做 CLI，
它就這樣長出來了

主持人一開頭就向 Boris 道謝：「謝謝你做出一個讓我連續三週睡不著的東西。」Boris 笑說，他自己第一次有這種感覺，是 2024 年 9 月剛做出 Claude Code 的時候——「三個月沒放過一天假，週末、每個晚上都在做，因為我覺得這可能會成為一個 thing，雖然那時它根本還不會寫程式。」

這個產品的起點完全是意外。Anthropic 一直押注「通往安全 AGI 的路，是先教會模型寫程式」，但沒有人叫 Boris 去做一個 CLI。他只是想搞懂怎麼用 Anthropic 的 API，於是寫了一個跑在終端機裡的小聊天程式——「因為這樣我就不用做 UI」。接著 tool use 功能剛好推出，他想試試看，給模型的第一個工具就是 bash，而那段程式碼是直接從官方文件的範例複製來的，只是把 Python 改寫成 TypeScript。

原型做出來兩天後，Boris 就丟給團隊試用。隔天他發現坐對面的工程師 Robert 已經在用它寫程式：「我說你在幹嘛？這東西只是個原型欸。」但它在那個形態下就已經有用了。後來內部使用曲線陡到 Dario 在發布會上問：「你是不是強制工程師用？」Boris 說沒有，「我只是發了個貼文，他們就口耳相傳開了。」最讓他意外的是：到現在大家居然還在用終端機——「終端機本來只該是起點，我沒想到它會是終點。」

我的 CLAUDE.md，
只有兩行

Boris 說，產品開發對他來說最重要的單一原則，是「latent demand（潛在需求）」——人們只會去做他們本來就在做的事，你沒辦法逼他們做新的事；你能做的，是把他們本來就想做的事變得更容易。Claude Code 的每一個功能，幾乎都是這樣從觀察使用者長出來的。CLAUDE.md 就是一例：當初是看到使用者開始自己寫 markdown 檔給模型讀，他才把它變成內建功能。

來上節目前他特地查了自己的 CLAUDE.md，結果——只有兩行。第一行：每次開 PR 就自動啟用 auto-merge；第二行：每次開 PR 就貼到團隊的 stamps 頻道讓人蓋章。「其他所有指示都放在 checkin 進 codebase 的那份 CLAUDE.md 裡，整個團隊每週都會貢獻好幾次。」每當他看到有人犯了可預防的錯，就直接在 PR 上 tag Claude：「把這條加進 CLAUDE.md。」

同樣的邏輯也解釋了 plan mode 怎麼來的。Boris 說 plan mode 其實沒什麼秘密，「它做的事就是在 prompt 裡加一句『請先不要寫程式』，就這樣，你自己手打也行。」他看到使用者反覆在做「叫 Claude 先規劃、先別動手」這件事，於是在某個週日晚上十點、邊看 GitHub issue 邊花了 30 分鐘寫出來，週一早上就上線。「這就是 YC 一直在講的：跟你的使用者聊，然後把它做出來——而不是先有宏大藍圖，再實作所有功能。」

永遠別賭
模型會輸

Claude Code 團隊辦公區的牆上，掛著一份裱框的〈The Bitter Lesson〉——Rich Sutton 那篇經典文章。Boris 把它的核心濃縮成一句：越通用的模型，終究會贏過越專用的模型；所以永遠別賭模型會輸（never bet against the model）。

這直接影響團隊每天的取捨。你可以幫 Claude Code 加功能、寫「鷹架（scaffolding）」——也就是模型本身以外的那些程式碼——在特定領域把表現提升個 10～20%。但問題是，下一個模型一出來，這點增益就被抹平了。所以每次都要在「現在投入工程、把能力延伸一點點」和「乾脆等下一個模型免費幫你做到」之間做選擇。這也是 Claude Code 一直待在 CLI 的原因：因為他們覺得，做出來的任何 UI 六個月後都會過時，模型進步太快了。

由此，他給創業者兩條最重要、卻有點反直覺的建議。第一：別為今天的模型而做，要為六個月後的模型而做。「這聽起來很怪，因為產品如果現在不能用，你怎麼找到 PMF？但你還是該這麼做——否則你會替今天的模型找到 PMF，然後下個月就被那些『為下一個模型而做』的人超車。」第二，就是那句 The Bitter Lesson：永遠別賭模型會輸。用模型、去摸它能力的邊界，然後為你認為六個月後會出現的那個模型而打造。

強烈的意見，
正在變得不重要

Boris 說，工程師這個職業一直訓練我們「要有強烈的意見」，資深工程師、架構師更是因此被獎勵。但隨著模型變強，很多這類意見其實已經不再相關了。所以他認為現在最重要的技能，反而是「能科學地思考、從第一性原理出發」的人——以及謙遜。他面試時很愛問一個非技術問題：「講一個你錯了的例子。」看對方能不能在事後認出自己的錯、扛下責任、並從中學到東西。「我自己大概有一半時間是錯的，半數點子都很爛，你就是得一直試。」

這種「初學者心態」之所以關鍵，是因為模型每升一級，agent 能做的事就變了，而剛畢業、沒有包袱的新人，常常比資深工程師更會用 Claude Code。他舉了個例子：團隊有次在抓記憶體洩漏，他自己照老方法 dump heap、開 DevTools 慢慢找；另一位工程師 Chris 卻直接問 Claude Code——Claude 自己寫了一個分析 heap dump 的小工具，比 Boris 更快找到漏洞。「我得不斷重新學這件事，因為我的腦袋還卡在六個月前。」

通才的威力，Boris 用工程師 Daisy 的故事說明：她加入團隊幾週後要替 Claude Code 加新功能，但她沒有自己寫，而是先開了一個 PR、給 Claude Code 一個「能測試任意工具」的工具，然後讓 Claude 自己把功能寫出來。這種跳出框架的思考，正是大多數人還沒掌握的新技能。Anthropic 內部早就用 Claude agents SDK 自動化幾乎所有開發環節：code review、security review、貼 issue 標籤、把東西推上 production。

另一個被大量使用、外界卻還在摸索的，是 sub-agent（子代理）。Boris 說，子代理本質上就是「遞迴的 Claude Code」，由主 agent 來下 prompt——團隊暱稱主 agent 叫「mama quad」。它的威力來自「不相關的 context window」：多個 agent 各自有乾淨、不被彼此污染的脈絡，丟更多 context 給問題本身就是一種 test-time compute。Boris 會依任務難度校準子代理數量：簡單就不用，很難的研究任務就叫它開 3 個、5 個、甚至 10 個並行去找。Claude Code 的 plugins 功能，就是一個工程師給了 spec、讓 Claude 在 Asana 開了一堆 ticket、再 spawn 一群 agent，整個 swarm 跑了幾天、幾乎沒有人介入就完成的。

「軟體工程師」這個職稱，
可能會消失

Boris 在 2024 年 5 月發表 Claude Code 時做過一個被全場倒抽一口氣的預測：「你以後不再需要 IDE 才能寫程式。」如今他自己從 Opus 4.5 起，100% 的程式碼都由 Claude 寫，已經解除安裝了 IDE，每天送出大約 20 個 PR、一行手寫程式都沒有。整個 Anthropic 則落在 70～90% 之間，很多團隊、很多人也都是 100%。

他特別點出這個數字有多誇張：在 Meta 時他負責全公司程式碼品質，當年團隊一年的努力換來約 2% 的生產力提升，「而 150% 這種數字，是完全聞所未聞的。」他也引用 Steve Yegge 那篇文章：一位 Anthropic 工程師如今的生產力，大約是 Google 巔峰期一位工程師的 1,000 倍——「三年前我們還在談 10x 工程師，現在在談 1000x。」

所以接下來這一年會發生什麼？Boris 說，沿著指數曲線往下畫，程式設計大致上會被「所有人」解決。他預期「軟體工程師」這個職稱會逐漸消失，變成「builder」或「product manager」；工作內容不再只是寫程式，還包括寫 spec、跟使用者聊——就像他團隊現在 PM 會寫程式、設計師會寫程式、連財務都會寫程式。「這只是下限，如果我們只是延續趨勢的話。」

訪談尾聲，Boris 把這一切連回他最在乎的事。當年他住在日本鄉下，每天早上開 Hacker News，開始用到這些早期 AI 產品時「第一次用就讓我屏息」——那種身為 builder 從未有過的感覺，最終把他帶進 Anthropic。而 Co-work（給非技術使用者的 Claude Code 圖形版）也呼應了同一套方法論：它本質上就是底層跑著 Claude Code 的桌面 App，由一位早期 Electron 貢獻者帶隊，用 Claude Code 在大約 10 天內、100% 寫出來。「我只是想做個很酷的東西，結果它居然這麼有用——這就是最讓我驚訝、也最興奮的事。而且感覺還只是剛開始。」