前 Codex 大神倒戈實錘！吹爆 Claude Code：編程提速 5 倍，點破 OpenAl 死穴在上下文

作者 | 高允毅

OpenAI Codex 的核心研發者，竟然成了 Claude Code 的忠實用戶？

Calvin French-Owen 是 Segment 聯合創始人、前 OpenAI 工程師、Codex 項目的早期研發者。他最近在一檔播客中，對當前最火的代碼智能體 Codex、Claude Code 和 Cursor 進行了銳評。

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

Calvin 用了一個極具畫面感的比喻，來形容用 Claude Code 的體驗：

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

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

面對復雜任務，Claude Code 會自動生成多個探索型子智能體，獨立掃描代碼倉庫、檢索上下文，再將關鍵信息匯總反饋。這種設計，顯著降低了上下文噪音，也解釋了它為何能穩定輸出高質量結果。

不過，他也肯定了自家產品，認為 Codex 很有“個性”，像 AlphaGo。在調試復雜問題時的表現上，Codex 堪稱超人類，很多 Opus 模型解決不了的問題，Codex 都能搞定。

“上下文管理”，是 Calvin French-Owen 在整期播客中反復強調的關鍵詞。

他認為，代碼的上下文信息密度極高，只要檢索方式得當，模型往往比人類更容易理解系統結構。但與此同時，上下文窗口本身，也成為制約代碼智能體發展的最大瓶頸。

提到上下文污染的問題時，主持人表示 LLM 會變笨。Calvin 趁此分享了一個非常實用的經驗：當上下文 token 占用超過 50%，他會主動清理。

他甚至分享了一種創業者常用的“金絲雀檢測”方法：在上下文里埋入一些無關但可驗證的小信息，一旦模型開始遺忘，說明上下文已經被污染。

在產品理念上，Calvin 認為 Claude Code 與 Codex 的差異，早已寫進兩家公司的基因里：

• Anthropic 更關注“做出適合人用的 AI”

• OpenAI 更關注“做出最強的 AI”

他判斷，從長期來看，OpenAI 的路線可能是必然趨勢，但就當下的使用體驗而言，他更偏愛 Anthropic。

在談到未來時，Calvin 給出了一個明確判斷：

• 公司會變小，但數量會變多

• 每個人都會擁有自己的智能體團隊

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

在這樣的背景下，產品的分發方式變得前所未有地重要。

自下而上的分發模式，正在以前所未有的速度擴散。工程師不會等審批、采購，只會用腳投票。

相比大公司對安全、合規和控制權的高度重視，開發者更在意的，依然是那句最樸素的評價：

“這東西，真的好用。”

以下是播客精彩細節，AI Coding 干貨密集，歡迎閱讀：

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

主持人：Calvin French-Owen 是 OpenAI 旗下 Codex 代碼模型的首批研發者之一，在此之前，他創立了 Segment 公司，這家公司市值數十億美元，最終被知名企業高價收購，成功實現資本變現。

Calvin French-Owen：說實話，現在對我們所有人來說，都是一段充滿變數的時期。我最近徹底迷上了 Claude Code，用一個比喻來說，十年前我還是個馬拉松愛好者，特別喜歡跑步，結果后來膝蓋受了重傷，這之后我就進入了所謂的 “管理者模式”，再也沒寫過代碼，想想真的很可惜。

但過去這九天，仿佛打開了新世界的大門，我找回了曾經寫代碼的所有感覺，就好像換了個全新的膝蓋，而且還是仿生的，能讓我寫代碼的速度快了 5 倍。

主持人：你怎么看待這款工具？畢竟你一直身處這個領域的前沿，Codex 開創的很多理念，至今仍被大家廣泛使用，而且這款模型還在持續迭代。

Calvin French-Owen：我在 OpenAI 工作時，負責 Codex 的網頁端項目，當時 Cursor 這款工具剛面世，他們基于 GPT-3.5 做了一個適配層，能在 IDE 中使用。Claude Code 也剛發布，它是基于 CLI 運行的，當時我們就有一個想法：未來的編程，應該更像和同事溝通 —— 你提出問題，對方去處理，最后帶著 PR 回來反饋。我們的網頁端項目就是從這個想法出發的，這也是我們當時的研發方向。

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

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

