聊《Codex怎么学？先做一个会暴露问题的真实项目》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

上周业务方提了个需求：把订单服务的库存扣减逻辑从同步调用改成异步消息驱动，理由是"现在高峰期DB连接池经常打满"。我顺手把需求丢给Codex，结果它给出的方案看着很完美，团队一起review的时候才发现，几个关键坑全藏在上下文里——这就是我用Codex接入真实项目一周后的真实感受：工具本身没问题，但团队协作流程没跟上，效率反而先跌了一截。

目录

• Codex 的定位：不是代码生成器，是上下文理解器
• 真实案例：订单服务库存扣减重构
• 排查过程：协作翻车的三个典型场景
• 代码解释：关键逻辑的输入输出与异常处理
• 失败原因：业务错误、配置错误、环境错误的区分
• 适用边界：什么时候不该照搬方案
• 总结

Codex 的定位：不是代码生成器，是上下文理解器

很多人对 Codex 的第一印象是"能把需求描述翻译成代码"，这个认知对了一半。它在小片段生成上确实快，比如写个单元测试、补个工具函数，但一旦进入项目级修改，它的真正价值在于上下文理解——而不是代码生成速度。

我做过一个对比：同样一个"加个日志"的需求，给 Codex 的上下文不同，结果天差地别。

反例：只给函数签名，Codex 会按通用模式补代码，结果日志级别写错、上下文丢失。
正例：把同类日志、调用链路、异常处理都喂进去，Codex 能写出风格一致、逻辑自洽的代码。

所以 Codex 的正确用法是：先喂上下文，再让它改代码，而不是直接让它"根据需求生成"。

真实案例：订单服务库存扣减重构

背景

项目是 Java Spring Boot 微服务，订单服务有段库存扣减逻辑：

@Service
public class InventoryService {

    @Autowired
    private InventoryMapper inventoryMapper;

    public boolean deductStock(Long orderId, Long productId, int quantity) {
        // 1. 查询库存
        Inventory inventory = inventoryMapper.selectByProductId(productId);
        if (inventory.getStock() < quantity) {
            throw new BusinessException("库存不足");
        }
        // 2. 扣减库存（同步）
        int rows = inventoryMapper.deductStock(productId, quantity);
        if (rows == 0) {
            throw new BusinessException("扣减失败");
        }
        // 3. 记录日志
        log.info("库存扣减成功, orderId={}, productId={}", orderId, productId);
        return true;
    }
}

业务方要求改成异步消息驱动，目的是削峰，避免高峰期 DB 连接池打满。

输入与步骤

我把以下信息喂给 Codex：

1. 完整的服务代码（库存服务、订单服务、消息队列配置）
2. 同类异步处理的其他模块代码（比如退款服务的异步逻辑）
3. 异常处理规范和日志规范
4. 需求文档（异步消息驱动、削峰、最终一致性）

Codex 输出了一段改造后的代码，核心逻辑如下：

@Service
public class InventoryService {

    @Autowired
    private InventoryMapper inventoryMapper;

    @Autowired
    private RabbitTemplate rabbitTemplate;

    public void deductStockAsync(Long orderId, Long productId, int quantity) {
        // 1. 发送异步消息
        Map<String, Object> msg = new HashMap<>();
        msg.put("orderId", orderId);
        msg.put("productId", productId);
        msg.put("quantity", quantity);
        msg.put("timestamp", System.currentTimeMillis());

        rabbitTemplate.convertAndSend(
            "inventory.exchange",
            "inventory.deduct",
            JSON.toJSONString(msg)
        );

        log.info("库存扣减消息已发送, orderId={}, productId={}", orderId, productId);
    }

    @RabbitListener(queues = "inventory.deduct.queue")
    public void handleDeductStock(String message) {
        Map<String, Object> msg = JSON.parseObject(message, Map.class);
        Long orderId = (Long) msg.get("orderId");
        Long productId = (Long) msg.get("productId");
        int quantity = (int) msg.get("quantity");

        try {
            int rows = inventoryMapper.deductStock(productId, quantity);
            if (rows == 0) {
                throw new BusinessException("扣减失败");
            }
            log.info("库存扣减成功, orderId={}, productId={}", orderId, productId);
        } catch (Exception e) {
            log.error("库存扣减异常, orderId={}, productId={}", orderId, productId, e);
            // 2. 死信队列处理
            rabbitTemplate.convertAndSend(
                "inventory.exchange",
                "inventory.deduct.dead",
                message
            );
            throw e;
        }
    }
}

可观察结果

代码跑起来后，发现三个问题：

1. 消息丢失风险：没有考虑消息发送失败的情况，如果 rabbitTemplate.convertAndSend 抛异常，订单状态和库存状态不一致。
2. 幂等性问题：没有加幂等校验，消息重试会导致重复扣减。
3. 日志不完整：原同步逻辑有"扣减成功"日志，但异步场景下，消费者里的日志缺少订单号的关联，排查困难。

这些问题 Codex 没有主动提示，因为它只看了代码，没看业务约束。

排查过程：协作翻车的三个典型场景

现象一：代码风格不一致

