定时任务会在没人盯着的时候运行。设计时先写一次完整的人工流程，确认输入能取得、输出能检查、失败能停住，再把它交给后台调度。
先写清每次运行的契约
任务提示要说明检查范围、时间窗口、数据来源、输出位置和无变化时的处理。重复运行不能重复发消息、重复建单或重复写同一记录。可以用稳定 ID、已处理时间戳或外部状态判断本轮应当创建、更新还是跳过。
再定义停止条件。遇到鉴权失效、来源结构变化、连续失败、写入冲突或需要人作判断时，任务应暂停并报告证据。成功回执也要包含本轮时间、读取范围、写入数量和可打开的结果链接。
选择运行位置和隔离方式
桌面端定时任务可以使用本地项目，并在项目目录或独立 Git worktree 中运行。需要本地文件时，电脑要保持开机，桌面应用也要运行。Web 端任务可以用上传内容和连接工具，无法直接进入电脑上的本地文件夹。CLI 与 IDE 当前不提供 Scheduled 管理界面，可以先用它们测试脚本或提示，再到 Web 或桌面端创建任务。
Git 仓库里的写入任务优先用独立 worktree，避免碰到正在开发的文件。只读报告可以使用项目目录，但仍要限制扫描范围。运行位置、客户端能力和可用计划会变化，实际以当前 Scheduled 界面为准。
先人工跑，再逐步放开
官方建议先在普通聊天中测试提示。检查模型、推理强度、技能和工具能否按预期工作，随后创建较低频的计划，观察前几次输出。稳定以后再调整周期。定时任务会继承默认沙箱设置，所需文件和网络权限应保持在最小范围。
独立任务每次从保存的提示启动，适合彼此无关的日报或巡检。聊天内定时任务会回到原聊天并保留上下文，适合跟进同一个部署、PR 或研究过程。任务可以使用技能和插件，但具体插件、连接器与写入动作受 ChatGPT 计划、工作区设置、管理员政策和外部账号权限影响。
专门测试第二次运行
人工测试通过以后，用完全相同的输入再跑一次。第二次应当跳过已处理对象，或更新同一条结果。它若再次发消息、创建文件或提交相同改动，去重规则还没有生效。再模拟两次运行重叠，检查是否会争用同一文件、重复占用锁或互相覆盖状态。
来源暂时没有新内容时，任务应返回简短的无变化回执。来源不可访问时，回执要包含错误类别和下次动作，不能把空结果当成成功。连续失败达到约定次数以后暂停，避免频繁重试扩大限流、费用或数据损坏。
涉及 Git 写入时，每轮先确认基础分支和工作树，提交只包含本轮改动。自动推送、开 PR 或发布会扩大外部影响，需要在任务里单独授权并设置明确目标。
每隔一段时间复查一次运行记录。确认来源仍有效，输出仍有人使用，失败告警能送达，旧 worktree 和运行记录按制度清理。长期自动化靠清楚的边界和回执维持，不靠更高频率。