Calvin French-Owen：Claude Code 現在確實是我日常編程的主力工具。說實話，我的主力工具每隔幾個月就會換一次。之前有段時間我特別偏愛 Cursor，它新出的模型速度很快，用起來確實不錯。后來我慢慢轉到了 Claude Code，尤其是搭配 Opus 模型使用時，體驗更好。

Claude Code 是款很有意思的產品，我覺得大家都低估了它在產品設計與模型層面的協同表現。要是你深入研究就會發現，Claude Code 最厲害的地方，就是它的上下文拆分能力。

比如需要調用功能、讓子智能體協同工作時，你讓 Claude Code 執行某個任務，它通常會生成一個甚至多個探索型子智能體。這些子智能體會通過 ripgrep 工具掃描整個文件系統、檢索相關內容，而且每個子智能體都有獨立的上下文窗口（context window）。

我認為 Anthropic 在這點上做得特別出色 —— 面對一項任務，模型能精準判斷出，這個任務適合在單個上下文窗口（context window）中完成，還是需要拆分后再執行。模型在這方面的表現堪稱驚艷，這也是它能輸出高質量結果的關鍵。

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

主持人：這一點確實很獨特。我個人挺意外的，不知道你有沒有這種感覺，總覺得有種復古的未來感，二十年前的 CLI 技術，居然打敗了本被寄予厚望的各類 IDE。

Calvin French-Owen：我完全認同。而且 Claude Code 不是 IDE，這一點其實很關鍵，因為它能讓你和正在編寫的代碼保持一定距離。IDE 的核心就是瀏覽文件，對吧？你需要把所有代碼狀態記在腦子里，還要理清其中的邏輯。但 CLI 完全不同，這讓它在使用體驗的設計上有了更大的發揮空間。

不知道你有沒有這種感覺，我用 Claude Code 的時候，感覺就像在代碼里 “飛馳”，各種操作都特別順暢。界面上會有小的進度指示器，隨時給我狀態反饋，而編寫的代碼本身反而不是視覺的核心。

開發環境本來就很雜亂，我特別喜歡 sandbox（沙箱）在概念上的簡潔性。但實際使用時，我遇到了很多棘手的問題，比如就連簡單的測試都搞不定：sandbox（沙箱）需要訪問 PostgreSQL 數據庫，卻一直連接失敗；我寫的 codex.md 文件只有二十行，最后還是無法運行。

但在 CLI 里，工具可以直接訪問開發數據庫。我不確定這么做是否合規，但我確實試過讓它訪問生產數據庫執行一些操作，而且它真的做到了。比如有一次，我遇到了一個并發問題，想排查一下，結果發現這款工具居然能調試五層嵌套的延遲任務，找出問題所在，還能自動編寫測試用例，之后這個問題就再也沒出現過。這真的太不可思議了。

主持人：沒錯。而且我覺得產品的推廣和使用獲取方式，被嚴重低估了。想想 Cursor、Claude Code 還有 Codex 的命令行版本，你只需下載就能用，不用向公司申請任何使用權限，這一點帶來的使用體驗差異，實在太大了。

做好上下文管理，

是用好頂尖模型的訣竅

主持人：你在代碼智能體領域有很多實踐，對于想要打造這類工具的人，你有什么建議？有哪些實戰經驗可以分享？

Calvin French-Owen：我覺得最重要的一點，是做好上下文管理。

當時我們為一款推理模型搭建了檢查點，隨后基于強化學習（RL）對它開展了大量微調工作：我們會給模型布置各類編程相關任務，比如解決編程問題、修復測試用例、實現新功能，再通過強化學習的方式，訓練模型如何更精準地應對這些任務。當然，目前大多數人還做不到這一步，但大家力所能及的是，多思考該給智能體提供哪些上下文信息，才能讓它輸出最優的結果。

比如觀察 Claude Code 的工作過程，它會生成多個探索型子智能體，這些子智能體會去檢索文件系統里的各類代碼相關內容，完成后會把上下文信息帶回來并為我做好總結，我就能清楚后續該怎么推進工作了。

看不同智能體的上下文構建方式，是件特別有意思的事。比如 Cursor 用的是語義搜索的方式，它會把所有內容轉化為向量形式，再匹配和查詢需求最相關的內容；而 Codex 和 Claude Code，其實用的都是 ripgrep 這個代碼搜索工具。這種方式之所以管用，是因為代碼的上下文信息密度很高。一行代碼通常不到 80 個字符，代碼倉庫里不會有太多大數據塊或 JSON 格式的文件，就算有，數量也極少。

