作者：Peter Steinberger

原文：https://steipete.me/posts/just-talk-to-it

最近我在這兒比較安靜，因?yàn)槲艺耦^于最新項(xiàng)目。Agentic 工程已經(jīng)強(qiáng)大到幾乎 100% 的代碼都由它代寫(xiě)�？晌覅s看到很多人還在繞彎子、搞花活，而不是把事辦成。

這篇文章部分靈感來(lái)自昨晚在倫敦的 Claude Code Anonymous[1] 上的交流，部分則是因?yàn)?距離我上次更新工作流已經(jīng)過(guò)去整整一個(gè)“AI 年”[2] 了，是時(shí)候做個(gè)回顧。

所有核心理念依然適用，所以我不會(huì)再贅述像上下文管理這類(lèi)基礎(chǔ)內(nèi)容。請(qǐng)先閱讀我的 《最佳 AI 工作流》文章[3]作為入門(mén)。

上下文與技術(shù)棧

我獨(dú)自開(kāi)發(fā)，當(dāng)前項(xiàng)目是一個(gè)約 30 萬(wàn)行 TypeScript React 代碼庫(kù)，包括一個(gè) Chrome 擴(kuò)展、一個(gè) CLI、一個(gè)基于 Tauri 的客戶(hù)端應(yīng)用，以及一個(gè)用 Expo 開(kāi)發(fā)的移動(dòng)應(yīng)用。網(wǎng)站托管在 Vercel，每次 PR 大約 2 分鐘即可部署新版本供測(cè)試；其余（應(yīng)用等）尚未自動(dòng)化。

使用方式與總體思路

我已完全把codexcli 當(dāng)作主力工具，每天同時(shí)跑 3–8 個(gè)實(shí)例，排列成 3×3 的終端網(wǎng)格；大多數(shù)放在同一目錄[4] ，部分實(shí)驗(yàn)則另開(kāi)文件夾。我試過(guò) worktrees、PR 等方式，最終都回到這套配置，因?yàn)樗羁斐鼋Y(jié)果。

我的 agents 自己會(huì)做 git 原子提交[5] 。為了保持相對(duì)干凈的提交歷史，我對(duì) agent 文件[6]迭代了很多次，這讓 git 操作更精準(zhǔn)，每個(gè) agent 只提交它改過(guò)的文件。

沒(méi)錯(cuò)，Claude 可以用 hooks，而 codex 暫時(shí)還不支持；但模型極其聰明，只要它們鐵了心， 任何 hook 都攔不住[7] 。

我以前被嘲笑，被稱(chēng)為垃圾生成器[8] ，很高興看到并行代理慢慢成為主流[9] 。

模型選擇器

我?guī)缀跤?gpt-5-codex 的中等配置構(gòu)建所有東西。它在智能和速度之間是很好的折中，并且會(huì)自動(dòng)調(diào)整思考深度。我發(fā)現(xiàn)過(guò)度糾結(jié)這些設(shè)置并不會(huì)帶來(lái)有意義的結(jié)果，不用操心_超思考_也挺好。

爆炸半徑

工作時(shí)，我總會(huì)考慮“爆炸半徑”。這個(gè)詞不是我發(fā)明的，但我非常喜歡。想到一個(gè)改動(dòng)時(shí)，我大致能判斷它會(huì)耗時(shí)多久、會(huì)動(dòng)到多少文件。我可以往代碼庫(kù)里扔很多“小炸彈”，也可以扔一顆“胖子”再補(bǔ)幾個(gè)小的。如果同時(shí)扔多顆大炸彈，就無(wú)法做隔離提交，一旦出錯(cuò)也更難回退。

觀察 agent 時(shí)，這也是個(gè)好指標(biāo)。如果耗時(shí)超出預(yù)期，我直接按 Esc，問(wèn)一句“進(jìn)度如何”，拿到狀態(tài)后再?zèng)Q定幫模型找準(zhǔn)方向、中止還是繼續(xù)。別怕中途打斷，文件變更是原子的，它們很擅長(zhǎng)從斷點(diǎn)續(xù)上。

拿不準(zhǔn)影響范圍時(shí)，我會(huì)用“先給我?guī)讉�(gè)方案再動(dòng)手”來(lái)評(píng)估。

為什么不用 worktrees？

我只跑一個(gè)開(kāi)發(fā)服務(wù)器，隨著項(xiàng)目演進(jìn)，我會(huì)點(diǎn)來(lái)點(diǎn)去，一次驗(yàn)證多處改動(dòng)。如果每個(gè)改動(dòng)都建分支/樹(shù)，速度會(huì)慢很多；開(kāi)多個(gè) dev server 也很快讓人抓狂。Twitter OAuth 還有域名限制，我只能注冊(cè)少數(shù)幾個(gè)回調(diào)域名。

那 Claude Code 呢？

