初级、高级程序员和AI处理同一需求，结果差异大，谁的表现最让人意外？
摘要：上个月，我们有个新功能要做：实现一个订单退款接口。 需求不复杂，但涉及金额变更、库存回滚、状态流转，刚好是个能拉开差距的典型场景。 当时团队有点忙，我临时把这个需求分别交给了三个"人"：
上个月，我们有个新功能要做：实现一个订单退款接口。
需求不复杂，但涉及金额变更、库存回滚、状态流转，刚好是个能拉开差距的典型场景。
当时团队有点忙，我临时把这个需求分别交给了三个"人"：
小王，工作1年半的初级开发
老陈，工作6年的高级开发
Cursor（我给它写了一个详细的Prompt）
三份代码我都仔细看过了。
看完之后，我沉默了很久。
第一个：小王（工作1年半）
我把需求文档发给他，他没有追问，当天下午就说："做完了，测试通过了。"
速度确实快。打开代码一看：
@PostMapping("/refund")
@Transactional
public Result<Boolean> refund(@RequestBody RefundRequest request) {
Order order = orderMapper.selectById(request.getOrderId());
if (order == null) {
throw new BusinessException("订单不存在");
}
if (order.getStatus() != OrderStatus.PAID) {
throw new BusinessException("订单状态不支持退款");
}
// 退款金额写回
order.setStatus(OrderStatus.REFUNDED);
order.setRefundAmount(request.getRefundAmount());
orderMapper.updateById(order);
// 调用支付退款接口
payService.refund(order.getPaymentNo(), request.getRefundAmount());
// 库存回滚
inventoryService.rollback(order.getProductId(), order.getQuantity());
return Result.success(true);
}
功能逻辑是对的，基本流程都有，单元测试也过了。
但我看了两分钟，发现了几个问题：
问题1：没有幂等控制。 如果这个接口被重复调用两次（网络超时重试是很常见的），订单会被退款两次，库存回滚两次。这是生产事故级别的bug。
问题2：退款金额没有校验上限。 request.getRefundAmount() 没有和订单实际支付金额做比对，理论上可以传一个比实际支付金额更大的数字。
问题3：payService.refund 失败后没有补偿机制。 调用第三方支付退款失败了怎么办？状态已经改了，但钱没退出去，这个烂摊子谁来收拾？
我去找小王聊。
他说："我以为测试通过了就行。"
这就是问题所在。他交付的是一个"能跑的功能"，不是一个"可以上生产的方案"。
他想到了正常流程，但没有想过任何一个异常流程。
第二个：老陈（工作6年）
老陈拿到需求之后，没有立刻动手。
他先发了一条消息给我，问了3个问题：
退款是全额退款还是支持部分退款？
退款金额打回原路还是可以退到其他账户？
退款后库存需要实时回滚，还是等退款成功回调之后再回滚？
我当时看到这3个问题，愣了一下。
这3个问题，需求文档里都没写清楚。
我去问了产品，产品想了半天，说："支持部分退款，退回原路，库存等退款成功回调之后再回滚。"
这3个答案，直接影响了整个接口的设计。如果不提前搞清楚，后面改起来成本极高。