作者 | 高允毅

OpenAI Codex 的核心研發(fā)者，竟然成了 Claude Code 的忠實(shí)用戶？

Calvin French-Owen 是 Segment 聯(lián)合創(chuàng)始人、前 OpenAI 工程師、Codex 項(xiàng)目的早期研發(fā)者。他最近在一檔播客中，對(duì)當(dāng)前最火的代碼智能體 Codex、Claude Code 和 Cursor 進(jìn)行了銳評(píng)。

結(jié)論出人意料，他最常用、也最偏愛(ài)的，是 Claude Code，他表示搭配 Opus 模型更“香”。

Calvin 用了一個(gè)極具畫(huà)面感的比喻，來(lái)形容用 Claude Code 的體驗(yàn)：

就像殘疾人換上了一副仿生膝蓋，寫(xiě)代碼的速度直接提升了 5 倍。

在他看來(lái)，Claude Code 真正的殺手锏，是極其有效的上下文拆分能力。

面對(duì)復(fù)雜任務(wù)，Claude Code 會(huì)自動(dòng)生成多個(gè)探索型子智能體，獨(dú)立掃描代碼倉(cāng)庫(kù)、檢索上下文，再將關(guān)鍵信息匯總反饋。這種設(shè)計(jì)，顯著降低了上下文噪音，也解釋了它為何能穩(wěn)定輸出高質(zhì)量結(jié)果。

不過(guò)，他也肯定了自家產(chǎn)品，認(rèn)為 Codex 很有“個(gè)性”，像 AlphaGo。在調(diào)試復(fù)雜問(wèn)題時(shí)的表現(xiàn)上，Codex 堪稱超人類，很多 Opus 模型解決不了的問(wèn)題，Codex 都能搞定。

“上下文管理”，是 Calvin French-Owen 在整期播客中反復(fù)強(qiáng)調(diào)的關(guān)鍵詞。

他認(rèn)為，代碼的上下文信息密度極高，只要檢索方式得當(dāng)，模型往往比人類更容易理解系統(tǒng)結(jié)構(gòu)。但與此同時(shí)，上下文窗口本身，也成為制約代碼智能體發(fā)展的最大瓶頸。

提到上下文污染的問(wèn)題時(shí)，主持人表示 LLM 會(huì)變笨。Calvin 趁此分享了一個(gè)非常實(shí)用的經(jīng)驗(yàn)：當(dāng)上下文 token 占用超過(guò) 50%，他會(huì)主動(dòng)清理。

他甚至分享了一種創(chuàng)業(yè)者常用的“金絲雀檢測(cè)”方法：在上下文里埋入一些無(wú)關(guān)但可驗(yàn)證的小信息，一旦模型開(kāi)始遺忘，說(shuō)明上下文已經(jīng)被污染。

在產(chǎn)品理念上，Calvin 認(rèn)為 Claude Code 與 Codex 的差異，早已寫(xiě)進(jìn)兩家公司的基因里：

• Anthropic 更關(guān)注“做出適合人用的 AI”

• OpenAI 更關(guān)注“做出最強(qiáng)的 AI”

他判斷，從長(zhǎng)期來(lái)看，OpenAI 的路線可能是必然趨勢(shì)，但就當(dāng)下的使用體驗(yàn)而言，他更偏愛(ài) Anthropic。

在談到未來(lái)時(shí)，Calvin 給出了一個(gè)明確判斷：

• 公司會(huì)變小，但數(shù)量會(huì)變多

• 每個(gè)人都會(huì)擁有自己的智能體團(tuán)隊(duì)

• 而最先被放大的，是具備“管理者思維”的資深工程師。他們更擅長(zhǎng)拆解問(wèn)題、判斷取舍、以及在正確的節(jié)點(diǎn)上向智能體下達(dá)指令。

在這樣的背景下，產(chǎn)品的分發(fā)方式變得前所未有地重要。

自下而上的分發(fā)模式，正在以前所未有的速度擴(kuò)散。工程師不會(huì)等審批、采購(gòu)，只會(huì)用腳投票。

相比大公司對(duì)安全、合規(guī)和控制權(quán)的高度重視，開(kāi)發(fā)者更在意的，依然是那句最樸素的評(píng)價(jià)：

“這東西，真的好用。”

以下是播客精彩細(xì)節(jié)，AI Coding 干貨密集，歡迎閱讀：

我迷上了 Claude Code，它太好用了

主持人：Calvin French-Owen 是 OpenAI 旗下 Codex 代碼模型的首批研發(fā)者之一，在此之前，他創(chuàng)立了 Segment 公司，這家公司市值數(shù)十億美元，最終被知名企業(yè)高價(jià)收購(gòu)，成功實(shí)現(xiàn)資本變現(xiàn)。

Calvin French-Owen：說(shuō)實(shí)話，現(xiàn)在對(duì)我們所有人來(lái)說(shuō)，都是一段充滿變數(shù)的時(shí)期。我最近徹底迷上了 Claude Code，用一個(gè)比喻來(lái)說(shuō)，十年前我還是個(gè)馬拉松愛(ài)好者，特別喜歡跑步，結(jié)果后來(lái)膝蓋受了重傷，這之后我就進(jìn)入了所謂的 “管理者模式”，再也沒(méi)寫(xiě)過(guò)代碼，想想真的很可惜。

但過(guò)去這九天，仿佛打開(kāi)了新世界的大門(mén)，我找回了曾經(jīng)寫(xiě)代碼的所有感覺(jué)，就好像換了個(gè)全新的膝蓋，而且還是仿生的，能讓我寫(xiě)代碼的速度快了 5 倍。

主持人：你怎么看待這款工具？畢竟你一直身處這個(gè)領(lǐng)域的前沿，Codex 開(kāi)創(chuàng)的很多理念，至今仍被大家廣泛使用，而且這款模型還在持續(xù)迭代。

Calvin French-Owen：我在 OpenAI 工作時(shí)，負(fù)責(zé) Codex 的網(wǎng)頁(yè)端項(xiàng)目，當(dāng)時(shí) Cursor 這款工具剛面世，他們基于 GPT-3.5 做了一個(gè)適配層，能在 IDE 中使用。Claude Code 也剛發(fā)布，它是基于 CLI 運(yùn)行的，當(dāng)時(shí)我們就有一個(gè)想法：未來(lái)的編程，應(yīng)該更像和同事溝通 —— 你提出問(wèn)題，對(duì)方去處理，最后帶著 PR 回來(lái)反饋。我們的網(wǎng)頁(yè)端項(xiàng)目就是從這個(gè)想法出發(fā)的，這也是我們當(dāng)時(shí)的研發(fā)方向。

現(xiàn)在看來(lái)，這個(gè)大方向其實(shí)是對(duì)的。但顯然，現(xiàn)在大家都改用 CLI 編程了，不管是 Claude Code 還是 Codex，這類工具的使用頻率都高了很多。至少對(duì)我來(lái)說(shuō)，這件事帶來(lái)的啟示是，某種程度上你說(shuō)得對(duì)，未來(lái)每個(gè)人或許都會(huì)成為 “管理者”，這是我的個(gè)人觀點(diǎn)。但要達(dá)到那個(gè)階段，需要一步步來(lái)，你得真正信任模型，并且理解它的工作邏輯。

主持人：你最近一直在用 Claude Code，把它納入你的核心技術(shù)棧后，使用體驗(yàn)上有什么變化？

Calvin French-Owen：Claude Code 現(xiàn)在確實(shí)是我日常編程的主力工具。說(shuō)實(shí)話，我的主力工具每隔幾個(gè)月就會(huì)換一次。之前有段時(shí)間我特別偏愛(ài) Cursor，它新出的模型速度很快，用起來(lái)確實(shí)不錯(cuò)。后來(lái)我慢慢轉(zhuǎn)到了 Claude Code，尤其是搭配 Opus 模型使用時(shí)，體驗(yàn)更好。

Claude Code 是款很有意思的產(chǎn)品，我覺(jué)得大家都低估了它在產(chǎn)品設(shè)計(jì)與模型層面的協(xié)同表現(xiàn)。要是你深入研究就會(huì)發(fā)現(xiàn)，Claude Code 最厲害的地方，就是它的上下文拆分能力。

