Codex 实战：用真实问题串起路线

关注

原创最新推荐文章于 2026-11-12 17:50:33 发布 304 阅读 AI 写同款· GEO 优化 ›

Claude CLI 升级为本地 AI 调度台：多模型协同与目标驱动工作流 AI 命令行工具正从单次请求-响应模式，演进为具备状态管理、多模型协同与任务编排能力的本地调度中枢。其核心原理在于引入 Agent 抽象层、Goal 驱动引擎与持久化状态中心，将自然语言目标自动拆解为可追溯、可重试、带权限控制的子任务 DAG。这种架构显著提升复杂场景下的工程可靠性与调试效率，尤其适用于 DevOps 故障闭环、数据科学流水线和文档自动化等需跨模型协作的生产环境。本文聚焦 Anthropic 最新 Claude Code CLI 的调度台范式，深入解析其如何通过 /agents 和 /goa 阅读详情

聊《Codex 实战：一次新的项目切入》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

先把这篇文章的目标说清楚：看完之后，你应该能判断这件事值不值得做，以及从哪里动手。

上周的需求评审会上，产品甩过来一个稍微有点复杂的逻辑：“用户下单后，如果库存不足，需要异步触发补偿流程，并且要记录详细的审计日志。”

如果是半年前，我会直接打开 IDE，根据文档敲代码。但最近，团队开始尝试引入 AI 辅助编程，特别是像 Codex 和 Claude Code 这类工具。我当时的第一反应不是兴奋，而是警惕：AI 真的懂我们的业务上下文吗？它生成的代码，是能直接进主干，还是需要我花更多时间去 Review？

这次我们没有把它当成“自动写代码的神器”，而是当作一个“初级结对程序员”。我们要解决的不仅是代码生成，更是如何将 AI 的产出纳入现有的工程规范。以下是我在这次实战中的真实复盘，包括边界在哪里、取舍怎么做，以及最后给团队的一些建议。

Codex 的定位：是副驾驶，不是自动驾驶

文章插图 1

在深入细节之前，必须先对齐认知。很多开发者（包括我自己）刚上手时容易有两个极端：要么觉得它能解决所有问题，要么觉得它一无是处。

我的结论很明确：Codex 擅长处理局部逻辑和样板代码，但在系统级架构和跨模块依赖上，它目前还是一个“有上下文缺失的实习生”。

在 Java 后端项目中，它的核心价值体现在：
1. 快速生成单元测试：这是它最稳的输出，覆盖率能迅速拉升。
2. 样板代码转换：比如 DTO 转换、简单的 CRUD 接口。
3. Debug 辅助：抛出异常时，让它分析可能的原因并给出修复建议。

但它不适合：

涉及核心资金流、库存扣减等强一致性业务。
需要理解整个微服务链路关系的重构。

所以，我们定下的原则是：“AI 写初稿，人类做架构把控”。所有的 AI 生成代码，必须经过严格的 Code Review，且不能跳过单元测试。

项目上下文理解：喂给它“对”的饲料

文章插图 2

AI 生成质量差的根本原因，往往是 Context（上下文）缺失。如果我直接扔给它一个方法签名，它只能凭概率猜测实现逻辑。

在这次实战中，我没有直接把需求丢给 Codex，而是做了三步预处理：

1. 抽取核心领域模型：我将 Order、Inventory、AuditLog 这几个类的关键字段和关系整理成 Mermaid 图表或简化的 UML 描述。
2. 提供接口契约：明确告诉 AI，我需要调用哪些 Service 的方法，返回类型是什么，是否有异常抛出的约定。
3. 指定编码规范：我们在项目中使用了 Lombok、特定的异常处理机制（如全局异常处理器 GlobalExceptionHandler）和日志规范（SLF4J + MDC）。

我在 Prompt 中这样描述背景：
> “我们正在开发一个电商订单系统。当前需要实现库存不足时的异步补偿。请基于以下类结构：OrderService, InventoryClient, AuditLogRepository。注意：本项目使用 Spring Boot 3.x，事务管理基于 @Transactional，日志需包含 traceId。”

这种“喂料”方式，显著降低了幻觉率。AI 不再随意编造不存在的 API，而是基于给定的契约进行填充。

优快云资料领取方式

代码修改流程：从生成到可用的距离

生成代码只是第一步，真正的挑战在于如何将其融入现有代码库。这里有一个具体的例子：我们需要实现一个库存扣减失败的回调。

1. 初始生成

当我给出需求后，Codex 生成了如下代码片段：

@Service
public class OrderCompensationService {

    @Autowired
    private InventoryClient inventoryClient;

    @Autowired
    private AuditLogRepository auditLogRepo;

