最近用 ChatGPT、Codex 做大型重構時我越來越不建議一種看起來特別“干凈”的做法字段準備改名直接全倉庫搜索舊字段統(tǒng)一替換然后刪掉舊字段。比如原來數(shù)據(jù)庫里有一個字段user_name現(xiàn)在準備統(tǒng)一改成display_name從代碼層面看這件事似乎很簡單。Codex可以很快完成修改Entity。修改DTO。修改Repository。修改SQL。修改測試。修改接口返回。最后把舊字段刪掉。本地Build通過。測試全綠。Git Diff看起來也很完整。于是很容易得出結論“遷移完成了?！钡嬲暇€以后問題可能才剛開始。因為生產(chǎn)環(huán)境不是舊版本瞬間消失 → 新版本瞬間全部替換。真實的滾動發(fā)布通常更像舊Pod還在跑。新Pod已經(jīng)啟動。兩個版本同時訪問同一個數(shù)據(jù)庫。這時候一個非常重要的問題就出現(xiàn)了新代碼改完了舊代碼還能不能繼續(xù)工作這也是為什么數(shù)據(jù)庫字段準備改名時我現(xiàn)在更傾向于讓Agent遵循Expand → Migrate → Contract而不是Rename → Delete → Done一、最危險的不是字段改錯而是新舊版本共存時互相看不懂假設舊版本代碼一直讀取user_name新版本已經(jīng)全部改成display_name如果數(shù)據(jù)庫直接執(zhí)行DROP COLUMN user_name ADD COLUMN display_name新版本當然可以正常工作。問題是滾動發(fā)布期間可能還有一半舊Pod沒有退出。這些舊Pod繼續(xù)執(zhí)行SELECT user_name FROM users結果立刻報錯。所以你會看到一種特別典型的現(xiàn)場新版本單獨測試正常。舊版本單獨運行也正常。但新舊版本一起存在時系統(tǒng)反而壞了。這個問題本質(zhì)上不是字段設計問題。而是Version Compatibility——版本兼容。二、Agent特別容易把“最終狀態(tài)”當成“遷移步驟”這是我覺得Agent工程里非常值得注意的一點。你告訴Codex把user_name改成display_name。它天然會傾向于生成一個“最終正確狀態(tài)”代碼里只剩display_name。數(shù)據(jù)庫里也只剩display_name。測試全部圍繞新字段。從最終架構看非常漂亮。但真實工程需要的不是Final State而是Safe Transition Path也就是系統(tǒng)怎樣從舊狀態(tài)安全走到新狀態(tài)。這兩件事完全不同。最終結果可能只需要一個字段。但遷移過程中可能必須允許兩個字段暫時同時存在。三、第一步不是Rename而是Expand假設現(xiàn)在數(shù)據(jù)庫只有user_name更安全的第一步通常不是刪掉它。而是先新增display_name此時數(shù)據(jù)庫里變成user_namedisplay_name兩個字段同時存在。舊版本繼續(xù)讀取user_name新版本可以開始識別display_name這樣做看起來有點“重復”。但它真正換來的東西是兼容窗口。你給新舊代碼提供了一段可以安全共存的時間。四、為什么這個兼容窗口這么重要因為生產(chǎn)發(fā)布不會只包含數(shù)據(jù)庫。還有應用實例。緩存。消費者。定時任務。異步任務。舊客戶端。這些東西不一定同時升級。比如10:00 數(shù)據(jù)庫Schema已經(jīng)更新。10:02 第一批新Pod上線。10:05 還有一半舊Pod在跑。10:10 消息消費者才完成升級。10:20 某個定時任務還是舊版本。如果你把Schema改成只能支持新代碼那么整個升級過程必須做到所有組件同時切換。這在真實系統(tǒng)里通常非常困難。而Expand階段的作用就是讓新舊組件在過渡期都能生存。五、第二步才是Migrate字段新增以后真正復雜的部分才開始。因為這時候可能出現(xiàn)新數(shù)據(jù)寫到哪里舊數(shù)據(jù)怎么辦舊代碼寫user_name。新代碼寫display_name。兩邊數(shù)據(jù)會不會不一致這時通常需要設計遷移策略。比較常見的一種方式是Dual Write——雙寫在過渡階段新代碼同時寫user_name和display_name比如用戶改昵稱兩個字段都更新。這樣即使請求下一次落到舊Pod舊版本讀取user_name仍然能拿到最新值。這解決的是寫兼容。六、讀也不能直接只讀新字段如果歷史數(shù)據(jù)還沒有遷完很多老記錄里display_name可能還是空的。所以新版本直接只讀新字段也可能出問題。更安全的讀取方式通常是優(yōu)先讀display_name如果為空回退到user_name也就是Read New, Fallback Old這樣即使歷史數(shù)據(jù)Backfill還沒全部完成新代碼也能繼續(xù)工作。所以遷移階段常見的組合就是寫新舊雙寫讀新字段優(yōu)先舊字段兜底這套邏輯雖然臨時看起來比較“臟”但它的價值就是把升級風險拆散。七、歷史數(shù)據(jù)必須單獨Backfill新增字段以后數(shù)據(jù)庫里可能有幾百萬甚至幾千萬歷史記錄。不能簡單假設以后用戶重新保存一次就會自然補齊。所以通常還需要Backfill把舊數(shù)據(jù)里的user_name逐步寫入display_name這里也不建議讓Agent直接生成一句UPDATE users SET display_name user_name然后在線上一把跑完。如果表很大可能帶來長事務。鎖等待。IO壓力。主從延遲。日志暴漲。所以更穩(wěn)的方式是分批。限速。可恢復。有進度記錄。例如每次遷移1000條。記錄Last ID。失敗后繼續(xù)。同時觀察數(shù)據(jù)庫CPU。IO。Replication Lag。事務耗時。八、為什么Schema Migration通常要比代碼修改更保守因為代碼回滾相對容易。新版本有問題可以重新部署舊版本。但數(shù)據(jù)庫變更很多時候沒有這么簡單。尤其是刪除字段。改變字段類型。重寫歷史數(shù)據(jù)。合并字段。一旦數(shù)據(jù)真的被破壞你不能只靠git revert恢復。所以數(shù)據(jù)庫變更里一個很重要的原則是Prefer Additive Changes First優(yōu)先做新增字段。新增表。新增索引。而不是直接刪除。直接覆蓋。直接不可逆修改。Agent改代碼越快這條原則反而越重要。九、真正危險的是“代碼可以回滾數(shù)據(jù)庫卻回不去”假設新版本上線以后出現(xiàn)問題。你決定Rollback。應用很快切回舊版本。結果舊版本開始報Unknown column user_name因為數(shù)據(jù)庫已經(jīng)把舊字段刪掉了。這時候你會發(fā)現(xiàn)應用回滾成功。系統(tǒng)還是起不來。這就是Code Rollback ≠ Schema Rollback所以在設計遷移時應該提前問如果新版本上線10分鐘后必須回滾舊版本還能不能正常訪問當前Schema如果答案是不能說明這個Migration還不夠安全。十、Expand階段真正想保證的是N/N-1兼容復雜系統(tǒng)里經(jīng)常要考慮當前版本N。上一版本N-1。在一段時間內(nèi)同時運行。比如Version 2.3和Version 2.2一起訪問數(shù)據(jù)庫。如果Schema只支持2.3滾動發(fā)布就會很危險。所以一個更實用的設計目標是當前Schema至少短期同時支持N和N-1。這對滾動發(fā)布?？焖倩貪L。多Region發(fā)布?；叶壬壎挤浅Ｖ匾Ｊ?、什么時候可以停止Dual Write這一步不能憑感覺。通常至少要確認所有新版本已經(jīng)穩(wěn)定上線。舊Pod全部退出。舊消費者退出。舊定時任務停止。歷史數(shù)據(jù)Backfill完成。新字段覆蓋率達到預期。監(jiān)控一段時間沒有異常。然后才能進入下一步停止寫舊字段。這時可以把雙寫改成只寫新字段。但舊字段仍然先保留。因為停止寫舊字段和刪除舊字段不應該是同一個動作。十二、Contract才是最后一步等到所有運行代碼都已經(jīng)不再依賴舊字段。歷史數(shù)據(jù)完成遷移。舊版本已經(jīng)確認不會再回滾。觀察期也足夠長。這時候才進入Contract也就是刪除舊讀取邏輯。刪除雙寫。刪除兼容代碼。最終刪除user_name這時候系統(tǒng)才真正完成遷移。所以整個流程其實是Expand新增新字段保持舊字段?！齅igrate雙寫。兼容讀。Backfill?！齋witch新字段成為主路徑?！齇bserve確認舊字段不再被使用。↓Contract最后刪除舊字段。十三、為什么不能讓Codex一次把所有步驟做完因為這些階段之間需要Production Evidence比如Backfill到底完成沒有舊Pod到底退出沒有還有沒有舊客戶端消息消費者是否全部升級新字段還有沒有空值這些事情不是代碼生成完成就能證明的。它們需要真實運行。監(jiān)控。時間窗口。線上數(shù)據(jù)。所以Agent可以一次性幫你生成Migration Plan。新字段代碼。雙寫邏輯。Backfill腳本。監(jiān)控。Contract腳本。但真正執(zhí)行時不應該一次全部放出去。這里要把Code Generation和Change Execution分開。十四、讓Agent做Migration時我更建議先輸出“階段計劃”不要直接“把user_name改成display_name?！备玫娜蝿帐窍茸屗敵鯬hase 1新增新字段不改變現(xiàn)有行為。Phase 2增加雙寫與兼容讀。Phase 3歷史數(shù)據(jù)Backfill。Phase 4切新字段為主。Phase 5確認舊版本退出。Phase 6刪除舊字段。每個Phase再明確需要修改哪些文件。驗證什么。如何回滾。進入下一階段的條件是什么。這樣Agent才是在執(zhí)行Migration Workflow而不是簡單Search Replace。十五、Backfill完成也不能只看“腳本跑完了”真正應該驗證的是新字段覆蓋率。新舊字段一致率。異常數(shù)據(jù)數(shù)量。空值數(shù)量。失敗重試。例如1000萬條記錄。腳本顯示“Completed”。但里面有3萬條失敗。那這次Migration當然還沒有結束。所以遷移完成應該基于Data Evidence而不是Job Status十六、給自己看一個指標Backward Compatibility Coverage這篇我建議只保留一個指標Backward Compatibility Coverage——向后兼容覆蓋率可以簡單理解成遷移期間關鍵讀寫路徑中同時能夠支持新舊版本的路徑數(shù)量 ÷ 關鍵遷移路徑總數(shù)例如這次字段改名影響API讀取。訂單寫入。消息消費者。定時任務。管理后臺。一共5條關鍵路徑。其中4條已經(jīng)兼容新舊Schema。但一個老定時任務仍然只能讀舊字段。那么向后兼容覆蓋率 80%。這時候最危險的不是新代碼寫得不好。而是還有一個隱藏舊路徑?jīng)]有被納入Migration。十七、兼容覆蓋率低不應該繼續(xù)刪舊字段如果Agent報告代碼全綠。新字段也能用。但兼容覆蓋率仍然只有60%這時候最不應該做的就是Contract。更應該繼續(xù)找還有哪些舊消費者。還有哪些批處理。還有哪些腳本。還有哪些外部服務。仍在使用舊Schema。只有這些依賴逐漸清零舊字段才真正有資格刪除。十八、Plus和Pro怎么判斷如果你平時主要讓ChatGPT、Codex做小型數(shù)據(jù)庫修改。新增幾個字段。改單個接口。影響范圍有限。這種任務下Plus通常已經(jīng)夠用。真正更重要的是不要讓Agent把數(shù)據(jù)庫Migration當成一次代碼重構。先把兼容。Backfill。回滾。階段邊界設計清楚。如果你的實際開發(fā)已經(jīng)變成大型系統(tǒng)頻繁做Schema演進。一次改動涉及多個服務。多個消費者。歷史數(shù)據(jù)遷移?；叶?。滾動發(fā)布。數(shù)據(jù)回填。多輪驗證。還需要Codex持續(xù)分析依賴、生成Migration、寫B(tài)ackfill、改代碼、補測試、做回歸這種高頻、長時間、多階段工程Workflow下Pro會更適合。因為更多任務容量可以真正用于大型代碼庫理解。長任務。多階段遷移。反復驗證。但無論使用Plus還是Pro最關鍵的原則都一樣Agent可以一次把最終代碼寫出來但生產(chǎn)遷移不能一次跳到最終狀態(tài)。最后數(shù)據(jù)庫字段準備改名為什么不能讓Agent一次把舊字段全部刪掉因為真實生產(chǎn)系統(tǒng)需要解決的不是“最終字段叫什么”而是“舊系統(tǒng)怎么安全走到新系統(tǒng)”一個成熟的Schema Migration真正重要的不是最終Diff有多干凈。而是整個過程中舊版本還能運行。新版本能夠灰度。歷史數(shù)據(jù)能夠遷移。出現(xiàn)問題還能回滾。當ChatGPT、Codex開始越來越快地完成大范圍代碼修改以后數(shù)據(jù)庫遷移反而應該更加保守。因為代碼可以幾分鐘重寫。歷史數(shù)據(jù)和線上兼容性卻不能靠一次Prompt重來。所以真正安全的路線通常不是Rename → Delete而是Expand → Migrate → Contract先兼容。再遷移。最后清理。這才是Agent真正進入生產(chǎn)工程以后數(shù)據(jù)庫Schema演進應該保持的節(jié)奏。持續(xù)分享 Codex、大模型開發(fā)與 AI 編程實戰(zhàn)內(nèi)容。長期深度使用各類代碼大模型也整理了穩(wěn)定的Plus/Pro會員訂閱渠道有需要可自取。