用 AI 改代碼這件事最常聽到的兩種說法是一種說“AI 能幫我把代碼寫得更優(yōu)雅”另一種說“AI 生成的東西根本不能用”。我實(shí)際跑過一段時(shí)間之后結(jié)論更偏中間AI 確實(shí)能把代碼改好但前提是你得把它當(dāng)成一個(gè)需要明確任務(wù)書的協(xié)作對(duì)象而不是一個(gè)丟一段代碼就能自動(dòng)優(yōu)化的黑盒工具。這篇文章不講概念講一套我自己一直在用的實(shí)操流程覆蓋代碼審查、局部重構(gòu)、補(bǔ)測(cè)試、批量調(diào)整、報(bào)錯(cuò)排查和 AI Agent 的邊界。適合正在用或準(zhǔn)備用 AI 編程工具的開發(fā)者看尤其是那些已經(jīng)過了“讓 AI 寫個(gè)爬蟲試試”的階段、想真正把 AI 嵌進(jìn)日常開發(fā)流程里的人。最值得關(guān)注的一點(diǎn)是AI 改代碼是否靠譜大概率不取決于模型選得多新而取決于你在交給它任務(wù)之前有沒有把上下文、約束、驗(yàn)證方式和驗(yàn)收標(biāo)準(zhǔn)交代清楚。下面按我從環(huán)境準(zhǔn)備到最終合入的真實(shí)順序拆開講。1. 先用一句話說清楚AI 改代碼到底改的是什么1.1 判斷代碼有沒有更好的三個(gè)維度先說“更好”的定義。不同場(chǎng)景里的“更好”完全不是一回事至少可以拆成三個(gè)維度。第一是可讀性。命名是否清楚函數(shù)是否過長(zhǎng)邏輯是否繞注釋是否解釋了“為什么”。這類改動(dòng) AI 做得最穩(wěn)因?yàn)樗恍枰斫鈽I(yè)務(wù)只需要遵循編碼習(xí)慣。第二是正確性。有沒有漏掉邊界條件異常路徑是否被吞掉狀態(tài)更新是否遺漏并發(fā)場(chǎng)景下是否存在競(jìng)態(tài)。這類改動(dòng) AI 能發(fā)現(xiàn)一部分但最終確認(rèn)必須由人來做。尤其是業(yè)務(wù)規(guī)則相關(guān)的正確性AI 沒有真實(shí)業(yè)務(wù)背景經(jīng)常會(huì)把“看起來合理”當(dāng)成“實(shí)際正確”。第三是可維護(hù)性。重復(fù)代碼是否被提取模塊邊界是否合理依賴方向是否正確新功能能否低成本加進(jìn)去。這一維度最難因?yàn)樯婕绊?xiàng)目歷史和團(tuán)隊(duì)約定AI 在單次對(duì)話里基本看不到全貌。所以結(jié)論很簡(jiǎn)單AI 最適合改第一類可以輔助第二類第三類要慎重。只要把任務(wù)落在這三個(gè)維度里AI 就不會(huì)變成“瞎優(yōu)化”。1.2 AI 擅長(zhǎng)什么不擅長(zhǎng)什么我把實(shí)際用下來比較穩(wěn)定的能力列一下。擅長(zhǎng)的事單個(gè)文件內(nèi)的局部重構(gòu)比如把一個(gè) 300 行的函數(shù)拆成幾個(gè)小函數(shù)。補(bǔ)充單元測(cè)試尤其是純函數(shù)、工具類、數(shù)據(jù)轉(zhuǎn)換這類輸入輸出明確的代碼。解釋陌生代碼生成調(diào)用關(guān)系說明。遵循已有的 lint 規(guī)則修代碼風(fēng)格問題。替換棄用 API 調(diào)用統(tǒng)一 import 路徑。定位明顯的空指針、未處理異常、變量作用域問題。不擅長(zhǎng)的事跨多個(gè)模塊甚至跨服務(wù)的架構(gòu)重構(gòu)。需要業(yè)務(wù)判斷的刪改比如“這個(gè)字段是否還需要保留”。真實(shí)性能問題AI 只能憑經(jīng)驗(yàn)猜不能替代壓測(cè)。安全邊界判斷尤其是涉及權(quán)限、認(rèn)證、敏感數(shù)據(jù)的代碼。保持“團(tuán)隊(duì)歷史風(fēng)格”的自覺性AI 很容易把局部代碼改得比全項(xiàng)目超前一個(gè)版本。這部分認(rèn)知很重要。你會(huì)發(fā)現(xiàn)凡是 AI 擅長(zhǎng)的都有一個(gè)共同點(diǎn)任務(wù)邊界清楚驗(yàn)收標(biāo)準(zhǔn)明確。凡是不擅長(zhǎng)的都需要大量項(xiàng)目上下文和人為經(jīng)驗(yàn)。因此工作流設(shè)計(jì)的目標(biāo)就是盡量把任務(wù)變成前者。2. 開始之前先把環(huán)境和工具鏈準(zhǔn)備好2.1 三類接入方式按場(chǎng)景選擇目前常見的接入方式大致有三類。不用糾結(jié)選哪個(gè)“最強(qiáng)”按任務(wù)類型選更合適。接入方式典型場(chǎng)景特點(diǎn)我常用的判斷IDE 內(nèi) AI 插件邊寫邊補(bǔ)全、代碼審查、快速解釋上下文自動(dòng)帶出操作輕量適合日常小改動(dòng)和學(xué)習(xí)命令行 AI 編程助手項(xiàng)目級(jí)重構(gòu)、批量任務(wù)、按指令改動(dòng)多個(gè)文件能讀整個(gè)項(xiàng)目結(jié)構(gòu)執(zhí)行鏈完整適合做單文件和批量改動(dòng)比如 Claude Code、OpenCode 這類工具直接調(diào)用 API沉淀成團(tuán)隊(duì)內(nèi)部工具、CI 集成、自動(dòng)化腳本可控性最強(qiáng)需要自己處理提示詞和上下文適合做成代碼審查機(jī)器人之類的固定流程我在日常開發(fā)里會(huì)用 IDE 插件做實(shí)時(shí)輔助用命令行 Agent 做稍大規(guī)模的改動(dòng)。兩類工具不沖突甚至可以串起來用先用 Agent 做批量調(diào)整再用 IDE 插件逐段 review。2.2 項(xiàng)目條件比工具數(shù)量重要不管用哪類工具項(xiàng)目本身必須滿足幾個(gè)前置條件否則 AI 給的改動(dòng)根本無法驗(yàn)證。第一代碼必須在版本管理里隨時(shí)能回滾。這是最硬的條件。沒有 git 這類版本管理工具AI 的一次大改動(dòng)就可能讓你丟失原有可用版本。我見過不止一次AI 重構(gòu)之后功能測(cè)試掛了最后全靠git checkout恢復(fù)。第二構(gòu)建和測(cè)試命令必須可復(fù)現(xiàn)。建議在項(xiàng)目根目錄寫清楚npm install npm run build npm testAI 工具在執(zhí)行改動(dòng)前通常會(huì)嘗試跑構(gòu)建和測(cè)試。如果命令本身在你的機(jī)器上都跑不通那 AI 在改動(dòng)后也無法判斷結(jié)果。所以要先保證一個(gè)干凈的基礎(chǔ)環(huán)境。第三AI 的改動(dòng)放在單獨(dú)分支里。不要直接在開發(fā)主干上讓 AI 折騰。獨(dú)立分支的好處是diff 歷史清晰出問題不影響其他人合入前還能再做一次完整檢查git checkout -b ai-refactor/xxx第四輸入文件要穩(wěn)定。編碼、換行符、生成文件路徑這些細(xì)節(jié)很容易被 AI 在重構(gòu)時(shí)順手改掉造成大量沒有意義的大 diff。2.3 常見報(bào)錯(cuò)先查 API Key 和環(huán)境變量AI 編程工具接入時(shí)報(bào)錯(cuò)最多的不是模型本身問題而是認(rèn)證和配置。我遇到過最典型的報(bào)錯(cuò)類似unexpected status 401 unauthorized: {code:api_key_required,message:api key required}這個(gè)報(bào)錯(cuò)基本不用懷疑代碼邏輯直接按順序檢查三件事。先看 API Key 是否真的配置了。很多工具通過環(huán)境變量讀取而不是直接寫在對(duì)話框里。確認(rèn)環(huán)境變量名是否和工具文檔完全一致echo $ANTHROPIC_API_KEY echo $OPENAI_API_KEY再看 Key 權(quán)限范圍。有的 Key 只允許訪問部分模型或部分接口權(quán)限不足也會(huì)返回 401 或 403?？梢栽诿钚欣锵劝l(fā)一個(gè)最小請(qǐng)求驗(yàn)證 Key 是否有效而不是直接跑完整項(xiàng)目。最后看請(qǐng)求是否真的帶上了認(rèn)證頭。有些代理配置、腳本封裝、自定義命令行工具會(huì)在轉(zhuǎn)發(fā)請(qǐng)求時(shí)把 Header 丟掉導(dǎo)致服務(wù)端識(shí)別不到身份。遇到 401 先查 Key 和環(huán)境變量不要急著換工具或重裝。能把日志完整讀一遍的人問題已經(jīng)解決一半。3. 一套能落地的 AI 改代碼工作流3.1 先讓 AI 解釋代碼不急著讓它改拿到一段要改的代碼最忌諱的操作是上來就發(fā)一句“幫我優(yōu)化這段代碼”。因?yàn)?AI 沒有和你共享思維它不知道這段代碼在業(yè)務(wù)里扮演什么角色也不知道哪些邊界必須保留。我的做法是先讓它用人類語言復(fù)述代碼邏輯。可以這樣問請(qǐng)先解釋這個(gè)函數(shù)做了什么。輸入是什么輸出是什么有哪些副作用函數(shù)被哪些地方調(diào)用這一步有三個(gè)作用。一是驗(yàn)證 AI 是否真的理解代碼。如果它把核心邏輯說錯(cuò)了那后續(xù)任何改動(dòng)都不可信這時(shí)候應(yīng)該換更小的上下文或者換提問方式。二是讓 AI 在回答過程中建立起對(duì)代碼的“心理模型”。后續(xù)讓它改代碼時(shí)它會(huì)更傾向于保留原始行為。三是你自己也能借這個(gè)過程重新整理一遍代碼邏輯。很多時(shí)候代碼寫久了你以為自己知道它干嘛真讓你講一遍反而講不清楚。3.2 單文件、小目標(biāo)做可回滾的局部重構(gòu)通過解釋驗(yàn)證沒問題之后再進(jìn)入修改階段。第一原則是單文件、小目標(biāo)。比如一個(gè)文件里有兩個(gè)重復(fù)的函數(shù)目標(biāo)是“抽取公共函數(shù)”。動(dòng)作就只做這一件不要同時(shí)改命名、加注釋、換格式、調(diào)日志。每多一類改動(dòng)review 成本就指數(shù)上升而且出了問題很難定位是哪一步引入的。具體步驟可以這樣選定一個(gè)文件先完整理解邏輯。告訴 AI 只改這個(gè)文件只解決一個(gè)明確問題。讓 AI 給出 diff而不是整個(gè)文件重寫。把 diff 應(yīng)用到代碼跑構(gòu)建和測(cè)試。確認(rèn)通過之后再進(jìn)入下一個(gè)文件或下一個(gè)問題。diff 比全量代碼好 review 得多。我看代碼合入時(shí)幾乎不看 AI 重寫的整個(gè)文件只看它實(shí)際改動(dòng)了哪些行。3.3 補(bǔ)測(cè)試優(yōu)先于改邏輯對(duì)有測(cè)試覆蓋的項(xiàng)目我強(qiáng)烈建議一個(gè)順序先讓 AI 基于當(dāng)前行為補(bǔ)測(cè)試再根據(jù)測(cè)試結(jié)果決定是否修邏輯。原因是AI 直接改邏輯時(shí)很容易把一個(gè)“應(yīng)該被修復(fù)的問題”和“當(dāng)前系統(tǒng)依賴的行為”一起改掉。測(cè)試的作用就是先把當(dāng)前行為凍結(jié)住。具體操作請(qǐng)為這個(gè)模塊補(bǔ)充單元測(cè)試。測(cè)試范圍正常輸入、邊界輸入、異常輸入。不要修改被測(cè)代碼。然后運(yùn)行測(cè)試。如果測(cè)試全部通過說明當(dāng)前代碼行為和你預(yù)期的行為一致那就不需要?jiǎng)舆壿嬜疃嘧鲋貥?gòu)。如果有些測(cè)試跑紅了說明當(dāng)前行為和你預(yù)期不一致。這時(shí)候讓 AI 看測(cè)試失敗信息再?zèng)Q定動(dòng)哪個(gè)位置的代碼。這個(gè)流程可以把“AI 改壞了”的概率壓到很低因?yàn)槟阆榷x了行為再允許它調(diào)整實(shí)現(xiàn)。3.4 批量任務(wù)要按“單一改動(dòng)類型”拆分到了批量場(chǎng)景任務(wù)拆分比單文件重要得多。我見過一個(gè)團(tuán)隊(duì)讓 AI 一次性做四件事統(tǒng)一命名風(fēng)格、加類型標(biāo)注、修所有 lint 警告、把 Promise 改成 async/await。最后 diff 大到?jīng)]法 review而且四個(gè)目標(biāo)之間互相干擾。正確做法是每一輪只處理一類改動(dòng)第一輪統(tǒng)一命名規(guī)范。第二輪補(bǔ)類型標(biāo)注。第三輪修 lint 警告。第四輪換異步寫法。每一輪單獨(dú)提交單獨(dú)跑測(cè)試。這樣做的好處是如果你的測(cè)試覆蓋足夠某一輪出了問題可以直接回滾這一輪提交不影響其他已經(jīng)完成的工作。批量任務(wù)還要特別注意輸出命名。AI 在處理多個(gè)文件時(shí)很容易生成臨時(shí)文件、備份文件或者把原有文件覆蓋到錯(cuò)誤位置。批量跑之前一定要在獨(dú)立分支里操作并且設(shè)置明確的輸出目錄和命名規(guī)則。4. 提示詞怎么組織AI 才不瞎改4.1 有效提示詞的四個(gè)要素我把這些年摸索出來的提示詞套路總結(jié)成四個(gè)要素。上下文。告訴 AI 它正在處理什么項(xiàng)目、什么語言、什么框架代碼路徑是什么。不要只丟一個(gè)函數(shù)片段就讓它猜整個(gè)項(xiàng)目。約束。明確告訴 AI 哪些不能動(dòng)。常見約束包括公共接口不能變、外部依賴不能換、不要引入新的設(shè)計(jì)模式、只修改指定文件。驗(yàn)證方式。告訴 AI 改完代碼后可以用什么命令驗(yàn)證結(jié)果的正確性。這會(huì)讓 AI 在改動(dòng)時(shí)自動(dòng)避開容易破壞測(cè)試的方案。輸出格式。要求 AI 按一定格式輸出比如先說明問題再給出 diff再解釋每處改動(dòng)理由。這樣不容易把“無用改動(dòng)”混在“必要改動(dòng)”里。4.2 一個(gè)可直接改用的代碼審查提示詞示例下面是我比較常用的一個(gè)審查提示詞你可以根據(jù)項(xiàng)目情況改你是這個(gè)項(xiàng)目的資深開發(fā)者。請(qǐng)對(duì)一個(gè)函數(shù)做保守的代碼審查。 第一步解釋這個(gè)函數(shù)現(xiàn)在做了什么包括輸入、輸出和副作用。 第二步列出潛在問題按嚴(yán)重程度排序嚴(yán)重、一般、輕微。 第三步對(duì)每個(gè)問題給出最小改動(dòng)建議。不要重寫整個(gè)函數(shù)不要改變對(duì)外行為不要引入新的抽象。 輸出格式 1. 函數(shù)行為說明 2. 問題列表 3. 最小改動(dòng)方案這個(gè)提示詞的關(guān)鍵詞是“保守”和“最小改動(dòng)”。沒有這兩個(gè)詞AI 很容易進(jìn)入創(chuàng)作模式把簡(jiǎn)單函數(shù)重構(gòu)成你覺得高深但項(xiàng)目里沒人能維護(hù)的代碼。4.3 模糊指令是代碼變?cè)愀獾母础皫臀覂?yōu)化一下”“讓這段代碼更好”“代碼不夠優(yōu)雅幫我改進(jìn)一下”——這類模糊指令是 AI 把代碼改壞的最大原因。為什么因?yàn)椤皟?yōu)化”沒有度量標(biāo)準(zhǔn)。AI 只能猜測(cè)你想要的優(yōu)化方向。它可能把循環(huán)改成 map你可能根本不想引入函數(shù)式寫法它可能把多個(gè)參數(shù)封裝成對(duì)象你反而覺得這樣調(diào)用更啰嗦。所以每次提需求之前先問自己一個(gè)問題這次改動(dòng)的驗(yàn)收標(biāo)準(zhǔn)是什么驗(yàn)收標(biāo)準(zhǔn)是“函數(shù)能從 300 行拆成 80 行以內(nèi)”那任務(wù)清晰。驗(yàn)收標(biāo)準(zhǔn)是“代碼看起來更高級(jí)”那任務(wù)不清晰請(qǐng)先別讓 AI 動(dòng)手。清晰的任務(wù)描述才可能得到穩(wěn)定的輸出。模糊的任務(wù)描述只會(huì)得到隨機(jī)的代碼改動(dòng)。提示詞里出現(xiàn)“提高”“優(yōu)化”“增強(qiáng)”這類詞時(shí)建議同時(shí)把“但仍然保持”的約束寫清楚。沒有約束的優(yōu)化等于讓 AI 自由發(fā)揮。5. 驗(yàn)證 AI 改完的代碼不能只看能不能跑5.1 先逐行看 diff再?zèng)Q定是否合入AI 說你改好了不等于代碼真的改好了。我合入 AI 改動(dòng)前做的第一件事永遠(yuǎn)是看 diff。git diff看 diff 時(shí)重點(diǎn)看三類內(nèi)容一是被刪除的代碼。AI 特別喜歡把一些看起來沒用的 catch 塊、空注釋、舊分支刪掉。這些代碼里有些確實(shí)沒用有些是歷史遺留的防御邏輯。刪除之前必須確認(rèn)真的沒有副作用。二是被新增的抽象層。AI 對(duì)“封裝”有天然沖動(dòng)動(dòng)不動(dòng)就新增一個(gè)中間層、基類、工廠函數(shù)。如果項(xiàng)目里沒有這個(gè)習(xí)慣建議讓它用最直接的方式寫。三是測(cè)試文件的改動(dòng)。如果一次重構(gòu)里測(cè)試文件也發(fā)生了大量修改要特別警惕。正常重構(gòu)應(yīng)該保持測(cè)試行為不變測(cè)試被大面積修改說明實(shí)現(xiàn)行為可能變了或者 AI 為了通過測(cè)試調(diào)整了斷言標(biāo)準(zhǔn)。5.2 測(cè)試通過不等于改得對(duì)只要項(xiàng)目測(cè)試覆蓋足夠測(cè)試通過是基本要求。但測(cè)試通過并不代表改動(dòng)就是對(duì)的。我一般會(huì)在測(cè)試通過之后做三輪補(bǔ)充檢查。第一輪是類型檢查。如果有 TypeScript、MyPy、Flow 這類工具一定要跑一遍。AI 改代碼時(shí)很容易留下隱式 any、動(dòng)態(tài)屬性或者把類型定義改寬了。npx tsc --noEmit第二輪是 lint。AI 寫的代碼可能風(fēng)格一致但不一定滿足項(xiàng)目的 lint 規(guī)則。跑一遍 lint 能過濾掉大量低級(jí)問題。第三輪是手工驗(yàn)證關(guān)鍵路徑。挑一個(gè)和這次改動(dòng)關(guān)系最緊密的用戶場(chǎng)景手動(dòng)跑一遍。比如你改的是登錄模塊就至少跑一遍登錄成功和登錄失敗兩個(gè)場(chǎng)景。5.3 三個(gè)很容易被 AI 改動(dòng)帶偏的坑第一個(gè)坑是形式主義重構(gòu)。AI 把代碼拆得很漂亮注釋、命名、空行都很規(guī)范但核心邏輯完全沒變甚至比以前更繞。驗(yàn)收時(shí)不要只看結(jié)構(gòu)一定在腦子里過一遍改動(dòng)前后行為是否一致。第二個(gè)坑是過度設(shè)計(jì)。AI 會(huì)為了“可擴(kuò)展性”引入將來用不到的配置項(xiàng)、策略模式、插件機(jī)制。如果項(xiàng)目當(dāng)前只有一種場(chǎng)景這些抽象就是負(fù)擔(dān)。約束里可以直接寫不引入新的設(shè)計(jì)模式不為不存在的需求預(yù)留抽象。第三個(gè)坑是自我證明幻覺。AI 在解釋自己改動(dòng)時(shí)往往會(huì)用非?？隙ǖ恼Z氣描述“這次修復(fù)解決了某問題”但代碼未必真的處理了根因。要拿日志、斷點(diǎn)、測(cè)試斷言去驗(yàn)證而不是信它的總結(jié)。6. 從單文件到全項(xiàng)目AI Agent 的用法與邊界6.1 適合交給 Agent 的批量任務(wù)隨著命令行 AI 編程助手這類工具越來越成熟很多人開始把整項(xiàng)目交給 Agent 處理。這里有一個(gè)很重要的判斷邊界有些任務(wù)適合有些任務(wù)絕對(duì)不能適合。我目前愿意交給 Agent 批量執(zhí)行的任務(wù)包括統(tǒng)一替換舊 API。比如某個(gè)第三方庫發(fā)布了新版本舊函數(shù)全部標(biāo)記 deprecated可以讓 Agent 在項(xiàng)目里自動(dòng)替換。補(bǔ)類型標(biāo)注。給 JavaScript 項(xiàng)目遷移 TypeScript 時(shí)先讓 Agent 給變量、函數(shù)簽名、模塊導(dǎo)出補(bǔ)上基礎(chǔ)類型。批量生成單元測(cè)試。對(duì)輸入輸出清楚的工具函數(shù)Agent 可以用很高的效率生成測(cè)試用例。清理 lint 警告。從項(xiàng)目根目錄跑一次 lint把報(bào)告里的警告按類型分組分批讓 Agent 處理。整理 TODO 注釋并生成問題清單。這些任務(wù)的共同點(diǎn)是規(guī)則統(tǒng)一、目標(biāo)明確、驗(yàn)證容易。Agent 每次改動(dòng)之后只要有完整的測(cè)試可以跑就能確認(rèn)是否引入回歸。6.2 不適合交給 Agent 的敏感任務(wù)反過來這些任務(wù)我堅(jiān)決不讓 Agent 直接執(zhí)行架構(gòu)級(jí)重構(gòu)。比如把單體拆成微服務(wù)或者把核心模塊的數(shù)據(jù)流方向改掉。這種任務(wù)需要大量業(yè)務(wù)上下文和架構(gòu)判斷Agent 沒有能力也不該負(fù)責(zé)。安全相關(guān)改動(dòng)。權(quán)限模型、認(rèn)證邏輯、支付流程、敏感數(shù)據(jù)脫敏這些代碼可以輔助分析但不準(zhǔn)直接自動(dòng)改寫。需要真實(shí)用戶反饋的交互流程。比如 UI 狀態(tài)的變更、表單校驗(yàn)規(guī)則如果只看代碼AI 可能覺得沒問題但真實(shí)用戶會(huì)感知到差異。涉及數(shù)據(jù)遷移的修改。刪字段、改表結(jié)構(gòu)、改緩存 key這類改動(dòng)一旦出錯(cuò)恢復(fù)成本很高。必須由人設(shè)計(jì)遷移方案AI 只負(fù)責(zé)執(zhí)行它那部分。6.3 用 Agent 之前先畫安全護(hù)欄在讓 Agent 真正動(dòng)項(xiàng)目之前我會(huì)先做幾件事。第一確認(rèn)初始 git 狀態(tài)是干凈的所有已有改動(dòng)都提交到分支上。第二明確 Agent 的工作目錄和可修改文件范圍。不要讓 Agent 隨意在項(xiàng)目根目錄自由發(fā)揮。第三檢查 Agent 可能會(huì)執(zhí)行的命令。很多命令行 Agent 會(huì)自動(dòng)安裝依賴、運(yùn)行腳本、調(diào)用外部 API。如果它提出的命令里包含 curl 下載文件、繞過某些檢查、修改權(quán)限之類的內(nèi)容我會(huì)手動(dòng)拒絕并重新評(píng)估。一個(gè)很通用的安全提醒是不要往終端或開發(fā)者工具里粘貼你不理解的代碼。這套邏輯現(xiàn)在同樣適用于 AI 編程——AI 給你的命令如果看不懂它做了什么就不要直接執(zhí)行。Agent 輔助編程時(shí)角色應(yīng)該是“執(zhí)行者”而不是“決策者”。決策權(quán)必須在你手里。7. 我踩過的坑和現(xiàn)在的使用習(xí)慣7.1 三個(gè)典型翻車場(chǎng)景翻車場(chǎng)景一過度抽象。有一次清理一個(gè)訂單狀態(tài)判斷函數(shù)我給 AI 的指令是“減少重復(fù)代碼”。結(jié)果 AI 把函數(shù)重構(gòu)成三個(gè)抽象層加了策略模式和狀態(tài)映射表。邏輯確實(shí)變復(fù)雜了但業(yè)務(wù)可讀性顯著下降最后我放棄了這次改動(dòng)。后來我意識(shí)到重復(fù)代碼有時(shí)是合理重復(fù)尤其當(dāng)幾處邏輯未來會(huì)朝不同方向演化時(shí)強(qiáng)行合并反而增加耦合。翻車場(chǎng)景二刪除“無用”代碼。某個(gè)歷史遺留的錯(cuò)誤處理分支AI 判斷它永遠(yuǎn)不會(huì)執(zhí)行順手刪掉了。結(jié)果三個(gè)月后一個(gè)極端輸入觸發(fā)了空指針。這類問題在代碼審查時(shí)很難發(fā)現(xiàn)因?yàn)閯h除動(dòng)作看起來很小。我的規(guī)避方式是所有“刪除冗余代碼”類的請(qǐng)求我都會(huì)單獨(dú)標(biāo)注“如果這塊代碼的作用不明確先不要?jiǎng)h標(biāo)記出來由我決定”。翻車場(chǎng)景三測(cè)試全綠但核心路徑?jīng)]覆蓋。AI 給一個(gè)文件生成了 20 個(gè)測(cè)試用例全部通過我差點(diǎn)直接合入。后來手工看覆蓋率才發(fā)現(xiàn)核心的高風(fēng)險(xiǎn)分支根本沒被測(cè)試到。它生成的全是簡(jiǎn)單路徑測(cè)試。從那以后我只看“測(cè)試覆蓋了哪些分支”不再看“測(cè)試數(shù)量多不多”。7.2 現(xiàn)在的工作流和判斷標(biāo)準(zhǔn)踩過這些坑之后我現(xiàn)在的使用習(xí)慣穩(wěn)定成一套固定流程。第一步給 AI 不超過一個(gè)文件的任務(wù)目標(biāo)是生成可驗(yàn)證的結(jié)果。第二步先讓 AI 解釋和列出改動(dòng)計(jì)劃我確認(rèn)方向后再讓它動(dòng)代碼。第三步所有改動(dòng)都必須給出 diff不允許直接覆蓋整個(gè)文件。第四步跑構(gòu)建、測(cè)試、類型檢查、lint四關(guān)全過才考慮 review。第五步親手跑一遍關(guān)鍵業(yè)務(wù)路徑。第六步合入前看最終 diff確認(rèn)沒有任何多余改動(dòng)。這套流程看起來笨但效率其實(shí)最高。因?yàn)樗衙看?AI 改動(dòng)的風(fēng)險(xiǎn)控制在一個(gè)小范圍內(nèi)真出問題也容易定位和回滾。7.3 適合哪些人用不適合哪些人用最后說適用人群。適合用 AI 改代碼的人至少要能讀懂 AI 的改動(dòng)。你不一定要成為精通 AI 的工具玩家但你必須能看懂 diff能判斷邏輯是否被改變。這也意味著 AI 改代碼的理想使用者是已經(jīng)具備一定開發(fā)經(jīng)驗(yàn)的工程師而不是完全不懂編程、只想讓 AI 自動(dòng)生成項(xiàng)目的門外漢。不適合的人包括項(xiàng)目本身沒有版本管理和測(cè)試改完也不知道是不是壞了。完全不會(huì) review 代碼只能全盤相信 AI 輸出。預(yù)期是“丟一個(gè)需求進(jìn)去自動(dòng)得到完整項(xiàng)目”的人。團(tuán)隊(duì)里沒有人工 review 機(jī)制AI 改動(dòng)可以直接上生產(chǎn)環(huán)境。AI 在代碼上的真正價(jià)值是幫有判斷力的人把重復(fù)勞動(dòng)吃掉而不是代替人做判斷。我現(xiàn)在的日常狀態(tài)是AI 負(fù)責(zé)把代碼問題暴露出來做批量改動(dòng)生成測(cè)試和文檔我負(fù)責(zé)看 diff、跑關(guān)鍵路徑、做業(yè)務(wù)決策。這套配合穩(wěn)定下來之后代碼質(zhì)量確實(shí)在往上走。如果你打算開始嘗試我建議不要從“讓 AI 重構(gòu)整個(gè)項(xiàng)目”開始先找一個(gè)小文件、一類問題、一次提交把最小閉環(huán)跑通。這個(gè)流程一旦熟練再逐步擴(kuò)大到更復(fù)雜的任務(wù)會(huì)踏實(shí)很多。