Codex 实战：用项目结果反推能力

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

摘要

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

最近团队里掀起了一阵“AI 结对编程”的热潮。以前大家觉得 GitHub Copilot 够用了，现在看到 Codex 和 Claude Code 这种能直接操作文件系统的 Agent 式工具，很多技术负责人开始焦虑：这玩意儿到底能不能直接进生产环境？还是说只是个人提升效率的小玩具？

上周我硬着头皮把我们组的一个老旧 Spring Boot 模块接入了 Codex，想看看它在处理“屎山”代码时的真实表现。结果不仅没让我省心，反而给我上了一课：AI 编程工具从个人试用走向团队协作，最大的门槛不是模型智商，而是上下文的一致性和修改边界的控制。

这篇文章不聊虚的概念，就复盘这次实战中我犯的几个错误假设，以及最后怎么把这些坑填上的。

目录

• 误判一：以为 AI 能自动理解业务逻辑
• 项目上下文理解：如何喂给 AI “正确”的信息
• 代码修改流程：从“生成”到“审查”
• 测试与验证：AI 写测不如人写准
• 团队使用建议：建立“人机协作”规范
• 总结

误判一：以为 AI 能自动理解业务逻辑

刚开始接入时，我犯了一个典型的“过度信任”错误。我把整个 src/main/java 目录扔给了 Codex，然后让它：“重构一下这个用户服务层，提取公共方法，保持原有逻辑不变。”

我以为它会像个老练的架构师一样，先读代码，再理解依赖，最后动手。但实际上，它生成的代码确实更整洁了，但业务语义丢失了。

举个例子，原代码里有一个奇怪的 if (user.getSource() == 3)，这是三年前的一个历史遗留 bug workaround。Codex 把它当成“无意义的魔法值”给优化掉了，导致线上某个特定渠道的用户注册流程直接断裂。

教训：AI 擅长语法转换和模式匹配，但不具备“业务上下文”的记忆。在处理复杂遗留项目时，不能直接把整个仓库丢给它。你需要做的是最小化上下文注入。

实战策略：缩小攻击面

不要一次性让它改整个类。正确的做法是：

1. 明确边界：只把当前涉及的 Service 方法和相关的 DTO 给 AI。
2. 提供注释级指令：在代码上方加上详细的业务逻辑注释，告诉 AI 这段代码“为什么”这么写，而不仅仅是“怎么”写的。

/**
 * 【重要】此处判断 source=3 是为了兼容 2023 年 Q2 导入的旧数据格式。
 * 新数据 source 为 1 或 2。
 * 重构时请务必保留此逻辑，不要移除或合并到通用校验流程中。
 */
public UserDTO processLegacyUser(UserRequest req) {
    // ... 原有逻辑
}

当我加上这段注释后再让它重构，它虽然还是改了变量名，但保住了那个关键的 if 分支。这就是用文档约束 AI 行为的有效性。

项目上下文理解：如何喂给 AI “正确”的信息

Codex 这类工具的强大之处在于它能读取文件树，但它的“视野”是有限的。如果你希望它理解全局依赖，必须通过结构化提示来引导。

在团队内部推广时，我发现最头疼的不是单个方法的生成，而是跨文件的引用错误。比如 AI 改了一个 Controller 的入参，却没去改对应的 Service 实现，或者反过来。

为了解决这个问题，我在项目中建立了一套简单的 AI_Context.md 规范，放在项目根目录。每次开启新会话前，我会先让 Codex 读取这个文件。

# Project Context Guide
1. **Architecture**: Hexagonal Architecture (Ports & Adapters).
2. **Key Dependencies**:
   - Use `JdbcTemplate` for raw SQL, never `MyBatis` in new code.
   - All services must return `Result<T>`, handle exceptions via `GlobalExceptionHandler`.
3. **Naming Convention**:
   - Service Impl suffix: `ServiceImpl`
   - DTO suffix: `Request` / `Response`
