3個月前，我把AI從寫玩具腳本推進到生產(chǎn)環(huán)境。現(xiàn)在代碼還在跑，但我多了幾頁筆記——全是"這方法在生產(chǎn)里會炸"的警告。

這不是vibe coding教程，是事故記錄。

從"能跑就行"到"炸了誰背鍋"

早期用AI寫代碼很爽。 greenfield腳本（全新腳本），原型，用完即棄的功能——AI生成、我掃一眼、扔服務(wù)器上，第二天忘了它存在。

生產(chǎn)環(huán)境不一樣。代碼要維護、要監(jiān)控、凌晨3點出問題要有人能看懂。我最初沒意識到這個斷層：AI寫的代碼在隔離環(huán)境里完美運行，放進真實基礎(chǔ)設(shè)施就像把家貓扔進雨林。

第一個教訓來得很快。AI生成的數(shù)據(jù)庫遷移腳本，本地測試通過，預發(fā)布環(huán)境通過，生產(chǎn)環(huán)境鎖表10分鐘。沒有惡意代碼，只是AI不知道我們的主庫有讀寫分離，選錯了執(zhí)行節(jié)點。

問題不是AI能力，是上下文。AI看不見你的基礎(chǔ)設(shè)施拓撲、看不見歷史事故、看不見那個"千萬別在周二下午部署"的潛規(guī)則。

我試過的7種生產(chǎn)適配方法

方法1：把基礎(chǔ)設(shè)施寫成文檔喂給AI

最直覺的做法。我把架構(gòu)圖、部署流程、監(jiān)控規(guī)則整理成markdown，塞進上下文窗口。

效果：AI開始生成"符合我們規(guī)范"的代碼，但規(guī)范是靜態(tài)的。上周剛改的告警閾值，文檔沒更新，AI按舊規(guī)則寫，新代碼一上線就誤報。

維護文檔比維護代碼還累。我放棄了這條路線。

方法2：讓AI只寫"被框死的代碼"

限制AI的發(fā)揮空間。只讓它填函數(shù)體，不準碰接口定義、不準碰配置、不準碰任何可能連鎖反應(yīng)的地方。

這確實減少了事故，但也閹割了AI的價值。變成高級自動補全，而不是agent（智能體）。

更麻煩的是，邊界在哪？一次我以為安全的"純計算函數(shù)"，AI內(nèi)部調(diào)了個緩存——它從訓練數(shù)據(jù)里"知道"這種場景該用緩存，但不知道我們的緩存有雙活架構(gòu)，選錯了實例。

方法3：強制AI生成"可審查的代碼"

要求每段AI代碼附帶解釋：這行為什么這樣寫、依賴什么假設(shè)、什么情況下會失效。

執(zhí)行起來像讓程序員寫注釋，AI會編造理由。更危險的是，我發(fā)現(xiàn)自己開始信任這些解釋——"它都說了這里會處理空指針"，結(jié)果沒處理。

解釋成了安慰劑。

方法4：人機結(jié)對，AI寫我審

回到最保守的模式。AI生成，我逐行閱讀、測試、簽字。

瓶頸立刻顯現(xiàn)：AI的速度是秒級，我的審查是小時級。3個月的實踐里，這種模式只適用于最關(guān)鍵的路徑代碼，占比不到20%。

剩下的80%怎么辦？我需要在"完全信任"和"完全人工"之間找到中間態(tài)。

方法5：用測試當安全網(wǎng)

加強測試覆蓋，讓AI代碼在測試里暴露問題。聽起來合理，但AI寫的測試也在vibe——它測試的是"我認為正確的行為"，不是"生產(chǎn)實際的行為"。

一次AI為某個API生成了20個測試用例，全部通過。上線后發(fā)現(xiàn)漏了跨時區(qū)場景——訓練數(shù)據(jù)里沒這個corner case（邊界情況），它想不到要測。

測試的盲點，就是AI的盲點。

方法6：小流量灰度+自動回滾

把AI代碼當成可疑代碼對待。1%流量、自動監(jiān)控、異常自動回滾。

這是目前我依賴最深的機制。但它解決的是"出問題怎么辦"，不是"怎么減少問題"。而且灰度本身有成本：需要基礎(chǔ)設(shè)施支持、需要維護分流邏輯、需要有人盯著監(jiān)控。

小團隊玩不起。我算過賬，維護這套灰度系統(tǒng)的工時，超過它幫我省下的編碼時間。

方法7：讓AI只讀不寫，當超級搜索

最極端的保守策略。AI不生成新代碼，只幫我理解舊代碼、找bug、寫文檔。

意外地好用。生產(chǎn)代碼的復雜性往往不在邏輯，而在歷史包袱——為什么這里有個看似多余的try-catch？AI能從git歷史里找到3年前的那次事故報告。

但這已經(jīng)偏離了vibe coding的初心。我想讓AI寫代碼，不是當考古學家。

那些文章沒告訴你的

網(wǎng)上教你vibe coding的帖子，場景多是：新side project（業(yè)余項目）、內(nèi)部工具、原型驗證。共同點是低 stakes（低風險）——炸了重寫，沒人受傷。

生產(chǎn)環(huán)境的高 stakes 改變了所有計算。不是AI能不能寫對，而是寫錯了我能不能發(fā)現(xiàn)。

我現(xiàn)在的實踐是混合策略：新模塊用方法6（灰度），舊代碼改動用方法7（只讀），關(guān)鍵路徑用方法4（人工審查）。沒有銀彈，只有持續(xù)的上下文工程。

一個具體例子：我讓AI生成了一段處理用戶上傳的代碼，本地測試完美。但我額外加了一步——把這段代碼和過去12個月的on-call記錄（值班記錄）一起喂給AI，問"這段代碼可能觸發(fā)哪些歷史問題？"它指出了2個我之前沒考慮的race condition（競態(tài)條件）。

這不是AI變聰明了，是我學會了喂對飼料。

還在跑的那部分

3個月過去，我倉庫里大概有15%的代碼是AI生成后直接進生產(chǎn)的。它們運行穩(wěn)定，但我記得每一塊的"出生證明"：哪段灰度過、哪段我逐行審過、哪段后來補了監(jiān)控。

更誠實的數(shù)據(jù)是：有8%的AI生成代碼被完全重寫，不是因為邏輯錯誤，是因為沒人能看懂AI為什么那樣設(shè)計。維護成本超過了重寫成本。

還有一個數(shù)字我沒法量化——我花在"教AI理解我們系統(tǒng)"上的時間。寫prompt、整理上下文、事后復盤，這些隱性成本很少被討論。

現(xiàn)在我的待辦列表里有一項：測試一個假設(shè)。如果我把過去3個月的所有AI交互記錄喂給新的agent，讓它總結(jié)"這個團隊的生產(chǎn)代碼有什么模式"，下次生成的代碼會不會更靠譜？

這需要再花3個月驗證。而3個月后，模型可能又換代了。