给 Codex 下任务怎么写？让目标、边界和验收都可检查 - AIPlan

一条能少返工的任务描述有 4 段：要解决什么、能改哪些文件、不能做什么、怎么判断做完。缺第 1 段它不知道往哪走，缺第 2、3 段它会扩散，缺第 4 段你得自己找证据。截至 2026 年 10 月 18 日核对，这 4 段在 Codex 各入口上通用。 第 1 段：问题，不是方案 写“给订单接口加缓存”是方案，写“订单列表接口 P95 是 2.1 秒，主要耗时在 3 次重复查询”是问题。方案会挡住更好的选择，问题不会。 对比一下： 写法 会得到什么 优化一下性能 8 条随机建议 加 Redis 缓存 会加缓存，但可能不该加 订单列表 P95 2.1 秒，日志显示 3 次重复查询 定位 + 针对性修复 第三种需要你多花 3 分钟看日志，换来的是它第一轮就在对的方向上。 第 2 段：范围要指名文件 “改用户模块”不够具体。要么写路径： 允许修改：internal/user/application/service.go, internal/user/transport/handler.go 要么写规则： 只改 internal/user/ 下的文件，不改数据库 schema，不改路由注册。 两者可以一起用。规则的用处是在你也不确定具体文件时给一个边界，模型的遵守度比模糊描述高很多。 范围外必须改的时候怎么办？加一句“如果需要超出范围，先停下来说明原因”。这句在实际使用里很有效，模型会在越界前给一次提示，你就获得了判断机会。 第 3 段：禁止项写得越具体越好 “注意代码质量”这种话没有约束力。有效的禁止项长这样： 不要： - 新增第三方依赖 - 改函数签名 - 改测试文件来让代码通过 - 格式化无关的文件 - 保留旧的实现作为兼容层 每条都对应一个具体的失败模式。第 3 条尤其重要，改测试让代码通过是最隐蔽的失控形式：测试全绿，行为已经变了。 禁止项超过 8 条时，挑最关键的 5 条，其余删掉。太长的清单模型会挑着执行，不如短而硬。 第 4 段：验收要能被命令验证 完成标准： - go test ./internal/user/... 全部通过 - go vet ./... 无输出 - gofmt -l 无输出 - 手工调用 GET /api/v1/users?page=2 返回 200 且 total 正确 前 3 条是命令，第 4 条是手工。有命令的部分让 Codex 自己跑，跑完把输出贴给你。没有命令的部分你亲自验。 官方在快速上手文档里建议在任务前后创建 Git 检查点，验收失败的退路就是这个检查点。 三类任务的可复用模板 修 bug： 现象：[报错原文] 复现：[步骤，3 步以内] 期望：[应该发生什么] 范围：只改 [文件路径] 约束：不改测试，不改函数签名 验收：复现路径通过，相邻正常路径仍通过 加功能： 需要：[一句话说清用户能做什么] 入口：[哪个页面或接口触发] 数据：[新增哪些字段，是否要迁移] 范围：[允许改的目录] 约束：不新增依赖，不改已有接口返回结构 验收：[给 3 条可执行的检查] 整理代码： 重复：[哪 3 处实现重复，给出路径和行号] 目标：合并成 1 处，行为不变 范围：[这些文件] 约束：不保留兼容层，删掉旧函数 验收：现有测试全通过，旧函数名在仓库中搜不到 三个模板的共同点：都有范围、都有约束、都有可验证的完成信号。 一条任务一个目标 把“修登录 bug 顺便把日志格式统一一下”拆成两条任务。合并的代价是验收标准混在一起：登录修好了但日志没改完，你不确定这条任务算不算完成。 拆开还有个好处：第二条任务可以在第一条的检查点之后做，出问题能单独回退。 多步骤的任务用编号写清楚，让它在每步结束后停一下等你确认。官方桌面版支持在任务中途跟进、改方向，利用这个能力比一次给完整长指令更可控。 上下文给多少合适 给太少它会猜，给太多它会被噪声带偏。判断标准：这段信息删掉之后，任务还能不能做对。 值得给：报错原文、相关文件路径、已有约定（比如“这个项目用 pnpm 10.34.3”）、验收命令。 不值得给：整个 node_modules 的目录树、3 天前的聊天记录、跟本次无关的模块说明。 长任务里有一个技巧：让它先把理解复述一遍再动手。开头加一句“先用 5 行说明你打算怎么改，等我确认”。5 行复述里如果方向就错了，你省下的是整轮返工。 需求本身不清楚时先别下任务 任务描述写得再好，需求错了也没用。产品需求怎么拆到可执行粒度，可以看 给 ChatGPT 写需求文档的可用结构。 判断标准简单：你能不能自己写出验收的第 4 段。写不出来，说明需求还没想清楚，这时候让模型动手只是把你的模糊变成代码。 一个 5 分钟就能试的改动 拿你今天手上的一个小任务，按 4 段重写一遍，看第一次输出的差异范围。如果 git diff 里只有你预期的文件，说明描述够清楚；如果多了 2 个文件，回去补第 3 段。 修 bug 场景的完整流程在 用 Codex 修 bug：先验证原因，再动实现，那篇里的四行复现格式可以直接挪到第 1 段。重构场景用第 2、3 段就够了，把旧名字搜干净比写多少条约束都有用。 Plus 的 $20 按 1 美元 ≈ 6.69 元折算约 ¥133.80，覆盖 CLI、桌面版、IDE 扩展和 iOS 四个入口。如果你一周只跑几次任务，¥115.50 的菲区官充 Plus 月卡 是同样的能力和额度，只是付款渠道不同。额度真正吃紧的是长上下文任务，那时候再看怎么拆分更划算。 写完任务描述后回头读一遍，看它是不是只回答了“做什么”，没有回答“改到哪为止”。后半句才是省返工的地方。 参考资料资料核对日期：2026-10-17 • Codex CLI 延伸阅读• 用 Codex 修 bug：先验证原因，再动实现 • 用 Codex 重构代码：替换旧实现，也要清理旧路径 • 用 ChatGPT 整理需求文档：先说清行为，再写功能列表 • Codex 手机号验证:什么场景触发:中国+86 能不能用:通用流程详解