Codex 实战应用

TL;DR：Codex 不只是写代码的工具——它是一个能理解上下文、执行命令、操作文件的全能技术搭档。本文从工作、编码、生活三个维度，给出 30+ 个可直接复用的实战场景和操作方式。

---

一、先搞清楚 Codex 能做什么

在讲场景之前，先对齐一个认知：Codex 不是一个聊天机器人，而是一个有手有脚的 AI Agent。

它能做的事：

能力	具体表现
读写文件	创建、编辑、删除你工作目录下的任何文件
执行命令	跑 shell 命令、启动服务、安装依赖
搜索信息	联网搜索、抓取网页、读取文档
多步推理	拆解复杂任务，逐步执行，中间可暂停确认
上下文记忆	记住当前会话的所有操作历史，跨文件关联
多格式输出	Markdown、代码、表格、图表、Word、PDF、PPT

Codex 的工作模式

和传统 AI 工具的核心区别

关键差异：Codex 的交付物是「做完的事」，不是「怎么做的建议」。

---

二、工作场景：让 Codex 成为你的效率倍增器

2.1 写邮件和商务消息

场景：你需要给合作方发一封项目延期的邮件，既要说明原因，又不能显得不专业。

操作方式：

你：帮我写一封邮件，发给合作方张总。
原因：第三方接口升级，原定周五的交付需要推迟到下周三。
语气：商务、专业、不卑不亢。
要点：1）说明原因 2）给出新时间 3）提供临时替代方案

Codex 输出：

主题：关于 XX 项目交付时间调整的说明

张总，您好：

因第三方数据接口将于本周五进行计划内升级（预计影响范围：数据同步模块），
原定于 6 月 27 日交付的版本需要调整至 7 月 1 日（周三）发布。

为降低对贵方业务的影响，我们准备了以下临时方案：
1. 升级期间，现有版本可正常运行，不受影响
2. 如需紧急数据，我们可通过手动导出方式提供支持
3. 新版本发布后，我们将第一时间安排联调验证

如对时间安排有疑问，随时沟通。

此致
[你的名字]

为什么这么写好：

• 先说结论（延期），再说原因（接口升级），最后给方案
• 提供了 3 个替代选项，让对方有选择感
• 没有过度道歉，保持了专业对等

---

2.2 写会议纪要

场景：刚开完一个需求评审会，需要整理纪要发给团队。

操作方式：

你：帮我整理会议纪要。

参会人：张三（产品）、李四（后端）、王五（前端）、赵六（测试）
讨论内容：
1. 用户导出功能：张三说要支持 Excel 和 CSV，李四说 Excel 实现成本高，
   建议先只做 CSV，王五同意。最后决定第一版只做 CSV。
2. 性能要求：赵六提出导出 10 万条数据时页面不能卡死。
   李四说改成异步导出，后台生成 + 下载链接通知。
3. 排期：李四说后端 3 天，王五说前端 2 天，赵六说测试 2 天。
   张三要求下周五前上线。

Codex 输出：

# 需求评审会议纪要

**日期**：2026-06-29
**参会人**：张三（产品）、李四（后端）、王五（前端）、赵六（测试）

## 结论

### 1. 用户导出功能
- **格式**：第一版仅支持 CSV（Excel 格式后续迭代考虑）
- **决策理由**：CSV 实现成本低，可满足核心需求，优先保证交付

### 2. 性能方案
- **方案**：采用异步导出（后台生成 → 下载链接通知）
- **目标**：支持 10 万条数据导出，不阻塞前端页面

### 3. 排期
| 阶段 | 负责人 | 工时 | 完成时间 |
|------|--------|------|---------|
| 后端开发 | 李四 | 3 天 | 7/2（周三） |
| 前端开发 | 王五 | 2 天 | 7/4（周五） |
| 测试 | 赵六 | 2 天 | 7/6（周日）→ 建议调整至 7/8（周二） |

## 待办

- [ ] [李四] 完成后端接口开发 — 7/2 前
- [ ] [王五] 完成前端页面 + 对接 — 7/4 前
- [ ] [赵六] 完成测试用例编写 + 执行 — 7/8 前
- [ ] [张三] 确认最终上线时间（排期超出原定 7/3） — 6/30 前

## 风险项

- 测试完成时间（7/8）晚于张三要求的上线时间（7/3），需产品确认是否调整

为什么这么写好：

• 只记结论和待办，不记讨论过程
• 每个待办有明确责任人和截止时间
• 主动标出了排期冲突的风险

---

2.3 数据分析与报告

场景：你有一份销售数据，需要快速出分析报告。

操作方式：

你：分析 sales_data.csv，给我出一份月度销售分析报告。
要求：
1. 找出销售额 Top 5 的产品
2. 对比上月环比变化
3. 找出异常数据（突增或突降）
4. 给管理层看的，要结论先行

