# CX-09 Automations 完整指南：App 里的后台任务、提醒和周期检查

本篇是 App 主线中的 Automations 后台任务篇。

主要来源：OpenAI Codex App Automations、App Features、Skills、Rules、CLI / GitHub Action 官方文档。

---

> **课程信息**
>
> - **作者**：老金
> - **GitHub**：https://github.com/KimYx0207
> - **公众号**：老金带你玩AI
> - **X（Twitter）**：老金带你玩AI
> - **个人博客**：https://aiking.dev
> - **预计学时**：2-3小时
> - **难度等级**：⭐⭐ 入门级
> - **更新日期**：2026年5月30日
> - **信息来源**：OpenAI Codex App Automations、App Features、Skills、Rules、CLI / GitHub Action 官方文档
> - **前置要求**：已完成 [CX-01 安装](./CX-01-Codex-App安装与认证完整指南.md)、[CX-02 桌面工作流](./CX-02-Codex-App桌面工作流完整指南.md)

---

## 📚 本课学习目标

完成本课学习后，你将能够：

1. **理解Automations的本质**：掌握它是后台/周期执行重复任务的能力，不是一次性工具
2. **创建规范的Automation**：写清频率、目录、目标、权限、输出、停止条件
3. **区分三类自动化任务**：摘要（只读）、检查（只读或最小写入）、修复（必须Review）
4. **组合Skill和Automation**：Automation管"什么时候运行"，Skill管"怎么做"
5. **理解与Command/Skill的区别**：Command手动触发、Skill复用流程、Automation按计划执行
6. **掌握安全基线**：学习阶段只读优先，不自动提交、不自动推送、不自动删除
7. **核对Automation效果**：时间、范围、输出、失败处理、副作用、暂停入口六维检查
8. **区分App/CI/SDK场景**：知道什么时候用App Automation、什么时候用GitHub Action或SDK

---

## 🗺️ 学习路径导航（先看这里！）

> 💡 **根据你的情况选择学习路径**：不用全看！

### 路径A：快速上手（⏱️ 15分钟）

**适合人群**：想快速创建一个每日检查任务

**只看这些章节**：

```
✅ 第1-2部分：Automations是什么 + 创建方式（5分钟）
✅ 第3部分：三类常见任务（3分钟）
✅ 第10部分：设计模板（7分钟）
```

---

### 路径B：完整学习（⏱️ 2-3小时）

**适合人群**：想系统掌握Automations和安全基线

**学习顺序**：从头到尾所有章节

---

## 术语表（小白必读）

Automations 是很多人第一次真正让 Codex “不在眼前也运行”的功能，所以先把几个词说清楚。

| 术语 | 一句话解释 | 新手注意 |
|---|---|---|
| Automation | 后台或周期运行的 Codex 任务 | 不是一次性 prompt |
| Standalone automation | 每次按计划启动新运行 | 适合独立报告和跨项目检查 |
| Thread automation | 绑定当前线程的定期唤醒 | 适合持续追踪同一件事 |
| Triage | 自动化结果 inbox | 有发现才进入 Triage，没发现可能自动归档 |
| Local project mode | 在当前项目目录运行 | 可能改到你正在工作的目录 |
| Background worktree | Git 仓库中隔离运行 | 更适合产生改动的自动化 |
| Sandbox setting | 自动化继承的默认权限边界 | 后台任务权限越大风险越高 |
| Skill-driven automation | Automation 负责时间，Skill 负责做法 | 团队最推荐的可维护组合 |
| Finding | 自动化运行发现的问题或报告 | 要能让人判断下一步 |

一句话：Automation 管“什么时候醒来”，Skill 管“醒来后怎么做”，Rules / sandbox 管“能做多大动作”，Triage 管“结果在哪里看”。

## 0. Automations 的工作机制

老金在自动化课里最怕“无人值守但没人负责”，所以每个后台任务都要有触发、权限和结果检查。

一次 Automation 运行可以理解为：

```text
你创建任务和计划
  -> Codex 在指定时间或线程节奏唤醒
  -> 根据 automation 类型选择项目、线程或 worktree
  -> 按默认 sandbox / approval / tools 执行
  -> 有发现就进入 Triage 或回到线程
  -> 没发现则可能自动归档
```

它和普通线程最大的区别是：你不一定在旁边看着。所以 prompt 必须比普通任务更耐久、更保守、更具体。

### 0.1 Standalone 和 Thread automation 怎么选

| 需求 | 推荐 | 原因 |
|---|---|---|
| 每天检查某项目测试是否失败 | Standalone | 每次运行相互独立，结果进 Triage |
| 每周总结多个项目文档漂移 | Standalone | 可跨项目，报告独立 |
| 30 分钟后继续看部署是否完成 | Thread automation | 需要保留当前线程上下文 |
| 持续跟进一个 PR review loop | Thread automation | 评论、修复、状态都在同一线程 |
| 每次都要从干净 prompt 开始 | Standalone | 上下文更可控 |
| 需要围绕当前讨论持续唤醒 | Thread automation | 保留上下文更重要 |

### 0.2 自动化 prompt 为什么要更“耐久”

普通线程里，Codex 可以随时问你；后台运行时，如果 prompt 含糊，它可能反复失败、反复报告同一件事，或在你没看见时产生不想要的副作用。

一个耐久 prompt 要包含：

```text
频率：什么时候运行
范围：在哪个项目、哪些目录
动作：每次醒来做什么
权限：是否允许写文件、联网、评论、创建 PR
输出：报告到哪里，格式是什么
停止：什么情况下不再重复，什么情况下升级给人
失败：命令失败、环境失败、权限不足时怎么处理
```

## 1. Automations 是什么

Automations 是让 Codex 在后台或按计划执行重复任务的能力。

