最近我在這里比較沉默，因為我正埋頭于最新項目。智能體工程已經(jīng)發(fā)展得如此出色，現(xiàn)在幾乎100%的代碼都由它完成。然而我看到很多人仍在試圖解決問題時制造各種復雜的把戲，而不是實實在在地把事情搞定。

這篇文章的靈感部分來自昨晚在倫敦 Claude 代碼匿名會[1]上的交流，部分因為自從我上次更新工作流程以來 AI 技術(shù)已發(fā)展了一年[2] 。是時候做個階段性總結(jié)了。

所有基礎理念仍然適用，因此我不會再贅述上下文管理這類基礎內(nèi)容。入門指南請參閱我的 《最優(yōu) AI 工作流程》文章[3] 。

上下文與技術(shù)棧

我目前獨立開發(fā)的項目包括：一個約 30 萬行代碼的 TypeScript React 應用、Chrome 擴展程序、命令行工具、基于 Tauri 的客戶端應用，以及使用 Expo 開發(fā)的移動應用。網(wǎng)站托管在 Vercel 上，提交 PR 后約 2 分鐘即可測試新版本。其他應用（如客戶端等）尚未實現(xiàn)自動化部署。

駕馭與總體方法

我已完全改用codex命令行工具作為日常主力。通常在 3x3 終端網(wǎng)格中并行運行 3-8 個實例，多數(shù)位于同一目錄[4] ，部分實驗會放在獨立文件夾。嘗試過工作樹和 PR 方案，但最終總是回歸這個最高效的配置。

我的代理程序能自主完成 git 原子提交[5] 。為保持提交歷史整潔，我對代理配置文件[6]進行了大量迭代優(yōu)化。這使得 git 操作更精準，確保每個代理僅提交其實際修改的文件。

沒錯，claude 支持鉤子而 codex 暫未實現(xiàn)，但模型足夠智能，當它們決意行動時任何鉤子都攔不住[7] 。

過去我常被嘲笑稱為廢話生成器[8] ，很高興看到并行代理逐漸成為主流[9] 。

模型選擇器

我?guī)缀醵加?gpt-5-codex 的中等設置來構(gòu)建所有內(nèi)容。它在智能與速度間取得了完美平衡，并能自動調(diào)節(jié)思考深度。我發(fā)現(xiàn)過度糾結(jié)這些設置并不會帶來實質(zhì)性提升，不用考慮_超頻思考_的感覺真好。

影響范圍

工作時，我總會考慮"爆炸半徑"這個概念——雖然這個詞不是我發(fā)明的，但我特別喜歡它。當我構(gòu)思一個改動時，我能較準確地預估所需時間及影響范圍。我可以向代碼庫投擲許多"小手雷"，或是扔一顆"胖子原子彈"配幾顆小炸彈。但如果同時引爆多個大當量炸彈，就無法實現(xiàn)隔離提交，出問題時回滾也會困難得多。

這也是我監(jiān)控智能體時的黃金準則。當某項操作耗時超出預期，我只需按下 ESC 鍵詢問"當前狀態(tài)"獲取進度更新，然后要么引導模型找到正確方向，要么中止或繼續(xù)任務。別擔心中途打斷模型——文件修改是原子級的，它們非常擅長從中斷處繼續(xù)工作。

當不確定改動影響時，我會用"先給我?guī)讉€備選方案再修改"來評估風險。

為什么不使用工作樹？

我運行一個開發(fā)服務器，隨著項目演進，我會點擊測試多個變更。為每個變更創(chuàng)建分支/樹會顯著拖慢速度，而啟動多個開發(fā)服務器很快就會變得煩人。另外我的 Twitter OAuth 有域名回調(diào)限制，只能注冊部分域名。

Claude Code 怎么樣？

我曾經(jīng)很喜歡 Claude Code，但現(xiàn)在完全無法忍受了（ 盡管 codex 是它的粉絲[10] ）。它的語言風格、那些絕對正確的[11]說辭、在測試失敗時還宣稱 100%生產(chǎn)就緒——我實在受夠了。Codex 更像是個內(nèi)向的工程師，埋頭苦干就能完成任務。它在開始工作前會讀取更多文件，所以即使簡單提示通常也能準確實現(xiàn)我的需求。

