自动化任务
定时任务
在 ChatGPT 中安排定期运行的任务
ChatGPT 桌面应用
安排定期任务在后台运行。在 ChatGPT 网页版和移动端， 符合条件的套餐还可以通过受支持的应用事件触发任务。在定时任务 中查看运行中、 已暂停和已完成的任务，以及最近的运行记录。你可以将 定时任务与技能结合，处理更复杂的工作。
GPT-5.5 将于 2026 年 10 月 14 日在所有套餐的 ChatGPT、ChatGPT Work 和 Codex 中
停用。请检查使用 GPT-5.5 的定时任务，并在该日期之前选择
可用的替代模型。对于使用 ChatGPT 登录的 Codex，如果
你的套餐和工作区提供访问权限，请选择 gpt-6-sol（GPT-6 Sol）。OpenAI API 不受
影响。有关各套餐的替代模型，请参阅 GPT-5.5 停用
说明。
在 ChatGPT 桌面应用中，定时任务可以处理本地项目， 并在项目目录或隔离的工作树中运行。当定时任务需要使用本地文件时， 请保持计算机开机且应用持续运行。
为你的工作区启用定时任务后，你可以在网页版 Chat 或 ChatGPT Work 中创建任务，并从 Scheduled 管理其运行记录。Web 任务 可以使用上传的上下文和已连接工具，但无法直接处理 计算机上的文件夹。
Codex CLI 不提供 Scheduled 管理界面。请使用网页版 ChatGPT 或桌面应用创建和管理定时任务。你可以先使用 CLI 准备和测试提示词、技能或脚本。
IDE 扩展不提供 Scheduled 管理界面。请使用 网页版 ChatGPT 或桌面应用创建和管理定时任务。你可以先使用 IDE 扩展准备和测试提示词、技能或工作区更改。
在网页上管理定时任务
打开 Scheduled，查看任务状态和最近的运行记录。如果每次运行都应从 保存的提示词开始，请使用独立定时任务。如果你希望 ChatGPT 带着现有 上下文返回同一对话，请使用对话中的定时任务。
网页上的定时任务可以使用该对话可用的已上传文件、已连接工具、技能和 插件。它们不会在多次运行之间持续保留本地文件夹或 工作树。请将长期有效的说明放在任务提示词或附加技能中， 并将所需源材料保存在可访问的项目、上传内容或已连接服务中。
安排任务前，请先在普通 Web 对话中测试其提示词。 查看前几次运行的结果；如果结果范围过大或需要更多上下文， 请调整提示词、工具或运行频率。
通过应用事件触发任务
在符合条件的套餐中，当支持的 Gmail、Slack 或 GitHub 事件发生时，定时任务便可运行。事件触发的任务可在网页版和移动版 ChatGPT 中使用，但无法在 ChatGPT 桌面应用、Codex CLI 或 IDE 扩展中使用。
让 ChatGPT 创建任务，然后说明要监测的事件以及事件发生时 要执行的操作。触发器决定任务何时运行；保存的提示词决定每次运行要执行的操作。一个任务可以使用多个事件触发器， 但不能同时使用事件触发器和基于时间的计划。
支持的事件触发器包括：
- Gmail： 新收到的邮件，可选择按发件人或主题筛选。
- Slack： 所选频道中的新消息，可选择按作者筛选， 并决定是否包括帖子回复。不支持表情回应、编辑、删除和 私信。
- GitHub： 仓库中的 PR 活动。可按 PR、 作者、标题或标签筛选，并选择由评审、评论、提交更新 或仅合并来触发任务。
创建任务前，请先连接应用并完成授权。对于 Slack，请将
@ChatGPT 添加到任务监测的每个频道。对于 GitHub，已连接的应用
必须拥有该仓库的访问权限。
如果短时间内接连发生多个匹配事件，ChatGPT 可能会将它们合并到 一次运行中处理。打开 Scheduled 可查看待处理事件，或选择 Run now 立即处理。
可用性取决于你的套餐和工作区设置。在受管理的 工作区中，管理员可以通过 Allow event-triggered scheduled tasks 权限控制访问。
例如，可以安排任务评估遥测错误并提交修复， 或创建有关代码库近期更改的报告。对于应持续使用相同上下文的工作， 请在现有对话中安排任务。
对于项目范围的定时任务，请保持计算机开机且 ChatGPT 桌面应用持续运行。任务计划运行时，所选项目必须仍可在磁盘上访问。
在 Git 仓库中，你可以选择让定时任务在本地项目中运行， 或在新的工作树中运行。两种方式都会在后台运行。 工作树可将定时任务的更改与尚未完成的本地工作分隔开， 而在本地项目中运行则可能修改你仍在处理的文件。 在未使用版本控制的项目中，定时任务会直接在项目目录中运行。
你也可以让模型和推理强度保持默认设置，或 明确选择它们，以便更精细地控制定时任务的运行方式。
如果定时任务使用的模型已停用，请将其更新为可用的替代模型。 请参阅模型迁移指南。
定时任务会使用你的默认沙箱设置，在无人值守的情况下运行。请先授予 足以让任务成功执行的最小访问权限，仅在必要时授予网络访问权限或更广泛的文件 访问权限。了解沙箱机制。
管理定时任务
在 ChatGPT 桌面应用侧边栏的 Scheduled 中查找所有定时任务 及其运行记录。
定时任务 视图相当于你的收件箱。有发现的定时任务运行记录 会显示在这里；当某次运行需要你关注时，未读标记会提醒你。
独立定时任务每次按计划运行时都会开启新聊天，并在
定时任务 中报告结果。如果每次运行都应相互独立，或某个
定时任务需要在一个或多个项目中运行，可使用独立定时任务。如果需要自定义
运行频率，请使用自定义计划控件。如需设置高级计划，请编辑其
RFC 5545 重复规则（RRULE），例如
RRULE:FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=9;BYMINUTE=0。
对于 Git 仓库，每个定时任务既可以在本地项目中运行， 也可以在专用的后台工作树中运行。如果你希望将定时任务的更改与未完成的本地 工作隔离，请使用工作树。如果你希望定时任务直接处理主 检出目录，请使用本地模式，但请注意，它可能会更改你正在编辑的文件。 在未使用版本控制的项目中，定时任务会直接在项目 目录中运行。你可以让同一定时任务在多个项目中运行。
通过网页版 ChatGPT Work，或桌面应用中的 ChatGPT Work 或 Codex 创建的定时任务可以使用插件。定时任务也可以使用技能。 为了让定时任务易于维护并可在团队间分享，请使用 技能定义操作并提供工具和上下文。 如果工作流不应依赖自动工具选择，请在任务提示词中选择或调用特定技能。
让 ChatGPT 创建或更新定时任务
你可以在 ChatGPT 或 Codex 聊天中创建和更新定时任务。 说明要完成的工作、运行时间，以及每次运行应返回 当前聊天还是开启新聊天。ChatGPT 可以起草提示词、选择 合适的结果发送位置，并在任务范围或运行频率 变化时更新任务。
例如，让 ChatGPT 在等待部署完成时安排当前对话中的后续检查， 或让它创建一个按照固定频率检查项目的独立定时任务。
技能也可以创建或更新定时任务。例如，用于 持续跟进 PR 的技能可以设置一个定时任务，通过 GitHub 插件检查 PR 状态并修复新的评审反馈。
在对话中安排任务
如果你希望 ChatGPT 按计划返回现有对话，请在该对话中安排任务。 定时任务会使用对话的现有上下文，而不是 每次都从新提示词开始。
对话中的定时任务可以使用以分钟为单位的间隔执行主动跟进 循环，也可以在需要特定时间检查时采用每日或每周计划。
适合在对话中安排任务的场景包括：
- 持续检查长时间运行的操作，直至完成
- 当你需要定期快照，而不是响应某个受支持的应用事件时， 按固定频率检查已连接的数据源
- 提醒 ChatGPT 按固定频率继续评审循环
- 运行使用插件的技能驱动型工作流，例如检查 PR 状态 并处理新反馈
- 在不丢失上下文的情况下继续进行中的研究或分流聊天
当每次运行应相互独立，或结果应作为单独的运行记录显示在 Scheduled 中时，请使用独立定时任务。
在对话中安排任务时，请确保提示词长期有效。提示词应说明 ChatGPT 每次计划运行时应做什么、如何判断是否有 重要内容需要报告，以及何时停止或请求你提供信息。
测试定时任务
安排任务前，请先在普通对话中手动测试提示词。 这有助于确认：
- 提示词清晰且范围正确。
- 所选或默认的模型、推理强度和工具符合预期。
- 生成的输出便于评审。
开始计划运行后，请查看前几次输出，并根据需要调整 提示词或运行频率。
在 ChatGPT 桌面应用中，你可以使用 $skill-name 在计划
任务提示词中明确触发技能。
清理定时任务的工作树
如果你为 Git 仓库选择使用工作树，频繁运行的计划可能会随时间推移创建 许多工作树。请归档不再需要的计划运行记录；除非你打算保留其工作树， 否则不要置顶这些运行记录。
权限和安全模型
定时任务会在无人值守的情况下使用你的默认沙箱设置运行。
有关这些边界的通俗说明，请参阅 沙箱机制概述。有关文件系统和网络 规则，请参阅权限。
- 如果沙箱模式为 read-only，需要修改文件、 访问网络或操作计算机上应用的工具调用会失败。 请考虑将沙箱设置更新为 workspace write。
- 如果沙箱模式为 workspace-write，需要修改工作区外文件、 访问网络或操作计算机上应用的工具调用会失败。你可以使用规则， 选择性地将命令加入允许在沙箱外运行的名单。
- 如果沙箱模式为 full access，后台定时任务的风险会 提高，因为 ChatGPT 可能会在不询问的情况下更改文件、运行命令和访问网络。 请考虑将沙箱设置更新为 workspace write，并 使用规则选择性定义智能体可以在 full access 下运行的命令。
如果你处于托管环境中，管理员可以使用管理员强制要求
限制这些行为。例如，他们可以禁止 approval_policy = "never"，或限制允许使用的沙箱模式。请参阅
管理员强制要求 (requirements.toml)。
当组织政策允许时，定时任务使用 approval_policy = "never"。
如果管理员要求不允许 approval_policy = "never"，
定时任务会回退到所选权限模式的审批行为。
示例
自动创建新技能
Scan all of the `~/.codex/sessions` files from the past day and if there have been any issues using particular skills, update the skills to be more helpful. Personal skills only, no repo skills.
If there’s anything we’ve been doing often and struggle with that we should save as a skill to speed up future work, let’s do it.
Definitely don't feel like you need to update any- only if there's a good reason!
Let me know if you make any.及时了解项目动态
Look at the latest remote origin/master or origin/main . Then produce an exec briefing for the last 24 hours of commits that touch <DIRECTORY>
Formatting + structure:
- Use rich Markdown (H1 workstream sections, italics for the subtitle, horizontal rules as needed).
- Preamble can read something like “Here’s the last 24h brief for <directory>:”
- Subtitle should read: “Narrative walkthrough with owners; grouped by workstream.”
- Group by workstream rather than listing each commit. Workstream titles should be H1.
- Write a short narrative per workstream that explains the changes in plain language.
- Use bullet points and bolding when it makes things more readable
- Feel free to make bullets per person, but bold their name
Content requirements:
- Include PR links inline (e.g., [#123](...)) without a “PRs:” label.
- Do NOT include commit hashes or a “Key commits” section.
- It’s fine if multiple PRs appear under one workstream, but avoid per‑commit bullet lists.
Scope rules:
- Only include changes within the current cwd (or main checkout equivalent)
- Only include the last 24h of commits.
- Use `gh` to fetch PR titles and descriptions if it helps.
Also feel free to pull PR reviews and comments将定时任务与技能结合，修复自己引入的 bug
创建一个新技能，通过创建新的 $recent-code-bugfix 来尝试修复你自己的提交所引入的 bug，并将其存储在你的个人技能中。
---
name: recent-code-bugfix
description: Find and fix a bug introduced by the current author within the last week in the current working directory. Use when a user wants a proactive bugfix from their recent changes, when the prompt is empty, or when asked to triage/fix issues caused by their recent commits. Root cause must map directly to the author’s own changes.
---
# Recent Code Bugfix
## Overview
Find a bug introduced by the current author in the last week, implement a fix, and verify it when possible. Operate in the current working directory, assume the code is local, and ensure the root cause is tied directly to the author’s own edits.
## Workflow
### 1) Establish the recent-change scope
Use Git to identify the author and changed files from the last week.
- Determine the author from `git config user.name`/`user.email`. If unavailable, use the current user’s name from the environment or ask once.
- Use `git log --since=1.week --author=<author>` to list recent commits and files. Focus on files touched by those commits.
- If the user’s prompt is empty, proceed directly with this default scope.
### 2) Find a concrete failure tied to recent changes
Prioritize defects that are directly attributable to the author’s edits.
- Look for recent failures (tests, lint, runtime errors) if logs or CI outputs are available locally.
- If no failures are provided, run the smallest relevant verification (single test, file-level lint, or targeted repro) that touches the edited files.
- Confirm the root cause is directly connected to the author’s changes, not unrelated legacy issues. If only unrelated failures are found, stop and report that no qualifying bug was detected.
### 3) Implement the fix
Make a minimal fix that aligns with project conventions.
- Update only the files needed to resolve the issue.
- Avoid adding extra defensive checks or unrelated refactors.
- Keep changes consistent with local style and tests.
### 4) Verify
Attempt verification when possible.
- Prefer the smallest validation step (targeted test, focused lint, or direct repro command).
- If verification cannot be run, state what would be run and why it wasn’t executed.
### 5) Report
Summarize the root cause, the fix, and the verification performed. Make it explicit how the root cause ties to the author’s recent changes.之后，创建新的定时任务：
Check my commits from the last 24h and submit a $recent-code-bugfix.