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