    // 假设这是主下单方法
    public void createOrder(OrderDTO order) {
        try {
            inventoryClient.deduct(order.getSkuId(), order.getQuantity());
        } catch (InsufficientStockException e) {
            // AI 生成的简单处理
            log.error("库存不足", e);
            throw new BusinessException("库存不足");
        }
    }
}

这段代码看起来没问题，但仔细一看，有几个致命缺陷：

缺乏异步解耦：题目要求是“异步触发”，但这里显然是同步阻塞。
事务边界混乱：如果在主事务中捕获异常并抛出，可能导致数据不一致。
没有利用消息队列：对于高并发场景，直接抛异常会导致用户等待时间过长。

2. 人工介入与修正

我并没有让 AI 继续“优化”，而是手动修改了架构思路，然后让 AI 补充具体实现。

我给出的新指令是：
> “改为异步处理。使用 Spring ApplicationEvent 发布事件，由监听器消费。监听器中调用 InventoryClient 重试，最大重试 3 次，间隔指数退避。同时记录审计日志。”

AI 随后生成的代码如下：

@Component
public class StockCompensationListener {

    @Autowired
    private InventoryClient inventoryClient;

    @Autowired
    private AuditLogRepository auditLogRepo;

    @Async
    @EventListener
    public void handleStockCompensation(StockCompensationEvent event) {
        int retryCount = 0;
        while (retryCount < 3) {
            try {
                inventoryClient.recoverStock(event.getSkuId(), event.getQuantity());
                auditLogRepo.save(new AuditLog(event.getOrderId(), "RECOVER_SUCCESS"));
                return;
            } catch (Exception e) {
                retryCount++;
                auditLogRepo.save(new AuditLog(event.getOrderId(), "RETRY_FAIL", "Attempt " + retryCount));
                if (retryCount == 3) {
                    // 最终失败报警，不吞异常
                    throw new RuntimeException("Recovery failed after 3 retries", e);
                }
                // 简单模拟指数退避
                Thread.sleep((long) Math.pow(2, retryCount) * 1000);
            }
        }
    }
}

虽然这还不是生产级别的健壮代码（比如应该用 Resilience4j 而不是手写 sleep），但它符合了异步、重试、日志的核心诉求。这就是取舍：我们接受 AI 在基础设施库选用上的不成熟，但通过明确指令控制业务逻辑的正确性。

测试与验证：AI 的最强项

如果说写业务代码让我有保留意见，那么写单元测试则是让我真香的地方。

在上面的 StockCompensationListener 中，我让 Codex 生成对应的 JUnit 5 + Mockito 测试用例。

@SpringBootTest
class StockCompensationListenerTest {

    @Autowired
    private StockCompensationListener listener;

    @MockBean
    private InventoryClient inventoryClient;

    @MockBean
    private AuditLogRepository auditLogRepo;

    @Test
    void testHandleSuccess() throws Exception {
        StockCompensationEvent event = new StockCompensationEvent("ORDER_123", "SKU_001", 5);

        Mockito.when(inventoryClient.recoverStock(Mockito.anyString(), Mockito.anyInt()))
               .thenReturn(true);

        // 执行
        listener.handleStockCompensation(event);

        // 验证
        Mockito.verify(auditLogRepo, Mockito.times(1))
               .save(Mockito.argThat(log -> log.getStatus().equals("RECOVER_SUCCESS")));
    }

    // ... 其他失败场景测试
}

AI 生成的测试用例覆盖率很高，涵盖了正常路径和异常路径。我只需要检查 Mock 的行为是否符合预期，以及断言是否严谨。这让我节省了至少 50% 的测试编写时间，而且测试的回归安全性比人工写的更高。

团队使用建议：边界与规范

基于这次实战，我对团队使用 AI 编程工具总结了三点建议：

1. 建立“Prompt 模板库”：
不要每次都从零开始写 Prompt。我们将常用的上下文（如项目结构、技术栈、规范）封装成 System Prompt 的一部分。对于 Java 团队，我们可以定义一套标准的“角色设定”，例如：“你是一名资深 Spring Boot 专家，遵循阿里巴巴 Java 开发手册...”。

2. 强制 Code Review 机制：
AI 生成的代码必须被视为“草稿”。Reviewer 的重点不应是语法错误，而应是：业务逻辑是否正确？性能是否有隐患？安全漏洞（如 SQL 注入、越权）是否存在？我们规定，任何涉及数据库写入的代码，必须在本地运行完整的集成测试后才能提交。

3. 从“单人提效”转向“团队协同”：
AI 工具最大的价值不是让一个人写得更快，而是降低团队的知识门槛。新人可以通过阅读 AI 生成的代码和测试，快速理解现有模块的逻辑。但这也带来了风险：如果所有人都依赖 AI 生成同样的代码，可能会导致技术债的快速积累。因此，需要定期清理和规范 AI 生成的代码风格。