Codex 开长任务前怎么写验收目标才不跑偏？
Codex 处理长任务前，应把目标、允许目录、完成条件、验证命令、预算边界和阻塞条件写清楚，避免执行到一半偏离真实需求。
适用场景：任务一句话说不清，Codex 就容易越做越散
这篇适合让 Codex 连续处理半小时以上的项目维护、静态 SEO 发布、AI API 接入、后台排错、自动化脚本和多文件改造。真实问题通常不是模型不会写代码，而是目标写得太粗：只说“帮我优化一下”“把这个功能做好”“修一下线上问题”，却没有说明允许修改哪些目录、哪些文件只读、上线后看什么结果。永沃云枢在 https://ai.jn83.com 维护 Codex 实操栏目时，会把长任务目标写成可验收的工程说明，而不是一句愿望。
Goal Mode 或类似长任务模式的重点，是让 Codex 围绕一个明确目标持续推进。但目标越长，越需要边界。比如 Codex 接入、AI 模型接口排错、CCSwitch 配置、开发者 AI 调用和 AI 自动化办公流程改造，都会涉及配置、日志、测试和远程环境。如果没有完成条件，任务很容易从一个小修复扩展成无关重构。
操作步骤：把目标写成能被检查的合同
第一步，写真实问题。不要只写“优化 SEO”，而要写“新增 4 篇原创中文 Codex 实操文章，更新栏目页、sitemap、首页卡片并上线验证”。真实问题越具体，Codex 越容易判断哪些动作有价值，哪些动作只是看起来忙。
第二步，写允许范围。明确本地工作区、远程目录、数据库表、禁止触碰的站点和不能修改的配置。长任务里最危险的不是少改，而是把不相关的仓库、站点或数据库一起改了。
第三步，写完成条件。完成条件应该包括文件生成、页面可访问、状态码、关键词、字数、内链、乱码检查、测试命令、推送结果和未完成事项。只有“页面看起来正常”不够，必须有可复核证据。
第四步，写阻塞条件。比如连续三次无法连接远程、缺少必要密钥、线上接口返回不一致、用户决策缺失等。Codex 遇到阻塞时应说明事实和已尝试动作，而不是继续猜。
常见问题/避坑：不要把目标写成开放式许愿
第一个坑是目标没有边界，导致 Codex 为了完成任务去改无关文件。第二个坑是验收命令缺失，最后只能靠肉眼判断。第三个坑是把“可抓取”“已提交”“已收录”混成一个结论。第四个坑是没有预算边界，长任务不断扩写、不断排查，最后产出反而不清晰。
另一个容易忽略的问题是过程记录。长任务如果中途发生上下文压缩或接手，必须能从文件清单、命令记录和验证结果恢复状态。任务目标里最好写明需要维护的记忆文件、日志路径和最终输出格式。
如果任务涉及 AI API 接入或模型调用管理，还要写明不能泄露 API Key、不能把真实用户数据写进公开日志、不能承诺搜索引擎一定收录。目标越清楚，安全边界越容易被执行。
检查清单：启动前十分钟比返工一天便宜
任务目标是否是一句话能验收的结果；允许修改目录是否明确；远程路径和数据库对象是否写清；禁止触碰范围是否列出；完成条件是否包括文件、命令、页面、状态码和内容检查；阻塞条件是否明确；最终输出是否要求区分已提交、可抓取和已收录。
建议把长任务提示分成“目标、范围、输入、步骤、验收、输出、禁区”七段。七段不需要很长，但每段都要能回答一个问题：做什么、在哪做、用什么做、怎么做、怎么证明、怎么汇报、什么不能做。
验收时不要只看 Codex 的总结，要回到具体证据：本地文件是否存在，线上页面是否 200，sitemap 是否无 BOM，首页是否出现新卡片，日志是否没有连续问号乱码。这样 Goal Mode 才真正服务交付，而不是变成一段更长的聊天。
FAQ：可以完全交给 Codex 或模型自动处理吗？
可以让 Codex 帮你收集文件、执行低风险检查、整理日志和生成初稿，但涉及生产配置、用户数据、金额、权限、正式发布和搜索提交时，仍要保留人工确认点。自动化的目标是减少重复操作，不是绕过验收。