AI 把我們的研究時間從 7 天縮短到 15 分鐘——專訪 Vanguard 的 Gareth Yoder

Vanguard 現金帳務計畫技術負責人 Gareth Yoder 主張，透過 MCP 伺服器讓 AI 能查詢老舊大型主機（mainframe）程式碼庫，把研究週轉時間從七天縮短到 15 分鐘，也成為 Vanguard 現金帳務現代化工程的轉捩點。這場演講是實務工作者的第一手分享：一邊遷移高交易量的帳務系統——資料、生產端與消費端三線並行——一邊迎來中途才出現的 AI 工具；那個亮眼的數字只是整段遷移故事裡的其中一項成果，並非全貌。

Yoder 是從計畫內部發聲：他督導四到六個團隊，系統每天處理約 3,000 萬次呼叫、每日產生約 50 萬本客戶帳務。以下是他對三大遷移支柱、具體工程選型（CDC、冪等性、Snowflake 式 ID、schema registry、Kafka），以及最後收尾的五項領導心法的說明。文中數字與說法皆為他本人所述。

現金帳務是高頻、多通道的資金移轉系統

Yoder 將現金帳務定義為：從外部世界流入 Vanguard 券商帳戶的所有資金，加上帳戶之間移轉的現金，涵蓋 ACH、電匯等支付軌道。系統服務網頁、行動與批次三種通道，採 active-active、多區域部署，並具備容錯能力。

| 指標 | 數字（Yoder 所述） |
|---|---|
| 每日服務呼叫量 | 最高 3,000 萬次 |
| 每日產生客戶帳務 | 約 50 萬本 |
| 待遷移的生產端 | 35 個 |
| 待接上的消費端 | 50 個 |
| 目前每日使用 AI 工具的工程師 | 現金計畫工程師的 90% |

這項現代化工程屬於企業級優先事項，因此 Vanguard 讓三大支柱——資料遷移、生產端遷移、消費端遷移——並行推進，而非依序進行。

讓老舊程式碼庫可被 AI 查詢，是整件事的轉捩點

在 AI 工具出現之前，研究工作是與大型主機工程師和架構師合作，逆向工程出資料結構模型。轉機出現在老舊程式碼庫透過 MCP 伺服器開放給 AI 工具之後：大型主機工程師原本要花七天的分析週期，縮短成 15 分鐘的一則提示。

「回饋迴圈從七天縮短到 15 分鐘。對我們的產品負責人、技術主管和開發人員來說，都是巨大的勝利。」

同一個 MCP 伺服器後來也承接了生產端支援。Vanguard 原本要開許多場分組討論，協助 35 個生產端上線；等到遷移檔案（放在公司 wiki）透過 MCP 伺服器開放後，生產端就能靠提示自助解決，討論場次與人工協助的需求都大幅下降。

資料遷移採用標準 CDC，並刻意避免過度設計

Vanguard 採用業界標準的變更資料擷取（change data capture, CDC）做法，同時掃描老舊與雲端資料庫。團隊每天執行兩層稽核：先以資料列層級的筆數比對確保強一致性，再以逐欄位檢查確保強完整性——金額、帳戶資訊、州稅與聯邦稅扣繳，以及其他每一項舊系統屬性，都必須在雲端完全吻合。

Yoder 明確提醒：不要過度設計遷移方案，因為現代化完成後，對帳程式碼就會被淘汰。稽核工具只是鷹架，不是產品。

生產端遷移重新設計資料模型，而非直接搬遷

生產端有三種方式觸及舊有基礎設施：服務請求、包裝該服務請求的 API，以及最令人頭痛的直接寫入資料表——資料憑空出現在資料庫裡，來源不明。Vanguard 於是在包裝 API 的閘道層放上一套共通資料結構，用來執行雲端資料寫入。

團隊沒有選擇直接搬遷（lift-and-shift），而是借用金融科技領域的概念：冪等性（idempotency）、多寫入者之間的強一致性，以及類似 Snowflake ID 的 ID 產生方式。Yoder 點名堅持直接搬遷的生產端最難上線；反倒是願意停下來、依現代化能力重新設計的團隊，進展更快。