你可以參考 Git（代碼版本管理工具）的忽略規則，先過濾掉無關內容或是已打包的文件，再通過 Git 和 ripgrep 查找代碼的上下文，這樣就能很好地理解代碼的實際功能了。同時這類工具還能自動掃描整個文件夾的結構，而且 LLM（大語言模型）特別擅長生成復雜的 Git 命令，這些命令讓人類手動寫的話，簡直是種折磨。而這一整套操作，其實就是強化學習（RL）在實際場景中的落地應用。

我現在也在做非編程領域的智能體集成系統，從代碼智能體的研發過程中，我也學到了很多：要把數據轉換成接近代碼的格式，讓模型能快速檢索到相關的周邊信息，進而獲取到結構化的有效數據。

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

Calvin French-Owen：第一個技巧，是盡量減少底層代碼和基礎架構的編寫。

我平時會在 Vercel、Next.js 或 Cloudflare Workers 這些平臺部署技術棧，這些平臺已經封裝了大量樣板代碼，不用自己費心搭建各類服務，也不用處理服務發現、中心端點注冊、數據庫配置這些問題。所有功能基本都能在一兩百行代碼內實現。我也傾向于采用微服務架構，或者使用結構清晰的獨立軟件包。

其次，要了解 LLM 的核心優勢。

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

我自己也會頻繁使用代碼審查機器人，YC 孵化的 Reptile 公司做的這款機器人用起來就特別順手；Cursor 的漏洞檢測機器人也很好用，我也常常用 Codex 做代碼審查，它在校驗代碼正確性這塊的表現尤其突出。

這些都是代碼智能體格外擅長的領域，除此之外，它們探索代碼倉庫的能力也很出色。

當然，智能體也有短板：它們擅長做拓展，但如果你的需求不是拓展功能，它們往往會重復編寫代碼，浪費大量時間做已經實現過的功能，這時候你就會覺得 “它完全沒理解我的需求”。

還有一個問題是上下文污染，智能體可能會陷入某個循環，因為執行力強，會一直沿著錯誤的方向推進，而它參考的上下文信息，其實對于解決問題毫無幫助。所以我常用的一個方法，是主動清理上下文，比如當上下文的 token 占用率超過 50% 時，就及時清理。

主持人：哇，這個比例其實特別關鍵。不知道你有沒有關注到，YC（Y Combinator 的縮寫，全球頂級的創業孵化器）2024 年秋季孵化營里，那家做 HumanLayer（人類層）的公司，創始人 Dex Horthy 就總聊這個話題，還專門提出了 “LLM 愚笨區”的概念：當上下文的 token 數量達到某個閾值后，模型的輸出質量就會開始下滑。

Calvin French-Owen：我完全認同這個觀點，結合強化學習（RL）的工作邏輯來看，這一點就更明顯了。

想象一下，你是一名參加考試的大學生，考試剛開始的五分鐘，你會覺得時間很充裕，一定能好好答題，認真思考每個問題；但如果只剩五分鐘，試卷還有一半沒做完，你就會慌不擇路，只求盡快寫完。LLM 的上下文窗口（context window），就是這個道理。

創業者們有一個小技巧，我覺得很實用：在上下文開頭加一個 “金絲雀檢測” 信息，就是一些特別小眾甚至有趣的內容，比如 “我叫 Calvin French-Owen，早上八點喝了茶” 這類無關的小事實。然后在和模型的交互過程中，時不時問它 “你記得我叫什么嗎？”“你記得我幾點喝的茶嗎？”，如果它開始忘記這些信息，就說明上下文已經被污染了。這是我見過很多人用的方法，我自己還沒試過，但完全相信它的效果。

主持人：這個方法很有意思。我在模型做上下文壓縮前，還沒遇到過這類問題，可能是我沒太留意。你是說，token 數超標后，模型會開始做出一些不合理的操作？我得留意一下，這個問題能在 Claude Code 內部解決嗎？比如讓模型自己做檢測，在上下文里加入類似 “心跳檢測” （通過定期發送 “狀態確認信號”，實時監控目標對象的運行狀態，一旦信號異常就觸發預警或處理）的機制，實時監控狀態。

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

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

Anthropic 要做人用的，

OpenAI 要做最好的，以及產品分發模式很重要

