定時任務
定時任務
在 ChatGPT 中安排定期執行的任務
- ChatGPT 桌面應用 在桌面端處理專案、檔案和耗時較長的任務。
- ChatGPT 網頁版 在瀏覽器中使用聊天、專案和 Work。
- Codex CLI 在終端中使用 Codex。
- Codex IDE 擴充套件 在編輯器中使用 Codex。
安排定期任務在後臺執行。在 ChatGPT 網頁版和移動端， 符合條件的套餐還可以通過受支援的應用事件觸發任務。在定時任務 中檢視執行中、 已暫停和已完成的任務，以及最近的執行記錄。你可以將 定時任務與技能結合，處理更複雜的工作。
GPT-5.5 將於 2026 年 10 月 14 日太平洋夏令時間中午 12 點（19:00 UTC）
在通過 ChatGPT 登入的 Codex 中停用。請檢查 Codex 中使用 GPT-5.5 的定時任務；
如果你的套餐和工作區提供存取權限，請選擇 gpt-6.1-sol（GPT-6.1 Sol）。
OpenAI API 及使用 API key 認證的 Codex 會話不受影響。有關各套餐的替代模型，
請參閱 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.