Codex 会做的事：

1. 读取 CSV 文件，理解数据结构
2. 用 Python/pandas 做数据清洗和聚合
3. 计算环比、识别异常
4. 生成带图表的 Markdown 报告

输出示例：

# 6 月销售分析报告

## 核心结论

本月总销售额 ¥2,340,000，环比增长 12.3%。增长主要由产品 A 驱动（占比 38%）。
需关注产品 D 的连续两月下滑趋势。

## 一、整体概况

| 指标 | 本月 | 上月 | 环比 |
|------|------|------|------|
| 总销售额 | ¥2,340,000 | ¥2,083,000 | +12.3% |
| 订单数 | 4,521 | 4,102 | +10.2% |
| 客单价 | ¥517.6 | ¥507.8 | +1.9% |

## 二、Top 5 产品

| 排名 | 产品 | 销售额 | 占比 | 环比 |
|------|------|--------|------|------|
| 1 | 产品 A | ¥889,200 | 38.0% | +28.5% |
| 2 | 产品 B | ¥514,800 | 22.0% | +5.2% |
| 3 | 产品 C | ¥374,400 | 16.0% | -3.1% |
| 4 | 产品 D | ¥280,800 | 12.0% | -15.7% |
| 5 | 产品 E | ¥163,800 | 7.0% | +42.0% |

## 三、异常预警

- **产品 D**：连续 2 个月下滑（-15.7%），建议排查原因（竞品/质量/库存）
- **产品 E**：单月增长 42%，需确认是否为一次性大单

## 四、建议

1. 产品 A 的增长势头良好，建议加大库存备货
2. 产品 D 需要产品团队介入分析下滑原因
3. 产品 E 的增长需要验证可持续性

---

2.4 写周报 / 日报

场景：周五了，要写周报。

操作方式：

你：帮我写本周周报。

本周做的事：
1. 完成了用户中心的重构，从 Spring MVC 迁移到 Spring Boot 3
2. 修了 3 个线上 Bug：订单重复提交、缓存穿透、日志丢失
3. 做了新人 Code Review，review 了 5 个 MR
4. 参加了架构评审会，确定了消息队列从 RabbitMQ 切到 Kafka 的方案

下周计划：
1. 用户中心性能压测
2. Kafka 迁移方案详细设计
3. 准备技术分享：Spring Boot 3 升级踩坑

Codex 输出：

# 周报（6/23 - 6/29）

## 本周完成

### 1. 用户中心重构 ✅
- 完成从 Spring MVC 到 Spring Boot 3 的迁移
- 涉及模块：用户注册、登录、权限管理
- 已通过集成测试，待上线

### 2. 线上 Bug 修复 ✅
| Bug | 影响范围 | 修复方式 |
|-----|---------|---------|
| 订单重复提交 | 支付模块 | 增加幂等性校验 |
| 缓存穿透 | 商品查询 | 空值缓存 + 布隆过滤器 |
| 日志丢失 | 全链路 | 修复 Logback 异步配置 |

### 3. Code Review ✅
- Review 5 个 MR，提出 12 条改进建议

### 4. 架构决策 ✅
- 确定消息队列迁移方案：RabbitMQ → Kafka
- 决策理由：Kafka 在高吞吐和消息回溯方面更适合当前业务增长需求

## 下周计划

| 任务 | 优先级 | 预计完成 |
|------|--------|---------|
| 用户中心性能压测 | P0 | 周三 |
| Kafka 迁移详细设计 | P0 | 周五 |
| 技术分享准备 | P1 | 周五 |

## 风险 / 阻塞

- 用户中心压测需要运维配合扩容测试环境，需提前协调

---

2.5 做 PPT / 汇报材料

场景：下周要给领导做技术分享。

操作方式：

你：帮我做一个技术分享的 PPT 大纲。
主题：Spring Boot 3 升级踩坑实录
时长：30 分钟
受众：团队里的 Java 开发，大部分还在用 Spring Boot 2

Codex 输出：

# Spring Boot 3 升级踩坑实录 — PPT 大纲

## 大纲（共 12 页，预计 30 分钟）

### 第 1 页：封面（1 分钟）
- 标题 + 你的名字 + 日期

### 第 2 页：为什么要升级（2 分钟）
- Spring Boot 2 的生命周期终点（2025.11 EOL）
- Spring Framework 6 的新特性红利
- 不升级的技术债风险

### 第 3 页：升级路线图（2 分钟）
- 整体流程：评估 → 迁移 → 测试 → 灰度 → 全量
- 我们用了一个月，分三个阶段

### 第 4-6 页：三个核心踩坑（15 分钟，每个 5 分钟）
- 坑 1：javax → jakarta 命名空间迁移
  - 现象：编译全红
  - 解法：OpenRewrite 自动化 + 手动修正
  - 耗时：比预期多 3 天
