ChatGPT 定时任务与 webhook 自动化实战：从定时提醒到事件驱动

定时任务（Scheduled tasks）支持 webhook 触发了。本文讲清基础排程与事件驱动的差异、三类事件源的接法、Free/Go/Plus/Pro 的限额差异，以及上线前的事件源预检命令。

TL;DR

ChatGPT 定时任务（Scheduled tasks）在 2026-08-25 起支持 webhook 触发：Gmail 新邮件、Slack 频道新消息、GitHub PR 动态都能自动启动任务，从'定时轮询'升级为'事件驱动'。Plus / Pro 可创建 webhook 任务；任务可分享（Free / Go / Plus / Pro），接收者能自定义并生成独立副本；Free 档最多 3 个活跃任务、每天最多 1 次，Free / Go 不能创建 webhook 任务。本文给出创建、触发、预检与限额管理的完整实战路径。

ChatGPT 定时任务（Scheduled tasks）是 ChatGPT 内的自动化能力：用自然语言定义一个任务，让它按时间计划运行，或在 2026-08-25 之后由 Gmail / Slack / GitHub 的 webhook 事件自动触发，结果在 ChatGPT 内查看。

操作步骤

明确任务性质并选触发方式
固定节奏（每日简报）用时间计划；事件响应（PR 汇报、邮件摘要）用 webhook。webhook 任务需要 Plus / Pro。
预检事件源
用命令行验证事件真的会发生：GitHub 用 REST API 查 PR 列表，Slack 用测试 webhook 发一条消息。事件源没通，任务建好也不会触发。
在 ChatGPT Work 里连接应用并建任务
ChatGPT Work 中连接 Gmail / Slack / GitHub，选择监听对象（发件人、频道、仓库），用自然语言写清任务指令与输出格式。
跑一次验证输出
手动制造一个事件（提一个测试 PR、发一条测试消息），确认任务触发且输出符合预期；不符合就改指令再跑。
分享给团队并管理限额
需要协作的任务用分享链接发给队友（他们可自定义并生成独立副本）；Free 档注意 3 个活跃任务上限，优先留给最有价值的任务。

ChatGPT 定时任务（Scheduled tasks）是 ChatGPT 内的自动化能力：用自然语言定义一个任务，让它按时间计划运行，或在 2026-08-25 之后由 Gmail、Slack、GitHub 的 webhook 事件自动触发。这篇文章讲清两代触发方式的差异、三类事件源的接法、各档位的限额，以及上线前的事件源预检——把"建了任务从不触发"这个最常见的问题挡在前面。

说明：本文的功能事实（事件类型、限额、分享规则）逐条核对自 ChatGPT 官方 Release Notes（文档核对版）；事件源预检命令来自 GitHub 与 Slack 官方文档。

1. 两种触发方式：时间计划 vs webhook

维度	时间计划任务	webhook 触发任务
触发逻辑	到点就跑（一次性或周期）	事件发生才跑
思路	cron 式轮询	事件驱动
适合场景	每日简报、每周总结、定期提醒	PR 汇报、邮件摘要、频道监控
可创建档位	Free / Go / Plus / Pro	Plus / Pro
事件源	无（按时间）	Gmail 新邮件 / Slack 频道消息 / GitHub PR 动态

选择标准一句话：固定节奏用时间计划，事件响应用 webhook。"每天早上 9 点给我日报"是时间计划；"我们仓库一有 PR 更新就汇总状态"是 webhook。

2. 限额与档位：建任务前先看这张表

能力	Free	Go	Plus	Pro
创建时间计划任务	✅	✅	✅	✅
活跃任务上限	3 个	以产品内显示为准	以产品内显示为准	以产品内显示为准
运行频率上限	每任务每天 1 次	以产品内显示为准	以产品内显示为准	以产品内显示为准
创建 webhook 任务	❌	❌	✅	✅
分享任务 / 接收分享	✅	✅	✅	✅

经验值说明：官方文档明确了 Free 档"最多 3 个活跃任务、每天最多 1 次"与"Free / Go 不能创建 webhook 任务"；Go / Plus / Pro 的具体上限官方未给数字，以 ChatGPT 内实际显示为准。如果你在 Free 档，把 3 个名额留给最有价值的任务，事件驱动类需求考虑升 Plus。

3. 上线前先做事件源预检

"建了任务从不触发"的头号原因，是事件源本身没通。webhook 任务的链路是"外部事件 → ChatGPT Work → 任务运行"，中间任何一环断了都表现为"静默不触发"。所以先在命令行里把两端验证通。

验证 GitHub PR 事件源（确认仓库里有你监听的对象，API 可访问）：

curl -s "https://api.github.com/repos/OWNER/REPO/pulls?state=open&per_page=5" | jq '.[].title'

能列出开放 PR 的标题，说明仓库与访问没问题。把这个 URL 里的 OWNER/REPO 换成任务要监听的仓库，先肉眼确认目标仓库确实存在 PR 活动。

查单个 PR 的关键字段（把 PR 编号纳入预检，确认监听对象具体可见）：

curl -s "https://api.github.com/repos/OWNER/REPO/pulls/123" | jq '{title, state, author: .user.login}'

验证 Slack 出站 webhook（确认你的 workspace 允许 webhook 收发消息）：

curl -X POST -H 'Content-type: application/json' \
  --data '{"text":"ChatGPT task webhook pre-check"}' \
  https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXX

换成你自己 incoming webhook 的地址，收到 "ChatGPT task webhook pre-check" 消息即说明链路通。Slack 侧测试通过，再回 ChatGPT 里连应用。

两段命令都来自 GitHub 与 Slack 官方文档，属于通用预检手段——它们验证的是"事件源这头是通的"，ChatGPT 侧的连接状态以 ChatGPT Work 内的应用授权为准。

4. 创建任务：指令写法决定输出质量

在 ChatGPT Work 里连接应用后，用自然语言写任务指令。三个让输出稳定的写法：

说清输出结构："汇总每个 PR 的标题、作者、当前状态，用表格返回"——和结构化思维一样，任务指令里越具体越稳。
说清范围与频率：webhook 任务明确"只看 open 状态的 PR""只汇总今天的邮件"；时间计划任务明确"工作日每天早上 9 点"。
说清收到结果后做什么：仅汇报，还是要给出建议——不写清楚，模型每次的收尾行为会漂。

5. 分享与协作

任务建好不是终点。官方的分享机制：Free / Go / Plus / Pro 都能把任务通过链接分享出去，接收者可以查看并自定义任务指令、连接自己的应用，并生成一份独立副本——你的原任务不受影响。注意一条限制：运行共享的 webhook 触发任务需要对应的 Work 访问权限，把 webhook 任务分享给 Free 档同事前先确认他们的档位。

6. 常见问题与排查

现象	可能原因	处理
webhook 任务从不触发	事件源没通 / 监听对象选错	回到第 3 节做预检；核对仓库、频道、发件人范围
任务触发了但输出没用	指令太泛	按第 4 节补结构、范围、收尾动作
Free 档建不了 webhook 任务	档位限制	升 Plus / Pro，或用时间计划任务近似替代
活跃任务建不进去	Free 档 3 个上限	删除或合并低价值任务腾名额
共享任务对方跑不了	webhook 任务需要 Work 权限	确认接收者档位与 Work 访问权限