現代化可以從好幾年壓到幾個月，卡關的是銀行那套變更審核怎麼跟得上

https://claude.com/blog/how-to-prepare-for-ai-driven-code-modernization-projects

2026 年 9 月 23 日，Jonah Ezekiel 跟 Lexie Tonelli 在 Anthropic 的 Notes from the Field 寫他們管大型 code 現代化專案的經驗，做法從實際客戶部署來。兩人都是 forward deployed engineers，文章掛在 Enterprise AI、Claude Code。談的是關鍵系統、法規產業，現代化要怎麼組織。

銀行核心系統每一筆改動都得走變更管理、審核、核准。監理、稽核、業務都要求這套。流程讓關鍵系統值得信任，設計時的假設是：每筆改動是人寫的，每筆 diff 是人看的。

Agent 把寫改動加速了。以前當好幾年、全員投入的現代化，現在可以在幾個月、甚至幾週做完。動手前後的組織工作常常還是那麼多。卡關從產出改動，移到組織怎麼圍著那些 diff 動起來。

文章寫的是動手之前要做完的事：終點是什麼、合格證明（certificate）要帶什麼證據、放行政策（promotion policy）怎麼讓過關的改動進正式環境、前置條件、Agent 工作流、以及先在一小塊跑通再放大。

終點沒講清楚，後面每一筆都會變成「這樣算不算對」

終點是現代化完成時，技術棧跟行為要長什麼樣子。它決定這次是三種現代化裡的哪一種。

升級型（Uplift）是同一套技術棧的版本往上推，例如 C++11 到 C++20。棧本身沒問題、版本掉隊時走這條：執行環境走到生命週期終點、安全漏洞沒補、套件再也升不上去。終點是一個 runtime 版本跟一套套件。

轉換型（Transform）是換棧、行為固定，例如 COBOL 到 Java。問題在棧、行為被信任時走這條。終點包含升級型要的那些，再加上新 code 要跟的語言、框架、架構慣例。

重塑型（Reimagine）是在新架構上從零重建，行為一併改。行為跟 code 都要動時走這條。終點包含轉換型要的那些，再加上一份寫下來的新系統行為規格。

組織裡常吵要走哪一種。Jonah 跟 Lexie 寫，最靠近正式環境的人，通常想換棧、行為不動，把風險關住，也就是轉換型。另一邊，長期活在這份 codebase 裡的工程師想順便還技術債；其他業務利害關係人想趁機點新需求，也就是重塑型。兩邊都說得通。問題沒先收掉，後面會變成某一筆改動「算不算對」的吵架。一開始把路講清楚會多一點摩擦，整案會比較順。

要定終點，常常先搞懂現在這套系統。把舊 code 實際在做什麼抽出來，盤點現有行為，才好決定哪一段該改、哪一段該丟，也才知道這次是轉換還是重塑。這一步常常挖出沒人記得的商業邏輯跟邊界情況。

Claude 可以做掉很大一塊盤點：畫相依、把沒人記得是誰蓋的工作流寫下來。code modernization plugin 的 assess、map、extract-rules 會把商業規則挖出來，附原始碼出處，給工程師審。

只靠 Claude 的盤點，不見得抓得到一套舊系統真正怎麼動。業務使用者、開發者的訪談，加上內部文件，可以把洞補上。前面花時間收脈絡，後面工作流做的每一個決定都吃這份品質。

重塑型還要多做一件事：詳細的行為規格要寫下來，跟使用者群組談妥。

定終點的同時，組織要問這次現代化值不值得做。現代化舊系統可以降低後續維護跟營運成本。他們寫，就現場經驗來看，成本下降通常不是大多數現代化案子的主因。

風險下降常常才是最重要的好處。討論要不要做的時候，要把「不做」的風險一起放到桌上。系統帶著沒補的漏洞，可能變成資安事件，或一次大到足以把生意本身打掉的中斷。執行環境沒人支援，或懂這套系統的工程師愈來愈少，都會把風險往上推。

Claude Code 這類 agentic 寫碼工具把時程壓短了，預算還是很難估，組織就卡住。他們公開過一些大型現代化的成本，別人也有，可以當粗略基準。後面有預算怎麼估。

要讓案子動起來，通常最難的是內部共識，以及擁有這套系統的團隊、依賴它的團隊，願意承諾。商業理由跟目標常常要在領導層定下來，這一步會比較好走，後面合格證明跟放行政策的取捨也有錨。利害關係人對一筆改動能帶多少風險談不攏時，「不做現代化」的風險是另一個砝碼。

合格證明寫給 Agent 迭代，也寫給最後要合併的人

合格證明是每一筆現代化改動都要過的條件或測試。選的條件，合起來要能最有力地證明：這筆改動對得上終點，是對的。

每一條都該能在沒有人盯著的情況下勾得過，Agent 工作流才能自己迭代到過關；過不了，再標給人看。

