最近一个月，我把四大国产大模型的代码能力拉到同一个真实业务重构场景里做了一轮硬碰硬的实测。起因很朴素：团队接手了一个遗留订单模块，要从老式JDBC数据访问层整体迁移到新持久层框架，同时把里头埋了两年的并发隐患一起解决。这活儿如果丢给大模型来做，到底能顶多少人力？四款模型在同一个仓库、同一段代码、同一组提示词下，表现差距远比想象中大。这篇内容就是把整个实测过程、验收标准、踩坑细节和最终结果完整摊开，给正在考虑用国产大模型辅助重构的团队一个参考。
1. 评测设计：为什么选真实业务重构而不是算法题
1.1 选型出发点：真实业务重构到底难在哪
这两年关于大模型代码能力的评测看过不少，但大多数测试还是围着算法题、LeetCode中等题、八股文式场景转。这类题目有一个共同特点：上下文极短、约束明确、输入输出清楚。模型只要见过类似题，很容易给出漂亮解法。可真实业务重构完全是另一码事——一个模块可能关联库存、订单、流水、账户多张表，业务规则藏在命名不规范的老代码里，事务边界动不动就跨方法，甚至还有历史遗留的隐式状态流转。
这次评测的任务全部来自一个模拟订单中心库存扣减模块，代码量不大，但是典型的"看着简单一改就翻车"结构。它包含三个真实业务痛点：
- 老代码没有任何注释，方法名和实际行为存在偏差；
- 数据访问层是手写JDBC，SQL字符串拼接严重，准备迁移到MyBatis；
- 库存扣减逻辑存在竞态条件，并发高了会超卖。
这三个点分别对应大模型的三项核心能力：遗留代码理解能力、跨层迁移改写能力、并发缺陷定位与修复能力。比起算法题，它们更能反映"模型能否帮工程师干真实的活"。
1.2 被测模型与评测方法
为了不涉及具体品牌，我用模型甲、模型乙、模型丙、模型丁来指代四款国产大模型，版本均为评测当天的公开通用对话版本，未开启联网搜索，温度参数全部设为0，保证输出可复现。
评测方式完全统一：同一个仓库，同一段代码片段，同一个提示词模板，同一套验收环境。执行环境是Java 17 + Spring Boot 3 + MySQL 8，数据库用Docker容器起一份独立实例。每个模型的输出都手动审查、编译、跑测试，不做主观印象打分。
提示词模板统一为三段式：先说业务背景，再贴代码片段，最后明确"我要你做什么、输出什么格式、不能做什么"。
1.3 评测维度与打分标准
打分维度一共六个，每个维度满分5分，按0.5分一档：
| 维度 | 说明 |
|---|---|
| 代码正确性 | 生成代码能否编译、能否通过单测、运行结果是否与预期一致 |
| 业务语义保留 | 是否改变了原有业务规则，比如扣减顺序、流水记录时机、异常抛出条件 |
| 边界处理 | 库存不足、并发扣减、空结果、超时等边界是否考虑到位 |
| 代码可维护性 | 命名、结构、注释、是否引入不必要复杂度 |
| 解释清晰度 | 对问题的定位、原因分析、方案理由是否讲得清楚 |
| 落地成本 | 产出物是否需要大量人工返工，是否需要额外引入重依赖 |
每个任务单独评分，最终加权平均。
2. 第一关：遗留代码理解与结构化注释生成
2.1 任务设置：把一段无注释的库存扣减模块讲清楚
第一关的任务是让模型理解一段约80行的遗留代码。这段代码的逻辑是：接收订单商品请求，查询库存表，判断库存是否充足，充足则扣减库存并插入扣减流水，否则抛出业务异常。但由于历史原因，方法名是handleOrderProcess，类名是OrderDealService，字段命名混乱，有一段看似"双写库存表"的冗余逻辑，实际上是为了兼容老报表系统。
提示词如下：
你是一名资深Java工程师。请阅读以下遗留代码，输出： 1. 这段代码的业务逻辑流程 2. 数据表和字段的使用情况 3. 潜在的风险点（事务、并发、异常处理等） 4. 针对该模块的重构建议 要求：结论简洁，优先说问题，不要输出修改后的完整代码。 [代码片段]四款模型的差距从这个任务开始就拉开了。
2.2 模型甲与模型乙的表现
模型甲的输出结构很干净，先按执行顺序拆分了主流程：参数校验、查询库存、判断可用量、扣减库存、插入流水、更新冗余报表字段。它准确识别出了"看似双写库存表，实际是向报表系统同步数据"这个隐藏语义，并且点名了两个关键风险：第一，checkAndDeduct虽然方法名暗示了原子操作，但实际上是"先查询再更新"的非原子流程；第二，事务注解加在handleOrderProcess上，可内部调用了另一个类的独立方法，事务会失效。
模型乙同样理清了主链路，但在风险识别上明显更浅。它把"双写库存"描述为"可能存在主从数据不一致"，建议做数据核对任务。这句话不能说错，但明显没有理解双写背后的报表兼容动机，给出的建议属于通用正确答案，对实际决策帮助有限。它也没有指出事务失效问题，只笼统说了"建议增加事务控制"。在注释理解这个维度上，模型乙的表现属于"能读但读不深"。
2.3 模型丙与模型丁的表现
模型丙的问题不是理解不足，而是输出爆炸。它给出了非常详细的流程分析，甚至把表结构、索引建议、分库分表方案都列了出来，其中确实包含正确结论——锁粒度太大、库存扣减必须使用条件更新、报表同步不应放在主事务里。但这份输出塞满了大量建模设想，属于"把它能想到的坑全列一遍"，工程师还得自己筛选哪些与当前代码真正相关。在"结构化注释生成"这件事上，它算合格，但落地成本高。
模型丁是四款里最让我意外的。它在业务语义上出现了比较明显的误判，把库存流水插入逻辑解释成了"记录每次浏览记录"，并且认为handleOrderProcess这个命名说明该方法"处理的是订单生命周期中的多个环节"。实际上方法内部只做了库存扣减，命名误导确实存在，但模型没有区分"命名想表达什么"和"代码实际做了什么"这两个层次，被方法名带偏了。这就是为什么真实重构场景比算法题更能暴露问题——算法题不需要判断代码语义和命名的偏差。
2.4 我对理解能力的判断依据
这一关的评分，重点不是看模型总结得有多全面，而是看它能不能抓住两个隐藏信息点：一是双写库存的真实用途，二是事务可能失效。
记住，大模型理解代码的方式是模式匹配加推理。它会从训练语料里见过的类似代码推断当前代码的意图。当语料里"双写"往往对应主从同步时，模型丁就会误判。这提醒我们：在真实项目里让大模型理解独家业务逻辑，一定要在提示词里提供足够的业务上下文，不能指望它靠代码"猜"出历史包袱。
最终评分：模型甲4.5分，模型乙3分，模型丙3.5分，模型丁2分。
3. 第二关：JDBC到MyBatis迁移的接口层改动
3.1 任务背景与业务约束
第二关是数据访问层迁移，这也是标题里"真实业务重构"最典型的工作。老代码用JDBC手写了好多SQL，现在要统一迁到MyBatis Mapper方式。这里面真正难的不是SQL本身，而是业务约束不能丢——比如查询库存时必须忽略逻辑删除的记录、扣减库存的SQL必须带库存充足条件、流水插入必须在同一事务里完成。
给模型的代码片段是一段手写JDBC的库存查询方法：
public List<StockRecord> queryStock(String productId, int warehouseType) { String sql = "SELECT * FROM stock_info WHERE product_id = '" + productId + "' AND warehouse_type = " + warehouseType; // 执行查询并逐行映射 }提示词要求：把它改造成MyBatis Mapper形式，使用注解方式，并补充合理的动态SQL处理，保证productId为空时不影响查询结果，同时处理可能存在的列表为空情况。禁止修改原有的SQL语义。
3.2 模型甲与模型乙的迁移结果
模型甲生成了完整的Mapper和对应的实体类映射，条件判断使用了MyBatis的<script>动态SQL，productId为空时自动跳过条件，warehouseType用一个Integer参数接收，并在SQL里做了空值排除。最重要的是它保留了warehouse_type字段的过滤逻辑，没有画蛇添足。把代码合入测试工程后，编译一次通过，写了几条测试数据跑下来结果与原JDBC实现一致。
模型乙生成的代码也基本可用，但在动态SQL的边界条件上出了一个小问题。当productId为空时，它生成的SQL是WHERE warehouse_type = ?，这没问题，可当productId不为空时，它写的条件判断用了productId != null and productId != ''，看似稳妥。问题出在参数占位符上：它直接拼了'${productId}'进去，虽然功能上能用，但引入了SQL注入风险。这是重构场景里非常典型的高危问题——输出代码功能正确，但安全底线被突破。
3.3 模型丙与模型丁的迁移结果
模型丙的迁移方案引入了@Cacheable缓存注解，希望通过二级缓存提升查询性能。单独看这段代码，缓存方案本身不算错，但在业务重构场景里这就是过度设计：原方法没有任何缓存语义，如果迁移后引入缓存，一旦库存被其他系统修改，缓存里的旧数据会让调用方读到过期库存，直接破坏业务正确性。我手动去掉缓存后才敢跑测试。它还重新命名了Mapper方法，导致调用方类也要跟着改，属于增加了不必要的重构面。
模型丁的问题集中在批量查询场景。它生成的方法用了foreach拼接批量ID，本来只是单ID查询，结果它直接"帮"我把查询方法改造成了批量接口。这种擅自扩能力的做法在重构里非常致命，容易让调用方误以为老逻辑本身就支持批量，从而漏掉对调用链路的审查。另外它生成的SQL里对warehouse_type用了<choose>分支，逻辑上没毛病，但代码冗余度高，阅读体验很差。
3.4 编译结果、单测与隐藏问题盘点
我把四份迁移代码都放进了同一测试工程，统一编译，编写了10条基础功能测试和5条边界测试，结果如下：
| 模型 | 能否编译 | 功能测试通过率 | SQL注入风险 | 是否擅自扩展行为 | 人工返工量 |
|---|---|---|---|---|---|
| 模型甲 | 通过 | 100% | 无 | 否 | 低 |
| 模型乙 | 通过 | 100% | 有 | 否 | 中 |
| 模型丙 | 通过 | 100% | 无 | 是（引入缓存） | 高 |
| 模型丁 | 通过 | 80% | 无 | 是（改为批量） | 高 |
有一个隐藏问题值得单独说：四款模型都把结果集映射成了StockRecord对象，但老代码里实际有一个字段叫lastUpdateTime，数据库列名是last_update_time。模型甲和模型丙正确做了驼峰映射，模型乙和模型丁把这个字段映射丢了，导致该字段全部返回null。功能测试没抓出来，因为调用方没断言这个字段，但真实业务里如果前端依赖这个时间做排序展示，就会产生隐性行为改变。重构最怕的就是这种"看起来没变、实际数据少了"的问题。
4. 第三关：并发缺陷修复与幂等改造
4.1 构造一个低概率并发事故现场
第三关是最能拉开模型差距的任务。库存扣减老代码是这样的：
public boolean deductStock(String productId, int count) { int stock = stockMapper.queryStock(productId); if (stock < count) { return false; } int affectedRows = stockMapper.updateStock(productId, stock - count); return affectedRows > 0; }这段代码的问题是经典的check-then-act竞态：两个线程同时读到库存100，同时判断100 >= 50，同时执行扣减，最终库存被写成50，实际上扣了两单各50，导致超卖。业务要求修复后在同一时刻只能有一个线程能扣减成功，库存永远不能为负数，且不能引入重锁影响整体吞吐。
这个任务考察的不只是"知不知道并发问题"，而是能否在数据库场景下给出真正可落地的修复。要注意的是，这里不是纯Java内存并发，最终一致性要看数据库层面的原子性，很多模型的方案会把线程安全和数据安全混为一谈。
4.2 四款模型修复方案对比
模型甲给出的方案是去掉先查后扣的流程，直接用一条条件更新SQL完成扣减：
UPDATE stock_info SET stock = stock - #{count} WHERE product_id = #{productId} AND stock >= #{count}然后通过执行影响行数判断是否扣减成功，失败时抛出业务异常。这个方案是Four中最接近生产实践的，既保证了原子性，又避免了分布式锁的复杂度。但模型甲忘了补一个细节：当count <= 0时，条件更新会恒真，导致库存被反向增加。我在验收时给它补上了参数校验，属于小返工。
模型乙用的是synchronized锁住整个方法。单实例部署下确实能解决本地竞态，但库存数据在数据库，如果应用后来做了多实例部署，锁立刻失效。考虑到当前系统已经是单体，这个方案不能说错，但属于修了眼前问题、埋了未来雷。模型乙没提锁粒度问题。
模型丙的方案最重，直接建议引入Redis分布式锁，并给出了锁的获取、释放、超时续期逻辑。整体设计成熟，但它没有意识到这个库存扣减场景根本不需要锁——数据库条件更新天然具备原子性。引入Redis锁反而增加了外部依赖和故障点，属于过度设计。模型丁最离谱，它把代码格式重新排了一下，然后原样返回，只加了"这段代码可能存在并发问题"的注释。等于没有做任何修复。
4.3 补测：生成单测能否抓住回归
最后一轮我让四款模型为修复后的方法生成单元测试，要求模拟并发场景：100个线程同时扣减10件库存，初始库存1000件，最终库存必须恰好为0，且每个扣减结果要么成功要么因库存不足失败，不允许出现例外。
模型甲的测试代码用了CountDownLatch同时放行所有线程，配合ExecutorService跑满并发，能稳定复现竞态条件下的bug——如果修复代码有问题，测试大概率失败。模型乙生成的测试是串行的，每个线程依次扣减，这种测试在修复前后都能通过，无法当作回归保护。模型丙生成的测试依赖Spring Boot容器和Redis，放在单元测试环境里根本起不来。模型丁输出了两行JUnit空测试壳，断言都没写。
这个结果其实很说明问题：很多模型能写"看起来正确"的业务代码，但让它思考"什么测试能证明这段代码是对的"，就暴露出对验证环节的理解不足。模型甲之所以赢，是因为它之前的修复方案本身就是基于"条件更新加影响行数判断"，它心里清楚怎样才叫扣减成功，自然能写出对应的并发测试。其他模型要么方案不对，要么验证思路不闭环。
5. 综合评分与场景化选择建议
5.1 各维度表现汇总
把三轮任务的评分汇总如下：
| 维度 | 模型甲 | 模型乙 | 模型丙 | 模型丁 |
|---|---|---|---|---|
| 代码正确性 | 5 | 4 | 4 | 2.5 |
| 业务语义保留 | 4.5 | 3.5 | 3 | 2 |
| 边界处理 | 4 | 3.5 | 3 | 2.5 |
| 代码可维护性 | 4.5 | 3.5 | 2.5 | 3 |
| 解释清晰度 | 4.5 | 3.5 | 4 | 2.5 |
| 落地成本 | 4 | 3 | 2.5 | 2.5 |
| 综合分 | 4.42 | 3.5 | 3.17 | 2.5 |
这个分数只代表这次评测环境下的表现。四个模型都在同一个场景下运行，参数一致，没有针对特定模型做提示词调优。真实使用中大家都会为特定任务调整提示词，所以综合分参考价值大于绝对意义。
5.2 什么场景可以优先选谁
从这轮实测看，不同模型的"偏科"非常明显，没有一款是全能王。
如果团队的核心痛点是老代码看不懂，需要大模型帮忙梳理业务链路、识别隐患，模型甲和模型丙都值得优先考虑。模型甲胜在精准，能快速锁定事务失效、非原子操作这类关键问题；模型丙胜在全面，适合用来做代码审查兜底，但需要人工过滤噪音。
如果任务是常规的数据访问层迁移，比如JDBC改MyBatis、JPA改MyBatis，模型甲和模型乙都能大幅提效。尤其是模型乙，在功能准确性上并不差，只要工程师在验收时补齐SQL注入检查就行。模型丙和模型丁在这类任务上容易擅自加缓存、改方法签名、扩大重构范围，反而增加review负担。
如果遇到并发缺陷排查，模型甲是首选，它对数据库原子更新和并发测试的理解明显更完整。模型丙的分布式锁思路也可以作为备选参考，但不要直接采用，除非系统确实需要跨实例互斥。
5.3 我踩过的坑与使用建议
这轮实测下来，我最大的感受是：大模型在真实重构场景里的上限很高，下限也很低。同样的任务，把提示词写清楚和写模糊，输出质量差别可能是两个等级。我整理了几个实际踩过的坑。
第一个坑是提示词里不给业务约束。第一轮理解任务，我没有告诉模型"双写是报表兼容"，模型丁立刻误判成主从同步。后来把业务背景补进提示词，它的理解准确率明显提升。所以不要指望模型能像老员工一样从代码里读出隐性业务规则，规则必须由人来提供。
第二个坑是不做参数校验就合入。模型甲生成的扣减SQL在count为负数时会出大问题，这是典型的"生成代码必须经过人工加protective check"的例子。任何从大模型拿到的代码都要当作初稿，而不是终稿，合入前至少补一轮边界测试。
第三个坑是让模型写测试，而不是直接要实现。实测中我发现一个非常高效的工作流：先让模型描述如何验证这个功能正确，再让它写测试代码，最后让它基于测试去改实现。这样生成出来的代码往往更稳，因为模型被迫先想清楚"正确"的含义。
最后提醒一句：国产大模型现在的代码能力已经真正能参与业务重构了，但不要迷信单一模型。我在第二关迁移任务中，会把模型甲生成的Mapper和模型乙生成的Mapper交叉对比，互相找问题，效率比只看一份输出高很多。工具是放大器，真正的重构判断力还是得靠自己。
我个人的习惯是，每次任务开始前，先花三分钟把"业务背景、目标代码、禁止行为"写清楚，然后让模型先生成一份执行计划。计划没问题再要代码，反而比直接拿代码更快。毕竟重构这件事，跑得快的未必是对的，跑得稳的才敢合入主干。
