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-02 桌面工作流

📚 本课学习目标

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

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 管“什么时候醒来”，Skill 管“醒来后怎么做”，Rules / sandbox 管“能做多大动作”，Triage 管“结果在哪里看”。

0. Automations 的工作机制

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

一次 Automation 运行可以理解为：

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

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

0.1 Standalone 和 Thread automation 怎么选

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

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

一个耐久 prompt 要包含：

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

1. Automations 是什么

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

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

适合：

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

不适合：

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

2. App 中的创建方式

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

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

好的 Automation 需要说明：

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

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

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

3. Automations 的三类常见任务

学习阶段优先只读。

3.1 不同任务的合格输出

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

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

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

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

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

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

5. 与 Skills 组合

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

例子：

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

好处：

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

6. 与 Commands 的区别

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

7. 安全基线

所有自动化都要避免：

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

8. 运行后核对

第一次运行后必须检查：

8.1 失败时怎么收敛

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

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

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

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

8.2 自动化失败模式

8.3 Triage 处理方法

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

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

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

9. 与 GitHub Action / CI 的区别

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

10. 设计模板

10.1 只读摘要任务

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

10.2 测试守护任务

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

10.3 文档漂移任务

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

10.4 小范围自动修复任务

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

10.5 PR 跟进任务

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

10.6 Skill 驱动任务

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

12. 自动化运营手册

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

12.1 上线前

12.2 上线后第一周

12.3 每月维护

每月看一次：

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

12.4 自动化分级

学习阶段停在 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 自己每天把事情做完”。更准确的理解是：它是一个会按时间醒来的后台同事。它可以提醒、检查、汇总、提出修复建议，也可以在受控范围内改文件，但它不应该替代人的发布判断。

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

13.1 常见自动化形态

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

14. Standalone 与 Thread Automation 的深层区别

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

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

适合正在进行的任务：

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

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

14.2 Standalone Automation：每次独立运行

适合周期性检查：

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

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

14.3 Project Automation：绑定项目目录

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

每周一检查 docs/ 目录是否可能过期。
读取 README、docs/、package.json 和最近一周的 commit 信息。
输出：
- 可能过期的文档段落
- 对应的代码或配置变化
- 建议更新的文件
 
默认只报告。如果你认为可以自动修复，只给出补丁建议，不直接写入。

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

15. 自动化 prompt 的耐久写法

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

15.1 差 prompt

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

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

15.2 好 prompt

每天上午 9 点检查当前项目的测试健康状态。
 
范围：
- 读取 package.json、测试配置和最近一次可用测试输出。
- 如果没有测试输出，说明缺少哪条命令，而不是猜测。
 
行为：
- 不修改文件。
- 不运行耗时超过 10 分钟的命令。
- 不访问项目外目录。
 
输出：
- 如果有问题，写成 Triage 摘要。
- 如果没有问题，说明检查了哪些来源，然后归档。

15.3 耐久 prompt 的五个要素

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

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

16.1 读 Triage 的顺序

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

16.2 Triage 分类表

16.3 Triage 二次追问 prompt

请基于这次 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 清理习惯

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

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

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

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

18.1 什么时候加 Skill

18.2 自动化调用 Skill

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

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

18.3 Skill 里的自动化说明

---
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 是后台运行，所以权限要比普通交互线程更保守。

19.1 自动化安全 prompt

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

19.2 自动写入时的边界 prompt

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

19.3 外部系统写操作

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

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

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

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

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

20.1 第一天

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

20.2 第三天

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

20.3 第七天

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

20.4 噪音削减 prompt

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

21. 自动化案例库

21.1 依赖更新观察

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

21.2 PR 评论跟进

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

21.3 文档链接巡检

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

21.4 发布前提醒

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

21.5 本地开发服务器观察

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

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

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

22.1 任务目标

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

22.2 先手动跑 prompt

请只读检查当前项目的文档漂移。
范围：
- README
- docs/
- package.json
- 最近的相关代码变更
 
输出：
- 明确不一致
- 可能过期
- 需要人工确认
 
不要修改文件。

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

22.3 创建自动化 prompt

每周一上午 9 点检查当前项目的文档漂移。
 
范围：
- README
- docs/
- package metadata
- 最近一周与文档相关的 commit
 
行为：
- 默认只读
- 不修改文件
- 不提交
- 不推送
- 如果没有发现，自动归档
 
输出：
- 文档路径
- 可疑陈述
- 代码或配置证据
- 建议下一步