裡面放什麼看終點，通常會從這張清單裡抽。原本的測試套件要過。現代化期間 Claude 寫的測試要全過。測試覆蓋率要到談好的門檻。效能基準留在談好的範圍裡。Claude 做獨立的對抗審查，每一次開新的 context window，找不到擋路的問題。有使用者介面的，Claude 用 computer use 找不到回歸。現況版本跟目標版本，同一組輸入要產出同一組輸出，輸入可以是線上的、錄下來的、或 Claude 生的。持久化狀態跟傳輸格式，在現況跟目標之間來回轉得回來。改動在 staging（測試環境）跑過談好的一段時間，錯誤率、延遲、警示沒有回歸。靜態分析跟安全掃描沒有新發現。編譯目標的話，建置要乾淨，型別檢查要過。

合格證明要跟之後會審、會放行進正式環境的人一起寫。現在就依賴這份 codebase 的開發者、使用者群組、業務負責人，在合格證明跟 Agent 工作流還在設計的時候拉進來。

他們的專業會決定合格證明量什麼。他們早進來，改動送到審核時才比較買帳。寫完有一個檢查法：他們願不願意只憑合格證明上的證據就合併。他們在裡面看見自己的門檻，後面的放行政策就可以比較輕。

合格證明要比對什麼、怎麼比，跟現代化類型有關。

升級型，對等是對原本那份 codebase，原本的測試套件可以當合格證明的核心。

轉換型，對等也是對原本那份，但原本的測試套件很少能在新棧上跑。正式流量重放、舊系統跟新系統之間的差異測試、跟正式環境並行上線，這幾件會做掉大部分的工作。

重塑型，合格證明錨在行為規格上。這是最難的一種。規格不像既有系統那樣，可以拿去對 diff，模型判斷會佔比較大一塊，結果也比較容易飄。這裡的合格證明靠從規格寫出來的測試、Claude 對每一筆改動對規格做的獨立對抗審查，以及新系統仍保留舊行為的那些地方做差異檢查。規格一釐清，合格證明就得改：規格的洞，常常先在這裡冒出來。

舊系統常常測試覆蓋薄、測試不穩、遙測很少。定義合格證明的一部分工作，就是把這些缺口找出來。強的合格證明撐不起來時，這一步最有用的其中一件事，是讓 Claude 把缺的證據補出來：把並行上線的環境站起來、做重放測試架、或多寫測試。

人一筆一筆看 diff，速度會跟不上 Agent 產出

放行政策是事先寫好、談妥的分級審核路徑，決定一筆改動要人看到多深，現代化才趕得上可接受的時程。

跟合格證明一樣，這一步要跟審核的人一起做，能嵌進組織既有的變更管理就嵌進去。細節會因組織、因它面對的風險取捨而不同，有幾條到處都成立。

改動按影響範圍跟 Agent 的把握分級。組織自己有變更或風險分級，就用那套。關鍵路徑維持完整的人審。

反覆出現的標記，修源頭。把被標記的改動過一段時間歸類來看。同一類標記一直冒出來，去改 Agent 工作流或合格證明，不要一筆一筆審。

輸出格式跟審核的人一起設計。談妥什麼資訊、什麼格式審得最快，哪些訊號比別的更讓人有把握。後面做工作流時，請他們先看早期樣本。

SME 的時間要花得準。SME 不會讀每一筆最後的 diff，他們的判斷仍是最缺的輸入。讓他們直接進最高風險那幾級，以及每一級裡被標記的 Agent 決定，不必在大 diff 裡翻。少數專家小時，就能顧到帶最多風險的那些改動。

這些規則很多是把 SME 的工時往前搬，專案一開始就請他們進來。他們的回饋會在整份 codebase 開跑前，把合格證明跟 Agent 工作流調好。

他們在樣本上的簽字，也會變成高把握區間走比較輕審核路徑的理由。傳統沒有 Agent 的做法，審核壓在最後。

放行政策還要反映這次現代化落在速度跟審核深度之間的哪一點。趕硬期限的現代化，例如執行環境即將失去支援，需要比較快的政策、比較輕的人審，並且明白約定每一筆改動接受比較多風險。

時程比較長的現代化，負擔得起比較深的人審、比較慢的切換。利害關係人會依風險胃口跟限制落到光譜上不同的點，值得在動手之前鎖死。

法規環境裡，任何改動走比較輕的人審，都會讓人真的不舒服。個別核准的人會猶豫要不要簽字，因為一筆壞改動的風險掛在他身上；領導層扛的是系統老化這件更大的風險。

Jonah 跟 Lexie 寫，放行政策的指令最好從組織頂層下來。事先談妥，一筆 bug 進正式環境時，責任是共擔的，不會釘在簽字的那一個人頭上。

這些仍依賴合格證明細到能當真正的證據，以及審核的人夠理解 Claude 是怎麼走到這一筆改動，才信得過。

環境、CI/CD、審核人力跟合規，常常卡在現代化團隊外面