项目级 Automation 依赖本机 App 环境：运行时这台机器要开机，Codex App 要在运行，目标项目目录也要仍然存在。Git 仓库可以选择在当前 local project 中运行，也可以在新的 background worktree 中运行；worktree 能把自动化改动和你手头未完成的本地改动隔离开。

适合：

- 每天检查测试是否失败。
- 每周总结依赖更新。
- 定期检查文档和代码是否漂移。
- 监控 PR、部署或 issue 状态。
- 生成团队例行摘要。

不适合：

- 一次性问题。
- 目标不清楚的大改。
- 需要人工决策的高风险写操作。

## 2. App 中的创建方式


App 主线里可以直接自然语言创建：

```text
每天早上 9 点检查这个项目的测试是否失败。如果失败，只汇总失败测试和可能原因，不要修改文件。
```

好的 Automation 需要说明：

- 运行频率。
- 工作目录。
- 任务目标。
- 是否允许写文件。
- 输出去哪里。
- 什么情况下停止或升级给人。

创建后不要立刻信任它。先检查：

1. App 是否显示 automation 名称和状态。
2. 运行时间是否符合你的时区。
3. 工作目录是否是目标项目。
4. 是否只读或写入范围受限。
5. 输出会回到当前线程、通知、PR 评论还是其他地方。
6. 有没有暂停、删除或修改入口。

## 3. Automations 的三类常见任务

| 类型 | 示例 | 权限建议 |
|---|---|---|
| 摘要 | 每周总结 open issues | 只读 |
| 检查 | 每天运行测试或 lint | 只读或最小写入 |
| 修复 | 自动修小问题并提交 PR | 必须明确范围和 Review |

学习阶段优先只读。

### 3.1 不同任务的合格输出

| 任务 | 合格输出 | 不合格输出 |
|---|---|---|
| 每日测试检查 | 失败测试名、错误摘要、相关文件、下一步建议 | 只说“测试失败” |
| 文档漂移检查 | 哪个文档与哪个源码/脚本不一致 | 泛泛说“文档可能过期” |
| 依赖更新摘要 | 包名、当前版本、目标版本、风险、是否需要人工决策 | 自动升级所有依赖 |
| PR 监控 | PR 状态、CI 状态、阻塞项、需要谁处理 | 无限重复评论 |

Automation 的价值是把重复检查变成稳定报告，不是让后台任务悄悄替你做高风险决策。

## 4. Cron、Heartbeat 和 Thread Follow-up 怎么理解

App 里的自动化可以理解成三类使用体验：

| 类型 | 适合 | 注意 |
|---|---|---|
| 定时 / 周期任务 | 每天、每周、每小时检查 | 写清时区、目录、输出 |
| 当前线程稍后继续 | 30 分钟后提醒、稍后复查 | 适合短期 follow-up |
| 监控任务 | 盯 PR、部署、issue 状态 | 要写清停止条件 |

不要手写复杂调度语法给普通读者。App 用户优先用自然语言创建，再在 App 里 Review 生成的计划。

### 4.1 频率设计：不要让自动化制造噪音

| 任务 | 推荐频率 | 原因 |
|---|---|---|
| 测试守护 | 每天一次或工作日前一次 | 太频繁会被失败噪音淹没 |
| PR 状态跟进 | 15-60 分钟，带停止条件 | 等 CI 或 review 时有价值 |
| 依赖摘要 | 每周一次 | 每天看依赖容易疲劳 |
| 文档漂移 | 每周或每次 release 前 | 文档变化不是秒级问题 |
| 安全扫描摘要 | 按风险和工具成本设置 | 高频扫描要看误报和费用 |

Automation 的目标不是"越频繁越安心"，而是让重要信息在正确时间出现。

## 5. 与 Skills 组合

Automation 管“什么时候运行”，Skill 管“怎么做”。

例子：

```text
每周一上午运行 $dependency-review，总结 package.json 的依赖风险。不要自动升级依赖。
```

好处：

- Automation 保持短。
- Skill 里沉淀详细流程。
- 团队可以复用同一个 Skill。

## 6. 与 Commands 的区别

| 能力 | 触发方式 | 适合 |
|---|---|---|
| Command | 当前会话手动输入 | 立即执行 |
| Skill | 用户点名或自然语言触发 | 可复用流程 |
| Automation | 时间或后台事件触发 | 重复任务 |

不要用 Automation 做本来一次就能完成的事。

## 7. 安全基线

| 任务 | 建议 |
|---|---|
| 文档漂移检查 | 只读，输出报告 |
| 测试守护 | 先只读，失败后提醒 |
| PR 修复 | 用 worktree 或分支，必须 Review |
| 依赖升级 | 不自动合并 |
| 外部服务通知 | 限定目标 channel / repo |

所有自动化都要避免：

- 读取 `.env*`。
- 自动推送主分支。
- 自动删除文件。
- 自动扩大外部服务权限。

## 8. 运行后核对


第一次运行后必须检查：

| 核对项 | 你应该看到 |
|---|---|
| 时间 | 按预期时间触发，不跨错时区 |
| 范围 | 只读/只写指定目录 |
| 输出 | 摘要足够人判断下一步 |
| 失败处理 | 失败时汇报原因，不无限重试 |
| 副作用 | 没有自动提交、推送、发错消息 |
| 暂停入口 | 能在 App 中暂停或删除 |

### 8.1 失败时怎么收敛

第一次失败不要马上放大权限。按这个顺序处理：

1. 看失败是不是环境问题：依赖没装、命令不存在、工作目录错。
2. 看失败是不是任务描述不清：范围、输出、停止条件没写。
3. 看是否需要改成只读报告：先让人判断，再决定是否允许写入。
4. 如果要自动修，必须加文件范围、验证命令和 Review 要求。

一个更稳的失败处理提示：

```text
如果检查失败，只输出失败原因、相关日志摘要和建议下一步。不要修改文件，不要重试超过 2 次，不要提交或推送。
```

