要用 AI 規劃程式碼遷移，先凍結已核實的現況和目標庫存，繪出依賴及兼容邊界，再要求 AI 整理附有入口門、出口門、觀察、回復觸發器和負責人的候選波次。目標架構、不可逆決定和每階段驗收仍由人負責。模型只可草擬藍圖，不可執行改寫或聲稱遷移完成。

這比通用 AI 項目計劃更具體：遷移會改變運行契約，而新舊狀態可能共存。AI 使用總指南說明安全上下文和審批；這裏使用 AI 整理順序與證據，不把架構權交給模型。

關鍵要點：

選擇遷移模式前先寫清目標和不做的事。

凍結現況和目標庫存，並繪出依賴。

把兼容假設變成明確的測試、入口門和出口門。

切換前寫好回復觸發器和行動。

AI 只草擬藍圖，不執行遷移；關鍵決定由人批准。

遷移要達成甚麼成果、哪些不在範圍內？

「遷移程式碼庫」沒說明改甚麼、為何改。先寫明驅動因素：運行環境不再受支援、程式庫替換、服務拆分、語言轉換、框架升級、部署平台改變、契約整合或保安要求。訂立可量度的成果，但不要過早選定實作方式。

撰寫一頁章程：

欄位	問題
成果	哪項能力或風險會改變？
非目標	哪些內容必須保持不變？
範圍	涉及哪些程式庫、服務、客戶端、工作和資料？
限制	兼容期、預算、凍結期、規例
成功	哪些可觀察條件能證明成果達成？
權限	誰選擇架構、誰批准切換？

NIST 的安全軟件開發框架（SSDF）把保安實踐定位為以風險為本、按機構情況調整的活動。［1］據此按影響和證據排序遷移風險，而非讓模型給出通用步驟。

不要把私人程式庫、憑證、正式環境資料傾印、客戶資料、內部網絡細節或未公開漏洞上載到未經批准的工具。使用最少量的去敏清單、公開介面、合成資料結構和受控環境。

凍結現況與目標清單

按系統實際運作方式盤點現況，而非照搬舊架構圖。包括可執行入口、程式庫、建置和部署工作、設定、資料儲存、隊列、排程工作、外部供應商、客戶端、可觀察性、存取控制和負責人，並附上來源位置和版本。

另建目標清單，區分已批准的設計和候選方案。AI 建議過的項目不會因此成為「目標狀態」。使用 現況已確認、目標已批准、候選、未知 和 範圍外 等狀態。

項目 ID	現況	目標	證據	負責人	狀態
R-01	運行環境 A 版本 x	運行環境 B 版本 y	建置檔案、發佈清單	平台團隊	目標已批准
Q-03	隊列消費者 v1	未知	部署設定	服務團隊	未知

對比兩份清單，找出新增、移除、保留的契約和歸屬不明項目。不要讓產生的摘要抹去無人負責的排程工作或甚少使用的客戶端。

哪些依賴會擴大影響範圍？

依賴不只是套件匯入。要對應同步調用、事件、隊列、共用資料結構、資料庫讀寫、檔案格式、快取、功能開關、身份與授權、部署次序、營運手冊和人手流程，並記下方向和證據。

只有每條依賴邊都引用檔案、設定項目、契約測試或獲批營運紀錄時，才讓 AI 產生候選依賴邊。發掘未知的運行時依賴屬於獨立的驗證計劃；匯入關係圖無法證明所有網絡和資料依賴。

按遷移風險為消費者排序：

契約敏感度和發佈獨立性；
資料歸屬和是否有狀態；
流量或業務重要性；
可否並行測試；
可否獨立回復；
負責人能否投入，以及外部協調難度。

輸出應揭示看似局部的程式庫升級，實際在哪些地方與序列化、資料庫或客戶端行為耦合。

建立遷移兼容矩陣

遷移常敗在邊界，而非重寫的內部邏輯。針對 API 版本、事件、資料結構、檔案、快取、CLI 參數和持久化狀態，列出「舊生產者／新消費者」和「新生產者／舊消費者」等組合。

邊界	舊 → 舊	舊 → 新	新 → 舊	新 → 新	證據／測試
事件資料結構	基線	候選	候選	目標	契約測試 ID
儲存紀錄	基線	讀取檢查	回復讀取	目標	測試資料 ID

