動(dòng)代碼遷移實(shí)戰(zhàn)：從Spring Boot 2到3的現(xiàn)代化升級(jí))
為什么“用 AI 遷移老代碼”突然成了硬需求過去一年里我身邊不少團(tuán)隊(duì)都在做同一件事把跑了五六年甚至十年的老系統(tǒng)從舊框架、舊 JDK、舊中間件上搬下來。有的是因?yàn)?Spring 版本太老安全漏洞沒人修;有的是因?yàn)?JDK 8 的維護(hù)成本越來越高想往 JDK 17 甚至 21 上走;還有的是因?yàn)闃I(yè)務(wù)方要求上云順手要把單體拆成服務(wù)。這件事的難點(diǎn)不在于“重構(gòu)業(yè)務(wù)邏輯”而在于“遷移本身的工程量”。一個(gè)大型遺留系統(tǒng)里真正需要人來逐行讀的代碼可能只有兩成剩下八成都是模式化的勞動(dòng)改 import、換 API、調(diào)整配置、處理廢棄方法、修復(fù)編譯錯(cuò)誤。這些工作重復(fù)、機(jī)械、費(fèi)時(shí)但又是遷移動(dòng)不動(dòng)就要以“人月”為單位計(jì)算的主要原因。AI 編程工具的興起恰好踩中了這個(gè)需求。從過去的“AI 幫你寫新代碼”到現(xiàn)在的“AI 幫你改老代碼”這個(gè)變化比很多人想象中更大。Claude Code、GitHub Copilot、Cursor 這類工具已經(jīng)不只是補(bǔ)全代碼而是能理解項(xiàng)目結(jié)構(gòu)、讀取編譯錯(cuò)誤、定位廢棄 API、跨文件修改甚至自動(dòng)跑測(cè)試驗(yàn)證改動(dòng)結(jié)果。換句話說AI 正在從“單點(diǎn)輔助”變成“遷移流水線的執(zhí)行者”。這篇文章的目標(biāo)很簡(jiǎn)單講清楚用 AI 做代碼現(xiàn)代化和遷移時(shí)真正有效的工作流是什么哪些步驟適合交給 AI哪些必須人來把關(guān)以及落地過程中最容易踩的坑。讀完你會(huì)得到一套可以復(fù)用的方法而不是一堆“AI 很強(qiáng)大”的正確廢話。1. 代碼遷移的傳統(tǒng)痛點(diǎn)和 AI 的介入方式先說一個(gè)真實(shí)場(chǎng)景。假設(shè)我們要把一個(gè)基于 Spring Boot 2.2 JDK 8 的老項(xiàng)目升級(jí)到 Spring Boot 3.2 JDK 17。看似只是版本號(hào)變了實(shí)際改動(dòng)范圍包括javax.* 到 jakarta.* 的包名遷移這是 Spring Boot 3 最廣為人知的破壞性變更大量 Spring Security 配置 API 的廢棄與替換三方庫版本的兼容性調(diào)整一些反射、字節(jié)碼操作的 JDK 模塊限制問題測(cè)試代碼里依賴舊 API 的斷言邏輯構(gòu)建腳本中 Maven 或 Gradle 插件的版本對(duì)齊傳統(tǒng)做法是先全局搜索 javax 替換成 jakarta然后啟動(dòng)項(xiàng)目看編譯報(bào)錯(cuò)一個(gè)一個(gè)改。運(yùn)氣好兩三天搞定;運(yùn)氣不好改完一處冒出來三處最后還要處理運(yùn)行時(shí)才暴露的問題。這個(gè)過程里有三個(gè)痛點(diǎn)第一重復(fù)勞動(dòng)集中。包名替換、注解遷移、配置文件改格式這些操作沒有技術(shù)含量但數(shù)量巨大。第二上下文斷裂。很多 API 替換不是“一對(duì)一”的而是“一對(duì)多”或者“多對(duì)一”。比如 Spring Security 中 WebSecurityConfigurerAdapter 的廢棄需要你理解新的 SecurityFilterChain 配置方式而不是光靠搜索替換就能完成。第三驗(yàn)證成本高。改完一百個(gè)文件你怎么知道沒有遺漏編譯通過不等于運(yùn)行正常運(yùn)行正常也不等于所有分支都被覆蓋到。AI 工具的介入方式正好針對(duì)這三個(gè)痛點(diǎn)它能快速處理大批量模式化替換而且不會(huì)像正則替換那樣誤傷邊界情況它能基于整個(gè)倉庫的上下文理解 API 之間的映射關(guān)系而不是只做文本匹配它可以反復(fù)迭代編譯失敗就把錯(cuò)誤拋給它它會(huì)自己定位文件、修改代碼、再驗(yàn)證所以用 AI 做遷移的核心理念不是“讓 AI 完全取代人”而是讓 AI 承擔(dān)重復(fù)勞動(dòng)讓人專注在決策和審核上。2. AI 代碼遷移與傳統(tǒng)工具的本質(zhì)區(qū)別可能有人會(huì)說IDEA 的重構(gòu)功能也能做包名替換也能做 API 遷移為什么還要用 AI這個(gè)問題問得非常好。事實(shí)上傳統(tǒng) IDE 重構(gòu)確實(shí)能處理一部分“語法層面的遷移”比如重命名類、移動(dòng)包、調(diào)整方法簽名。但對(duì)于“語義層面的遷移”傳統(tǒng)工具就無能為力了。舉一個(gè)具體例子JDK 8 升級(jí)到 JDK 17 時(shí)SecurityManager被標(biāo)記為廢棄準(zhǔn)備移除。如果你的代碼里調(diào)用了System.getSecurityManager()IDE 能幫你把方法調(diào)用的地方全部列出來但它不會(huì)告訴你“業(yè)務(wù)上應(yīng)該怎么替代這個(gè)安全模型”。因?yàn)檫@已經(jīng)不是代碼層面的問題而是架構(gòu)層面的問題。AI 能做的是在理解你整個(gè)項(xiàng)目上下文的基礎(chǔ)上給出“這段代碼在新的安全模型下應(yīng)該怎么寫”的建議并直接修改到代碼里。它不是在執(zhí)行 IDE 的重構(gòu)規(guī)則而是在模擬一個(gè)熟悉這個(gè)技術(shù)棧的工程師在改代碼。另一個(gè)本質(zhì)區(qū)別在于錯(cuò)誤反饋的閉環(huán)。傳統(tǒng)流程是人改代碼編譯器報(bào)錯(cuò)人再看代碼再改。AI 流程是AI 改代碼AI 看編譯器報(bào)錯(cuò)AI 再改直到編譯通過。以 Claude Code 為代表的編程 Agent 工具甚至可以在自己的循環(huán)里反復(fù)執(zhí)行命令、讀取日志、修改文件形成一個(gè)自動(dòng)化迭代回路。這意味著遷移工作中最耗時(shí)的“編譯-報(bào)錯(cuò)-修復(fù)”循環(huán)可以由 AI 自主完成人只需要在關(guān)鍵節(jié)點(diǎn)介入審查。3. 環(huán)境準(zhǔn)備選擇 AI 工具與配置本地工作區(qū)如果要用 AI 做代碼遷移環(huán)境準(zhǔn)備比寫新代碼要更講究。因?yàn)檫w移工作涉及大量“讀取文件、搜索代碼、執(zhí)行命令”的能力不同工具能發(fā)揮的作用差異很大。3.1 工具選擇思路目前主流 AI 編程工具有兩類一類是 IDE 插件型比如 GitHub Copilot、Cursor 等。它們的優(yōu)勢(shì)是和你當(dāng)前的開發(fā)環(huán)境深度綁定適合“人在回路”的逐文件修改。另一類是 Agent 型比如 Claude Code。它們運(yùn)行在終端里能直接操作文件系統(tǒng)、執(zhí)行 Shell 命令、讀取編譯日志更適合“批量任務(wù)”和“自動(dòng)化流水線”。從最近的社區(qū)熱度來看Claude Code 這類工具在“任務(wù)級(jí)編程”場(chǎng)景下的表現(xiàn)尤其突出。如果你要處理的是整個(gè)倉庫級(jí)別的遷移Agent 型的優(yōu)勢(shì)會(huì)比 IDE 插件更大。需要說明一點(diǎn)各家工具的版本迭代非常快本文不會(huì)寫死具體的版本號(hào)。安裝時(shí)請(qǐng)以官方倉庫和文檔為準(zhǔn)核心思路是通用的。3.2 Claude Code 的安裝與配置示例以 Claude Code 為例安裝過程本身不復(fù)雜但有幾個(gè)細(xì)節(jié)值得注意。如果使用 npm 安裝基本命令如下npm install -g anthropic-ai/claude-code安裝完成后在項(xiàng)目根目錄運(yùn)行claude第一次運(yùn)行時(shí)需要完成登錄和 API 配置。這里要提醒一句Claude Code 會(huì)讀取你的項(xiàng)目文件并向模型發(fā)送請(qǐng)求所以不要在包含敏感信息的目錄下直接運(yùn)行最好先確認(rèn)項(xiàng)目的保密級(jí)別。對(duì)于企業(yè)項(xiàng)目建議使用企業(yè)版或本地方案避免涉密代碼外傳。配置完成后建議先把項(xiàng)目結(jié)構(gòu)梳理清楚。一個(gè)典型的交互流程如下cd /path/to/your/legacy-project claude進(jìn)入交互界面后可以先讓 AI 讀取項(xiàng)目說明和構(gòu)建文件例如請(qǐng)先閱讀 pom.xml 和 src/main/resources/application.yml 然后告訴我這個(gè)項(xiàng)目的 Spring Boot 版本、JDK 版本和主要依賴。這一步非常重要。AI Agent 只有在充分理解項(xiàng)目背景后后續(xù)的遷移工作才會(huì)準(zhǔn)確。如果你一上來就直接說“幫我升級(jí)到 Spring Boot 3”它會(huì)缺乏上下文很容易在錯(cuò)誤的文件里做修改。3.3 倉庫級(jí)別的準(zhǔn)備工作除了工具安裝還需要做好倉庫的工程準(zhǔn)備。建議在正式讓 AI 動(dòng)手前完成以下三步建立分支遷移工作必須在獨(dú)立分支上執(zhí)行絕不在主干上直接改。跑通基線構(gòu)建先用當(dāng)前代碼跑一次完整構(gòu)建mvn clean package或gradle build確認(rèn)遷移前的代碼是“可編譯、可測(cè)試”的。如果原始代碼就是壞的AI 改完之后你很難區(qū)分哪些是它引入的問題哪些是歷史遺留問題。記錄基線測(cè)試結(jié)果把遷移前的測(cè)試用例執(zhí)行結(jié)果記錄下來作為遷移后的對(duì)照基準(zhǔn)。這樣才能在 AI 改完代碼之后用“編譯通過 測(cè)試通過 關(guān)鍵邏輯審查”三個(gè)維度驗(yàn)證遷移質(zhì)量。4. 核心流程拆解AI 遷移的五個(gè)階段在真正動(dòng)手之前先把遷移工作的整體流程拆解清楚。根據(jù)我在多個(gè)項(xiàng)目中的觀察一套高效的 AI 輔助遷移流程通常分為五個(gè)階段。4.1 階段一全量盤點(diǎn)這個(gè)階段的目標(biāo)是讓 AI 幫你建立遷移的“作戰(zhàn)地圖”。你需要讓 AI 掃描整個(gè)項(xiàng)目識(shí)別出所有涉及遷移的關(guān)鍵點(diǎn)。以 Spring Boot 2 到 3 的遷移為例可以這樣下達(dá)指令請(qǐng)分析當(dāng)前項(xiàng)目的 Spring Boot 版本、JDK 版本和所有依賴。 列出所有可能需要修改的地方包括但不限于 - javax 包的 import 語句 - Spring Security 配置類 - 數(shù)據(jù)庫訪問層的廢棄 API - 測(cè)試代碼中的兼容性問題 - 構(gòu)建腳本中的插件版本 請(qǐng)把分析結(jié)果按高影響/中影響/低影響分類輸出。AI 會(huì)返回一份清單。這份清單的價(jià)值在于它讓你在動(dòng)手改代碼之前就大概知道遷移的規(guī)模有多大、風(fēng)險(xiǎn)集中在哪些模塊。很多遷移失敗不是因?yàn)楦牟粍?dòng)代碼而是因?yàn)榈凸懒四承╇[藏依賴的改動(dòng)成本。4.2 階段二制定遷移計(jì)劃拿到盤點(diǎn)結(jié)果后不要急著讓 AI 全量開改。正確做法是把遷移工作拆成若干個(gè)子任務(wù)排好優(yōu)先級(jí)。推薦的執(zhí)行順序是構(gòu)建腳本和依賴管理優(yōu)先改這是所有代碼編譯的基礎(chǔ)基礎(chǔ)配置文件和公共模塊先遷移比如通用工具類、公共實(shí)體類業(yè)務(wù)模塊按依賴關(guān)系從底層到上層逐個(gè)遷移測(cè)試代碼最后遷移等主代碼編譯通過了再修測(cè)試你可以把計(jì)劃直接發(fā)給 AI讓它在執(zhí)行時(shí)遵守我將按照以下順序執(zhí)行遷移 第一步修改 pom.xml更新 Spring Boot 版本到 3.x替換所有 javax 為 jakarta。 第二步修改公共模塊的編譯錯(cuò)誤。 第三步逐個(gè)遷移業(yè)務(wù)模塊。 每一步完成之后都執(zhí)行一次 mvn compile直到編譯通過再進(jìn)入下一步。 請(qǐng)確認(rèn)理解。讓 AI 明確執(zhí)行順序能避免它東改一下西改一下最后整個(gè)倉庫處于半遷移狀態(tài)、編譯錯(cuò)誤鋪天蓋地的混亂局面。4.3 階段三迭代式遷移執(zhí)行這是核心階段也是 AI 價(jià)值最大的階段。你需要輸入的關(guān)鍵指令是讓 AI 自己形成“修改-編譯-修復(fù)”的循環(huán)。比如現(xiàn)在開始執(zhí)行第一步。修改完成后運(yùn)行 mvn compile。 如果編譯失敗請(qǐng)根據(jù)報(bào)錯(cuò)信息繼續(xù)修復(fù)直到編譯通過。 每次修改文件時(shí)請(qǐng)說明修改了哪些地方以及為什么這樣改。在這個(gè)階段AI 會(huì)做類似下面的事情搜索所有javax.servlet的 import批量替換成jakarta.servlet運(yùn)行 Maven 編譯遇到WebSecurityConfigurerAdapter報(bào)錯(cuò)搜索類定義找到新的SecurityFilterChainBean 寫法重寫配置類再次編譯循環(huán)往復(fù)直到編譯通過整個(gè)過程看起來很像一個(gè)初級(jí)工程師在干活但速度要快得多。不過要注意AI 在“改到編譯通過”這件事上很有耐心但它不會(huì)主動(dòng)思考“這個(gè)改法雖然在編譯層面沒問題但在運(yùn)行層面是否等價(jià)”。這就是為什么遷移過程中必須有人的審查節(jié)點(diǎn)。4.4 階段四人工審查與邏輯核對(duì)當(dāng) AI 報(bào)告“編譯通過”之后最重要的工作才剛剛開始。你需要做的是讓 AI 輸出一份變更摘要然后針對(duì)高風(fēng)險(xiǎn)文件做人工 diff 審查。具體來說重點(diǎn)關(guān)注以下內(nèi)容業(yè)務(wù)邏輯是否被意外改動(dòng)比如某個(gè)條件判斷被 AI 順手“簡(jiǎn)化”了配置類型是否發(fā)生變化比如原本是讀取配置項(xiàng)被 AI 改成了硬編碼異常處理行為是否不一致比如原本捕獲 IOException被 AI 改成了捕獲 Exception線程安全相關(guān)代碼是否被誤改如果發(fā)現(xiàn) AI 的改動(dòng)超出遷移范圍你需要明確糾正并讓它回退。這里給出一個(gè)糾偏指令的示例在剛才的修改中src/main/java/com/example/service/OrderService.java 中原本的查詢條件被改動(dòng)導(dǎo)致業(yè)務(wù)邏輯可能發(fā)生變化。 這個(gè)文件不屬于本次遷移的必要改動(dòng)范圍 請(qǐng)回退該文件中與遷移無關(guān)的邏輯變更只保留 javax 到 jakarta 的 import 替換。4.5 階段五驗(yàn)證與收尾遷移代碼通過了人工審查之后需要做完整驗(yàn)證。建議按以下順序執(zhí)行mvn clean package mvn test如果項(xiàng)目有集成測(cè)試或端到端測(cè)試也要一并運(yùn)行。對(duì)于沒有自動(dòng)化測(cè)試覆蓋的模塊需要人工回歸驗(yàn)證。最后把變色龍一樣的雜項(xiàng)處理干凈更新 README 中的版本說明、清理廢棄依賴、刪除不再必要的兼容層代碼。到這里一次完整的 AI 輔助遷移工作就算結(jié)束了。5. 完整示例用 Claude Code 遷移 Spring Boot 2 到 3這一節(jié)我用一個(gè)最小化示例展示完整的遷移過程。示例項(xiàng)目結(jié)構(gòu)如下為了演示只保留了核心文件legacy-demo/ ├── pom.xml ├── src/main/java/com/example/legacy/ │ ├── LegacyApplication.java │ ├── config/SecurityConfig.java │ └── controller/HelloController.java ├── src/main/resources/ │ └── application.yml └── src/test/java/com/example/legacy/ └── LegacyApplicationTests.java5.1 原始代碼先看遷移前的核心文件。文件pom.xml?xml version1.0 encodingUTF-8? project xmlnshttp://maven.apache.org/POM/4.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd modelVersion4.0.0/modelVersion parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.2.13.RELEASE/version relativePath/ /parent groupIdcom.example/groupId artifactIdlegacy-demo/artifactId version1.0.0/version properties java.version1.8/java.version /properties dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-security/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependency /dependencies /project文件src/main/java/com/example/legacy/config/SecurityConfig.javapackage com.example.legacy.config; import org.springframework.context.annotation.Configuration; import org.springframework.security.config.annotation.web.builders.HttpSecurity; import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity; import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter; Configuration EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http .authorizeRequests() .antMatchers(/public/**).permitAll() .anyRequest().authenticated() .and() .formLogin(); } }文件src/main/java/com/example/legacy/controller/HelloController.javapackage com.example.legacy.controller; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; import javax.servlet.http.HttpServletRequest; RestController RequestMapping(/api) public class HelloController { GetMapping(/hello) public String hello(HttpServletRequest request) { return Hello, request.getRemoteAddr(); } }文件src/test/java/com/example/legacy/LegacyApplicationTests.javapackage com.example.legacy; import org.junit.jupiter.api.Test; import org.junit.jupiter.api.extension.ExtendWith; import org.springframework.boot.test.context.SpringBootTest; import org.springframework.test.context.junit.jupiter.SpringExtension; ExtendWith(SpringExtension.class) SpringBootTest class LegacyApplicationTests { Test void contextLoads() { } }5.2 啟動(dòng) AI 遷移在項(xiàng)目根目錄啟動(dòng) Claude Codecd legacy-demo claude在交互界面中輸入以下指令這是一個(gè)基于 Spring Boot 2.2 和 JDK 8 的遺留項(xiàng)目。 我需要將它遷移到 Spring Boot 3.2 和 JDK 17。 請(qǐng)先閱讀 pom.xml、SecurityConfig.java、HelloController.java 和 LegacyApplicationTests.java梳理出所有需要修改的地方。 然后按以下順序執(zhí)行 1. 更新 pom.xml 中 Spring Boot 版本和 Java 版本。 2. 替換所有 javax 為 jakarta 的 import。 3. 修復(fù) Spring Security 配置類的廢棄 API。 4. 修改測(cè)試代碼中不兼容的注解。 每一步完成后都運(yùn)行 mvn compile 或 mvn test直到全部通過。5.3 AI 修改后的關(guān)鍵文件按照上述流程AI 修改后的核心文件預(yù)期如下。文件pom.xml修改后?xml version1.0 encodingUTF-8? project xmlnshttp://maven.apache.org/POM/4.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd modelVersion4.0.0/modelVersion parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.2.0/version relativePath/ /parent groupIdcom.example/groupId artifactIdlegacy-demo/artifactId version1.0.0/version properties java.version17/java.version /properties dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-security/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependency /dependencies /project文件src/main/java/com/example/legacy/config/SecurityConfig.java修改后package com.example.legacy.config; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.security.config.annotation.web.builders.HttpSecurity; import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity; import org.springframework.security.web.SecurityFilterChain; Configuration EnableWebSecurity public class SecurityConfig { Bean public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { http .authorizeRequests(authorize - authorize .requestMatchers(/public/**).permitAll() .anyRequest().authenticated() ) .formLogin(); return http.build(); } }文件src/main/java/com/example/legacy/controller/HelloController.java修改后package com.example.legacy.controller; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; import jakarta.servlet.http.HttpServletRequest; RestController RequestMapping(/api) public class HelloController { GetMapping(/hello) public String hello(HttpServletRequest request) { return Hello, request.getRemoteAddr(); } }5.4 關(guān)鍵點(diǎn)解釋上面三處修改分別對(duì)應(yīng)了三種典型遷移模式第一pom.xml的修改是“版本升級(jí)型”。Spring Boot 版本從 2.2.13 跳到 3.2.0JDK 版本從 1.8 升到 17。這個(gè)修改本身很簡(jiǎn)單但它會(huì)引發(fā)后續(xù)一連串連鎖變更。第二HelloController.java的修改是“純包名替換型”。代碼邏輯完全不變只有javax.servlet變成了jakarta.servlet。這種改動(dòng)適合批量處理也最容易驗(yàn)證——編譯通過基本就說明沒問題了。第三SecurityConfig.java的修改是“API 重構(gòu)型”。這是三種類型中最復(fù)雜的。在 Spring Security 5.x 中WebSecurityConfigurerAdapter是主流寫法;到了 Spring Security 6.0這個(gè)類已經(jīng)被移除必須用SecurityFilterChainBean 的方式聲明。同時(shí)antMatchers也改成了requestMatchers?？梢钥吹降谌幐膭?dòng)是無法通過“全局搜索替換”或者“IDE 重構(gòu)”自動(dòng)完成的。AI 必須理解 Spring Security 新版本的設(shè)計(jì)思路才能寫出正確的替代代碼。這也說明了為什么用 AI 做遷移時(shí)選擇能力較強(qiáng)的模型非常重要。5.5 驗(yàn)證結(jié)果遷移完成后運(yùn)行構(gòu)建驗(yàn)證mvn clean test預(yù)期輸出中會(huì)包含類似下面的內(nèi)容[INFO] BUILD SUCCESS [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0如果測(cè)試通過說明這個(gè)最簡(jiǎn)單的示例已經(jīng)完成了遷移。實(shí)際項(xiàng)目中文件數(shù)量可能是幾十甚至幾百倍驗(yàn)證的復(fù)雜程度也會(huì)成倍上升。但核心流程是相同的。6. 提示詞設(shè)計(jì)與遷移效率的關(guān)系很多人覺得用 AI 編程就是“把需求發(fā)給 AI”實(shí)際上提示詞的質(zhì)量直接決定遷移工作的成敗。我見過不少團(tuán)隊(duì)用 AI 做遷移最后發(fā)現(xiàn) AI 改出來的代碼“編譯過了但不敢上線”。原因不是 AI 能力不行而是提示詞里沒有說清楚邊界和約束。一條高質(zhì)量的遷移提示詞至少應(yīng)該包含四個(gè)要素項(xiàng)目背景當(dāng)前使用的技術(shù)棧版本、目標(biāo)版本任務(wù)邊界哪些模塊要改哪些模塊不要?jiǎng)訄?zhí)行策略每個(gè)步驟完成后的驗(yàn)證方式輸出要求修改文件的列表、修改原因、風(fēng)險(xiǎn)說明對(duì)比兩組提示詞低質(zhì)量提示詞幫我升級(jí) Spring Boot 版本。這條指令的問題在于AI 不知道該升到什么版本不知道要不要處理 Security 配置不知道改完要不要跑測(cè)試更不知道哪些業(yè)務(wù)代碼不能動(dòng)。結(jié)果要么是亂改要么是反復(fù)問你問題效率極低。高質(zhì)量提示詞請(qǐng)將本項(xiàng)目從 Spring Boot 2.2.13 遷移到 3.2.0JDK 從 8 升級(jí)到 17。 本次遷移只允許修改 pom.xml、src/main/java 和 src/test/java 下的文件 不允許修改數(shù)據(jù)庫腳本和部署配置文件。 執(zhí)行順序 1. 更新依賴版本。 2. 修改編譯錯(cuò)誤。 3. 運(yùn)行 mvn test 驗(yàn)證。 在所有步驟完成前不要停止。 每次修改后請(qǐng)簡(jiǎn)要說明修改了哪些文件和原因。這條指令明確了目標(biāo)版本、文件范圍、執(zhí)行順序和驗(yàn)證方式AI 的產(chǎn)出質(zhì)量會(huì)顯著提高。7. 常見問題與排查方法用 AI 做遷移時(shí)遇到的問題往往不在“AI 會(huì)不會(huì)寫代碼”而在“AI 寫完之后你發(fā)現(xiàn)不了問題”。下面幾個(gè)是我在實(shí)際中看到的高頻問題。問題現(xiàn)象可能原因排查方式解決方案AI 一直反復(fù)編譯失敗陷入死循環(huán)項(xiàng)目存在嚴(yán)重的歷史編譯問題手動(dòng)運(yùn)行mvn compile查看完整報(bào)錯(cuò)先手動(dòng)修復(fù)基線編譯問題再交給 AIAI 修改了大量無關(guān)文件提示詞中沒有明確文件范圍檢查 Git diff 統(tǒng)計(jì)用路徑或模塊限定 AI 的修改范圍遷移后測(cè)試用例行為與之前不一致AI 在修改中“簡(jiǎn)化”了邏輯對(duì)比關(guān)鍵文件的 diff回退非必要邏輯改動(dòng)重新限定任務(wù)邊界編譯通過但運(yùn)行時(shí)報(bào) NoClassDefFoundError依賴版本沖突或傳遞依賴改變運(yùn)行mvn dependency:tree查看依賴樹在 pom.xml 中顯式聲明所需依賴版本AI 誤解了業(yè)務(wù)概念替換成錯(cuò)誤的 API提示詞上下文不足審查 AI 輸出的修改說明在提示詞中補(bǔ)充業(yè)務(wù)語義和約束遷移過程中 API Key 報(bào)錯(cuò)或權(quán)限不足環(huán)境變量未配置查看工具日志和官方文檔檢查網(wǎng)絡(luò)環(huán)境和認(rèn)證配置確認(rèn)有合法調(diào)用權(quán)限遇到內(nèi)存訪問錯(cuò)誤導(dǎo)致工具崩潰本地環(huán)境或內(nèi)存分配異常查看工具當(dāng)前版本的 issue按官方指引處理必要時(shí)升級(jí)工具版本這里的核心思想是AI 是一個(gè)高效的執(zhí)行者但它不是項(xiàng)目的歷史記憶。你對(duì)項(xiàng)目的業(yè)務(wù)理解才是遷移安全性的最終保障。8. AI 代碼遷移的安全邊界與最佳實(shí)踐最后聊一個(gè)很多人忽略的問題安全邊界。用 AI 做代碼遷移安全風(fēng)險(xiǎn)不只在“代碼質(zhì)量”層面還包括“數(shù)據(jù)合規(guī)”和“供應(yīng)鏈安全”層面。8.1 敏感信息與合規(guī)當(dāng) AI 工具連接云端模型時(shí)你本地的代碼和文件內(nèi)容可能會(huì)被發(fā)送到模型提供商進(jìn)行處理。對(duì)于包含業(yè)務(wù)敏感信息、未公開算法、客戶數(shù)據(jù)的項(xiàng)目這可能是不可接受的。在動(dòng)手之前務(wù)必確認(rèn)項(xiàng)目是否允許使用云端 AI 服務(wù)是否可以使用企業(yè)版或私有化部署方案代碼中是否存在硬編碼的密鑰或內(nèi)部地址遷移前應(yīng)該先清理一個(gè)穩(wěn)妥的實(shí)踐是在遷移前先做一次密鑰掃描把AK/SK、數(shù)據(jù)庫密碼、內(nèi)部 IP 都刪掉或用環(huán)境變量替換。8.2 最小權(quán)限原則如果你使用了能執(zhí)行命令的 Agent 工具比如 Claude Code要特別注意它對(duì)環(huán)境的訪問權(quán)限。在本地開發(fā)環(huán)境上運(yùn)行還好但如果你在具備生產(chǎn)環(huán)境訪問權(quán)限的機(jī)器上運(yùn)行就要格外小心。盡量使用最小權(quán)限賬號(hào)運(yùn)行 AI Agent不要用 root 或管理員權(quán)限。8.3 不要盲信 AI 生成的代碼這一點(diǎn)再怎么強(qiáng)調(diào)都不過分。AI 在編譯層面的正確性很高但在業(yè)務(wù)語義層面的正確性是有限的。它可能把你的if (user ! null user.isActive())“優(yōu)化”成if (user.isActive())因?yàn)樗X得user已經(jīng)被前面邏輯判斷過了。這種改動(dòng)在編譯和單測(cè)中都不會(huì)被發(fā)現(xiàn)但在生產(chǎn)環(huán)境里可能就是致命的 bug。所以在 AI 完成遷移后必須有代碼審查環(huán)節(jié)。最好讓不參與這次遷移的同事來 review diff因?yàn)楫?dāng)事人容易對(duì) AI 的改動(dòng)產(chǎn)生“路徑依賴”看什么都覺得沒問題。8.4 遷移的工程最佳實(shí)踐清單結(jié)合前面的內(nèi)容整理一份可以直接復(fù)制使用的清單遷移前創(chuàng)建獨(dú)立分支保證主分支穩(wěn)定遷移前跑通基線構(gòu)建記錄測(cè)試結(jié)果遷移工作拆分成小步驟每步都驗(yàn)證提示詞中明確文件范圍、目標(biāo)版本、驗(yàn)證方式AI 每完成一個(gè)階段就進(jìn)行一次代碼審查所有敏感信息必須先清理再做遷移遷移完成后用自動(dòng)化測(cè)試加人工回歸雙重驗(yàn)證對(duì) AI 修改過的文件保持 diff 記錄便于回滾9. 總結(jié)AI 遷移的真實(shí)定位回到開頭的問題用 AI 做代碼現(xiàn)代化和遷移到底意味著什么它不是“按一個(gè)按鈕老系統(tǒng)自動(dòng)變成新系統(tǒng)”的魔法。真實(shí)的圖景是AI 把遷移中大量重復(fù)的、低創(chuàng)造性的工作量承擔(dān)下來讓人能把精力投放在真正需要理解業(yè)務(wù)、判斷風(fēng)險(xiǎn)和設(shè)計(jì)架構(gòu)的部分。這意味著兩個(gè)變化。第一遷移的成本結(jié)構(gòu)在改變。以前一個(gè)大型項(xiàng)目的遷移預(yù)算中80% 花在“人肉改代碼”上。現(xiàn)在這部分可以由 AI 以極低成本完成人力成本集中到遷移方案設(shè)計(jì)、代碼審查和運(yùn)行驗(yàn)證上。第二遷移的風(fēng)險(xiǎn)特征在改變。以前遷移最大的風(fēng)險(xiǎn)是“時(shí)間不夠、代碼改不完”現(xiàn)在最大的風(fēng)險(xiǎn)變成了“AI 改錯(cuò)了但人沒發(fā)現(xiàn)”。所以AI 時(shí)代做遷移代碼審查能力反而變得更重要了。如果你正準(zhǔn)備把一個(gè)老項(xiàng)目從舊技術(shù)棧上搬下來我的建議是不要一上來就追求“全自動(dòng)遷移”。先選一個(gè)邊界清晰、風(fēng)險(xiǎn)可控的模塊把 AI 遷移的流程跑通積累一些提示詞和審查經(jīng)驗(yàn)再逐步擴(kuò)大范圍。工具在快速進(jìn)化但工程方法論的價(jià)值不會(huì)過時(shí)。 AI驅(qū)動(dòng)代碼遷移實(shí)戰(zhàn)：從Spring Boot 2到3的現(xiàn)代化升級(jí)
為什么“用 AI 遷移老代碼”突然成了硬需求過去一年里我身邊不少團(tuán)隊(duì)都在做同一件事把跑了五六年甚至十年的老系統(tǒng)從舊框架、舊 JDK、舊中間件上搬下來。有的是因?yàn)?Spring 版本太老安全漏洞沒人修;有的是因?yàn)?JDK 8 的維護(hù)成本越來越高想往 JDK 17 甚至 21 上走;還有的是因?yàn)闃I(yè)務(wù)方要求上云順手要把單體拆成服務(wù)。這件事的難點(diǎn)不在于“重構(gòu)業(yè)務(wù)邏輯”而在于“遷移本身的工程量”。一個(gè)大型遺留系統(tǒng)里真正需要人來逐行讀的代碼可能只有兩成剩下八成都是模式化的勞動(dòng)改 import、換 API、調(diào)整配置、處理廢棄方法、修復(fù)編譯錯(cuò)誤。這些工作重復(fù)、機(jī)械、費(fèi)時(shí)但又是遷移動(dòng)不動(dòng)就要以“人月”為單位計(jì)算的主要原因。AI 編程工具的興起恰好踩中了這個(gè)需求。從過去的“AI 幫你寫新代碼”到現(xiàn)在的“AI 幫你改老代碼”這個(gè)變化比很多人想象中更大。Claude Code、GitHub Copilot、Cursor 這類工具已經(jīng)不只是補(bǔ)全代碼而是能理解項(xiàng)目結(jié)構(gòu)、讀取編譯錯(cuò)誤、定位廢棄 API、跨文件修改甚至自動(dòng)跑測(cè)試驗(yàn)證改動(dòng)結(jié)果。換句話說AI 正在從“單點(diǎn)輔助”變成“遷移流水線的執(zhí)行者”。這篇文章的目標(biāo)很簡(jiǎn)單講清楚用 AI 做代碼現(xiàn)代化和遷移時(shí)真正有效的工作流是什么哪些步驟適合交給 AI哪些必須人來把關(guān)以及落地過程中最容易踩的坑。讀完你會(huì)得到一套可以復(fù)用的方法而不是一堆“AI 很強(qiáng)大”的正確廢話。1. 代碼遷移的傳統(tǒng)痛點(diǎn)和 AI 的介入方式先說一個(gè)真實(shí)場(chǎng)景。假設(shè)我們要把一個(gè)基于 Spring Boot 2.2 JDK 8 的老項(xiàng)目升級(jí)到 Spring Boot 3.2 JDK 17。看似只是版本號(hào)變了實(shí)際改動(dòng)范圍包括javax.* 到 jakarta.* 的包名遷移這是 Spring Boot 3 最廣為人知的破壞性變更大量 Spring Security 配置 API 的廢棄與替換三方庫版本的兼容性調(diào)整一些反射、字節(jié)碼操作的 JDK 模塊限制問題測(cè)試代碼里依賴舊 API 的斷言邏輯構(gòu)建腳本中 Maven 或 Gradle 插件的版本對(duì)齊傳統(tǒng)做法是先全局搜索 javax 替換成 jakarta然后啟動(dòng)項(xiàng)目看編譯報(bào)錯(cuò)一個(gè)一個(gè)改。運(yùn)氣好兩三天搞定;運(yùn)氣不好改完一處冒出來三處最后還要處理運(yùn)行時(shí)才暴露的問題。這個(gè)過程里有三個(gè)痛點(diǎn)第一重復(fù)勞動(dòng)集中。包名替換、注解遷移、配置文件改格式這些操作沒有技術(shù)含量但數(shù)量巨大。第二上下文斷裂。很多 API 替換不是“一對(duì)一”的而是“一對(duì)多”或者“多對(duì)一”。比如 Spring Security 中 WebSecurityConfigurerAdapter 的廢棄需要你理解新的 SecurityFilterChain 配置方式而不是光靠搜索替換就能完成。第三驗(yàn)證成本高。改完一百個(gè)文件你怎么知道沒有遺漏編譯通過不等于運(yùn)行正常運(yùn)行正常也不等于所有分支都被覆蓋到。AI 工具的介入方式正好針對(duì)這三個(gè)痛點(diǎn)它能快速處理大批量模式化替換而且不會(huì)像正則替換那樣誤傷邊界情況它能基于整個(gè)倉庫的上下文理解 API 之間的映射關(guān)系而不是只做文本匹配它可以反復(fù)迭代編譯失敗就把錯(cuò)誤拋給它它會(huì)自己定位文件、修改代碼、再驗(yàn)證所以用 AI 做遷移的核心理念不是“讓 AI 完全取代人”而是讓 AI 承擔(dān)重復(fù)勞動(dòng)讓人專注在決策和審核上。2. AI 代碼遷移與傳統(tǒng)工具的本質(zhì)區(qū)別可能有人會(huì)說IDEA 的重構(gòu)功能也能做包名替換也能做 API 遷移為什么還要用 AI這個(gè)問題問得非常好。事實(shí)上傳統(tǒng) IDE 重構(gòu)確實(shí)能處理一部分“語法層面的遷移”比如重命名類、移動(dòng)包、調(diào)整方法簽名。但對(duì)于“語義層面的遷移”傳統(tǒng)工具就無能為力了。舉一個(gè)具體例子JDK 8 升級(jí)到 JDK 17 時(shí)SecurityManager被標(biāo)記為廢棄準(zhǔn)備移除。如果你的代碼里調(diào)用了System.getSecurityManager()IDE 能幫你把方法調(diào)用的地方全部列出來但它不會(huì)告訴你“業(yè)務(wù)上應(yīng)該怎么替代這個(gè)安全模型”。因?yàn)檫@已經(jīng)不是代碼層面的問題而是架構(gòu)層面的問題。AI 能做的是在理解你整個(gè)項(xiàng)目上下文的基礎(chǔ)上給出“這段代碼在新的安全模型下應(yīng)該怎么寫”的建議并直接修改到代碼里。它不是在執(zhí)行 IDE 的重構(gòu)規(guī)則而是在模擬一個(gè)熟悉這個(gè)技術(shù)棧的工程師在改代碼。另一個(gè)本質(zhì)區(qū)別在于錯(cuò)誤反饋的閉環(huán)。傳統(tǒng)流程是人改代碼編譯器報(bào)錯(cuò)人再看代碼再改。AI 流程是AI 改代碼AI 看編譯器報(bào)錯(cuò)AI 再改直到編譯通過。以 Claude Code 為代表的編程 Agent 工具甚至可以在自己的循環(huán)里反復(fù)執(zhí)行命令、讀取日志、修改文件形成一個(gè)自動(dòng)化迭代回路。這意味著遷移工作中最耗時(shí)的“編譯-報(bào)錯(cuò)-修復(fù)”循環(huán)可以由 AI 自主完成人只需要在關(guān)鍵節(jié)點(diǎn)介入審查。3. 環(huán)境準(zhǔn)備選擇 AI 工具與配置本地工作區(qū)如果要用 AI 做代碼遷移環(huán)境準(zhǔn)備比寫新代碼要更講究。因?yàn)檫w移工作涉及大量“讀取文件、搜索代碼、執(zhí)行命令”的能力不同工具能發(fā)揮的作用差異很大。3.1 工具選擇思路目前主流 AI 編程工具有兩類一類是 IDE 插件型比如 GitHub Copilot、Cursor 等。它們的優(yōu)勢(shì)是和你當(dāng)前的開發(fā)環(huán)境深度綁定適合“人在回路”的逐文件修改。另一類是 Agent 型比如 Claude Code。它們運(yùn)行在終端里能直接操作文件系統(tǒng)、執(zhí)行 Shell 命令、讀取編譯日志更適合“批量任務(wù)”和“自動(dòng)化流水線”。從最近的社區(qū)熱度來看Claude Code 這類工具在“任務(wù)級(jí)編程”場(chǎng)景下的表現(xiàn)尤其突出。如果你要處理的是整個(gè)倉庫級(jí)別的遷移Agent 型的優(yōu)勢(shì)會(huì)比 IDE 插件更大。需要說明一點(diǎn)各家工具的版本迭代非常快本文不會(huì)寫死具體的版本號(hào)。安裝時(shí)請(qǐng)以官方倉庫和文檔為準(zhǔn)核心思路是通用的。3.2 Claude Code 的安裝與配置示例以 Claude Code 為例安裝過程本身不復(fù)雜但有幾個(gè)細(xì)節(jié)值得注意。如果使用 npm 安裝基本命令如下npm install -g anthropic-ai/claude-code安裝完成后在項(xiàng)目根目錄運(yùn)行claude第一次運(yùn)行時(shí)需要完成登錄和 API 配置。這里要提醒一句Claude Code 會(huì)讀取你的項(xiàng)目文件并向模型發(fā)送請(qǐng)求所以不要在包含敏感信息的目錄下直接運(yùn)行最好先確認(rèn)項(xiàng)目的保密級(jí)別。對(duì)于企業(yè)項(xiàng)目建議使用企業(yè)版或本地方案避免涉密代碼外傳。配置完成后建議先把項(xiàng)目結(jié)構(gòu)梳理清楚。一個(gè)典型的交互流程如下cd /path/to/your/legacy-project claude進(jìn)入交互界面后可以先讓 AI 讀取項(xiàng)目說明和構(gòu)建文件例如請(qǐng)先閱讀 pom.xml 和 src/main/resources/application.yml 然后告訴我這個(gè)項(xiàng)目的 Spring Boot 版本、JDK 版本和主要依賴。這一步非常重要。AI Agent 只有在充分理解項(xiàng)目背景后后續(xù)的遷移工作才會(huì)準(zhǔn)確。如果你一上來就直接說“幫我升級(jí)到 Spring Boot 3”它會(huì)缺乏上下文很容易在錯(cuò)誤的文件里做修改。3.3 倉庫級(jí)別的準(zhǔn)備工作除了工具安裝還需要做好倉庫的工程準(zhǔn)備。建議在正式讓 AI 動(dòng)手前完成以下三步建立分支遷移工作必須在獨(dú)立分支上執(zhí)行絕不在主干上直接改。跑通基線構(gòu)建先用當(dāng)前代碼跑一次完整構(gòu)建mvn clean package或gradle build確認(rèn)遷移前的代碼是“可編譯、可測(cè)試”的。如果原始代碼就是壞的AI 改完之后你很難區(qū)分哪些是它引入的問題哪些是歷史遺留問題。記錄基線測(cè)試結(jié)果把遷移前的測(cè)試用例執(zhí)行結(jié)果記錄下來作為遷移后的對(duì)照基準(zhǔn)。這樣才能在 AI 改完代碼之后用“編譯通過 測(cè)試通過 關(guān)鍵邏輯審查”三個(gè)維度驗(yàn)證遷移質(zhì)量。4. 核心流程拆解AI 遷移的五個(gè)階段在真正動(dòng)手之前先把遷移工作的整體流程拆解清楚。根據(jù)我在多個(gè)項(xiàng)目中的觀察一套高效的 AI 輔助遷移流程通常分為五個(gè)階段。4.1 階段一全量盤點(diǎn)這個(gè)階段的目標(biāo)是讓 AI 幫你建立遷移的“作戰(zhàn)地圖”。你需要讓 AI 掃描整個(gè)項(xiàng)目識(shí)別出所有涉及遷移的關(guān)鍵點(diǎn)。以 Spring Boot 2 到 3 的遷移為例可以這樣下達(dá)指令請(qǐng)分析當(dāng)前項(xiàng)目的 Spring Boot 版本、JDK 版本和所有依賴。 列出所有可能需要修改的地方包括但不限于 - javax 包的 import 語句 - Spring Security 配置類 - 數(shù)據(jù)庫訪問層的廢棄 API - 測(cè)試代碼中的兼容性問題 - 構(gòu)建腳本中的插件版本 請(qǐng)把分析結(jié)果按高影響/中影響/低影響分類輸出。AI 會(huì)返回一份清單。這份清單的價(jià)值在于它讓你在動(dòng)手改代碼之前就大概知道遷移的規(guī)模有多大、風(fēng)險(xiǎn)集中在哪些模塊。很多遷移失敗不是因?yàn)楦牟粍?dòng)代碼而是因?yàn)榈凸懒四承╇[藏依賴的改動(dòng)成本。4.2 階段二制定遷移計(jì)劃拿到盤點(diǎn)結(jié)果后不要急著讓 AI 全量開改。正確做法是把遷移工作拆成若干個(gè)子任務(wù)排好優(yōu)先級(jí)。推薦的執(zhí)行順序是構(gòu)建腳本和依賴管理優(yōu)先改這是所有代碼編譯的基礎(chǔ)基礎(chǔ)配置文件和公共模塊先遷移比如通用工具類、公共實(shí)體類業(yè)務(wù)模塊按依賴關(guān)系從底層到上層逐個(gè)遷移測(cè)試代碼最后遷移等主代碼編譯通過了再修測(cè)試你可以把計(jì)劃直接發(fā)給 AI讓它在執(zhí)行時(shí)遵守我將按照以下順序執(zhí)行遷移 第一步修改 pom.xml更新 Spring Boot 版本到 3.x替換所有 javax 為 jakarta。 第二步修改公共模塊的編譯錯(cuò)誤。 第三步逐個(gè)遷移業(yè)務(wù)模塊。 每一步完成之后都執(zhí)行一次 mvn compile直到編譯通過再進(jìn)入下一步。 請(qǐng)確認(rèn)理解。讓 AI 明確執(zhí)行順序能避免它東改一下西改一下最后整個(gè)倉庫處于半遷移狀態(tài)、編譯錯(cuò)誤鋪天蓋地的混亂局面。4.3 階段三迭代式遷移執(zhí)行這是核心階段也是 AI 價(jià)值最大的階段。你需要輸入的關(guān)鍵指令是讓 AI 自己形成“修改-編譯-修復(fù)”的循環(huán)。比如現(xiàn)在開始執(zhí)行第一步。修改完成后運(yùn)行 mvn compile。 如果編譯失敗請(qǐng)根據(jù)報(bào)錯(cuò)信息繼續(xù)修復(fù)直到編譯通過。 每次修改文件時(shí)請(qǐng)說明修改了哪些地方以及為什么這樣改。在這個(gè)階段AI 會(huì)做類似下面的事情搜索所有javax.servlet的 import批量替換成jakarta.servlet運(yùn)行 Maven 編譯遇到WebSecurityConfigurerAdapter報(bào)錯(cuò)搜索類定義找到新的SecurityFilterChainBean 寫法重寫配置類再次編譯循環(huán)往復(fù)直到編譯通過整個(gè)過程看起來很像一個(gè)初級(jí)工程師在干活但速度要快得多。不過要注意AI 在“改到編譯通過”這件事上很有耐心但它不會(huì)主動(dòng)思考“這個(gè)改法雖然在編譯層面沒問題但在運(yùn)行層面是否等價(jià)”。這就是為什么遷移過程中必須有人的審查節(jié)點(diǎn)。4.4 階段四人工審查與邏輯核對(duì)當(dāng) AI 報(bào)告“編譯通過”之后最重要的工作才剛剛開始。你需要做的是讓 AI 輸出一份變更摘要然后針對(duì)高風(fēng)險(xiǎn)文件做人工 diff 審查。具體來說重點(diǎn)關(guān)注以下內(nèi)容業(yè)務(wù)邏輯是否被意外改動(dòng)比如某個(gè)條件判斷被 AI 順手“簡(jiǎn)化”了配置類型是否發(fā)生變化比如原本是讀取配置項(xiàng)被 AI 改成了硬編碼異常處理行為是否不一致比如原本捕獲 IOException被 AI 改成了捕獲 Exception線程安全相關(guān)代碼是否被誤改如果發(fā)現(xiàn) AI 的改動(dòng)超出遷移范圍你需要明確糾正并讓它回退。這里給出一個(gè)糾偏指令的示例在剛才的修改中src/main/java/com/example/service/OrderService.java 中原本的查詢條件被改動(dòng)導(dǎo)致業(yè)務(wù)邏輯可能發(fā)生變化。 這個(gè)文件不屬于本次遷移的必要改動(dòng)范圍 請(qǐng)回退該文件中與遷移無關(guān)的邏輯變更只保留 javax 到 jakarta 的 import 替換。4.5 階段五驗(yàn)證與收尾遷移代碼通過了人工審查之后需要做完整驗(yàn)證。建議按以下順序執(zhí)行mvn clean package mvn test如果項(xiàng)目有集成測(cè)試或端到端測(cè)試也要一并運(yùn)行。對(duì)于沒有自動(dòng)化測(cè)試覆蓋的模塊需要人工回歸驗(yàn)證。最后把變色龍一樣的雜項(xiàng)處理干凈更新 README 中的版本說明、清理廢棄依賴、刪除不再必要的兼容層代碼。到這里一次完整的 AI 輔助遷移工作就算結(jié)束了。5. 完整示例用 Claude Code 遷移 Spring Boot 2 到 3這一節(jié)我用一個(gè)最小化示例展示完整的遷移過程。示例項(xiàng)目結(jié)構(gòu)如下為了演示只保留了核心文件legacy-demo/ ├── pom.xml ├── src/main/java/com/example/legacy/ │ ├── LegacyApplication.java │ ├── config/SecurityConfig.java │ └── controller/HelloController.java ├── src/main/resources/ │ └── application.yml └── src/test/java/com/example/legacy/ └── LegacyApplicationTests.java5.1 原始代碼先看遷移前的核心文件。文件pom.xml?xml version1.0 encodingUTF-8? project xmlnshttp://maven.apache.org/POM/4.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd modelVersion4.0.0/modelVersion parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.2.13.RELEASE/version relativePath/ /parent groupIdcom.example/groupId artifactIdlegacy-demo/artifactId version1.0.0/version properties java.version1.8/java.version /properties dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-security/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependency /dependencies /project文件src/main/java/com/example/legacy/config/SecurityConfig.javapackage com.example.legacy.config; import org.springframework.context.annotation.Configuration; import org.springframework.security.config.annotation.web.builders.HttpSecurity; import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity; import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter; Configuration EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http .authorizeRequests() .antMatchers(/public/**).permitAll() .anyRequest().authenticated() .and() .formLogin(); } }文件src/main/java/com/example/legacy/controller/HelloController.javapackage com.example.legacy.controller; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; import javax.servlet.http.HttpServletRequest; RestController RequestMapping(/api) public class HelloController { GetMapping(/hello) public String hello(HttpServletRequest request) { return Hello, request.getRemoteAddr(); } }文件src/test/java/com/example/legacy/LegacyApplicationTests.javapackage com.example.legacy; import org.junit.jupiter.api.Test; import org.junit.jupiter.api.extension.ExtendWith; import org.springframework.boot.test.context.SpringBootTest; import org.springframework.test.context.junit.jupiter.SpringExtension; ExtendWith(SpringExtension.class) SpringBootTest class LegacyApplicationTests { Test void contextLoads() { } }5.2 啟動(dòng) AI 遷移在項(xiàng)目根目錄啟動(dòng) Claude Codecd legacy-demo claude在交互界面中輸入以下指令這是一個(gè)基于 Spring Boot 2.2 和 JDK 8 的遺留項(xiàng)目。 我需要將它遷移到 Spring Boot 3.2 和 JDK 17。 請(qǐng)先閱讀 pom.xml、SecurityConfig.java、HelloController.java 和 LegacyApplicationTests.java梳理出所有需要修改的地方。 然后按以下順序執(zhí)行 1. 更新 pom.xml 中 Spring Boot 版本和 Java 版本。 2. 替換所有 javax 為 jakarta 的 import。 3. 修復(fù) Spring Security 配置類的廢棄 API。 4. 修改測(cè)試代碼中不兼容的注解。 每一步完成后都運(yùn)行 mvn compile 或 mvn test直到全部通過。5.3 AI 修改后的關(guān)鍵文件按照上述流程AI 修改后的核心文件預(yù)期如下。文件pom.xml修改后?xml version1.0 encodingUTF-8? project xmlnshttp://maven.apache.org/POM/4.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd modelVersion4.0.0/modelVersion parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.2.0/version relativePath/ /parent groupIdcom.example/groupId artifactIdlegacy-demo/artifactId version1.0.0/version properties java.version17/java.version /properties dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-security/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependency /dependencies /project文件src/main/java/com/example/legacy/config/SecurityConfig.java修改后package com.example.legacy.config; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.security.config.annotation.web.builders.HttpSecurity; import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity; import org.springframework.security.web.SecurityFilterChain; Configuration EnableWebSecurity public class SecurityConfig { Bean public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { http .authorizeRequests(authorize - authorize .requestMatchers(/public/**).permitAll() .anyRequest().authenticated() ) .formLogin(); return http.build(); } }文件src/main/java/com/example/legacy/controller/HelloController.java修改后package com.example.legacy.controller; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; import jakarta.servlet.http.HttpServletRequest; RestController RequestMapping(/api) public class HelloController { GetMapping(/hello) public String hello(HttpServletRequest request) { return Hello, request.getRemoteAddr(); } }5.4 關(guān)鍵點(diǎn)解釋上面三處修改分別對(duì)應(yīng)了三種典型遷移模式第一pom.xml的修改是“版本升級(jí)型”。Spring Boot 版本從 2.2.13 跳到 3.2.0JDK 版本從 1.8 升到 17。這個(gè)修改本身很簡(jiǎn)單但它會(huì)引發(fā)后續(xù)一連串連鎖變更。第二HelloController.java的修改是“純包名替換型”。代碼邏輯完全不變只有javax.servlet變成了jakarta.servlet。這種改動(dòng)適合批量處理也最容易驗(yàn)證——編譯通過基本就說明沒問題了。第三SecurityConfig.java的修改是“API 重構(gòu)型”。這是三種類型中最復(fù)雜的。在 Spring Security 5.x 中WebSecurityConfigurerAdapter是主流寫法;到了 Spring Security 6.0這個(gè)類已經(jīng)被移除必須用SecurityFilterChainBean 的方式聲明。同時(shí)antMatchers也改成了requestMatchers?？梢钥吹降谌幐膭?dòng)是無法通過“全局搜索替換”或者“IDE 重構(gòu)”自動(dòng)完成的。AI 必須理解 Spring Security 新版本的設(shè)計(jì)思路才能寫出正確的替代代碼。這也說明了為什么用 AI 做遷移時(shí)選擇能力較強(qiáng)的模型非常重要。5.5 驗(yàn)證結(jié)果遷移完成后運(yùn)行構(gòu)建驗(yàn)證mvn clean test預(yù)期輸出中會(huì)包含類似下面的內(nèi)容[INFO] BUILD SUCCESS [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0如果測(cè)試通過說明這個(gè)最簡(jiǎn)單的示例已經(jīng)完成了遷移。實(shí)際項(xiàng)目中文件數(shù)量可能是幾十甚至幾百倍驗(yàn)證的復(fù)雜程度也會(huì)成倍上升。但核心流程是相同的。6. 提示詞設(shè)計(jì)與遷移效率的關(guān)系很多人覺得用 AI 編程就是“把需求發(fā)給 AI”實(shí)際上提示詞的質(zhì)量直接決定遷移工作的成敗。我見過不少團(tuán)隊(duì)用 AI 做遷移最后發(fā)現(xiàn) AI 改出來的代碼“編譯過了但不敢上線”。原因不是 AI 能力不行而是提示詞里沒有說清楚邊界和約束。一條高質(zhì)量的遷移提示詞至少應(yīng)該包含四個(gè)要素項(xiàng)目背景當(dāng)前使用的技術(shù)棧版本、目標(biāo)版本任務(wù)邊界哪些模塊要改哪些模塊不要?jiǎng)訄?zhí)行策略每個(gè)步驟完成后的驗(yàn)證方式輸出要求修改文件的列表、修改原因、風(fēng)險(xiǎn)說明對(duì)比兩組提示詞低質(zhì)量提示詞幫我升級(jí) Spring Boot 版本。這條指令的問題在于AI 不知道該升到什么版本不知道要不要處理 Security 配置不知道改完要不要跑測(cè)試更不知道哪些業(yè)務(wù)代碼不能動(dòng)。結(jié)果要么是亂改要么是反復(fù)問你問題效率極低。高質(zhì)量提示詞請(qǐng)將本項(xiàng)目從 Spring Boot 2.2.13 遷移到 3.2.0JDK 從 8 升級(jí)到 17。 本次遷移只允許修改 pom.xml、src/main/java 和 src/test/java 下的文件 不允許修改數(shù)據(jù)庫腳本和部署配置文件。 執(zhí)行順序 1. 更新依賴版本。 2. 修改編譯錯(cuò)誤。 3. 運(yùn)行 mvn test 驗(yàn)證。 在所有步驟完成前不要停止。 每次修改后請(qǐng)簡(jiǎn)要說明修改了哪些文件和原因。這條指令明確了目標(biāo)版本、文件范圍、執(zhí)行順序和驗(yàn)證方式AI 的產(chǎn)出質(zhì)量會(huì)顯著提高。7. 常見問題與排查方法用 AI 做遷移時(shí)遇到的問題往往不在“AI 會(huì)不會(huì)寫代碼”而在“AI 寫完之后你發(fā)現(xiàn)不了問題”。下面幾個(gè)是我在實(shí)際中看到的高頻問題。問題現(xiàn)象可能原因排查方式解決方案AI 一直反復(fù)編譯失敗陷入死循環(huán)項(xiàng)目存在嚴(yán)重的歷史編譯問題手動(dòng)運(yùn)行mvn compile查看完整報(bào)錯(cuò)先手動(dòng)修復(fù)基線編譯問題再交給 AIAI 修改了大量無關(guān)文件提示詞中沒有明確文件范圍檢查 Git diff 統(tǒng)計(jì)用路徑或模塊限定 AI 的修改范圍遷移后測(cè)試用例行為與之前不一致AI 在修改中“簡(jiǎn)化”了邏輯對(duì)比關(guān)鍵文件的 diff回退非必要邏輯改動(dòng)重新限定任務(wù)邊界編譯通過但運(yùn)行時(shí)報(bào) NoClassDefFoundError依賴版本沖突或傳遞依賴改變運(yùn)行mvn dependency:tree查看依賴樹在 pom.xml 中顯式聲明所需依賴版本AI 誤解了業(yè)務(wù)概念替換成錯(cuò)誤的 API提示詞上下文不足審查 AI 輸出的修改說明在提示詞中補(bǔ)充業(yè)務(wù)語義和約束遷移過程中 API Key 報(bào)錯(cuò)或權(quán)限不足環(huán)境變量未配置查看工具日志和官方文檔檢查網(wǎng)絡(luò)環(huán)境和認(rèn)證配置確認(rèn)有合法調(diào)用權(quán)限遇到內(nèi)存訪問錯(cuò)誤導(dǎo)致工具崩潰本地環(huán)境或內(nèi)存分配異常查看工具當(dāng)前版本的 issue按官方指引處理必要時(shí)升級(jí)工具版本這里的核心思想是AI 是一個(gè)高效的執(zhí)行者但它不是項(xiàng)目的歷史記憶。你對(duì)項(xiàng)目的業(yè)務(wù)理解才是遷移安全性的最終保障。8. AI 代碼遷移的安全邊界與最佳實(shí)踐最后聊一個(gè)很多人忽略的問題安全邊界。用 AI 做代碼遷移安全風(fēng)險(xiǎn)不只在“代碼質(zhì)量”層面還包括“數(shù)據(jù)合規(guī)”和“供應(yīng)鏈安全”層面。8.1 敏感信息與合規(guī)當(dāng) AI 工具連接云端模型時(shí)你本地的代碼和文件內(nèi)容可能會(huì)被發(fā)送到模型提供商進(jìn)行處理。對(duì)于包含業(yè)務(wù)敏感信息、未公開算法、客戶數(shù)據(jù)的項(xiàng)目這可能是不可接受的。在動(dòng)手之前務(wù)必確認(rèn)項(xiàng)目是否允許使用云端 AI 服務(wù)是否可以使用企業(yè)版或私有化部署方案代碼中是否存在硬編碼的密鑰或內(nèi)部地址遷移前應(yīng)該先清理一個(gè)穩(wěn)妥的實(shí)踐是在遷移前先做一次密鑰掃描把AK/SK、數(shù)據(jù)庫密碼、內(nèi)部 IP 都刪掉或用環(huán)境變量替換。8.2 最小權(quán)限原則如果你使用了能執(zhí)行命令的 Agent 工具比如 Claude Code要特別注意它對(duì)環(huán)境的訪問權(quán)限。在本地開發(fā)環(huán)境上運(yùn)行還好但如果你在具備生產(chǎn)環(huán)境訪問權(quán)限的機(jī)器上運(yùn)行就要格外小心。盡量使用最小權(quán)限賬號(hào)運(yùn)行 AI Agent不要用 root 或管理員權(quán)限。8.3 不要盲信 AI 生成的代碼這一點(diǎn)再怎么強(qiáng)調(diào)都不過分。AI 在編譯層面的正確性很高但在業(yè)務(wù)語義層面的正確性是有限的。它可能把你的if (user ! null user.isActive())“優(yōu)化”成if (user.isActive())因?yàn)樗X得user已經(jīng)被前面邏輯判斷過了。這種改動(dòng)在編譯和單測(cè)中都不會(huì)被發(fā)現(xiàn)但在生產(chǎn)環(huán)境里可能就是致命的 bug。所以在 AI 完成遷移后必須有代碼審查環(huán)節(jié)。最好讓不參與這次遷移的同事來 review diff因?yàn)楫?dāng)事人容易對(duì) AI 的改動(dòng)產(chǎn)生“路徑依賴”看什么都覺得沒問題。8.4 遷移的工程最佳實(shí)踐清單結(jié)合前面的內(nèi)容整理一份可以直接復(fù)制使用的清單遷移前創(chuàng)建獨(dú)立分支保證主分支穩(wěn)定遷移前跑通基線構(gòu)建記錄測(cè)試結(jié)果遷移工作拆分成小步驟每步都驗(yàn)證提示詞中明確文件范圍、目標(biāo)版本、驗(yàn)證方式AI 每完成一個(gè)階段就進(jìn)行一次代碼審查所有敏感信息必須先清理再做遷移遷移完成后用自動(dòng)化測(cè)試加人工回歸雙重驗(yàn)證對(duì) AI 修改過的文件保持 diff 記錄便于回滾9. 總結(jié)AI 遷移的真實(shí)定位回到開頭的問題用 AI 做代碼現(xiàn)代化和遷移到底意味著什么它不是“按一個(gè)按鈕老系統(tǒng)自動(dòng)變成新系統(tǒng)”的魔法。真實(shí)的圖景是AI 把遷移中大量重復(fù)的、低創(chuàng)造性的工作量承擔(dān)下來讓人能把精力投放在真正需要理解業(yè)務(wù)、判斷風(fēng)險(xiǎn)和設(shè)計(jì)架構(gòu)的部分。這意味著兩個(gè)變化。第一遷移的成本結(jié)構(gòu)在改變。以前一個(gè)大型項(xiàng)目的遷移預(yù)算中80% 花在“人肉改代碼”上。現(xiàn)在這部分可以由 AI 以極低成本完成人力成本集中到遷移方案設(shè)計(jì)、代碼審查和運(yùn)行驗(yàn)證上。第二遷移的風(fēng)險(xiǎn)特征在改變。以前遷移最大的風(fēng)險(xiǎn)是“時(shí)間不夠、代碼改不完”現(xiàn)在最大的風(fēng)險(xiǎn)變成了“AI 改錯(cuò)了但人沒發(fā)現(xiàn)”。所以AI 時(shí)代做遷移代碼審查能力反而變得更重要了。如果你正準(zhǔn)備把一個(gè)老項(xiàng)目從舊技術(shù)棧上搬下來我的建議是不要一上來就追求“全自動(dòng)遷移”。先選一個(gè)邊界清晰、風(fēng)險(xiǎn)可控的模塊把 AI 遷移的流程跑通積累一些提示詞和審查經(jīng)驗(yàn)再逐步擴(kuò)大范圍。工具在快速進(jìn)化但工程方法論的價(jià)值不會(huì)過時(shí)。