任务设计

为什么要学这个？

同样一个需求，不同的描述方式，Codex 给你的结果天差地别。

说清楚了，一次搞定。说不清楚，来回改十遍。

好任务的五个要素

记住这五条，每次给 Codex 派活都过一遍：

1. 目标：你想干啥

别含糊。

❌ "帮我搞一下那个页面"
✅ "帮我创建一个登录页面，包含用户名和密码输入框，一个登录按钮"

2. 范围：改哪些文件

告诉它该碰什么，不该碰什么。

❌ "优化一下项目"
✅ "只修改 src/views/Login.vue，不要动其他文件"

3. 上下文：背景信息

Codex 不知道你的项目历史，你得告诉它。

这是一个 Spring Boot 项目，用 MyBatis-Plus 做 ORM。
数据库是 MySQL，表名叫 user。
实体类在 com.example.entity.User。

4. 禁止事项：别干啥

防止它自作主张。

不要修改数据库表结构。
不要引入新的依赖。
不要改 pom.xml。

5. 验收标准：怎么算完成

让它知道什么时候算干完了。

完成后跑一下 mvn test，确保测试都通过。
最后告诉我改了哪些文件。

一个完整的任务描述模板

## 目标
在 src/main/java/com/example/controller/ 下创建 UserController，
提供用户的增删改查 REST API。

## 范围
- 只在 controller 包下新建文件
- 不要修改现有的 Service 和 Mapper

## 上下文
- 项目用 Spring Boot 3.x + MyBatis-Plus
- 实体类：com.example.entity.User（有 id, name, email 字段）
- Service：com.example.service.UserService（已有 CRUD 方法）
- 统一返回类：com.example.common.Result

## 禁止事项
- 不引入新依赖
- 不修改数据库
- 不改已有代码

## 验收标准
- 代码能编译通过
- 遵循项目现有代码风格
- 每个接口返回 Result 包装

常见错误

错误	后果	正确做法
太模糊	Codex 猜你要啥，结果不对	写具体
太啰嗦	重要信息淹没在废话里	突出重点
不给上下文	Codex 用默认假设，可能不符合你的项目	给必要的背景
不设边界	Codex 可能改不该改的文件	明确禁止事项

我的经验

过来人的话

写任务描述就像给新同事派活。你不会跟新同事说"帮我搞一下那个东西"，你会说清楚要做什么、在哪做、别碰什么、做完告诉我。

对 Codex 也一样。

下一步

学会描述任务了，接下来 验证结果和执行闭环。