聞樂 發(fā)自 凹非寺
量子位 | 公眾號(hào) QbitAI

AI Coding火到不用多說，但怎么用才最高效呢？

這份連大神卡帕西和OpenAI總裁Greg Brockman都在轉(zhuǎn)發(fā)推薦的Coding Agents指南，用3招教你快速交付。

大神們?cè)谵D(zhuǎn)，網(wǎng)友也在夸！

這份實(shí)戰(zhàn)指南的作者是Swift開發(fā)出身、深耕AI驅(qū)動(dòng)開發(fā)領(lǐng)域的大神Peter Steinberger，他也是一位AI Coding重度愛好者，已經(jīng)寫了很多份實(shí)戰(zhàn)經(jīng)驗(yàn)博客。

簡單總結(jié)一下今天的這篇AI Coding指南：先按任務(wù)類型選對(duì)模型，再重構(gòu)工作流提速，但要捋清人機(jī)分工。

Peter不僅給出了自己的模型配置，最后還有實(shí)用小技巧～

三大關(guān)鍵策略

按任務(wù)類型選對(duì)模型

大家用AI編碼，很多時(shí)候是不是一個(gè)模型用到底？

結(jié)果一到大項(xiàng)目就卡殼，小項(xiàng)目修改還慢。問題呢，就出在“沒給模型找對(duì)活兒”。

人家這份指南里就說了，第一步就得先按任務(wù)類型給Coding模型分好工。大任務(wù)就用Codex，小任務(wù)Opus更好使

比如，搞幾十頁的工程規(guī)范落地、項(xiàng)目重構(gòu)這種大活兒就直接上Codex，它有個(gè)特點(diǎn)，開始寫代碼前會(huì)默讀文件，把項(xiàng)目邏輯摸透，雖然比Opus多花點(diǎn)時(shí)間，但對(duì)復(fù)雜需求的完成度更好。

Peter之前重構(gòu)Opus 4.0的舊代碼，Codex花了幾個(gè)小時(shí)讀透了整個(gè)項(xiàng)目，不僅沒漏關(guān)鍵邏輯，還修復(fù)了2個(gè)隱藏Bug。

如果只是小范圍修改這種比較零碎的任務(wù)，那Opus更合適。它不用讀很久的文件，響應(yīng)很快，基本上幾分鐘就能出結(jié)果。

不過，要進(jìn)階的話，首選GPT-5.2-Codex，直接一步到位。

現(xiàn)在Peter最常用的就是GPT-5.2-Codex，尤其是high模式，不管搭Chrome擴(kuò)展的前端還是寫Go語言的CLI工具，它都能兼顧速度和準(zhǔn)確率，也不用在Codex和Opus之間來回切換了。

在這里，Peter還給出了自己的配置。

重構(gòu)工作流

選對(duì)模型是基礎(chǔ)，而真正讓作者同時(shí)推進(jìn)8個(gè)項(xiàng)目還不慌的是他這套定制化的工作流。

因?yàn)槊刻鞎?huì)冒出很多新的想法，比如“給Clawdis加個(gè)控制臥室溫度的功能”“寫個(gè)CLI查外賣進(jìn)度”……

但這些想法Peter并不會(huì)記在備忘錄里，而是直接扔進(jìn)Codex的排隊(duì)列表。

比如開發(fā)“YouTube視頻總結(jié)Chrome擴(kuò)展”時(shí)，他一邊讓Codex驗(yàn)證CLI核心邏輯（把視頻轉(zhuǎn)成Markdown），一邊把 “加瀏覽器彈窗提醒”“支持本地存儲(chǔ)” 等想法塞進(jìn)隊(duì)列，Codex會(huì)按優(yōu)先級(jí)慢慢處理，不用他盯著催，也不怕遺忘在備忘錄里。

而且，一個(gè)小tips是堅(jiān)決不回滾！