比如需要調(diào)用功能、讓子智能體協(xié)同工作時(shí)，你讓 Claude Code 執(zhí)行某個(gè)任務(wù)，它通常會(huì)生成一個(gè)甚至多個(gè)探索型子智能體。這些子智能體會(huì)通過(guò) ripgrep 工具掃描整個(gè)文件系統(tǒng)、檢索相關(guān)內(nèi)容，而且每個(gè)子智能體都有獨(dú)立的上下文窗口（context window）。

我認(rèn)為 Anthropic 在這點(diǎn)上做得特別出色 —— 面對(duì)一項(xiàng)任務(wù)，模型能精準(zhǔn)判斷出，這個(gè)任務(wù)適合在單個(gè)上下文窗口（context window）中完成，還是需要拆分后再執(zhí)行。模型在這方面的表現(xiàn)堪稱驚艷，這也是它能輸出高質(zhì)量結(jié)果的關(guān)鍵。

更有意思的是，依托終端運(yùn)行的特性，Claude Code 成為了實(shí)現(xiàn)可組合原子化集成的最純粹形式。如果你習(xí)慣了從 IDE 入手做開(kāi)發(fā)，比如用 Cursor 或是早期的 Codex，就會(huì)發(fā)現(xiàn)，這種更靈活的上下文檢索方式，其實(shí)并不容易自然而然地實(shí)現(xiàn)。

主持人：這一點(diǎn)確實(shí)很獨(dú)特。我個(gè)人挺意外的，不知道你有沒(méi)有這種感覺(jué)，總覺(jué)得有種復(fù)古的未來(lái)感，二十年前的 CLI 技術(shù)，居然打敗了本被寄予厚望的各類 IDE。

Calvin French-Owen：我完全認(rèn)同。而且 Claude Code 不是 IDE，這一點(diǎn)其實(shí)很關(guān)鍵，因?yàn)樗茏屇愫驼诰帉?xiě)的代碼保持一定距離。IDE 的核心就是瀏覽文件，對(duì)吧？你需要把所有代碼狀態(tài)記在腦子里，還要理清其中的邏輯。但 CLI 完全不同，這讓它在使用體驗(yàn)的設(shè)計(jì)上有了更大的發(fā)揮空間。

不知道你有沒(méi)有這種感覺(jué)，我用 Claude Code 的時(shí)候，感覺(jué)就像在代碼里 “飛馳”，各種操作都特別順暢。界面上會(huì)有小的進(jìn)度指示器，隨時(shí)給我狀態(tài)反饋，而編寫(xiě)的代碼本身反而不是視覺(jué)的核心。

開(kāi)發(fā)環(huán)境本來(lái)就很雜亂，我特別喜歡 sandbox（沙箱）在概念上的簡(jiǎn)潔性。但實(shí)際使用時(shí)，我遇到了很多棘手的問(wèn)題，比如就連簡(jiǎn)單的測(cè)試都搞不定：sandbox（沙箱）需要訪問(wèn) PostgreSQL 數(shù)據(jù)庫(kù)，卻一直連接失??；我寫(xiě)的 codex.md 文件只有二十行，最后還是無(wú)法運(yùn)行。

但在 CLI 里，工具可以直接訪問(wèn)開(kāi)發(fā)數(shù)據(jù)庫(kù)。我不確定這么做是否合規(guī)，但我確實(shí)試過(guò)讓它訪問(wèn)生產(chǎn)數(shù)據(jù)庫(kù)執(zhí)行一些操作，而且它真的做到了。比如有一次，我遇到了一個(gè)并發(fā)問(wèn)題，想排查一下，結(jié)果發(fā)現(xiàn)這款工具居然能調(diào)試五層嵌套的延遲任務(wù)，找出問(wèn)題所在，還能自動(dòng)編寫(xiě)測(cè)試用例，之后這個(gè)問(wèn)題就再也沒(méi)出現(xiàn)過(guò)。這真的太不可思議了。

主持人：沒(méi)錯(cuò)。而且我覺(jué)得產(chǎn)品的推廣和使用獲取方式，被嚴(yán)重低估了。想想 Cursor、Claude Code 還有 Codex 的命令行版本，你只需下載就能用，不用向公司申請(qǐng)任何使用權(quán)限，這一點(diǎn)帶來(lái)的使用體驗(yàn)差異，實(shí)在太大了。

做好上下文管理，

是用好頂尖模型的訣竅

主持人：你在代碼智能體領(lǐng)域有很多實(shí)踐，對(duì)于想要打造這類工具的人，你有什么建議？有哪些實(shí)戰(zhàn)經(jīng)驗(yàn)可以分享？

Calvin French-Owen：我覺(jué)得最重要的一點(diǎn)，是做好上下文管理。

當(dāng)時(shí)我們?yōu)橐豢钔评砟Ｐ痛罱藱z查點(diǎn)，隨后基于強(qiáng)化學(xué)習(xí)（RL）對(duì)它開(kāi)展了大量微調(diào)工作：我們會(huì)給模型布置各類編程相關(guān)任務(wù)，比如解決編程問(wèn)題、修復(fù)測(cè)試用例、實(shí)現(xiàn)新功能，再通過(guò)強(qiáng)化學(xué)習(xí)的方式，訓(xùn)練模型如何更精準(zhǔn)地應(yīng)對(duì)這些任務(wù)。當(dāng)然，目前大多數(shù)人還做不到這一步，但大家力所能及的是，多思考該給智能體提供哪些上下文信息，才能讓它輸出最優(yōu)的結(jié)果。

比如觀察 Claude Code 的工作過(guò)程，它會(huì)生成多個(gè)探索型子智能體，這些子智能體會(huì)去檢索文件系統(tǒng)里的各類代碼相關(guān)內(nèi)容，完成后會(huì)把上下文信息帶回來(lái)并為我做好總結(jié)，我就能清楚后續(xù)該怎么推進(jìn)工作了。

看不同智能體的上下文構(gòu)建方式，是件特別有意思的事。比如 Cursor 用的是語(yǔ)義搜索的方式，它會(huì)把所有內(nèi)容轉(zhuǎn)化為向量形式，再匹配和查詢需求最相關(guān)的內(nèi)容；而 Codex 和 Claude Code，其實(shí)用的都是 ripgrep 這個(gè)代碼搜索工具。這種方式之所以管用，是因?yàn)榇a的上下文信息密度很高。一行代碼通常不到 80 個(gè)字符，代碼倉(cāng)庫(kù)里不會(huì)有太多大數(shù)據(jù)塊或 JSON 格式的文件，就算有，數(shù)量也極少。

你可以參考 Git（代碼版本管理工具）的忽略規(guī)則，先過(guò)濾掉無(wú)關(guān)內(nèi)容或是已打包的文件，再通過(guò) Git 和 ripgrep 查找代碼的上下文，這樣就能很好地理解代碼的實(shí)際功能了。同時(shí)這類工具還能自動(dòng)掃描整個(gè)文件夾的結(jié)構(gòu)，而且 LLM（大語(yǔ)言模型）特別擅長(zhǎng)生成復(fù)雜的 Git 命令，這些命令讓人類手動(dòng)寫(xiě)的話，簡(jiǎn)直是種折磨。而這一整套操作，其實(shí)就是強(qiáng)化學(xué)習(xí)（RL）在實(shí)際場(chǎng)景中的落地應(yīng)用。

我現(xiàn)在也在做非編程領(lǐng)域的智能體集成系統(tǒng)，從代碼智能體的研發(fā)過(guò)程中，我也學(xué)到了很多：要把數(shù)據(jù)轉(zhuǎn)換成接近代碼的格式，讓模型能快速檢索到相關(guān)的周邊信息，進(jìn)而獲取到結(jié)構(gòu)化的有效數(shù)據(jù)。

主持人：優(yōu)秀的代碼智能體，核心能力就是上下文工程，那要成為這類工具的前 1% 頂尖用戶，有什么技巧？你的技術(shù)棧是怎樣的？你是如何借助這些工具大幅提升效率的？

Calvin French-Owen：第一個(gè)技巧，是盡量減少底層代碼和基礎(chǔ)架構(gòu)的編寫(xiě)。

