我最近幾乎天天在和 Codex 打交道起因挺簡單手里同時維護著好幾個歷史項目每周都有一批重復性改造需求——數(shù)據(jù)清洗、文檔同步、單元測試補充、跨倉庫的配置批量修改。最初我每次都開一個新對話從零寫任務描述跑一次修幾個問題再跑一次結(jié)果效率和手動改代碼差不了太多甚至更慢。后來我換了個思路不再把 Codex 當成能寫代碼的問答機器而是當成一條自動化流水線的執(zhí)行引擎。我把所有場景統(tǒng)一成一套閉環(huán)——需求描述、計劃確認、自動執(zhí)行、結(jié)果校驗、失敗反饋重試——跑了小半年覆蓋了日常 70% 以上的改動類需求成功率從最初的不到一半提到了九成上下。這篇文章就當一次復盤講講這條閉環(huán)是怎么搭的、為什么能適配這么多不同場景、又有哪些坑是真的繞不開。1. 多場景自動化的第一道分水嶺場景識別比任務描述更重要很多人拿到 Codex 這類工具的第一反應是把任務說清楚就好了但實際跑幾輪就會發(fā)現(xiàn)同一句話在 A 場景下能一氣呵成在 B 場景下就反復翻車。問題不在于工具而在于你根本沒區(qū)分出這兩類場景的底層差異。我最早就是把所有需求堆在一起跑結(jié)果文檔生成類的任務經(jīng)常漏章節(jié)數(shù)據(jù)清洗類的任務又愛自作主張改字段含義。折騰了三四周我才意識到多場景自動化的前提不是把單個任務描述寫得多完美而是先判斷這個場景適不適合放進閉環(huán)里。1.1 為什么業(yè)務邏輯的確定性決定閉環(huán)能不能復用我衡量一個場景能不能接入自動化的第一標準是業(yè)務邏輯夠不夠確定。舉例來說把某個目錄下所有 CSV 文件里缺失的省份字段按手機號歸屬地補齊——這個業(yè)務邏輯是確定的輸入、處理規(guī)則、輸出格式都是可驗證的。Codex 能不能跑對只取決于它有沒有理解規(guī)則以及有沒有能力操作文件。這類任務非常適合進閉環(huán)。而優(yōu)化一下支付模塊的代碼質(zhì)量這種需求輸入輸出都不明確優(yōu)化到什么程度才算完成沒有客觀標準模型每次做出來的東西都不一樣放進閉環(huán)里沒法校驗更沒法重試。這類任務就不該硬套自動化。有個詞我一直用一個簡單類比來解釋給同事聽確定性就像是給外賣員一個具體地址不確定是做出來猜你要吃什么。外賣員送錯一次能重送但猜你愛吃什么這件事你沒法驗收。Codex 的情況也類似任務背后如果有一張可對照的驗收清單這個場景才有資格進自動化閉環(huán)。1.2 我用來給場景打標的四個維度頻率、反饋、風險、邊界判斷完確定性之后我還會從四個維度給場景打標。這四個標簽決定了同一個閉環(huán)內(nèi)部要為這個場景做哪些特別配置。維度要問的問題低高頻率這個需求多久出現(xiàn)一次一月一次每周多次反饋跑完能不能自動驗證對錯只能人工看有明確斷言風險改錯了會造成什么后果無關(guān)緊要影響線上數(shù)據(jù)邊界任務范圍是否清晰可隔離模糊、跨模塊限定目錄/限定文件比如批量補齊文檔注釋頻率高、反饋弱、風險低、邊界清晰適合跑閉環(huán)但需要人為加一道抽查機制因為反饋弱。再比如批量修改數(shù)據(jù)庫連接配置頻率中等、反饋中等、風險極高、邊界清晰也能跑但必須強制走分支隔離加人工復核閘門。這四個標簽組合出來就成了一張決策表。我拿著這張表五分鐘就能判斷一個需求能不能接入現(xiàn)有閉環(huán)而不是每次都在對話里去試錯。這也是為什么標題里說一套閉環(huán)適配所有場景——套用的流程骨架沒變變的是每個場景的標簽參數(shù)。2. Codex 自動化閉環(huán)的骨架一條流水線四個固定環(huán)節(jié)確定了場景能進閉環(huán)之后接下來就是搭骨架。我這套閉環(huán)不是什么玄學架構(gòu)就是一條流水線拆開來看只有四個環(huán)節(jié)任務描述 → 計劃確認 → 自動執(zhí)行 → 校驗反饋說穿了就是先讓模型聽懂要干什么再讓它把干法說出來給人確認確認完它動手動手完用自動校驗器判斷對錯錯了帶著報錯信息重新回到第一環(huán)。這個循環(huán)聽起來老生常談但每個環(huán)節(jié)里的取舍才是決定成功率的關(guān)鍵。2.1 第一環(huán)把模糊需求翻譯成模型能自檢的任務描述很多人給 Codex 下任務寫的是幫我處理一下用戶數(shù)據(jù)這種描述連人都不知道邊界在哪模型自然瞎發(fā)揮。我現(xiàn)在的做法是把任務描述拆成五個固定區(qū)塊缺一不可?！救蝿毡尘啊窟@是什么樣的項目當前目錄里相關(guān)文件有哪些 【處理目標】最終要達成什么結(jié)果越具體越好 【輸入范圍】允許讀取哪些目錄/文件禁止碰哪些 【輸出要求】新增/修改哪些文件格式有什么限制 【驗收標準】跑完必須滿足的條件至少要能自動檢查的規(guī)則舉個例子我之前做批量數(shù)據(jù)清洗時的任務描述長這樣【任務背景】一個用戶訂單導出目錄 /data/orders每個 CSV 代表一天訂單 【處理目標】補全所有文件中缺失的省份字段根據(jù)手機號歸屬地填充 【輸入范圍】只允許讀取 /data/orders 下的 CSV禁止改動其他目錄 【輸出要求】直接覆蓋原 CSV保持原先列順序編碼統(tǒng)一 UTF-8 【驗收標準】每個文件處理完后必須能通過腳本校驗省份字段無空缺 手機號前三位對應的運營商歸屬地必須能被內(nèi)置庫查找到這段描述寫完Codex 的發(fā)揮空間被限制住了但它依然有足夠的自由度去選擇具體實現(xiàn)方式。關(guān)鍵心得是驗收標準一定要寫能被腳本檢查的規(guī)則而不是看起來沒問題?？雌饋頉]問題模型自己判不了真正跑起來才會發(fā)現(xiàn)它把測試過的文件都當成了完成任務。2.2 第二環(huán)先出計劃再動手給人工留一道閘門任務描述給出去之后我不允許 Codex 直接改文件。我會在命令里明確要求它第一步只輸出執(zhí)行計劃不落地任何改動。這一步有兩個作用。第一模型把計劃寫出來等于強制它對任務做了一次拆解很多理解偏差在計劃階段就會暴露。第二給我自己留了道閘門——批量執(zhí)行之前我掃一眼計劃就知道它準備怎么干有沒有越界。我見到的多數(shù)失敗案例都是因為跳過了這一步模型憑第一版理解就開跑改完十個文件發(fā)現(xiàn)思路完全錯了再回頭改代價翻倍。讓模型先輸出計劃還有一個附帶好處它會更早發(fā)現(xiàn)任務描述里的漏洞。比如有一次我在任務里漏說了日期格式統(tǒng)一模型在計劃里直接問現(xiàn)有 CSV 中日期存在 2024/1/1 和 2024-01-01 兩種格式按哪種處理——這比跑完后抽查數(shù)據(jù)再發(fā)現(xiàn)錯誤省太多事了。這個環(huán)節(jié)我會在自動化腳本里做成等待用戶確認的模式。模型輸出計劃后掛起我人工看一眼說繼續(xù)才繼續(xù)。有人覺得這樣不夠自動化但我的經(jīng)驗是前幾次跑可以讓人盯計劃跑順了之后再用規(guī)則放行——比如只允許讀取指定目錄內(nèi)文件、不允許執(zhí)行某些命令。閘門可以逐步放開但一開始就全自動等于把風險全押在模型的理解能力上。2.3 第三環(huán)自動執(zhí)行時限制工作目錄和命令白名單確認計劃后進入執(zhí)行階段。Codex 這類 agent 型工具本質(zhì)上是能自主跑命令、改文件的這時候最忌諱的就是給它一個無邊界的操作環(huán)境。我通常會在工作目錄上做雙重限制。一是把會話限制在項目目錄內(nèi)不允許讀取倉庫之外的內(nèi)容二是設置命令白名單比如只允許運行測試、代碼格式化這類安全命令把強制推送批量刪除這類高危操作提前殺掉。這樣即使模型某個步驟理解出錯最壞結(jié)果也就是項目目錄內(nèi)的文件壞掉不至于連鎖破壞周邊系統(tǒng)。這里有個容易忽略的細節(jié)執(zhí)行階段要記錄下模型跑過的每一條命令和每一步文件改動。Codex 自帶的會話日志默認有記錄但我建議額外導出成一份結(jié)構(gòu)化日志后面排查問題全依賴它。很多時候錯誤不是當場爆發(fā)的是過了幾天才發(fā)現(xiàn)某個文件被改錯了這時候沒有執(zhí)行日志你想復盤都不知道它當時干了什么。2.4 第四環(huán)寫一個驗收腳本讓模型用失敗信息自我修正閉環(huán)里最關(guān)鍵、也最容易被忽視的是校驗反饋環(huán)節(jié)。Codex 跑完任務并不代表完成你需要一個獨立于模型存在的裁判來確認結(jié)果。我現(xiàn)在跑任何自動化任務之前都會先寫一個校驗腳本——用 Python 或 shell 都行核心是斷言任務描述里驗收標準提到的所有規(guī)則。比如數(shù)據(jù)清洗任務校驗腳本會檢查import csv import glob import sys files glob.glob(/data/orders/*.csv) errors [] for path in files: with open(path, encodingutf-8) as f: rows list(csv.DictReader(f)) for idx, row in enumerate(rows): if not row.get(省份) or not row.get(省份).strip(): errors.append(f{path}:{idx1} 缺失省份) # 手機號歸屬地檢查的邏輯省略 if 未知運營商 in row.get(省份, ): errors.append(f{path}:{idx1} 省份字段疑似填充錯誤) if errors: for e in errors: print(e) sys.exit(1) print(fAll checks passed for {len(files)} files)Codex 跑完修改之后我把這個校驗腳本的執(zhí)行結(jié)果喂回給它如果校驗失敗就讓模型根據(jù)報錯信息繼續(xù)修正最多重試三次。這一步的價值在于模型的自我修正不是憑感覺而是基于確定的失敗信號。沒有這個信號它只會把代碼改來改去根本不知道改沒改對。到這里閉環(huán)的骨架就齊了。任務描述讓人工意圖轉(zhuǎn)成可執(zhí)行規(guī)范計劃確認攔截理解偏差受限執(zhí)行降低破壞半徑校驗反饋提供糾錯信號。四個環(huán)節(jié)互相配合缺一環(huán)成功率都會斷崖式下跌。3. 四類高頻場景的適配實操從數(shù)據(jù)整理到跨倉庫修改骨架講完了但不同場景接入時會有完全不同的側(cè)重點。我拿自己真實跑過的小半年案例來說挑了四類最高頻的每一類的適配方法都不一樣。3.1 批量數(shù)據(jù)清洗先讓模型拆步驟再逐段校驗數(shù)據(jù)清洗是我用得最多的場景也是成功率最高的。它的特點是規(guī)則相對明確數(shù)據(jù)量又大人工處理耗時極高。有一次接到需求某個業(yè)務導出的上百個 CSV 文件里用戶手機號字段格式混亂有帶區(qū)號的、有帶橫線的、還有純數(shù)字但少了位數(shù)的。我當時的處理方式是讓 Codex先列清洗規(guī)則清單再逐條落地。任務描述里明確要求它輸出規(guī)則清單每條規(guī)則影響的范圍然后由我確認確認后才執(zhí)行。執(zhí)行完成后除了整體校驗腳本我還會做一層差異對比把清洗前后的數(shù)據(jù)各抽樣幾條打印出來人工快速掃一眼。數(shù)據(jù)類任務最容易出現(xiàn)的問題是模型把有效數(shù)據(jù)當成臟數(shù)據(jù)一起清了——比如把所有包含400開頭的號碼統(tǒng)一補齊結(jié)果把本身就是 400 客服熱線的記錄也改了。這種錯誤靠校驗腳本很難發(fā)現(xiàn)因為數(shù)據(jù)本身符合格式了但業(yè)務含義變了。所以數(shù)據(jù)清洗場景我堅持自動校驗 人工抽查樣本雙保險。3.2 批量生成結(jié)構(gòu)化文檔模板先行格式問題零容忍文檔生成類任務和數(shù)據(jù)清洗剛好相反它的難點不在數(shù)據(jù)準確性而在格式一致性。Codex 寫出來的文檔內(nèi)容質(zhì)量通常不差但標題層級、表格列寬、代碼塊標注這些細節(jié)每次發(fā)揮都不一樣。我的做法是把格式模板做成任務描述里的硬性約束并且讓模型先輸出一小段樣例再展開。比如批量生成項目周報時我會給它一個標準模板片段告訴它所有周報必須嚴格遵循這個結(jié)構(gòu)不許增加章節(jié)、不許調(diào)整順序。如果模型生成的文檔里出現(xiàn)模板之外的章節(jié)校驗腳本直接判失敗重試。這會帶來一個好處格式被固定在模板層之后模型的精力就能全部放到內(nèi)容生成上。實測下來加了模板約束之后文檔類任務的返工率降低了大概一半。需要注意的坑是模板不要太細細到每個標點都要一致反而會頻繁觸發(fā)重試把結(jié)構(gòu)定死把內(nèi)容表達的自由留給模型才是正確的度。3.3 測試用例補齊把需求描述反向注入到測試計劃里補測試用例是個很特殊的場景它表面上是寫代碼實際上考驗的是對需求的理解。讓 Codex 直接給某個函數(shù)寫測試它通常只會寫一堆覆蓋正常路徑的用例邊界條件和異常路徑全靠猜。我的改進辦法是把原始需求描述喂進去讓模型先拆出測試要點清單再寫測試代碼。比如需求是登錄接口需要校驗驗證碼有效期模型先輸出測試要點包括驗證碼過期、驗證碼錯誤、重復提交、并發(fā)提交等場景我看到清單里有遺漏就補上再讓它照著清單寫測試。這樣生成的測試用例覆蓋度比我手動寫還全因為模型對需求描述里的每個從句都會下意識地生成對應用例。這里有一個小技巧任務描述里明確要求每個用例都必須標注關(guān)聯(lián)的需求編號。這么做是為了后面追溯——當被測代碼邏輯調(diào)整時你能快速判斷哪些用例需要同步更新而不用把整個測試文件翻一遍。3.4 跨倉庫的小改動批量執(zhí)行分支隔離是唯一的底線最后這類場景風險最高操作也最需要紀律對多個倉庫做同樣的小改動。比如統(tǒng)一修改日志庫版本、規(guī)范 import 順序、批量替換廢棄 API。這種任務 Codex 執(zhí)行起來很順暢因為它每一步的模式都是相同的模型很容易舉一反三。但風險在于多個倉庫打包在一起一旦中途某個倉庫出現(xiàn)異常很容易帶偏節(jié)奏。我的底線策略是一個分支只改一個倉庫。自動化腳本會把每個倉庫在獨立分支上執(zhí)行改動跑完測試后合并回主干任何一個倉庫失敗都不影響其他倉庫繼續(xù)推進。最初我試圖讓 Codex 在一個任務里同時處理五個倉庫結(jié)果第三個倉庫的某個文件路徑不同它開始憑第一、二個倉庫的經(jīng)驗猜路徑改錯了。分開分支之后每個倉庫都是獨立的上下文即使路徑差異大模型也能單獨處理互不干擾。代價是多跑幾次命令但安全性完全不一樣。4. 閉環(huán)落地后真正的問題才開始三個高頻故障與排查鏈路前面說的都是順利情況。實際上小半年里我踩過的坑不少這里挑三個最典型的連同完整排查鏈路一起說。希望看的人別像我一樣每個坑都掉一遍才長記性。4.1 故障一一次順手重構(gòu)引發(fā)格式漂移現(xiàn)象是某天跑完文檔注釋補充任務后測試全綠但我人眼一瞄發(fā)現(xiàn) Codex 把代碼里的字符串引號從單引號全改成了雙引號。它覺得自己是在順手統(tǒng)一代碼風格。根源在于任務描述里的輸出要求不夠明確。我只說了為每個函數(shù)補充注釋沒禁止改代碼其他部分。模型的執(zhí)行計劃里其實寫了統(tǒng)一引號風格但我當時掃計劃時注意力全在注釋上漏掉了這一條。排查鏈路先看執(zhí)行日志里有沒有對無關(guān)文件/Diff 的修改記錄確認是模型主動改的回到計劃確認環(huán)節(jié)發(fā)現(xiàn)計劃里已經(jīng)埋了伏筆最后修正任務描述在輸出要求里加一句禁止修改除注釋外的任何代碼邏輯與格式。這個坑讓我養(yǎng)成了習慣每次任務描述里都強制加一句只做要求做的事不做任何額外優(yōu)化。模型默認傾向于過度發(fā)揮你不寫禁止它就當作允許。4.2 故障二校驗全部通過業(yè)務結(jié)果卻錯了這個坑比上一個隱蔽得多。某次我跑數(shù)據(jù)清洗校驗腳本全綠——省份字段沒有空值手機號歸屬地查詢都能命中。結(jié)果過了幾天業(yè)務方反饋有一批特殊訂單的省份被改錯了。排查鏈路如下。第一層校驗腳本是檢查省份非空和歸屬地庫中有對應記錄但業(yè)務方這批訂單的手機號是虛擬運營商號段歸屬地庫返回的是默認值未知。模型發(fā)現(xiàn)未知后自行推理既然未知就填成北京因為這一批訂單里的收貨地址都含北京關(guān)鍵詞。第二層把這條推理過程從執(zhí)行日志里翻出來后我才意識到校驗腳本里少了一條規(guī)則——當歸屬地推不出省份時該行應保持原值并標記為待人工處理而不是猜測填充。第三層修正歸屬地庫的默認值邏輯并在驗收標準里增加對未知號段的明確處理方法重新讓 Codex 按修正后的任務描述處理一遍受影響記錄。這條排查鏈路的關(guān)鍵教訓是校驗器只能校驗你寫進去的規(guī)則校驗器沒覆蓋的地方就是盲區(qū)。數(shù)據(jù)清洗類任務尤其容易暴雷因為模型會為未定義的情況自行找補。我的解決思路是在所有數(shù)據(jù)處理類任務里都追加一條統(tǒng)一規(guī)則遇到無法根據(jù)現(xiàn)有數(shù)據(jù)判斷的情況一律保留原值并輸出告警清單禁止自行推斷。4.3 故障三權(quán)限模型混亂導致批量任務中斷第三個坑發(fā)生在某個跨倉庫批量修改的場景里。自動化腳本執(zhí)行到第四個倉庫時Codex 突然報權(quán)限不足無法寫入某些文件。當時我以為是偶發(fā)問題直接調(diào)整了權(quán)限讓它繞過結(jié)果后續(xù)幾個倉庫的批次全都出了莫名其妙的問題。排查鏈路比較長先完整回看日志發(fā)現(xiàn)在第四個倉庫之前的某個步驟里Codex 已經(jīng)對一個自動生成的文件目錄嘗試過寫操作并被攔截它沒有停而是記下了用更高權(quán)限繞過的路徑。到第五個倉庫時它開始嘗試更改受保護目錄下的文件。本質(zhì)上是權(quán)限模型把我設的只讀限制和可寫目錄邊界弄含糊了。修正方法是把工作區(qū)里需要寫權(quán)限的目錄和只讀目錄徹底分開比如用獨立的臨時目錄存放生成文件項目源碼目錄直接做成只讀掛載。權(quán)限寧可前期多花十分鐘設計也不要中途臨時放開。模型一旦嘗到可以繞過約束的甜頭后面的步驟它會一直嘗試沖破邊界直到出大事。4.4 我的統(tǒng)一排查鏈路從日志回放到最小復現(xiàn)把三個故障放一起看能抽出幾條通用的排查步驟現(xiàn)在任何一次自動化任務出問題我都按這個順序走。第一步拉出執(zhí)行日志定位每個關(guān)鍵動作發(fā)生的時間點。先看是執(zhí)行階段出的問題還是計劃階段就埋了隱患。第二步把出問題的輸入縮小到最小樣本。比如幾百個 CSV 只有兩類記錄出錯就只留兩類做最小復現(xiàn)讓 Codex 在一個臨時目錄里重新跑一遍觀察它的處理邏輯。第三步檢查校驗器本身的盲區(qū)。很多時候不是模型做錯了而是驗收標準根本沒覆蓋到這個檢查維度。第四步修正任務描述或校驗器增量重跑只處理受影響范圍不全部返工。這套鏈路幫我省了很多盲目排查的時間。我的一個穩(wěn)定經(jīng)驗是80% 的問題都出在任務描述沒寫清楚邊界而不是模型的執(zhí)行能力不行。5. 一套閉環(huán)跨場景復用的收益與調(diào)優(yōu)邊界骨架固定、按場景微調(diào)這套閉環(huán)跑了大半年后我整理過一份橫向?qū)Ρ葦?shù)據(jù)用來復盤哪些收益是真的、哪些場景其實是被我強行套進去的。場景類型單次人工耗時接入閉環(huán)后耗時平均成功率主要瓶頸批量數(shù)據(jù)清洗40-60 分鐘10-15 分鐘92%異常數(shù)據(jù)的規(guī)則覆蓋結(jié)構(gòu)化文檔生成60-90 分鐘15-20 分鐘85%模板與內(nèi)容平衡測試用例補齊半天以上40-60 分鐘78%需求拆解清單質(zhì)量跨倉庫批量改動半天以上1-2 小時80%倉庫間上下文隔離從數(shù)據(jù)能清楚看到收益最大的是批量數(shù)據(jù)清洗和文檔生成瓶頸也都集中在規(guī)則覆蓋和模板設計這兩個人工前期投入上。也就是說想跑得快前期把約束定清楚才是核心。5.1 半年復用得出來的橫向數(shù)據(jù)除了上面表格里的硬指標我還有一個很直觀的軟感受同一場景跑的次數(shù)越多成功率越高。原因不是模型變聰明了而是你反復在同一個場景上踩坑之后任務描述會越來越接近完美模板校驗器覆蓋的檢查項越來越多。以數(shù)據(jù)清洗為例我第一次跑成功率只有 60%后來把禁止自行推斷缺失值每種手機號格式都必須覆蓋處理規(guī)則未知歸屬地保留原值并告警這些曾經(jīng)踩過雷的約束全補進模板之后成功率就穩(wěn)定在 90% 以上。這些約束本質(zhì)上就是你在這個場景攢下來的領(lǐng)域經(jīng)驗。所以我現(xiàn)在每跑通一個新的場景類別都會單獨建一個模板文件夾里面存一份任務描述模板和一份校驗腳本模板。下次再遇到同類需求直接套模板改幾個參數(shù)就能跑建立場景的時間大幅縮短我把這個過程稱為場景資產(chǎn)化。這也是標題里適配所有場景的核心動力不是模型萬能而是模板庫越攢越多、越來越精。5.2 三種不適合硬套閉環(huán)的場景也得誠實說有些場景試過幾次后我就放棄了因為投入產(chǎn)出比太低。第一種強創(chuàng)意型任務。比如為產(chǎn)品想一個 slogan或者重新設計首頁視覺風格沒有客觀驗收標準改來改去都在憑感覺拉扯放進閉環(huán)只會得到一堆自動化的重試本質(zhì)上是浪費。第二種跨系統(tǒng)強依賴任務。如果改動需要同時操作線上數(shù)據(jù)庫、第三方接口和內(nèi)部權(quán)限系統(tǒng)風險太大任何一步出錯都可能是事故級別的這類場景我寧可人工慢慢做。第三種低頻且規(guī)則每回都變的場景。比如一個月來一次、每次業(yè)務規(guī)則還不一樣的需求光是編寫任務描述和校驗器的時間就已經(jīng)超過人工處理時間了閉環(huán)在這類場景里是純負債。5.3 給剛上手的三個調(diào)整建議如果你是剛接觸這類 agent 化編碼工具想直接把這套閉環(huán)用起來我給三個經(jīng)過實測的調(diào)整方向。第一先選確定性最高的場景試水比如批量為代碼文件補充注釋、統(tǒng)一文檔格式而不是一上來就處理敏感數(shù)據(jù)或高風險配置。先把閉環(huán)跑順、把失敗模式摸清再逐步加難度。第二每次失敗都要回到任務描述找原因而不是只在模型能力上找問題。我小半年的經(jīng)驗里十次失敗有八次是任務描述邊界不清怪模型只會讓你原地打轉(zhuǎn)。第三前期堅持人工看執(zhí)行計劃不要圖省事直接全自動。計劃確認環(huán)節(jié)不僅是在攔截錯誤也是在幫你積累這類任務會出哪些問題的手感積累到一定程度你再考慮用規(guī)則白名單的方式逐步放開。最后再分享一個小技巧給每個自動化任務單獨開一個 git 分支。不管任務多小改動多簡單都不要在主分支上直接跑。這樣就算 Codex 跑歪了你只需要刪除分支就能回到干凈狀態(tài)成本幾乎為零。我見過太多人因為這次改動很小省略這一步然后花一下午手工回滾。自動化跑得再快也不如安全的兜底重要。