切勿單憑類型相似便標為兼容。要界定測試資料、測試、環境、預期結果和負責人，並涵蓋語義改變，例如預設、排序、逾時、重試、錯誤對應、權限檢查和語言地區處理。

如無法向後兼容，便明確寫出協調切換和停機風險，不要藏在籠統的「更新消費者」工作內。

哪種遷移模式配合你的限制？

AWS 把 Strangler Fig 模式描述為：在新舊路徑並存期間逐步取代舊系統的功能，遷移完成後再讓舊系統退役。［2］當路由和有邊界的能力容許逐步轉移時，它能降低風險；但對強耦合狀態或原子一致性要求並不自動適用。

根據證據評估候選模式：

原地升級，輔以兼容轉接層；
透過抽象層分支；
增量路由或 Strangler 方式；
影子流量或唯讀比較；
雙讀、雙寫或事件複製；
在維護時段內離線轉換；
部分並存不安全時，進行協調式一次過切換。

讓 AI 比較各模式的前提條件、可逆步驟、狀態分叉風險、營運成本和退出條件。由人類架構負責人選擇模式並記錄理由。例如，雙寫能提高過渡彈性，但會引入次序、部分失敗、對帳和回復的複雜性。

資料與狀態應如何獨立規劃？

程式碼可重新部署，狀態未必可逆。盤點資料結構變更、回填、識別碼、時間戳記、編碼、索引、限制、保留期、事件偏移、快取鍵、工作階段和衍生資料，並確定每個階段的真源。

每項轉換都要記錄：

輸入和輸出的資料結構版本；
確定性的轉換規則；
驗證樣本或對帳查詢；
無效或遲到紀錄的處理方式；
檢查點和重新啟動行為；
向前兼容和回復讀取行為；
備份、保留和還原的證據；
負責人和批准。

在合適環境測試還原之前，不要聲稱備份可用。不要把真實正式環境資料放進模型上下文；除非獲批的私人流程明確容許，只使用資料結構或合成樣本。

用 AI 規劃程式碼遷移時拆成有門禁的波次

Microsoft 的遷移規劃指引強調依賴發掘、遷移排序、工作負載分組、回復規劃和遷移波次，而非把所有工作負載一視同仁。［3］每個波次應細小到可觀察、可撤回，並尊重依賴。

每個波次需要：

欄位	用途
範圍	精確的組件、消費者和資料
入口門禁	開始前需要的證據
變更	已批准的技術動作，而非產生的程式碼
觀察	指標、日誌、追蹤、契約測試、對帳
保持期	擴大範圍前所需的時間或樣本
出口門禁	繼續推進的條件
回復觸發條件	停止該波次的可量度條件
負責人	有權作決定的人

適當時，先建設能減少不確定性的基礎設施和測試能力：契約測試、遙測、路由控制、資料對帳或兼容轉接層。未說明證據和剩餘影響範圍時，不要稱某個波次為「低風險」。

設計並行運行和比較

系統容許時，影子執行或雙跑可在轉移權威前比較輸出。確定哪方為權威、如何抑制副作用、如何為請求抽樣，以及如何規範化非確定性欄位。切勿把正式環境寫入送往未經批准的影子路徑。

建立比較類別：

識別碼或規範化序列化結果要求完全相同；
數值或時間類輸出採用容差範圍；
契約容許時，採用集合比較或忽略次序的比較；
由領域負責人批准的語義等同；
無法自動化的情況作人手覆核。

記錄不相符的類別和負責人。很高的整體相符率可能掩蓋嚴重的授權或資金處理差異，因此要按嚴重程度設門禁，而非只看一個醒目百分比。

把可觀察性寫入計劃

在遷移前選定訊號：可用性、延遲、錯誤類別、資源使用、隊列延遲、資料對帳、授權拒絕、客戶端版本和業務不變量。建立已知基線，並把遷移專用遙測與日常監察分開。

每個訊號都需要查詢或儀表板引用、預期範圍、收集間隔、保留期、負責人和行動門檻。AI 可以整理目錄格式或提出缺漏類別，但不能虛構基線數值或斷言某個儀表板存在。

還要納入反向證據：某波次後舊路徑不應再有流量，就去量度；舊格式紀錄不應再被建立，就去查詢。退出條件既要證明目標運作正常，也要證明退役路徑不再具權威。

切換前的遷移回復方案要寫明甚麼？