- 坑 2：Spring Security 配置变化
  - 现象：所有接口 403
  - 解法：SecurityFilterChain 替代 WebSecurityConfigurerAdapter
  - 对比代码（旧 vs 新）
- 坑 3：第三方依赖兼容性
  - 现象：MyBatis-Plus、Swagger 报错
  - 解法：升级对应版本 / 替换方案

### 第 7 页：性能对比（3 分钟）
- 启动时间：45s → 12s
- 内存占用：512MB → 320MB
- QPS 压测对比图

### 第 8 页：升级 Checklist（3 分钟）
- 给想升级的团队一个可直接用的检查清单

### 第 9 页：总结与建议（2 分钟）
- 3 条核心建议
- 升级收益 > 成本，建议尽早规划

### 第 10 页：Q&A（2 分钟）

---

三、编码场景：Codex 作为你的编程搭档

3.1 项目搭建与脚手架

场景：要开一个新项目，需要快速搭建基础框架。

操作方式：

你：帮我创建一个 Spring Boot 3 项目。
要求：
- Java 17
- 用 MyBatis-Plus 做 ORM
- 集成 Redis 缓存
- 包含统一的异常处理、日志配置、接口文档（Knife4j）
- 用 Hutool 做工具类
- 项目名：order-service

Codex 会做的事：

生成的项目结构：

order-service/
├── pom.xml
├── src/main/java/com/example/order/
│   ├── OrderServiceApplication.java
│   ├── config/
│   │   ├── RedisConfig.java
│   │   └── SwaggerConfig.java
│   ├── common/
│   │   ├── Result.java
│   │   ├── GlobalExceptionHandler.java
│   │   └── BusinessException.java
│   ├── controller/
│   │   └── BaseController.java
│   └── util/
│       └── (使用 Hutool，不自建)
├── src/main/resources/
│   ├── application.yml
│   ├── application-dev.yml
│   └── logback-spring.xml
└── src/test/java/com/example/order/
    └── OrderServiceApplicationTests.java

---

3.2 代码实现：从需求到代码

场景：需要实现一个订单分页查询接口。

操作方式：

你：实现订单分页查询接口。
要求：
- GET /api/orders?pageNum=1&pageSize=10&status=PAID
- 返回分页数据，包含总数、总页数
- 用 MyBatis-Plus 的 Page
- 参数要做校验
- 写单元测试

Codex 的实现过程：

生成的核心代码：

// OrderController.java
@RestController
@RequestMapping("/api/orders")
@RequiredArgsConstructor
@Tag(name = "订单管理")
public class OrderController {

    private final OrderService orderService;

    @GetMapping
    @Operation(summary = "分页查询订单")
    public Result<PageResult<OrderVO>> listOrders(
            @Valid OrderQueryDTO query) {
        return Result.ok(orderService.pageQuery(query));
    }
}

// OrderQueryDTO.java — 参数校验
@Data
public class OrderQueryDTO {
    @Min(value = 1, message = "页码最小为 1")
    private Integer pageNum = 1;

    @Min(value = 1, message = "每页条数最小为 1")
    @Max(value = 100, message = "每页条数最大为 100")
    private Integer pageSize = 10;

    private OrderStatus status;
}

// OrderServiceImpl.java
@Service
@RequiredArgsConstructor
public class OrderServiceImpl implements OrderService {

    private final OrderMapper orderMapper;

    @Override
    public PageResult<OrderVO> pageQuery(OrderQueryDTO query) {
        Page<Order> page = new Page<>(query.getPageNum(), query.getPageSize());

        LambdaQueryWrapper<Order> wrapper = new LambdaQueryWrapper<Order>()
                .eq(query.getStatus() != null, Order::getStatus, query.getStatus())
                .orderByDesc(Order::getCreateTime);

        Page<Order> result = orderMapper.selectPage(page, wrapper);

        List<OrderVO> voList = result.getRecords().stream()
                .map(this::toVO)
                .collect(Collectors.toList());

        return PageResult.of(voList, result.getTotal(),
                result.getCurrent(), result.getSize());
    }
}

---

3.3 Bug 排查：从报错到修复

场景：线上报了一个 NPE，需要定位和修复。

操作方式：

你：线上报了个 NullPointerException，堆栈如下：

java.lang.NullPointerException: Cannot invoke "String.length()" 
  because "s" is null
  at com.example.order.service.OrderServiceImpl.buildOrderNo(OrderServiceImpl.java:87)
  at com.example.order.service.OrderServiceImpl.createOrder(OrderServiceImpl.java:42)

帮我定位原因并修复。

Codex 的排查过程：

修复代码：