### 8.2 自动化失败模式

| 失败模式 | 表现 | 修正 |
|---|---|---|
| 无限重复同一错误 | 每次 Triage 都报同一个环境问题 | 加停止条件，先修环境 |
| 自动化改到本地未完成文件 | local project mode 下直接写当前工作区 | 改用 background worktree |
| 报告太空 | 只说“失败了” | 要求输出命令、摘要、相关文件、下一步 |
| 自动修范围扩大 | 从 docs 链接修到代码重构 | 写清可改目录、文件类型和禁止事项 |
| 外部通知太吵 | 频繁评论 PR 或发消息 | 限制通知条件和频率 |
| 权限不足反复失败 | read-only 下试图写文件或联网 | 要么改成只读报告，要么明确提升最小权限 |

### 8.3 Triage 处理方法

Triage 不是垃圾箱，而是自动化的工作台。处理顺序：

1. 先看 automation 名称、运行时间和项目。
2. 再看 finding 是否具体：命令、错误、文件、建议是否齐全。
3. 如果是环境问题，先修环境，不要放大自动化权限。
4. 如果是代码问题，决定交给当前线程、worktree、Cloud，还是人工处理。
5. 处理完归档，避免 Triage 长期堆积。

团队使用时，可以把 Triage 当作每日站会的一部分：只看高价值 finding，不讨论自动化本身的噪音。

## 9. 与 GitHub Action / CI 的区别


| 类型 | 运行位置 | 适合 |
|---|---|---|
| App Automation | Codex App / 用户环境 | 个人和团队例行检查 |
| GitHub Action | CI runner | PR、push、仓库自动化 |
| CLI `codex exec` | 终端或脚本 | 无头一次性任务 |
| SDK | 自研系统 | 内部平台和复杂队列 |

不要把 App Automation 当成 webhook server。接飞书、钉钉、企业微信或内部系统时，通常应由外部系统触发 CI / SDK / Cloud，而不是让桌面 App 暴露公网。

## 10. 设计模板

### 10.1 只读摘要任务

```text
每周五 17:00 总结本仓库本周 open PR 的状态，列出阻塞原因和需要人工决策的项。只读，不评论 PR。
```

### 10.2 测试守护任务

```text
每天 9:00 在当前项目运行 npm test。如果失败，汇总失败测试名、错误摘要和相关文件。不要修改文件。
```

### 10.3 文档漂移任务

```text
每周一检查 README、AGENTS.md 和 docs/ 是否与 package.json 的脚本一致。只输出 drift report，不修改文件。
```

### 10.4 小范围自动修复任务

```text
每周三检查 docs 中失效的内部相对链接。只允许修改 docs/ 下的 markdown 链接，改完展示 diff，不自动提交。
```

### 10.5 PR 跟进任务

```text
每 30 分钟检查当前 PR 的 CI 和 review 状态。只读读取 PR、CI 和评论。如果 CI 通过且没有未处理 review，请报告“可以人工合并”。如果有失败，只总结失败项和建议下一步。不要评论 PR，不要 push，不要合并。连续 6 次没有变化后停止并报告。
```

### 10.6 Skill 驱动任务

```text
每周五 16:00 在当前项目运行 $release-readiness。只读检查 release notes、测试命令、文档链接和未合并 PR。输出 release readiness report，不修改文件。
```

这种写法让 Automation prompt 保持短，复杂流程由 Skill 维护。

## 11. 课堂工坊：从只读自动化到小范围修复

### 案例一：每日测试守护，只报告不修

目标：创建一个不会改文件的后台检查。

```text
每天早上 9 点在当前项目运行 npm test。如果失败，只汇总失败测试名、错误摘要、相关文件和建议下一步。不要修改文件，不要重试超过 2 次，不要提交或推送。
```

创建后在 App Automations 面板确认：任务名称、运行时间、目标项目、输出位置和暂停入口。第一次运行后看 Triage 或对应线程，确认它没有产生 diff。

### 案例二：文档漂移检查，用 worktree 隔离

目标：让后台任务检查文档和脚本是否一致，同时避免污染当前工作区。

```text
每周一检查 README、AGENTS.md 和 docs/ 中提到的命令是否和 package.json scripts 一致。Git 仓库中请优先使用 background worktree。只输出 drift report，不修改文件。
```

你应该看到：报告能列出具体文档和具体脚本差异；如果选择 worktree，自动化运行不会把临时改动混进你当前未完成工作。

### 案例三：小范围自动修复但必须 Review

目标：只允许修 Markdown 相对链接，避免自动化扩大到代码。

```text
每周三检查 docs/ 下失效的内部相对链接。只允许修改 docs/ 下的 markdown 链接。改完展示 diff，等待我 Review，不要提交、推送或创建 PR。
```

你应该看到：自动化如果发现问题，只产生 docs/ 下 markdown 的小 diff；如果需要改代码、配置或外部链接，它应停下来报告。

## 12. 自动化运营手册

Automation 上线后要运营。没人维护的后台任务会慢慢变成噪音或风险。

### 12.1 上线前

| 项 | 做法 |
|---|---|
| 手动试跑 | 先在普通线程里跑一次 prompt |
| 权限确认 | 优先 read-only，写入必须限定目录 |
| 输出检查 | 报告能让人决定下一步 |
| 失败路径 | 命令失败、工具不可见、权限不足时怎么说 |
| 停止条件 | 重复无变化、连续失败、目标完成后停止 |
| Owner | 谁负责看 Triage 和调整 prompt |

### 12.2 上线后第一周

| 天数 | 检查 |
|---|---|
| 第一次运行后 | 是否按预期时间、项目、权限运行 |
| 第 2-3 次 | 是否重复报告同一无用信息 |
| 一周后 | 是否需要改频率、输出格式或停止条件 |
| 第一次产生 diff 后 | 是否使用 worktree，diff 是否可 Review |

