For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
主导航

建议

工作流

能力

参考资料

API Dashboard
试用 ChatGPT

计划任务

在 ChatGPT 中按计划运行任务，或通过受支持的应用事件触发任务

设置在后台定期运行的任务。在 ChatGPT 网页版和移动版中， 符合条件的套餐还支持通过受支持的应用事件触发任务。在 计划任务中查看已启用、 已暂停和已完成的任务以及最近的运行记录。您可以将 计划任务与技能结合使用，处理更复杂的工作。

GPT-5.5 将于 2026 年 10 月 14 日在所有套餐的 ChatGPT、ChatGPT Work 和 Codex 中退役。 请检查使用 GPT-5.5 的计划任务，并在该日期之前 选择可用的替代模型。对于通过 ChatGPT 登录使用的 Codex， 请将 gpt-5.5 替换为 gpt-5.6-sol（GPT-5.6 Sol）。OpenAI API 不受影响。请参阅GPT-5.5 退役。

在 ChatGPT 桌面应用中，计划任务可以处理本地项目，并在项目目录或隔离的工作树中运行。当计划任务需要使用本地文件时，请保持计算机开机并让应用持续运行。

例如，您可以设置计划任务来评估遥测错误并提交修复， 或生成有关代码库近期更改的报告。对于需要 持续沿用同一上下文的工作，请在现有聊天中设置计划任务。

对于限定于项目范围的计划任务，请保持计算机开机并让 ChatGPT 桌面应用持续运行。在任务的计划运行时间，所选项目必须仍在磁盘上且可访问。

在 Git 代码仓库中，您可以选择让计划任务在本地项目 或新的工作树中运行。这两种方式都在 后台运行。工作树可以将计划任务的更改与尚未完成的本地工作隔离， 而在本地项目中运行任务则可能修改您仍在 处理的文件。在未使用版本控制的项目中，计划任务会直接在 项目目录中运行。

您也可以保留模型和推理强度的默认设置；如果希望更精细地控制计划任务的运行方式，可以自行指定这些设置。

如果计划任务通过 ChatGPT 登录使用 gpt-5.4 或 gpt-5.4-mini， 请在这些模型于 2026 年 8 月 31 日退役之前更新任务。请将 gpt-5.4 替换为 gpt-5.6-terra，并将 gpt-5.4-mini 替换为 gpt-5.6-luna。

计划任务使用您的默认沙盒设置，在无人值守的情况下运行。请先授予 足以完成任务的最小访问权限，仅在必要时授予网络或更广泛的文件 访问权限。了解沙盒。

管理计划任务

在 ChatGPT 桌面应用侧边栏的 计划任务 中， 查看所有计划任务及其运行记录。

计划任务 视图相当于您的收件箱。有发现结果的计划任务运行记录 会显示在这里；当某次运行需要您关注时，会出现未读标记。

独立的计划任务会在每次计划运行时新建聊天， 并在 计划任务中报告结果。如果每次运行都应相互独立，或一个 计划任务需要在一个或多个项目中运行，请使用这种任务。如果需要自定义 运行频率，请使用自定义计划控件。对于更复杂的计划，可以编辑其 RFC 5545 重复规则（RRULE），例如 RRULE:FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=9;BYMINUTE=0。

对于 Git 代码仓库，每个计划任务都可以在本地项目中运行，或 在专用的后台工作树中运行。 如果您希望将计划任务的更改与尚未完成的本地工作隔离， 请使用工作树。如果您希望计划任务直接在主检出目录中运行，请使用本地模式， 但请注意，任务可能会更改您正在编辑的文件。 在未使用版本控制的项目中，计划任务会直接在项目目录中运行。 您可以让同一个计划任务在多个项目中运行。

通过网页版 ChatGPT Work，或桌面应用中的 ChatGPT Work 或 Codex 创建的计划任务可以使用插件。计划任务也可以使用技能。 为了让计划任务易于维护并可在团队间共享，请使用 技能来定义操作并提供工具和上下文。 如果工作流程不应依赖自动工具选择，请在任务提示中 选择或调用特定技能。

