廣東
當開發依賴AI生成的黑箱代碼在多租戶SaaS系統中引爆故障，當技術債以AI的速度積累，產品經理該如何在效率與風險間找到平衡？本文通過真實案例剖析AI編程的隱形陷阱，并提供一套從源頭治理的解決方案，幫助團隊在AI時代守住代碼質量的底線。
———— / BEGIN / ————
平臺上有不少文章在討論“產品經理要不要用AI寫PRD”，但我今天想聊的，是另一個更隱蔽也更棘手的問題：當你的開發在用AI寫代碼，而你對代碼質量開始失控時，該怎么辦？
需要說明的是，這不是在否定AI編程工具，更不是在指責所有用AI的開發——大多數開發使用AI是理性的、有判斷力的。但作為產品經理，我在日常協作中觀察到了一些值得警惕的現象，想分享出來，和大家一起探討。
“又延期了。”
這已經是這個版本第三次調整上線時間了。原因說起來有點諷刺——一個開發用AI寫了段代碼，單租戶跑得挺順，一上線就被多租戶的真實流量打垮，整個服務停了一上午。
那個開發事后自己也說不清代碼的核心邏輯是什么。他只是把需求“喂”給了AI，代碼能跑通，就提交了。
這是一個運行了多年的SaaS老系統，代碼庫里塞滿了十年來的業務邏輯和“特殊處理”。而AI編程工具，正在悄悄變成一個陷阱——看起來能提效，實際上正在往老系統里埋下一顆又一顆定時炸彈。
作為產品經理，我對最終結果負責，卻無法直接控制代碼的生產過程。眼睜睜看著質量下滑、節奏被打亂，卻有一種又著急又使不上力的感覺。
根源在哪？不是AI不行，而是我們從來沒有從源頭上為它劃定邊界。
0→1的浪漫與1→n的現實
AI編程工具的宣傳語總是很動人：十分鐘生成一個完整模塊，代碼質量堪比高級工程師。但很少有人告訴你，這些案例大多來自“從零開始”的項目。
在0→1的場景下，AI確實很強大。沒有歷史包袱，沒有復雜的業務邏輯嵌套，沒有十年前的遺留代碼需要兼容。AI可以在白紙上畫出漂亮的圖案。
但SaaS B端的老系統是什么樣？
代碼庫里既有架構師留下的優雅設計，也有實習生留下的“屎山”
業務邏輯經過無數次迭代，充滿了針對特定客戶場景的“特殊處理”
多租戶架構下，數據隔離、并發控制、資源競爭處處是坑
無數個“為什么這樣寫”的答案，藏在離職同事的腦海里
這樣的系統，不是一個能用“標準答案”應對的考場，而是一個充滿“例外”的復雜生態。AI的訓練數據來自通用場景，它不知道你們公司那張表里的某個字段為什么不能為空，也不理解那個看似無用的判斷是為了修補三年前的一次線上故障。
AI給出的，永遠是“平均的業務邏輯”，而不是“你們公司特有的業務邏輯”。
那些“順利上線”背后的隱形代價
部分依賴AI開發的代碼，在剛提交時看起來一切正常。功能跑通了，測試用例過了，順利上線了。所有人都覺得“效率真高”。
但問題往往在幾周或幾個月后集中爆發。
1. 代碼變成黑箱
傳統開發中，代碼是我們自己寫的，每一行都是思考的結果。遇到問題，我們知道從哪里下手排查。
AI生成的代碼則不同。它可能用了一種你不熟悉的寫法，調用了一個晦澀的API，采用了一種你沒見過的設計模式。當出現Bug時，開發者可能自己都看不懂這段代碼——只能把錯誤信息再扔回給AI，讓AI自己改自己寫的代碼。
這是一個“遞歸噩夢”：AI寫 → 人跑 → 報錯 → 人把報錯給AI → AI改 → 人再跑 → 循環往復。表面上看起來在“調試”，實際上是在消耗時間。
2. 修改成本飆升
老系統的特點是：代碼是寫給人看的，偶爾才給機器跑。 當一段代碼沒人真正理解時，后續的每一次修改都像拆雷。
我見過一個功能，AI寫完后運行正常。三個月后，產品需要在這個基礎上加一個小需求。開發研究了兩天，不敢動那部分AI生成的代碼——因為看不懂邏輯是怎么串聯的，不知道改了這處會不會讓另一處崩潰。最終，他選擇“重寫”，白白浪費了時間。
3. 多租戶延時爆炸
最可怕的問題，是在上線后才暴露的。
前面提到的那個“停擺一上午”的案例就是典型：AI寫的代碼在單租戶、低負載下毫無問題。但當多個租戶同時使用，數據量激增，并發請求涌來時，那個沒有考慮資源競爭、沒有做邊界檢查、沒有處理緩存的代碼，就像一顆埋在系統深處的定時炸彈。
這種問題，功能測試根本測不出來。只有真實的生產環境，才能讓它“爆炸”。
為什么“出問題再改”行不通？
很多人會說：出了問題改不就行了？
問題在于，在老系統中，這種“單點解決”的方式，正在積累更大的技術債。
每一次用AI生成代碼然后發現問題、再生成、再發現問題，都是在增加系統的混亂度。代碼庫變得越來越難以理解，維護成本越來越高，新人接手越來越困難。
更可怕的是，如果團隊習慣了這種模式，可能會出現能力空心化：開發人員不再需要理解業務邏輯、不再需要思考代碼結構、不再需要掌握調試技巧——反正AI會寫、會改、會解釋。
但當AI真的遇到AI無法解決的問題時，團隊可能已經沒有人能站出來了。
源頭治理：給AI使用劃定“安全區”
經歷了多次“延期-返工-故障”的循環后，我開始思考：問題出在哪里？
不是AI不能用，而是我們沒有給AI的使用劃定邊界。就像你不會讓實習生去改核心賬務系統一樣，你也不能讓AI去處理那些對業務至關重要的邏輯。
作為產品經理，我在推動團隊建立一套“源頭治理”的規則。核心思路是：在代碼被寫出來之前，就把風險攔住。
第一步：給代碼分等級
把系統里的功能按業務影響劃分等級，不同等級對應不同的AI使用規則：
第二步：給開發者設門檻
使用AI之前，開發人員應該能夠回答幾個問題：
這段代碼的核心邏輯是什么？（能不能用一句話講清楚）
它和我們現有的業務規則怎么對應的？（對應需求文檔哪一條）
如果數據量變成現在的10倍，它會出問題嗎？（有沒有考慮邊界）
多個人同時用，它會沖突嗎？（有沒有并發隱患）
如果這段代碼出問題，最壞情況是什么？（能不能承受）
如果一個開發答不上來，說明他可能沒有真正理解這段代碼在干什么。這個清單不需要技術多深，但需要動腦子。
第三步：讓理解“被看見”
建議開發在提交AI生成的代碼時，加注釋寫清楚“為什么這么寫”：
這個注釋的價值在于：倒逼開發去理解代碼；讓審查者能驗證理解是否正確；讓未來的維護者能看懂這段代碼。
第四步：用事故推動制度
當AI代碼出了問題，不做簡單歸咎，而是追問：
這段代碼屬于哪個等級？當時的規則允許用AI嗎？
如果允許，開發有沒有認真思考過那幾個核心問題？
如果不允許，為什么還會出現在代碼里？
這個過程不是為了追責，而是為了讓制度本身不斷迭代，也讓所有人意識到：AI代碼出問題，值得被認真追溯，而不是悄悄修復就完事。
特別提醒：如果你身處弱矩陣團隊，產品經理話語權有限，以上制度聽起來很理想，但在弱矩陣組織（如產品經理無考核權、技術團隊相對獨立）中，你可能無法直接推動。這時候可以嘗試：
借力：將風險包裝成“線上故障隱患”或“客戶投訴風險”，用業務視角說服技術負責人或上級。
找同盟：聯合測試負責人、質量架構師，他們同樣深受AI代碼不可控之苦。
小切口試點：選擇一兩個靠譜的開發，在非核心模塊試行分級規則，用實際效果證明價值。
向上管理：用一次真實事故（哪怕是預發環境的）作為案例，讓管理層意識到“不設規則的長期成本”。
不要試圖一步到位建立完整制度，哪怕只推動一條“AI代碼必須加注釋”的小規則，也是進展。
結語：AI是副駕駛，不是代駕
回到那個讓我思考這個問題的最初場景：那個導致停擺的開發，后來怎么樣了呢？
問題修復后，沒有人追究根源，沒有人反思流程，只是把這個故障當作一次“意外”。然后，下一段AI代碼，下一個開發，下一次延期，正在來的路上。
這就是為什么我要寫這篇文章。
AI編程工具確實強大，但它不會讓一個糟糕的流程變好，反而會加速它變得更糟。在老系統里，每一行AI生成的、無人理解的代碼，都是在給未來的自己埋雷。
我們需要的不是更聰明的AI，而是更清醒的人。AI可以寫代碼，但理解代碼、承擔責任、把控質量的，必須是人。
畢竟，代碼可以AI寫，但事故不能AI背。
本文來自公眾號：雨柒 作者：雨柒
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
