书接上文：《万字：AI Coding到了什么程度了？》，我们得到的结论是：AI Coding已经不只是适合写Demo、补函数、起页面了。在约束清楚、边界明确、验收方式可执行的前提下，它已经可以参与相当一部分真实交付工作。
然后，用过AI Coding的同学也会很清楚，在新项目、规则清晰的项目上，AI的威力很大，那么对应的问题也就来了：年老失修的屎山代码AI Coding的情况怎么样呢？比如：运行十余年的系统，文档缺失、逻辑混乱、维护成本高到离谱，想重构又怕出问题，不重构又制约业务迭代，这种地狱模式AI是否立得住？
今天就和大家分享我们团队的AI Coding实战经历：仅用2周，成功重构一套运行10年、累计54万行PHP代码的核心电商系统，平稳迁移至Java版本，全程依靠AI，成功做到了按时平稳地交付。
地狱开局
10年老系统、54万行PHP、两周交付窗口、核心电商链路、PHP迁到Java，这类项目，哪怕纯人工来做，很多团队都得沉默。
因为这种事最难的地方，从来都不是代码怎么写，而是：你根本不知道自己到底在动一个什么东西。
老系统不像新项目，新项目业务逻辑清晰（至少文档清晰），很多时候你只要把需求拆清楚，AI就能一路往前推，但屎山代码不是这样。它最大的问题，不是烂，而是它烂得很复杂、很真实、还已经在线上跑了很多年。
很多逻辑，文档里没有；很多分支，设计稿里没有；很多兼容，甚至连原开发自己都未必记得为什么要这么写。你今天看到的一段坏代码，很可能不是谁当年水平不行，而是因为三年前有个线上事故，临时用这种方式先兜住；你今天觉得某个字段命名奇怪，也许背后已经挂着三个旧客户端和五个外围系统…
AI的价值
这次项目里，我们一直坚持一个很明确的原则：AI扛效率，人控边界。因为AI最大的风险，从来不是它不会写，而是它看起来写得很像那么回事。
AI在这次项目里，真正改变的是这三件事：
- 把旧系统变成可操作的对象：批量梳理接口调用关系、提炼参数逻辑和异常分支、生成架构图、提取入参出参
- 大规模机械翻译和重复改造：PHP转Java初稿生成、函数拆解与重构、工具类提取、DTO化改造
- 验证、比对、排障：自动生成测试用例、辅助白盒测试、自动生成新旧差异清单
工程化方法论
这次项目如果一定要提炼方法论：
- 先按风险分层，不平均用力（20%接口承载80%风险）
- 强制Plan模式，先出方案，再动代码
- 把Prompt从提问升级成规则系统
- 把能跑拆成三层：能跑、能对、能稳
结语
做完这次项目之后，我对AI Coding有一个更明确的判断：
- 遗留系统改造被AI覆盖了：遗留系统最痛的（理解成本高、重复劳动多、验证链条长），恰恰都是AI最擅长提效的地方
- 边界很重要：会写提示词，不等于会做交付；会调模型，不等于会做工程。真正的门槛，是风险拆解、边界定义、验证设计、灰度发布和回滚兜底
- 有人会失业：以后工程师更重要的能力，可能不再只是我能写出一段多漂亮的代码，而是我能不能快速理解系统、拆解问题、识别边界、设计工作流，并对最终结果负责
AI不会替你为系统承担责任，但它会把那些原本压得人喘不过气的脏活、累活、重复活，成片地吞掉。谁先学会和它协同，谁就更有机会接住那些过去根本不敢接的硬仗。
来源：虎嗅 | 作者：叶小钗 | 原文链接：AI Coding 实战：10年祖传系统，54万行代码，2周重构结束