主持人：看來 Claude Code 和 Codex 的架構差異很大，Codex 似乎更適合長時間運行的任務，所以二者的使用場景不同，架構設計也天差地別。現在看來，CLI 的工具越來越火，2026 年可能會成為 “CLI 元年”。

但同時也有觀點認為，通用人工智能已經到來，超級人工智能也近在咫尺。目前的代碼智能體已經非常智能，但還達不到自主長時間運行的程度，如果計算能力提升十倍，能實現 24 小時甚至 48 小時的自主任務運行嗎？Codex 的架構，能適配這種場景嗎？

Calvin French-Owen：這是個很好的問題，答案其實藏在兩家公司的創立基因里。

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

而 OpenAI 的核心思路，是訓練出最優秀的模型，通過持續的強化學習（RL），讓它能處理更長期、更復雜的任務，最終實現通用人工智能。所以它的模型，工作方式可能和人類完全不同。還是以建狗窩為例，就像 AlphaGo 的下棋思路和人類不同一樣，OpenAI 的模型可能會直接用 3D 打印機，從零開始打印出一個狗窩，完全符合你的需求，過程可能會很長，成品也會高度定制化，甚至有些設計會很怪異，但最終能實現功能。

或許從長遠來看，這才是正確的方向，所以很期待兩家公司的后續發展。總的來說，OpenAI 的路線似乎是必然趨勢，但我個人更喜歡 Anthropic 的思路。十年前，我還會自己寫一些奇怪的腳本，在重構代碼或理解代碼邏輯時，用它來梳理各類信息，而 Claude Code 給我的感覺，和當年的這種體驗一模一樣，用它一天，能完成五個人的工作量，就像給編程裝上了火箭助推器，太不可思議了。

主持人：很期待不同規模的公司，會如何應用這類工具。我發現，不管是業余愛好者，還是小型創業公司，都在盡可能挖掘代碼智能體的潛力，因為他們根本沒時間研究其他方法。創業公司的資金和時間都有限，一切都要以速度為核心。但大公司不一樣，他們有太多東西可以失去，還有各種代碼審查的內部流程，也已經組建了龐大的技術團隊。

未來可能會出現一種很有趣的現象：一個人組成的小團隊，看到其他團隊的工作效率低，就會自己用代碼智能體做一個原型，效果反而更好。總有一天，這種小團隊的成果會超越大團隊，行業格局的轉變，一定會很有意思。

Calvin French-Owen：其實前幾天我試了一款產品，它的用法很有意思：你下載一個桌面應用，它會調用你電腦上運行的 Claude Code，再通過 MCP 服務器和桌面應用通信。這種方式讓電腦的使用變得很不一樣，你不用征得任何人同意，下載后直接用就行。

在這個變化飛快的時代，產品的分發模式真的太重要了，自下而上的模式遠比自上而下好，因為后者的效率實在太低。公司的首席技術官總會顧慮安全、隱私問題，擔心各種突發情況，想要絕對的控制權，但工程師們只會直接裝上工具開始用，然后感嘆 “這東西太好用了”。

主持人：你說得太對了。我本身是做企業級 ToB 業務的，總覺得自上而下的銷售模式能構建一定的競爭壁壘，肯定會有公司找到方法，做出一款人人都能用上的產品，或許先從個人用戶切入會是個思路。

當年的網景導航器（互聯網早期最具里程碑意義的網頁瀏覽器）就是如此，它對非商業用途免費，結果很多人下載后用在商業場景，網景就通過追蹤 IP 地址，統計不同公司的使用量，然后告知對方 “你們違規使用了，只需購買授權就能繼續用”。我很好奇，這種模式現在還能復制嗎？

Calvin French-Owen：你關于分發模式的觀點很有意思，現在很多人甚至會直接根據 Claude Code 的建議做架構決策，他們可能都不知道該用什么分析工具，只要 Claude Code 說用 PostHog（ YC W2020 批次孵化的開源平臺 PostHog，核心定位是給開發者和產品團隊的 “全能型產品優化工具箱”），他們就會百分百采用。

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

我覺得做開發者工具的話，完善的文檔、真實的用戶口碑，甚至在 Reddit 上的一些討論，這些都能極大地提升產品的認可度，這也是很多開源項目能快速崛起的原因。

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

不知道你有沒有看到，Ramp 公司最近發了一篇博客，講他們如何打造自研的代碼智能體，里面提到他們用開源代碼作為框架，因為模型可以直接讀取源代碼，理解其工作邏輯。我對開源產品一直這么做：克隆代碼倉庫，然后啟動 Codex 或 Claude Code，讓它講解代碼的邏輯，用起來特別實用。