// 修复前（第 87 行）
private String buildOrderNo(String prefix) {
    // prefix 为 null 时直接 NPE
    return prefix + DateUtil.format(new Date(), "yyyyMMddHHmmss") 
         + RandomUtil.randomNumbers(4);
}

// 修复后
private String buildOrderNo(String prefix) {
    String safePrefix = StrUtil.blankToDefault(prefix, "ORD");
    return safePrefix + DateUtil.format(new Date(), "yyyyMMddHHmmss") 
         + RandomUtil.randomNumbers(4);
}

自查：

• 空指针风险：已通过 StrUtil.blankToDefault 兜底
• 命名清晰：safePrefix 表达了"安全的前缀"
• 方法长度：修复后仍只有 4 行
• 风格一致：使用了项目已有的 Hutool 工具类

---

3.4 Code Review：帮你审查代码

场景：你写了一段代码，想让 Codex 帮你 review。

操作方式：

你：帮我 review 这段代码，关注：安全性、性能、可维护性。

public List<User> searchUsers(String keyword) {
    String sql = "SELECT * FROM user WHERE name LIKE '%" + keyword + "%'";
    List<User> users = jdbcTemplate.query(sql, new UserRowMapper());
    if (users == null) {
        return new ArrayList<>();
    }
    return users;
}

Codex 的 Review 结果：

## Code Review 结果

### 🔴 严重问题

#### 1. SQL 注入漏洞（P0）
**位置**：第 2 行
**问题**：直接拼接用户输入到 SQL 中
**风险**：攻击者可通过 keyword 参数注入任意 SQL