我曾經(jīng)很愛(ài) Claude Code，現(xiàn)在完全受不了（ 盡管 codex 是它的粉絲[10] ）。它的語(yǔ)氣、那種 “絕對(duì)正確”[11]、測(cè)試全掛卻告訴你“100% 生產(chǎn)就緒”的口吻——我真的受夠了。Codex 更像內(nèi)向的工程師，默默推進(jìn)，把事情搞定。它開(kāi)工前會(huì)讀更多文件，所以哪怕提示很短，通常也能一次到位。

我時(shí)間線上幾乎所有人都認(rèn)同：codex 才是正道[12] 。[13]

Codex 的其他優(yōu)勢(shì)

• 約 23 萬(wàn)可用上下文，對(duì)比 Claude 的 15.6 萬(wàn)。沒(méi)錯(cuò)，如果你運(yùn)氣好或愿意按 API 價(jià)付費(fèi)，也能用到 Sonnet 1M，但現(xiàn)實(shí)是 Claude 在耗盡上下文前早就“犯傻”了，根本沒(méi)法真正利用那么長(zhǎng)的窗口。

• 更高效的 token 利用率。不知道 OpenAI 做了什么優(yōu)化，但我的上下文消耗速度遠(yuǎn)慢于 Claude Code。以前用 Claude 時(shí)經(jīng)�？匆�(jiàn)“正在壓縮…”，換成 Codex 后幾乎沒(méi)撐爆過(guò)上下文。

• 消息隊(duì)列。Codex 支持 排隊(duì)發(fā)消息 [14] 。Claude 原本也有，但幾個(gè)月前他們改成讓新消息“引導(dǎo)”模型。如果想引導(dǎo) Codex，我只需按 Esc 再回車(chē)就能發(fā)新消息。兩種模式任選顯然更好。我常把相關(guān)功能任務(wù)排成隊(duì)列，它總能穩(wěn)定地一件件完成。

• 速度OpenAI 用 Rust 重寫(xiě)了 Codex，效果立竿見(jiàn)影——快到離譜。用 Claude Code 時(shí)，我經(jīng)常遇到幾秒卡頓，進(jìn)程內(nèi)存直接飆到 GB 級(jí)，終端還狂閃，尤其是 Ghostty。Codex 完全沒(méi)有這些毛病，輕盈又迅捷。

• 語(yǔ)言。這對(duì)我的心理健康真的很重要。 [15] 我曾無(wú)數(shù)次對(duì)著 Claude 咆哮，卻很少對(duì) Codex 發(fā)火。哪怕 Codex 模型差一點(diǎn)，單憑這點(diǎn)我也會(huì)選它。兩者各用幾周，你自會(huì)明白。

• 不會(huì)再有隨機(jī) Markdown 文件到處躺尸 [16] 。 懂的都懂 [17] 。

在我看來(lái)，最終用戶(hù)和模型公司之間幾乎沒(méi)有中間地帶。我用訂閱制最劃算。目前我有 4 個(gè) OpenAI 訂閱和 1 個(gè) Anthropic 訂閱，每月總共約 1k 美元，基本無(wú)限 token。如果用 API 調(diào)用，費(fèi)用大概貴 10 倍。別跟我摳數(shù)學(xué)，我用過(guò) ccusage 這類(lèi) token 計(jì)數(shù)工具，數(shù)據(jù)都不精確，但就算只貴 5 倍也是血賺。

我喜歡 amp、Factory 這類(lèi)工具，只是不看好它們能長(zhǎng)期存活。codex 和 claude code 每次更新都在進(jìn)步，功能和思路越來(lái)越趨同。也許某家在待辦列表、引導(dǎo)或輕微 dx 特性上暫時(shí)領(lǐng)先，但我不認(rèn)為它們能顯著跑贏大型 AI 公司。

amp 已經(jīng)不再把 GPT-5 當(dāng)作主推模型，現(xiàn)在把它稱(chēng)為 “oracle”[18]。與此同時(shí)，我用的是 codex，基本上一直在和這個(gè)更聰明的模型——oracle——并肩工作。 當(dāng)然有基準(zhǔn)測(cè)試[19] ，但鑒于使用數(shù)據(jù)嚴(yán)重偏斜，我并不相信那些結(jié)果。codex 給我的效果遠(yuǎn)比 amp 好。不過(guò) session 共享這點(diǎn)我得給他們點(diǎn)贊，他們確實(shí)在推進(jìn)一些有趣的想法。

工廠，還是不信。他們的視頻有點(diǎn)尷尬，不過(guò)我的時(shí)間線上確實(shí)有不少好評(píng)，盡管還不支持圖片，而且?guī)в袠?biāo)志性的閃爍[20] 。

Cursor 的 Tab 補(bǔ)全模型在業(yè)界領(lǐng)先，前提是你還親自寫(xiě)代碼。我主要用 VS Code，但挺欣賞他們?cè)跒g覽器自動(dòng)化和計(jì)劃模式上的推進(jìn)。我確實(shí)試過(guò) GPT-5-Pro，可 Cursor 那些五月就煩過(guò)我的老 bug 還在[21] 。聽(tīng)說(shuō)在修，所以我把它留在 Dock 里。

