设置 App 自动化任务
基于官方 Codex App Automations 教程，面向新手讲清 automations 适合什么重复任务、worktree 怎么选、权限怎么控。
Codex App Automations 用来在后台自动运行重复任务。官方说明：有发现的结果会进入 inbox；没有需要报告的内容会自动归档。复杂任务可以和 skills 结合。
新手先记住：automation 是无人值守运行。它不是“省一个点击”，而是把某个重复检查交给后台持续执行。无人值守就必须先想清权限、范围、停止条件和结果审查。
先理解：automations 解决什么问题
适合 automation 的任务，通常有固定频率、固定范围、固定判断标准。
比如定期检查 PR 状态、扫描最近提交的风险、汇总某个目录的变化、跟进长期命令是否完成、提醒某个 review loop 继续推进。
不适合 automation 的任务，是目标模糊、需要频繁人工判断、会改大范围文件、会触碰凭据或生产配置的任务。
怎么判断用 thread automation 还是 standalone
Thread automation 挂在当前 thread 上，适合需要保留同一段上下文的任务。比如持续跟进一个部署、一个 PR review、一个正在排查的问题。
Standalone automation 每次按 schedule 启动 fresh run，适合彼此独立的周期任务。比如每天看某个目录最近变化、每周生成文档过期报告。
如果每次 run 都应该从干净上下文开始，用 standalone。如果必须记住这段对话里的历史，用 thread automation。
本地项目和 worktree 怎么选
Git 仓库里，automation 可以在本地项目中运行，也可以在后台 worktree 中运行。
本地项目模式会直接碰你当前 checkout，可能改到你正在编辑的文件。只适合只读任务，或你明确希望它处理当前工作区。
Worktree 模式会把 automation 的改动和你正在做的工作隔离开。涉及写文件、生成 patch、长期后台运行时，新手优先选 worktree。
未使用版本控制的项目没有这种隔离，automation 会直接在项目目录中运行。风险更高，只建议做只读任务。
权限怎么给
Automations 使用你的默认 sandbox settings。read-only 下，修改文件、访问网络、操作本机 app 的 tool calls 会失败。workspace-write 可以改 workspace，但 workspace 外、网络和 app 操作仍受限制。full access 风险最高，因为后台任务可能不询问就修改文件、运行命令或访问网络。
新手默认从 read-only 开始。确实需要写文件，再切 workspace-write，并把任务范围写窄。
后台 automation 不适合默认 full access。需要特殊命令时，优先用 rules 选择性 allowlist，而不是全放开。
企业环境里，管理员可以用 requirements 限制 approval policy 和 sandbox modes。
prompt 应该怎么写
Automation prompt 要能在未来反复运行，所以不能依赖“刚才我们说的那个”。它应该写清任务范围、检查频率、什么时候报告、什么时候归档、什么时候停止、什么时候向用户要输入。
如果它会改文件，还要写清允许目录、禁止目录、验证命令和输出格式。
如果任务复杂，先做 skill。用 skill 定义稳定流程，再在 automation 中显式调用它，比把长 prompt 直接塞进 automation 更可维护。
新手常见坑
- 没手动测试 prompt 就设 schedule。
- 让 automation 在本地 checkout 写文件，干扰自己正在开发的改动。
- 把一次性模糊任务做成长期自动化。
- full access 后台运行，事后才发现改了不该改的文件。
- 没有停止条件，automation 一直报告低价值结果。
- 使用 worktree 后不清理历史 runs，积累一堆 worktree。
- 结果进 inbox 后不审查，只以为自动化等于完成。
怎么验收
先在普通 thread 手动跑一次 prompt，确认 scope、工具、模型和输出符合预期。
再创建 automation，只让它跑前几次，并逐次审查 inbox 结果。
如果它会写文件，确认改动发生在 worktree 或允许范围内，并且验证命令能跑。
如果没有发现内容，它应该能安静归档，而不是制造噪音。
如果任务完成或不再需要，应该能归档 run、停止 automation，并清理不再需要的 worktree。