微服务重构是后端开发中最复杂的任务之一——代码量大、业务逻辑复杂、风险高。2026年我们用 AI 编程工具（Claude Code + Cursor）完成了投递系统从 PHP 到 Go 的微服务重构，效率比纯人工提升了 3 倍。今天把完整实践分享出来。

一、项目背景

投递系统是招聘平台的核心业务，负责职位投递、简历处理、状态流转、通知推送。原系统是 PHP 单体，随着业务增长遇到了瓶颈：

  • 性能瓶颈：核心接口 QPS 到 800 就扛不住，P99 延迟 120ms
  • 维护困难：PHP 代码耦合严重，改一个功能影响一片
  • 人才断层：PHP 开发者越来越少，招人难
  • 扩展性差：单体架构无法独立扩展，高峰期整个系统都慢

重构目标：

  • 从 PHP 单体迁移到 Go 微服务
  • 核心接口 QPS 从 800 提升到 5000+
  • P99 延迟从 120ms 降到 15ms
  • 保持业务逻辑不变，用户无感知
  • 灰度上线，可回滚

二、AI 工具选型

重构过程中用了两个 AI 工具，各有分工：

工具 用途 优势场景
Claude Code 终端里的 AI 编程助手，复杂重构、批量修改、脚本编写 后端代码迁移、批量重构、命令行操作
Cursor AI 原生 IDE，多文件编辑、代码理解、UI 操作 多文件新功能开发、代码审查、界面操作

分工策略：

  • 理解代码和规划：Cursor（看代码方便，多文件对比）
  • 批量迁移和重构：Claude Code（终端操作快，批量处理强）
  • 新功能开发：Cursor（Composer 多文件编辑）
  • 测试和脚本：Claude Code（写测试、写迁移脚本）
  • Bug 修复和调试：都可以，看个人习惯

两个工具配合使用，比只用一个效率高很多。

三、重构工作流

阶段1：理解和规划（AI 辅助）

第一步：AI 理解旧代码

用 Cursor 打开 PHP 项目，让 AI 分析代码结构：

1
2
3
4
5
6
7
8

@code 分析一下这个 PHP 项目的代码结构，列出：
1. 核心模块和职责
2. 关键业务流程（投递、简历处理、状态流转）
3. 数据库表结构和关系
4. 外部依赖（Redis、RabbitMQ、其他服务）
5. 代码中的技术债和风险点

输出结构化的分析报告。

AI 会分析整个项目，输出结构化的报告。这一步人工做可能要 2-3 天，AI 辅助 2-3 小时就够了。

第二步：AI 生成迁移方案

基于分析报告，让 AI 生成迁移方案：

1
2
3
4
5
6
7
8
9

基于上面的分析，生成 Go 微服务的迁移方案：
1. 服务拆分方案（拆成几个微服务，每个服务的职责）
2. 目录结构和分层架构
3. 数据库迁移策略（双写还是增量同步）
4. 接口定义（gRPC proto 文件）
5. 灰度上线和回滚方案
6. 风险点和应对措施

参考我们之前的简历服务重构方案 @/docs/resume-service-migration.md

AI 生成方案后，人工 review 和调整，确认后进入实施。

第三步：搭建项目骨架

用 Claude Code 搭建 Go 项目骨架：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

帮我创建一个 Go 微服务项目骨架，要求：
1. 用 Gin + GORM + gRPC
2. 分层架构：handler → service → repository
3. 目录结构：
   - cmd/（入口）
   - internal/handler/（HTTP 接口）
   - internal/service/（业务逻辑）
   - internal/repository/（数据访问）
   - internal/proto/（gRPC 定义）
   - internal/middleware/（中间件）
   - configs/（配置）
   - scripts/（脚本）
4. 配置用 viper，日志用 zap
5. 加 Makefile，包含 build/test/lint/gen 命令
6. 加 Dockerfile 和 docker-compose.yml
7. 加 .gitignore 和 README

Claude Code 会自动创建所有文件和目录，几分钟搭好项目骨架。

阶段2：逐模块迁移（AI 主力）

按模块逐个迁移，每个模块的流程：

第一步：AI 理解 PHP 代码

1
2

