在与 Codex 协作的工程实践中，任务设计 (Task Design) 的质量直接决定了 AI 的交付成果。一个定义清晰的任务能够显著降低 AI 的推理偏差，减少返工次数，并确保改动符合项目的架构约束。
任务设计的六大核心要素
为了确保 Codex 能够精准执行任务，您的指令应当涵盖以下六个关键维度：
| 核心要素 | 描述要点 | 实战示例 |
| :--- | :--- | :--- |
| 明确目标 (Goal) | 用简练的语言描述最终期望达到的状态。 | “修复登录页在页面刷新后 Token 状态丢失的问题。” |
| 上下文背景 (Context) | 提供当前问题的现象、触发路径或相关业务逻辑。 | “用户成功登录后手动刷新浏览器，Vuex 状态被重置，导致非预期退出。” |
| 执行范围 (Scope) | 严格限定 AI 允许读取或修改的文件与模块。 | “仅允许修改 src/auth 目录下的逻辑，严禁触碰路由配置文件。” |
| 技术约束 (Constraints) | 写明禁止执行的操作或必须遵守的架构规范。 | “禁止修改现有的数据库 Schema，不得引入任何第三方加密库。” |
| 验证方式 (Verification) | 明确告知 AI 任务完成后应运行的检查命令。 | “执行 pnpm test auth 并确保所有单元测试通过。” |
| 交付格式 (Deliverables) | 规定 AI 在任务结束时的汇报模板。 | “请按‘根因分析、修改点摘要、验证结果、潜在风险’的格式汇报。” |
从“模糊指令”到“工程级任务描述”
案例对比：优化登录逻辑
❌ 模糊写法（低效）：
> “帮我优化一下登录逻辑，现在刷新会出问题。”
*缺陷：未定义问题根因，未限制修改范围，AI 可能会在大范围内进行盲目尝试。*
✅ 清晰写法（专业）：
> “请修复登录页面在浏览器刷新后状态丢失的 Bug。
>
> 背景说明：
> * 现象：用户登录后刷新页面，鉴权状态未从 localStorage 恢复，导致自动跳转至登录页。
> * 期望：刷新后应优先尝试从本地持久化存储恢复状态。
>
> 执行范围与约束：
> * 重点排查 src/store/modules/auth.ts 及其关联的拦截器。
> * 禁止修改后端接口协议及 API 定义。
>
> 验收要求：
> * 运行 npm run test:unit -- auth 验证逻辑正确性。
> * 手动检查改动是否引入了冗余的日志打印。
>
> 交付要求：
> * 说明状态丢失的具体原因、修改的文件清单及验证结论。”
大规模任务的拆解策略：分阶段演进
对于复杂的业务需求，建议遵循“分析 -> 方案 -> 实施”的三步走策略，避免 AI 在大规模改动中失控。
- 第一阶段：只读影响面分析
要求 AI 先不修改代码，仅输出受影响的文件清单和潜在风险点。
2. 第二阶段：方案评审与分步规划
要求 AI 给出具体的修改计划，并为每一步设定独立的验证节点。
3. 第三阶段：原子化实施
每次仅下达一个微小的、可验证的子任务，直到最终闭环。
实战模板推荐：
> “请先不要修改任何文件。请阅读 [目录/模块]，分析实现 [功能目标] 的可行性。请输出：
> 1. 受影响的文件与接口清单。
> 2. 推荐的实施步骤（按优先级排序）。
> 3. 每一步对应的验证命令。
> 4. 当前是否存在技术阻碍或风险。”
主动控制：引导 AI 暴露不确定性
在处理文档缺失或依赖过时的项目时，建议在指令末尾加入以下“熔断机制”：
> “在执行过程中，如果遇到官方文档与实际代码逻辑冲突的情况，或者需要基于推测进行修改时，请立即停止操作并向我说明冲突点，待我确认后再继续。”
这种做法能有效防止 AI 在不确定的情况下进行“暴力尝试”，确保每一步改动都建立在真实的工程事实之上。
下一篇推荐：任务验收与验证 —— 学习如何驱动 AI 高效完成任务并确保高质量交付。