像 Auggie 這樣的工具在我時(shí)間線上只冒了個(gè)泡，之后再?zèng)]人提起。歸根結(jié)底，它們都不過(guò)是套了 GPT-5 和/或 Sonnet 的殼，隨時(shí)可換。RAG 對(duì) Sonnet 或許有用，但 GPT-5 的檢索能力太強(qiáng)，根本沒(méi)必要再給代碼建獨(dú)立向量索引。

最有盼頭的是 opencode 和 crush，尤其是搭配開(kāi)源模型。你完全可以用自己的 OpenAI 或 Anthropic 訂閱（ 靠點(diǎn)小技巧[22] ），不過(guò)這么做是否合規(guī)存疑，而且把為 Codex 或 Claude Code 優(yōu)化的模型塞進(jìn)一個(gè)更弱的套殼里，意義何在？

那 $openmodel呢？

我一直關(guān)注中國(guó)的開(kāi)源模型，它們追趕的速度令人驚嘆。GLM 4.6 和 Kimi K2.1 都是強(qiáng)有力的競(jìng)爭(zhēng)者，正逐步逼近 Sonnet 3.7 的水準(zhǔn)，不過(guò)我依然不把它們當(dāng)作日常主力[23] 。

基準(zhǔn)測(cè)試只能說(shuō)明一半。在我看來(lái)，智能體工程在五月隨著 Sonnet 4.0 的發(fā)布，從“這玩意兒不行”躍升到“這還不錯(cuò)”；而 gpt-5-codex 的出現(xiàn)，則讓我們從“不錯(cuò)”直接飛躍到“這也太神了”。

規(guī)劃模式與方法

基準(zhǔn)測(cè)試忽略了“模型+測(cè)試框架”在收到提示時(shí)所采取的策略。Codex 遠(yuǎn)比其他模型謹(jǐn)慎，在決定行動(dòng)前會(huì)讀取倉(cāng)庫(kù)中的更多文件。 當(dāng)你提出一個(gè)愚蠢請(qǐng)求時(shí)，它會(huì)更有力地反駁。[24] Claude 等智能體則急切得多，先隨便試_點(diǎn)什么_再說(shuō)。這可以通過(guò)規(guī)劃模式和嚴(yán)格的結(jié)構(gòu)化文檔來(lái)緩解，但對(duì)我來(lái)說(shuō)這像是在給破系統(tǒng)打補(bǔ)丁。

我現(xiàn)在幾乎不用大規(guī)劃文件與 Codex 協(xié)作。Codex 甚至沒(méi)有專(zhuān)門(mén)的規(guī)劃模式——但它對(duì)提示的遵從度高得多，我只需寫(xiě)“我們先討論”或“給我?guī)讉�(gè)選項(xiàng)”，它就會(huì)耐心等我拍板，不需要任何測(cè)試框架的花招。直接跟它說(shuō)話(huà)就行。

但 Claude Code 現(xiàn)在有了插件[25]

你聽(tīng)到遠(yuǎn)處那聲嘆息了嗎？是我。真是一坨大寫(xiě)的廢話(huà)。這讓我對(duì) Anthropic 的重心徹底失望。他們?cè)噲D用插件給模型的低效打補(bǔ)丁。沒(méi)錯(cuò)，為特定任務(wù)維護(hù)好文檔是明智之舉——我在 docs 文件夾里放了一大摞有用的 Markdown 文檔。

可是子代理啊�。�！

但關(guān)于這場(chǎng)子代理的整段舞蹈，總得說(shuō)兩句。早在五月，它還叫子任務(wù)，主要是一種在模型不需要全文時(shí)把任務(wù)甩到獨(dú)立上下文里的做法——核心目的是并行化，或減少像嘈雜構(gòu)建腳本這類(lèi)場(chǎng)景的上下文浪費(fèi)。后來(lái)他們重新包裝并升級(jí)為子代理，于是你帶著幾條指令就能優(yōu)雅地甩出一個(gè)任務(wù)。

使用場(chǎng)景沒(méi)變。別人用子代理做的事，我通�？块_(kāi)幾個(gè)獨(dú)立窗口搞定。如果我想研究點(diǎn)什么，就在另一個(gè)終端面板里做完，再貼到另一個(gè)面板。這樣我能完全掌控并看見(jiàn)我所設(shè)計(jì)的上下文，而子代理卻讓你更難查看、引導(dǎo)或控制回傳的內(nèi)容。

我們還得聊聊 Anthropic 在博客中推薦的那個(gè)子代理�？纯催@個(gè) “AI 工程師”代理[26] 。它是一鍋大雜燴，提到 GPT-4o 和 o1 的集成，整體就像自動(dòng)生成的詞語(yǔ)濃湯，努力裝作有意義。里面沒(méi)有任何實(shí)質(zhì)內(nèi)容能讓你的代理成為更優(yōu)秀的“AI 工程師”。