@/old/apply/controller/ApplyController.php 分析这个 PHP 文件的业务逻辑，
列出每个函数的功能、输入输出、调用的依赖、关键业务规则。

第二步：AI 生成 Go 代码

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

把上面的 PHP 代码转换成 Go，要求：
1. 遵循我们的分层架构，业务逻辑放 service 层
2. 用 GORM 操作数据库，不要写原生 SQL（除非复杂查询）
3. 错误处理用我们的统一错误码
4. 日志用 zap，包含 request_id
5. 参数校验用 validator
6. 保持业务逻辑完全一致，不要改变行为
7. 加必要的注释

参考 @/internal/service/resume_service.go 的风格

AI 生成代码后，人工 review：

  • 业务逻辑是否一致
  • 有没有边界条件没处理
  • 错误处理是否正确
  • 性能有没有问题（如 N+1 查询）

第三步：AI 生成测试

1
2
3
4
5
6
7

给 @/internal/service/apply_service.go 写单元测试，要求：
1. 覆盖正常场景和异常场景
2. 用 mockery mock repository 层
3. 用 testify 断言
4. 表驱动测试
5. 覆盖率 ≥ 80%
6. 测试数据用假数据，不要依赖真实数据库

AI 写测试比人快很多，而且覆盖更全。但要注意 review 测试逻辑——AI 有时会写"放水"的测试（断言太松或 mock 不对）。

第四步：运行测试和修复

1
2

运行 go test ./internal/service/ -v，看测试是否通过。
如果有失败，分析原因并修复。

Claude Code 可以自动运行测试、分析失败原因、修复代码，循环直到测试通过。

阶段3：集成和验证（AI 辅助）

接口对比测试：

写一个对比测试工具，同时调用旧 PHP 接口和新 Go 接口，对比返回结果是否一致：

1
2
3
4
5
6

帮我写一个接口对比测试工具：
1. 同时调用旧接口（PHP）和新接口（Go）
2. 对比返回的 JSON，忽略时间戳和 ID 等动态字段
3. 记录不一致的请求和响应
4. 输出对比报告（通过率、不一致列表）
5. 支持批量测试（从文件读取测试用例）

用这个工具跑几千个请求，确保新旧接口行为一致。不一致的地方 AI 辅助分析原因。

性能测试：

1
2
3
4
5

帮我写一个压测脚本，用 hey 或 wrk 压测投递接口：
1. 压测场景：正常投递、重复投递、并发投递
2. 指标：QPS、P50/P95/P99 延迟、错误率
3. 输出压测报告
4. 对比 PHP 版和 Go 版的性能

压测发现性能问题，AI 辅助分析和优化：

1
2

压测发现 P99 延迟 50ms，目标是 15ms。
用 pprof 分析一下性能瓶颈，给出优化建议。

阶段4：灰度上线（AI 辅助）

灰度策略：

  1. 双写：写流量同时写 PHP 和 Go，读流量走 PHP
  2. 数据对比：对比两边的数据，确保一致
  3. 读流量灰度：按用户 ID 灰度，1% → 10% → 50% → 100%
  4. 监控：实时监控错误率、延迟、业务指标
  5. 回滚：有问题立即切回 PHP

AI 辅助写灰度脚本、监控面板、回滚脚本。

四、AI 在各环节的效率提升

环节 纯人工耗时 AI 辅助耗时 提升
代码理解和分析 3天 3小时 8倍
迁移方案设计 2天 4小时 4倍
项目骨架搭建 1天 10分钟 48倍
单模块代码迁移 2天 4小时 4倍
单元测试编写 1天 2小时 4倍
Bug 修复 4小时/个 30分钟/个 8倍
性能分析优化 2天 4小时 4倍
脚本工具编写 1天 2小时 4倍
整体 约30人天 约10人天 3倍

AI 辅助下，整个重构从 30 人天缩短到 10 人天，效率提升 3 倍。而且代码质量更高（测试更全、规范更统一）。

五、AI 辅助重构的最佳实践

1. 先理解再迁移

不要让 AI 直接"把 PHP 翻译成 Go"，要先让 AI 理解业务逻辑，再基于理解生成 Go 代码。直接翻译会保留 PHP 的写法和坏味道，不是地道的 Go 代码。