### 12.3 每月维护

每月看一次：

- 是否还有人读 Triage。
- 任务是否仍有价值。
- 是否有权限过宽的 automation。
- 是否有长期失败但没人处理的 run。
- 是否需要把 prompt 抽成 Skill。
- 是否要改成 CI / Cloud / SDK 路径。

### 12.4 自动化分级

| 等级 | 能做什么 | 例子 |
|---|---|---|
| L1 只读报告 | 不改文件、不外部写 | 每日测试失败摘要 |
| L2 小范围本地修复 | 只改指定 docs / tests，等待 Review | 修 markdown 内部链接 |
| L3 创建 PR | 在 worktree / 分支中提交建议 PR | 依赖小版本更新 |
| L4 外部系统动作 | 评论、发消息、更新 issue | 需要明确 scope 和审计 |
| L5 高风险自动化 | 部署、合并、生产写入 | 默认不建议由 App Automation 做 |

学习阶段停在 L1-L2。团队成熟后，再讨论 L3-L4。L5 要有专门治理，不写成普通教程路径。

## 常见问题

### Q1：电脑关机时 App Automations 还会运行吗？

取决于当前 App 和环境能力。需要可靠持续运行时，优先考虑云端 runner、GitHub Action 或 Codex Cloud。

### Q2：Automation 能自动修 bug 吗？

能，但不建议一开始就自动修。先做只读报告，再逐步放开小范围写入。

### Q3：可以用配置文件批量管理 Automations 吗？

以当前 App 支持能力为准。教程不要臆造不存在的 `.codex/automations.toml` 主路径。

### Q4：Automation 可以用 Subagents 吗？

可以，但要更保守。后台并行任务必须写清文件所有权、是否只读、合并方式和停止条件。否则多个后台执行单元会更难 Review。

### Q5：Automation 没有发现问题时去哪了？

按官方行为，自动化有发现会进入 inbox / Triage；没有要报告的内容可能自动归档。你应该在 Automations 面板里查看运行历史，而不是只等聊天消息。

### Q6：自动化适合自动发 PR 吗？

可以作为进阶用法，但不建议学习阶段直接启用。先做只读报告，再允许小范围 worktree 改动，最后才考虑创建 PR，并且必须让人 Review。

### Q7：为什么自动化要先手动测试 prompt？

因为定时运行会放大 prompt 的问题。手动线程里先跑一次，可以确认范围、输出、权限和 diff 是否可控，再设为自动化。

---

## 13. 深入理解：Automation 是后台同事，不是无人驾驶

Automations 最容易被误解成“让 Codex 自己每天把事情做完”。更准确的理解是：它是一个会按时间醒来的后台同事。它可以提醒、检查、汇总、提出修复建议，也可以在受控范围内改文件，但它不应该替代人的发布判断。

你可以用这张表判断任务适不适合自动化：

| 任务特征 | 适合自动化吗 | 原因 |
|----------|--------------|------|
| 每次都要重复检查 | 适合 | prompt 可以稳定复用 |
| 输出是报告或提醒 | 适合 | 风险低、容易 triage |
| 每次都要人工判断 | 部分适合 | 让它准备材料，人来决策 |
| 会修改生产配置 | 谨慎 | 后台写入风险高 |
| 需要登录很多外部系统 | 谨慎 | 插件、权限和数据范围要清楚 |
| 电脑经常关机 | 不适合本地项目自动化 | 本机 App 不运行时无法按本地项目执行 |

### 13.1 常见自动化形态

| 形态 | 例子 | 推荐权限 |
|------|------|----------|
| 定期巡检 | 每天看测试是否失败 | 只读 |
| 信息汇总 | 汇总 PR 评论和 Slack 讨论 | 只读 + 插件读取 |
| 修复建议 | 生成文档漂移修复方案 | workspace write 或先报告 |
| 小范围整理 | 格式化、更新索引、整理 changelog | worktree + Review |

越靠近“会写文件、会改外部状态”，越需要 worktree、Review 和人工确认。

## 14. Standalone 与 Thread Automation 的深层区别

前面已经讲过基本选择。这里用课程案例再压实一次。

### 14.1 Thread Automation：让同一个对话定期醒来

适合正在进行的任务：

```text
请在这个线程里每 15 分钟醒来一次，检查我刚才启动的部署是否完成。
每次只读取当前终端或已连接来源的状态。
如果部署成功，给我一个简短总结并停止提醒。
如果部署失败，列出最重要的错误和下一步建议。
不要修改文件。
```

这个自动化依赖当前线程上下文，所以适合 thread automation。

### 14.2 Standalone Automation：每次独立运行

适合周期性检查：

```text
每个工作日上午 9 点检查这个项目：
1. 读取 Git 状态和测试配置
2. 如果有失败的测试记录，生成摘要
3. 如果没有发现问题，自动归档
4. 不修改文件，不提交，不推送

输出要适合我在 Triage 里快速阅读。
```

这个任务不需要保留前一次对话，所以适合 standalone automation。

### 14.3 Project Automation：绑定项目目录

适合围绕某个仓库长期运行：

```text
每周一检查 docs/ 目录是否可能过期。
读取 README、docs/、package.json 和最近一周的 commit 信息。
输出：
- 可能过期的文档段落
- 对应的代码或配置变化
- 建议更新的文件

默认只报告。如果你认为可以自动修复，只给出补丁建议，不直接写入。
```

如果仓库是 Git 项目，可以选择本地项目或 background worktree。教学时建议优先讲 worktree，因为它更容易解释隔离。

## 15. 自动化 prompt 的耐久写法

普通聊天 prompt 可以依赖当下上下文，Automation prompt 不行。它要能在下周、下个月、项目状态变化后仍然读得懂。

### 15.1 差 prompt