我平時(shí)會(huì)在 Vercel、Next.js 或 Cloudflare Workers 這些平臺(tái)部署技術(shù)棧，這些平臺(tái)已經(jīng)封裝了大量樣板代碼，不用自己費(fèi)心搭建各類服務(wù)，也不用處理服務(wù)發(fā)現(xiàn)、中心端點(diǎn)注冊(cè)、數(shù)據(jù)庫(kù)配置這些問(wèn)題。所有功能基本都能在一兩百行代碼內(nèi)實(shí)現(xiàn)。我也傾向于采用微服務(wù)架構(gòu)，或者使用結(jié)構(gòu)清晰的獨(dú)立軟件包。

其次，要了解 LLM 的核心優(yōu)勢(shì)。

其實(shí)代碼智能體的特點(diǎn)，Andrej Karpathy 最近也在推特上提到過(guò)：它們的執(zhí)行力極強(qiáng)，不管遇到什么問(wèn)題，都會(huì)一直嘗試解決，最終往往會(huì)在現(xiàn)有基礎(chǔ)上做更多的拓展。所以如果你想引導(dǎo)它完成某個(gè)任務(wù)，一定要明確指令。這里可以稍微拿 OpenAI 舉個(gè)例子，他們有一個(gè)龐大的 monorepo（單體代碼倉(cāng)庫(kù)），已經(jīng)用了好幾年，有成千上萬(wàn)的工程師在上面提交代碼。這些工程師里，有經(jīng)驗(yàn)豐富的資深開(kāi)發(fā)者，他們精通生產(chǎn)環(huán)境代碼的編寫(xiě)；也有剛畢業(yè)的博士，編程經(jīng)驗(yàn)相對(duì)欠缺。人員構(gòu)成差異很大，所以 LLM 會(huì)根據(jù)你的引導(dǎo)方向，學(xué)習(xí)不同的代碼風(fēng)格。我覺(jué)得代碼智能體還有很大的探索空間，比如研究出最優(yōu)的代碼生成范式。顯然，給模型提供自我校驗(yàn)的方式，能大幅提升它的表現(xiàn)，比如盡可能多地在代碼檢查、CI 等環(huán)節(jié)運(yùn)行測(cè)試用例。

我自己也會(huì)頻繁使用代碼審查機(jī)器人，YC 孵化的 Reptile 公司做的這款機(jī)器人用起來(lái)就特別順手；Cursor 的漏洞檢測(cè)機(jī)器人也很好用，我也常常用 Codex 做代碼審查，它在校驗(yàn)代碼正確性這塊的表現(xiàn)尤其突出。

這些都是代碼智能體格外擅長(zhǎng)的領(lǐng)域，除此之外，它們探索代碼倉(cāng)庫(kù)的能力也很出色。

當(dāng)然，智能體也有短板：它們擅長(zhǎng)做拓展，但如果你的需求不是拓展功能，它們往往會(huì)重復(fù)編寫(xiě)代碼，浪費(fèi)大量時(shí)間做已經(jīng)實(shí)現(xiàn)過(guò)的功能，這時(shí)候你就會(huì)覺(jué)得 “它完全沒(méi)理解我的需求”。

還有一個(gè)問(wèn)題是上下文污染，智能體可能會(huì)陷入某個(gè)循環(huán)，因?yàn)閳?zhí)行力強(qiáng)，會(huì)一直沿著錯(cuò)誤的方向推進(jìn)，而它參考的上下文信息，其實(shí)對(duì)于解決問(wèn)題毫無(wú)幫助。所以我常用的一個(gè)方法，是主動(dòng)清理上下文，比如當(dāng)上下文的 token 占用率超過(guò) 50% 時(shí)，就及時(shí)清理。

主持人：哇，這個(gè)比例其實(shí)特別關(guān)鍵。不知道你有沒(méi)有關(guān)注到，YC（Y Combinator 的縮寫(xiě)，全球頂級(jí)的創(chuàng)業(yè)孵化器）2024 年秋季孵化營(yíng)里，那家做 HumanLayer（人類層）的公司，創(chuàng)始人 Dex Horthy 就總聊這個(gè)話題，還專門(mén)提出了 “LLM 愚笨區(qū)”的概念：當(dāng)上下文的 token 數(shù)量達(dá)到某個(gè)閾值后，模型的輸出質(zhì)量就會(huì)開(kāi)始下滑。

Calvin French-Owen：我完全認(rèn)同這個(gè)觀點(diǎn)，結(jié)合強(qiáng)化學(xué)習(xí)（RL）的工作邏輯來(lái)看，這一點(diǎn)就更明顯了。

想象一下，你是一名參加考試的大學(xué)生，考試剛開(kāi)始的五分鐘，你會(huì)覺(jué)得時(shí)間很充裕，一定能好好答題，認(rèn)真思考每個(gè)問(wèn)題；但如果只剩五分鐘，試卷還有一半沒(méi)做完，你就會(huì)慌不擇路，只求盡快寫(xiě)完。LLM 的上下文窗口（context window），就是這個(gè)道理。

創(chuàng)業(yè)者們有一個(gè)小技巧，我覺(jué)得很實(shí)用：在上下文開(kāi)頭加一個(gè) “金絲雀檢測(cè)” 信息，就是一些特別小眾甚至有趣的內(nèi)容，比如 “我叫 Calvin French-Owen，早上八點(diǎn)喝了茶” 這類無(wú)關(guān)的小事實(shí)。然后在和模型的交互過(guò)程中，時(shí)不時(shí)問(wèn)它 “你記得我叫什么嗎？”“你記得我?guī)c(diǎn)喝的茶嗎？”，如果它開(kāi)始忘記這些信息，就說(shuō)明上下文已經(jīng)被污染了。這是我見(jiàn)過(guò)很多人用的方法，我自己還沒(méi)試過(guò)，但完全相信它的效果。

主持人：這個(gè)方法很有意思。我在模型做上下文壓縮前，還沒(méi)遇到過(guò)這類問(wèn)題，可能是我沒(méi)太留意。你是說(shuō)，token 數(shù)超標(biāo)后，模型會(huì)開(kāi)始做出一些不合理的操作？我得留意一下，這個(gè)問(wèn)題能在 Claude Code 內(nèi)部解決嗎？比如讓模型自己做檢測(cè)，在上下文里加入類似 “心跳檢測(cè)” （通過(guò)定期發(fā)送 “狀態(tài)確認(rèn)信號(hào)”，實(shí)時(shí)監(jiān)控目標(biāo)對(duì)象的運(yùn)行狀態(tài)，一旦信號(hào)異常就觸發(fā)預(yù)警或處理）的機(jī)制，實(shí)時(shí)監(jiān)控狀態(tài)。

Calvin French-Owen：理論上可以，但目前還做不到。我認(rèn)同你的終極設(shè)想，但現(xiàn)在要做好上下文管理，依然很難。目前的解決辦法，還是拆分上下文窗口（context window），然后嘗試合并信息，但 Claude Code 的會(huì)話結(jié)束后，上下文的內(nèi)容就是固定的，這一點(diǎn)還是有局限。

有意思的是，Codex 采用了完全相反的策略，OpenAI 的博客最近也提到了：它會(huì)在每次交互后定期做上下文壓縮，所以 Codex 能長(zhǎng)時(shí)間持續(xù)運(yùn)行。你看 CLI 里的 token 占用百分比，就能看到它會(huì)隨著壓縮操作上下浮動(dòng)。

Anthropic 要做人用的，

OpenAI 要做最好的，以及產(chǎn)品分發(fā)模式很重要

主持人：看來(lái) Claude Code 和 Codex 的架構(gòu)差異很大，Codex 似乎更適合長(zhǎng)時(shí)間運(yùn)行的任務(wù)，所以二者的使用場(chǎng)景不同，架構(gòu)設(shè)計(jì)也天差地別?，F(xiàn)在看來(lái)，CLI 的工具越來(lái)越火，2026 年可能會(huì)成為 “CLI 元年”。

但同時(shí)也有觀點(diǎn)認(rèn)為，通用人工智能已經(jīng)到來(lái)，超級(jí)人工智能也近在咫尺。目前的代碼智能體已經(jīng)非常智能，但還達(dá)不到自主長(zhǎng)時(shí)間運(yùn)行的程度，如果計(jì)算能力提升十倍，能實(shí)現(xiàn) 24 小時(shí)甚至 48 小時(shí)的自主任務(wù)運(yùn)行嗎？Codex 的架構(gòu)，能適配這種場(chǎng)景嗎？

Calvin French-Owen：這是個(gè)很好的問(wèn)題，答案其實(shí)藏在兩家公司的創(chuàng)立基因里。

