文章目錄一、能運行不代表正確二、AI 為什么會生成“看著對”的代碼1. 缺少業務上下文2. 使用了看似合理的 API3. 忽略了邊界條件4. 把示例代碼誤當成生產代碼三、一個典型的錯誤案例四、生成代碼后先檢查什么第一步重新閱讀需求第二步找出 AI 做的假設第三步準備最小測試集第四步檢查項目環境五、四種常見錯誤要重點防范1. 邏輯正確業務錯誤2. 正常數據正確異常數據出錯3. 本地可用項目中不可用4. 功能正確但存在安全問題六、讓 AI 幫你驗證而不是只讓它生成七、不要只看 AI 的解釋八、AI 生成代碼驗收清單總結?創作者全棧弄潮兒 個人主頁全棧弄潮兒的個人主頁? 個人社區歡迎你的加入全棧開發社區 專欄地址AI 編程提效實戰使用 AI 寫代碼時我們經常會遇到一種情況代碼格式很完整。變量命名看起來很規范。沒有明顯的語法錯誤。運行簡單示例也能得到結果。但是放到真實項目中卻出現了問題。這就是“看著對其實錯”。問題不一定是 AI 不會寫代碼而是 AI 給出的代碼通常基于已有信息進行推測。如果需求、項目上下文或驗證過程不完整代碼就可能與真實目標不一致。這篇文章重點解決一個問題AI 生成代碼后我們應該如何判斷它到底能不能用一、能運行不代表正確代碼的正確性至少包含四個層面檢查層面需要確認的問題語法代碼能不能被正確解析運行執行時會不會報錯邏輯結果是否符合業務規則工程是否安全、可維護、不會影響其他功能很多人只檢查了前兩項代碼沒有語法錯誤也可以正常運行。但真正容易出問題的往往是后兩項。例如一個計算折扣的函數即使能夠正常返回數字也不代表折扣計算一定正確。二、AI 為什么會生成“看著對”的代碼1. 缺少業務上下文同一個字段在不同項目中可能有不同含義。例如discount可能表示0.2代表打八折。20代表優惠 20%。2000代表優惠金額 2000 元。如果只告訴 AI“寫一個計算折扣的函數”它無法確定這個字段的真實含義只能按照常見寫法進行猜測。2. 使用了看似合理的 APIAI 可能會生成一個名稱合理的函數或者使用一個已經過時的 API。代碼看起來符合某個框架的風格但當前項目版本可能并不支持它。因此看到 AI 使用陌生方法時應該通過項目文檔、類型定義或官方文檔進行確認。3. 忽略了邊界條件AI 生成的代碼通常先滿足正常輸入。但真實項目還需要考慮空值。負數。0。最大值和最小值。小數精度。錯誤類型。重復操作。網絡或數據庫異常。如果沒有明確提出這些要求AI 可能不會主動完整處理。4. 把示例代碼誤當成生產代碼為了說明思路AI 有時會省略參數校驗。權限檢查。日志處理。錯誤處理。超時和重試。數據庫事務。示例代碼適合幫助我們理解方向但不能直接等同于可以上線的代碼。三、一個典型的錯誤案例假設業務需求是商品價格以元為單位。discount傳入整數百分比。discount: 20表示優惠 20%。折后價格不能小于 0。價格結果保留兩位小數。我們讓 AI 生成函數functioncalculateFinalPrice(price,discount){returnprice*(1-discount);}這段代碼看起來很簡潔但執行下面的代碼console.log(calculateFinalPrice(100,20));結果是-1900原因是代碼把20當成了20.0而不是20%。正確的計算方式應該先將百分比轉換成小數functioncalculateFinalPrice(price,discount){if(!Number.isFinite(price)||price0){thrownewError(price 必須是大于等于 0 的數字);}if(!Number.isFinite(discount)||discount0||discount100){thrownewError(discount 必須是 0 到 100 之間的數字);}constfinalPriceprice*(1-discount/100);returnNumber(finalPrice.toFixed(2));}這段代碼仍然需要根據項目實際規則進行確認但至少處理了幾個關鍵問題明確discount的單位是百分比。檢查價格和折扣是否為有效數字。防止折扣小于 0 或大于 100。對金額結果進行精度處理。這個例子說明AI 不一定寫錯了語法但可能理解錯了字段含義。四、生成代碼后先檢查什么第一步重新閱讀需求不要拿到代碼后馬上運行先對照需求檢查輸入參數的類型是否正確。字段單位是否正確。返回值是否符合約定。成功條件是否完整。失敗時應該如何處理。是否包含權限和安全要求。尤其要關注金額、時間、比例、狀態值和 ID 這類容易產生歧義的字段。第二步找出 AI 做的假設可以直接問 AI請列出你生成這段代碼時做出的所有假設。 重點檢查 1. 每個參數的類型和單位 2. 空值和異常值的處理方式 3. 時間、金額和比例的計算規則 4. 依賴的庫和版本 5. 權限和安全前提 不要修改代碼只列出假設和可能需要確認的問題。這一步很有用因為隱藏的假設往往就是錯誤的來源。第三步準備最小測試集至少準備四類輸入測試類型示例目的正常值價格 100折扣 20檢查主要流程邊界值折扣 0、100檢查最小和最大范圍異常值空值、字符串、負數檢查參數校驗極端值很大的價格和小數檢查精度和穩定性對應到前面的函數可以先寫出測試console.log(calculateFinalPrice(100,20));console.log(calculateFinalPrice(100,0));console.log(calculateFinalPrice(100,100));try{calculateFinalPrice(100,120);}catch(error){console.log(error.message);}預期結果應該是80 100 0 discount 必須是 0 到 100 之間的數字測試不是為了證明 AI 一定正確而是為了盡快暴露錯誤。第四步檢查項目環境代碼從單獨示例放進項目后還要確認使用的庫是否已經安裝。導入方式是否符合當前版本。項目是否使用 TypeScript 類型約束。返回格式是否符合現有接口。日志和錯誤處理是否符合項目規范。是否需要補充單元測試。如果 AI 使用了項目中不存在的函數或依賴不能為了讓代碼運行就隨意安裝新包。先確認項目是否已經有同類能力。五、四種常見錯誤要重點防范1. 邏輯正確業務錯誤代碼按照某種邏輯運行但不符合產品規則。例如把自然日當成工作日計算。把“優惠 20%”理解成“價格乘以 20%”。把訂單狀態1當成已完成但項目中1表示待支付。把用戶的本地時間當成服務器時間。這類問題只能通過需求、接口文檔和業務示例確認不能只看語法。2. 正常數據正確異常數據出錯例如搜索功能在輸入關鍵字時正常但輸入空字符串、特殊字符或超長字符串時發生異常。需要主動測試空字符串。只有空格的字符串。特殊字符。超長內容。不符合類型的參數。3. 本地可用項目中不可用常見原因包括AI 使用了錯誤的框架版本。本地示例依賴了未安裝的包。環境變量名稱不一致。接口字段與項目約定不同。沒有考慮真實的異步和權限流程。因此生成代碼后必須放回真實項目運行而不是只在獨立代碼片段中測試。4. 功能正確但存在安全問題代碼能實現功能不代表可以安全使用。需要重點檢查是否直接拼接 SQL。是否把用戶輸入插入 HTML。是否繞過權限校驗。是否返回密碼、Token 等敏感字段。是否把詳細服務器錯誤返回給用戶。是否將密鑰寫死在源代碼中。安全檢查應該單獨進行不要默認“功能測試通過就安全”。六、讓 AI 幫你驗證而不是只讓它生成可以使用下面這個 Prompt請不要直接修改下面的代碼先幫我驗證它是否符合需求。 需求 [粘貼完整需求和業務規則] 代碼 [粘貼代碼] 請按照以下順序輸出 1. 代碼當前實現了什么 2. 代碼做了哪些未經確認的假設 3. 與需求不一致的地方 4. 需要測試的正常、邊界和異常場景 5. 可能的安全風險 6. 仍然無法確定的問題 請為每個問題標注高、中或低優先級。 只有在我確認問題后再給出修改方案。七、不要只看 AI 的解釋AI 解釋代碼時可能非常流暢但流暢不等于準確。驗證答案時建議結合以下方式運行最小示例。查看項目類型定義。閱讀依賴庫官方文檔。搜索項目中已有的同類寫法。添加正常、邊界和異常測試。使用代碼審查工具檢查修改范圍。涉及核心邏輯時讓同事進行人工評審。對于金額、權限、支付、數據刪除和隱私相關代碼驗證標準應該更嚴格。八、AI 生成代碼驗收清單提交代碼前可以使用下面這份清單我能用自己的話解釋這段代碼。參數類型、單位和取值范圍已經確認。正常輸入已經測試。邊界輸入已經測試。異常輸入已經測試。依賴和 API 與當前項目版本一致。返回結果符合接口約定。沒有遺漏權限和安全校驗。沒有把示例代碼中的假數據帶進生產環境。已經運行項目現有測試。已經檢查本次修改的文件范圍。我知道這段代碼為什么這樣實現而不是只知道它能運行。如果最后一項無法確認說明這段代碼還不適合直接提交。總結AI 生成的代碼之所以會“看著對其實錯”常見原因有業務上下文不足。參數和字段含義存在歧義。使用了過時或不存在的 API。忽略邊界條件和異常處理。把示例代碼直接當成生產代碼。使用 AI 編程時不要只問“代碼能不能運行”還要繼續確認它是否符合需求是否覆蓋邊界是否適合當前項目是否安全可以記住一套簡單流程先讀需求 ↓ 確認假設 ↓ 運行最小示例 ↓ 測試邊界和異常 ↓ 檢查項目環境與安全 ↓ 再提交代碼AI 負責提高編碼速度開發者負責驗證結果是否真實可靠。下一篇文章將介紹《從零搭建你的 AI 編程工作流》?堅持原創求關注點贊收藏