验证动作：我让团队里另一个开发者用 Codex 改同一块代码，结果两段代码风格完全不同——一个用了 Optional，一个直接判空；一个用了 log.info，一个用了 logger.info。

排除结果：不是 Codex 的问题，是我们没有给它统一的代码规范上下文。后来我们把团队的代码规范文档、风格示例都喂给它，输出才趋于一致。

现象二：异常处理逻辑缺失

验证动作：review 代码时发现，Codex 生成的异常处理只覆盖了"业务异常"，没有考虑"系统异常"的重试策略。

排除结果：这是 Codex 的上下文理解边界问题——它不知道我们项目有重试机制，因为重试配置在另一个模块里，没有喂给它。

现象三：测试用例不完整

验证动作：Codex 生成的单元测试只覆盖了正常路径，没有覆盖异常路径和边界条件。

排除结果：不是 Codex 能力问题，是我们没有明确告诉它测试规范。后来我把团队的测试规范（Mockito 用法、边界条件覆盖要求）喂给它，测试用例才完整。

代码解释：关键逻辑的输入输出与异常处理

消息发送段

rabbitTemplate.convertAndSend(
    "inventory.exchange",
    "inventory.deduct",
    JSON.toJSONString(msg)
);

• 输入：订单ID、商品ID、数量
• 核心逻辑：将参数序列化成 JSON，发送到指定的 Exchange 和 Routing Key
• 输出：无返回值，依赖 RabbitMQ 的确认机制
• 异常处理：如果发送失败，会抛 AmqpException，但 Codex 没有处理这个异常，导致订单状态不一致

消息消费段

@RabbitListener(queues = "inventory.deduct.queue")
public void handleDeductStock(String message) {
    // ...
    try {
        int rows = inventoryMapper.deductStock(productId, quantity);
        if (rows == 0) {
            throw new BusinessException("扣减失败");
        }
        log.info("库存扣减成功, orderId={}, productId={}", orderId, productId);
    } catch (Exception e) {
        log.error("库存扣减异常, orderId={}, productId={}", orderId, productId, e);
        rabbitTemplate.convertAndSend(
            "inventory.exchange",
            "inventory.deduct.dead",
            message
        );
        throw e;
    }
}

• 输入：JSON 格式的消息体
• 核心逻辑：解析消息、扣减库存、记录日志
• 输出：无返回值，依赖数据库事务
• 异常处理：捕获异常后发送到死信队列，但没有幂等校验，消息重试会重复扣减

关键缺失：幂等性校验

// 应该加这段
String idempotentKey = "inventory_deduct:" + orderId + ":" + productId;
if (redisTemplate.hasKey(idempotentKey)) {
    log.warn("重复消息, 已处理过, orderId={}, productId={}", orderId, productId);
    return;
}
redisTemplate.opsForValue().set(idempotentKey, "1", 24, TimeUnit.HOURS);

这段 Codex 没有主动加，因为它不知道我们有 Redis 做幂等控制。

失败原因：业务错误、配置错误、环境错误的区分

业务错误

• 表现：逻辑不符合业务需求，比如异步场景下没有考虑最终一致性
• 区分方法：问业务方"这个场景下，数据不一致能接受吗？"
• 本次案例：消息发送失败没有补偿机制，导致订单和库存状态不一致

配置错误

• 表现：代码能跑，但配置不对，比如 Exchange、Queue 名称写错
• 区分方法：看报错信息，通常是 Exchange not found 或 Queue not bound
• 本次案例：Codex 生成的代码里 Exchange 名称和项目实际配置不一致

环境错误

• 表现：本地能跑，线上报错，比如依赖版本不一致
• 区分方法：对比本地和线上的依赖版本、配置文件
• 本次案例：本地 RabbitMQ 版本和线上不一致，导致消息序列化方式不同

适用边界：什么时候不该照搬方案

适用场景

• 小范围重构：改动点明确、上下文可控
• 代码风格统一：有规范的代码示例可以喂给 Codex
• 测试用例生成：有明确的测试规范

限制条件

• 跨模块依赖：Codex 看不到其他模块的代码，容易生成不兼容的接口
• 业务约束复杂：需要理解业务语义，Codex 只能看代码
• 团队协作：多人用 Codex 生成代码，风格可能不一致

取舍建议

• 不要完全依赖 Codex：它适合"辅助"，不适合"主导"
• 必须人工 review：特别是异常处理、幂等性、事务边界
• 统一上下文：把项目规范、代码风格、测试规范都喂给它

总结

Codex 接入团队项目，最先翻车的不是代码，是协作流程。

工具本身没问题，但团队协作需要建立新的规范：

1. 上下文喂全：把项目规范、代码风格、测试规范都喂给 Codex
2. 人工 review 不能省：特别是异常处理、幂等性、事务边界
3. 统一输出风格：多人用 Codex 生成代码，容易风格不一致

这次项目让我意识到：AI 编程工具不是替代开发者，而是放大开发者的上下文理解能力。上下文喂得越全，输出越靠谱；协作流程没跟上，工具再强也是白搭。

资料展示

下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

需要这份AI大模型资料清单的话，在评论区回复「清单」即可；我会根据大家的问题继续补充对应的实战内容。