2. 小步快跑，逐模块迁移

不要一次迁移整个系统，拆成小模块，每个模块：

  1. AI 理解旧代码
  2. AI 生成新代码
  3. 人工 review
  4. AI 生成测试
  5. 运行测试验证
  6. 集成测试

每个模块可独立验证、独立回滚，风险可控。

3. 人工 review 不能省

AI 生成的代码可能有问题：

  • 业务逻辑理解错误
  • 边界条件没处理
  • 性能问题（N+1 查询、内存泄漏）
  • 安全问题（SQL 注入、权限绕过）
  • 测试"放水"（断言太松）

特别是业务逻辑，AI 可能理解偏差，必须人工仔细 review。

4. 测试是安全网

重构前先有测试（旧系统的集成测试），重构后跑测试，确保行为一致。AI 写测试快，但要 review 测试逻辑。

5. 用 AI 做重复劳动

AI 擅长重复劳动：

  • 批量代码转换
  • 写 CRUD 代码
  • 写单元测试
  • 写脚本工具
  • 代码格式化和规范化

人专注于：

  • 架构设计
  • 业务逻辑理解
  • 代码 review
  • 性能优化
  • 风险决策

6. 保留旧代码，灰度切换

重构期间新旧代码并存，灰度切换，不要一上来就删旧代码。有问题随时回滚。

六、踩坑经验

  1. AI 直接翻译代码：一开始让 AI"把 PHP 翻译成 Go"，结果生成的代码充满 PHP 味道（如用数组代替结构体、全局变量），不是地道的 Go。要先让 AI 理解逻辑，再用 Go 的方式重写
  2. 业务逻辑理解偏差：AI 有时会误解业务逻辑（特别是隐含的规则），生成的代码看起来对但行为不对。一定要有对比测试，新旧接口结果对比
  3. 测试"放水"：AI 写的测试有时断言太松（如只检查不报错，不检查返回值），测试通过但实际没验证逻辑。测试代码也要人工 review
  4. 一次迁移太多：一开始想一次迁移整个模块，结果代码量大、问题多、难以定位。拆成小函数/小接口，逐个迁移，逐个验证
  5. 忽略性能问题：AI 生成的代码功能对但性能差（如 N+1 查询、循环里查数据库）。要做性能测试，AI 辅助分析和优化
  6. 不保留旧代码：重构时急于删旧代码，结果新代码有问题想回滚都回滚不了。新旧代码并存，全量稳定运行一周后再删旧代码
  7. AI 生成的代码风格不统一：不同时间让 AI 生成代码，风格可能不一致（如错误处理方式、命名风格）。用 .cursorrules 统一规范，AI 生成的代码风格一致
  8. 过度依赖 AI：有人觉得"AI 生成的就一定对"，不 review 直接合并，结果出 Bug。AI 是助手不是替代，代码必须人工 review

七、总结

AI 辅助微服务重构核心：

  1. 工具配合是关键：Claude Code（终端/批量/脚本）+ Cursor（多文件/理解/UI），各有分工，配合使用效率最高
  2. 先理解再迁移：不要直接翻译，先让 AI 理解业务逻辑，再用目标语言的地道方式重写
  3. 小步快跑是原则：逐模块/逐接口迁移，每个可独立验证、独立回滚，风险可控
  4. 人工 review 是底线：AI 生成的代码必须人工 review，特别是业务逻辑、性能、安全，AI 可能出错
  5. 测试是安全网：重构前有测试，重构后跑测试，对比新旧接口结果，确保行为一致
  6. AI 做重复劳动：批量转换、CRUD、测试、脚本让 AI 做，人专注架构、业务、review、优化
  7. 灰度上线是保障：新旧并存，双写验证，灰度切流量，有问题随时回滚
  8. 效率提升 3 倍是真实的：我们的实践证明，AI 辅助下重构效率提升 3 倍，代码质量更高（测试更全）

AI 编程工具不是要替代开发者，而是要把开发者从重复劳动中解放出来，专注于更有价值的架构设计和业务决策。微服务重构这种复杂任务，AI 能大幅提升效率，但人的判断力和经验仍然不可替代。AI 负责"做"，人负责"决策"和"审查"，这才是 AI 辅助研发的正确姿势。