我把整个订单系统喂给GPT-5.6，它连隐式反射调用都找到了
上周把跑了3年的订单系统给重构了。GPT-5.6的API，17个微服务，2300多个文件，4天搞定。
去年干过一票类似的，6个人，3个月。
不是标题党。是真的。
先说下背景。这系统是21年写的，4任主程经手，技术债厚得离谱。去年那次重构差点把团队搞散——光理业务逻辑就花了2周。各种隐式依赖、魔法数字、没人敢动的上帝类，有个同事跟我说他晚上做梦都在看if-else。
这次GPT-5.6出来，官方说上下文窗口扩到2M token，大代码库理解能力有质的提升。我第一反应：又来画饼。但刚好赶上要重构，就顺手测了下。
打脸来得很快。
场景一：全量代码库理解
我把整个订单模块的代码，大概80万行，一次性通过API喂进去。然后问了个跨服务的业务逻辑问题：
"用户取消订单时，优惠券回滚和库存释放的先后顺序是什么？库存释放失败的话，优惠券会不会被误扣？"
看着简单对吧？实际涉及4个微服务、2个消息队列、1个定时补偿任务。去年排查相关bug，3个人翻了2天代码。
GPT-5.6大概40秒后给出完整调用链路：
- 订单服务先调优惠券服务的rollback()
- 然后发MQ消息给库存服务
- 库存服务消费失败会重试，最多3次
- 但优惠券不会自动回滚，要靠定时任务扫描coupon_rollback_fail表来补偿
我找老张核对。老张是这块的活文档，他看完说全对。连那个补偿任务的cron表达式都标出来了。
说实话，看到这个我后背有点发凉。新人理解系统的成本，从几周降到几分钟？
嗯...这个比较复杂。但确实在发生。
场景二：跨文件重构
我给GPT-5.6下了个需求："把订单状态机从if-else改成策略模式，保证所有调用方不受影响。"
这玩意儿牵一发动全身。订单状态11种，流转规则写了满满3页wiki，各种边界条件能逼疯人。
它的输出：
1. 先画了个状态流转图，mermaid语法，我直接贴文档里就能用
2. 列出需要新建的4个策略类，每个类的职责
3. 标出23个调用方文件，逐个说明改动方案
4. 然后提醒我："PromotionService.java第342行有个隐式依赖，通过反射调了状态机的私有方法，这个要单独处理"
看到第4点我骂了句脏话。那个反射调用是2年前紧急需求留下的，全组就我和老张知道。写代码的人早离职了。
按它的方案，我花了1天改完。全量回归测试，0bug。
等等，这里我要更正一下——不是0bug，是0个功能性bug。后来发现有个日志级别写错了，warning打成warnning。这个锅是我的，它给的代码是对的。
场景三：翻车现场
也不是每次都这么神。
有次让它分析死锁问题，我把相关代码和日志都丢进去。它分析得头头是道，指出根本原因是两个事务加锁顺序不一致。
我按建议改了。死锁确实没了。
但出现了更严重的数据不一致。
后来才发现，它忽略了一个异步回调里的隐式事务传播。那个逻辑藏在一个AOP切面里，代码层面根本看不出来。我翻了2天，最后是在arthas里watch了3个小时才定位到。
教训：GPT-5.6对显式逻辑的理解很强。但对运行时行为、框架黑魔法、配置中心动态下发这类东西，还是容易翻。别当银弹，该做的Code Review一步不能少。
一些数据
这次重构的关键指标：
| 指标 | 去年人工重构 | 这次GPT-5.6辅助 |
|------|-------------|-------------------|
| 代码理解阶段 | 14人天 | 2人天 |
| 方案设计阶段 | 8人天 | 1.5人天 |
| 实际编码阶段 | 45人天 | 8人天 |
| 测试阶段 | 20人天 | 6人天 |
| 发现bug数 | 17个 | 3个 |
| 上线后事故 | 2次 | 0次 |
效率提升大概5到6倍。但我觉得这个数字意义不大。
真正有价值的是：资深工程师的时间可以花在架构决策上，而不是在代码海洋里当考古学家。
几个建议
如果你也想在大型重构里用GPT-5.6，我踩过的坑供参考：
1. 喂代码前先做清洗
把明显废弃的、注释掉的、测试用的假数据清理掉。垃圾进垃圾出，大模型也一样。我用了一个周末专门干这个，大概删了1万2千行废代码。据我了解，很多老项目都有这问题。
2. 分步提问
别一上来就问"怎么重构"。先让它理解现状，再分析问题，最后出方案。每一步验证完再往下走，能避免很多幻觉。这个套路我是从2024年底那篇《LLM-driven Refactoring》论文里学的，确实管用。
3. 关键决策必须人工确认
涉及资金、数据安全、核心业务流程的地方，它的建议只能当参考。这次所有跟支付相关的改动，我都是亲自review的。不敢放手。
4. 把它的输出当第一稿
它给的设计方案、代码实现，当成一个高级实习生的产出。能用，但需要资深工程师打磨。别指望一步到位。我觉得这个心态很重要，不然很容易翻车。
写了这么多，其实最想说的是：工具在进化，但工程师的核心能力没变。
理解业务、做权衡、承担责任。
GPT-5.6能帮你省掉80%的体力活。但最后拍板的那个瞬间，还是得你来。
你们团队开始用GPT-5.6了吗？有没有遇到过什么神奇的翻车现场？评论区聊聊，我特别想听听别人的踩坑故事。最近在v2ex上看到几个帖子讨论这个，感觉大家都还在摸索阶段。
#GPT5 #API重构 #技术管理 #工程效率 #AI编程
读者评论 2