年初接了个活，一个跑了六七年的内部系统要把一批用存储过程写的业务逻辑迁移成应用层代码，代码本身没什么文档，写这套东西的人早就离职了，属于典型的”没人敢动”的遗留系统。这次基本全程用 Claude Code 辅助，记一下过程中的取舍和几个印象深的地方，不是吹它多神，是记录几个真实的坎坷。
一开始最大的问题不是写代码，是看不懂现状。存储过程里的逻辑层层嵌套，一个过程调另一个过程，中间还夹杂着几个看名字完全猜不出用途的临时表。没有直接开写，先让它通读这批 SQL 文件，输出一份逻辑梳理文档,包括每个存储过程做了什么、被谁调用、有哪些隐藏的业务分支。这一步花的时间不少,但比自己一行行啃 SQL 快得多，而且它整理出来的调用关系图确实帮我发现了两处死代码——有个存储过程压根没有任何调用方，删了都没人知道。
真正开始动手的时候踩了第一个坑：一上来贪心，想让它把整个模块一次性迁移完。结果改到一半，发现某个存储过程里藏着一个很隐蔽的业务规则——某类订单在退款的时候金额计算要额外扣一道特殊手续费，这个逻辑散落在三个不同的分支判断里,没有任何注释。它没识别出这层隐藏规则,迁移过去的代码在这一点上是错的,还好上线前的回归测试兜住了，不然是真金白银的账损。这次之后改变了策略，不再图快整块迁移，而是拆成一个个边界清晰的小任务，每完成一小块就跑一遍对照测试（老的存储过程和新代码拿同一批历史数据跑，比对结果是否一致），确认没问题再往下走。这个教训说白了不是 Claude Code 的锅，遗留系统里的隐藏业务规则本来就是所有重构工作最大的风险，不管是人还是 AI 来做，都得靠测试兜底，不能纯靠读代码就自信满满地觉得理解全了。
中间有一段是关于测试数据构造的活，这块反而是体验最好的部分。老系统的测试数据规则很绕，得模拟出几十种订单状态组合,手写这些测试用例本来是最枯燥的体力活,交给它写测试数据生成脚本效率提升非常明显，而且因为规则本身就是从代码里推导出来的，覆盖度比我自己手写还全，测出来两个我压根没想到的边界情况（比如订单金额为零但优惠券又核销了的诡异组合）。这种规则明确、纯体力堆量的活，是这次体验下来收益最扎实的场景。
也不是所有环节都顺利，涉及到需要拍板做取舍的地方，比如老逻辑里有个明显不合理但线上一直这么跑的计算方式，是原样照搬保持行为一致，还是趁机改成正确逻辑，这种需要业务判断、要跟产品和财务对齐的决策，它给不出答案，也不该指望它给答案，这类拍板始终得是人来做，Claude Code 能帮着把两种方案的影响面列清楚，最终选哪个还是得拉相关的人一起商量。
上线前最后一步是让它帮忙写迁移过程的回滚方案，这一步反而是我最谨慎的地方，回滚脚本涉及生产数据，写完之后没有直接用，而是在预发环境完整跑了一遍演练,确认真出问题的时候这套回滚流程真的能把数据带回原状，才敢在正式迁移方案里带上。这也是这次复盘下来比较明确的一个心得：凡是涉及生产数据、不可逆操作的部分，AI 辅助写的方案都要经过真实环境的演练验证，不能因为代码看起来逻辑通顺就直接信了。
整体算下来这次改造花的时间比预估的要短，主要省下来的是读代码梳理逻辑和写测试数据这两块最耗人力的部分。但真正决定这次改造成不成功的，还是那几个靠人工经验和业务判断兜底的关键节点——识别隐藏规则、做取舍决策、验证回滚方案，这些地方偷不得懒，也没打算偷懒。