让 ChatGPT 创建或更新计划任务

您可以在 ChatGPT 或 Codex 聊天中创建和更新计划任务。请描述要完成的工作、运行时间，以及每次运行是应返回当前聊天还是新建聊天。ChatGPT 可以起草提示、选择合适的聊天位置，并在任务范围或运行频率发生变化时更新任务。

例如，您可以在等待部署完成时，让 ChatGPT 在当前聊天中安排后续跟进；也可以让它创建独立的计划任务，定期检查项目。

技能也可以创建或更新计划任务。例如，用于持续跟进 Pull Request 的技能可以设置计划任务，通过 GitHub 插件检查 PR 状态，并根据新的审查反馈进行修复。

在聊天中设置计划任务

如果您希望 ChatGPT 按计划返回某个现有聊天，请在该聊天中设置计划任务。任务会使用聊天的现有上下文，而不是每次都从新的提示开始。

聊天中的计划任务可以按分钟间隔运行，持续跟进工作；如果需要在特定时间检查进展，也可以设置每日或每周运行。

在聊天中设置计划任务可用于：

  • 检查长时间运行的操作，直到其完成
  • 当您需要定期获取快照，而不是响应某个受支持的应用事件时，按固定频率检查已连接的数据源
  • 提醒 ChatGPT 按固定频率继续执行审查循环
  • 运行由技能驱动且使用插件的工作流程，例如检查 PR 状态并处理新的反馈
  • 继续进行中的研究或问题分诊聊天，同时保留其上下文

如果每次运行都应相互独立，或 发现结果应在 计划任务中作为单独运行显示，请使用独立的计划任务。

在聊天中设置计划任务时，请确保提示能够长期适用。提示应说明 ChatGPT 在每次计划运行时应执行什么操作、如何判断是否有重要内容需要报告，以及何时应停止或向您征求意见。

测试计划任务

设置计划任务前，请先在常规聊天中手动测试提示。这有助于您确认：

  • 提示清晰，范围恰当。
  • 所选或默认的模型、推理强度和工具的表现符合预期。
  • 生成的输出可供审查。

开始按计划运行后，请检查前几次输出，并根据需要调整提示或运行频率。

在 ChatGPT 桌面应用中，您可以在计划任务的提示中 使用 $skill-name 来明确触发某项技能。

清理计划任务的工作树

如果您为 Git 代码仓库选择使用工作树，频繁运行计划任务可能会逐渐产生大量工作树。请归档不再需要的计划运行记录；除非打算保留其工作树，否则请避免置顶运行记录。

权限与安全模型

计划任务在无人值守的情况下运行，并使用您的默认沙盒设置。

有关这些边界的通俗说明，请参阅 沙盒概览。有关文件系统和网络 规则，请参阅权限。

  • 如果您的沙盒模式为 只读，需要 修改文件、访问网络或操作您计算机上的应用的工具调用都会失败。 您可以考虑将沙盒设置更改为工作空间可写。
  • 如果您的沙盒模式为 workspace-write，需要 修改工作空间以外的文件、访问网络或操作您计算机上的应用的 工具调用都会失败。您可以使用规则，有选择地将命令加入允许列表， 以便在沙盒外运行这些命令。
  • 如果您的沙盒模式为 完全访问权限，后台计划任务会带来 较高风险，因为 ChatGPT 可能会在不询问您的情况下 修改文件、运行命令和访问网络。您可以考虑将沙盒设置更改为工作空间可写，并 使用规则，有选择地指定智能体 可以在完全访问权限下运行哪些命令。

如果您处于受管理的环境中，管理员可以通过 强制要求来限制这些行为。例如，他们可以禁止使用 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

结合计划任务与技能，修复您自己引入的错误

创建一个名为 $recent-code-bugfix 的新技能，用于尝试修复您自己的提交所引入的错误，并将其保存在您的个人技能中。

---
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.