切换主题
Codex 任务设计方法论
来源：CodexGuide - 任务设计 (https://codexguide.ai/practice/task-design.html)
任务设计决定 Codex 的工作质量。一个好的任务会同时说明目标、上下文、范围、约束、验证方式和最终交付。
任务六要素
- 目标：一句话说明结果。示例：修复登录页刷新后状态丢失的问题
- 背景：给出现象和上下文。示例：用户登录后刷新页面，会回到未登录状态
- 范围：限定文件或模块。示例：只修改 src/auth 模块和相关测试
- 约束：写明禁止事项。示例：不改数据库 schema，不引入新依赖
- 验证：给出命令或检查方式。示例：pnpm test auth
- 交付：要求复盘格式。示例：总结根因、改动、测试和风险
从模糊到清晰
模糊写法：帮我优化登录逻辑。
清晰写法：
请修复登录页刷新后状态丢失的问题。
背景：
- 用户登录后刷新页面，会回到未登录状态。
- 期望刷新后仍能恢复已登录状态。
范围：
- 优先检查 src/auth 和相关测试。
- 不改数据库和后端接口。
验证：
- 运行 pnpm test auth。
- 如果需要新增测试，请覆盖刷新恢复状态的场景。
交付：
- 说明根因、改动文件、验证结果和剩余风险。
大任务拆分
大任务建议拆成三步：
- 只读分析：让 Codex 找影响面。
- 方案确认：让 Codex 给出切分和验证方式。
- 分步实施：每次只做一个可验证改动。
模板：
请先不要修改代码。阅读 [模块/目录]，分析 [目标] 会影响哪些文件、接口和测试。请输出：
- 影响面
- 推荐实施步骤
- 每一步的验证方式
- 第一阶段最小改动建议
让 Codex 主动暴露不确定性
可以在任务末尾加上：
如果你需要推测，请明确标注"推测"。如果官方文档、代码和测试之间有冲突，请先停下来说明冲突。
这句话适合文档更新、版本升级、依赖迁移和跨模块改动。
实践要点
- 越具体越好。"运行测试：pnpm test" 比"记得测试"有用。
- 把生成目录、构建产物、锁文件策略写清楚。
- 如果是 monorepo，请说明每个包的边界。
- 对安全敏感项目，单独写"禁止事项"。
📎 📒 返回笔记索引