這到底是什么意思？如果你想得到更好的輸出，告訴模型“你是一名專(zhuān)注于生產(chǎn)級(jí) LLM 應(yīng)用的 AI 工程師”并不會(huì)改變什么。給它文檔、示例和“做/不做”清單才有用。我打賭，如果你讓 agent 去“Google AI agent 構(gòu)建最佳實(shí)踐”并讓它加載一些網(wǎng)站，效果會(huì)比這堆廢話(huà)好得多。你甚至可以說(shuō)這種垃圾就是上下文毒藥[27] 。

我如何寫(xiě)提示

當(dāng)初用 claude 時(shí)，我（當(dāng)然沒(méi)有， 我說(shuō)話(huà)[28] ）會(huì)寫(xiě)非常冗長(zhǎng)的提示，因?yàn)檫@個(gè)模型“懂我”，我給的上下文越多越準(zhǔn)。雖然對(duì)任何模型都成立，但我發(fā)現(xiàn)用 codex 后提示詞明顯變短了。往往只有一兩句話(huà)+ 一張圖[29] 。這模型讀代碼庫(kù)的能力驚人，直接就能 get 到我。我有時(shí)甚至回歸打字，因?yàn)?codex 理解所需的上下文實(shí)在太少了。

添加圖片是一個(gè)絕佳的技巧，可以提供更多上下文，模型非常擅長(zhǎng)精準(zhǔn)定位你展示的內(nèi)容，它能找到字符串并匹配，直接抵達(dá)你提到的地方。我敢說(shuō)，至少 50% 的提示里都有截圖。我很少做標(biāo)注，那樣效果更好，但速度較慢。把截圖拖進(jìn)終端只需 2 秒。

帶語(yǔ)義修正的 Wispr Flow[30] 依然是王者。

基于網(wǎng)頁(yè)的 Agent

最近我又折騰了一番網(wǎng)頁(yè) Agent：Devin、Cursor 和 Codex。Google 的 Jules 看起來(lái)不錯(cuò)，但配置過(guò)程實(shí)在煩人，而且 Gemini 2.5 現(xiàn)在已經(jīng)算不上好模型了。等 Gemini 3 Pro[31] 發(fā)布，情況可能會(huì)迅速改變。唯一留下來(lái)的是 codex web。它同樣難配置且問(wèn)題多多，目前終端加載不正常[32] ，但我用了一份舊環(huán)境鏡像，總算跑了起來(lái)，代價(jià)是啟動(dòng)更慢。

我用 Codex Web 當(dāng)臨時(shí)問(wèn)題跟蹤器。出門(mén)在外想到什么，就在 iOS 應(yīng)用里丟一句話(huà)，回頭在 Mac 上統(tǒng)一處理。當(dāng)然，我完全可以做更多，甚至直接在手機(jī)上審閱/合并，但我選擇不。工作已經(jīng)夠上癮了，出門(mén)或見(jiàn)朋友時(shí)我不想再被拉進(jìn)去。嘿，這話(huà)出自一個(gè)花了快兩個(gè)月做工具、只為讓手機(jī)寫(xiě)代碼更方便[33]的人。

Codex Web 原本不計(jì)入用量上限，但這種好日子已經(jīng)屈指可數(shù)[34] 。

智能體之旅

聊聊工具。Conductor[35]、Terragon[36]、Sculptor[37]，還有上千個(gè)同類(lèi)。有的是興趣項(xiàng)目，有的泡在 VC 的錢(qián)海里。我試了一大堆，沒(méi)有一個(gè)留下。在我看來(lái)，它們都在繞開(kāi)當(dāng)下的低效，并推行一種并不最優(yōu)的工作流。更別提，大多數(shù)把終端藏起來(lái)，不讓用戶(hù)看到模型輸出的全部?jī)?nèi)容。

大多數(shù)只是 Anthropic SDK 的薄殼 + 工作樹(shù)管理，沒(méi)有護(hù)城河。我甚至懷疑你是否真的想在手機(jī)上更方便地調(diào)用編程智能體。它們帶給我的那點(diǎn)用例，codex web 已完全覆蓋。

我確實(shí)注意到一個(gè)模式：幾乎每位工程師都會(huì)經(jīng)歷一段“造自己的工具”的階段，大多因?yàn)楹猛�，也因�(yàn)楝F(xiàn)在做起來(lái)太容易了。除了造那些（我們以為）能讓以后造工具更簡(jiǎn)單的工具，還能造什么呢？

但 Claude Code 支持后臺(tái)任務(wù)！

沒(méi)錯(cuò)。codex 目前確實(shí)少了些 Claude 的花哨功能，最痛的缺失是后臺(tái)任務(wù)管理。雖然它該有超時(shí)機(jī)制，但我已多次遇到 CLI 任務(wù)卡住的情況，比如啟動(dòng) dev server 或陷入死鎖的測(cè)試。