回復是經測試的轉換，不是一句「有需要時還原」。界定觸發條件、決策權限、最長決策時間、路由動作、部署動作、狀態處理、客戶端溝通和驗證方式。把程式碼回復和資料回復分開：舊的二進位程式可能無法理解新版本寫入的紀錄。

使用回復表：

觸發條件	門檻	決策人	動作	狀態處理	驗證
契約不相符	任何嚴重類別	API 負責人	路由回舊路徑	停止新寫入並對帳	契約測試套件 + 計數器

依賴回復機制前先測試它。如變更不可逆，便如實說明，並訂立預防措施、備份、補償動作和更高層級審批。不要讓模型把「不可逆」淡化成「較難還原」。

遷移怎樣才算真正完成？

Microsoft 的現代化指引建議按業務價值、技術依賴、成功準則和回復規劃劃分邏輯階段。［4］遷移完成應包括舊系統退役，而不只是目標系統上線。

退出條件可包括：

凍結範圍內的兼容性和契約測試套件全部通過；
對帳結果達到各類別的門檻；
所需保持期結束且沒有觸發回復；
所有受支援的客戶端都已遷移，或已獲批准的例外；
新狀態成為權威，而且備份／還原證據屬最新；
舊系統的流量、工作、憑證、功能開關和寫入已全部移除；
文件、歸屬、警報和營運手冊都與目標狀態一致；
具名的決策負責人批准退役。

把證據包和未解決的例外歸檔。長期保留「臨時」轉接層的遷移不一定失敗，但須明確其負責人、成本和覆核日期。

使用可複製的遷移藍圖

# 程式碼遷移藍圖
- 成果：
- 非目標：
- 凍結證據引用：
- 現況清單：
- 已批准的目標清單：
- 未知項目：
- 架構決策負責人：

## 邊界
- 消費者 / 生產者：
- 現行契約：
- 目標契約：
- 兼容性測試：
- 資料 / 狀態影響：

## 波次
- 範圍：
- 依賴：
- 入口門禁：
- 已批准的變更：
- 並行運行方式：
- 觀察項目與門檻：
- 保持期：
- 出口門禁：
- 回復觸發條件與動作：
- 負責人：

## 完成
- 對帳：
- 舊系統退役：
- 文件 / 營運手冊：
- 例外：
- 人工批准：

讓 AI 找出空白欄位、無依據假設、循環依賴、欠缺的負責人和回復缺口。不要在同一批准中讓它既產生又套用遷移。執行任何產生的變更前，先按 AI 生成程式碼審閱清單和程式庫的變更流程審閱。

常見問題

AI 能選擇目標架構嗎？

它可以比較已記錄的選項和限制。架構須由負責工程師選擇和批准，因為決定涉及提示詞以外的背景、風險和歸屬。

增量遷移總是較安全嗎？

不是。並存可能帶來路由、兼容性和狀態分叉風險。應按系統限制和經測試的回復方案選擇模式。

資料庫遷移應如何處理？

把資料結構兼容、回填、無效紀錄、檢查點、對帳、備份、還原和回復讀取與程式碼部署分開規劃。

項目計劃與遷移藍圖有何分別？

項目計劃廣泛協調工作；遷移藍圖則為技術並存、兼容性、狀態權威、有門禁的切換和退役建模。

甚麼時候適合一次過切換？

部分並存不可行或風險更高，而且團隊有獲批時段、完整演練、有力驗證、復原方案和明確權限時。

AI 能根據這份計劃產生遷移程式碼嗎？

那應是一項獨立、範圍明確並經程式碼審閱和測試的變更。批准藍圖不等於批准產生的實作。

波次進行中出現未知依賴怎麼辦？

在相應門禁停下，記錄證據，重估影響範圍和兼容性，修改波次前先取得批准。

遷移甚麼時候才算完成？

當目標行為和狀態達到已批准門禁、客戶端完成過渡、例外都有負責人、舊系統權威已移除且退役獲批時。

來源

Sources checked 2026 年 8 月 29 日。

NIST, “Secure Software Development Framework” — https://csrc.nist.gov/projects/ssdf
AWS Prescriptive Guidance, “Strangler fig pattern” — https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/strangler-fig.html
Microsoft Cloud Adoption Framework, “Plan a cloud migration” — https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/migrate/plan-migration
Microsoft Cloud Adoption Framework, “Plan cloud modernization” — https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/modernize/plan-cloud-modernization

用 AI 規劃程式碼遷移，由庫存盤點一直到舊系統退役