用AI重构老代码，纯属自嗨？
我觉得拿AI去重构祖传老代码，基本就是给自己挖坑。老代码能跑就别乱动，AI根本看不懂那些历史包袱和隐藏业务逻辑；它一出手就是重写，测试覆盖不够直接炸锅。有那功夫不如写新功能。你有没有被AI“优化”出过线上事故？来聊聊。
回复（4）
登录后参与讨论
我觉得拿AI去重构祖传老代码，基本就是给自己挖坑。老代码能跑就别乱动，AI根本看不懂那些历史包袱和隐藏业务逻辑；它一出手就是重写，测试覆盖不够直接炸锅。有那功夫不如写新功能。你有没有被AI“优化”出过线上事故？来聊聊。
登录后参与讨论
你这个观点我基本同意，但也不绝对。我之前用AI重写一个跑了三年的对账逻辑，结果它把两个字段的精度处理改了，测试还没覆盖到，上线当天就出问题了。后来学乖了，只让AI先写注释和加测试，把老代码的边界条件锁死，再考虑重构，这样风险小很多。
我上月拿一个八年的订单状态机试过，让AI先补测试再重构，结果它把三个隐藏的脏数据兼容分支直接删了，测试还全绿，因为那些分支线上压根没覆盖。所以我现在的态度是：老代码要动就人来定边界，AI最多当个加注释和补测试的工具，让它主导重构基本等于赌命。
老代码那堆脏分支，AI 删得比谁都快，测试全绿反而更吓人，因为这恰恰说明你压根没测到点上。我的态度很明确：AI 可以帮你补测试、加注释、梳理调用链，但重构方案必须人来拍板，谁主导谁背锅。真出过线上事故的都懂，那玩意儿不是自嗨，是自爆。
老代码重构这事，我站反方但只反一半：让AI主导重写绝对是给自己埋雷，但说纯属自嗨也太绝对了。我见过最划算的用法是让AI把核心链路的隐藏分支和脏数据兼容逻辑扒出来写成测试，人再拍板动不动——这步做完，很多时候你会发现根本不用重构。真要有人拿AI“优化”出过线上事故，那多半是连测试都没锁死就敢上线，这不叫AI的锅，叫流程的锅。