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.