开始使用Codex自动化：重复任务提示词与预约前检查

摘要： Codex自动化应在确定执行时间前，设计输入、结果、运行环境与防重复标准。先确认一次手动运行的结果，再预约同一工作，并检查最初几次结果与下次运行时间。重复检查也需要确定此前比较基准的保存位置，以及何时结束。

1. 从哪种重复业务开始

相比“帮我管理项目”，“读取README与docs中变化的执行命令，报告错误路径与文档差异并附上依据”更容易自动化，因为输入固定、结果可审阅。若包含代码修改，还应补充修改对象与验证条件。初次宜选择让人工决定下一行动的小型报告任务。

OpenAI官方定时任务文档说明，预约任务在网页与桌面应用中创建和管理，CLI与IDE没有相同的预约管理界面。使用本地文件的任务需要电脑开机且应用正在运行。网页任务可使用上传资料或连接工具，但不同于直接访问电脑的本地文件夹。

本文章使用作者编写的假想文档检查案例说明设置方法，并非实际登记预约或运行特定项目的体验记录。提示词中的路径与比较标准应按自己的项目替换，可用功能需在当前账户与工作区确认。

业务	自动化输入	可审查结果
检查文档变化	目标文档、比较提交与验证范围	变更摘要与错误候选的依据位置
总结近期提交	仓库、分支与准确期间	按主题整理的变化与相关提交
追踪CI状态	目标PR、运行标识符与可访问工具	新失败、完成或需要用户处理的状态
编写文档修改方案	需修改文件、允许变更与完成标准	修改文件与实际验证结果

如果让运行中的任务自行寻找并补齐空输入，可能读取其他项目或改变比较范围。应先写明项目、基准与报告位置。若工作需要连接服务，也应在手动运行中确认是否实际可访问。

2. 先完成一次运行

手动运行的目的不是检查提示词是否写得漂亮，而是确认能否读取必要资料并生成有用结果。下方示例的比较提交应填入实际存在的值。如果还留有方括号，应先完善输入再预约。

이 프로젝트의 문서 변경을 한 번 점검해 주세요.
프로젝트: [실제 프로젝트 경로]
비교: [실제 기준 커밋]부터 현재 HEAD까지
대상: README.md와 docs 폴더의 변경된 문서
확인: 실행 명령의 설명, 파일 경로, 문서끼리 다른 안내
출력: 비교 기준 / 변경 요약 / 문제 후보 / 근거 / 미확인 사항
명령을 실행하지 않고 읽어서 판단한 내용은 그렇게 표시해 주세요.
파일 수정과 외부 게시 없이 결과를 대화에 작성해 주세요.
변경이 없으면 확인한 비교 범위와 함께 변경 없음을 적어 주세요.

检查结果是否实际确认了基准提交与当前提交。“链接正常”也需区分是只读取链接字符串，还是确认实际响应。如果不允许访问外部链接，可能只检查了文档地址的格式。确定必要验证范围，可减少报告夸大。

首个结果冗长且模糊时，可先缩小输出。例如最多报告五个问题候选，每项要求“文件位置、原因、影响与确认方法”。目标文档太多时，可先检查安装与运行指南，而不是整个项目。增加运行频率无法解决输入不明确的问题。

3. 选择项目与运行环境

官方最佳实践介绍了桌面应用Scheduled中选择项目、提示词、周期与运行环境的流程。先确认登记项目是否指向实际工作文件夹。同名项目有多个时，宜同时检查路径与仓库。

选择项目决定“读取什么”，选择运行环境决定“在哪里执行”。即使同一仓库，工作中的本地文件夹与独立检出也可能有不同的依赖与本地资料。项目名也无法确定文档变更与什么比较，应在提示词中另行写明。

选择	适合情况	预约前确认事项
本地项目	需要当前文件夹资料与已安装工具	工作中文件与预约任务的修改范围
Git工作树	希望在独立空间审查修改结果	起始基准、必要依赖与配置文件
网页可访问资料	上传或连接服务的资料已经足够	原文是否最新、连接权限与结果保存位置

官方工作树文档说明，Git项目的预约任务可在独立工作树中运行，不使用Git的项目则在项目文件夹中运行。即使只审阅文档，也应确认比较对象实际存在于该环境，不能假设既有本地文件会全部自动复制。

本地环境文档中的setup script可用于准备新工作树的依赖。仅阅读文档的任务无需加入不必要安装。若需验证命令，应先确认新环境也准备了同一命令，以及能否使用安装所需网络。

4. 具体写明日程与时区

预约请求应写明时区，而不只有星期和时间。例如“每周一上午9点，按Asia/Seoul”，比“周一早上”更明确。跨国团队还应确定是按谁的工作开始时间。以下是登记示例，输入它并不意味着预约已完成。

방금 확인한 문서 점검을 반복 예약해 주세요.
작업 이름: [프로젝트명] 문서 변경 점검
일정: 매주 월요일 오전 9시, Asia/Seoul 기준
프로젝트: [현재 확인한 프로젝트와 경로]
실행 환경: [로컬 또는 Git worktree]
각 실행 결과는 독립된 검토 보고서로 남겨 주세요.
대상과 검증 범위는 확인한 프롬프트를 사용해 주세요.
새 문제, 해결, 접근 실패처럼 조치가 필요한 변화만 알려 주세요.
종료일: [예: 2026년 10월 30일 오후 6시, 한국 시간]
등록된 일정, 다음 실행 시각, 대상 프로젝트를 알려 주세요.

