任务设计

任务设计决定 Codex 的工作质量。一个好任务会同时说明目标、上下文、范围、约束、验证方式和最终交付。对半桶水学习者来说，这一节的重点不是写“高级 prompt”，而是把自己脑子里那团模糊的需求，整理成 Codex 能执行、你能验收的工作单。

这节解决什么

很多失败任务不是因为 Codex 不会做，而是因为任务本身太散：

• “帮我优化一下”没有说明优化到什么程度。
• “整理资料”没有说明资料来源、输出格式和判断标准。
• “改一下代码”没有说明哪些地方不能碰、怎么验证是否改对。

这一节帮你建立一张任务卡：让 Codex 知道要做什么，也让你知道最后怎么判断结果能不能用。

适合谁

• 第一次发现 Codex 结果“看起来很努力，但不是我要的”的学习者。
• 经常处理资料整理、文案初稿、PPT、表格、网页和项目文件的人。
• 想把一次成功经验沉淀成团队模板、个人 Skill 或 AGENTS.md 规则的人。

工作流卡

项目	你要写清楚什么	不写清楚的风险
输入	文件、链接、背景、参考样例	Codex 只能猜你的材料在哪里
过程	先分析、再修改、还是直接产出	任务顺序混乱，容易返工
输出	文档、表格、清单、代码、截图或复盘	结果形式和你的交付场景不匹配
验收	命令、人工检查点、对照标准	看起来完成了，但不知道能不能交付

任务六要素

要素	写法	示例
目标	一句话说明结果	修复登录页刷新后状态丢失的问题
背景	给出现象和上下文	用户刷新页面后需要重新登录
范围	限定文件或模块	只修改 auth 模块和相关测试
约束	写明禁止事项	不改数据库 schema，不引入新依赖
验证	给出命令或检查方式	pnpm test auth
交付	要求复盘格式	总结根因、改动、测试和风险

你可以把六要素当成“给同事派活”的基本礼貌：不是把所有细节一次说完，而是把对方不能猜的部分说清楚。

从模糊到清晰

模糊写法：

帮我优化登录逻辑。

清晰写法：

请修复登录页刷新后状态丢失的问题。

背景：
- 用户登录后刷新页面，会回到未登录状态。
- 期望刷新后仍能恢复已登录状态。

范围：
- 优先检查 `src/auth` 和相关测试。
- 不改数据库和后端接口。

验证：
- 运行 `pnpm test auth`。
- 如果需要新增测试，请覆盖刷新恢复状态的场景。

交付：
- 说明根因、改动文件、验证结果和剩余风险。

半桶水式写法

如果你一开始写不出完整任务，就先写“我要得到什么结果”和“我怎么判断它能用”。这两句先立住，Codex 才不容易跑偏。

大任务拆分

大任务建议拆成三步：

1. 只读分析：让 Codex 找影响面。
2. 方案确认：让 Codex 给出切分和验证方式。
3. 分步实施：每次只做一个可验证改动。

模板：

请先不要修改代码。阅读 [模块/目录]，分析 [目标] 会影响哪些文件、接口和测试。请输出：
1. 影响面
2. 推荐实施步骤
3. 每一步的验证方式
4. 第一阶段最小改动建议

让 Codex 主动暴露不确定性

可以加上：

如果你需要推测，请明确标注“推测”。如果官方文档、代码和测试之间有冲突，请先停下来说明冲突。

这句话适合文档更新、版本升级、依赖迁移和跨模块改动。

你要重点检查什么

• Codex 是否先理解材料，再开始产出或修改。
• 它有没有明确说明自己读了哪些文件、用了哪些依据。
• 它有没有把不确定的部分标出来，而不是直接编一个答案。
• 它有没有给出验证方法，例如构建、测试、截图、人工核对清单。
• 它有没有越过你设置的边界，例如改了无关文件、调用了不该用的外部服务。

验收标准

完成这一节后，你应该能做到：

• 把一句模糊需求改写成包含目标、背景、范围、约束、验证和交付的任务。
• 面对一个大任务时，先让 Codex 做影响面分析，而不是直接开改。
• 在结果出来后，用验收标准判断“能不能交付”，而不是只看回答是否顺眼。
• 把一个高频任务保存成下次可复用的任务模板。

复用模板

请帮我完成：[一句话目标]

背景：
- [为什么要做这件事]
- [当前材料、现象或问题]

输入材料：
- [文件/链接/目录/参考样例]

范围：
- 优先处理：[允许处理的内容]
- 不要处理：[明确禁止的内容]

执行方式：
- 请先简要说明你的理解和计划。
- 如果发现信息不足，请先提问或标注假设。
- 修改前说明会影响哪些文件或结果。

验收：
- [命令、截图、人工检查点或结果标准]

交付：
- 请总结：做了什么、依据是什么、如何验证、还有哪些风险。

风险边界

任务设计不能替代人的判断。涉及客户隐私、账号密钥、医疗法律金融建议、生产环境操作和不可逆删除时，要把边界写得更具体，并要求 Codex 在执行前停下来确认。