平台或基礎設施管主機，QA 或釋出工程管測試容量，資安跟合規管核准。那些團隊常常有自己的 backlog 或核准流程。終點、合格證明、放行政策還在談的時候，需求一確定就要開口。

環境這邊，要有一台專用的遠端主機跑工作流，codebase 跟其他相關來源 Claude 要夠得到。合格證明要求的測試容量要有。能把合格證明撐厚的東西也要有：正式環境遙測、並行上線的環境、或拿來重放的正式資料。

codebase 跟 CI/CD 這邊，要有一份相依圖，根據建置與編譯紀錄、import 分析、或執行期追蹤。plugin 的 map 是起點，codebase 又大又舊時，前面可能還要做更多。套件與相依要怎麼處理，寫進終點定義。需要的話，相容性檢查準備好加進 CI/CD。若在原地現代化，談妥程式碼凍結政策。還在開發的人要有溝通計畫，涵蓋凍結、以及新的相容性要求。

團隊跟審核這邊，依賴這份 codebase 的其他團隊要談好怎麼參與，例如在合格證明上簽字，或依放行政策來審，並且把審核時間空下來。

資安跟合規這邊，Claude Code 要有一條被核准、可以用在原始碼上的模型通路。Agent 工作流走最小權限：只寫進現代化分支，沒有正式環境帳密。祕密跟個人資料從現代化分支清掉或遮掉。每一筆改動可追蹤，PR 連到一份 Agent 逐字稿跟合格證明的證據。新相依要做授權跟漏洞檢查。

工作流圍著終點、合格證明、放行政策來建，先小範圍跑通

用 Claude Code 做出客製的動態工作流。它把現代化拆成許多比較小、可並行的 subagent 支線來產出改動。

他們建議從 code modernization plugin 起步，工作流可能用到的東西放到檔案系統上，或經 MCP 讓 Claude 夠得到。終點、合格證明、放行政策、codebase、文件，以及合格證明要用的資料來源或工具，都算。他們這篇也可以丟給 Claude 當脈絡。這些構成專案的中央知識庫。

東西就位之後，建現代化工作流是比較容易的那一段。SME 視需要審 Claude 的產出，包括針對這份 codebase 的 skills、抽出來的規則，下游要靠它之前先看過。

把做出來的東西拿到 codebase 的小塊上跑，請 SME 看它產出的改動、Agent 的過程、以及合格證明過關的證據，再去調。

問題冒出來時，改的是工作流，不是每一筆改動。目標是有把握：放大之後，改動幾乎處處都能過合格證明，審核的人願意依放行政策合併。

跑的時候，先在 codebase 的一小塊從頭到尾做完現代化，含依放行政策審核、把改動合併進去。還便宜的時候把行不通的修好，重複到有把握，再放大到整份 codebase。

轉換型跟重塑型是在既有系統旁邊把目標建起來，完成後再切過去。升級型多一條路：在還活著的 codebase 上原地現代化，開發同時繼續。

系統不能停，或 codebase 變得很快、旁邊那份現代化複本很難跟上時，通常走這條。他們看過能用的做法是：從依賴的葉子往內，把 codebase 切成邏輯分區；一次凍結、現代化一個分區；CI/CD 擋住新的提交，不能把已經現代化的分區改回去。

法規環境裡，驗證常常比寫改動更貴

常有人問，這種現代化 token 會花多少。每次都不一樣，主要成本驅動大概是這幾件。codebase 有多少是要讀的、有多少是要改的。合格證明有多厚：在法規環境裡，驗證通常比寫那筆改動佔更大一份。合格證明要求多少新測試、多少測試修復。跑的過程中，其他團隊在旁邊合併，要對帳多少。

在一小塊 codebase 做完現代化時，量 token 用量，再外推到整次。試點看不到的，例如活的 codebase 上的對帳，當未知。這樣能估出整次現代化的成本下限。

試點量到的數字，也會指出 Agent 工作流哪裡能把成本壓下來。找出吃最多 token 的段落，想怎麼讓它省。運算重的驗證訊號放到比較便宜的檢查後面，容易過的先過，重的才跑。

機械、量大、合格證明能完整勾掉的工作，可以考慮用 Sonnet 這類在成本跟能力之間取平衡的模型。難的轉換、以及核對正確性的對抗審查，留給較聰明的模型。

便宜的模型過不了合格證明時，也可以升到較貴的模型。試點時把重試率仔細看過，因為連著幾次便宜的嘗試，可能比一次貴的更貴。把工作流跟試點資料都給 Claude，它可以一起做掉很大一塊分析。

現代化完的 codebase 是一份產出。其他產出是做出它的工作流、一份寫明什麼叫對的合格證明、一套變更管理已經接受的放行政策，以及每一筆進去的改動留下的證據軌。把這套打法寫成可重用的資產，下一輪升級或改寫，模式已經在。

Anthropic 的 forward deployed engineers 會跟客戶在最關鍵的系統上走這六步。