• “構(gòu)建軟件就像爬山，不用筆直往上走，繞點(diǎn)路、退兩步都正常，關(guān)鍵是別在‘要不要回滾’上浪費(fèi)時(shí)間�！�

遇到相似的功能，不用從頭寫

比如作者之前在VibeTunnel項(xiàng)目里做過 “字符流輸出”，后來開發(fā)Clawdis時(shí)需要類似功能，他直接讓Codex“去../VibeTunnel文件夾里看看，照這個(gè)邏輯給Clawdis加一個(gè)”，10分鐘就適配好了。

甚至搭新項(xiàng)目時(shí)，他也會(huì)讓Codex參考舊項(xiàng)目的結(jié)構(gòu)，比如“按../Sparkle項(xiàng)目的目錄格式，搭一個(gè)新的日志工具”，這時(shí)候模型就能自動(dòng)復(fù)制適配。

人機(jī)分工

當(dāng)然了，寫代碼這件事也不能全靠AI，這時(shí)候就得來個(gè)人機(jī)分工，原則很簡單：AI干執(zhí)行，人做決策

這些事一定要自己做：選哪個(gè)依賴庫、系統(tǒng)架構(gòu)怎么設(shè)計(jì)、功能優(yōu)先級(jí)怎么排……

寫基礎(chǔ)代碼、修復(fù)已知bug、生成GUI界面、更新項(xiàng)目日志，甚至“注冊(cè)域名”“改DNS配置”這種瑣事，都可以交給AI。

作者舉了自己實(shí)戰(zhàn)中的兩個(gè)例子。

在選擇用Go語言做CLI工具前，他花了半天研究“Go的類型系統(tǒng)是不是更適合AI生成代碼”“有沒有常用的Go庫能復(fù)用”，確定之后再讓AI開寫，最后也沒怎么返工。

不過在開發(fā)數(shù)據(jù)可視化工具時(shí)，就直接讓AI花了20分鐘寫核心代碼，再讓它幫忙測(cè)試，也不用自己切設(shè)備操作。

實(shí)用小技巧

除了上面的核心方法，作者還分享了幾個(gè)挺實(shí)用的小操作，都是踩坑總結(jié)出來的。

第一個(gè)是開發(fā)先從CLI開始，再擴(kuò)展功能

不管想做什么項(xiàng)目，先搭個(gè)簡單的CLI工具驗(yàn)證核心邏輯，比如他之前做“YouTube視頻總結(jié)Chrome擴(kuò)展”的時(shí)候，先寫了個(gè)能把視頻轉(zhuǎn)成文字、再用模型總結(jié)成 Markdown的CLI版本。

確認(rèn)能跑通后，才讓AI搭前端、做瀏覽器擴(kuò)展，一天就搞定了。

第二個(gè)是讓文檔幫模型記上下文，不用反復(fù)提需求

在每個(gè)項(xiàng)目里建個(gè)docs文件夾，把“系統(tǒng)設(shè)計(jì)思路”“功能說明”寫進(jìn)去，再用腳本讓AI讀這些文檔。

比如Peter在docs里寫了“Clawdis這個(gè)項(xiàng)目要支持控制家里的燈光”，之后讓AI加新功能時(shí)，不用反復(fù)說“要和燈光控制兼容”，模型就會(huì)自己讀文檔，減少了溝通成本。

第三個(gè)是單人開發(fā)直接提交主分支，不用搞復(fù)雜分支

要是你一個(gè)人開發(fā)，那就不用建“dev分支”“feature分支”，改完直接提交主分支。

Peter表示：

• “分支多了反而容易有合并沖突，Codex有時(shí)候會(huì)自動(dòng)建臨時(shí)工作區(qū)處理混亂代碼，改完合并回主分支，比手動(dòng)管理分支簡單多了。”

Peter說的這些坑你有沒有踩過？

還有啥AI Coding實(shí)用小技巧歡迎分享！

原文地址：https://steipete.me/posts/2025/shipping-at-inference-speed

— 完 —