```text
每天帮我看看有没有问题。
```

这个 prompt 缺少对象、频率之外的行为、输出形式、边界和停止条件。

### 15.2 好 prompt

```text
每天上午 9 点检查当前项目的测试健康状态。

范围：
- 读取 package.json、测试配置和最近一次可用测试输出。
- 如果没有测试输出，说明缺少哪条命令，而不是猜测。

行为：
- 不修改文件。
- 不运行耗时超过 10 分钟的命令。
- 不访问项目外目录。

输出：
- 如果有问题，写成 Triage 摘要。
- 如果没有问题，说明检查了哪些来源，然后归档。
```

### 15.3 耐久 prompt 的五个要素

| 要素 | 要回答的问题 |
|------|--------------|
| 对象 | 每次醒来检查哪个项目或线程 |
| 来源 | 读取哪些文件、工具、插件或终端输出 |
| 行为 | 允许做什么，不做什么 |
| 输出 | 报告、提醒、diff 建议还是后续问题 |
| 停止 | 什么情况下归档、停止或请求人工判断 |

## 16. Triage 工作法：把后台输出变成行动

Automations 的结果会进入 Triage。Triage 不是垃圾箱，而是一个决策收件箱。

### 16.1 读 Triage 的顺序

```text
1. 先看是否有真实发现。
2. 再看发现来自哪个项目和哪次自动化。
3. 判断它是信息、提醒、风险还是可执行修复。
4. 对可执行修复，打开对应线程或项目。
5. 用 Review 面板看 diff，决定是否保留。
```

### 16.2 Triage 分类表

| 类型 | 例子 | 处理方式 |
|------|------|----------|
| 无事发生 | 没有失败测试 | 归档 |
| 信息摘要 | 本周 PR 评论汇总 | 阅读后归档或转任务 |
| 风险提醒 | 依赖升级后测试失败 | 打开线程继续查 |
| 建议修复 | 文档链接坏了并给出补丁 | 用 Review 看 diff |
| 阻塞问题 | 认证失败、插件不可用 | 修配置或停用自动化 |

### 16.3 Triage 二次追问 prompt

```text
请基于这次 automation run 的结果，帮我判断它属于：
1. 可以直接归档的信息
2. 需要我今天处理的问题
3. 需要新建任务的问题
4. 自动化本身需要调整的问题

请给出理由，不要修改文件。
```

这个 prompt 能把“后台输出”转成“人的下一步”。

## 17. Worktree 自动化：把后台写入隔离开

官方文档强调：Git 仓库里的 automations 可以选择本地项目或新的 worktree。教学时要把这个点讲透，因为它直接影响安全感。

### 17.1 Local 项目模式

Local 模式直接在你的项目目录运行。优点是简单，缺点是可能碰到你正在写的文件。

适合：

- 只读检查。
- 你明确希望它操作当前 checkout。
- 非 Git 项目只能直接在项目目录执行。

不适合：

- 会频繁写文件。
- 你白天也在同一个目录开发。
- 团队多人共用一个项目目录。

### 17.2 Worktree 模式

Worktree 模式给自动化一个独立 checkout。优点是隔离，缺点是需要维护和清理。

适合：

- 自动化会提出小补丁。
- 每周或每天都要跑。
- 你不想污染当前未提交改动。

### 17.3 Worktree 清理习惯

```text
每周查看 automations pane：
1. 归档已经处理的 runs。
2. 不再需要的 worktree 不要长期保留。
3. 对频率过高但价值低的任务降频或停用。
4. 对经常失败的任务先修 prompt，不要继续堆运行次数。
```

Worktree 不是免费的无限沙盒。它让工作隔离，但仍然需要人维护。

## 18. 自动化与 Skills：把重复动作沉淀成可维护流程

如果一个 automation prompt 越写越长，说明它可能应该拆出 Skill。

### 18.1 什么时候加 Skill

| 信号 | 处理 |
|------|------|
| 多个自动化复用同一流程 | 写成 Skill |
| prompt 里有很多步骤 | 把步骤放进 Skill |
| 需要附带参考文件 | Skill 用 references |
| 需要脚本辅助 | Skill 用 scripts |
| 团队要共享 | Skill 打包进 Plugin |

### 18.2 自动化调用 Skill

```text
$docs-drift
每周一上午检查这个项目的文档漂移。
使用 skill 中定义的流程。
只报告可能过期的位置和证据。
不要直接修改文件，除非我在后续线程里要求。
```

这个 prompt 把“重复流程”交给 Skill，把“时间和范围”交给 Automation。

### 18.3 Skill 里的自动化说明

```md
---
name: docs-drift
description: Check whether project documentation has drifted from code and configuration.
---

Workflow:
1. Read README, docs, package metadata, and recent code changes.
2. Identify statements likely to be outdated.
3. Cite source files and the conflicting evidence.
4. Return a compact report.

Automation usage:
- Prefer read-only runs.
- Use worktree only when the user asks for proposed edits.
- Archive runs with no findings.
```

这样自动化 prompt 不需要每次复制完整工作法。

## 19. 自动化安全模型：无人值守时权限更要窄

Automations 是后台运行，所以权限要比普通交互线程更保守。

| 权限模式 | 自动化里的含义 |
|----------|----------------|
| Read-only | 修改、网络或外部 app 相关工具可能失败 |
| Workspace write | 可在工作区写文件，但项目外和网络仍受限 |
| Full access | 风险更高，适合受控环境，不适合随手默认 |

### 19.1 自动化安全 prompt

```text
这是一条无人值守自动化。
默认只读。
如果你认为需要修改文件，请输出建议补丁和原因，不要直接写。
如果你需要外部网络、插件登录或项目外目录，请报告缺少的权限。
```

### 19.2 自动写入时的边界 prompt