未來公司會變小，

數據很重要

主持人：我們不妨暢想一下四十年后的未來：軟件、數據庫、訪問控制依然存在，但軟件的核心會高度個性化。訪問控制、權限分配這類事，依然是大家開會討論的重點，也就是所謂的 “管理者模式”，但公司的其他所有功能、規則，都由員工通過自己的 Claude Code 這類工具定義。可能還是 CLI，也可能是由大量智能體組成的協作體系，那會是一種怎樣的場景？

比如想象一下，現在如果有公司要接入 Segment，我們復刻代碼倉庫，給他們一個專屬版本，讓它在自己的服務器上運行；如果他們想做修改，只需在聊天窗口告訴智能體，智能體通過代碼循環完成編輯，而 Segment 總公司推出新功能后，智能體還能自動完成版本合并。

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

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

在 YC，我們的工作基本都是 Manager Schedule（管理者日程），這讓我們很難有時間自己寫代碼、做產品。但現在有了代碼智能體，一切都變了，很多合伙人開會時，就像這期播客剛開始時我做的一樣，讓智能體后臺運行處理任務，自己專注開會，等會開完，任務也完成了。

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

Calvin French-Owen：我覺得未來的核心基礎能力之一，依然是保持數據模型的一致性，而核心的記錄系統，也有機會率先實現智能體化。現在我們的工作，還是高度依賴數據庫，以及底層的 SQL 或 NoSQL 查詢，但未來或許會出現一種工具，能為定制化軟件的各類視圖，自動生成所需的所有數據。

未來的軟件世界，會有大量定制化視圖，但數據的準確性，依然是核心前提。數據的重要性不言而喻，這一點從很多公司的做法中就能看出來：比如很多公司通過 API 或 MCP 開放數據訪問權限，而 Slack(全球最主流的企業級團隊協作與即時溝通平臺，常被稱作「硅谷版釘釘 / 企業微信」) 就收緊了 API 的權限，因為他們不想讓用戶把平臺上的所有數據都導出，然后基于這些數據搭建智能體應用。

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

Calvin French-Owen：總的來說，工程師的資歷越深，受益就越多。因為智能體特別擅長把想法轉化為實際行動，如果你能用幾句話清晰地描述需求，就能立刻讓它落地。

我在瀏覽開源代碼倉庫時，經常會有這種感受：看到某處代碼，覺得可以優化，只要把這個想法告訴智能體，讓它去執行，最后等待反饋就行。這種方式能極大地提升效率，放大個人的影響力。

其次，能判斷哪些代碼修改在架構層面是合理的、哪些是不合理的，或者能準確判斷該在哪個節點向智能體發出指令，這一點也很重要。我覺得做事有條理、帶有 “管理者思維” 的工程師，會更適配這類工具。

而且目前來看，這個領域還缺少一款核心產品，比如類似 Conductor 這樣的工具，能整合你所有的會話，提醒你 “這個任務已經完成，需要你確認”“你該把注意力轉到另一個任務上了”。Conductor（核心解決 AI 編程的 “失憶問題）這類工具，應該給智能體加上上下文管理功能，其實人類也需要這樣的上下文管理工具，這一點是毋庸置疑的。

主持人：如果讓你回到大學，重新學習計算機科學，讓你自己制定課程表，你會選擇學習哪些內容？

Calvin French-Owen：就我個人而言，理解各類系統的工作原理，依然是最重要的。比如 Git、HTTP、隊列這類數據庫，了解這些系統的基礎概念，至關重要。另外，我會專門安排一個學期，每周都動手做項目，盡全力挖掘模型的潛力。

在使用模型的過程中，你會發現，遇到問題時，總能向上層抽象，讓模型來解決。比如你可以給模型一個 “實現” 命令，讓它完成計劃的下一階段；也可以給一個 “全部實現” 命令，讓它分階段執行，生成新的子智能體；還能給一個 “校驗” 命令，讓它自查成果。模型的能力邊界一直在變化，所以多動手嘗試，是很有必要的。