這就是我又轉(zhuǎn)回 Claude 的原因之一，但鑒于該模型在其他方面實(shí)在蠢得離譜，我現(xiàn)在用 `tmux`[38]。這是個(gè)老工具，可在后臺(tái)持久會(huì)話(huà)里跑 CLI，模型里也有充足的世界知識(shí)，所以你只需“用 tmux 跑”。無(wú)需定制 agent md 的瞎折騰。

那 MCP 呢

關(guān)于 MCP，別人已經(jīng)寫(xiě)了很多。在我看來(lái)，大多數(shù)只是給市場(chǎng)部打勾炫耀用的。幾乎所有 MCP 其實(shí)就該是 CLI。說(shuō)這話(huà)的人， 我自己就寫(xiě)了 5 個(gè) MCP[39]。

我可以直接通過(guò)名稱(chēng)調(diào)用 CLI，無(wú)需在 agents 文件里寫(xiě)任何說(shuō)明。代理第一次調(diào)用時(shí)會(huì)隨便敲個(gè) $randomcrap，CLI 會(huì)彈出幫助菜單，于是上下文立刻就掌握了全部用法，之后一路順暢。不像 MCP 那樣持續(xù)燒錢(qián)、把垃圾塞進(jìn)上下文，我無(wú)需為任何工具付費(fèi)。用 GitHub 的 MCP，一次就燒掉 23k token——他們后來(lái)優(yōu)化過(guò)，剛上線時(shí)差點(diǎn) 50k。換成ghCLI，功能幾乎一樣，模型本來(lái)就會(huì)用，上下文稅為零。

我把部分 CLI 工具開(kāi)源了，比如 bslog[40] 和 inngest[41]。

我現(xiàn)在用 `chrome-devtools-mcp`[42] 來(lái)閉環(huán)[43] ，它已取代 Playwright 成為我調(diào)試網(wǎng)頁(yè)的首選 MCP。雖然用得不多，但真要用時(shí)，它能很好地閉環(huán)。我給自己的網(wǎng)站做了設(shè)計(jì)：可以生成 API Key，讓模型通過(guò) curl 查詢(xún)?nèi)我舛它c(diǎn)，幾乎所有場(chǎng)景下都更快、更省 token，所以連這個(gè) MCP 也不是天天需要。

但代碼就是一坨屎！

我大約把 20% 的時(shí)間[44]花在重構(gòu)上。當(dāng)然，這些全由智能體完成，我可不會(huì)手動(dòng)浪費(fèi)時(shí)間。重構(gòu)日非常適合在我精力不足或疲憊時(shí)進(jìn)行，因?yàn)闊o(wú)需太多專(zhuān)注或清晰思考也能取得顯著進(jìn)展。

典型的重構(gòu)工作包括：用jscpd查重、用 `knip`[45] 清理死代碼、跑eslint的react-compiler和廢棄插件、檢查能否合并新引入的 API 路由、維護(hù)文檔、拆分過(guò)大的文件、為棘手部分補(bǔ)測(cè)試和注釋、更新依賴(lài)、 升級(jí)工具鏈[46] 、調(diào)整目錄結(jié)構(gòu)、找出并重寫(xiě)慢測(cè)試、引入現(xiàn)代 React 模式并重寫(xiě)代碼（例如你可能不需要 `useEffect`[47]）�？傆惺虑榭勺�。

你可以說(shuō)這些應(yīng)該在每次提交時(shí)就做，但我發(fā)現(xiàn)“快速迭代→維護(hù)改進(jìn)”這種階段式節(jié)奏——也就是償還技術(shù)債——反而更高效，也更有趣。

你采用“先寫(xiě)規(guī)格再開(kāi)發(fā)”嗎？

我六月份還這么做[48] 。先設(shè)計(jì)一份大規(guī)格，然后讓模型照著敲代碼，最好一口氣跑幾個(gè)小時(shí)。在我看來(lái)，這已經(jīng)是老派的軟件開(kāi)發(fā)思路了。

現(xiàn)在我通常直接跟 Codex 開(kāi)聊：把網(wǎng)頁(yè)、點(diǎn)子貼進(jìn)去，讓它讀代碼，我們一起把新功能揉出來(lái)。如果邏輯比較繞，我就讓它把所有內(nèi)容寫(xiě)成一份規(guī)格，扔給 GPT-5-Pro 審一遍（通過(guò) chatgpt.com），看看有沒(méi)有更好的主意（出乎意料地，計(jì)劃常常因此大幅改進(jìn)！），再把我覺(jué)得有用的部分貼回主上下文，更新文件。

到現(xiàn)在，我對(duì)哪些任務(wù)需要多少上下文已經(jīng)心里有數(shù)，而 codex 的上下文容量相當(dāng)不錯(cuò)，所以我常常直接開(kāi)干。有些人很“虔誠(chéng)”，每次都清空上下文重新規(guī)劃——我覺(jué)得這對(duì) Sonnet 有用，但 GPT-5 處理大上下文強(qiáng)得多，那樣做反而每次得多花 10 分鐘，讓模型慢慢把構(gòu)建功能所需的文件重新拉一遍。

