許多工程師對「遷移（Migration）」這個詞感到頭痛。無論是將舊系統搬到新架構，還是將數十萬行缺乏文件、原作者早已離職的遺留代碼（Legacy Code）重構，這類專案通常被視為「搬山」一樣艱巨。傳統做法是花數月進行分析、寫數百張 Jira 票券，然後由工程師一個個處理，風險高且週期極長。
ServiceTitan 的 Principal AI Engineer David Stein 分享了一套將這種「搬山」過程轉化為「組裝線」的實作方法。他指出，不能簡單地把整個專案丟給 AI（如 Cursor 或 Claude），因為 LLM（大型語言模型）會產生幻覺（Hallucinations），且無法在缺乏上下文的情況下處理大規模的複雜度。
要實現快速遷移，核心在於將問題「分解、標準化、自動化」。
將大山分解為小石子
面對巨大的遷移任務，第一步不是思考如何移動整座山，而是定義如何遷移「一顆小石子」。在 ServiceTitan 的案例中，他們需要遷移數百個報表指標（Reporting Metrics）到新的數據平台（如 dbt MetricFlow）。
他們將任務分解到 AI Agent 可以獨立完成且能被驗證的粒度。例如，單個指標的遷移流程包含：獲取舊代碼上下文、確認資料庫表結構、理解數據分佈、根據新架構設計文件、撰寫代碼，最後進行驗證。
建立剛性的驗證迴圈（Validation Loop）
這是整個方案中最關鍵的一環。AI 寫代碼很快，但如果沒有剛性的驗證，產出的結果可能是看起來正確但實際錯誤的「廢料（Slop）」。
為了消除幻覺，團隊建立了一個類似「物理引擎」的模擬器（Simulator）。這個驗證工具會同時運行舊系統和新系統，比對兩者的輸出結果（格式、數據分佈、數值）是否完全一致。
這種驗證必須是程式化且剛性的（Programmatically Rigid），只有得到明確的 Pass 或 Fail，AI 才能確定任務完成。如果 Fail，AI 會根據錯誤訊息進入「自我修復迴圈（Self-healing Loop）」，重新調整代碼直到通過驗證。
組裝線模式的實作細節
當分解與驗證到位後，就可以將遷移過程視為一條組裝線，將 AI Agent 當作執行單調任務的「小助手（Minions）」。
第一，定義目標狀態（Goal State）。他們建立一個 migration_goals.txt 文件，明確定義什麼叫作「完成」，並詳細列出 AI 可以使用的工具（例如 SnowSQL CLI）以及如何使用這些工具來驗證工作。
第二，提供標準化上下文。AI 需要像人類工程師一樣獲取資訊。團隊不使用複雜的框架，而是直接賦予 AI 存取 Staging 環境的 CLI 工具，讓 AI 能自行查詢 Snowflake 資料庫中的真實數據分佈，而非僅依賴對公式的描述。
第三，任務清單化。將所有指標列在 migration_tasks 文件中，分階段執行。AI 每完成一個指標，就在文件中標記為完成。
實務上的限制與挑戰
雖然這套方法能處理約 85% 的重複性勞務，但仍有 15% 的複雜案例需要資深工程師介入。常見的失敗原因包括：
缺乏邊緣案例數據：當 AI 找不到能涵蓋特定邏輯的測試數據時會卡住。解決方案是建立「黃金清單（Golden Lists）」，將已知具有代表性的 ID 或時間區間寫入上下文文件，將團隊內部的經驗（Tribal Knowledge）顯式化。
安全性風險：賦予 AI 執行 CLI 工具權限具有風險。實務上必須將 AI 限制在 Staging 環境，嚴禁提供生產環境的金鑰（Secrets）或具有刪除權限的帳號。
這套模式的價值在於極大地提升了「架構敏捷性」。在傳統模式下，如果遷移到一半發現新架構設計有誤，修正成本極高且團隊挫折感強；但在組裝線模式下，只要修改驗證腳本與目標文件，就可以快速重新運行自動化流程。
對工程師的啟發
這場分享的核心觀點是：AI Agent 的真正威力不在於幫你寫單個函數，而是在於它能將原本需要數十人、數個季度才能完成的「大規模單調遷移」，壓縮到數週內完成。
當我們能將複雜的工程問題分解為「可驗證的微小步驟」時，遺留代碼的遷移就不再是不可逾越的大山，而是一場可控的工業化生產。
來源：infoq.com - Moving Mountains: Migrating Legacy Code in Weeks instead of Years
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。