长任务最危险的失败不是报错，而是“做了很多事却无法证明完成”：代理持续改文件、上下文不断增长、测试被推迟，最后用一段总结替代验收。/goal 能让目标持续附着于任务，但它不会自动把模糊愿望变成工程规格，也不会替你定义检查点。

本文面向希望让 Codex 持续推进迁移、重构、内容工程或完整站点的开发者。你需要一个 Git 仓库和可运行的验证命令。我们会把官方 Goal mode 与仓库内可审计工作流连接起来，同时明确它不扩大权限、不等于定时部署，也不存在本文自造的“万能检查点命令”。

视觉资产记录：封面（1600 × 900）与文中闭环图（1400 × 800）均为 WEB/SUN 于 2026-07-16 创作的程序化 SVG；来源/许可为本项目原创自有资产，未使用第三方图片。

读取规格、选择里程碑、实现、验证、记录证据和小型提交组成长任务闭环

图 1（1400 × 800）：每轮从完成定义选择一个可验证里程碑；失败回到当前里程碑，证据通过后才提交并进入下一项。原创程序化 SVG，WEB/SUN，2026-07-16。

/goal 提供什么，不提供什么

OpenAI 的 Long-running work说明，目标文字既是任务的第一条提示，也是完成条件；应包含 outcome、constraints 与 verification。目标会保留在同一个任务上下文中，用户仍可发送后续消息调整约束。在桌面应用，进度条提供暂停、恢复、编辑和清除；CLI 参考则记录 /goal <objective>、/goal edit、/goal pause、/goal resume 与 /goal clear 等操作。

Goal mode 不扩大 sandbox 或 approval policy。官方文档明确指出，遇到需要决定或授权的动作仍会暂停。因此“持续推进”只意味着在已有权限与范围内继续选择下一步，不意味着可以自行推送、部署、付款、发送消息或读取新的秘密。

当前官方 Slash commands与 CLI 命令清单没有把 /checkpoint 列为公开命令。本文所说的“检查点”是工程约定：规格中的里程碑、进度文件中的证据、一次小型提交与干净工作区。不要把它写成一条不存在的 Codex 指令。

短目标引用长规格

CLI Developer commands写明目标必须非空且最多 4,000 字符；更长的要求放进文件，再让目标指向该文件。

短目标只保留身份与执行纪律：

/goal 将当前仓库推进到可发布状态。先完整阅读根目录 CODEX_GOAL.md，
把其中全部约束和完成定义视为目标；维护 docs/goal-progress.md，
按里程碑实现、验证和提交。不要推送或部署，遇到外部授权时记录阻塞并继续其他项。

CODEX_GOAL.md 则按稳定结构编写：现状基线、公开接口、功能范围、非目标、内容/数据合同、性能与无障碍阈值、测试矩阵、Git/外部动作边界、已知外部阻塞、最终完成清单。规格不要只写“做得高级”“全面优化”，要给出可枚举路由、数量、命令、阈值和回归保护。

目标元素 弱描述 可验证描述
Outcome 做完整博客 固定路由可访问，文章与资源达到明确数量
Constraint 注意性能 首页初始 JS 上限、普通文章页上限、无持续离屏 RAF
Verification 测试一下 列出命令、视口、浏览器和必须保存的证据
Boundary 不要乱改 禁止 push/部署，保护现有首页，外部授权单列

完成定义必须区分“代理可完成”与“外部发布门禁”。域名、账号凭证、真实个人资料或第三方素材授权可能只能由用户提供；把它们写成明确阻塞，不应为了让清单变绿而假定已授权，也不应因此停止所有不相关工程工作。

检查点是一组持久事实

docs/goal-progress.md 不是流水账，而是一张可以恢复工作的状态表。每个里程碑至少记录：范围、文件所有者、开始/完成状态、执行命令、结果摘要、截图或报告路径、提交 hash、剩余风险和下一项。失败证据也保留，例如某浏览器仍有一个可复现问题，避免下一轮重新发现。

启动前先建立 baseline：保存 git status，识别用户已有的未提交成果，运行当前可用构建与关键交互，并记录已知失败。基线变更应先单独提交或明确保护，之后每个阶段都与它比较。否则代理可能把原本存在的功能当废代码清除，也可能把任务开始前的失败误算成自己的回归；“先知道仓库是什么状态”本身就是第一项证据。

## M03 / Article runtime

- Scope: reading progress, TOC, code copy
- Owner: main task
- Evidence: `pnpm check`; `pnpm test:e2e --grep reading`
- Result: 18 passed; screenshots in `artifacts/m03/`
- Commit: `<hash after verification>`
- Remaining: WebKit focus order fails at 320px
- Next: fix focus order, rerun the same matrix

真正的检查点同时满足四件事：变更范围小到能解释；验证与该范围相关；证据写入仓库或可追踪报告；提交信息指向一个完成的里程碑。只更新进度文字但没跑测试，不是检查点；一次提交混合架构、四十篇内容和部署文档，也难以回退。

恢复任务时先读规格与进度，再检查 git status 和最近提交，重新运行当前里程碑最小门禁。聊天摘要只能辅助，仓库事实才决定从哪里继续。若测试标准在中途改变，记录为什么改变及批准来源，不能通过删断言或放宽阈值宣布完成。

并行工作的核心是所有权

官方长任务指南允许不同任务并行，但警告不要让两个任务修改相同文件，并建议用 Worktrees提供隔离 checkout。适合并行的是官方资料研究、独立文章、独立测试审计与互不重叠的页面；共享 schema、路由、全局样式、锁文件和进度总表应由一个主任务拥有。

仅仅说“你做前端、他做内容”还不够，要写到路径：子任务 A 只新增 src/content/blog/ai-*，子任务 B 只新增独立 SVG，主任务独占 content.config.ts。交接时返回文件列表、验证命令和已知问题。共享同一 checkout 时不要让多个任务提交；由主任务审查整体 diff 后按里程碑提交，避免把别人的未完成变更一起带入。

Worktree 能隔离文件，但不能隔离所有外部资源。多个任务仍可能争用同一开发端口、浏览器 profile、模拟器、付费配额或远端环境；这些资源也要指定所有者。并行的目标是缩短独立关键路径，不是最大化代理数量。

让验证驱动下一步

每个里程碑采用同一循环：读规格、检查现状、选择未完成且无阻塞的一项、实现、运行局部门禁、浏览器或设备审查、更新证据、提交，再选择下一项。到阶段边界运行更宽的集成命令；最终运行完整 QA、检查内部链接、生产构建、工作区和监听端口。

常见失败模式包括：目标只有活动没有结果；把所有约束塞进超过限制的命令；进度只写“完成”；代理同时编辑共享文件；为了绿灯删除测试；每次恢复都从头调研；将需要用户授权的动作默认为允许；留下开发服务器；做完实现却没有回归初始基线。

用户在同一任务里询问状态时，报告“已满足哪些完成条件、证据在哪里、正在做哪一项、剩余阻塞是什么”，不要只报文件数量或运行时长。若新消息改变范围，先更新规格与完成定义，让后续提交可以解释这次变化。

结论

/goal 负责让目标持续存在；长规格负责让目标足够完整；进度文件、测试证据和小型提交负责让任务能够恢复与审计；权限政策和外部阻塞负责划清不能擅自跨越的边界。四者缺一，长时间运行只会放大漂移。

最好的目标不是让 Codex“忙很久”，而是让它始终能从仓库回答三个问题：下一项可执行工作是什么，什么证据证明它完成，完成后如何安全进入下一项。

Sources