我的時間線上普遍認為 codex 才是[12]正確選擇[13] 。

Codex 的其他優(yōu)勢

• ~23 萬可用上下文 vs Claude 的 15.6 萬。雖然 Sonnet 有 100 萬上下文（如果你運氣好或支付 API 費用），但實際上 Claude 在耗盡上下文之前就會變得非常不靠譜，所以這并不現(xiàn)實可用。

• 更高效的 token 使用。不知道 OpenAI 做了什么不同，但我的上下文填充速度比 Claude Code 慢得多。以前用 Claude 時經(jīng)?？吹?Compacting..."提示，而在 Codex 中我很少能超出上下文限制。

• 消息隊列。Codex 支持 消息排隊 [14] 功能。Claude 原本也有此特性，但幾個月前他們將其改為消息"引導"模型模式。若想引導 Codex，我只需按 ESC 鍵加回車發(fā)送新消息。同時保留兩種操作方式顯然更優(yōu)。我經(jīng)常將相關(guān)功能任務排入隊列，它能穩(wěn)定可靠地逐一處理。

• 速度OpenAI 用 Rust 重寫了 Codex，效果顯著。它快得驚人。使用 Claude Code 時我經(jīng)常遇到數(shù)秒卡頓，進程內(nèi)存占用會暴漲到 GB 級別。還有終端閃爍問題，特別是在 Ghostty 上使用時。Codex 完全沒有這些問題，感覺極其輕量快速。

• 語言體驗這對我的心理健康影響重大 [15] 。我曾無數(shù)次對著 Claude 怒吼，卻很少對 Codex 發(fā)脾氣。即便 Codex 是個更差的模型，單憑這點我也會用它。如果你同時使用兩者幾周就會明白。

• 不會到處生成隨機 markdown 文件 [16] 。 懂的都懂 [17] 。

在我看來，終端用戶和模型公司之間其實沒有太多中間地帶。訂閱模式目前給我?guī)砹俗顒澦愕慕灰住椰F(xiàn)有 4 個 OpenAI 訂閱和 1 個 Anthropic 訂閱，每月總成本約 1 千美元就能獲得近乎無限的 token 額度。如果改用 API 調(diào)用，費用可能會高出 10 倍。別太糾結(jié)這個數(shù)字，我用過 ccusage 等 token 統(tǒng)計工具，計算并不精確，但即便只有 5 倍差價也絕對超值。

雖然我喜歡 amp 或 Factory 這類工具，但我不認為它們能長期存活。無論是 Codex 還是 Claude Code，每個版本都在進步，最終都會趨同于相似的理念和功能集。某些工具可能在待辦清單、流程引導或開發(fā)者體驗上暫時領先，但我不認為它們能真正撼動大型 AI 公司的競爭優(yōu)勢。