更有趣的做法是做 UI 相關(guān)的工作時(shí)，我往往從極其簡(jiǎn)單、嚴(yán)重缺需求的請(qǐng)求開(kāi)始，看著模型實(shí)時(shí)構(gòu)建、瀏覽器同步刷新。接著我把后續(xù)改動(dòng)排隊(duì)進(jìn)去，持續(xù)迭代功能。很多時(shí)候我根本不確定最終該長(zhǎng)什么樣，這樣就能邊玩邊試，看著它慢慢成形。我常見(jiàn) codex 做出我壓根沒(méi)想到的有趣效果；我不重置，只是不斷迭代，把混沌一點(diǎn)點(diǎn)捏成我覺(jué)得對(duì)的樣子。

構(gòu)建過(guò)程中，我常會(huì)蹦出相關(guān)交互的靈感，順手把別的部分也改了；這部分我交給另一個(gè) agent 處理。通常我主攻一個(gè)核心功能，再捎帶幾個(gè)沾邊的小任務(wù)。

我一邊寫(xiě)這篇文章，一邊在 Chrome 擴(kuò)展里新建 Twitter 數(shù)據(jù)導(dǎo)入器，為此我重構(gòu)了 graphql 導(dǎo)入器。因?yàn)椴淮_定方案是否合適，我把它放在獨(dú)立文件夾，方便提 PR 時(shí)回頭審視。主倉(cāng)庫(kù)在做重構(gòu)，所以我能專(zhuān)心寫(xiě)這篇文章。

讓我看看你的斜杠命令！

我只有幾個(gè)，而且很少用：

• /commit（自定義提示，說(shuō)明多個(gè) agent 在同一目錄工作，只需提交你的改動(dòng)，這樣我就能得到干凈的提交信息，gpt 不會(huì)因?yàn)槠渌膭?dòng)而崩潰，也不會(huì)在 linter 報(bào)錯(cuò)時(shí)試圖回滾）

• /automerge（一次處理一個(gè) PR，回應(yīng)機(jī)器人評(píng)論、回復(fù)，讓 CI 變綠，并在變綠后 squash）

• /massageprs（與 automerge 相同，只是不 squash，這樣如果 PR 很多，我可以并行處理）

• /review（內(nèi)置，偶爾用，因?yàn)?GitHub 上已有 review 機(jī)器人，但有時(shí)仍有用）

即便有了這些，我通常還是只打“commit”；除非明知臟文件太多，不給點(diǎn)提示代理可能會(huì)搞砸。當(dāng)我確信這幾個(gè)字就夠了，就不必再玩花樣/浪費(fèi)上下文。你會(huì)慢慢培養(yǎng)出直覺(jué)。我還沒(méi)見(jiàn)過(guò)其他真正有用的命令。

你還有哪些別的技巧？

與其絞盡腦汁寫(xiě)出完美提示來(lái)驅(qū)動(dòng) Agent 完成長(zhǎng)時(shí)間任務(wù)，不如用“懶人方案”。做大重構(gòu)時(shí)，Codex 經(jīng)常半路就停下來(lái)。如果你想走開(kāi)等結(jié)果， **直接連發(fā)幾條“繼續(xù)”消息**[49]即可。Codex 完成后若再收到消息， 它會(huì)愉快地?zé)o視[50] 。

讓模型在每個(gè)功能/修復(fù)完成后立刻寫(xiě)測(cè)試，用同一份上下文。這樣測(cè)試質(zhì)量會(huì)高得多，還能揪出實(shí)現(xiàn)里的 bug。純 UI 微調(diào)就沒(méi)必要寫(xiě)測(cè)試，其他情況都建議寫(xiě)。AI 寫(xiě)測(cè)試普遍一般，但聊勝于無(wú)——說(shuō)實(shí)話(huà)，你自己會(huì)給每個(gè)小修復(fù)都補(bǔ)測(cè)試嗎？

讓模型保留你的意圖，并“在復(fù)雜處加注釋”，對(duì)你和未來(lái)的模型運(yùn)行都有好處。

當(dāng)遇到難題時(shí)，只需提示并加入一些觸發(fā)詞，如“慢慢來(lái)”“全面”“閱讀所有可能相關(guān)的代碼”“提出可能的假設(shè)”，就能讓 Codex 解決最棘手的問(wèn)題。

你的 Agents/Claude 文件長(zhǎng)什么樣？

我有一個(gè) Agents.md 文件，通過(guò)符號(hào)鏈接指向 claude.md，因?yàn)?Anthropic 決定不做標(biāo)準(zhǔn)化。我知道這很別扭，也不理想，畢竟 GPT-5 偏好的提示方式[51] 與 Claude 差異很大。如果你還沒(méi)讀過(guò)它們的提示指南，現(xiàn)在先停下來(lái)去讀。

