一份能执行的任务单，要让 Codex 知道最后交什么、去哪里找材料、哪些地方不能动，以及完成后怎样证明结果可用。内容不用很长，缺少任何一项关键约束时，先补事实比堆更多形容词有效。
本文内容核对到 2026 年 8 月。Codex 的入口和命令可能调整，任务写法仍应围绕可观察的结果展开。
从可见结果开始写
“优化登录页”没有说明读者最终会看到什么。可以改成“修复登录页在 375 像素宽度下按钮被遮挡的问题，保留现有交互和文案”。这句话给出了行为、页面和约束，Codex 可以据此查找代码，也能在相同宽度复查。
官方提示文档建议说明目标、上下文、输出和边界。写代码任务时，还应补上验证办法。框架名称、目标浏览器或兼容版本只有会改变方案时才写，不用把整个项目介绍复制进来。
把可靠线索放在附近
知道文件路径就直接提供。问题能够复现时，写出从启动命令到错误出现的最短步骤。日志里保留第一段有效错误和退出状态，截图则指出需要查看的区域。若只是怀疑某个文件，用“可能相关”表达，别把猜测写成结论。
项目已有 AGENTS.md、贡献说明或测试脚本时，让 Codex 先读取这些文件。它们能提供仓库约定，临时任务单负责本次工作独有的要求。
边界只写会防止真实问题的内容
边界可以限制文件、行为或外部影响。支付接口不能改变，请明确保留 API 形状。任务只允许本地修改，就写明不要推送和部署。涉及消息、发布或数据库写入时，要求先准备草稿或方案，得到确认后再执行。
约束互相冲突会让任务停住。例如要求“完全不改结构”又要求删除一个公共参数，Codex 无法同时满足。发送前读一遍，确认每条边界都服务同一个结果。
分开必做项和可选改进
任务里常会夹带“顺便整理一下”这类要求。把必须完成的结果放在前面，可选改进写成完成主任务以后才能评估的事项。这样测试失败或时间不足时，Codex 知道先保住哪一部分。
可选项也要给停止条件。可以要求只报告发现，暂不修改。若它预计会新增依赖、扩大文件范围或改变公开接口，应先说明影响并等待决定。
验收条件要能由别人重复
“看起来正常”很难交接。写出需要运行的测试、要打开的路由或应保持不变的相邻行为。界面改动可以要求桌面和手机宽度各检查一次，错误修复应重跑原复现步骤。暂时没有自动测试时，列出人工核对动作和预期现象。
一份简短任务单可以按下面的顺序写。
目标
修复设置页保存后刷新会丢失开关状态的问题
线索
复现步骤和相关页面路径
边界
保留现有 API 形状，不处理无关样式
验收
补充回归测试，重跑原复现步骤并报告结果
发送后先看它怎样理解
高风险或跨多个模块的任务，可以先让 Codex 复述目标、计划读取的文件和验证方法。方向正确再实施。小而可撤回的任务可以直接执行，完成后仍要对照原任务单逐项检查。
需求中包含当前价格、产品能力或外部规则时，要求使用最新官方来源并保留链接。无法联网或来源不足就停止写死结论。这个边界能避免代码做对了，依赖的业务事实却已经过期。