```text
这条自动化可以在 background worktree 中修改文件。
只允许修改 docs/ 目录内的 Markdown 文件。
不要改代码、配置、锁文件或生成物。
完成后输出改了哪些文件、为什么改、建议我在 Review 面板里看什么。
```

### 19.3 外部系统写操作

如果自动化涉及 GitHub、Slack、Drive 等外部系统，建议默认只读：

```text
你可以读取 GitHub PR 评论并总结。
不要发表评论，不要改 PR 标题，不要打 label，不要关闭 issue。
如果你认为需要外部写操作，请把建议写给我，由我决定。
```

这能防止“后台任务看似聪明，实际替人做了不可逆动作”。

## 20. 自动化运营：第一周最关键

自动化不是创建后就结束。真正的课程重点是创建后的第一周。

### 20.1 第一天

```text
人工运行一次同样的 prompt。
检查输出是否可读。
确认没有多余写入。
确认 Triage 摘要能让人快速决策。
```

### 20.2 第三天

```text
看前三次输出：
- 有没有重复噪音？
- 有没有遗漏重要信息？
- 有没有经常请求不该请求的权限？
- 是否需要降频？
```

### 20.3 第七天

```text
决定：
- 保留
- 降频
- 改成 thread automation
- 改成 standalone automation
- 拆出 Skill
- 停用
```

### 20.4 噪音削减 prompt

```text
这条自动化产生了太多低价值提醒。
请根据最近几次输出，帮我重写 prompt：
1. 只报告有行动价值的发现
2. 没有发现时自动归档
3. 把重复信息合并
4. 对不确定信息标注来源和不确定原因
```

## 21. 自动化案例库

### 21.1 依赖更新观察

```text
每周二上午检查依赖更新风险。
读取 package.json、lockfile 和最近一周依赖相关提交。
只报告：
- 新增依赖
- major version 升级
- 安全相关依赖变化
- 可能需要人工 review 的升级

不要直接运行升级命令，不要修改 lockfile。
```

### 21.2 PR 评论跟进

```text
每天下午 5 点检查当前项目相关 PR 的未处理评论。
使用可用的 GitHub 连接能力读取评论。
输出：
- 新评论
- 已解决评论
- 需要我回复的问题
- 可以交给 Codex 本地修复的问题

不要回复评论，不要推送代码。
```

### 21.3 文档链接巡检

```text
每周五检查 docs/ 目录中的内部链接。
可以运行快速链接检查命令。
如果发现坏链，在 worktree 中提出最小修复。
不要改动 docs/ 之外的文件。
```

### 21.4 发布前提醒

```text
在这个线程里每 30 分钟提醒我检查发布准备情况，直到我说停止。
每次醒来时只做三件事：
1. 总结当前线程里的未完成发布事项
2. 提醒我需要人工确认的步骤
3. 如果没有新事项，保持简短
```

### 21.5 本地开发服务器观察

```text
在这个线程里每 10 分钟查看当前终端输出。
如果开发服务器崩溃，摘出错误堆栈和最可能原因。
如果服务器正常运行，只简单说明状态。
不要重启服务，除非我明确要求。
```

## 22. 综合工坊：创建一个每周文档漂移自动化

这个工坊把 Automations、Skills、worktree 和 Triage 串起来。

### 22.1 任务目标

每周检查项目文档是否和代码、配置、README 不一致。默认只报告，不直接修改。

### 22.2 先手动跑 prompt

```text
请只读检查当前项目的文档漂移。
范围：
- README
- docs/
- package.json
- 最近的相关代码变更

输出：
- 明确不一致
- 可能过期
- 需要人工确认

不要修改文件。
```

只有手动输出可读，才适合变成 Automation。

### 22.3 创建自动化 prompt

```text
每周一上午 9 点检查当前项目的文档漂移。

范围：
- README
- docs/
- package metadata
- 最近一周与文档相关的 commit

行为：
- 默认只读
- 不修改文件
- 不提交
- 不推送
- 如果没有发现，自动归档

输出：
- 文档路径
- 可疑陈述
- 代码或配置证据
- 建议下一步
```

### 22.4 第一周观察

```text
第 1 次：检查输出是否太泛。
第 2 次：检查是否重复提醒同一件事。
第 3 次：检查有没有误报。
第 4 次：决定保留、降频或改 prompt。
```

### 22.5 Triage 处理

```text
请根据这次 docs drift automation 的结果，帮我判断：
1. 哪些可以直接归档
2. 哪些应该今天处理
3. 哪些适合开一个 Codex App 线程修
4. 自动化 prompt 是否需要调整
```

## 23. 综合工坊：PR 评论跟进自动化

### 23.1 适用场景

你有一个活跃 PR，希望每天收一次评论摘要，但不想让后台任务自动回复或改代码。

### 23.2 Prompt

```text
每个工作日下午 5 点检查当前项目关联 PR 的新评论。

使用可用 GitHub 连接能力只读读取：
- reviewer comments
- unresolved conversations
- CI status summary if available

不要：
- 回复评论
- 修改 PR 标题
- 打 label
- push 代码
- 关闭 issue

输出：
- 新评论
- 需要我回复的问题
- 可以本地修复的问题
- 阻塞合并的问题
```

### 23.3 后续处理

```text
请把这次 PR automation 输出转成明天上午的工作计划。
按 30 分钟、60 分钟、需要他人确认 三类整理。
```

## 24. Automation 设计题

### 24.1 题目 A

```text
每天自动修复所有测试失败并推送。
```

判断：高风险，不适合普通 Automation。可以改成：

```text
每天检查测试失败并生成 Triage 报告。
如果能定位最小修复，给出建议，不直接推送。
```

### 24.2 题目 B

```text
每周检查 docs 链接，坏链在 worktree 中提出修复。
```

判断：可以试点。范围清楚，写入 docs，worktree 隔离。

### 24.3 题目 C

```text
每小时读取生产数据库，找异常用户并自动封禁。
```

