當開發(fā)依賴AI生成的黑箱代碼在多租戶SaaS系統(tǒng)中引爆故障，當技術(shù)債以AI的速度積累，產(chǎn)品經(jīng)理該如何在效率與風險間找到平衡？本文通過真實案例剖析AI編程的隱形陷阱，并提供一套從源頭治理的解決方案，幫助團隊在AI時代守住代碼質(zhì)量的底線。

———— / BEGIN / ————

平臺上有不少文章在討論“產(chǎn)品經(jīng)理要不要用AI寫PRD”，但我今天想聊的，是另一個更隱蔽也更棘手的問題：當你的開發(fā)在用AI寫代碼，而你對代碼質(zhì)量開始失控時，該怎么辦？

需要說明的是，這不是在否定AI編程工具，更不是在指責所有用AI的開發(fā)——大多數(shù)開發(fā)使用AI是理性的、有判斷力的。但作為產(chǎn)品經(jīng)理，我在日常協(xié)作中觀察到了一些值得警惕的現(xiàn)象，想分享出來，和大家一起探討。

“又延期了?！?/p>

這已經(jīng)是這個版本第三次調(diào)整上線時間了。原因說起來有點諷刺——一個開發(fā)用AI寫了段代碼，單租戶跑得挺順，一上線就被多租戶的真實流量打垮，整個服務停了一上午。

那個開發(fā)事后自己也說不清代碼的核心邏輯是什么。他只是把需求“喂”給了AI，代碼能跑通，就提交了。

這是一個運行了多年的SaaS老系統(tǒng)，代碼庫里塞滿了十年來的業(yè)務邏輯和“特殊處理”。而AI編程工具，正在悄悄變成一個陷阱——看起來能提效，實際上正在往老系統(tǒng)里埋下一顆又一顆定時炸彈。

作為產(chǎn)品經(jīng)理，我對最終結(jié)果負責，卻無法直接控制代碼的生產(chǎn)過程。眼睜睜看著質(zhì)量下滑、節(jié)奏被打亂，卻有一種又著急又使不上力的感覺。

根源在哪？不是AI不行，而是我們從來沒有從源頭上為它劃定邊界。

0→1的浪漫與1→n的現(xiàn)實

AI編程工具的宣傳語總是很動人：十分鐘生成一個完整模塊，代碼質(zhì)量堪比高級工程師。但很少有人告訴你，這些案例大多來自“從零開始”的項目。

在0→1的場景下，AI確實很強大。沒有歷史包袱，沒有復雜的業(yè)務邏輯嵌套，沒有十年前的遺留代碼需要兼容。AI可以在白紙上畫出漂亮的圖案。

但SaaS B端的老系統(tǒng)是什么樣？

• 代碼庫里既有架構(gòu)師留下的優(yōu)雅設計，也有實習生留下的“屎山”

• 業(yè)務邏輯經(jīng)過無數(shù)次迭代，充滿了針對特定客戶場景的“特殊處理”

• 多租戶架構(gòu)下，數(shù)據(jù)隔離、并發(fā)控制、資源競爭處處是坑

• 無數(shù)個“為什么這樣寫”的答案，藏在離職同事的腦海里

這樣的系統(tǒng)，不是一個能用“標準答案”應對的考場，而是一個充滿“例外”的復雜生態(tài)。AI的訓練數(shù)據(jù)來自通用場景，它不知道你們公司那張表里的某個字段為什么不能為空，也不理解那個看似無用的判斷是為了修補三年前的一次線上故障。

AI給出的，永遠是“平均的業(yè)務邏輯”，而不是“你們公司特有的業(yè)務邏輯”。

那些“順利上線”背后的隱形代價

部分依賴AI開發(fā)的代碼，在剛提交時看起來一切正常。功能跑通了，測試用例過了，順利上線了。所有人都覺得“效率真高”。

但問題往往在幾周或幾個月后集中爆發(fā)。

1. 代碼變成黑箱

傳統(tǒng)開發(fā)中，代碼是我們自己寫的，每一行都是思考的結(jié)果。遇到問題，我們知道從哪里下手排查。

AI生成的代碼則不同。它可能用了一種你不熟悉的寫法，調(diào)用了一個晦澀的API，采用了一種你沒見過的設計模式。當出現(xiàn)Bug時，開發(fā)者可能自己都看不懂這段代碼——只能把錯誤信息再扔回給AI，讓AI自己改自己寫的代碼。

這是一個“遞歸噩夢”：AI寫 → 人跑 → 報錯 → 人把報錯給AI → AI改 → 人再跑 → 循環(huán)往復。表面上看起來在“調(diào)試”，實際上是在消耗時間。

2. 修改成本飆升

老系統(tǒng)的特點是：代碼是寫給人看的，偶爾才給機器跑。 當一段代碼沒人真正理解時，后續(xù)的每一次修改都像拆雷。

我見過一個功能，AI寫完后運行正常。三個月后，產(chǎn)品需要在這個基礎上加一個小需求。開發(fā)研究了兩天，不敢動那部分AI生成的代碼——因為看不懂邏輯是怎么串聯(lián)的，不知道改了這處會不會讓另一處崩潰。最終，他選擇“重寫”，白白浪費了時間。

3. 多租戶延時爆炸

最可怕的問題，是在上線后才暴露的。