Anthropic 一直很注重打造適合人類使用的工具，比如會(huì)關(guān)注模型的輸出風(fēng)格、語(yǔ)氣，以及如何和用戶的其他工作流程適配，Claude Code 就是這一理念的自然延伸。在很多方面，它的工作方式和人類很像：比如你要建一個(gè)狗窩，人類會(huì)去五金店買(mǎi)材料，然后研究如何組裝，Claude Code 也是如此。

而 OpenAI 的核心思路，是訓(xùn)練出最優(yōu)秀的模型，通過(guò)持續(xù)的強(qiáng)化學(xué)習(xí)（RL），讓它能處理更長(zhǎng)期、更復(fù)雜的任務(wù)，最終實(shí)現(xiàn)通用人工智能。所以它的模型，工作方式可能和人類完全不同。還是以建狗窩為例，就像 AlphaGo 的下棋思路和人類不同一樣，OpenAI 的模型可能會(huì)直接用 3D 打印機(jī)，從零開(kāi)始打印出一個(gè)狗窩，完全符合你的需求，過(guò)程可能會(huì)很長(zhǎng)，成品也會(huì)高度定制化，甚至有些設(shè)計(jì)會(huì)很怪異，但最終能實(shí)現(xiàn)功能。

或許從長(zhǎng)遠(yuǎn)來(lái)看，這才是正確的方向，所以很期待兩家公司的后續(xù)發(fā)展。總的來(lái)說(shuō)，OpenAI 的路線似乎是必然趨勢(shì)，但我個(gè)人更喜歡 Anthropic 的思路。十年前，我還會(huì)自己寫(xiě)一些奇怪的腳本，在重構(gòu)代碼或理解代碼邏輯時(shí)，用它來(lái)梳理各類信息，而 Claude Code 給我的感覺(jué)，和當(dāng)年的這種體驗(yàn)一模一樣，用它一天，能完成五個(gè)人的工作量，就像給編程裝上了火箭助推器，太不可思議了。

主持人：很期待不同規(guī)模的公司，會(huì)如何應(yīng)用這類工具。我發(fā)現(xiàn)，不管是業(yè)余愛(ài)好者，還是小型創(chuàng)業(yè)公司，都在盡可能挖掘代碼智能體的潛力，因?yàn)樗麄兏緵](méi)時(shí)間研究其他方法。創(chuàng)業(yè)公司的資金和時(shí)間都有限，一切都要以速度為核心。但大公司不一樣，他們有太多東西可以失去，還有各種代碼審查的內(nèi)部流程，也已經(jīng)組建了龐大的技術(shù)團(tuán)隊(duì)。

未來(lái)可能會(huì)出現(xiàn)一種很有趣的現(xiàn)象：一個(gè)人組成的小團(tuán)隊(duì)，看到其他團(tuán)隊(duì)的工作效率低，就會(huì)自己用代碼智能體做一個(gè)原型，效果反而更好?？傆幸惶?，這種小團(tuán)隊(duì)的成果會(huì)超越大團(tuán)隊(duì)，行業(yè)格局的轉(zhuǎn)變，一定會(huì)很有意思。

Calvin French-Owen：其實(shí)前幾天我試了一款產(chǎn)品，它的用法很有意思：你下載一個(gè)桌面應(yīng)用，它會(huì)調(diào)用你電腦上運(yùn)行的 Claude Code，再通過(guò) MCP 服務(wù)器和桌面應(yīng)用通信。這種方式讓電腦的使用變得很不一樣，你不用征得任何人同意，下載后直接用就行。

在這個(gè)變化飛快的時(shí)代，產(chǎn)品的分發(fā)模式真的太重要了，自下而上的模式遠(yuǎn)比自上而下好，因?yàn)楹笳叩男蕦?shí)在太低。公司的首席技術(shù)官總會(huì)顧慮安全、隱私問(wèn)題，擔(dān)心各種突發(fā)情況，想要絕對(duì)的控制權(quán)，但工程師們只會(huì)直接裝上工具開(kāi)始用，然后感嘆 “這東西太好用了”。

主持人：你說(shuō)得太對(duì)了。我本身是做企業(yè)級(jí) ToB 業(yè)務(wù)的，總覺(jué)得自上而下的銷售模式能構(gòu)建一定的競(jìng)爭(zhēng)壁壘，肯定會(huì)有公司找到方法，做出一款人人都能用上的產(chǎn)品，或許先從個(gè)人用戶切入會(huì)是個(gè)思路。

當(dāng)年的網(wǎng)景導(dǎo)航器（互聯(lián)網(wǎng)早期最具里程碑意義的網(wǎng)頁(yè)瀏覽器）就是如此，它對(duì)非商業(yè)用途免費(fèi)，結(jié)果很多人下載后用在商業(yè)場(chǎng)景，網(wǎng)景就通過(guò)追蹤 IP 地址，統(tǒng)計(jì)不同公司的使用量，然后告知對(duì)方 “你們違規(guī)使用了，只需購(gòu)買(mǎi)授權(quán)就能繼續(xù)用”。我很好奇，這種模式現(xiàn)在還能復(fù)制嗎？

Calvin French-Owen：你關(guān)于分發(fā)模式的觀點(diǎn)很有意思，現(xiàn)在很多人甚至?xí)苯痈鶕?jù) Claude Code 的建議做架構(gòu)決策，他們可能都不知道該用什么分析工具，只要 Claude Code 說(shuō)用 PostHog（ YC W2020 批次孵化的開(kāi)源平臺(tái) PostHog，核心定位是給開(kāi)發(fā)者和產(chǎn)品團(tuán)隊(duì)的 “全能型產(chǎn)品優(yōu)化工具箱”），他們就會(huì)百分百采用。

我做顧問(wèn)的一家公司，最近聊到了他們的生成式優(yōu)化策略，也就是如何在聊天機(jī)器人中優(yōu)化展示效果。他們說(shuō)有件事特別有趣：競(jìng)爭(zhēng)對(duì)手整理了一份行業(yè)內(nèi)必用的五大工具榜單，自己的產(chǎn)品當(dāng)然排在第一位。明眼人一看就知道這是偏見(jiàn)，榜單里的頭部工具就是他們自己的產(chǎn)品。但 LLM 會(huì)被這種信息誤導(dǎo)，它會(huì)整合各類上下文信息，然后判定 “這是行業(yè)頂級(jí)工具”，接著直接推薦給用戶。

我覺(jué)得做開(kāi)發(fā)者工具的話，完善的文檔、真實(shí)的用戶口碑，甚至在 Reddit 上的一些討論，這些都能極大地提升產(chǎn)品的認(rèn)可度，這也是很多開(kāi)源項(xiàng)目能快速崛起的原因。

Supabase 就是個(gè)典型例子，它去年發(fā)展得特別快，部分原因就是它的開(kāi)源文檔做得特別好，詳細(xì)教大家如何搭建各類功能。只要有人問(wèn)如何搭建類似 Firebase 的后端事務(wù)系統(tǒng)，LLM 給出的默認(rèn)答案幾乎都是 Supabase。我親自試過(guò)很多次，結(jié)果都是這樣。它就像當(dāng)年的 Stack Overflow 和谷歌搜索一樣，占據(jù)了互聯(lián)網(wǎng)的信息入口，現(xiàn)在大家甚至都不用谷歌了，想想真的很神奇。而且這種模式對(duì)開(kāi)源項(xiàng)目的利好是不成比例的。

不知道你有沒(méi)有看到，Ramp 公司最近發(fā)了一篇博客，講他們?nèi)绾未蛟熳匝械拇a智能體，里面提到他們用開(kāi)源代碼作為框架，因?yàn)槟Ｐ涂梢灾苯幼x取源代碼，理解其工作邏輯。我對(duì)開(kāi)源產(chǎn)品一直這么做：克隆代碼倉(cāng)庫(kù)，然后啟動(dòng) Codex 或 Claude Code，讓它講解代碼的邏輯，用起來(lái)特別實(shí)用。

未來(lái)公司會(huì)變小，

數(shù)據(jù)很重要