判断：不适合作为普通 Codex Automation。涉及生产数据和外部高风险写操作，需要专门系统和人工流程。

## 25. Automation 进阶常见问题

### Q1：没有发现时为什么会自动归档？

后台任务如果每次都提醒“没事”，会制造噪音。Triage 应该优先展示有行动价值的发现。

### Q2：Automation 能不能跑测试？

可以，但要考虑耗时、权限和噪音。频率高的自动化不要跑全量慢测试，优先跑目标命令或读取已有 CI 状态。

### Q3：Automation 能不能和 Subagents 一起用？

可以，但要谨慎。后台并行会增加成本和风险。更适合只读多视角分析，不适合无人值守并行写入。

### Q4：Automation 的 prompt 改了会影响之前的 runs 吗？

通常后续运行会使用新 prompt；历史 run 仍是历史记录。改 prompt 后要观察前几次输出。

### Q5：为什么自动化第一周要密切观察？

因为真正的问题往往不是能不能跑，而是是否产生有价值、低噪音、可处理的结果。

## 26. Automation 运营案例：后台任务也要有人接住

Automation 最大的失败不是"没有运行"，而是运行了很多次，却没有人处理输出。一个健康的自动化更像一条小型运营流程：它有触发时间、有输入范围、有输出位置、有停用条件，也有人定期判断它还值不值得继续跑。

以“每周一检查文档漂移”为例，第一版 prompt 往往会写得太宽：

```text
每周检查文档有没有问题。
```

这会产生三个麻烦：

```text
- Codex 不知道重点看哪些文档。
- 输出可能变成泛泛建议。
- 团队不知道哪些结果需要当天处理。
```

更像课程可用案例的版本应该把责任写进 prompt：

```text
每周一上午检查 docs 目录是否与当前代码和配置明显不一致。

只读执行：
1. 读取 docs 目录、package scripts、配置文件和最近一周的 diff。
2. 找出会误导新人的文档漂移。
3. 输出 3 类结果：本周必须修、可以排期、暂不处理。
4. 每条结果都附文件路径和原因。

不要：
- 修改文件。
- 创建分支。
- 调用外部系统。
- 输出超过 10 条问题。
```

这时后台任务的接力方式就很清楚：

```text
任务 owner：看输出是否有价值，必要时改 prompt 或降频。
工程同学：只处理“本周必须修”的具体项。
项目负责人：用摘要判断是否影响发布或培训。
安全/平台同学：只在任务要写文件、调用外部系统或提升权限时介入。
```

如果一条 automation 连续三次只产出低价值提醒，不要继续忍受噪音。可以这样请 Codex 帮你调参：

```text
请分析最近三次 automation 输出。

目标：
1. 找出重复、低价值或不可行动的提醒。
2. 建议减少噪音的 prompt 改法。
3. 判断应该保留当前频率、降频，还是停用。
4. 不要修改 automation 配置，只输出建议。
```

## 27. Automation 作业：设计一个低噪音任务

```md
# Automation Design

## Goal

...

## Schedule

...

## Sources

...

## Allowed Actions

...

## Not Allowed

...

## Triage Output

...

## Archive Condition

...
```

要求：必须写出“没有发现时如何处理”，否则自动化容易制造噪音。

## 28. Automation 第一周运营日志：别创建完就忘

Automation 的第一周最关键。不要只看它有没有按时运行，要看它是否真的减少了人的负担。

可以用下面这份日志记录前三次运行：

```md
# Automation First Week Log

Automation:
Schedule:
Owner:

## Run 1

Useful findings:
Noise:
Missed issues:
Action taken:
Prompt change needed:

## Run 2

Useful findings:
Noise:
Missed issues:
Action taken:
Prompt change needed:

## Run 3

Useful findings:
Noise:
Missed issues:
Action taken:
Prompt change needed:

## Decision

Keep / reduce frequency / rewrite prompt / pause
```

第一周最常见的发现不是"Codex 不会做"，而是 prompt 太宽。比如：

```text
每天检查项目有没有问题。
```

它会导致输出像泛泛体检。改成：

```text
每天上午 9 点只读检查 docs 目录和最近 24 小时的代码 diff。

只报告：
1. 文档明显误导用户的地方。
2. README 命令和 package scripts 不一致的地方。
3. 新增配置没有文档说明的地方。

最多输出 5 条。
如果没有发现，自动归档，不要输出鼓励性总结。
```

如果第一周每次都有 10 条以上提醒，优先减范围，而不是加更多分类。

```text
请根据最近三次 automation 输出帮我收窄 prompt。

要求：
1. 保留真正需要本周处理的问题。
2. 删除重复提醒。
3. 限制每次最多输出 5 条。
4. 明确没有发现时自动归档。
5. 不修改 automation，只给新 prompt。
```

Automation 是后台同事，但不是不用管理的同事。第一周运营日志能让读者看到：创建任务只是开始，真正的价值来自观察、调参和停用。

## 29. Automation 降噪案例：把“每天提醒”改成“只报异常”

很多自动化刚开始会变成每日噪音。比如这个 prompt：

```text
每天检查 PR 评论并总结。
```

它每天都会说很多话，但不一定推动事情。先把目标改成异常检测：

```text
每个工作日上午 10 点检查当前项目相关 PR 评论。

只报告以下异常：
1. 有 reviewer 要求修改但 24 小时内没有回应。
2. 同一个问题被重复评论两次以上。
3. reviewer 要求补测试但当前 diff 没有测试文件变化。
4. PR 状态被阻塞但没有明确 owner。

如果没有异常，自动归档。
不要总结所有正常评论。
```

输出也要能行动：

```md
# PR Comment Follow-up

## Needs Action Today

- PR:
- Comment:
- Why it matters:
- Suggested next reply or local action:

## Can Wait

- ...

## No Action

Archived if empty.
```