AI 工具也補上了系統之間的語意落差。雲端生態系使用人類可讀的帳務列舉值，舊系統則用狀態碼，Yoder 說 AI 工具把舊系統的意圖轉譯成雲端模型，「做得非常好」。

消費端無論即時、批次或串流，都共用同一套 schema registry

全部 50 個消費端不論走哪種通道，都透過 schema registry 取用資料，共有三種存取模式：

| 通道 | 機制 | 應用範例 |
|---|---|---|
| 即時 | GraphQL；消費端只訂閱自己需要的屬性 | 可用資金——流量最高的即時 API，供應客戶帳戶上顯示的餘額 |
| 批次 | 資料倉儲提供各消費端專屬的資料分享檢視 | 對帳、資料分析 |
| 串流 | Kafka topic 串流所有新增與更新 | 詐欺團隊將即時資料匯入詐欺工具 |

資料治理支撐了這套模型：消費端只看得到自身使用情境所需的屬性。串流方面，Vanguard 提供至少一次（at-least-once）送達保證，並延續生產端的冪等性，讓消費端能安全重試半途失敗的批次工作，不會產生重複帳務，同時仍能收到每一筆帳務事件。

商業案例中介資料，讓消費端登入表變成事故處理工具

上線只需一組三碼的應用程式程式碼，但 Vanguard 要求更多：每個消費端都要提供用途描述與商業案例理由。Yoder 舉的例子包括：一筆交易委託需要現金帳務來履行現金義務；退休帳戶需要法定強制提領；529 帳戶撥款到大學學費帳戶。

把這些描述分組後，AI 工具就能拼出準確影像：哪些使用情境已完成現代化、支援度最高的業務功能是什麼。它也能回答「SLA 若被違反，影響是什麼」——這在事故期間至關重要。若某個應用程式程式碼效能下滑、但仍維持在五個九可用性之上，商業案例就能告訴處理人員手上還有幾小時（批次）或幾分鐘（即時 API，客戶已開始收到錯誤，自癒刻不容緩）。Vanguard 正評估把商業案例理由與可觀測性、日誌追蹤結合，以加快反應速度。

五項領導心法，以及同時維護兩套程式碼庫的代價

Yoder 給領導層的收尾框架：

1. 讓老舊程式碼庫可被 AI 查詢——透過 MCP 伺服器開放後，研究時間從七天縮短到 15 分鐘。
2. 把遷移檔案當產品經營——它和業務功能一樣關鍵，因為每個生產端都靠它上線；最終會被淘汰，但過渡期間極其重要。
3. 重新設計，不要直接搬遷——最難上線的生產端與消費端，正是那些試圖把舊系統原封不動搬到新系統的。
4. 逐步匯入 AI——永遠沒有完美的起跑點；先開始，再隨技術演進持續調整。
5. 可觀測性沒有商量餘地——要清楚誰生產你的資料、誰消費你的資料，尤其當產品進入日常營運（BAU）、團隊必須每天維運時。

至於同時維護兩套程式碼庫，他的原則是「往前修，不要修過去」：在現代化後的版本修 bug，讓這成為生產端與消費端遷移的誘因。他也點出一項後果——這會打亂稽核日誌，因此白名單機制至關重要——並強調要有正確的指標、告警與可追溯性，且隨產品成長經常檢視。

值得關注的重點

這裡最值得帶走的，不是「七天變 15 分鐘」這個數字，而是它背後的做法：Vanguard 把老舊程式碼庫、遷移檔案與消費端商業案例都當成可被機器查詢的資產，再讓 AI 工具去讀。這等於把檔案與中介資料重新定位為基礎設施，而非額外負擔。目前還有兩條線未收攏。第一，Yoder 說 Vanguard 仍在評估如何把商業案例理由併入可觀測性與日誌追蹤——事故應變的效益目前仍是承諾，尚未兌現。第二，「團隊大腦」概念（共用的知識庫，讓新進工程師拿到與五年老手相同的提示上下文）與多代理工作流程都還在演進，尚未有成果報告。而為遷移打造的對帳與稽核工具，按 Yoder 自己的設計，註定要被淘汰——值得持續觀察：等舊系統完全退役、安全網撤下後，「往前修」與白名單的做法是否還站得住腳。