amp 已不再將 GPT-5 作為核心驅(qū)動，現(xiàn)在稱其為 ["預言機"](https://ampcode.com/news/gpt-5-oracle ""預言機"")。而我主要使用 Codex，基本上一直與這個更智能的預言機模型協(xié)同工作。 確實存在基準測試[18] ，但考慮到使用數(shù)據(jù)的偏差，我并不完全信任這些測試結(jié)果。Codex 帶給我的效果遠優(yōu)于 amp。不過必須稱贊他們的會話共享功能，確實推動了一些有趣的創(chuàng)新理念。

Factory 的表現(xiàn)未能說服我。他們的宣傳視頻有些尷尬，雖然在我的時間線上看到不少好評，但目前還不支持圖片處理（尚未實現(xiàn)），而且存在標志性的閃爍問題[19] 。

Cursor...如果你仍親自編寫代碼，它的標簽補全模型確實是行業(yè)標桿。我主要使用 VS Code，但很欣賞他們在瀏覽器自動化和計劃模式等功能上的創(chuàng)新。雖然嘗試過 GPT-5-Pro，但 Cursor 仍然存在五月份就讓我困擾的那些 bug[20]。聽說正在修復中，所以它仍保留在我的程序塢里。

像 Auggie 這樣的項目在我的時間線上只是曇花一現(xiàn)，之后就再無人提及。說到底它們要么基于 GPT-5 要么基于 Sonnet，都是可替代品。RAG 對 Sonnet 或許有幫助，但 GPT-5 的搜索能力已經(jīng)強大到無需為代碼單獨建立向量索引。

最有潛力的候選者是 opencode 和 crush，尤其是與開源模型結(jié)合使用時。你完全可以把 OpenAI 或 Anthropic 的訂閱賬號接入它們（ 多虧了巧妙的 hax 技術(shù)[21] ），但這么做是否被允許存疑，而且用性能較弱的框架來運行專為 Codex 或 Claude Code 優(yōu)化的模型意義何在。

那么 $openmodel 呢？

我持續(xù)關(guān)注著中國的開源模型，它們追趕速度之快令人印象深刻。GLM 4.6 和 Kimi K2.1 都是強勁競爭者，正逐步接近 Sonnet 3.7 的水平，不過我不建議將它們作為主力工具[22]使用。

基準測試只能說明部分情況。在我看來，代理工程在五月份 Sonnet 4.0 發(fā)布時實現(xiàn)了從"這很糟糕"到"這很棒"的跨越，而 gpt-5-codex 的出現(xiàn)則讓我們迎來了從"很棒"到"令人驚嘆"的更大飛躍。

計劃模式與方法

基準測試所忽略的是模型+框架在接收提示時采取的策略。codex 會謹慎得多，它會仔細閱讀你代碼庫中的更多文件后才決定如何行動。 當你提出愚蠢請求時，它的拒絕態(tài)度會更堅決。[23]Claude/其他代理則急切得多，總是急于嘗試_某些方案_ 。通過計劃模式和嚴格的架構(gòu)文檔可以緩解這個問題，但對我而言這就像在修補一個故障系統(tǒng)。

我現(xiàn)在很少對 codex 使用大型計劃文件。codex 甚至沒有專門的計劃模式——但它如此擅長遵循提示，我只需寫下"我們來討論"或"給我?guī)讉€選項"，它就會耐心等待直到我批準。不需要任何框架偽裝。直接對話即可。

但 Claude Code 現(xiàn)在擁有插件[24] 功能

你聽到遠處那聲嘆息了嗎？那是我發(fā)出的。簡直是一派胡言。這次真的讓我對 Anthropic 的關(guān)注點感到失望。他們試圖修補模型中的低效問題。沒錯，為特定任務維護優(yōu)質(zhì)文檔是個好主意。我自己就用 markdown 格式在文檔文件夾里保存了大量實用文檔。

但是但是子代理?。。。?!

不過關(guān)于這套子代理的把戲必須說幾句。今年五月這還叫子任務，主要是當模型不需要完整文本時，將任務拆分到獨立上下文的一種方式——本質(zhì)上是實現(xiàn)并行化或減少上下文浪費（比如處理嘈雜的構(gòu)建腳本）。后來他們重新包裝升級為子代理概念，讓你能帶著指令集漂亮地打包分派任務。

實際用例毫無變化。別人用子代理實現(xiàn)的功能，我通常用分屏就能搞定。想研究什么？開個新終端面板操作，然后粘貼到另一個面板就行。這樣我能完全掌控和觀察自己設計的上下文，不像子代理那樣難以查看、引導或控制返回內(nèi)容。

我們還得談談 Anthropic 在博客中推薦的子代理?？纯催@個 ["AI 工程師"代理](https://github.com/wshobson/agents/blob/main/plugins/llm-application-dev/agents/ai-engineer.md ""AI 工程師"代理") ，簡直就是一堆廢話的大雜燴——提到 GPT-4o 和 o1 進行集成，整體看起來就像自動生成的文字亂燉，試圖強行合理化。里面沒有任何實質(zhì)內(nèi)容能讓你的代理成為更好的"AI 工程師"。

這到底是什么意思？如果你想獲得更好的輸出，告訴模型"你是專門從事生產(chǎn)級 LLM 應用的 AI 工程師"并不會改變什么。給它文檔、示例和注意事項才有幫助。我敢打賭，讓代理"搜索 AI 代理構(gòu)建最佳實踐"并加載一些網(wǎng)站，效果都比這堆垃圾強。你甚至可以說這種廢話是上下文毒藥[25] 。

我的提示詞編寫方式

當初使用 Claude 時，我常常編寫（當然不是我會說[26] ）非常詳盡的提示詞，因為這個模型提供的上下文越多就越"懂我"。雖然這對任何模型都適用，但我發(fā)現(xiàn)使用 Codex 時提示詞變得極其簡短，往往只需 1-2 句話外加一張圖片[27] 。這個模型在理解代碼庫方面表現(xiàn)出色，總能準確領會我的意圖。我甚至有時會回歸純文本輸入，因為 Codex 只需極少上下文就能理解。

添加圖片是個絕妙的技巧，能為模型提供更多上下文——它特別擅長精準識別你展示的內(nèi)容，能快速找到字符串進行匹配并直達你提及的位置。我至少有50%的提示詞都包含截圖，雖然很少添加標注（這樣效果更好但速度較慢）。把截圖拖進終端只需兩秒鐘。

具備語義校正功能的 Wispr Flow[28] 仍是王者。

基于網(wǎng)頁的智能體

最近我又重新測試了幾款網(wǎng)頁智能體：Devin、Cursor 和 Codex。谷歌的 Jules 界面不錯但配置過程令人抓狂，而 Gemini 2.5 已不再是優(yōu)質(zhì)模型。或許等 Gemini 3 Pro[29] 發(fā)布后會有轉(zhuǎn)機。唯一堅持使用的是 Codex 網(wǎng)頁版，雖然配置繁瑣且存在故障——目前終端無法正常加載[30] ，但我用舊版環(huán)境成功運行了它，代價是預熱時間變長。

我將 Codex web 用作短期問題追蹤器。每當外出時有靈感，我就通過 iOS 應用記錄一行文字，稍后在 Mac 上回顧。當然，我完全可以用手機做更多事甚至審閱合并，但我選擇不這么做。我的工作已經(jīng)足夠令人沉迷，所以在外面或見朋友時，我不想被進一步牽扯。說這話的我可是花了近兩個月開發(fā)手機編程工具的人[31] 。

Codex web 原本不計入使用限額，但這樣的日子已所剩無幾[32] 。

智能體演進之路

聊聊這些工具吧。Conductor[33]、Terragon[34]、Sculptor[35] 還有上千種同類。有些是興趣項目，有些則浸沒在風投資金里。我試過太多，沒一個能留下來。在我看來，它們都在圍繞當前低效打轉(zhuǎn)，推崇的并非最優(yōu)工作流。更何況多數(shù)工具隱藏終端界面，不完整顯示模型輸出內(nèi)容。

大多數(shù)只是 Anthropic SDK 的淺層封裝加上工作樹管理，毫無技術(shù)壁壘。我甚至懷疑你是否真的需要在手機上更方便地編寫代理代碼。這些工具對我而言的小用途，codex web 已完全覆蓋。

不過我確實注意到這個現(xiàn)象：幾乎每個工程師都會經(jīng)歷自己造輪子的階段，主要是因為這很有趣，而且現(xiàn)在做起來容易多了。還有什么比（我們認為）能讓造更多工具變得更簡單的工具更值得構(gòu)建的呢？

但 Claude Code 支持后臺任務！

確實。codex 目前缺少 claude 具備的一些花哨功能，最令人頭疼的是缺少后臺任務管理。雖然應該設置超時機制，但我確實多次遇到它因永不結(jié)束的 cli 任務而卡住的情況，比如啟動開發(fā)服務器或陷入死鎖的測試。

這就是我轉(zhuǎn)回使用 claude 的原因之一，但由于該模型在其他方面表現(xiàn)太過幼稚，我現(xiàn)在改用 `tmux`[36]。這是個能在后臺運行 CLI 持久會話的老工具，而且模型本身具備豐富的世界知識，你只需"通過 tmux 運行"即可。完全不需要那些自定義代理的做作把戲。

那 MCPs 呢？

關(guān)于 MCPs 已有大量討論。在我看來，大多數(shù) MCPs 不過是市場部門用來打勾炫耀的噱頭。幾乎所有的 MCPs 都應該用 CLI 實現(xiàn)——說這話的我自己就寫過 5 個 MCPs[37]。

我只需通過名稱引用 CLI 工具，完全不需要在代理配置文件中添加任何說明。首次調(diào)用時，代理會嘗試執(zhí)行 $randomcrap 命令，CLI 會自動顯示幫助菜單，此時上下文已完整掌握該工具的使用方法，后續(xù)調(diào)用就能順暢工作。與持續(xù)消耗上下文資源的 MCPs

參考資料

倫敦 Claude 代碼匿名會: https://x.com/christianklotz/status/1977866496001867925

自從我上次更新工作流程以來 AI 技術(shù)已發(fā)展了一年: https://x.com/pmddomingos/status/1976399060052607469

《最優(yōu) AI 工作流程》文章: https://steipete.me/posts/2025/optimal-ai-development-workflow

位于同一目錄: https://x.com/steipete/status/1977771686176174352

[5]

原子提交: https://x.com/steipete/status/1977498385172050258

[6]

代理配置文件: https://gist.github.com/steipete/d3b9db3fa8eb1d1a692b7656217d8655

[7]

任何鉤子都攔不住: https://x.com/steipete/status/1977119589860601950

[8]

廢話生成器: https://x.com/weberwongwong/status/1975749583079694398

[9]

逐漸成為主流: https://x.com/steipete/status/1976353767705457005

[10]

盡管 codex 是它的粉絲: https://x.com/steipete/status/1977072732136521836

[11]

絕對正確的: https://x.com/vtahowe/status/1976709116425871772

[12]

codex 才是: https://x.com/s_streichsbier/status/1974334735829905648

[13]

正確選擇: https://x.com/kimmonismus/status/1976404152541680038

[14]

消息排隊: https://x.com/steipete/status/1978099041884897517

[15]

這對我的心理健康影響重大: https://x.com/steipete/status/1975297275242160395

[16]

不會到處生成隨機 markdown 文件: https://x.com/steipete/status/1977466373363437914

[17]

懂的都懂: https://x.com/deepfates/status/1975604489634914326

確實存在基準測試: https://x.com/btibor91/status/1976299256383250780

標志性的閃爍問題: https://x.com/badlogicgames/status/1977103325192667323

Cursor 仍然存在五月份就讓我困擾的那些 bug: https://x.com/steipete/status/1976226900516209035

[21]

多虧了巧妙的 hax 技術(shù): https://x.com/steipete/status/1977286197375647870

[22]

主力工具: https://x.com/imfeat7/status/1977246145278583258

[23]

當你提出愚蠢請求時，它的拒絕態(tài)度會更堅決。: https://x.com/thsottiaux/status/1975565380388299112

[24]

插件: https://www.anthropic.com/news/claude-code-plugins

[25]

上下文毒藥: https://x.com/IanIsSoAwesome/status/1976662563699245358

[26]

我會說: https://x.com/steipete/status/1978104202820812905

[27]

一張圖片: https://x.com/steipete/status/1977175451408990379

[28]

Wispr Flow: https://wisprflow.ai/

[29]

Gemini 3 Pro: https://x.com/cannn064/status/1973415142302830878

[30]

無法正常加載: https://x.com/steipete/status/1974798735055192524

[31]

花了近兩個月開發(fā)手機編程工具的人: https://steipete.me/posts/2025/vibetunnel-first-anniversary

[32]

這樣的日子已所剩無幾: https://x.com/steipete/status/1976292221390553236

[33]

Conductor: https://conductor.build/

[34]

Terragon: https://www.terragonlabs.com/

[35]

Sculptor: https://x.com/steipete/status/1973132707707113691

[36]

tmux: https://x.com/steipete/status/1977745596380279006

[37]

自己就寫過 5 個 MCPs: https://github.com/steipete/claude-code-mcp