Claude 對(duì) 全大寫(xiě)尖叫命令 [52] 反應(yīng)良好——比如威脅它“如果執(zhí)行命令 X 就意味著徹底失敗，100 只小貓會(huì)死”——但 GPT-5 會(huì)被嚇到（理所當(dāng)然）。所以把這些都扔掉，像人類(lèi)一樣說(shuō)話(huà)。這也意味著這些文件無(wú)法最優(yōu)共享。但對(duì)我不是問(wèn)題，因?yàn)槲抑饕?Codex，并接受在極少數(shù)讓 Claude 上場(chǎng)時(shí)，指令可能偏弱。

我的 Agent 文件目前約有 800 行，感覺(jué)像是一堆組織留下的“疤痕”。不是我寫(xiě)的，是 Codex 寫(xiě)的；每當(dāng)發(fā)生什么事，我就讓它在里面添一句簡(jiǎn)明備注。我遲早得清理，但盡管龐大，它卻出奇地好用，GPT 也確實(shí)大多會(huì)遵從里面的條目——至少比 Claude 靠譜得多。（給點(diǎn)面子的話(huà)，Sonnet 4.5 在這方面有進(jìn)步。）

除了 git 指令，它還包含對(duì)我的產(chǎn)品的說(shuō)明、我偏好的命名和 API 模式、關(guān)于 React Compiler 的筆記——往往是我用的技術(shù)棧太前沿，超出了模型世界知識(shí)范圍的東西。我預(yù)計(jì)隨著模型更新，又能精簡(jiǎn)不少。例如，Sonnet 4.0 得靠我指點(diǎn)才能理解 Tailwind 4，而 Sonnet 4.5 和 GPT-5 已經(jīng)內(nèi)置了這部分知識(shí)，于是我把那些廢話(huà)全刪了。

重點(diǎn)部分包括我偏好的 React 模式、數(shù)據(jù)庫(kù)遷移管理、測(cè)試、 使用并編寫(xiě) ast-grep 規(guī)則[53] 。（如果你不了解或沒(méi)用過(guò) ast-grep 作為代碼庫(kù)檢查工具，請(qǐng)先暫停，讓你的模型把它配置成 Git 鉤子以阻止提交。）

我也嘗試過(guò)并開(kāi)始使用基于文本的“設(shè)計(jì)系統(tǒng)”[54] 來(lái)規(guī)范外觀，目前尚無(wú)定論。

所以 GPT-5-Codex 就完美了？

當(dāng)然不是。有時(shí)候它會(huì)重構(gòu)半小時(shí)，然后崩潰[55]并全部回退，你得像哄小孩一樣重新運(yùn)行并安撫它，告訴它時(shí)間足夠。有時(shí)它會(huì)忘了自己還能執(zhí)行 bash 命令[56] ，需要一點(diǎn)鼓勵(lì)。有時(shí)它會(huì)用俄語(yǔ)或韓語(yǔ)[57]回復(fù)。 有時(shí)這家伙一滑，把原始思考發(fā)給了 bash。[58] 但總的來(lái)說(shuō)這些情況相當(dāng)罕見(jiàn)，它在其他方面簡(jiǎn)直好得離譜，所以我可以忽略這些小毛病。人類(lèi)也不完美。

我對(duì) codex 最大的煩惱是它“丟”行，快速往上滾時(shí)部分內(nèi)容會(huì)消失。我真希望這排在 OpenAI 的 bug 清單首位，因?yàn)樗俏矣袝r(shí)不得不放慢速度、以免消息消失的主要原因。

結(jié)論

別把時(shí)間浪費(fèi)在 RAG、子代理、Agents 2.0[59] 這類(lèi)多半只是噱頭的玩意兒上。直接跟它聊，玩起來(lái)，培養(yǎng)直覺(jué)。你跟代理打得越多，結(jié)果就越好。

Simon Willison 的文章說(shuō)得極是[60] ——管理代理所需的很多技能，跟管理工程師[61]差不多——幾乎全是資深軟件工程師的特質(zhì)。

沒(méi)錯(cuò)， 寫(xiě)好軟件依舊很難[62] 。我不再手寫(xiě)代碼，不代表我就不再深入思考架構(gòu)、系統(tǒng)設(shè)計(jì)、依賴(lài)、功能，或者怎樣讓用戶(hù)驚喜。用 AI 只是意味著大家對(duì)交付的期望值更高了。

PS：這篇文章 100% 有機(jī)手寫(xiě)。我熱愛(ài) AI，也承認(rèn)有些事還是老派[63]來(lái)得好。保留錯(cuò)別字，保留我的聲音。??[64]

參考資料

Claude Code Anonymous: https://x.com/christianklotz/status/1977866496001867925

距離我上次更新工作流已經(jīng)過(guò)去整整一個(gè)“AI 年”: https://x.com/pmddomingos/status/1976399060052607469