登记后，应将显示的下次运行时间与请求时区一并确认。如果使用此案例日期，第一个周一是2026年10月5日。若设定较晚开始日期或指定已过去的时间，下次运行日期可能不同。重要日程宜同时核对请求文字与实际保存的日程。

未确认电脑关机期间的任务如何处理时，不要假设会自动补跑。本地检查应选择可正常执行的时段；运行记录有遗漏区间时，应决定是否纳入下一次比较范围。错过期间与没有变化是不同状态。

5. 延续同一对话还是独立运行

官方文档区分延续既有对话上下文的预约，与从保存提示词开始的独立预约。追踪进行中的CI直到完成，使用同一对话较方便；单独保存每周报告，独立运行较方便。应在请求中明确方式与结果位置。

不能假设独立运行会自动记住旧报告或比较基准。如果需要先前状态，应指定可读取记录。即使使用同一对话，保留日期或提交作为比较基准，也更容易确认“上次以来”的含义。

假想文档检查可设计为：每次报告记录起始与结束提交，下次读取最后一次成功结束提交之后的变化。状态文件是作者建议的运营方式，并不表示Codex默认会生成该文件。

상태 기록: [프로젝트 안의 .automation/docs-audit-state.json]
기록 항목: 마지막 성공 비교 커밋, 확인 시각, 기존 문제의 식별 정보
기록이 없으면 지정한 초기 기준부터 비교하고 초기 실행이라고 표시하세요.
기록의 커밋을 찾을 수 없으면 임의로 기준을 바꾸지 말고 알려 주세요.
문서 점검이 성공한 뒤에만 마지막 성공 기준을 갱신하세요.
실패한 실행에서는 기존 기준을 유지하세요.
쓰기 허용 대상은 지정한 상태 파일뿐이며 문서 본문은 수정하지 마세요.

此方式需要状态文件写入权限。如果目标是完全只读报告，应使用可访问旧报告的基准，或改为每次比较固定期间。决定创建状态文件时，也宜规定保留哪些字段以及由谁修改。

6. 减少重复报告与重复工作

重复包括存在两个相同预约，以及一个预约反复将同一问题报告为新问题。查找前者时，应比较项目、目的与周期，而不只看任务名。变更日程应明确修改既有任务的意图，修改后确认只有一个活动预约。

기존 [프로젝트명] 문서 변경 점검 예약을 수정해 주세요.
같은 목적의 새 예약을 추가하지 마세요.
요일은 유지하고 시간을 오전 9시에서 오전 10시로 바꿔 주세요.
시간대, 프로젝트, 실행 환경, 기존 프롬프트는 유지해 주세요.
수정 후 활성 작업과 다음 실행 시각을 확인해 주세요.

问题重复可按“同一文件位置与同一原因”管理。如果文件名改变或行号移动就一律视为新问题，会产生重复提醒。如果没有用于比较旧问题的资料，应要求只记录本次发现的事实，不要声称已判断重复。

预约包含“修改文档”时，应先确认是否已有修改方案，避免重复创建相同修改。不同预约修改同一状态文件可能造成记录冲突，因此一个记录交给一个任务较简单。提示词中的禁止重复文字，无法保证文件锁定或并发任务冲突防护。

7. 确定失败、完成与结束条件

状态	报告内容	比较基准处理
检查成功，无变化	检查范围与时间	记录成功基准
新问题或旧问题解决	依据与相较先前状态的变化	记录成功基准与问题状态
资料访问失败	失败对象与所需行动	保留此前成功基准
比较提交不存在	未找到基准的事实	向用户请求新基准
达到结束日期或完成条件	最终状态与剩余问题	确认预约结束已生效

长时间追踪同一状态的预约，结束条件尤其有用。可要求CI成功或失败确定后结束确认，限期文档检查在结束日期停止。持续业务则可用一个月后重新审查结果用途与运行频率的时间点，替代结束日期。

预约是采用默认沙盒设置的无人运行，并受组织政策约束。请参考官方沙盒文档确定必要文件与网络范围。访问受阻导致失败时，宜重新匹配读取对象、必要命令与验证范围，而不是统一取消所有访问限制。

提示词写入结束条件后，也应确认实际管理界面已反映停止或完成状态。保留记录与停止预约是不同操作。整理已完成运行时，应先确认还需审阅的报告与必要修改。

8. 用两次假想运行审阅结果

假设假想项目“实验笔记网页”每周一上午9点检查文档变化。首轮确认起始提交A与结束提交B之间的三份变更文档，并发现运行指南有一个错误文件夹名。报告应同时保留对应句子、实际确认路径，以及是否执行命令。

第二轮检查B之后的变化。如果同一文件夹错误仍存在且无新错误，应标为旧问题未解决。若用户修改了文件夹名，则记录解决依据。如果应用未运行而错过检查，应保留成功基准，从最后成功位置比较，减少遗漏。

最初几次应亲自阅读时间、项目、基准与问题状态是否正确。提醒过多则收窄需报告的变化标准；检查过久则减少目标文档。确认能稳定获得有用结果后，再加入修改业务或目标项目，更容易评价自动化效果。

官方来源与确认日期： 定时任务, 最佳实践, 工作树, 本地环境, 沙盒。2026年10月3日确认。案例、状态文件与提示词均为作者编写的说明示例。