原文鏈接AI 輔助編程實戰(zhàn)從需求邊界到可審查交付開發(fā)中最容易出現(xiàn)的誤解是只要把需求丟給 AI它就能交付一個功能。實際上AI 擅長整理上下文、生成候選方案、補全局部實現(xiàn)、解釋報錯和發(fā)現(xiàn)可疑點需求邊界、技術(shù)取舍、風險判斷、測試驗證與最終合并責任仍然必須由人承擔。下面用一個基于常見內(nèi)部系統(tǒng)改編的案例跑完整個閉環(huán)。它不是某個具體公司的真實項目復盤但保留了團隊開發(fā)中常見的權(quán)限、歷史數(shù)據(jù)、接口兼容、測試與代碼審查約束。案例給任務(wù)系統(tǒng)增加“批量歸檔”團隊已有一個任務(wù)系統(tǒng)。任務(wù)完成后不會立即刪除而是保留在“已完成”列表中。運營同學提出新需求當前項目的項目管理員可以一次選擇多條已完成任務(wù)并歸檔歸檔后默認任務(wù)列表不再展示但具備該項目歸檔查看權(quán)限的管理員可在歸檔列表中恢復。這句話還不能直接開始寫代碼因為它沒有明確權(quán)限范圍、狀態(tài)轉(zhuǎn)換、重復請求和返回結(jié)果。先把需求翻譯成可交付的邊界可以讓 AI 先做“需求質(zhì)檢員”復述已知條件列出歧義和潛在風險但最終規(guī)則必須由產(chǎn)品、開發(fā)或負責人確認。本例最終確認如下項目確認結(jié)果操作對象僅允許歸檔狀態(tài)為completed且尚未歸檔的任務(wù)操作權(quán)限只有當前項目的項目管理員可操作成員只能查看操作范圍單次最多歸檔 100 條且任務(wù)必須屬于當前項目數(shù)據(jù)策略不物理刪除寫入archivedAt、archivedBy冪等性已歸檔任務(wù)再次提交時不報錯、不重復寫入并返回可識別原因返回結(jié)果返回成功數(shù)、跳過數(shù)以及可安全披露的跳過原因非目標本期不做自動歸檔、跨項目批量操作和歸檔導出可驗收標準是管理員能歸檔本項目中符合條件的任務(wù)無權(quán)限用戶不能產(chǎn)生寫入未完成、已刪除、跨項目或不存在的任務(wù)不會被錯誤歸檔重復點擊不會產(chǎn)生重復副作用歸檔后默認列表、歸檔列表、分頁和篩選結(jié)果符合既有規(guī)則。**人機分工很明確**AI 可以幫助暴露問題人必須決定規(guī)則。規(guī)則沒有定下來再漂亮的代碼也只是把猜測固化進系統(tǒng)。第一步先拆“小變更”不要索要“一整個功能”本例可以拆成六個任務(wù)確認數(shù)據(jù)模型歸檔字段、恢復字段和必要索引。定義接口契約請求參數(shù)、響應(yīng)、錯誤和冪等行為。實現(xiàn)權(quán)限、項目歸屬和狀態(tài)校驗。實現(xiàn)批量更新并記錄操作者與時間。調(diào)整默認列表和歸檔列表查詢。補齊測試、變更說明、風險點和驗證結(jié)果?？梢砸?AI 每次只處理一個任務(wù)并固定返回修改哪些文件、依賴哪些假設(shè)、尚未覆蓋哪些場景、應(yīng)執(zhí)行哪些驗證命令。這樣得到的是一系列可追溯的候選變更而不是一大段難以審查的代碼。第二步讓 AI 比較方案而不是替你做架構(gòu)決定批量歸檔至少有兩種實現(xiàn)方式。方案 A逐條讀取并更新讀取任務(wù)、逐條校驗、逐條更新并匯總結(jié)果。優(yōu)點是失敗原因細缺點是數(shù)據(jù)庫往返次數(shù)多并且要明確部分成功時的事務(wù)語義。方案 B按條件批量更新再計算結(jié)果先驗證當前用戶是否為該項目管理員再用“項目 ID 任務(wù) ID 集合 已完成 未歸檔”的條件批量更新隨后根據(jù)影響行數(shù)和補充查詢計算成功、跳過結(jié)果。優(yōu)點是通常更高效缺點是要額外設(shè)計逐條原因的查詢和并發(fā)語義。本例選擇方案 B因為單次最多 100 條且只要求匯總級結(jié)果。需要注意僅憑updateMany的影響行數(shù)通常不能區(qū)分“不存在”“跨項目”“未完成”和“已歸檔”如果接口承諾逐條原因就必須補充受控查詢或調(diào)整接口契約。AI 可以比較復雜度、失敗模式和索引需求但事務(wù)邊界、ORM 能力、并發(fā)規(guī)則以及是否值得提前抽象必須由開發(fā)者結(jié)合現(xiàn)有代碼庫決定。為了一個歸檔功能新增通用規(guī)則引擎、事件總線或多層策略類可能只是過度設(shè)計。Google 的代碼審查實踐也強調(diào)應(yīng)優(yōu)先解決已經(jīng)明確存在的問題而不是為想象中的未來需求堆疊復雜度。第三步把接口寫成可驗證的契約POST /projects/:projectId/tasks/archive Content-Type: application/json { taskIds: [task_101, task_102, task_103] }成功響應(yīng)示例{ archivedCount: 2, skipped: [ { taskId: task_103, reason: ALREADY_ARCHIVED } ] }還要提前規(guī)定空數(shù)組、重復 ID、超過 100 條、無權(quán)限、跨項目、未完成、已刪除或不存在、數(shù)據(jù)庫失敗以及請求期間發(fā)生并發(fā)恢復或狀態(tài)修改時的行為。常見錯誤是只按 ID 更新遺漏projectId條件。權(quán)限、歸屬和狀態(tài)應(yīng)當同時出現(xiàn)在服務(wù)端的查詢或更新條件中而不能依賴前端傳參或 AI 的口頭保證。偽代碼可以接近const result await taskRepository.updateMany({ where: { id: { in: uniqueTaskIds }, projectId, status: completed, archivedAt: null }, data: { archivedAt: now, archivedBy: currentUser.id } });這段代碼仍不完整它沒有展示管理員身份驗證、參數(shù)校驗、錯誤映射、審計日志、逐條跳過原因和事務(wù)邊界。第四步讓 AI 寫局部代碼同時暴露假設(shè)較好的順序是先解釋倉庫中相似功能再草擬服務(wù)方法簽名人工確認接口和錯誤碼后實現(xiàn)最小更新邏輯最后生成測試骨架和審查建議。每一步都要求 AI 標出假設(shè)例如假設(shè)TaskRepository已有支持條件更新的updateMany方法權(quán)限中間件已保證登錄態(tài)未覆蓋并發(fā)恢復任務(wù)與歸檔請求同時發(fā)生的情形。假設(shè)清單能把隱蔽的模型幻覺變成可檢查項目。GitHub 對 AI 編程助手的說明也提醒模型建議不一定最優(yōu)或完整使用者仍需驗證輸出。第五步測試不是讓 AI“補幾個用例”測試應(yīng)從驗收標準反推?？梢韵冉⒕仃囋僮?AI 補充測試骨架、測試數(shù)據(jù)和反例測試維度關(guān)鍵場景預期結(jié)果正常路徑管理員歸檔 3 個已完成任務(wù)3 條被歸檔默認列表不再出現(xiàn)權(quán)限普通成員發(fā)起歸檔無權(quán)限且不產(chǎn)生寫入歸屬提交其他項目任務(wù) ID不更新并按契約返回跳過或拒絕狀態(tài)提交進行中的任務(wù)不歸檔并返回原因冪等已歸檔任務(wù)再次提交不重復寫入結(jié)果可解釋輸入校驗空數(shù)組、重復 ID、超過 100 條返回參數(shù)錯誤并發(fā)歸檔期間任務(wù)被恢復符合既定事務(wù)或條件更新約定查詢回歸默認列表、歸檔列表、分頁篩選舊功能不受影響失敗處理數(shù)據(jù)庫異?；虺瑫r返回統(tǒng)一錯誤不泄露內(nèi)部細節(jié)還可以讓 AI 扮演“反例生成器”如果刪除projectId條件哪條測試會失敗如果漏掉archivedAt: null重復請求會怎樣如果權(quán)限判斷放在批量更新之后數(shù)據(jù)會發(fā)生什么好的測試不只是“跑綠”還要確認錯誤實現(xiàn)確實會讓測試失敗。Google 的審查指南建議在同一變更中檢查生產(chǎn)代碼及相應(yīng)測試并確認斷言有效、不會產(chǎn)生假陽性。第六步用失敗的生成結(jié)果練習審查async archiveTasks(taskIds: string[]) { return this.taskRepository.updateMany({ where: { id: { in: taskIds } }, data: { archivedAt: new Date() } }); }這段代碼可能通過最簡單的成功測試但不能直接合并至少存在以下問題沒有權(quán)限校驗、項目歸屬限制、狀態(tài)限制、冪等約束、操作者審計字段和可解釋結(jié)果。它說明了一個關(guān)鍵現(xiàn)實局部答案“看起來合理”不等于符合業(yè)務(wù)、工程和安全約束。第七步把 AI 放進代碼審查但不要把審批權(quán)交給它提交 Pull Request 后可以讓 AI 總結(jié)改動、標出可疑空值路徑、檢查重復邏輯、解釋失敗流水線并提出候選問題但作者和人工評審者仍需判斷是否修復、是否符合倉庫約定以及是否可以合并。GitHub 相關(guān)文檔應(yīng)以當前產(chǎn)品能力和團隊權(quán)限配置為準不能把 AI 的評論當成人工批準。AI 輔助代碼審查清單正確性驗收標準、權(quán)限、項目歸屬、狀態(tài)、冪等和并發(fā)是否完整?？删S護性是否沿用既有分層、命名和錯誤處理是否引入不必要抽象。安全與隱私是否遺漏后端授權(quán)日志、提示詞和測試數(shù)據(jù)中是否包含密鑰、令牌、生產(chǎn)數(shù)據(jù)或個人信息代理是否采用最小權(quán)限高影響操作是否保留人工確認。性能與數(shù)據(jù)規(guī)模是否存在 N1 查詢條件字段是否需要索引批量大小和返回體是否合理。異常處理參數(shù)錯誤、無權(quán)限、狀態(tài)沖突和系統(tǒng)錯誤是否區(qū)分是否泄露內(nèi)部細節(jié)部分成功能否安全重試。測試覆蓋是否驗證數(shù)據(jù)庫最終狀態(tài)移除權(quán)限或歸屬條件時測試是否會失敗。項目一致性API、錯誤碼、日志、審計、文檔、接口定義和前端調(diào)用是否同步變更是否便于回滾。OWASP 關(guān)于具備代理能力的 LLM 應(yīng)用建議采用最小功能、最小權(quán)限和人工確認原則下游系統(tǒng)仍應(yīng)獨立完成授權(quán)校驗不能相信模型自行判斷權(quán)限。一頁式工作流每次讓 AI 參與開發(fā)都留下這些產(chǎn)物階段階段產(chǎn)物AI 可以做什么人必須確認什么通過條件需求澄清邊界、非目標、驗收標準、待確認問題復述需求、發(fā)現(xiàn)歧義業(yè)務(wù)規(guī)則與優(yōu)先級每條驗收標準可驗證任務(wù)拆解小任務(wù)清單、依賴關(guān)系、風險排序拆分技術(shù)任務(wù)、列遺漏項粒度與順序每項可獨立測試或?qū)彶榉桨冈O(shè)計接口契約、數(shù)據(jù)變化、方案對比比較路徑、生成草圖架構(gòu)取舍與兼容性符合現(xiàn)有約定局部編碼小范圍 Diff、假設(shè)清單編寫樣板、重構(gòu)局部邏輯業(yè)務(wù)條件、權(quán)限與異常靜態(tài)檢查和測試通過測試調(diào)試測試矩陣、復現(xiàn)步驟生成骨架、解釋報錯邊界和修復有效性錯誤可復現(xiàn)且修復通過代碼審查PR 描述、風險點、審查記錄總結(jié)改動、提出問題是否修復、是否合并人工審批和流水線通過最后的邊界AI 可以加速但不能替你交付AI 輔助編程的效率不是讓開發(fā)者少思考而是把重復整理、候選生成、代碼解釋和初步檢查交給工具讓人把時間集中在理解業(yè)務(wù)、做取舍、驗證結(jié)果和承擔責任上。真正的交付物不只是一段批量更新代碼而是一組可追溯證據(jù)明確的驗收標準、受約束的接口、可解釋的異常處理、覆蓋風險的測試、可審查的 Pull Request以及人工確認后的合并決定?？梢詮囊粋€原則開始每次讓 AI 生成或修改代碼都要求它說明上下文、假設(shè)、未覆蓋場景與驗證方式每次準備合并都由人用測試和審查把這些回答逐一驗真。參考資料GitHub DocsUsing GitHub Copilot to explore pull requestsGitHub DocsUsing GitHub Copilot code reviewGitHub DocsResponsible use of GitHub Copilot ChatGoogle Engineering PracticesWhat to look for in a code reviewNISTSecure Software Development FrameworkOWASPExcessive Agency