如果需要连接 GitHub 或其他外部系统，prompt 还要写清只读边界：

```text
只读取 PR 评论和状态。
不要回复评论。
不要修改 issue、label、assignee。
不要创建分支。
```

这类降噪思路可以迁移到文档、CI、发布、依赖更新。不要让 Automation 成为“每天更勤奋地制造摘要”的机器；它应该只在值得人注意时出现。

## 30. Automation 与 Worktree：后台写入为什么要隔离

对于 Git 仓库，项目自动化可以在后台 worktree 中运行，这能减少它和你当前本地改动互相踩到的概率。但 worktree 不是免责牌。后台写入仍然需要边界。

适合 worktree 的自动化：

```text
- 更新生成索引。
- 小范围格式化文档。
- 修复 docs drift。
- 准备 changelog 草稿。
```

不适合无人值守写入：

```text
- 修改认证、支付、权限代码。
- 改数据库迁移。
- 更新生产配置。
- 大范围重构。
- 自动 commit/push。
```

一个低风险 worktree prompt：

```text
每周五下午检查 docs 目录中的链接和导航索引。

允许：
- 在后台 worktree 中修改 docs index。
- 只改 markdown 导航和明显失效的内部链接。
- 输出改动摘要。

不允许：
- 修改代码文件。
- 提交、推送或发布。
- 调用外部写入。

完成后把结果放入 Triage，等待人工 Review。
```

如果这个任务第一次运行，不要直接允许写入。先跑只读版本：

```text
本周先只读检查 docs index。
输出建议修改列表，不要写文件。
下周再决定是否允许 worktree 写入。
```

Automation 的成熟路线通常是：只读报告 -> 半自动草稿 -> worktree 小范围写入 -> 人工 Review 后合并。不要从第一天就跳到最后一步。

## 31. Automation 停用案例：好自动化也会过期

自动化不是越多越成熟。项目阶段变了、团队流程变了、插件权限变了，原来有用的 automation 也可能变成噪音或风险。

停用信号：

```text
- 连续三次没有可行动输出。
- 输出需要人工解释才能理解。
- 任务 owner 已经离开或不再处理。
- 依赖的外部系统权限变化。
- 它和新的 CI、PR 模板或团队流程重复。
- 它开始建议超出原范围的改动。
```

停用前先做只读复盘：

```text
请分析这个 automation 最近 5 次运行。

输出：
1. 产生了多少可行动结果。
2. 哪些结果被实际处理。
3. 哪些是重复噪音。
4. 是否仍然需要这个 schedule。
5. 建议保留、降频、改 prompt 还是停用。

不要修改 automation。
```

如果决定停用，写一条记录：

```md
# Automation Pause Note

Automation:
Paused on:
Owner:

## Why paused

- ...

## Replacement

- Manual checklist / CI job / different automation / no replacement

## When to revisit

- ...
```

如果只是降频：

```text
请把这个 automation 从每日检查改成每周检查。

同时收窄 prompt：
1. 只报告 blocking 问题。
2. 没有发现时自动归档。
3. 每次最多 5 条。
4. 不修改文件。
```

课程里讲停用，是为了让读者建立维护意识。后台任务不是“设好就放着”，它会消耗注意力、权限和信任。能创建，也要能暂停。

## 32. Automation 课堂练习：从提醒到流程

给学生一个坏自动化：

```text
每天提醒我关注项目进展。
```

要求改写成流程：

```text
每个工作日上午 9 点检查项目状态。

只读读取：
- Git 状态。
- 最近一次测试摘要。
- open PR 评论摘要。

只报告：
1. 阻塞今天工作的事项。
2. 需要我回复的评论。
3. 昨天失败但今天仍未处理的测试。

如果没有事项，自动归档。
不要输出普通鼓励、泛泛总结或项目新闻。
```

再要求学生写停用条件：

```text
停用条件：
- 连续 2 周没有 actionable 输出。
- 团队改用 PR dashboard。
- 输出中超过一半是重复提醒。
```

最后让 Codex 生成 triage 模板：

```md
# Daily Project Triage

## Blocking Today

...

## Needs Reply

...

## Still Failing

...

## No Action

Archive if all sections are empty.
```

这个练习把“提醒我”变成了“按条件报告异常”。这就是 Automation 课程应该训练的核心能力。

## 📝 总结与检查清单

完成本课后，请确认以下所有项：

- [ ] 理解Automation是后台/周期执行，不是一次性工具
- [ ] 能写清频率、目录、目标、权限、输出、停止条件
- [ ] 学习阶段优先只读任务（摘要、检查）
- [ ] 知道如何组合Skill和Automation
- [ ] 第一次运行后做了六维核对（时间/范围/输出/失败/副作用/暂停）
- [ ] 不让Automation自动提交、推送、删除或扩大权限

**全部勾选后即掌握 Codex Automations。**

---

## 附录

### A. 自动化能力对比

| 能力 | 触发方式 | 适合 |
|------|---------|------|
| Command | 手动输入 | 立即执行 |
| Skill | 用户点名 | 可复用流程 |
| Automation | 时间/后台事件 | 重复任务 |

### B. 推荐学习资源

- **Codex App Automations 官方文档**：https://developers.openai.com/codex/app/automations
- **本系列上一篇**：[CX-08 Subagents](./CX-08-Codex-Subagents多Agent协作完整指南.md)
- **本系列下一篇**：[CX-10 Review / GitHub / PR](./CX-10-Codex-Review-GitHub-PR完整指南.md)

---

**课程制作**：老金
**最后更新**：2026年6月18日
**许可**：本课程采用 MIT License；转载、复制或二次分发时必须保留版权声明与许可声明

---

## 下一步

下一篇：[CX-10 Review / GitHub / PR 工作流](./CX-10-Codex-Review-GitHub-PR完整指南.md)。