還有一件事讓我覺得很有意思，我特別想教 18 到 22 歲的年輕人做產品。我們這桌人，都做出過用戶真正需要、真正喜歡的產品，該怎么把這種能力教給年輕人，是一個值得思考的問題。我很好奇，五年后的年輕人，會不會在產品審美等方面遠超現在的我們？因為他們能借助智能體，做出更多的嘗試，產出更多的成果。他們本就該如此，不是嗎？他們的產品落地速度、接觸現實的機會，應該是上一代人的十倍。

主持人：說到這里，我有一個疑問，不知道你有沒有這種感受：我小時候，媽媽總跟我說 “別一心二用，根本沒認真聽我說話”。這話其實有道理，我當時確實盯著電腦，沒認真聽，但我發現，我比父母那一代人更擅長多任務處理。而現在的年輕人，比我們更厲害，因為他們成長在互聯網時代，每天接觸抖音這類短視頻，應對各種碎片化信息。我覺得，未來既需要能深度思考的人 —— 他們能專注觀察、理解問題、解決問題，也需要能靈活切換場景的人 —— 他們能同時處理多個任務，不斷切換上下文，也就是所謂的 “注意力缺陷多動障礙模式”。

Calvin French-Owen：沒錯，新一代的年輕人特別擅長這一點。我一直覺得，有一種聰明人，或許是帶有注意力缺陷多動障礙的特質，他們腦子里同時醞釀著很多好項目，但從來沒有真正完成過一個。我自己可能就有點這種性格。我之前發布了自己的氛圍代碼，其實如果不是 Claude Code，我根本完不成。

我覺得，有些人的大腦就像有十個分支同時運轉，但一天的時間有限，根本沒法把所有想法都落地，所以項目總是半途而廢。而現在，Claude Code 能幫我把所有想法都落地。你在博客里也提到過，用它的感覺就像玩電子游戲，總有新鮮感。比如你開始做一個項目，做到一半覺得無聊，又有了新的想法，想先做新想法，再回頭做原來的項目，以前這么做，很容易半途而廢，但現在有了智能體，兩個項目最終都能完成。

主持人：十歲的孩子每天都有寫作作業，昨天他第一次用人工智能寫作業，我一看就知道，那些表達根本不是一個十歲孩子能寫出來的。

這讓我想到，我們現在和很多 18 到 22 歲的年輕人合作，他們有實習經歷，但沒有做過管理工作，不懂產品市場匹配后的運營邏輯 —— 當你面對數百萬的任務隊列、數十萬的錯誤日志時，才是真正的管理工作。這份工作其實很枯燥，要逐行排查錯誤日志，還要在后臺手動確保產品對所有用戶都能正常運行。

新一代的開發者，該如何理解這些內容？Claude Code 這樣的智能體，能教他們架構設計這類知識嗎？還是說，他們只能自己踩坑試錯，在摸索中成長？

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

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

主持人：說到這里，我很好奇，如果現在讓你用當下的工具，重新打造 Segment，你會怎么做？

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

但保持數據管道（data pipeline）的穩定運行、實現業務流程的自動化，比如客戶注冊時，通過 Customer IO 自動發送郵件、管理用戶群體，這些功能的價值依然存在，而且還有很大的拓展空間。

比如借助這些數據構建完整的用戶畫像（user profile），再讓小型大模型（LLM）智能體分析：該如何給用戶推送郵件？用戶登錄時，是否要調整產品的部分功能？是否要根據用戶的不同特征，設計差異化的引導流程？這些都是很有意思的方向，而且都能通過智能體實現。

這也是我會做出的核心改變：就像你之前說的，向技術棧上層遷移，摒棄底層的基礎開發工作，更多聚焦在營銷活動這類更抽象的業務層面發力。

主持人：沒錯。我特別驚訝的是，Claude Code 僅憑我正在做的項目的上下文，就能精準理解我的需求和意圖。我至今依然覺得代碼智能體很神奇：你把代碼倉庫的副本給它，留個簡單的指令，比如 “實現這個功能”，它就能完成。大多數情況下，它根本不知道你的公司是做什么的、你的用戶是誰，或許因為訓練數據里有我的信息，它知道我是加里，但它能完成任務這件事，本身就令人難以置信。這也能看出上下文的重要性，對吧？如果它捕捉到的上下文信息有誤，就會偏離方向；如果遺漏了關鍵信息，就會重復造輪子。

