AI 生成程式碼的風險，不在模型，在缺乏自審
AI 生成程式碼的風險不在於模型本身，而在於缺乏自審機制。建立分層的驗證流程，比等待更聰明的模型更實際。
問題不是 AI 寫得爛
我們常把 AI 生成程式碼的風險歸咎於模型本身——hallucination、邏輯錯誤、不符合業務邏輯。但這樣想其實把焦點放錯了。
真正的風險是：開發者拿到程式碼後，沒有能力或沒有機制去驗證它。這不是 AI 的問題，是整個工作流程的問題。
自審機制的三個層次
我在想，如果 AI 生成的程式碼能自己檢查自己，會怎樣。
第一層：語法和型別檢查。這個簡單，linter 和編譯器已經做了。但大多數開發者只是讓 CI/CD 跑過去就算完事。
第二層：邏輯一致性檢查。程式碼寫出來了，但它有沒有真的解決原問題？這需要 AI 回過頭來看一遍自己的輸出，對照原需求。我見過的 LLM 應用很少做這個。
第三層：隱藏假設的曝光。AI 生成的程式碼往往包含開發者沒想到的假設——比如對輸入格式的假設、對外部服務可用性的假設。自審機制應該把這些假設列出來，讓人類決定是否接受。
為什麼這比升級模型更實際
等 Claude 或 GPT 下一版本會更聰明，這個思路沒錯。但如果現在你的工作流程本身就沒有驗證機制，換再聰明的模型也只是把爛程式碼變成「看起來更合理的爛程式碼」。
自審機制的好處是：它對所有模型都有效。你用 Llama、Claude 還是 GPT，只要 AI 能用自然語言解釋自己的決定，就能被檢查。
而且，這個機制是可以漸進式建立的。不需要一次到位。先從「AI 生成完程式碼後，寫一段說明這段程式碼做了什麼」開始。然後加上「列出所有你做的假設」。再加上「這段程式碼有什麼邊界情況你沒考慮」。
我現在的做法
在公司的 AI PoC 裡，我開始要求生成程式碼的時候附帶一個「檢查清單」。不是我去檢查，是 AI 自己生成這個清單，然後我們用這個清單去 review。
效果怎樣？比起直接看程式碼，能早一步發現邏輯問題。不是全部，但足夠降低風險。
關鍵是：這個做法的成本很低。只是改變了 prompt 的方式，沒有改變工具鏈。
還有什麼不確定
我不知道這個機制對多複雜的程式碼還有效。現在試的都是幾百行的東西。如果是上千行的系統，AI 的自審能力會不會崩潰？這個還要驗證。
另外，如果 AI 自審的邏輯本身也有偏差，那就成了「盲人領盲人」。這時候人類的角色就更重要了——你需要知道什麼時候信 AI 的自審，什麼時候不信。
但無論如何，比起被動地接受 AI 的輸出，主動建立驗證機制總是更好的選擇。
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。