《最佳 AI 工作流》文章: https://steipete.me/posts/2025/optimal-ai-development-workflow

放在同一目錄: https://x.com/steipete/status/1977771686176174352

[5]

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

[6]

agent 文件: https://gist.github.com/steipete/d3b9db3fa8eb1d1a692b7656217d8655

[7]

任何 hook 都攔不住: 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]

“絕對(duì)正確”: https://x.com/vtahowe/status/1976709116425871772

[12]

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

[13]

。: https://x.com/kimmonismus/status/1976404152541680038

[14]

排隊(duì)發(fā)消息: https://x.com/steipete/status/1978099041884897517

[15]

這對(duì)我的心理健康真的很重要。: https://x.com/steipete/status/1975297275242160395

[16]

不會(huì)再有隨機(jī) Markdown 文件到處躺尸: https://x.com/steipete/status/1977466373363437914

[17]

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

“oracle”: https://ampcode.com/news/gpt-5-oracle

當(dāng)然有基準(zhǔn)測(cè)試: https://x.com/btibor91/status/1976299256383250780

標(biāo)志性的閃爍: https://x.com/badlogicgames/status/1977103325192667323

[21]

Cursor 那些五月就煩過(guò)我的老 bug 還在: https://x.com/steipete/status/1976226900516209035

[22]

靠點(diǎn)小技巧: https://x.com/steipete/status/1977286197375647870

[23]

日常主力: https://x.com/imfeat7/status/1977246145278583258

[24]

當(dāng)你提出一個(gè)愚蠢請(qǐng)求時(shí)，它會(huì)更有力地反駁。: https://x.com/thsottiaux/status/1975565380388299112

[25]

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

[26]

“AI 工程師”代理: https://github.com/wshobson/agents/blob/main/plugins/llm-application-dev/agents/ai-engineer.md

[27]

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

[28]

我說(shuō)話(huà): https://x.com/steipete/status/1978104202820812905

[29]

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

[30]

Wispr Flow: https://wisprflow.ai/

[31]

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

[32]

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

[33]

花了快兩個(gè)月做工具、只為讓手機(jī)寫(xiě)代碼更方便: https://steipete.me/posts/2025/vibetunnel-first-anniversary

[34]

這種好日子已經(jīng)屈指可數(shù): https://x.com/steipete/status/1976292221390553236

[35]

Conductor: https://conductor.build/

[36]

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

[37]

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

[38]

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

[39]

我自己就寫(xiě)了 5 個(gè) MCP: https://github.com/steipete/claude-code-mcp

[40]

bslog: https://github.com/steipete/bslog

[41]

inngest: https://github.com/steipete/inngest

[42]

chrome-devtools-mcp: https://developer.chrome.com/blog/chrome-devtools-mcp

[43]

來(lái)閉環(huán): https://x.com/steipete/status/1977762275302789197

[44]

20% 的時(shí)間: https://x.com/steipete/status/1976985959242907656

[45]

knip: https://knip.dev/

[46]

升級(jí)工具鏈: https://x.com/steipete/status/1977472427354632326

[47]

你可能不需要useEffect: https://react.dev/learn/you-might-not-need-an-effect

[48]

我六月份還這么做: https://steipete.me/posts/2025/the-future-of-vibe-coding

[49]

直接連發(fā)幾條“繼續(xù)”消息: https://x.com/steipete/status/1978099041884897517

[50]

它會(huì)愉快地?zé)o視: https://x.com/steipete/status/1978111714685063640

[51]

GPT-5 偏好的提示方式: https://cookbook.openai.com/examples/gpt-5/gpt-5_prompting_guide

[52]

全大寫(xiě)尖叫命令 : https://x.com/Altimor/status/1975752110164578576

[53]

使用并編寫(xiě) ast-grep 規(guī)則: https://x.com/steipete/status/1963411717192651154

[54]

基于文本的“設(shè)計(jì)系統(tǒng)”: https://x.com/steipete/status/1973838406099874130

[55]

崩潰: https://x.com/steipete/status/1973834765737603103

[56]

bash 命令: https://x.com/steipete/status/1977695411436392588

[57]

用俄語(yǔ)或韓語(yǔ): https://x.com/steipete/status/1976207732534300940

[58]

有時(shí)這家伙一滑，把原始思考發(fā)給了 bash。: https://x.com/steipete/status/1974108054984798729

[59]

Agents 2.0: https://x.com/steipete/status/1977660298367766766

[60]

Simon Willison 的文章說(shuō)得極是: https://simonwillison.net/2025/Oct/7/vibe-engineering/

[61]

管理工程師: https://x.com/lukasz_app/status/1974424549635826120

[62]

寫(xiě)好軟件依舊很難: https://x.com/svpino/status/1977396812999688371

[63]

老派: https://x.com/Alphafox78/status/1975679120898965947

[64]

??: https://x.com/rohanpaul_ai/status/1977005259567595959