你覺得目前代碼智能體的發展，還有哪些制約因素？上下文窗口的限制依然存在，但現在的窗口已經很大了，雖然還做不了大規模的架構重構，但很多任務都能完成。Opus4.5 模型的智能程度有了很大提升，帶來了很大的突破，我不知道這是預訓練還是后訓練的成果。除了基礎的模型智能、前沿模型的能力和上下文窗口，還有哪些因素能推動它的發展？

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

而且我們還需要找到更好的方法，專門訓練模型處理長上下文的能力。互聯網上有大量的訓練數據，能讓模型預測下一句話、下一個段落是什么，但如果有 8 萬個 token 的上下文，模型需要根據其中 2 萬個 token 的信息，判斷下一步該做什么，這就困難多了。

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

我還發現，測試的重要性遠超我的預期。我剛開始用 Claude Code 的前兩三天，完全沒寫測試用例，或者說寫得很少，結果效率很低。直到有一天，我決定 “今天專門做重構，把測試覆蓋率做到 100%”，從那之后，我的編程效率直接飆升，模型能精準完成任務，而且不會出問題。我幾乎不用手動測試，因為測試覆蓋率足夠高，代碼的穩定性也有保障。這和很多公司在編程之外的提示工程工作很像，大家都在采用測試驅動開發的模式。

我們之前和杰克?赫勒做過一期節目，他提到一個重要的范式轉變：做出優質的提示詞，核心也是測試驅動，測試用例其實就是評估標準。

主持人：目前還是有一些流程會出問題，我覺得需要一款能對接 Stack Overflow（全球最大、最權威的程序員專屬問答社區） 的 Claude Code，相當于專屬的智能體版 Stack Overflow。

我最近就遇到一個奇葩問題：我本想設置任務隊列的優先級，結果模型自動生成了一個帶逗號的字符串，它以為這個語法能生效，但系統實際需要的是 JSON 數組，結果所有任務都無法運行。然后我看著 Claude Code 花了 30 分鐘，遍歷了 Rails 主動任務框架幾千行的源代碼，一步步排查問題，最后居然找到了漏洞。

當時我真的驚呆了。想想十年前，我遇到這種問題，只會去 Stack Overflow 或 Rails 的博客找答案，然后發現 “原來這個低級漏洞一直沒人修，大家都以為能直接用逗號分隔的字符串，其實必須改成數組”。現在想起來，真的特別搞笑。

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

Calvin French-Owen：沒錯。我覺得智能體的記憶功能，也是一個很有意思的研究方向。

Claude Code 已經做了相關嘗試，Codex2 也一樣，它們會把所有的會話記錄以文件的形式保存。未來或許可以給智能體加一個工具，讓它能讀取過往的會話記錄。不過目前來看，智能體之間的協作，還缺少一個核心環節。

如果能有一個方式，讓同事之間的提示詞能智能共享，比如你遇到了一個問題，發現另一個同事布萊恩之前已經解決過了，你們能共享這個解決方案，那就太完美了。我覺得未來或許會出現模型生成的維基百科，或者類似格拉奧佩迪亞的知識庫。

Codex 寫代碼時，能明顯看出它的 “個性”，它會做很多人類不會做的事，有點像 AlphaGo 的思路，比如它會寫 Python 腳本，修改文件系統的部分內容。這種行為很有趣，是一種模型習得的、和人類截然不同的方式。但對我來說，它在調試復雜問題時的表現，堪稱超人類，很多 Opus 模型解決不了的問題，Codex 都能搞定。

主持人：能舉個具體的復雜問題的例子嗎？

Calvin French-Owen：比如并發問題或者命名問題。我發現模型其實在并發處理方面的表現還不錯，真正的難點在這類場景：一個請求需要調用多個不同的服務 —— 就像你之前提到的，處理帶逗號的內容時的序列化和反序列化問題。模型需要跟蹤這類復雜的操作邏輯，或者更新復雜的用戶界面狀態。如果涉及的文件太多，Opus 模型往往會遺漏關鍵信息，但 Codex 能精準捕捉到。

主持人：確實很有意思。那你預測一下，這類代碼工具未來會如何發展？

Calvin French-Owen：這個領域的發展真的很有意思，我感覺自己就像一個新來的探索者，明明知道這個領域在飛速發展，卻因為一直處于 “管理者模式”，沒有實際參與。直到有一個項目出現，我決定全身心投入，現在才算真正踏入這個領域，雖然感覺有些陌生，但一切又和我記憶中編程的本質一模一樣。我覺得大家應該都有這種感受，而最重要的事，就是多動手嘗試，因為這個領域的變化太快了，每隔幾個月就會有新的突破。

