背景与动机
Codex Cloud 的核心价值是异步。你把一个边界清楚的工程任务交出去，Codex 在后台读代码、修改、验证，然后把结果带回来。
异步任务的前提是：任务本身可以被独立判断，不需要你每五分钟做一次产品决策。
适合云端异步的任务
适合：
- 修复明确失败的测试。
- 补充文档或示例。
- 按现有模式添加小功能。
- 做代码审查。
- 批量整理格式一致的内容。
不适合：
- 需求不清楚的新产品设计。
- 需要访问本地私有资源的任务。
- 需要实时调试硬件或本地 GUI 的任务。
- 生产数据库、支付、密钥等高风险写入。
任务描述要包含验收标准
异步任务不能只写“帮我做一下”。建议使用：
目标：范围：不要做：参考文件：验证命令：完成输出：示例：
目标：为 notes 内容新增 AI 编程专栏。范围：只新增 src/content/notes 下的 Markdown 文件。不要做：不要修改组件、路由、样式和现有文章。参考文件：读取现有 notes/cicd 和 notes/go 的 frontmatter。验证命令：pnpm check 和 pnpm build。完成输出：列出新增文件、验证结果和未完成项。异步结果怎么验收
回来后重点看：
- 是否遵守范围。
- 是否跑过验证。
- 是否有额外改动。
- 是否留下半成品入口。
- 是否说明无法验证的原因。
不要只看“能不能运行”，还要看它有没有做用户没要求的扩展。
人工确认点
这些节点建议保留人工确认：
- 创建或删除大量文件。
- 改数据库迁移。
- 改认证、支付、权限。
- 引入新依赖。
- 修改部署流程。
- 推送分支或创建 PR。
异步不是放弃控制，而是把控制点放在任务边界和验收上。
云端任务描述模板
任务目标：只允许修改：禁止修改：参考实现：验收命令：交付物：失败时怎么处理：示例：
任务目标：修复 README 中过期的启动命令。只允许修改：README.md。禁止修改：源码、依赖、构建配置。参考实现：package.json scripts。验收命令：pnpm check。交付物：diff、验证结果、无法验证原因。失败时怎么处理：停止并说明阻塞，不要扩大范围。一句话总结
Codex Cloud 适合边界明确、可验证、低交互的工程任务；任务越异步，提示词里的范围和验收越要具体。