聞樂 發(fā)自 凹非寺
量子位 | 公眾號 QbitAI
AI Coding火到不用多說，卡帕但怎么用才最高效呢？西推效率
這份連大神卡帕西和OpenAI總裁Greg Brockman都在轉(zhuǎn)發(fā)推薦的Coding Agents指南，用3招教你快速交付。指南招教28加拿大28预测网站
大神們在轉(zhuǎn)，網(wǎng)友也在夸！卡帕
這份實戰(zhàn)指南的作者是Swift開發(fā)出身、深耕AI驅(qū)動開發(fā)領(lǐng)域的指南招教大神Peter Steinberger，他也是翻倍一位AI Coding重度愛好者，已經(jīng)寫了很多份實戰(zhàn)經(jīng)驗博客。卡帕
簡單總結(jié)一下今天的西推效率這篇AI Coding指南：先按任務(wù)類型選對模型，再重構(gòu)工作流提速，指南招教但要捋清人機分工。翻倍
Peter不僅給出了自己的模型配置，最后還有實用小技巧～
三大關(guān)鍵策略
按任務(wù)類型選對模型
大家用AI編碼，西推效率很多時候是指南招教28加拿大28预测网站不是一個模型用到底？
結(jié)果一到大項目就卡殼，小項目修改還慢。問題呢，就出在“沒給模型找對活兒”。
人家這份指南里就說了，第一步就得先按任務(wù)類型給Coding模型分好工。大任務(wù)就用Codex，小任務(wù)Opus更好使
比如，搞幾十頁的工程規(guī)范落地、項目重構(gòu)這種大活兒就直接上Codex，它有個特點，開始寫代碼前會默讀文件，把項目邏輯摸透，雖然比Opus多花點時間，但對復(fù)雜需求的完成度更好。
Peter之前重構(gòu)Opus 4.0的舊代碼，Codex花了幾個小時讀透了整個項目，不僅沒漏關(guān)鍵邏輯，還修復(fù)了2個隱藏Bug。
如果只是小范圍修改這種比較零碎的任務(wù)，那Opus更合適。它不用讀很久的文件，響應(yīng)很快，基本上幾分鐘就能出結(jié)果。
不過，要進階的話，首選GPT-5.2-Codex，直接一步到位。
現(xiàn)在Peter最常用的就是GPT-5.2-Codex，尤其是high模式，不管搭Chrome擴展的前端還是寫Go語言的CLI工具，它都能兼顧速度和準(zhǔn)確率，也不用在Codex和Opus之間來回切換了。
在這里，Peter還給出了自己的配置。
重構(gòu)工作流
選對模型是基礎(chǔ)，而真正讓作者同時推進8個項目還不慌的是他這套定制化的工作流。
因為每天會冒出很多新的想法，比如“給Clawdis加個控制臥室溫度的功能”“寫個CLI查外賣進度”……
但這些想法Peter并不會記在備忘錄里，而是直接扔進Codex的排隊列表。
比如開發(fā)“YouTube視頻總結(jié)Chrome擴展”時，他一邊讓Codex驗證CLI核心邏輯（把視頻轉(zhuǎn)成Markdown），一邊把 “加瀏覽器彈窗提醒”“支持本地存儲” 等想法塞進隊列，Codex會按優(yōu)先級慢慢處理，不用他盯著催，也不怕遺忘在備忘錄里。
而且，一個小tips是堅決不回滾！
- “構(gòu)建軟件就像爬山，不用筆直往上走，繞點路、退兩步都正常，關(guān)鍵是別在‘要不要回滾’上浪費時間。”
遇到相似的功能，不用從頭寫
比如作者之前在VibeTunnel項目里做過 “字符流輸出”，后來開發(fā)Clawdis時需要類似功能，他直接讓Codex“去../VibeTunnel文件夾里看看，照這個邏輯給Clawdis加一個”，10分鐘就適配好了。
甚至搭新項目時，他也會讓Codex參考舊項目的結(jié)構(gòu)，比如“按../Sparkle項目的目錄格式，搭一個新的日志工具”，這時候模型就能自動復(fù)制適配。
人機分工
當(dāng)然了，寫代碼這件事也不能全靠AI，這時候就得來個人機分工，原則很簡單：AI干執(zhí)行，人做決策
這些事一定要自己做：選哪個依賴庫、系統(tǒng)架構(gòu)怎么設(shè)計、功能優(yōu)先級怎么排……
寫基礎(chǔ)代碼、修復(fù)已知bug、生成GUI界面、更新項目日志，甚至“注冊域名”“改DNS配置”這種瑣事，都可以交給AI。
作者舉了自己實戰(zhàn)中的兩個例子。
在選擇用Go語言做CLI工具前，他花了半天研究“Go的類型系統(tǒng)是不是更適合AI生成代碼”“有沒有常用的Go庫能復(fù)用”，確定之后再讓AI開寫，最后也沒怎么返工。
不過在開發(fā)數(shù)據(jù)可視化工具時，就直接讓AI花了20分鐘寫核心代碼，再讓它幫忙測試，也不用自己切設(shè)備操作。
實用小技巧
除了上面的核心方法，作者還分享了幾個挺實用的小操作，都是踩坑總結(jié)出來的。
第一個是開發(fā)先從CLI開始，再擴展功能
不管想做什么項目，先搭個簡單的CLI工具驗證核心邏輯，比如他之前做“YouTube視頻總結(jié)Chrome擴展”的時候，先寫了個能把視頻轉(zhuǎn)成文字、再用模型總結(jié)成 Markdown的CLI版本。
確認(rèn)能跑通后，才讓AI搭前端、做瀏覽器擴展，一天就搞定了。
第二個是讓文檔幫模型記上下文，不用反復(fù)提需求
在每個項目里建個docs文件夾，把“系統(tǒng)設(shè)計思路”“功能說明”寫進去，再用腳本讓AI讀這些文檔。
比如Peter在docs里寫了“Clawdis這個項目要支持控制家里的燈光”，之后讓AI加新功能時，不用反復(fù)說“要和燈光控制兼容”，模型就會自己讀文檔，減少了溝通成本。
第三個是單人開發(fā)直接提交主分支，不用搞復(fù)雜分支
要是你一個人開發(fā)，那就不用建“dev分支”“feature分支”，改完直接提交主分支。
Peter表示：
- “分支多了反而容易有合并沖突，Codex有時候會自動建臨時工作區(qū)處理混亂代碼，改完合并回主分支，比手動管理分支簡單多了。”
Peter說的這些坑你有沒有踩過？
還有啥AI Coding實用小技巧歡迎分享！
原文地址：https://steipete.me/posts/2025/shipping-at-inference-speed
— 完 —