我覺得未來，能把代碼智能體的價值發揮到極致的人，會是那些帶有 “管理者思維” 的人，他們擅長用特定的方式引導智能體的工作流程。在某些方面，他們還會像設計師或藝術家，能精準判斷產品該包含哪些功能、可以舍棄哪些內容。而且他們會很擅長思考自動化的實現方式，以及判斷智能體在哪些環節會遺漏上下文信息。

說個有趣的事，我最近用 Codex 做 Rails 項目，發現一個很明顯的問題：OpenAI 里沒人關注 Rails 框架。這其實也能理解，Rails 算是一種比較老舊的語言，用起來也比較奇怪，只是我十年前深入研究過它，現在用起來還是很有感情。這也讓我發現一個道理：任何人都能做出一款產品，但做出用戶真正需要的產品，卻無比困難，哪怕你像 OpenAI 一樣，擁有無限的資源。

如果 Codex 的研發人員現在正在看這期節目，我想提一個建議：把主流的運行時環境都梳理一遍，給它們加上適配的語法糖，其實針對前 15 種主流運行時，最多只需要提交 10 個代碼合并請求就能搞定。這件事也提醒我們：現在，開發者再也沒有借口，做出對用戶不友好的軟件了。

訓練數據的組合方式，也是一個很有意思的點。Codex 在 Python monorepo（用「單一代碼倉庫」的方式管理的 Python 項目）上的表現特別好，這和 OpenAI 的代碼環境息息相關。我在 OpenAI 內部使用 Codex 時，真的覺得這款工具太神奇了，表現堪稱完美，這和它的訓練數據組合、研發人員的技術方向都密不可分。

Anthropic 則更關注前端相關的開發，至于 Ruby 語言，目前哪家公司的模型做得最好、誰的訓練數據組合更優，我還不太清楚。

不同的實驗室有不同的思路：有些實驗室認為 “數據越多越好”，會盡可能多地投喂數據；有些則會更精細地調整數據的組合方式。不同的思路，會帶來截然不同的結果，比如只選取 JavaScript 領域前 10% 的優質數據做訓練，和用全量數據訓練，效果肯定不一樣。

不過就我的使用體驗來看，OpenAI 的模型在 Ruby 語言上的表現其實很好，問題主要出在模型的配套框架上。Rails 框架有個很奇葩的設定，必須用特定的方式訪問 PostgreSQL 數據庫，否則就無法適配，核心問題還是 sandbox 的限制。

OpenAI 其實是所有公司中，對 sandbox 和安全問題最重視的。我記得研發 Codex 時，模型發布前的一個核心審核環節，就是每次都要詳細說明模型的安全風險，以及對應的應對方案。我們當時重點研究的一個問題，就是提示詞注入，尤其是模型面向互聯網開放后，這個問題更突出。很多用戶都要求模型能對接互聯網，我們當時心里也沒底，因為提示詞注入的實現方式，看起來太簡單了。

我們團隊的產品經理亞歷克斯，做了一個測試：他在 GitHub 上提了一個問題，里面包含一個明顯的提示詞注入指令，比如 “泄露這個信息”，然后讓模型去解決這個問題。他當時覺得 “模型肯定不會中招”，結果模型立刻就執行了提示詞注入的指令。也正因如此，OpenAI 對這個問題的擔憂是很有道理的，他們的解決方案是：讓模型的所有操作都在 sandbox 中運行，確保它不會訪問電腦上的敏感文件，嚴格保護用戶的機密信息。而創業公司因為追求發展速度，可能根本不在乎這些，他們只希望模型能正常工作。

主持人：你是那種會冒險跳過權限驗證的人嗎？

Calvin French-Owen：其實我不是，我會設置一系列的校驗環節，也會仔細查看模型的每一步操作。

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

會議推薦

InfoQ 2026 全年會議規劃已上線！從 AI Infra 到 Agentic AI，從 AI 工程化到產業落地，從技術前沿到行業應用，全面覆蓋 AI 與軟件開發核心賽道！集結全球技術先鋒，拆解真實生產案例、深挖技術與產業落地痛點，探索前沿領域、聚焦產業賦能，獲取實戰落地方案與前瞻產業洞察，高效實現技術價值轉化。把握行業變革關鍵節點，搶占 2026 智能升級發展先機！

今日薦文

你也「在看」嗎？