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

———— / BEGIN / ————

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

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

“又延期了?！?/p>

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

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

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

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

根源在哪？不是AI不行，而是我們從來(lái)沒(méi)有從源頭上為它劃定邊界。

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

AI編程工具的宣傳語(yǔ)總是很動(dòng)人：十分鐘生成一個(gè)完整模塊，代碼質(zhì)量堪比高級(jí)工程師。但很少有人告訴你，這些案例大多來(lái)自“從零開(kāi)始”的項(xiàng)目。

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

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

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

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

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

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

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

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

那些“順利上線”背后的隱形代價(jià)

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

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

1. 代碼變成黑箱

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

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

這是一個(gè)“遞歸噩夢(mèng)”：AI寫 → 人跑 → 報(bào)錯(cuò) → 人把報(bào)錯(cuò)給AI → AI改 → 人再跑 → 循環(huán)往復(fù)。表面上看起來(lái)在“調(diào)試”，實(shí)際上是在消耗時(shí)間。

2. 修改成本飆升

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

我見(jiàn)過(guò)一個(gè)功能，AI寫完后運(yùn)行正常。三個(gè)月后，產(chǎn)品需要在這個(gè)基礎(chǔ)上加一個(gè)小需求。開(kāi)發(fā)研究了兩天，不敢動(dòng)那部分AI生成的代碼——因?yàn)榭床欢壿嬍窃趺创?lián)的，不知道改了這處會(huì)不會(huì)讓另一處崩潰。最終，他選擇“重寫”，白白浪費(fèi)了時(shí)間。

3. 多租戶延時(shí)爆炸

最可怕的問(wèn)題，是在上線后才暴露的。

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

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

為什么“出問(wèn)題再改”行不通？

很多人會(huì)說(shuō)：出了問(wèn)題改不就行了？

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

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

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

但當(dāng)AI真的遇到AI無(wú)法解決的問(wèn)題時(shí)，團(tuán)隊(duì)可能已經(jīng)沒(méi)有人能站出來(lái)了。

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

經(jīng)歷了多次“延期-返工-故障”的循環(huán)后，我開(kāi)始思考：?jiǎn)栴}出在哪里？

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

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

第一步：給代碼分等級(jí)

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

第二步：給開(kāi)發(fā)者設(shè)門檻

使用AI之前，開(kāi)發(fā)人員應(yīng)該能夠回答幾個(gè)問(wèn)題：

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

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

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

4. 多個(gè)人同時(shí)用，它會(huì)沖突嗎？（有沒(méi)有并發(fā)隱患）

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

如果一個(gè)開(kāi)發(fā)答不上來(lái)，說(shuō)明他可能沒(méi)有真正理解這段代碼在干什么。這個(gè)清單不需要技術(shù)多深，但需要?jiǎng)幽X子。

第三步：讓理解“被看見(jiàn)”

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

這個(gè)注釋的價(jià)值在于：倒逼開(kāi)發(fā)去理解代碼；讓審查者能驗(yàn)證理解是否正確；讓未來(lái)的維護(hù)者能看懂這段代碼。

第四步：用事故推動(dòng)制度

當(dāng)AI代碼出了問(wèn)題，不做簡(jiǎn)單歸咎，而是追問(wèn)：

• 這段代碼屬于哪個(gè)等級(jí)？當(dāng)時(shí)的規(guī)則允許用AI嗎？

• 如果允許，開(kāi)發(fā)有沒(méi)有認(rèn)真思考過(guò)那幾個(gè)核心問(wèn)題？

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

這個(gè)過(guò)程不是為了追責(zé)，而是為了讓制度本身不斷迭代，也讓所有人意識(shí)到：AI代碼出問(wèn)題，值得被認(rèn)真追溯，而不是悄悄修復(fù)就完事。

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

• 借力：將風(fēng)險(xiǎn)包裝成“線上故障隱患”或“客戶投訴風(fēng)險(xiǎn)”，用業(yè)務(wù)視角說(shuō)服技術(shù)負(fù)責(zé)人或上級(jí)。

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

• 小切口試點(diǎn)：選擇一兩個(gè)靠譜的開(kāi)發(fā)，在非核心模塊試行分級(jí)規(guī)則，用實(shí)際效果證明價(jià)值。

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

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

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

回到那個(gè)讓我思考這個(gè)問(wèn)題的最初場(chǎng)景：那個(gè)導(dǎo)致停擺的開(kāi)發(fā)，后來(lái)怎么樣了呢？

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

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

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

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

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

本文來(lái)自公眾號(hào)：雨柒 作者：雨柒