**修复**：
```java
String sql = "SELECT * FROM user WHERE name LIKE ?";
jdbcTemplate.query(sql, new Object[]{"%" + keyword + "%"}, new UserRowMapper());

或者用 MyBatis-Plus：

LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<User>()
    .like(User::getName, keyword);
return userMapper.selectList(wrapper);

🟡 改进建议

2. 冗余的 null 检查（P2）

位置：第 3-5 行
问题：Spring JdbcTemplate.query() 不会返回 null，只可能返回空列表
建议：删除 null 检查，直接返回

3. SELECT * 问题（P2）

位置：第 2 行
问题：查询了所有字段，但可能只需要部分字段
建议：明确指定需要的字段，减少网络传输和内存占用

✅ 做得好的地方

• 方法命名清晰，searchUsers 表达了意图
• 返回空列表而非 null，调用方不需要判空

---

### 3.5 数据库操作：建表、优化、迁移

**场景**：需要设计订单表结构。

**操作方式**：

你：帮我设计订单表。
业务场景：

• 用户可以下单购买商品
• 订单有状态流转：待支付 → 已支付 → 已发货 → 已完成 / 已取消
• 需要支持按用户、时间、状态查询
• 预计日增 10 万条数据
• 用 MySQL 8.0

**Codex 输出**：

```sql
CREATE TABLE `t_order` (
    `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键',
    `order_no` VARCHAR(32) NOT NULL COMMENT '订单号（业务唯一键）',
    `user_id` BIGINT NOT NULL COMMENT '用户 ID',
    `total_amount` DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT '订单总金额',
    `pay_amount` DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT '实付金额',
    `status` TINYINT NOT NULL DEFAULT 0 COMMENT '状态：0-待支付 1-已支付 2-已发货 3-已完成 4-已取消',
    `pay_time` DATETIME DEFAULT NULL COMMENT '支付时间',
    `ship_time` DATETIME DEFAULT NULL COMMENT '发货时间',
    `finish_time` DATETIME DEFAULT NULL COMMENT '完成时间',
    `remark` VARCHAR(500) DEFAULT '' COMMENT '备注',
    `is_deleted` TINYINT NOT NULL DEFAULT 0 COMMENT '逻辑删除：0-正常 1-已删除',
    `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
    PRIMARY KEY (`id`),
    UNIQUE KEY `uk_order_no` (`order_no`),
    KEY `idx_user_id` (`user_id`),
    KEY `idx_status_create_time` (`status`, `create_time`),
    KEY `idx_create_time` (`create_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表';

索引设计说明：

---

3.6 写测试：单元测试 + 集成测试

场景：给订单服务写单元测试。

操作方式：

你：给 OrderServiceImpl.pageQuery 写单元测试。
要覆盖：
1. 正常分页查询
2. 带状态筛选
3. 空结果
4. 边界值（pageNum=0, pageSize=0）

Codex 生成的测试：

@ExtendWith(MockitoExtension.class)
class OrderServiceImplTest {

    @Mock
    private OrderMapper orderMapper;

    @InjectMocks
    private OrderServiceImpl orderService;

    @Test
    @DisplayName("正常分页查询 - 返回分页数据")
    void pageQuery_normal() {
        // Given
        OrderQueryDTO query = new OrderQueryDTO();
        query.setPageNum(1);
        query.setPageSize(10);

        Page<Order> mockPage = new Page<>(1, 10);
        mockPage.setRecords(List.of(buildOrder("ORD001"), buildOrder("ORD002")));
        mockPage.setTotal(2);

        when(orderMapper.selectPage(any(Page.class), any()))
                .thenReturn(mockPage);

        // When
        PageResult<OrderVO> result = orderService.pageQuery(query);

        // Then
        assertThat(result.getTotal()).isEqualTo(2);
        assertThat(result.getList()).hasSize(2);
        assertThat(result.getList().get(0).getOrderNo()).isEqualTo("ORD001");
    }

    @Test
    @DisplayName("带状态筛选 - 只查已支付订单")
    void pageQuery_withStatus() {
        // Given
        OrderQueryDTO query = new OrderQueryDTO();
        query.setPageNum(1);
        query.setPageSize(10);
        query.setStatus(OrderStatus.PAID);

        when(orderMapper.selectPage(any(Page.class), any()))
                .thenReturn(new Page<>(1, 10));

        // When
        orderService.pageQuery(query);

        // Then - 验证查询条件包含状态筛选
        ArgumentCaptor<LambdaQueryWrapper<Order>> captor = 
                ArgumentCaptor.forClass(LambdaQueryWrapper.class);
        verify(orderMapper).selectPage(any(Page.class), captor.capture());
        // 验证 wrapper 中包含 status 条件
    }

    @Test
    @DisplayName("空结果 - 返回空列表")
    void pageQuery_empty() {
        // Given
        Page<Order> emptyPage = new Page<>(1, 10);
        emptyPage.setRecords(Collections.emptyList());
        emptyPage.setTotal(0);

        when(orderMapper.selectPage(any(Page.class), any()))
                .thenReturn(emptyPage);

        // When
        PageResult<OrderVO> result = orderService.pageQuery(new OrderQueryDTO());

        // Then
        assertThat(result.getTotal()).isZero();
        assertThat(result.getList()).isEmpty();
    }
}

---

3.7 DevOps：Docker、CI/CD、部署

场景：给项目加 Docker 支持。

操作方式：

你：给我的 Spring Boot 项目生成 Dockerfile 和 docker-compose.yml。
要求：
- 多阶段构建，最终镜像尽量小
- 支持环境变量注入配置
- 包含健康检查
- docker-compose 里加上 MySQL 和 Redis

Codex 输出：

# Dockerfile - 多阶段构建
# 阶段 1：构建
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline -B
COPY src ./src
RUN mvn package -DskipTests -B

# 阶段 2：运行
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY --from=builder /app/target/*.jar app.jar

# 健康检查
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
    CMD wget -qO- http://localhost:8080/actuator/health || exit 1

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

# docker-compose.yml
version: '3.8'

services:
  app:
    build: .
    ports:
      - "8080:8080"
    environment:
      - SPRING_DATASOURCE_URL=jdbc:mysql://mysql:3306/order_db
      - SPRING_DATASOURCE_USERNAME=root
      - SPRING_DATASOURCE_PASSWORD=${DB_PASSWORD}
      - SPRING_REDIS_HOST=redis
    depends_on:
      mysql:
        condition: service_healthy
      redis:
        condition: service_healthy

  mysql:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
      MYSQL_DATABASE: order_db
    ports:
      - "3306:3306"
    volumes:
      - mysql_data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      retries: 5

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      retries: 5

volumes:
  mysql_data:

---

四、生活场景：Codex 不只是写代码

4.1 学习新技术：当你的私人导师

场景：想学 Rust，但不知道从哪开始。

操作方式：

你：我想学 Rust，有 Java 5 年经验。
帮我制定一个学习路线，要求：
1. 利用我的 Java 经验，做对比学习
2. 每周 5 小时，预计 8 周
3. 每周有可运行的小项目
4. 标注 Java 开发者容易踩的坑

Codex 输出：

# Rust 学习路线（Java 开发者版）

## 总体思路

Java → Rust 的核心思维转变：
- 垃圾回收 → 所有权系统
- 继承 → Trait
- 异常 → Result/Option
- 运行时多态 → 编译时多态

## 8 周计划

### 第 1 周：环境 + 基础语法
**目标**：能写简单的命令行程序

| Java | Rust | 差异点 |
|------|------|--------|
| `String s = "hello";` | `let s = "hello";` | Rust 默认不可变 |
| `System.out.println(s);` | `println!("{}", s);` | 格式化语法不同 |
| `null` | `Option<T>` | Rust 没有 null |

**练习**：写一个猜数字游戏
**Java 开发者易踩坑**：
- 习惯性地想加 `new`，Rust 不需要
- 变量默认不可变，需要 `mut`

### 第 2 周：所有权 + 借用
**目标**：理解 Rust 最核心的概念

**核心对比**：

Java: GC 自动管理内存，你不用想
Rust: 编译期通过所有权系统保证内存安全，零成本

**练习**：实现一个简单的链表
**易踩坑**：
- 移动语义：`let b = a;` 之后 `a` 就不能用了
- 借用规则：不能同时有可变引用和不可变引用

### 第 3 周：结构体 + 枚举 + 模式匹配
...

### 第 4 周：Trait（对应 Java 的 Interface）
...

### 第 5 周：错误处理 + 泛型
...

### 第 6 周：并发（对应 Java 的线程池）
...

### 第 7 周：异步编程（tokio）
...

### 第 8 周：综合项目 — 写一个 REST API
...

---

4.2 个人项目管理：装修、旅行、搬家

场景：准备装修房子，需要管理整个流程。

操作方式：

你：帮我做一个装修项目管理方案。
房子：90 平，两室一厅，毛坯
预算：20 万
时间：希望 3 个月内完工
要求：
1. 列出所有步骤和顺序
2. 每步预估费用
3. 标注哪些可以并行
4. 给出注意事项和常见坑

Codex 输出：

# 装修项目管理方案

## 总览

```mermaid
gantt
    title 装修进度（12 周）
    dateFormat  YYYY-MM-DD
    section 前期
    设计定稿          :a1, 2026-07-01, 7d
    预算确认          :a2, 2026-07-01, 5d
    section 硬装
    拆改              :b1, after a1, 5d
    水电              :b2, after b1, 10d
    防水              :b3, after b2, 3d
    瓦工（瓷砖）       :b4, after b3, 10d
    木工              :b5, after b2, 7d
    油漆              :b6, after b5, 10d
    section 安装
    厨卫吊顶           :c1, after b6, 3d
    地板安装           :c2, after b6, 2d
    门/柜安装          :c3, after c2, 5d
    开关/灯具/洁具     :c4, after c3, 3d
    section 收尾
    开荒保洁           :d1, after c4, 2d
    家具进场           :d2, after d1, 3d
    通风散味           :d3, after d2, 14d

预算分配（总计 20 万）

项目	预算	占比	备注
硬装（施工+材料）	¥80,000	40%	水电、瓦工、油漆等
主材	¥40,000	20%	瓷砖、地板、门、橱柜
厨卫	¥25,000	12.5%	烟灶、卫浴、吊顶
家具	¥30,000	15%	沙发、床、餐桌
家电	¥15,000	7.5%	空调、洗衣机、冰箱
预留	¥10,000	5%	应对超支

关键注意事项

⚠️ 水电阶段

• 必须现场盯工，拍照记录管线走向
• 插座宁多勿少，特别是厨房台面和床头
• 卫生间必须做等电位连接（安全）

⚠️ 防水阶段

• 卫生间防水至少刷两遍，做 48 小时闭水试验
• 阳台如果有水龙头，也要做防水

⚠️ 常见坑

• 装修公司报价漏项，后期加钱 → 签约前逐项核对
• 定制柜子周期长（30-45 天），要提前下单
• 美缝不要省，填缝剂半年就发黑

---

### 4.3 健康管理：运动计划、饮食记录

**场景**：想开始跑步，但是零基础。

**操作方式**：

你：帮我制定一个跑步训练计划。
现状：

• 30 岁，男，久坐办公，零基础
• 体重 80kg，目标减到 72kg
• 膝盖没有伤，但担心受伤
• 每周能跑 3-4 次，每次 30-45 分钟
• 目标是 3 个月后能跑 10 公里

**Codex 输出**：

```markdown
# 零基础跑步训练计划（12 周 → 10km）

## 训练原则

1. **循序渐进**：每周跑量增幅不超过 10%
2. **跑走结合**：前 4 周不要追求纯跑步
3. **休息日必须休息**：恢复也是训练
4. **心率优先**：前 8 周保持有氧心率区间（130-150 bpm）

## 12 周计划

### 第 1-2 周：建立习惯

| 日 | 训练内容 | 时长 |
|----|---------|------|
| 周一 | 快走 5 分钟 + 跑 1 分钟 × 8 组 + 快走 5 分钟 | 30 min |
| 周三 | 同上 | 30 min |
| 周五 | 快走 5 分钟 + 跑 2 分钟 × 6 组 + 快走 5 分钟 | 30 min |
| 周日 | 休息或散步 | - |

### 第 3-4 周：增加跑步比例

| 日 | 训练内容 | 时长 |
|----|---------|------|
| 周一 | 快走 3 分钟 + 跑 3 分钟 × 6 组 | 30 min |
| 周三 | 快走 3 分钟 + 跑 4 分钟 × 5 组 | 35 min |
| 周五 | 快走 3 分钟 + 跑 5 分钟 × 4 组 | 35 min |
| 周日 | 快走 40 分钟（轻松恢复） | 40 min |

### 第 5-8 周：纯跑步过渡

| 周 | 周一 | 周三 | 周五 | 周日 |
|----|------|------|------|------|
| 5 | 跑 3km | 跑 3km | 跑 2km（轻松） | 休息 |
| 6 | 跑 3.5km | 跑 3km | 跑 2km | 休息 |
| 7 | 跑 4km | 跑 3.5km | 跑 2.5km | 休息 |
| 8 | 跑 5km | 跑 4km | 跑 3km | 休息 |

### 第 9-12 周：冲刺 10km

| 周 | 周一 | 周三 | 周五 | 周日（长距离） |
|----|------|------|------|---------------|
| 9 | 跑 5km | 跑 4km | 跑 3km | 跑 7km |
| 10 | 跑 5km | 跑 4km | 休息 | 跑 8km |
| 11 | 跑 6km | 跑 5km | 休息 | 跑 9km |
| 12 | 跑 5km（轻松） | 跑 3km（轻松） | 休息 | **🎯 10km 目标** |

## 受伤预防

| 部位 | 常见伤 | 预防方法 |
|------|--------|---------|
| 膝盖 | 跑步膝 | 加强股四头肌力量（靠墙静蹲） |
| 脚踝 | 扭伤 | 跑前活动脚踝，选平整路面 |
| 小腿 | 胫骨疼痛 | 控制跑量增幅，选好跑鞋 |
| 足底 | 足底筋膜炎 | 跑后拉伸小腿，踩网球按摩 |

## 装备建议（入门级）

| 装备 | 预算 | 推荐 |
|------|------|------|
| 跑鞋 | ¥300-500 | 亚瑟士 GEL-CUMULUS / 耐克 Pegasus |
| 运动手表 | ¥500-1000 | 佳明 Forerunner 55 / 华为 GT4 |
| 速干衣 | ¥100-200 | 迪卡侬即可 |

---

4.4 理财规划：记账分析、预算制定

场景：想分析一下自己的消费情况。

操作方式：

你：这是我的本月消费记录（CSV 格式），帮我分析一下。
要求：
1. 按类别统计
2. 找出消费异常项
3. 和上月对比
4. 给出优化建议

Codex 会做的事：

1. 读取 CSV，自动识别消费类别
2. 用 Python 做聚合分析
3. 生成可视化图表
4. 给出可操作的优化建议

---

4.5 旅行规划：行程、预算、清单

场景：计划一次旅行。

操作方式：

你：帮我规划一次日本关西 5 日游。
人数：2 人
时间：10 月中旬
预算：每人 8000 元（不含机票）
偏好：美食 > 文化 > 购物
住宿：中等水平，干净方便

Codex 输出：

# 关西 5 日游行程

## 行程总览

| 日期 | 城市 | 主题 | 核心景点 |
|------|------|------|---------|
| Day 1 | 大阪 | 美食 | 道顿堀、黑门市场、心斋桥 |
| Day 2 | 京都 | 文化 | 伏见稻荷、清水寺、祇园 |
| Day 3 | 京都 | 文化 | 岚山竹林、金阁寺、锦市场 |
| Day 4 | 奈良 + 大阪 | 文化 + 美食 | 奈良公园、东大寺、梅田蓝天大厦 |
| Day 5 | 大阪 | 购物 | 临空 Outlet、难波 |

## 预算明细（2 人合计）

| 项目 | 预算 | 说明 |
|------|------|------|
| 住宿 | ¥4,000 | 4 晚 × ¥500/晚（含税）× 2 间 |
| 交通 | ¥2,000 | ICOCA 卡 + 奈良 JR |
| 餐饮 | ¥6,000 | 5 天 × ¥600/天/人 × 2 |
| 门票 | ¥1,200 | 金阁寺、蓝天大厦等 |
| 购物 | ¥2,800 | 弹性预算 |
| **合计** | **¥16,000** | 人均 ¥8,000 |

## 美食推荐

| 餐次 | 推荐 | 预算/人 |
|------|------|---------|
| Day1 午餐 | 黑门市场海鲜 | ¥150 |
| Day1 晚餐 | 蟹道乐（道顿堀） | ¥300 |
| Day2 午餐 | 清水寺附近豆腐料理 | ¥80 |
| Day2 晚餐 | 祇园怀石料理 | ¥400 |
| Day3 午餐 | 岚山豆腐料理 | ¥80 |
| Day3 晚餐 | 锦市场小吃 | ¥100 |
| Day4 午餐 | 奈良柿叶寿司 | ¥60 |
| Day4 晚餐 | 大阪烧（千房） | ¥100 |
| Day5 午餐 | 拉面（一风堂） | ¥60 |

## 出行准备清单

- [ ] 护照（有效期 > 6 个月）
- [ ] 日本签证
- [ ] ICOCA 交通卡（到机场买）
- [ ] 随身 WiFi / eSIM
- [ ] 日元现金（建议 3 万日元备用）
- [ ] 转换插头（日本是双扁插）
- [ ] 舒适走路鞋（日均 2 万步）

---

五、高效使用 Codex 的 10 条原则

原则 1：说清楚你要什么

原则 2：给上下文，不给孤立问题

❌ "这段代码怎么优化？"
✅ "这段代码在订单查询接口里，QPS 约 500，目前 P99 延迟 200ms，目标是降到 50ms 以下"

原则 3：分步给大任务，不要一次甩一堆

原则 4：让 Codex 先读代码再改

❌ "在 UserService 里加个方法"
✅ "先读 UserService.java，理解现有代码风格，然后在合适的位置加一个根据手机号查询用户的方法"

原则 5：要求验证结果

❌ "帮我改这段代码"
✅ "帮我改这段代码，改完跑一下测试，确认没有 break"

原则 6：善用对比和方案选择

"我需要实现分布式锁，对比一下 Redis 方案和 Zookeeper 方案的优劣，
结合我们的场景（3 台服务、QPS 1000、对一致性要求高）给出推荐"

原则 7：让 Codex 做 Review

"帮我 review 这个 PR，关注：安全性、性能、代码风格、是否有遗漏的边界条件"

原则 8：用 Codex 学新东西

"解释一下 Java 的虚拟线程（Virtual Threads），和传统线程的区别是什么，
什么场景下该用，给个代码示例"

原则 9：让 Codex 帮你写文档

"根据这段代码，生成 API 文档，格式：路径、方法、参数、返回值、调用示例"

原则 10：复杂任务用文件规划

"这个任务比较复杂，先帮我做一个任务计划文件，列出所有步骤，
我确认后再逐步执行"

---

六、常见误区与避坑指南

误区 1：把 Codex 当搜索引擎用

错误用法	正确用法
“Java 怎么创建线程？”	“帮我实现一个线程池，核心线程 5，最大线程 20，队列容量 100，拒绝策略用 CallerRunsPolicy”
“MySQL 索引原理”	“分析这条慢 SQL，给出索引优化建议：SELECT * FROM orders WHERE user_id = ? AND status = ? ORDER BY create_time DESC LIMIT 20”

核心区别：Codex 的价值在于「执行」，不在于「回答」。

误区 2：不看 Codex 的输出

Codex 生成的代码不是 100% 正确的。你需要：

• 检查业务逻辑是否符合需求
• 确认没有引入不存在的 API
• 验证边界条件是否覆盖
• 跑测试确认行为正确

误区 3：一次给太大的任务

误区 4：不给项目上下文

❌ "帮我写个工具类"
✅ "帮我写个工具类，项目用的是 Hutool 5.8，Java 17，Spring Boot 3，
    先看看项目里已有的工具类风格，保持一致"

误区 5：忽略 Codex 的自查能力

❌ 拿到代码就用
✅ "改完之后自查一遍：有没有空指针风险？SQL 注入风险？异常是否都处理了？"

---

七、进阶玩法

7.1 多轮对话：迭代式开发

7.2 跨文件操作

你：帮我把项目里所有的 System.out.println 替换成 log.info，
    同时确保每个类都有 @Slf4j 注解。

Codex 会：

1. 搜索所有包含 System.out.println 的文件
2. 逐个替换为 log.info
3. 检查每个文件是否有 @Slf4j，没有就加上
4. 检查是否有 import lombok.extern.slf4j.Slf4j

7.3 生成完整文档体系

你：根据这个项目的代码，生成以下文档：
1. README.md（项目介绍、快速开始、目录结构）
2. API 文档（所有 Controller 的接口）
3. 数据库设计文档（所有表结构 + ER 图）
4. 部署文档（本地开发 + Docker 部署）

7.4 代码重构

你：这个 Service 类有 800 行，帮我重构。
要求：
1. 按职责拆分（查询、写入、通知）
2. 提取公共方法
3. 保持对外接口不变
4. 重构完跑测试确认没有 break

---

八、总结

Codex 的核心价值

一句话总结

Codex 是一个能执行的技术搭档，不是一个只会回答的聊天机器人。用好它的关键是：说清楚需求、给足上下文、分步执行、验证结果。

下一步

1. 打开 Codex，从最简单的任务开始（写个工具类、改个 Bug）
2. 逐步尝试复杂场景（项目搭建、代码重构）
3. 把生活中的琐事也交给它（邮件、计划、分析）
4. 积累经验后，形成自己的 Prompt 模板库

---

文档版本：v1.0
最后更新：2026-06-29
适用版本：Codex Desktop