前面提到的那個“停擺一上午”的案例就是典型：AI寫的代碼在單租戶、低負載下毫無問題。但當多個租戶同時使用，數(shù)據(jù)量激增，并發(fā)請求涌來時，那個沒有考慮資源競爭、沒有做邊界檢查、沒有處理緩存的代碼，就像一顆埋在系統(tǒng)深處的定時炸彈。

這種問題，功能測試根本測不出來。只有真實的生產(chǎn)環(huán)境，才能讓它“爆炸”。

為什么“出問題再改”行不通？

很多人會說：出了問題改不就行了？

問題在于，在老系統(tǒng)中，這種“單點解決”的方式，正在積累更大的技術(shù)債。

每一次用AI生成代碼然后發(fā)現(xiàn)問題、再生成、再發(fā)現(xiàn)問題，都是在增加系統(tǒng)的混亂度。代碼庫變得越來越難以理解，維護成本越來越高，新人接手越來越困難。

更可怕的是，如果團隊習慣了這種模式，可能會出現(xiàn)能力空心化：開發(fā)人員不再需要理解業(yè)務邏輯、不再需要思考代碼結(jié)構(gòu)、不再需要掌握調(diào)試技巧——反正AI會寫、會改、會解釋。

但當AI真的遇到AI無法解決的問題時，團隊可能已經(jīng)沒有人能站出來了。

源頭治理：給AI使用劃定“安全區(qū)”

經(jīng)歷了多次“延期-返工-故障”的循環(huán)后，我開始思考：問題出在哪里？

不是AI不能用，而是我們沒有給AI的使用劃定邊界。就像你不會讓實習生去改核心賬務系統(tǒng)一樣，你也不能讓AI去處理那些對業(yè)務至關重要的邏輯。

作為產(chǎn)品經(jīng)理，我在推動團隊建立一套“源頭治理”的規(guī)則。核心思路是：在代碼被寫出來之前，就把風險攔住。

第一步：給代碼分等級

把系統(tǒng)里的功能按業(yè)務影響劃分等級，不同等級對應不同的AI使用規(guī)則：

第二步：給開發(fā)者設門檻

使用AI之前，開發(fā)人員應該能夠回答幾個問題：

1. 這段代碼的核心邏輯是什么？（能不能用一句話講清楚）

2. 它和我們現(xiàn)有的業(yè)務規(guī)則怎么對應的？（對應需求文檔哪一條）

3. 如果數(shù)據(jù)量變成現(xiàn)在的10倍，它會出問題嗎？（有沒有考慮邊界）

4. 多個人同時用，它會沖突嗎？（有沒有并發(fā)隱患）

5. 如果這段代碼出問題，最壞情況是什么？（能不能承受）

如果一個開發(fā)答不上來，說明他可能沒有真正理解這段代碼在干什么。這個清單不需要技術(shù)多深，但需要動腦子。

第三步：讓理解“被看見”

建議開發(fā)在提交AI生成的代碼時，加注釋寫清楚“為什么這么寫”：

這個注釋的價值在于：倒逼開發(fā)去理解代碼；讓審查者能驗證理解是否正確；讓未來的維護者能看懂這段代碼。

第四步：用事故推動制度

當AI代碼出了問題，不做簡單歸咎，而是追問：

• 這段代碼屬于哪個等級？當時的規(guī)則允許用AI嗎？

• 如果允許，開發(fā)有沒有認真思考過那幾個核心問題？

• 如果不允許，為什么還會出現(xiàn)在代碼里？

這個過程不是為了追責，而是為了讓制度本身不斷迭代，也讓所有人意識到：AI代碼出問題，值得被認真追溯，而不是悄悄修復就完事。

特別提醒：如果你身處弱矩陣團隊，產(chǎn)品經(jīng)理話語權(quán)有限，以上制度聽起來很理想，但在弱矩陣組織（如產(chǎn)品經(jīng)理無考核權(quán)、技術(shù)團隊相對獨立）中，你可能無法直接推動。這時候可以嘗試：

• 借力：將風險包裝成“線上故障隱患”或“客戶投訴風險”，用業(yè)務視角說服技術(shù)負責人或上級。

• 找同盟：聯(lián)合測試負責人、質(zhì)量架構(gòu)師，他們同樣深受AI代碼不可控之苦。

• 小切口試點：選擇一兩個靠譜的開發(fā)，在非核心模塊試行分級規(guī)則，用實際效果證明價值。

• 向上管理：用一次真實事故（哪怕是預發(fā)環(huán)境的）作為案例，讓管理層意識到“不設規(guī)則的長期成本”。

不要試圖一步到位建立完整制度，哪怕只推動一條“AI代碼必須加注釋”的小規(guī)則，也是進展。

結(jié)語：AI是副駕駛，不是代駕

回到那個讓我思考這個問題的最初場景：那個導致停擺的開發(fā)，后來怎么樣了呢？

問題修復后，沒有人追究根源，沒有人反思流程，只是把這個故障當作一次“意外”。然后，下一段AI代碼，下一個開發(fā)，下一次延期，正在來的路上。

這就是為什么我要寫這篇文章。

AI編程工具確實強大，但它不會讓一個糟糕的流程變好，反而會加速它變得更糟。在老系統(tǒng)里，每一行AI生成的、無人理解的代碼，都是在給未來的自己埋雷。

我們需要的不是更聰明的AI，而是更清醒的人。AI可以寫代碼，但理解代碼、承擔責任、把控質(zhì)量的，必須是人。

畢竟，代碼可以AI寫，但事故不能AI背。

本文來自公眾號：雨柒 作者：雨柒