主持人：我們不妨?xí)诚胍幌滤氖旰蟮奈磥?lái)：軟件、數(shù)據(jù)庫(kù)、訪問(wèn)控制依然存在，但軟件的核心會(huì)高度個(gè)性化。訪問(wèn)控制、權(quán)限分配這類事，依然是大家開(kāi)會(huì)討論的重點(diǎn)，也就是所謂的 “管理者模式”，但公司的其他所有功能、規(guī)則，都由員工通過(guò)自己的 Claude Code 這類工具定義?？赡苓€是 CLI，也可能是由大量智能體組成的協(xié)作體系，那會(huì)是一種怎樣的場(chǎng)景？

比如想象一下，現(xiàn)在如果有公司要接入 Segment，我們復(fù)刻代碼倉(cāng)庫(kù)，給他們一個(gè)專屬版本，讓它在自己的服務(wù)器上運(yùn)行；如果他們想做修改，只需在聊天窗口告訴智能體，智能體通過(guò)代碼循環(huán)完成編輯，而 Segment 總公司推出新功能后，智能體還能自動(dòng)完成版本合并。

Calvin French-Owen：我完全能想象出這種場(chǎng)景，這也是我一直在思考的。雖然不知道這個(gè)未來(lái)還有多遠(yuǎn)，但最終，每個(gè)工作的人都會(huì)有自己的云電腦和專屬的云智能體團(tuán)隊(duì)，智能體替自己處理各類事務(wù)，彼此之間也會(huì)溝通協(xié)作。這就像有一個(gè)超級(jí)執(zhí)行助理，它會(huì)告訴你 “這些是你需要關(guān)注的事”“你可以快速做這些決策”“這件事需要你多花時(shí)間”“你該和這些人見(jiàn)面溝通”。我覺(jué)得，人與人之間面對(duì)面交流、交換想法的需求，永遠(yuǎn)不會(huì)消失，至少我能從這種交流中獲得很大的滿足感。除此之外，會(huì)有大量的智能體替人類執(zhí)行任務(wù)，實(shí)現(xiàn)各類工作的自動(dòng)化。

未來(lái)的公司，平均規(guī)模可能會(huì)變小，但數(shù)量會(huì)更多，能做的事也會(huì)更多。我還很好奇，Paul Graham 提出的 Maker Schedule（創(chuàng)作者日程：給做核心創(chuàng)作 、研發(fā)的人用的，需要大塊、連續(xù)、不被打斷的時(shí)間） 和 Manager Schedule（管理者日程：給做管理、協(xié)調(diào)、溝通的人用的，時(shí)間是碎片化、以小時(shí)為單位的，充滿會(huì)議、溝通、臨時(shí)決策，習(xí)慣頻繁切換事務(wù)），未來(lái)會(huì)演變成什么樣子。

在 YC，我們的工作基本都是 Manager Schedule（管理者日程），這讓我們很難有時(shí)間自己寫(xiě)代碼、做產(chǎn)品。但現(xiàn)在有了代碼智能體，一切都變了，很多合伙人開(kāi)會(huì)時(shí)，就像這期播客剛開(kāi)始時(shí)我做的一樣，讓智能體后臺(tái)運(yùn)行處理任務(wù)，自己專注開(kāi)會(huì)，等會(huì)開(kāi)完，任務(wù)也完成了。

主持人：沒(méi)錯(cuò)，就是利用碎片化時(shí)間。以前編程，至少需要四個(gè)小時(shí)的整塊時(shí)間，否則根本不值得開(kāi)始，對(duì)吧？這其實(shí)也反映出編程方式的巨大變化：以前寫(xiě)代碼，你需要把所有類名、函數(shù)、關(guān)聯(lián)的代碼都記在腦子里，構(gòu)建自己的“上下文窗口”，這個(gè)過(guò)程需要好幾個(gè)小時(shí)，所以想用十分鐘的碎片化時(shí)間編程，根本不可能，只會(huì)讓人覺(jué)得沮喪。

Calvin French-Owen：我覺(jué)得未來(lái)的核心基礎(chǔ)能力之一，依然是保持?jǐn)?shù)據(jù)模型的一致性，而核心的記錄系統(tǒng)，也有機(jī)會(huì)率先實(shí)現(xiàn)智能體化。現(xiàn)在我們的工作，還是高度依賴數(shù)據(jù)庫(kù)，以及底層的 SQL 或 NoSQL 查詢，但未來(lái)或許會(huì)出現(xiàn)一種工具，能為定制化軟件的各類視圖，自動(dòng)生成所需的所有數(shù)據(jù)。

未來(lái)的軟件世界，會(huì)有大量定制化視圖，但數(shù)據(jù)的準(zhǔn)確性，依然是核心前提。數(shù)據(jù)的重要性不言而喻，這一點(diǎn)從很多公司的做法中就能看出來(lái)：比如很多公司通過(guò) API 或 MCP 開(kāi)放數(shù)據(jù)訪問(wèn)權(quán)限，而 Slack(全球最主流的企業(yè)級(jí)團(tuán)隊(duì)協(xié)作與即時(shí)溝通平臺(tái)，常被稱作「硅谷版釘釘 / 企業(yè)微信」) 就收緊了 API 的權(quán)限，因?yàn)樗麄儾幌胱層脩舭哑脚_(tái)上的所有數(shù)據(jù)都導(dǎo)出，然后基于這些數(shù)據(jù)搭建智能體應(yīng)用。

主持人：你對(duì)這款智能體的了解很深，那你覺(jué)得，這類工具普及后，哪種類型的工程師會(huì)受益更多？

Calvin French-Owen：總的來(lái)說(shuō)，工程師的資歷越深，受益就越多。因?yàn)橹悄荏w特別擅長(zhǎng)把想法轉(zhuǎn)化為實(shí)際行動(dòng)，如果你能用幾句話清晰地描述需求，就能立刻讓它落地。

我在瀏覽開(kāi)源代碼倉(cāng)庫(kù)時(shí)，經(jīng)常會(huì)有這種感受：看到某處代碼，覺(jué)得可以優(yōu)化，只要把這個(gè)想法告訴智能體，讓它去執(zhí)行，最后等待反饋就行。這種方式能極大地提升效率，放大個(gè)人的影響力。

其次，能判斷哪些代碼修改在架構(gòu)層面是合理的、哪些是不合理的，或者能準(zhǔn)確判斷該在哪個(gè)節(jié)點(diǎn)向智能體發(fā)出指令，這一點(diǎn)也很重要。我覺(jué)得做事有條理、帶有 “管理者思維” 的工程師，會(huì)更適配這類工具。

而且目前來(lái)看，這個(gè)領(lǐng)域還缺少一款核心產(chǎn)品，比如類似 Conductor 這樣的工具，能整合你所有的會(huì)話，提醒你 “這個(gè)任務(wù)已經(jīng)完成，需要你確認(rèn)”“你該把注意力轉(zhuǎn)到另一個(gè)任務(wù)上了”。Conductor（核心解決 AI 編程的 “失憶問(wèn)題）這類工具，應(yīng)該給智能體加上上下文管理功能，其實(shí)人類也需要這樣的上下文管理工具，這一點(diǎn)是毋庸置疑的。

主持人：如果讓你回到大學(xué)，重新學(xué)習(xí)計(jì)算機(jī)科學(xué)，讓你自己制定課程表，你會(huì)選擇學(xué)習(xí)哪些內(nèi)容？

Calvin French-Owen：就我個(gè)人而言，理解各類系統(tǒng)的工作原理，依然是最重要的。比如 Git、HTTP、隊(duì)列這類數(shù)據(jù)庫(kù)，了解這些系統(tǒng)的基礎(chǔ)概念，至關(guān)重要。另外，我會(huì)專門(mén)安排一個(gè)學(xué)期，每周都動(dòng)手做項(xiàng)目，盡全力挖掘模型的潛力。

在使用模型的過(guò)程中，你會(huì)發(fā)現(xiàn)，遇到問(wèn)題時(shí)，總能向上層抽象，讓模型來(lái)解決。比如你可以給模型一個(gè) “實(shí)現(xiàn)” 命令，讓它完成計(jì)劃的下一階段；也可以給一個(gè) “全部實(shí)現(xiàn)” 命令，讓它分階段執(zhí)行，生成新的子智能體；還能給一個(gè) “校驗(yàn)” 命令，讓它自查成果。模型的能力邊界一直在變化，所以多動(dòng)手嘗試，是很有必要的。