4. **Forbidden**: Do not generate unit tests yet. Focus on logic correctness first.

这种做法看似繁琐，但在多人协作时非常有效。它相当于给 AI 设了一道“护栏”，防止它用错误的技术栈或命名规范生成代码。

代码修改流程：从“生成”到“审查”

在实际操作中，我调整了工作流：不再直接 Accept AI 的代码，而是将其视为“草稿”。

Codex 生成的代码通常语法正确，但往往缺乏异常处理的健壮性。特别是在网络调用和数据库事务方面，它倾向于生成最简路径。

我的审查清单

每次 AI 提交 PR 或生成文件后，我会重点检查以下几点：

1. 事务传播行为：AI 经常忽略 @Transactional 的传播级别，默认 REQUIRED 可能在嵌套调用中引发死锁或数据不一致。
2. 资源释放：虽然 Java 有 try-with-resources，但 AI 有时会忘记关闭自定义的连接池对象。
3. 日志脱敏：AI 生成的日志往往直接打印对象，可能包含敏感信息（如手机号、身份证）。

// AI 生成的常见错误示例
public void updateOrder(Order order) {
    orderRepository.save(order);
    log.info("Order updated: {}", order); // 危险！可能打印敏感字段
}

// 修正后的代码
public void updateOrder(Order order) {
    orderRepository.save(order);
    log.info("Order [{}] updated successfully", order.getId()); // 安全
}

这个过程让我意识到，AI 是初级程序员，你是 Tech Lead。你的核心价值从“写代码”转移到了“Review 代码”和“定义规范”。

测试与验证：AI 写测不如人写准

很多博主推荐用 AI 生成单元测试，但我发现效果参差不齐。Codex 生成的测试用例往往覆盖了 Happy Path，但对边界条件和异常场景的覆盖很弱。

在我的实战中，我采取的策略是：让人写测试用例的描述，让 AI 生成测试代码。

例如，我不说“写一个测试”，而是说：
> “请为 UserService.login 方法编写 JUnit 5 测试。需要覆盖以下场景：
> 1. 用户名不存在时抛出 UserNotFoundException。
> 2. 密码错误时抛出 AuthenticationException。
> 3. 正常登录返回 Token。
> 请确保 Mock 掉 passwordEncoder 和 userRepository。”

这样生成的测试代码准确度大幅提升，且逻辑清晰。验证阶段，我会手动运行这些测试，并检查覆盖率报告。如果发现某个分支没被覆盖，我会再次要求 AI 补充。

团队使用建议：建立“人机协作”规范

从个人试用走向团队协作，最大的阻力来自于代码风格的不统一和安全风险。

1. 禁止直接 Commit：所有 AI 生成的代码必须经过人工 Review 后才能合入主分支。这一点必须作为硬性规定写入团队公约。
2. 标签化管理：在 Git 提交信息中标注 [AI-Helped]，方便追溯哪些逻辑是 AI 生成的，便于后续维护和责任认定。
3. 知识库共建：将常用的 Context Guide 模板沉淀下来，新项目直接复用，减少重复配置成本。

总结

这次 Codex 实战让我明白，AI 编程助手并不是万能的“代码自动机”。它在处理标准化、模块化强的新代码时表现出色，但在面对复杂业务逻辑和历史遗留系统时，依然需要人类提供明确的指引和严格的审查。

技术负责人的角色正在发生转变：我们不再仅仅是架构的设计者，更是 AI 行为的“提示词工程师”和代码质量的“守门员”。

对于想尝试 AI 编程的团队，我的建议是：从小处着手，先在一个非核心的内部工具项目中跑通流程，积累 Context 模板和审查规范，然后再逐步推广到核心业务线。 不要指望一键重构，而要追求“人在回路”中的高效协作。

毕竟，工具再聪明，也替不了你对业务负责的那份心。

资料展示

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

如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。