工程實(shí)戰(zhàn)：用Claude Code與Codex實(shí)現(xiàn)AI輔助編程的迭代重構(gòu))
1. 循環(huán)工程到底是什么從概念到落地場(chǎng)景1.1 一個(gè)被名字耽誤的實(shí)用方法論第一次看到“Loop Engineering”這個(gè)詞很多人會(huì)以為是某種硬件層面的循環(huán)控制技術(shù)或者跟嵌入式開發(fā)里的主循環(huán)、事件循環(huán)有關(guān)。實(shí)際上在AI輔助編程的語境下它指的是一套圍繞迭代循環(huán)構(gòu)建的工程化工作方法——把“寫代碼”這件事拆成若干個(gè)可重復(fù)、可驗(yàn)證、可回滾的小循環(huán)每個(gè)循環(huán)里都有明確的輸入、動(dòng)作和驗(yàn)收標(biāo)準(zhǔn)。我最初接觸這個(gè)概念是在用Claude Code做重構(gòu)的時(shí)候。當(dāng)時(shí)面對(duì)一個(gè)兩千多行的老模塊直接讓AI“幫我重構(gòu)一下”結(jié)果它一口氣改了十幾個(gè)文件跑起來一堆報(bào)錯(cuò)我連它改了哪里都理不清。后來換了個(gè)思路把重構(gòu)拆成“讀一個(gè)函數(shù)→改一個(gè)函數(shù)→跑一次測(cè)試→確認(rèn)無誤→進(jìn)入下一個(gè)”的循環(huán)每次只動(dòng)一小塊出問題立刻能定位。這就是循環(huán)工程最樸素的樣子。它解決的核心問題是AI編程工具能力很強(qiáng)但“一次性大改”的失敗成本極高。循環(huán)工程通過控制每次迭代的范圍把不可控的大風(fēng)險(xiǎn)拆解成可控的小風(fēng)險(xiǎn)。適合所有正在用Claude Code、Codex、Cursor這類工具做實(shí)際項(xiàng)目的人尤其是接手遺留代碼、做大規(guī)模重構(gòu)、或者需要保證線上穩(wěn)定性的場(chǎng)景。1.2 為什么現(xiàn)在特別值得關(guān)注過去一年AI編程工具從“補(bǔ)全單行代碼”進(jìn)化到了“理解整個(gè)項(xiàng)目并執(zhí)行多步操作”。Claude Code能直接讀寫文件、執(zhí)行終端命令Codex能根據(jù)自然語言描述生成完整函數(shù)Cursor能跨文件做重構(gòu)。能力越強(qiáng)越需要一套方法來約束它——否則就像給一個(gè)大力士一把沒有刻度的扳手力氣越大越容易擰壞螺絲。循環(huán)工程的價(jià)值在于它提供了一套與工具能力匹配的操作紀(jì)律。不是限制工具而是讓工具的輸出變得可預(yù)期、可驗(yàn)證。我實(shí)測(cè)下來同樣的重構(gòu)任務(wù)用循環(huán)工程的方式做返工率能降低六成以上而且整個(gè)過程心里有底不會(huì)出現(xiàn)“改到一半不知道自己在哪”的情況。1.3 核心循環(huán)的四個(gè)階段一個(gè)完整的工程循環(huán)包含四個(gè)階段我把它簡(jiǎn)稱為RIVA循環(huán)Read讀取讓AI讀取當(dāng)前要處理的最小單元比如一個(gè)函數(shù)、一個(gè)類、一個(gè)配置文件。關(guān)鍵是限定范圍不要讓它讀整個(gè)項(xiàng)目。Intent意圖用一句話說清楚這次循環(huán)要達(dá)成什么目標(biāo)比如“把這個(gè)函數(shù)的同步IO改成異步”“給這個(gè)類加上參數(shù)校驗(yàn)”。Verify驗(yàn)證改完之后立刻跑測(cè)試、跑lint、或者手動(dòng)觸發(fā)一次調(diào)用確認(rèn)行為符合預(yù)期。Advance推進(jìn)確認(rèn)無誤后把這個(gè)改動(dòng)提交或暫存然后進(jìn)入下一個(gè)最小單元。這四個(gè)階段看起來簡(jiǎn)單但每個(gè)階段都有講究。比如Read階段如果范圍劃大了AI會(huì)引入無關(guān)改動(dòng)Intent如果寫得模糊AI會(huì)自由發(fā)揮Verify如果跳過問題會(huì)累積到后面才爆發(fā)。后面我會(huì)逐個(gè)拆解每個(gè)階段的實(shí)操細(xì)節(jié)。2. 工具鏈選型Claude Code、Codex、Cursor怎么配2.1 三個(gè)工具在循環(huán)中的角色分工很多人糾結(jié)“到底用哪個(gè)工具”我的經(jīng)驗(yàn)是不要二選一而是讓它們各司其職。在循環(huán)工程的框架下三個(gè)工具對(duì)應(yīng)不同的循環(huán)環(huán)節(jié)工具最適合的環(huán)節(jié)核心優(yōu)勢(shì)典型用法Claude CodeRead Intent能直接讀文件、執(zhí)行命令上下文理解強(qiáng)讀取模塊、分析依賴、執(zhí)行重構(gòu)CodexIntent 生成函數(shù)級(jí)生成質(zhì)量高補(bǔ)全邏輯嚴(yán)謹(jǐn)生成新函數(shù)、補(bǔ)全測(cè)試用例CursorVerify 編輯編輯器內(nèi)聯(lián)操作流暢diff直觀審查改動(dòng)、微調(diào)、跑測(cè)試這個(gè)分工不是絕對(duì)的但遵循一個(gè)原則讀取和分析用Claude Code生成和補(bǔ)全用Codex審查和微調(diào)用Cursor。這樣每個(gè)工具都在自己最擅長(zhǎng)的環(huán)節(jié)工作循環(huán)效率最高。2.2 Claude Code的安裝與基礎(chǔ)配置Claude Code目前有桌面版和命令行版兩種形態(tài)。命令行版更適合循環(huán)工程因?yàn)樗苤苯忧度虢K端工作流。安裝方式根據(jù)系統(tǒng)不同有所差異核心是確保Node環(huán)境就緒然后通過包管理器安裝。安裝完成后第一件事是配置項(xiàng)目級(jí)的權(quán)限文件。默認(rèn)情況下Claude Code每次讀寫文件都會(huì)詢問這在循環(huán)中會(huì)打斷節(jié)奏?？梢栽陧?xiàng)目根目錄創(chuàng)建一個(gè)配置文件聲明哪些目錄允許自動(dòng)讀寫{ permissions: { allow: [ Read(src/**), Write(src/**), Bash(npm test), Bash(npm run lint) ], deny: [ Read(.env), Write(package-lock.json) ] } }這個(gè)配置的意圖很明確允許它在src目錄下自由讀寫允許跑測(cè)試和lint但禁止碰環(huán)境變量文件和鎖文件。鎖文件一定要禁寫否則AI一次依賴安裝就可能把整個(gè)lock文件重寫導(dǎo)致依賴版本漂移。注意權(quán)限配置是循環(huán)工程的安全帶。寧可多花五分鐘配好也不要讓AI在無約束狀態(tài)下操作項(xiàng)目。2.3 Codex的接入與模型選擇Codex在國(guó)內(nèi)的使用體驗(yàn)取決于接入方式。目前常見的做法是通過API接入模型選擇上建議用推理能力強(qiáng)的版本處理復(fù)雜邏輯用輕量版本處理簡(jiǎn)單補(bǔ)全。配置文件通常放在用戶目錄下核心字段包括模型名稱、API端點(diǎn)、超時(shí)時(shí)間。一個(gè)容易踩的坑是超時(shí)設(shè)置。循環(huán)工程中經(jīng)常需要AI讀取較大文件或生成較長(zhǎng)函數(shù)默認(rèn)超時(shí)往往不夠。建議把超時(shí)調(diào)到60秒以上同時(shí)開啟流式輸出這樣即使生成時(shí)間長(zhǎng)也能看到進(jìn)度不會(huì)以為卡死了。另一個(gè)關(guān)鍵是上下文窗口管理。Codex每次請(qǐng)求攜帶的上下文有限如果讓它在循環(huán)中反復(fù)讀取整個(gè)項(xiàng)目很快就會(huì)超出窗口。正確做法是每次只傳當(dāng)前循環(huán)需要的最小上下文——比如只傳目標(biāo)函數(shù)和它的直接依賴而不是整個(gè)文件。2.4 Cursor的中文環(huán)境與效率設(shè)置Cursor的默認(rèn)界面是英文的對(duì)中文用戶來說設(shè)置中文回復(fù)能顯著提升閱讀效率。在設(shè)置里找到語言選項(xiàng)把界面語言和AI回復(fù)語言都切成中文。注意這兩個(gè)是分開的界面語言影響菜單回復(fù)語言影響AI輸出的內(nèi)容。注冊(cè)環(huán)節(jié)Cursor支持多種方式國(guó)內(nèi)用戶用郵箱注冊(cè)即可不需要糾結(jié)手機(jī)號(hào)的問題。免費(fèi)額度方面新賬號(hào)有一定量的快速請(qǐng)求次數(shù)超出后會(huì)降速但不會(huì)斷供對(duì)于循環(huán)工程這種“小步快跑”的用法額度消耗其實(shí)比想象中慢——因?yàn)槊看窝h(huán)的請(qǐng)求都很小。Cursor還有一個(gè)對(duì)循環(huán)工程特別有用的功能內(nèi)聯(lián)diff審查。每次AI改動(dòng)后它會(huì)用高亮標(biāo)出增刪行你可以逐行確認(rèn)。我習(xí)慣在Verify階段用這個(gè)功能快速掃一遍確認(rèn)沒有意外改動(dòng)后再跑測(cè)試。2.5 工具之間的切換與協(xié)同三個(gè)工具同時(shí)用最大的問題是上下文同步。我的做法是用項(xiàng)目文件本身作為共享上下文。Claude Code讀取并分析后把結(jié)論寫到一個(gè)臨時(shí)筆記文件里Codex生成代碼時(shí)把筆記文件作為上下文傳入Cursor審查時(shí)直接看代碼diff。這樣工具之間不需要直接通信通過文件系統(tǒng)間接同步。另一個(gè)技巧是統(tǒng)一快捷鍵。三個(gè)工具默認(rèn)的快捷鍵不同容易按錯(cuò)。我把它們的“執(zhí)行當(dāng)前操作”都映射到同一個(gè)組合鍵上形成肌肉記憶后循環(huán)的節(jié)奏感會(huì)強(qiáng)很多。3. 循環(huán)工程的核心操作流程3.1 循環(huán)單元的劃分原則循環(huán)工程最關(guān)鍵的一步是劃分循環(huán)單元。單元太大一次改太多容易失控單元太小循環(huán)次數(shù)過多效率低。我的經(jīng)驗(yàn)法則是一個(gè)循環(huán)單元對(duì)應(yīng)一個(gè)可獨(dú)立測(cè)試的行為。具體來說如果改一個(gè)函數(shù)這個(gè)函數(shù)有對(duì)應(yīng)的單元測(cè)試那它就是一個(gè)循環(huán)單元。如果改一個(gè)類類的方法之間有耦合那就把類拆成幾個(gè)循環(huán)先改構(gòu)造函數(shù)和初始化邏輯跑一次測(cè)試再改核心方法再跑一次最后改輔助方法。每次只動(dòng)一個(gè)方法測(cè)試通過后再動(dòng)下一個(gè)。對(duì)于前端組件循環(huán)單元可以是一個(gè)組件的渲染邏輯、一個(gè)事件處理函數(shù)、或者一個(gè)樣式塊。對(duì)于配置文件循環(huán)單元可以是一個(gè)配置項(xiàng)。核心判斷標(biāo)準(zhǔn)是改完之后我能不能用一條命令驗(yàn)證它是對(duì)的。如果不能說明單元?jiǎng)澊罅恕?.2 Read階段如何讓AI精準(zhǔn)理解上下文Read階段的目標(biāo)是讓AI理解當(dāng)前循環(huán)單元而不是整個(gè)項(xiàng)目。很多人習(xí)慣說“讀一下這個(gè)項(xiàng)目”這是循環(huán)工程的大忌。正確做法是明確指定文件路徑和行號(hào)范圍。比如要改一個(gè)函數(shù)可以這樣下指令讀取 src/services/userService.js 中 getUserById 函數(shù)大約在第45行到第80行 以及它調(diào)用的 validateUserId 函數(shù)在 src/utils/validators.js 第12行到第25行。 不要讀取其他文件。這樣AI的上下文里只有兩個(gè)函數(shù)分析精度高而且不會(huì)因?yàn)樽x了無關(guān)文件而產(chǎn)生“順手改一下”的沖動(dòng)。如果項(xiàng)目結(jié)構(gòu)復(fù)雜AI可能找不到文件。這時(shí)候可以用Claude Code的搜索能力先讓它定位在 src 目錄下搜索所有包含 getUserById 的文件列出文件路徑和行號(hào)。定位到之后再執(zhí)行精確讀取。這個(gè)“先搜索后讀取”的兩步法比直接讓AI猜文件位置可靠得多。3.3 Intent階段把需求寫成可執(zhí)行的指令I(lǐng)ntent階段是把“我想干什么”翻譯成AI能精確執(zhí)行的指令。模糊的意圖會(huì)導(dǎo)致AI自由發(fā)揮而自由發(fā)揮在循環(huán)工程中是不可接受的。對(duì)比一下模糊意圖“優(yōu)化這個(gè)函數(shù)”精確意圖“把這個(gè)函數(shù)里的同步文件讀取改成異步使用fs.promises保持函數(shù)簽名不變錯(cuò)誤處理邏輯不變”精確意圖包含三個(gè)要素改什么、改成什么、什么不變。第三個(gè)要素經(jīng)常被忽略但它極其重要——它告訴AI哪些東西不能碰避免它在改A的時(shí)候順手把B也改了。我習(xí)慣在Intent里加一句“只修改這個(gè)函數(shù)不要改動(dòng)其他任何代碼”。這句話看起來多余但實(shí)測(cè)能顯著減少意外改動(dòng)。AI有時(shí)候會(huì)“好心”幫你優(yōu)化相鄰的代碼在循環(huán)工程里這是災(zāi)難。3.4 Verify階段驗(yàn)證手段的層次化設(shè)計(jì)Verify階段是循環(huán)工程的質(zhì)量閘門。驗(yàn)證手段分三個(gè)層次按成本從低到高排列靜態(tài)檢查跑lint、跑類型檢查。成本最低幾秒鐘出結(jié)果能抓住語法錯(cuò)誤和類型不匹配。單元測(cè)試跑當(dāng)前循環(huán)單元對(duì)應(yīng)的測(cè)試。成本中等幾十秒到幾分鐘能抓住邏輯錯(cuò)誤。集成驗(yàn)證手動(dòng)觸發(fā)一次真實(shí)調(diào)用或者跑端到端測(cè)試。成本最高但能抓住單元測(cè)試覆蓋不到的問題。我的做法是每次循環(huán)至少跑靜態(tài)檢查涉及邏輯改動(dòng)必須跑單元測(cè)試涉及接口改動(dòng)必須做集成驗(yàn)證。三個(gè)層次不必每次都全跑但靜態(tài)檢查是底線不能省。如果項(xiàng)目沒有單元測(cè)試怎么辦那就手動(dòng)構(gòu)造一個(gè)最小驗(yàn)證場(chǎng)景。比如改了一個(gè)工具函數(shù)可以在終端里用node直接調(diào)用它傳幾個(gè)典型參數(shù)看輸出。這個(gè)手動(dòng)驗(yàn)證的過程其實(shí)就是在補(bǔ)測(cè)試債。3.5 Advance階段提交策略與回滾準(zhǔn)備Advance階段是把驗(yàn)證通過的改動(dòng)固化下來。這里的關(guān)鍵是提交粒度。一個(gè)循環(huán)單元對(duì)應(yīng)一個(gè)提交提交信息寫清楚這次循環(huán)做了什么。這樣如果后面發(fā)現(xiàn)問題可以精確回滾到某個(gè)循環(huán)之前的狀態(tài)。我習(xí)慣用git的暫存功能每次循環(huán)驗(yàn)證通過后git add當(dāng)前改動(dòng)的文件但不急著commit。等積累了三到五個(gè)循環(huán)后再一起commitcommit信息里列出這幾個(gè)循環(huán)的內(nèi)容。這樣既保持了細(xì)粒度又不會(huì)讓提交歷史過于碎片化?；貪L準(zhǔn)備方面除了git我還會(huì)在循環(huán)開始前把當(dāng)前文件復(fù)制一份到臨時(shí)目錄。雖然git能回滾但有時(shí)候改動(dòng)還沒提交git回滾不了。有個(gè)物理備份心里更踏實(shí)。4. 項(xiàng)目實(shí)戰(zhàn)用循環(huán)工程重構(gòu)一個(gè)真實(shí)模塊4.1 項(xiàng)目背景與重構(gòu)目標(biāo)我拿一個(gè)真實(shí)的Node.js項(xiàng)目練手。這個(gè)項(xiàng)目有一個(gè)orderService.js里面有一個(gè)processOrder函數(shù)大約300行負(fù)責(zé)訂單處理的全流程校驗(yàn)參數(shù)、查庫(kù)存、算價(jià)格、寫數(shù)據(jù)庫(kù)、發(fā)通知。問題是這個(gè)函數(shù)太長(zhǎng)了邏輯耦合嚴(yán)重改一處容易影響另一處。重構(gòu)目標(biāo)是把它拆成五個(gè)獨(dú)立的函數(shù)validateOrder、checkStock、calculatePrice、saveOrder、sendNotification每個(gè)函數(shù)職責(zé)單一可以獨(dú)立測(cè)試。整個(gè)重構(gòu)過程用循環(huán)工程的方式推進(jìn)。4.2 第一個(gè)循環(huán)拆出參數(shù)校驗(yàn)第一個(gè)循環(huán)單元是validateOrder。Read階段讓Claude Code讀取processOrder函數(shù)的前50行以及項(xiàng)目里已有的校驗(yàn)工具函數(shù)。Intent階段指令是從 processOrder 函數(shù)中提取參數(shù)校驗(yàn)邏輯創(chuàng)建一個(gè)新的 validateOrder 函數(shù)。 新函數(shù)接收 order 對(duì)象返回 { valid: boolean, errors: string[] }。 保持原有的校驗(yàn)規(guī)則完全不變不要添加新的校驗(yàn)。 只創(chuàng)建新函數(shù)不要修改 processOrder 的其他部分。AI生成后Verify階段跑lint和已有的訂單測(cè)試。測(cè)試通過說明校驗(yàn)邏輯沒有破壞。Advance階段把新函數(shù)和原函數(shù)的調(diào)用點(diǎn)一起暫存。這個(gè)循環(huán)花了大約十分鐘。如果不用循環(huán)工程直接讓AI重構(gòu)整個(gè)函數(shù)很可能一次改出十幾個(gè)問題排查時(shí)間遠(yuǎn)超十分鐘。4.3 第二個(gè)循環(huán)庫(kù)存檢查的異步改造第二個(gè)循環(huán)單元是checkStock。這個(gè)邏輯原本是同步的但庫(kù)存查詢實(shí)際上要走網(wǎng)絡(luò)請(qǐng)求同步寫法會(huì)阻塞。Intent階段指令從 processOrder 中提取庫(kù)存檢查邏輯創(chuàng)建 checkStock 函數(shù)。 將同步的庫(kù)存查詢改為異步使用 async/await。 函數(shù)簽名async function checkStock(order) 返回 { available: boolean, shortage: number }。 錯(cuò)誤處理保持原有邏輯網(wǎng)絡(luò)異常時(shí)拋出同樣的錯(cuò)誤類型。這里有個(gè)細(xì)節(jié)AI一開始把錯(cuò)誤處理改成了返回{ available: false }而不是拋異常。這改變了原有行為。我在Verify階段跑測(cè)試時(shí)發(fā)現(xiàn)了因?yàn)橛幸粋€(gè)測(cè)試用例專門驗(yàn)證網(wǎng)絡(luò)異常時(shí)的錯(cuò)誤類型。于是回退在Intent里補(bǔ)充“網(wǎng)絡(luò)異常時(shí)必須拋出StockServiceError不要吞掉異?！?。重新生成后通過。這個(gè)循環(huán)暴露了一個(gè)重要經(jīng)驗(yàn)AI傾向于“優(yōu)化”錯(cuò)誤處理把異常改成返回值。在循環(huán)工程中這種行為必須被約束因?yàn)殄e(cuò)誤處理方式的改變會(huì)影響調(diào)用方。4.4 第三個(gè)循環(huán)價(jià)格計(jì)算的純函數(shù)化第三個(gè)循環(huán)單元是calculatePrice。這個(gè)邏輯原本依賴外部的this上下文和幾個(gè)實(shí)例變量。Intent階段指令提取價(jià)格計(jì)算邏輯創(chuàng)建純函數(shù) calculatePrice。 所有依賴的外部變量改為通過參數(shù)傳入。 函數(shù)簽名calculatePrice(order, pricingRules, userLevel) 返回 number。 計(jì)算邏輯和精度保持完全一致不要改變舍入方式。純函數(shù)化的好處是可測(cè)試性大幅提升。Verify階段我寫了一個(gè)快速測(cè)試腳本傳入幾組典型參數(shù)對(duì)比新舊函數(shù)的輸出。全部一致后通過。這個(gè)循環(huán)的坑在于浮點(diǎn)數(shù)精度。AI在重構(gòu)時(shí)把原來的toFixed(2)改成了Math.round導(dǎo)致某些邊界值結(jié)果不同。測(cè)試腳本抓到了這個(gè)差異。教訓(xùn)是涉及數(shù)值計(jì)算的重構(gòu)Verify階段必須做新舊對(duì)比不能只跑原有測(cè)試。4.5 第四、五個(gè)循環(huán)數(shù)據(jù)庫(kù)寫入與通知解耦第四和第五個(gè)循環(huán)相對(duì)簡(jiǎn)單因?yàn)榍叭齻€(gè)循環(huán)已經(jīng)把主要邏輯拆出去了。saveOrder循環(huán)主要是把數(shù)據(jù)庫(kù)操作提取出來加上事務(wù)邊界。sendNotification循環(huán)是把通知邏輯改成事件驅(qū)動(dòng)通過EventEmitter解耦。這兩個(gè)循環(huán)各花了五到八分鐘主要時(shí)間花在Verify階段的集成測(cè)試上。因?yàn)樯婕皵?shù)據(jù)庫(kù)和外部通知需要啟動(dòng)測(cè)試環(huán)境。但因?yàn)橛星叭齻€(gè)循環(huán)打下的基礎(chǔ)改動(dòng)范圍很小問題定位很快。五個(gè)循環(huán)做完processOrder從300行變成了一個(gè)20行的編排函數(shù)依次調(diào)用五個(gè)子函數(shù)。整個(gè)重構(gòu)過程大約兩小時(shí)中間沒有出現(xiàn)“改崩了要回滾整個(gè)重構(gòu)”的情況。4.6 循環(huán)工程的效率對(duì)比為了量化效果我做了個(gè)對(duì)比同樣的重構(gòu)任務(wù)用傳統(tǒng)“一次性大改”的方式做了一次用循環(huán)工程做了一次。指標(biāo)一次性大改循環(huán)工程總耗時(shí)1.5小時(shí)2小時(shí)返工次數(shù)4次1次返工耗時(shí)約1小時(shí)約10分鐘最終bug數(shù)3個(gè)0個(gè)心理負(fù)擔(dān)高全程焦慮低每步可控一次性大改看起來總耗時(shí)短但返工耗時(shí)加起來反而更長(zhǎng)而且最終還有bug。循環(huán)工程雖然單次循環(huán)看起來慢但總耗時(shí)可控質(zhì)量更高。更重要的是循環(huán)工程的過程中你知道自己在哪一步出了問題能立刻定位這種確定性是傳統(tǒng)方式給不了的。5. 常見問題與排查技巧實(shí)錄5.1 AI不按指令改總是“順手優(yōu)化”這是最高頻的問題。AI看到一段代碼即使你只讓它改一個(gè)函數(shù)它也會(huì)“好心”把相鄰的代碼一起優(yōu)化了。排查思路先檢查Intent指令是否足夠明確有沒有加“只修改這個(gè)函數(shù)不要改動(dòng)其他任何代碼”這句話。如果加了還出現(xiàn)就在Verify階段用diff工具逐行審查發(fā)現(xiàn)意外改動(dòng)立刻回退并在下一輪Intent里把“不要改XX”寫得更具體。我的經(jīng)驗(yàn)是Claude Code比Codex更容易“順手優(yōu)化”因?yàn)樗纳舷挛睦斫飧鼜?qiáng)更容易產(chǎn)生“整體優(yōu)化”的沖動(dòng)。用Claude Code做Read和Intent時(shí)要特別強(qiáng)調(diào)范圍限制。5.2 循環(huán)次數(shù)太多感覺效率低循環(huán)單元?jiǎng)澋锰?xì)會(huì)導(dǎo)致循環(huán)次數(shù)過多。判斷標(biāo)準(zhǔn)是如果一個(gè)循環(huán)單元改完之后你花在Verify上的時(shí)間比改代碼的時(shí)間還長(zhǎng)說明單元?jiǎng)澬×?。這時(shí)候應(yīng)該把相鄰的幾個(gè)小單元合并成一個(gè)稍大的單元。另一個(gè)原因是Verify手段太重。如果每次循環(huán)都跑完整的集成測(cè)試那確實(shí)慢。應(yīng)該分層驗(yàn)證小改動(dòng)只跑lint和單元測(cè)試涉及接口的才跑集成測(cè)試。5.3 測(cè)試環(huán)境啟動(dòng)慢拖累Verify這是基礎(chǔ)設(shè)施問題不是循環(huán)工程本身的問題。解決辦法是讓測(cè)試環(huán)境常駐不要每次循環(huán)都重啟。比如數(shù)據(jù)庫(kù)用Docker容器常駐測(cè)試數(shù)據(jù)用fixture預(yù)置測(cè)試用例之間做好隔離。這樣Verify階段只需要跑測(cè)試命令不需要等環(huán)境啟動(dòng)。如果環(huán)境實(shí)在啟動(dòng)慢可以在循環(huán)中先用mock驗(yàn)證邏輯等積累幾個(gè)循環(huán)后再做一次真實(shí)環(huán)境的集成驗(yàn)證。但mock驗(yàn)證不能完全替代真實(shí)驗(yàn)證最終還是要跑一次真的。5.4 AI生成的代碼風(fēng)格與項(xiàng)目不一致這個(gè)問題在多人協(xié)作的項(xiàng)目中特別明顯。解決辦法是在項(xiàng)目根目錄放一個(gè)代碼風(fēng)格說明文件比如.editorconfig或者一個(gè)簡(jiǎn)短的STYLE.md在Intent階段讓AI先讀這個(gè)文件。Claude Code和Cursor都能讀取項(xiàng)目配置文件并遵循。另一個(gè)技巧是在Intent里附上一個(gè)“參考實(shí)現(xiàn)”的路徑讓AI模仿那個(gè)文件的風(fēng)格。比如“參考src/services/otherService.js的代碼風(fēng)格”。這比抽象的風(fēng)格描述有效得多。5.5 循環(huán)過程中發(fā)現(xiàn)前面的循環(huán)有問題這是正常情況循環(huán)工程不要求一次做對(duì)。發(fā)現(xiàn)前面循環(huán)有問題時(shí)不要在當(dāng)前循環(huán)里順手修而是回退到那個(gè)循環(huán)單獨(dú)修完再繼續(xù)。比如第三個(gè)循環(huán)發(fā)現(xiàn)第一個(gè)循環(huán)的validateOrder少了一個(gè)校驗(yàn)規(guī)則應(yīng)該先回退到第一個(gè)循環(huán)的狀態(tài)補(bǔ)上校驗(yàn)驗(yàn)證通過然后再重新推進(jìn)到第三個(gè)循環(huán)。這樣做看起來麻煩但能保證每個(gè)循環(huán)的狀態(tài)都是干凈的。如果在前面的問題沒修的情況下繼續(xù)推進(jìn)問題會(huì)累積到最后排查成本更高。5.6 常見問題速查表問題現(xiàn)象可能原因排查動(dòng)作預(yù)防措施AI改動(dòng)范圍超出預(yù)期Intent范圍描述不清檢查diff回退意外改動(dòng)Intent加“只改XX”約束循環(huán)效率低單元?jiǎng)澨』蝌?yàn)證太重合并小單元分層驗(yàn)證按可測(cè)試行為劃分單元測(cè)試跑得慢環(huán)境未常駐檢查環(huán)境啟動(dòng)方式用容器常駐測(cè)試環(huán)境代碼風(fēng)格不一致未提供風(fēng)格參考檢查項(xiàng)目配置文件Intent中附參考文件路徑前面循環(huán)有問題驗(yàn)證不充分回退到問題循環(huán)單獨(dú)修每個(gè)循環(huán)嚴(yán)格VerifyAI吞掉異常AI傾向“優(yōu)化”錯(cuò)誤處理檢查錯(cuò)誤處理邏輯Intent明確錯(cuò)誤處理方式6. 進(jìn)階技巧讓循環(huán)工程更順手的幾個(gè)習(xí)慣6.1 維護(hù)一個(gè)循環(huán)日志每次循環(huán)開始前在臨時(shí)文件里記一行循環(huán)編號(hào)、目標(biāo)、涉及文件。循環(huán)結(jié)束后記一行結(jié)果、耗時(shí)、遇到的問題。這個(gè)日志不需要很正式就是給自己看的。積累十幾個(gè)循環(huán)后回看日志能發(fā)現(xiàn)自己的模式——比如哪類改動(dòng)容易出問題哪類驗(yàn)證手段最有效。我用的是一個(gè)簡(jiǎn)單的Markdown文件放在項(xiàng)目根目錄的.loop-log.md加在.gitignore里不提交。格式大概是## Loop 3 - 2024-XX-XX 目標(biāo)提取 calculatePrice 為純函數(shù) 文件src/services/orderService.js 結(jié)果通過耗時(shí)8分鐘 問題AI把toFixed改成了Math.round測(cè)試抓到6.2 為循環(huán)工程準(zhǔn)備專用測(cè)試腳本項(xiàng)目原有的測(cè)試套件可能很重跑一次要幾分鐘。循環(huán)工程需要的是快速反饋所以值得為常用循環(huán)單元寫一些輕量測(cè)試腳本。比如針對(duì)工具函數(shù)的測(cè)試可以直接用node運(yùn)行不需要啟動(dòng)整個(gè)測(cè)試框架。這些腳本放在scripts/loop-tests/目錄下按循環(huán)單元命名。每次循環(huán)的Verify階段先跑這些輕量腳本通過了再跑正式測(cè)試。這樣大部分問題在輕量腳本階段就被抓住了不用等正式測(cè)試。6.3 用git worktree做并行循環(huán)如果項(xiàng)目比較大可以同時(shí)開多個(gè)循環(huán)每個(gè)循環(huán)在一個(gè)獨(dú)立的git worktree里進(jìn)行。這樣循環(huán)之間互不干擾一個(gè)循環(huán)在Verify時(shí)另一個(gè)循環(huán)可以繼續(xù)改。等所有循環(huán)都驗(yàn)證通過后再合并回主分支。這個(gè)技巧適合大型重構(gòu)但要注意合并沖突。如果兩個(gè)循環(huán)改了同一個(gè)文件的不同部分合并時(shí)可能沖突。所以并行循環(huán)的前提是循環(huán)單元之間文件不重疊。6.4 定期回顧循環(huán)質(zhì)量每做完一個(gè)較大的任務(wù)花十分鐘回顧一下哪些循環(huán)一次通過哪些循環(huán)返工了返工的原因是什么。如果發(fā)現(xiàn)某類循環(huán)總是返工說明這類循環(huán)的Intent模板或者Verify手段需要調(diào)整。比如我發(fā)現(xiàn)自己早期做“異步改造”類循環(huán)時(shí)總是返工原因是Intent里沒有明確錯(cuò)誤處理方式。后來在模板里固定加上“錯(cuò)誤處理保持原有邏輯異常類型不變”返工率就降下來了。6.5 把循環(huán)工程用在非編程場(chǎng)景循環(huán)工程的思路其實(shí)不限于編程。寫文檔、做設(shè)計(jì)、甚至整理數(shù)據(jù)都可以用同樣的方法把大任務(wù)拆成小循環(huán)每個(gè)循環(huán)有明確的輸入、動(dòng)作、驗(yàn)證。比如寫一篇長(zhǎng)文可以按章節(jié)循環(huán)讀參考資料→寫這一節(jié)→檢查邏輯和事實(shí)→確認(rèn)后進(jìn)入下一節(jié)。這樣比一次性寫完再改要高效得多。我在寫技術(shù)方案文檔時(shí)就用這個(gè)方法。每個(gè)循環(huán)寫一個(gè)小節(jié)寫完立刻讓AI檢查事實(shí)錯(cuò)誤和邏輯漏洞確認(rèn)后繼續(xù)。最后整篇文檔的返工率比一次性寫完低很多。6.6 循環(huán)工程的邊界循環(huán)工程不是萬能的。對(duì)于探索性任務(wù)——比如“我不知道這個(gè)功能該怎么實(shí)現(xiàn)先試試看”——循環(huán)工程反而會(huì)限制思路。這種情況下應(yīng)該先做一次自由探索找到方向后再用循環(huán)工程來落地。另外對(duì)于非常小的改動(dòng)——比如改一個(gè)變量名、修一個(gè)拼寫錯(cuò)誤——循環(huán)工程的開銷大于收益。直接改就行不需要走完整循環(huán)。判斷標(biāo)準(zhǔn)是如果改動(dòng)的影響范圍你完全清楚而且驗(yàn)證成本極低就不需要循環(huán)。我個(gè)人的習(xí)慣是改動(dòng)涉及三個(gè)以上文件或者涉及核心邏輯就走循環(huán)工程否則直接改。這個(gè)閾值可以根據(jù)項(xiàng)目情況調(diào)整。6.7 一個(gè)容易被忽略的細(xì)節(jié)循環(huán)之間的休息連續(xù)做五六個(gè)循環(huán)后注意力會(huì)下降Verify階段容易走神。我的做法是每做完三個(gè)循環(huán)強(qiáng)制休息五分鐘站起來走走回來再繼續(xù)。這五分鐘的投入能避免因?yàn)槠趯?dǎo)致的驗(yàn)證疏漏很劃算。循環(huán)工程的本質(zhì)是用紀(jì)律換確定性。它不會(huì)讓單次操作變快但會(huì)讓整個(gè)任務(wù)的總耗時(shí)和總風(fēng)險(xiǎn)大幅下降。對(duì)于需要保證質(zhì)量的工程任務(wù)這個(gè)交換是值得的。 循環(huán)工程實(shí)戰(zhàn)：用Claude Code與Codex實(shí)現(xiàn)AI輔助編程的迭代重構(gòu)
1. 循環(huán)工程到底是什么從概念到落地場(chǎng)景1.1 一個(gè)被名字耽誤的實(shí)用方法論第一次看到“Loop Engineering”這個(gè)詞很多人會(huì)以為是某種硬件層面的循環(huán)控制技術(shù)或者跟嵌入式開發(fā)里的主循環(huán)、事件循環(huán)有關(guān)。實(shí)際上在AI輔助編程的語境下它指的是一套圍繞迭代循環(huán)構(gòu)建的工程化工作方法——把“寫代碼”這件事拆成若干個(gè)可重復(fù)、可驗(yàn)證、可回滾的小循環(huán)每個(gè)循環(huán)里都有明確的輸入、動(dòng)作和驗(yàn)收標(biāo)準(zhǔn)。我最初接觸這個(gè)概念是在用Claude Code做重構(gòu)的時(shí)候。當(dāng)時(shí)面對(duì)一個(gè)兩千多行的老模塊直接讓AI“幫我重構(gòu)一下”結(jié)果它一口氣改了十幾個(gè)文件跑起來一堆報(bào)錯(cuò)我連它改了哪里都理不清。后來換了個(gè)思路把重構(gòu)拆成“讀一個(gè)函數(shù)→改一個(gè)函數(shù)→跑一次測(cè)試→確認(rèn)無誤→進(jìn)入下一個(gè)”的循環(huán)每次只動(dòng)一小塊出問題立刻能定位。這就是循環(huán)工程最樸素的樣子。它解決的核心問題是AI編程工具能力很強(qiáng)但“一次性大改”的失敗成本極高。循環(huán)工程通過控制每次迭代的范圍把不可控的大風(fēng)險(xiǎn)拆解成可控的小風(fēng)險(xiǎn)。適合所有正在用Claude Code、Codex、Cursor這類工具做實(shí)際項(xiàng)目的人尤其是接手遺留代碼、做大規(guī)模重構(gòu)、或者需要保證線上穩(wěn)定性的場(chǎng)景。1.2 為什么現(xiàn)在特別值得關(guān)注過去一年AI編程工具從“補(bǔ)全單行代碼”進(jìn)化到了“理解整個(gè)項(xiàng)目并執(zhí)行多步操作”。Claude Code能直接讀寫文件、執(zhí)行終端命令Codex能根據(jù)自然語言描述生成完整函數(shù)Cursor能跨文件做重構(gòu)。能力越強(qiáng)越需要一套方法來約束它——否則就像給一個(gè)大力士一把沒有刻度的扳手力氣越大越容易擰壞螺絲。循環(huán)工程的價(jià)值在于它提供了一套與工具能力匹配的操作紀(jì)律。不是限制工具而是讓工具的輸出變得可預(yù)期、可驗(yàn)證。我實(shí)測(cè)下來同樣的重構(gòu)任務(wù)用循環(huán)工程的方式做返工率能降低六成以上而且整個(gè)過程心里有底不會(huì)出現(xiàn)“改到一半不知道自己在哪”的情況。1.3 核心循環(huán)的四個(gè)階段一個(gè)完整的工程循環(huán)包含四個(gè)階段我把它簡(jiǎn)稱為RIVA循環(huán)Read讀取讓AI讀取當(dāng)前要處理的最小單元比如一個(gè)函數(shù)、一個(gè)類、一個(gè)配置文件。關(guān)鍵是限定范圍不要讓它讀整個(gè)項(xiàng)目。Intent意圖用一句話說清楚這次循環(huán)要達(dá)成什么目標(biāo)比如“把這個(gè)函數(shù)的同步IO改成異步”“給這個(gè)類加上參數(shù)校驗(yàn)”。Verify驗(yàn)證改完之后立刻跑測(cè)試、跑lint、或者手動(dòng)觸發(fā)一次調(diào)用確認(rèn)行為符合預(yù)期。Advance推進(jìn)確認(rèn)無誤后把這個(gè)改動(dòng)提交或暫存然后進(jìn)入下一個(gè)最小單元。這四個(gè)階段看起來簡(jiǎn)單但每個(gè)階段都有講究。比如Read階段如果范圍劃大了AI會(huì)引入無關(guān)改動(dòng)Intent如果寫得模糊AI會(huì)自由發(fā)揮Verify如果跳過問題會(huì)累積到后面才爆發(fā)。后面我會(huì)逐個(gè)拆解每個(gè)階段的實(shí)操細(xì)節(jié)。2. 工具鏈選型Claude Code、Codex、Cursor怎么配2.1 三個(gè)工具在循環(huán)中的角色分工很多人糾結(jié)“到底用哪個(gè)工具”我的經(jīng)驗(yàn)是不要二選一而是讓它們各司其職。在循環(huán)工程的框架下三個(gè)工具對(duì)應(yīng)不同的循環(huán)環(huán)節(jié)工具最適合的環(huán)節(jié)核心優(yōu)勢(shì)典型用法Claude CodeRead Intent能直接讀文件、執(zhí)行命令上下文理解強(qiáng)讀取模塊、分析依賴、執(zhí)行重構(gòu)CodexIntent 生成函數(shù)級(jí)生成質(zhì)量高補(bǔ)全邏輯嚴(yán)謹(jǐn)生成新函數(shù)、補(bǔ)全測(cè)試用例CursorVerify 編輯編輯器內(nèi)聯(lián)操作流暢diff直觀審查改動(dòng)、微調(diào)、跑測(cè)試這個(gè)分工不是絕對(duì)的但遵循一個(gè)原則讀取和分析用Claude Code生成和補(bǔ)全用Codex審查和微調(diào)用Cursor。這樣每個(gè)工具都在自己最擅長(zhǎng)的環(huán)節(jié)工作循環(huán)效率最高。2.2 Claude Code的安裝與基礎(chǔ)配置Claude Code目前有桌面版和命令行版兩種形態(tài)。命令行版更適合循環(huán)工程因?yàn)樗苤苯忧度虢K端工作流。安裝方式根據(jù)系統(tǒng)不同有所差異核心是確保Node環(huán)境就緒然后通過包管理器安裝。安裝完成后第一件事是配置項(xiàng)目級(jí)的權(quán)限文件。默認(rèn)情況下Claude Code每次讀寫文件都會(huì)詢問這在循環(huán)中會(huì)打斷節(jié)奏?？梢栽陧?xiàng)目根目錄創(chuàng)建一個(gè)配置文件聲明哪些目錄允許自動(dòng)讀寫{ permissions: { allow: [ Read(src/**), Write(src/**), Bash(npm test), Bash(npm run lint) ], deny: [ Read(.env), Write(package-lock.json) ] } }這個(gè)配置的意圖很明確允許它在src目錄下自由讀寫允許跑測(cè)試和lint但禁止碰環(huán)境變量文件和鎖文件。鎖文件一定要禁寫否則AI一次依賴安裝就可能把整個(gè)lock文件重寫導(dǎo)致依賴版本漂移。注意權(quán)限配置是循環(huán)工程的安全帶。寧可多花五分鐘配好也不要讓AI在無約束狀態(tài)下操作項(xiàng)目。2.3 Codex的接入與模型選擇Codex在國(guó)內(nèi)的使用體驗(yàn)取決于接入方式。目前常見的做法是通過API接入模型選擇上建議用推理能力強(qiáng)的版本處理復(fù)雜邏輯用輕量版本處理簡(jiǎn)單補(bǔ)全。配置文件通常放在用戶目錄下核心字段包括模型名稱、API端點(diǎn)、超時(shí)時(shí)間。一個(gè)容易踩的坑是超時(shí)設(shè)置。循環(huán)工程中經(jīng)常需要AI讀取較大文件或生成較長(zhǎng)函數(shù)默認(rèn)超時(shí)往往不夠。建議把超時(shí)調(diào)到60秒以上同時(shí)開啟流式輸出這樣即使生成時(shí)間長(zhǎng)也能看到進(jìn)度不會(huì)以為卡死了。另一個(gè)關(guān)鍵是上下文窗口管理。Codex每次請(qǐng)求攜帶的上下文有限如果讓它在循環(huán)中反復(fù)讀取整個(gè)項(xiàng)目很快就會(huì)超出窗口。正確做法是每次只傳當(dāng)前循環(huán)需要的最小上下文——比如只傳目標(biāo)函數(shù)和它的直接依賴而不是整個(gè)文件。2.4 Cursor的中文環(huán)境與效率設(shè)置Cursor的默認(rèn)界面是英文的對(duì)中文用戶來說設(shè)置中文回復(fù)能顯著提升閱讀效率。在設(shè)置里找到語言選項(xiàng)把界面語言和AI回復(fù)語言都切成中文。注意這兩個(gè)是分開的界面語言影響菜單回復(fù)語言影響AI輸出的內(nèi)容。注冊(cè)環(huán)節(jié)Cursor支持多種方式國(guó)內(nèi)用戶用郵箱注冊(cè)即可不需要糾結(jié)手機(jī)號(hào)的問題。免費(fèi)額度方面新賬號(hào)有一定量的快速請(qǐng)求次數(shù)超出后會(huì)降速但不會(huì)斷供對(duì)于循環(huán)工程這種“小步快跑”的用法額度消耗其實(shí)比想象中慢——因?yàn)槊看窝h(huán)的請(qǐng)求都很小。Cursor還有一個(gè)對(duì)循環(huán)工程特別有用的功能內(nèi)聯(lián)diff審查。每次AI改動(dòng)后它會(huì)用高亮標(biāo)出增刪行你可以逐行確認(rèn)。我習(xí)慣在Verify階段用這個(gè)功能快速掃一遍確認(rèn)沒有意外改動(dòng)后再跑測(cè)試。2.5 工具之間的切換與協(xié)同三個(gè)工具同時(shí)用最大的問題是上下文同步。我的做法是用項(xiàng)目文件本身作為共享上下文。Claude Code讀取并分析后把結(jié)論寫到一個(gè)臨時(shí)筆記文件里Codex生成代碼時(shí)把筆記文件作為上下文傳入Cursor審查時(shí)直接看代碼diff。這樣工具之間不需要直接通信通過文件系統(tǒng)間接同步。另一個(gè)技巧是統(tǒng)一快捷鍵。三個(gè)工具默認(rèn)的快捷鍵不同容易按錯(cuò)。我把它們的“執(zhí)行當(dāng)前操作”都映射到同一個(gè)組合鍵上形成肌肉記憶后循環(huán)的節(jié)奏感會(huì)強(qiáng)很多。3. 循環(huán)工程的核心操作流程3.1 循環(huán)單元的劃分原則循環(huán)工程最關(guān)鍵的一步是劃分循環(huán)單元。單元太大一次改太多容易失控單元太小循環(huán)次數(shù)過多效率低。我的經(jīng)驗(yàn)法則是一個(gè)循環(huán)單元對(duì)應(yīng)一個(gè)可獨(dú)立測(cè)試的行為。具體來說如果改一個(gè)函數(shù)這個(gè)函數(shù)有對(duì)應(yīng)的單元測(cè)試那它就是一個(gè)循環(huán)單元。如果改一個(gè)類類的方法之間有耦合那就把類拆成幾個(gè)循環(huán)先改構(gòu)造函數(shù)和初始化邏輯跑一次測(cè)試再改核心方法再跑一次最后改輔助方法。每次只動(dòng)一個(gè)方法測(cè)試通過后再動(dòng)下一個(gè)。對(duì)于前端組件循環(huán)單元可以是一個(gè)組件的渲染邏輯、一個(gè)事件處理函數(shù)、或者一個(gè)樣式塊。對(duì)于配置文件循環(huán)單元可以是一個(gè)配置項(xiàng)。核心判斷標(biāo)準(zhǔn)是改完之后我能不能用一條命令驗(yàn)證它是對(duì)的。如果不能說明單元?jiǎng)澊罅恕?.2 Read階段如何讓AI精準(zhǔn)理解上下文Read階段的目標(biāo)是讓AI理解當(dāng)前循環(huán)單元而不是整個(gè)項(xiàng)目。很多人習(xí)慣說“讀一下這個(gè)項(xiàng)目”這是循環(huán)工程的大忌。正確做法是明確指定文件路徑和行號(hào)范圍。比如要改一個(gè)函數(shù)可以這樣下指令讀取 src/services/userService.js 中 getUserById 函數(shù)大約在第45行到第80行 以及它調(diào)用的 validateUserId 函數(shù)在 src/utils/validators.js 第12行到第25行。 不要讀取其他文件。這樣AI的上下文里只有兩個(gè)函數(shù)分析精度高而且不會(huì)因?yàn)樽x了無關(guān)文件而產(chǎn)生“順手改一下”的沖動(dòng)。如果項(xiàng)目結(jié)構(gòu)復(fù)雜AI可能找不到文件。這時(shí)候可以用Claude Code的搜索能力先讓它定位在 src 目錄下搜索所有包含 getUserById 的文件列出文件路徑和行號(hào)。定位到之后再執(zhí)行精確讀取。這個(gè)“先搜索后讀取”的兩步法比直接讓AI猜文件位置可靠得多。3.3 Intent階段把需求寫成可執(zhí)行的指令I(lǐng)ntent階段是把“我想干什么”翻譯成AI能精確執(zhí)行的指令。模糊的意圖會(huì)導(dǎo)致AI自由發(fā)揮而自由發(fā)揮在循環(huán)工程中是不可接受的。對(duì)比一下模糊意圖“優(yōu)化這個(gè)函數(shù)”精確意圖“把這個(gè)函數(shù)里的同步文件讀取改成異步使用fs.promises保持函數(shù)簽名不變錯(cuò)誤處理邏輯不變”精確意圖包含三個(gè)要素改什么、改成什么、什么不變。第三個(gè)要素經(jīng)常被忽略但它極其重要——它告訴AI哪些東西不能碰避免它在改A的時(shí)候順手把B也改了。我習(xí)慣在Intent里加一句“只修改這個(gè)函數(shù)不要改動(dòng)其他任何代碼”。這句話看起來多余但實(shí)測(cè)能顯著減少意外改動(dòng)。AI有時(shí)候會(huì)“好心”幫你優(yōu)化相鄰的代碼在循環(huán)工程里這是災(zāi)難。3.4 Verify階段驗(yàn)證手段的層次化設(shè)計(jì)Verify階段是循環(huán)工程的質(zhì)量閘門。驗(yàn)證手段分三個(gè)層次按成本從低到高排列靜態(tài)檢查跑lint、跑類型檢查。成本最低幾秒鐘出結(jié)果能抓住語法錯(cuò)誤和類型不匹配。單元測(cè)試跑當(dāng)前循環(huán)單元對(duì)應(yīng)的測(cè)試。成本中等幾十秒到幾分鐘能抓住邏輯錯(cuò)誤。集成驗(yàn)證手動(dòng)觸發(fā)一次真實(shí)調(diào)用或者跑端到端測(cè)試。成本最高但能抓住單元測(cè)試覆蓋不到的問題。我的做法是每次循環(huán)至少跑靜態(tài)檢查涉及邏輯改動(dòng)必須跑單元測(cè)試涉及接口改動(dòng)必須做集成驗(yàn)證。三個(gè)層次不必每次都全跑但靜態(tài)檢查是底線不能省。如果項(xiàng)目沒有單元測(cè)試怎么辦那就手動(dòng)構(gòu)造一個(gè)最小驗(yàn)證場(chǎng)景。比如改了一個(gè)工具函數(shù)可以在終端里用node直接調(diào)用它傳幾個(gè)典型參數(shù)看輸出。這個(gè)手動(dòng)驗(yàn)證的過程其實(shí)就是在補(bǔ)測(cè)試債。3.5 Advance階段提交策略與回滾準(zhǔn)備Advance階段是把驗(yàn)證通過的改動(dòng)固化下來。這里的關(guān)鍵是提交粒度。一個(gè)循環(huán)單元對(duì)應(yīng)一個(gè)提交提交信息寫清楚這次循環(huán)做了什么。這樣如果后面發(fā)現(xiàn)問題可以精確回滾到某個(gè)循環(huán)之前的狀態(tài)。我習(xí)慣用git的暫存功能每次循環(huán)驗(yàn)證通過后git add當(dāng)前改動(dòng)的文件但不急著commit。等積累了三到五個(gè)循環(huán)后再一起commitcommit信息里列出這幾個(gè)循環(huán)的內(nèi)容。這樣既保持了細(xì)粒度又不會(huì)讓提交歷史過于碎片化?；貪L準(zhǔn)備方面除了git我還會(huì)在循環(huán)開始前把當(dāng)前文件復(fù)制一份到臨時(shí)目錄。雖然git能回滾但有時(shí)候改動(dòng)還沒提交git回滾不了。有個(gè)物理備份心里更踏實(shí)。4. 項(xiàng)目實(shí)戰(zhàn)用循環(huán)工程重構(gòu)一個(gè)真實(shí)模塊4.1 項(xiàng)目背景與重構(gòu)目標(biāo)我拿一個(gè)真實(shí)的Node.js項(xiàng)目練手。這個(gè)項(xiàng)目有一個(gè)orderService.js里面有一個(gè)processOrder函數(shù)大約300行負(fù)責(zé)訂單處理的全流程校驗(yàn)參數(shù)、查庫(kù)存、算價(jià)格、寫數(shù)據(jù)庫(kù)、發(fā)通知。問題是這個(gè)函數(shù)太長(zhǎng)了邏輯耦合嚴(yán)重改一處容易影響另一處。重構(gòu)目標(biāo)是把它拆成五個(gè)獨(dú)立的函數(shù)validateOrder、checkStock、calculatePrice、saveOrder、sendNotification每個(gè)函數(shù)職責(zé)單一可以獨(dú)立測(cè)試。整個(gè)重構(gòu)過程用循環(huán)工程的方式推進(jìn)。4.2 第一個(gè)循環(huán)拆出參數(shù)校驗(yàn)第一個(gè)循環(huán)單元是validateOrder。Read階段讓Claude Code讀取processOrder函數(shù)的前50行以及項(xiàng)目里已有的校驗(yàn)工具函數(shù)。Intent階段指令是從 processOrder 函數(shù)中提取參數(shù)校驗(yàn)邏輯創(chuàng)建一個(gè)新的 validateOrder 函數(shù)。 新函數(shù)接收 order 對(duì)象返回 { valid: boolean, errors: string[] }。 保持原有的校驗(yàn)規(guī)則完全不變不要添加新的校驗(yàn)。 只創(chuàng)建新函數(shù)不要修改 processOrder 的其他部分。AI生成后Verify階段跑lint和已有的訂單測(cè)試。測(cè)試通過說明校驗(yàn)邏輯沒有破壞。Advance階段把新函數(shù)和原函數(shù)的調(diào)用點(diǎn)一起暫存。這個(gè)循環(huán)花了大約十分鐘。如果不用循環(huán)工程直接讓AI重構(gòu)整個(gè)函數(shù)很可能一次改出十幾個(gè)問題排查時(shí)間遠(yuǎn)超十分鐘。4.3 第二個(gè)循環(huán)庫(kù)存檢查的異步改造第二個(gè)循環(huán)單元是checkStock。這個(gè)邏輯原本是同步的但庫(kù)存查詢實(shí)際上要走網(wǎng)絡(luò)請(qǐng)求同步寫法會(huì)阻塞。Intent階段指令從 processOrder 中提取庫(kù)存檢查邏輯創(chuàng)建 checkStock 函數(shù)。 將同步的庫(kù)存查詢改為異步使用 async/await。 函數(shù)簽名async function checkStock(order) 返回 { available: boolean, shortage: number }。 錯(cuò)誤處理保持原有邏輯網(wǎng)絡(luò)異常時(shí)拋出同樣的錯(cuò)誤類型。這里有個(gè)細(xì)節(jié)AI一開始把錯(cuò)誤處理改成了返回{ available: false }而不是拋異常。這改變了原有行為。我在Verify階段跑測(cè)試時(shí)發(fā)現(xiàn)了因?yàn)橛幸粋€(gè)測(cè)試用例專門驗(yàn)證網(wǎng)絡(luò)異常時(shí)的錯(cuò)誤類型。于是回退在Intent里補(bǔ)充“網(wǎng)絡(luò)異常時(shí)必須拋出StockServiceError不要吞掉異?！?。重新生成后通過。這個(gè)循環(huán)暴露了一個(gè)重要經(jīng)驗(yàn)AI傾向于“優(yōu)化”錯(cuò)誤處理把異常改成返回值。在循環(huán)工程中這種行為必須被約束因?yàn)殄e(cuò)誤處理方式的改變會(huì)影響調(diào)用方。4.4 第三個(gè)循環(huán)價(jià)格計(jì)算的純函數(shù)化第三個(gè)循環(huán)單元是calculatePrice。這個(gè)邏輯原本依賴外部的this上下文和幾個(gè)實(shí)例變量。Intent階段指令提取價(jià)格計(jì)算邏輯創(chuàng)建純函數(shù) calculatePrice。 所有依賴的外部變量改為通過參數(shù)傳入。 函數(shù)簽名calculatePrice(order, pricingRules, userLevel) 返回 number。 計(jì)算邏輯和精度保持完全一致不要改變舍入方式。純函數(shù)化的好處是可測(cè)試性大幅提升。Verify階段我寫了一個(gè)快速測(cè)試腳本傳入幾組典型參數(shù)對(duì)比新舊函數(shù)的輸出。全部一致后通過。這個(gè)循環(huán)的坑在于浮點(diǎn)數(shù)精度。AI在重構(gòu)時(shí)把原來的toFixed(2)改成了Math.round導(dǎo)致某些邊界值結(jié)果不同。測(cè)試腳本抓到了這個(gè)差異。教訓(xùn)是涉及數(shù)值計(jì)算的重構(gòu)Verify階段必須做新舊對(duì)比不能只跑原有測(cè)試。4.5 第四、五個(gè)循環(huán)數(shù)據(jù)庫(kù)寫入與通知解耦第四和第五個(gè)循環(huán)相對(duì)簡(jiǎn)單因?yàn)榍叭齻€(gè)循環(huán)已經(jīng)把主要邏輯拆出去了。saveOrder循環(huán)主要是把數(shù)據(jù)庫(kù)操作提取出來加上事務(wù)邊界。sendNotification循環(huán)是把通知邏輯改成事件驅(qū)動(dòng)通過EventEmitter解耦。這兩個(gè)循環(huán)各花了五到八分鐘主要時(shí)間花在Verify階段的集成測(cè)試上。因?yàn)樯婕皵?shù)據(jù)庫(kù)和外部通知需要啟動(dòng)測(cè)試環(huán)境。但因?yàn)橛星叭齻€(gè)循環(huán)打下的基礎(chǔ)改動(dòng)范圍很小問題定位很快。五個(gè)循環(huán)做完processOrder從300行變成了一個(gè)20行的編排函數(shù)依次調(diào)用五個(gè)子函數(shù)。整個(gè)重構(gòu)過程大約兩小時(shí)中間沒有出現(xiàn)“改崩了要回滾整個(gè)重構(gòu)”的情況。4.6 循環(huán)工程的效率對(duì)比為了量化效果我做了個(gè)對(duì)比同樣的重構(gòu)任務(wù)用傳統(tǒng)“一次性大改”的方式做了一次用循環(huán)工程做了一次。指標(biāo)一次性大改循環(huán)工程總耗時(shí)1.5小時(shí)2小時(shí)返工次數(shù)4次1次返工耗時(shí)約1小時(shí)約10分鐘最終bug數(shù)3個(gè)0個(gè)心理負(fù)擔(dān)高全程焦慮低每步可控一次性大改看起來總耗時(shí)短但返工耗時(shí)加起來反而更長(zhǎng)而且最終還有bug。循環(huán)工程雖然單次循環(huán)看起來慢但總耗時(shí)可控質(zhì)量更高。更重要的是循環(huán)工程的過程中你知道自己在哪一步出了問題能立刻定位這種確定性是傳統(tǒng)方式給不了的。5. 常見問題與排查技巧實(shí)錄5.1 AI不按指令改總是“順手優(yōu)化”這是最高頻的問題。AI看到一段代碼即使你只讓它改一個(gè)函數(shù)它也會(huì)“好心”把相鄰的代碼一起優(yōu)化了。排查思路先檢查Intent指令是否足夠明確有沒有加“只修改這個(gè)函數(shù)不要改動(dòng)其他任何代碼”這句話。如果加了還出現(xiàn)就在Verify階段用diff工具逐行審查發(fā)現(xiàn)意外改動(dòng)立刻回退并在下一輪Intent里把“不要改XX”寫得更具體。我的經(jīng)驗(yàn)是Claude Code比Codex更容易“順手優(yōu)化”因?yàn)樗纳舷挛睦斫飧鼜?qiáng)更容易產(chǎn)生“整體優(yōu)化”的沖動(dòng)。用Claude Code做Read和Intent時(shí)要特別強(qiáng)調(diào)范圍限制。5.2 循環(huán)次數(shù)太多感覺效率低循環(huán)單元?jiǎng)澋锰?xì)會(huì)導(dǎo)致循環(huán)次數(shù)過多。判斷標(biāo)準(zhǔn)是如果一個(gè)循環(huán)單元改完之后你花在Verify上的時(shí)間比改代碼的時(shí)間還長(zhǎng)說明單元?jiǎng)澬×?。這時(shí)候應(yīng)該把相鄰的幾個(gè)小單元合并成一個(gè)稍大的單元。另一個(gè)原因是Verify手段太重。如果每次循環(huán)都跑完整的集成測(cè)試那確實(shí)慢。應(yīng)該分層驗(yàn)證小改動(dòng)只跑lint和單元測(cè)試涉及接口的才跑集成測(cè)試。5.3 測(cè)試環(huán)境啟動(dòng)慢拖累Verify這是基礎(chǔ)設(shè)施問題不是循環(huán)工程本身的問題。解決辦法是讓測(cè)試環(huán)境常駐不要每次循環(huán)都重啟。比如數(shù)據(jù)庫(kù)用Docker容器常駐測(cè)試數(shù)據(jù)用fixture預(yù)置測(cè)試用例之間做好隔離。這樣Verify階段只需要跑測(cè)試命令不需要等環(huán)境啟動(dòng)。如果環(huán)境實(shí)在啟動(dòng)慢可以在循環(huán)中先用mock驗(yàn)證邏輯等積累幾個(gè)循環(huán)后再做一次真實(shí)環(huán)境的集成驗(yàn)證。但mock驗(yàn)證不能完全替代真實(shí)驗(yàn)證最終還是要跑一次真的。5.4 AI生成的代碼風(fēng)格與項(xiàng)目不一致這個(gè)問題在多人協(xié)作的項(xiàng)目中特別明顯。解決辦法是在項(xiàng)目根目錄放一個(gè)代碼風(fēng)格說明文件比如.editorconfig或者一個(gè)簡(jiǎn)短的STYLE.md在Intent階段讓AI先讀這個(gè)文件。Claude Code和Cursor都能讀取項(xiàng)目配置文件并遵循。另一個(gè)技巧是在Intent里附上一個(gè)“參考實(shí)現(xiàn)”的路徑讓AI模仿那個(gè)文件的風(fēng)格。比如“參考src/services/otherService.js的代碼風(fēng)格”。這比抽象的風(fēng)格描述有效得多。5.5 循環(huán)過程中發(fā)現(xiàn)前面的循環(huán)有問題這是正常情況循環(huán)工程不要求一次做對(duì)。發(fā)現(xiàn)前面循環(huán)有問題時(shí)不要在當(dāng)前循環(huán)里順手修而是回退到那個(gè)循環(huán)單獨(dú)修完再繼續(xù)。比如第三個(gè)循環(huán)發(fā)現(xiàn)第一個(gè)循環(huán)的validateOrder少了一個(gè)校驗(yàn)規(guī)則應(yīng)該先回退到第一個(gè)循環(huán)的狀態(tài)補(bǔ)上校驗(yàn)驗(yàn)證通過然后再重新推進(jìn)到第三個(gè)循環(huán)。這樣做看起來麻煩但能保證每個(gè)循環(huán)的狀態(tài)都是干凈的。如果在前面的問題沒修的情況下繼續(xù)推進(jìn)問題會(huì)累積到最后排查成本更高。5.6 常見問題速查表問題現(xiàn)象可能原因排查動(dòng)作預(yù)防措施AI改動(dòng)范圍超出預(yù)期Intent范圍描述不清檢查diff回退意外改動(dòng)Intent加“只改XX”約束循環(huán)效率低單元?jiǎng)澨』蝌?yàn)證太重合并小單元分層驗(yàn)證按可測(cè)試行為劃分單元測(cè)試跑得慢環(huán)境未常駐檢查環(huán)境啟動(dòng)方式用容器常駐測(cè)試環(huán)境代碼風(fēng)格不一致未提供風(fēng)格參考檢查項(xiàng)目配置文件Intent中附參考文件路徑前面循環(huán)有問題驗(yàn)證不充分回退到問題循環(huán)單獨(dú)修每個(gè)循環(huán)嚴(yán)格VerifyAI吞掉異常AI傾向“優(yōu)化”錯(cuò)誤處理檢查錯(cuò)誤處理邏輯Intent明確錯(cuò)誤處理方式6. 進(jìn)階技巧讓循環(huán)工程更順手的幾個(gè)習(xí)慣6.1 維護(hù)一個(gè)循環(huán)日志每次循環(huán)開始前在臨時(shí)文件里記一行循環(huán)編號(hào)、目標(biāo)、涉及文件。循環(huán)結(jié)束后記一行結(jié)果、耗時(shí)、遇到的問題。這個(gè)日志不需要很正式就是給自己看的。積累十幾個(gè)循環(huán)后回看日志能發(fā)現(xiàn)自己的模式——比如哪類改動(dòng)容易出問題哪類驗(yàn)證手段最有效。我用的是一個(gè)簡(jiǎn)單的Markdown文件放在項(xiàng)目根目錄的.loop-log.md加在.gitignore里不提交。格式大概是## Loop 3 - 2024-XX-XX 目標(biāo)提取 calculatePrice 為純函數(shù) 文件src/services/orderService.js 結(jié)果通過耗時(shí)8分鐘 問題AI把toFixed改成了Math.round測(cè)試抓到6.2 為循環(huán)工程準(zhǔn)備專用測(cè)試腳本項(xiàng)目原有的測(cè)試套件可能很重跑一次要幾分鐘。循環(huán)工程需要的是快速反饋所以值得為常用循環(huán)單元寫一些輕量測(cè)試腳本。比如針對(duì)工具函數(shù)的測(cè)試可以直接用node運(yùn)行不需要啟動(dòng)整個(gè)測(cè)試框架。這些腳本放在scripts/loop-tests/目錄下按循環(huán)單元命名。每次循環(huán)的Verify階段先跑這些輕量腳本通過了再跑正式測(cè)試。這樣大部分問題在輕量腳本階段就被抓住了不用等正式測(cè)試。6.3 用git worktree做并行循環(huán)如果項(xiàng)目比較大可以同時(shí)開多個(gè)循環(huán)每個(gè)循環(huán)在一個(gè)獨(dú)立的git worktree里進(jìn)行。這樣循環(huán)之間互不干擾一個(gè)循環(huán)在Verify時(shí)另一個(gè)循環(huán)可以繼續(xù)改。等所有循環(huán)都驗(yàn)證通過后再合并回主分支。這個(gè)技巧適合大型重構(gòu)但要注意合并沖突。如果兩個(gè)循環(huán)改了同一個(gè)文件的不同部分合并時(shí)可能沖突。所以并行循環(huán)的前提是循環(huán)單元之間文件不重疊。6.4 定期回顧循環(huán)質(zhì)量每做完一個(gè)較大的任務(wù)花十分鐘回顧一下哪些循環(huán)一次通過哪些循環(huán)返工了返工的原因是什么。如果發(fā)現(xiàn)某類循環(huán)總是返工說明這類循環(huán)的Intent模板或者Verify手段需要調(diào)整。比如我發(fā)現(xiàn)自己早期做“異步改造”類循環(huán)時(shí)總是返工原因是Intent里沒有明確錯(cuò)誤處理方式。后來在模板里固定加上“錯(cuò)誤處理保持原有邏輯異常類型不變”返工率就降下來了。6.5 把循環(huán)工程用在非編程場(chǎng)景循環(huán)工程的思路其實(shí)不限于編程。寫文檔、做設(shè)計(jì)、甚至整理數(shù)據(jù)都可以用同樣的方法把大任務(wù)拆成小循環(huán)每個(gè)循環(huán)有明確的輸入、動(dòng)作、驗(yàn)證。比如寫一篇長(zhǎng)文可以按章節(jié)循環(huán)讀參考資料→寫這一節(jié)→檢查邏輯和事實(shí)→確認(rèn)后進(jìn)入下一節(jié)。這樣比一次性寫完再改要高效得多。我在寫技術(shù)方案文檔時(shí)就用這個(gè)方法。每個(gè)循環(huán)寫一個(gè)小節(jié)寫完立刻讓AI檢查事實(shí)錯(cuò)誤和邏輯漏洞確認(rèn)后繼續(xù)。最后整篇文檔的返工率比一次性寫完低很多。6.6 循環(huán)工程的邊界循環(huán)工程不是萬能的。對(duì)于探索性任務(wù)——比如“我不知道這個(gè)功能該怎么實(shí)現(xiàn)先試試看”——循環(huán)工程反而會(huì)限制思路。這種情況下應(yīng)該先做一次自由探索找到方向后再用循環(huán)工程來落地。另外對(duì)于非常小的改動(dòng)——比如改一個(gè)變量名、修一個(gè)拼寫錯(cuò)誤——循環(huán)工程的開銷大于收益。直接改就行不需要走完整循環(huán)。判斷標(biāo)準(zhǔn)是如果改動(dòng)的影響范圍你完全清楚而且驗(yàn)證成本極低就不需要循環(huán)。我個(gè)人的習(xí)慣是改動(dòng)涉及三個(gè)以上文件或者涉及核心邏輯就走循環(huán)工程否則直接改。這個(gè)閾值可以根據(jù)項(xiàng)目情況調(diào)整。6.7 一個(gè)容易被忽略的細(xì)節(jié)循環(huán)之間的休息連續(xù)做五六個(gè)循環(huán)后注意力會(huì)下降Verify階段容易走神。我的做法是每做完三個(gè)循環(huán)強(qiáng)制休息五分鐘站起來走走回來再繼續(xù)。這五分鐘的投入能避免因?yàn)槠趯?dǎo)致的驗(yàn)證疏漏很劃算。循環(huán)工程的本質(zhì)是用紀(jì)律換確定性。它不會(huì)讓單次操作變快但會(huì)讓整個(gè)任務(wù)的總耗時(shí)和總風(fēng)險(xiǎn)大幅下降。對(duì)于需要保證質(zhì)量的工程任務(wù)這個(gè)交換是值得的。