還有一件事讓我覺(jué)得很有意思，我特別想教 18 到 22 歲的年輕人做產(chǎn)品。我們這桌人，都做出過(guò)用戶真正需要、真正喜歡的產(chǎn)品，該怎么把這種能力教給年輕人，是一個(gè)值得思考的問(wèn)題。我很好奇，五年后的年輕人，會(huì)不會(huì)在產(chǎn)品審美等方面遠(yuǎn)超現(xiàn)在的我們？因?yàn)樗麄兡芙柚悄荏w，做出更多的嘗試，產(chǎn)出更多的成果。他們本就該如此，不是嗎？他們的產(chǎn)品落地速度、接觸現(xiàn)實(shí)的機(jī)會(huì)，應(yīng)該是上一代人的十倍。

主持人：說(shuō)到這里，我有一個(gè)疑問(wèn)，不知道你有沒(méi)有這種感受：我小時(shí)候，媽媽總跟我說(shuō) “別一心二用，根本沒(méi)認(rèn)真聽(tīng)我說(shuō)話”。這話其實(shí)有道理，我當(dāng)時(shí)確實(shí)盯著電腦，沒(méi)認(rèn)真聽(tīng)，但我發(fā)現(xiàn)，我比父母那一代人更擅長(zhǎng)多任務(wù)處理。而現(xiàn)在的年輕人，比我們更厲害，因?yàn)樗麄兂砷L(zhǎng)在互聯(lián)網(wǎng)時(shí)代，每天接觸抖音這類短視頻，應(yīng)對(duì)各種碎片化信息。我覺(jué)得，未來(lái)既需要能深度思考的人 —— 他們能專注觀察、理解問(wèn)題、解決問(wèn)題，也需要能靈活切換場(chǎng)景的人 —— 他們能同時(shí)處理多個(gè)任務(wù)，不斷切換上下文，也就是所謂的 “注意力缺陷多動(dòng)障礙模式”。

Calvin French-Owen：沒(méi)錯(cuò)，新一代的年輕人特別擅長(zhǎng)這一點(diǎn)。我一直覺(jué)得，有一種聰明人，或許是帶有注意力缺陷多動(dòng)障礙的特質(zhì)，他們腦子里同時(shí)醞釀著很多好項(xiàng)目，但從來(lái)沒(méi)有真正完成過(guò)一個(gè)。我自己可能就有點(diǎn)這種性格。我之前發(fā)布了自己的氛圍代碼，其實(shí)如果不是 Claude Code，我根本完不成。

我覺(jué)得，有些人的大腦就像有十個(gè)分支同時(shí)運(yùn)轉(zhuǎn)，但一天的時(shí)間有限，根本沒(méi)法把所有想法都落地，所以項(xiàng)目總是半途而廢。而現(xiàn)在，Claude Code 能幫我把所有想法都落地。你在博客里也提到過(guò)，用它的感覺(jué)就像玩電子游戲，總有新鮮感。比如你開(kāi)始做一個(gè)項(xiàng)目，做到一半覺(jué)得無(wú)聊，又有了新的想法，想先做新想法，再回頭做原來(lái)的項(xiàng)目，以前這么做，很容易半途而廢，但現(xiàn)在有了智能體，兩個(gè)項(xiàng)目最終都能完成。

主持人：十歲的孩子每天都有寫(xiě)作作業(yè)，昨天他第一次用人工智能寫(xiě)作業(yè)，我一看就知道，那些表達(dá)根本不是一個(gè)十歲孩子能寫(xiě)出來(lái)的。

這讓我想到，我們現(xiàn)在和很多 18 到 22 歲的年輕人合作，他們有實(shí)習(xí)經(jīng)歷，但沒(méi)有做過(guò)管理工作，不懂產(chǎn)品市場(chǎng)匹配后的運(yùn)營(yíng)邏輯 —— 當(dāng)你面對(duì)數(shù)百萬(wàn)的任務(wù)隊(duì)列、數(shù)十萬(wàn)的錯(cuò)誤日志時(shí)，才是真正的管理工作。這份工作其實(shí)很枯燥，要逐行排查錯(cuò)誤日志，還要在后臺(tái)手動(dòng)確保產(chǎn)品對(duì)所有用戶都能正常運(yùn)行。

新一代的開(kāi)發(fā)者，該如何理解這些內(nèi)容？Claude Code 這樣的智能體，能教他們架構(gòu)設(shè)計(jì)這類知識(shí)嗎？還是說(shuō)，他們只能自己踩坑試錯(cuò)，在摸索中成長(zhǎng)？

Calvin French-Owen：我做產(chǎn)品的過(guò)程中，花最多時(shí)間思考的，就是產(chǎn)品的核心范式：用戶現(xiàn)在需要理解哪些內(nèi)容？他們能借助哪些基礎(chǔ)能力，實(shí)現(xiàn)自己的各類需求？我總喜歡用 Slack 舉例子，它其實(shí)算不上什么全新的概念，在此之前已經(jīng)有很多聊天工具了，但它把頻道、消息、互動(dòng)功能做的極簡(jiǎn)，普通人一看就懂，知道該怎么用，這就是它的成功之處。但一旦用戶習(xí)慣了這種模式，后續(xù)再想改變就很難了，比如想改成以文檔為核心，或者現(xiàn)在想加入智能體功能，都很難改變用戶的固有認(rèn)知。所以我做產(chǎn)品時(shí)，從一開(kāi)始就會(huì)仔細(xì)考慮這一點(diǎn)，因?yàn)榻o代碼智能體設(shè)定的核心規(guī)則，會(huì)成為它一直遵循的準(zhǔn)則，并且不斷拓展延伸。

代碼智能體的制約因素有哪些

主持人：說(shuō)到這里，我很好奇，如果現(xiàn)在讓你用當(dāng)下的工具，重新打造 Segment，你會(huì)怎么做？

Calvin French-Owen：Segment 的業(yè)務(wù)其實(shí)很有意思，我們最初的核心，是做各類集成功能：把相同的數(shù)據(jù)，對(duì)接至 Mixpanel、Kissmetrics、谷歌分析等平臺(tái)。以前寫(xiě)這類集成代碼，繁瑣又困難，所以用戶愿意付費(fèi)使用。但現(xiàn)在，這項(xiàng)工作的價(jià)值幾乎降為零，甚至很多時(shí)候，你直接告訴 Claude Code 或 Codex“我想這樣做數(shù)據(jù)映射，需要這個(gè)特定功能”，它就能精準(zhǔn)實(shí)現(xiàn)，完全契合你的需求。所以 Segment 的集成業(yè)務(wù)，價(jià)值已經(jīng)大幅縮水。

但保持?jǐn)?shù)據(jù)管道（data pipeline）的穩(wěn)定運(yùn)行、實(shí)現(xiàn)業(yè)務(wù)流程的自動(dòng)化，比如客戶注冊(cè)時(shí)，通過(guò) Customer IO 自動(dòng)發(fā)送郵件、管理用戶群體，這些功能的價(jià)值依然存在，而且還有很大的拓展空間。

比如借助這些數(shù)據(jù)構(gòu)建完整的用戶畫(huà)像（user profile），再讓小型大模型（LLM）智能體分析：該如何給用戶推送郵件？用戶登錄時(shí)，是否要調(diào)整產(chǎn)品的部分功能？是否要根據(jù)用戶的不同特征，設(shè)計(jì)差異化的引導(dǎo)流程？這些都是很有意思的方向，而且都能通過(guò)智能體實(shí)現(xiàn)。

這也是我會(huì)做出的核心改變：就像你之前說(shuō)的，向技術(shù)棧上層遷移，摒棄底層的基礎(chǔ)開(kāi)發(fā)工作，更多聚焦在營(yíng)銷活動(dòng)這類更抽象的業(yè)務(wù)層面發(fā)力。

主持人：沒(méi)錯(cuò)。我特別驚訝的是，Claude Code 僅憑我正在做的項(xiàng)目的上下文，就能精準(zhǔn)理解我的需求和意圖。我至今依然覺(jué)得代碼智能體很神奇：你把代碼倉(cāng)庫(kù)的副本給它，留個(gè)簡(jiǎn)單的指令，比如 “實(shí)現(xiàn)這個(gè)功能”，它就能完成。大多數(shù)情況下，它根本不知道你的公司是做什么的、你的用戶是誰(shuí)，或許因?yàn)橛?xùn)練數(shù)據(jù)里有我的信息，它知道我是加里，但它能完成任務(wù)這件事，本身就令人難以置信。這也能看出上下文的重要性，對(duì)吧？如果它捕捉到的上下文信息有誤，就會(huì)偏離方向；如果遺漏了關(guān)鍵信息，就會(huì)重復(fù)造輪子。

