主题
一个 Java 老手、Python 新手,用 AI 协作在 1 天 内完成了跨语言跨框架的全栈重构。 本文记录完整过程:从规划到执行、从踩坑到规则沉淀,所有数据均来自 git 提交记录。
一、为什么要重构
旧系统的痛点
灵智 AI v1:Java 8 / Spring Boot + 3 个 Vue 2 微前端(qiankun)
| 痛点 | 表现 |
|---|---|
| 代码重复 | 3 套 Vuex / 路由 / Webpack 配置,前端 40%+ 重复 |
| 构建缓慢 | Webpack 冷启动 30-50s |
| 部署复杂 | 4 个独立 CI 任务,任一失败需逐个排查 |
| 技术栈老化 | Java 8(无 record/var),Vue 2 EOL |
重构目标
Java 8 / Spring Boot → Python 3.12 / FastAPI
3 个 Vue 2 微前端 → 1 个 Vue 3 / Vite 单应用
4 个 CI 任务 → 2 个 CI 任务
Webpack 30-50s → Vite 2-3s为什么敢做?
- 输入确定:27 张表、135 个 API、58 个页面 — 全部可枚举
- 输出确定:功能等价迁移,不改业务逻辑
- 已验证:Flocks 项目已用 Python/FastAPI 跑通
核心判断:功能等价迁移 = 高确定性任务,正是 AI 最擅长的场景。
二、整体策略
Strangler Fig 模式
新旧系统并行运行、Nginx 逐域切流,而非 Big Bang 替换:
- 零停机 — 新旧服务并行,按域逐步切流
- 可回滚 — 任何一个域出问题,Nginx 秒切回 Java
- 数据一致 — 两服务共享同一 MySQL + Redis
分层推进:8 个 Phase
正式动手前,先产出 PLAN.md(架构蓝图)和 TASKS.md(69 个可执行任务):
Phase 0: 项目骨架 ← 所有 Phase 的前提
Phase 1: CRUD 资源管理 ← 27 表 + 131 API,建立模板
Phase 2: V5 网关 + WS ← 依赖 Phase 1
Phase 3: 定时任务 ← 依赖 Phase 2
Phase F1: 前端骨架 ← 可与 Phase 2/3 并行
Phase F2: 页面迁移 ← 依赖 F1 + Phase 1
Phase 5: 部署上线 ← 所有功能完成后核心原则:滚动细化
不预先拆完所有任务。每个 Phase 入口先做源码分析再细化:
进入 Phase 1 → AI 读 Java 源码 → 产出分析 Spec → 人审批 → 细化为 13 个子任务 → AI 执行三、完整时间线(来自 56 个 git commit)
7 个关键阶段
| 阶段 | 时间 | 耗时 | 关键动作 | 产出 |
|---|---|---|---|---|
| ① 规划 | 4/17 23:59 | 38 min | 人 + AI 共同产出 PLAN.md、TASKS.md | 8 Phase 蓝图 + 69 个任务清单 |
| ② 骨架 | 4/18 00:37 | 50 min | AI 搭建后端骨架 + 读 Java 源码分析 | FastAPI 应用 + 源码分析 Spec |
| ③ CRUD | 01:27 ~ 09:04 | ~8h | AI 按模板自动批量生成(人 01:40 去休息) | 36 文件 / 113 API / 27 表 ORM |
| ④ 偏差修复 | 09:20 | 16 min | 对比验证发现 5 类偏差 → 提炼规则 | 5 条编码规则写入 .claude/rules/ |
| ⑤ 网关 + 任务 | 09:34 ~ 19:09 | ~10h | AI 按任务顺序推进 Phase 2 + 3 | WebSocket + 6 个同步任务 + 19 个烟测 |
| ⑥ 前端 | 19:16 ~ 20:10 | 54 min | 14 页面批量迁移 + 7 通用组件 | 4,309 行 Vue 3 代码 |
| ⑦ 部署 + 修复 | 21:09 ~ 次日 12:30 | — | 部署流水线 + BUGFIX 8 大问题全量修复 | Docker + Nginx + UI 美化 |
几个值得说的时间点
① 规划 38 分钟 — 整个重构最重要的投入
后续 AI 能自主领任务、高速执行,完全依赖这 38 分钟建立的"确定性空间":
PLAN.md— 8 Phase 架构蓝图(技术选型、依赖关系、迁移顺序)TASKS.md— 69 个任务(每任务标记 Phase、优先级、状态,AI 按顺序自动领取)CLAUDE.md— AI 的"工作手册"(会话流程 + 编码规范)
③ AI 自动执行 CRUD — 人休息了 6 小时
01:35 人审批了第一个实体(Platform)的模板,01:40 人离开。次日 07:29 回来时,AI 已继续推进到第 3 个实体。后续实体全部自动套用模板,单个实体 3-5 分钟完成。
④ 偏差修复 16 分钟 — 催生了编码规则飞轮
Phase 1 全量完成后运行对比验证(Python vs Java 同请求),发现 5 类问题。16 分钟修复后,5 条规则写入 .claude/rules/,后续 Phase 2/3 再未出现同类问题。
⑥ 前端 54 分钟完成 14 个页面
核心原因:CRUD Store 工厂 + API 工厂消灭了 70% 的重复代码。每个列表页只需 ~80 行,而 V1 需要 ~300 行。
四、踩坑与规则沉淀
6 类典型偏差
| 类别 | 发生了什么 | 影响 | 沉淀的规则 |
|---|---|---|---|
| 跨语言字段映射 | AI 基于代码推测写 ORM,字段名与实际 DB 不一致 | 5 个字段错误 | 写 ORM 前必须查实际表结构 |
| 框架 API 差异 | Pydantic v2 的字段别名机制与 v1 不同 | 全部序列化输出错误 | 统一使用 alias 模式 |
| 异步编程陷阱 | 忘记 await 异步函数,不报错但不工作 | Redis 操作全部静默失败 | 异步函数必须 await |
| 初始化时机 | 模块级创建 DB 连接,绑定了错误的 event loop | 测试和多 worker 报错 | 延迟到应用启动时初始化 |
| 路由匹配顺序 | /list 路径被 /{id} 动态路由抢先匹配 | 405 错误 | 固定路由必须在动态路由之前 |
| N+1 查询 | 列表接口循环查询关联数据 | 性能问题 | 批量查询 + map 映射 |
规则沉淀的飞轮效应
AI 踩坑 → 人发现偏差 → 提炼规则 → 写入 .claude/rules/ → AI 不再犯 → 越写越快| 时间点 | 累计规则数 | 效果 |
|---|---|---|
| Phase 0 完成 | 0 | AI 自由发挥,踩坑概率高 |
| Phase 1 验证后 | 5 | 字段/序列化/异步三类问题消失 |
| Phase 2 完成后 | 11 | 新增性能、状态机、安全等规则 |
| Phase 3 完成后 | 14 | 规则覆盖全面,后续开发质量稳定 |
越写越快、越写越准 — 这就是"确定性空间"不断扩大的过程。
五、人与 AI 的分工
| 角色 | 做了什么 | 花的时间 |
|---|---|---|
| 人 | 写 PLAN.md + TASKS.md(架构决策) | ~38 min |
| 审批第一个实体模板(Platform) | ~5 min | |
| 发现偏差,提炼编码规则 | ~20 min | |
| 审批 Spec + 确认任务顺序 | ~15 min | |
| 审批 BUGFIX Sprint 依赖顺序 | ~10 min | |
| 小计 | ~88 min | |
| AI | 源码分析(读 Java 代码,梳理 27 表 135 端点) | — |
| 按模板批量生成后端代码(36 文件 113 API) | — | |
| 前端页面迁移(14 页面 + 7 组件) | — | |
| 烟测 + 单元测试编写 | — | |
| BUGFIX-PLAN 依赖分析 + 全量修复 | — |
协作模式
人维护"确定性空间"的边界 ←→ AI 在边界内高速执行
↑ ↓
规则沉淀 ←── 偏差发现 ←── AI 执行产出六、量化数据
产出总览
| 维度 | 数据 |
|---|---|
| 总周期 | 36.5 小时(4/17 23:59 ~ 4/19 12:30) |
| 主体开发 | 4/18 一天(53/56 commit,占 95%) |
| 人工参与 | ~88 分钟 |
| 后端 Python | 8,675 行 / 93 文件 |
| 前端 Vue 3 | 4,309 行 / 38 文件 |
| 测试代码 | 747 行 / 8 文件 |
| 代码总计 | 14,983 行 / 143 文件 |
| Git commit | 56 个 |
| Feature 分支 | 26 个 |
| Merge 操作 | 20 次 |
| API 端点 | 131 个 |
| ORM 模型 | 27 张表 |
| 前端页面 | 14 个 |
| 编码规则 | 14 条 |
效率对比(仅供参考)
| 模块 | 传统估算 | AI 协作实际 | 倍率 |
|---|---|---|---|
| 后端 CRUD(27 表) | 2-3 周 | 1 天 | ~15x |
| 前端页面(14 页) | 1-2 周 | 54 分钟 | ~100x |
| 部署流水线 | 2-3 天 | 1 小时 | ~20x |
这些倍率基于"功能等价迁移"这一高确定性场景。需求不明确的新功能开发,倍率会低很多。
七、时间线全景
4/17 4/18 4/19
23:59 00:00 06:00 12:00 18:00 00:00 12:30
│ │ │ │ │ │ │
├─ ① 规划 ─┐ │ │ │ │ │ │
│ 38min │ │ │ │ │ │ │
│ ├─ ② 骨架 ──┐│ │ │ │ │ │
│ │ 50min ││ │ │ │ │ │
│ │ │├─ 休息 ─┤ │ │ │ │
│ │ ││ ~6h │ │ │ │ │
│ │ ││ ├─ ③ CRUD ────────┤ │ │
│ │ ││ │ (AI 自动执行) │ │ │
│ │ ││ │ ├─ ④ 偏差修复 │
│ │ ││ │ │ 16min │ │
│ │ ││ │ ├─ ⑤ 网关+任务 ──┤
│ │ ││ │ │ │
│ │ ││ │ │ ⑥ 前端 54m │
│ │ ││ │ │ ⑦ 部署 │
│ │ ││ │ │ │
│ │ ││ │ │ BUGFIX │
▼ ▼ ▼▼ ▼ ▼ ▼
START 骨架完成 人休息 CRUD开始 验证通过 全功能完成八、可复制的方法论
适用场景
- 功能等价迁移 — 换语言/框架,不改业务逻辑
- 遗留系统现代化 — 有完整旧系统可参考
- 标准化批量开发 — 多个相似实体的 CRUD
五个关键成功因素
- 先规划,后执行 — PLAN.md + TASKS.md 建立确定性空间,AI 才能自主领任务
- 第一个实体建模板 — Platform 通过后,后续 10+ 实体 3-5 分钟自动套用
- 踩坑即刻写规则 — 每次偏差沉淀为规则文件,AI 不犯第二次
- 烟测优先 — Phase 完成立即验证,快速发现问题
- 滚动细化 — 不预拆所有任务,每个 Phase 入口先分析再细化
什么时候不适合
- 需求不明确的探索性项目(输入不确定)
- 业务逻辑需要重新设计的重构(输出不确定)
- 没有参考实现的全新开发
角色转变
你最大的价值不是写出那 14,983 行代码,而是写出那 14 条规则 —— 它们让 AI 从"不可控"变成"可控"。