22.4 第一周观察

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

22.5 Triage 处理

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

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

23.1 适用场景

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

23.2 Prompt

每个工作日下午 5 点检查当前项目关联 PR 的新评论。
 
使用可用 GitHub 连接能力只读读取：
- reviewer comments
- unresolved conversations
- CI status summary if available
 
不要：
- 回复评论
- 修改 PR 标题
- 打 label
- push 代码
- 关闭 issue
 
输出：
- 新评论
- 需要我回复的问题
- 可以本地修复的问题
- 阻塞合并的问题

23.3 后续处理

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

24. Automation 设计题

24.1 题目 A

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

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

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

24.2 题目 B

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

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

24.3 题目 C

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

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

25. Automation 进阶常见问题

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

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

Q2：Automation 能不能跑测试？

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

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

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

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

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

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

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

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

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

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

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

这会产生三个麻烦：

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

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

每周一上午检查 docs 目录是否与当前代码和配置明显不一致。
 
只读执行：
1. 读取 docs 目录、package scripts、配置文件和最近一周的 diff。
2. 找出会误导新人的文档漂移。
3. 输出 3 类结果：本周必须修、可以排期、暂不处理。
4. 每条结果都附文件路径和原因。
 
不要：
- 修改文件。
- 创建分支。
- 调用外部系统。
- 输出超过 10 条问题。

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

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

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

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

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

# Automation Design
 
## Goal
 
...
 
## Schedule
 
...
 
## Sources
 
...
 
## Allowed Actions
 
...
 
## Not Allowed
 
...
 
## Triage Output
 
...
 
## Archive Condition
 
...

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

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

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

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

# 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 太宽。比如：

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

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

每天上午 9 点只读检查 docs 目录和最近 24 小时的代码 diff。
 
只报告：
1. 文档明显误导用户的地方。
2. README 命令和 package scripts 不一致的地方。
3. 新增配置没有文档说明的地方。
 
最多输出 5 条。
如果没有发现，自动归档，不要输出鼓励性总结。

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

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

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

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

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

每天检查 PR 评论并总结。

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

每个工作日上午 10 点检查当前项目相关 PR 评论。
 
只报告以下异常：
1. 有 reviewer 要求修改但 24 小时内没有回应。
2. 同一个问题被重复评论两次以上。
3. reviewer 要求补测试但当前 diff 没有测试文件变化。
4. PR 状态被阻塞但没有明确 owner。
 
如果没有异常，自动归档。
不要总结所有正常评论。

输出也要能行动：

# 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 还要写清只读边界：

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

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

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

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

适合 worktree 的自动化：

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

不适合无人值守写入：

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

一个低风险 worktree prompt：

每周五下午检查 docs 目录中的链接和导航索引。
 
允许：
- 在后台 worktree 中修改 docs index。
- 只改 markdown 导航和明显失效的内部链接。
- 输出改动摘要。
 
不允许：
- 修改代码文件。
- 提交、推送或发布。
- 调用外部写入。
 
完成后把结果放入 Triage，等待人工 Review。

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

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

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

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

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

停用信号：

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

停用前先做只读复盘：

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

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

# Automation Pause Note
 
Automation:
Paused on:
Owner:
 
## Why paused
 
- ...
 
## Replacement
 
- Manual checklist / CI job / different automation / no replacement
 
## When to revisit
 
- ...

如果只是降频：

请把这个 automation 从每日检查改成每周检查。
 
同时收窄 prompt：
1. 只报告 blocking 问题。
2. 没有发现时自动归档。
3. 每次最多 5 条。
4. 不修改文件。

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

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

给学生一个坏自动化：

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

要求改写成流程：

每个工作日上午 9 点检查项目状态。
 
只读读取：
- Git 状态。
- 最近一次测试摘要。
- open PR 评论摘要。
 
只报告：
1. 阻塞今天工作的事项。
2. 需要我回复的评论。
3. 昨天失败但今天仍未处理的测试。
 
如果没有事项，自动归档。
不要输出普通鼓励、泛泛总结或项目新闻。

再要求学生写停用条件：

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

最后让 Codex 生成 triage 模板：

# 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. 自动化能力对比

B. 推荐学习资源

• Codex App Automations 官方文档：https://developers.openai.com/codex/app/automations
• 本系列上一篇：CX-08 Subagents
• 本系列下一篇：CX-10 Review / GitHub / PR

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

下一步

下一篇：CX-10 Review / GitHub / PR 工作流。