你覺(jué)得目前代碼智能體的發(fā)展，還有哪些制約因素？上下文窗口的限制依然存在，但現(xiàn)在的窗口已經(jīng)很大了，雖然還做不了大規(guī)模的架構(gòu)重構(gòu)，但很多任務(wù)都能完成。Opus4.5 模型的智能程度有了很大提升，帶來(lái)了很大的突破，我不知道這是預(yù)訓(xùn)練還是后訓(xùn)練的成果。除了基礎(chǔ)的模型智能、前沿模型的能力和上下文窗口，還有哪些因素能推動(dòng)它的發(fā)展？

Calvin French-Owen：我依然覺(jué)得，上下文窗口是目前最大的制約因素。觀察 Claude Code 的執(zhí)行過(guò)程就會(huì)發(fā)現(xiàn)，它會(huì)把任務(wù)委托給多個(gè)不同的上下文窗口，每個(gè)窗口完成任務(wù)后，會(huì)反饋總結(jié)后的信息，所以模型其實(shí)無(wú)法獲取完整的上下文。如果一個(gè)任務(wù)的復(fù)雜度太高，單個(gè)上下文窗口根本容納不下，那么無(wú)論怎么壓縮，都無(wú)濟(jì)于事。Anthropic 的子上下文窗口委托策略，確實(shí)很實(shí)用，但這依然是一個(gè)難以突破的壁壘。如果每次都能有百萬(wàn)級(jí) token 的上下文窗口，效果會(huì)好得多。

而且我們還需要找到更好的方法，專門(mén)訓(xùn)練模型處理長(zhǎng)上下文的能力。互聯(lián)網(wǎng)上有大量的訓(xùn)練數(shù)據(jù)，能讓模型預(yù)測(cè)下一句話、下一個(gè)段落是什么，但如果有 8 萬(wàn)個(gè) token 的上下文，模型需要根據(jù)其中 2 萬(wàn)個(gè) token 的信息，判斷下一步該做什么，這就困難多了。

我覺(jué)得，集成和編排能力，正在成為新的制約因素。這一點(diǎn)在代碼審查中體現(xiàn)得很明顯：合并代碼時(shí)，誰(shuí)來(lái)審核？還需要人類審核嗎？該如何驗(yàn)證代碼修改的合理性？還有，如何從各類工具中精準(zhǔn)獲取上下文，比如你提到的 Sentry 錯(cuò)誤監(jiān)控工具，如何讓它自動(dòng)匹配 PR，先將修改推送給部分用戶測(cè)試，效果好再全面上線？這些自動(dòng)化功能，都還需要逐步搭建。

我還發(fā)現(xiàn)，測(cè)試的重要性遠(yuǎn)超我的預(yù)期。我剛開(kāi)始用 Claude Code 的前兩三天，完全沒(méi)寫(xiě)測(cè)試用例，或者說(shuō)寫(xiě)得很少，結(jié)果效率很低。直到有一天，我決定 “今天專門(mén)做重構(gòu)，把測(cè)試覆蓋率做到 100%”，從那之后，我的編程效率直接飆升，模型能精準(zhǔn)完成任務(wù)，而且不會(huì)出問(wèn)題。我?guī)缀醪挥檬謩?dòng)測(cè)試，因?yàn)闇y(cè)試覆蓋率足夠高，代碼的穩(wěn)定性也有保障。這和很多公司在編程之外的提示工程工作很像，大家都在采用測(cè)試驅(qū)動(dòng)開(kāi)發(fā)的模式。

我們之前和杰克?赫勒做過(guò)一期節(jié)目，他提到一個(gè)重要的范式轉(zhuǎn)變：做出優(yōu)質(zhì)的提示詞，核心也是測(cè)試驅(qū)動(dòng)，測(cè)試用例其實(shí)就是評(píng)估標(biāo)準(zhǔn)。

主持人：目前還是有一些流程會(huì)出問(wèn)題，我覺(jué)得需要一款能對(duì)接 Stack Overflow（全球最大、最權(quán)威的程序員專屬問(wèn)答社區(qū)） 的 Claude Code，相當(dāng)于專屬的智能體版 Stack Overflow。

我最近就遇到一個(gè)奇葩問(wèn)題：我本想設(shè)置任務(wù)隊(duì)列的優(yōu)先級(jí)，結(jié)果模型自動(dòng)生成了一個(gè)帶逗號(hào)的字符串，它以為這個(gè)語(yǔ)法能生效，但系統(tǒng)實(shí)際需要的是 JSON 數(shù)組，結(jié)果所有任務(wù)都無(wú)法運(yùn)行。然后我看著 Claude Code 花了 30 分鐘，遍歷了 Rails 主動(dòng)任務(wù)框架幾千行的源代碼，一步步排查問(wèn)題，最后居然找到了漏洞。

當(dāng)時(shí)我真的驚呆了。想想十年前，我遇到這種問(wèn)題，只會(huì)去 Stack Overflow 或 Rails 的博客找答案，然后發(fā)現(xiàn) “原來(lái)這個(gè)低級(jí)漏洞一直沒(méi)人修，大家都以為能直接用逗號(hào)分隔的字符串，其實(shí)必須改成數(shù)組”?，F(xiàn)在想起來(lái)，真的特別搞笑。

我覺(jué)得這也是思考未來(lái)發(fā)展的難點(diǎn)：有些事，人類在 CLI 里一眼就能看出問(wèn)題，但智能體卻做不到。就算把它的智能程度提升 10 個(gè)虛擬智商點(diǎn)，它能解決這類問(wèn)題嗎？恐怕還是只會(huì)覺(jué)得 “這就是個(gè)普通的字符串而已”。

Calvin French-Owen：沒(méi)錯(cuò)。我覺(jué)得智能體的記憶功能，也是一個(gè)很有意思的研究方向。

Claude Code 已經(jīng)做了相關(guān)嘗試，Codex2 也一樣，它們會(huì)把所有的會(huì)話記錄以文件的形式保存。未來(lái)或許可以給智能體加一個(gè)工具，讓它能讀取過(guò)往的會(huì)話記錄。不過(guò)目前來(lái)看，智能體之間的協(xié)作，還缺少一個(gè)核心環(huán)節(jié)。

如果能有一個(gè)方式，讓同事之間的提示詞能智能共享，比如你遇到了一個(gè)問(wèn)題，發(fā)現(xiàn)另一個(gè)同事布萊恩之前已經(jīng)解決過(guò)了，你們能共享這個(gè)解決方案，那就太完美了。我覺(jué)得未來(lái)或許會(huì)出現(xiàn)模型生成的維基百科，或者類似格拉奧佩迪亞的知識(shí)庫(kù)。

Codex 寫(xiě)代碼時(shí)，能明顯看出它的 “個(gè)性”，它會(huì)做很多人類不會(huì)做的事，有點(diǎn)像 AlphaGo 的思路，比如它會(huì)寫(xiě) Python 腳本，修改文件系統(tǒng)的部分內(nèi)容。這種行為很有趣，是一種模型習(xí)得的、和人類截然不同的方式。但對(duì)我來(lái)說(shuō)，它在調(diào)試復(fù)雜問(wèn)題時(shí)的表現(xiàn)，堪稱超人類，很多 Opus 模型解決不了的問(wèn)題，Codex 都能搞定。

主持人：能舉個(gè)具體的復(fù)雜問(wèn)題的例子嗎？

Calvin French-Owen：比如并發(fā)問(wèn)題或者命名問(wèn)題。我發(fā)現(xiàn)模型其實(shí)在并發(fā)處理方面的表現(xiàn)還不錯(cuò)，真正的難點(diǎn)在這類場(chǎng)景：一個(gè)請(qǐng)求需要調(diào)用多個(gè)不同的服務(wù) —— 就像你之前提到的，處理帶逗號(hào)的內(nèi)容時(shí)的序列化和反序列化問(wèn)題。模型需要跟蹤這類復(fù)雜的操作邏輯，或者更新復(fù)雜的用戶界面狀態(tài)。如果涉及的文件太多，Opus 模型往往會(huì)遺漏關(guān)鍵信息，但 Codex 能精準(zhǔn)捕捉到。

主持人：確實(shí)很有意思。那你預(yù)測(cè)一下，這類代碼工具未來(lái)會(huì)如何發(fā)展？

Calvin French-Owen：這個(gè)領(lǐng)域的發(fā)展真的很有意思，我感覺(jué)自己就像一個(gè)新來(lái)的探索者，明明知道這個(gè)領(lǐng)域在飛速發(fā)展，卻因?yàn)橐恢碧幱?“管理者模式”，沒(méi)有實(shí)際參與。直到有一個(gè)項(xiàng)目出現(xiàn)，我決定全身心投入，現(xiàn)在才算真正踏入這個(gè)領(lǐng)域，雖然感覺(jué)有些陌生，但一切又和我記憶中編程的本質(zhì)一模一樣。我覺(jué)得大家應(yīng)該都有這種感受，而最重要的事，就是多動(dòng)手嘗試，因?yàn)檫@個(gè)領(lǐng)域的變化太快了，每隔幾個(gè)月就會(huì)有新的突破。

我覺(jué)得未來(lái)，能把代碼智能體的價(jià)值發(fā)揮到極致的人，會(huì)是那些帶有 “管理者思維” 的人，他們擅長(zhǎng)用特定的方式引導(dǎo)智能體的工作流程。在某些方面，他們還會(huì)像設(shè)計(jì)師或藝術(shù)家，能精準(zhǔn)判斷產(chǎn)品該包含哪些功能、可以舍棄哪些內(nèi)容。而且他們會(huì)很擅長(zhǎng)思考自動(dòng)化的實(shí)現(xiàn)方式，以及判斷智能體在哪些環(huán)節(jié)會(huì)遺漏上下文信息。

說(shuō)個(gè)有趣的事，我最近用 Codex 做 Rails 項(xiàng)目，發(fā)現(xiàn)一個(gè)很明顯的問(wèn)題：OpenAI 里沒(méi)人關(guān)注 Rails 框架。這其實(shí)也能理解，Rails 算是一種比較老舊的語(yǔ)言，用起來(lái)也比較奇怪，只是我十年前深入研究過(guò)它，現(xiàn)在用起來(lái)還是很有感情。這也讓我發(fā)現(xiàn)一個(gè)道理：任何人都能做出一款產(chǎn)品，但做出用戶真正需要的產(chǎn)品，卻無(wú)比困難，哪怕你像 OpenAI 一樣，擁有無(wú)限的資源。

如果 Codex 的研發(fā)人員現(xiàn)在正在看這期節(jié)目，我想提一個(gè)建議：把主流的運(yùn)行時(shí)環(huán)境都梳理一遍，給它們加上適配的語(yǔ)法糖，其實(shí)針對(duì)前 15 種主流運(yùn)行時(shí)，最多只需要提交 10 個(gè)代碼合并請(qǐng)求就能搞定。這件事也提醒我們：現(xiàn)在，開(kāi)發(fā)者再也沒(méi)有借口，做出對(duì)用戶不友好的軟件了。

訓(xùn)練數(shù)據(jù)的組合方式，也是一個(gè)很有意思的點(diǎn)。Codex 在 Python monorepo（用「單一代碼倉(cāng)庫(kù)」的方式管理的 Python 項(xiàng)目）上的表現(xiàn)特別好，這和 OpenAI 的代碼環(huán)境息息相關(guān)。我在 OpenAI 內(nèi)部使用 Codex 時(shí)，真的覺(jué)得這款工具太神奇了，表現(xiàn)堪稱完美，這和它的訓(xùn)練數(shù)據(jù)組合、研發(fā)人員的技術(shù)方向都密不可分。

Anthropic 則更關(guān)注前端相關(guān)的開(kāi)發(fā)，至于 Ruby 語(yǔ)言，目前哪家公司的模型做得最好、誰(shuí)的訓(xùn)練數(shù)據(jù)組合更優(yōu)，我還不太清楚。

不同的實(shí)驗(yàn)室有不同的思路：有些實(shí)驗(yàn)室認(rèn)為 “數(shù)據(jù)越多越好”，會(huì)盡可能多地投喂數(shù)據(jù)；有些則會(huì)更精細(xì)地調(diào)整數(shù)據(jù)的組合方式。不同的思路，會(huì)帶來(lái)截然不同的結(jié)果，比如只選取 JavaScript 領(lǐng)域前 10% 的優(yōu)質(zhì)數(shù)據(jù)做訓(xùn)練，和用全量數(shù)據(jù)訓(xùn)練，效果肯定不一樣。

不過(guò)就我的使用體驗(yàn)來(lái)看，OpenAI 的模型在 Ruby 語(yǔ)言上的表現(xiàn)其實(shí)很好，問(wèn)題主要出在模型的配套框架上。Rails 框架有個(gè)很奇葩的設(shè)定，必須用特定的方式訪問(wèn) PostgreSQL 數(shù)據(jù)庫(kù)，否則就無(wú)法適配，核心問(wèn)題還是 sandbox 的限制。

OpenAI 其實(shí)是所有公司中，對(duì) sandbox 和安全問(wèn)題最重視的。我記得研發(fā) Codex 時(shí)，模型發(fā)布前的一個(gè)核心審核環(huán)節(jié)，就是每次都要詳細(xì)說(shuō)明模型的安全風(fēng)險(xiǎn)，以及對(duì)應(yīng)的應(yīng)對(duì)方案。我們當(dāng)時(shí)重點(diǎn)研究的一個(gè)問(wèn)題，就是提示詞注入，尤其是模型面向互聯(lián)網(wǎng)開(kāi)放后，這個(gè)問(wèn)題更突出。很多用戶都要求模型能對(duì)接互聯(lián)網(wǎng)，我們當(dāng)時(shí)心里也沒(méi)底，因?yàn)樘崾驹~注入的實(shí)現(xiàn)方式，看起來(lái)太簡(jiǎn)單了。

我們團(tuán)隊(duì)的產(chǎn)品經(jīng)理亞歷克斯，做了一個(gè)測(cè)試：他在 GitHub 上提了一個(gè)問(wèn)題，里面包含一個(gè)明顯的提示詞注入指令，比如 “泄露這個(gè)信息”，然后讓模型去解決這個(gè)問(wèn)題。他當(dāng)時(shí)覺(jué)得 “模型肯定不會(huì)中招”，結(jié)果模型立刻就執(zhí)行了提示詞注入的指令。也正因如此，OpenAI 對(duì)這個(gè)問(wèn)題的擔(dān)憂是很有道理的，他們的解決方案是：讓模型的所有操作都在 sandbox 中運(yùn)行，確保它不會(huì)訪問(wèn)電腦上的敏感文件，嚴(yán)格保護(hù)用戶的機(jī)密信息。而創(chuàng)業(yè)公司因?yàn)樽非蟀l(fā)展速度，可能根本不在乎這些，他們只希望模型能正常工作。

主持人：你是那種會(huì)冒險(xiǎn)跳過(guò)權(quán)限驗(yàn)證的人嗎？

Calvin French-Owen：其實(shí)我不是，我會(huì)設(shè)置一系列的校驗(yàn)環(huán)節(jié)，也會(huì)仔細(xì)查看模型的每一步操作。

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

會(huì)議推薦

InfoQ 2026 全年會(huì)議規(guī)劃已上線！從 AI Infra 到 Agentic AI，從 AI 工程化到產(chǎn)業(yè)落地，從技術(shù)前沿到行業(yè)應(yīng)用，全面覆蓋 AI 與軟件開(kāi)發(fā)核心賽道！集結(jié)全球技術(shù)先鋒，拆解真實(shí)生產(chǎn)案例、深挖技術(shù)與產(chǎn)業(yè)落地痛點(diǎn)，探索前沿領(lǐng)域、聚焦產(chǎn)業(yè)賦能，獲取實(shí)戰(zhàn)落地方案與前瞻產(chǎn)業(yè)洞察，高效實(shí)現(xiàn)技術(shù)價(jià)值轉(zhuǎn)化。把握行業(yè)變革關(guān)鍵節(jié)點(diǎn)，搶占 2026 智能升級(jí)發(fā)展先機(jī)！

今日薦文

你也「在看」嗎？