Codex适合做什么工作：先从有文件、有步骤、有验收的任务开始

Codex第一项任务，别从重构整个项目开始

适合没用过Codex，也不关心它是什么技术，只想判断自己的工作能不能交给它推进的人。

选任务的目的不是把责任交给工具，而是找到一段可重复、可检查的工作。需要专业签字、最终审批或不可逆操作的环节仍由人完成。

Codex可能读取文件、修改内容并执行命令，因此首个任务应使用副本或版本控制。把生产环境和唯一原件排除在授权范围之外。

好任务需要文件、步骤和验收

• 你每周重复的工作清单
• 每项工作的输入文件与步骤
• 可明确判断对错的交付标准
• 建立一个测试副本或新目录，不直接操作唯一原件。
• 写下一句验收标准：首个任务有明确输入、步骤和验收，Codex产出能被你复查，失败不会影响唯一原件或生产环境

给每个候选任务补上输入位置、允许操作和验收人。三项中任何一项说不清，就先不把它列为首个任务。

从只读盘点到小范围修改

先从十分钟能检查完的小样开始

首个样本不必追求价值最大，只要真实、可恢复，而且你能在十分钟内判断对错。验证成本太高的任务，即使执行很快，也不适合作为起点。

从每周重复的工作里找候选项

优先选择会重复、步骤相对稳定、材料在电脑或系统中的工作。

把会议整理、文件对比、内容更新、日志排查等候选项列出来，同时写下发生频率。偶尔才做、每次规则都变的任务先放后面。

看它是否真的有文件可读

确认Codex可以在授权范围内读取文件、表格、页面或日志，而不是只能凭空聊天。

列出Codex能够读取的文件、页面、表格或日志，以及禁止访问的范围。如果输入只存在于你的经验里，就先把判断规则写出来。

把“做好”改成可以打勾的结果

数量、格式、差异、测试、页面状态或人工清单要能判断成功。

例如“输出两版差异表且总数与原文件一致”，比“帮我认真检查一下”更容易执行。完成标准最好能由另一个人复核。

优先做只读盘点或副本修改

先做只读盘点、单个文件或测试副本，验证后再沉淀规则和Skill。

先让Codex盘点、对比或处理一份副本，查看它读了什么、改了什么、如何验证。小样没有稳定通过前，不要扩大到整个目录。

再决定要不要扩大范围

用预先写下的标准验收小样，记录需要人工判断的环节。连续几次都能复现后，再把任务扩大或整理成Skill。

三个任务，哪个更适合第一次做

每周整理会议记录、核对两版表格、更新网站内容和检查死链都适合起步；最终审批、不可逆发布和没有材料支撑的专业判断不应直接交给Codex。

可以先这样描述任务：

我正在处理“用材料、流程、频率和验收四个条件判断一个工作是否适合Codex”。已有材料包括你每周重复的工作清单、每项工作的输入文件与步骤、可明确判断对错的交付标准。请先不要扩大任务范围，也不要补造缺失信息。先完成“找流程化任务”，输出可以人工检查的中间结果；我确认后，再继续“检查是否有真实材料”。最终请按照“首个任务有明确输入、步骤和验收，Codex产出能被你复查，失败不会影响唯一原件或生产环境”列出验收结果和仍需人工确认的内容。

如果第一次结果还是很泛，通常不是提示词不够长，而是输入和交付物不具体。先缩到一个文件和一个验收目标，再重新测试。

做了很久却说不清结果怎么办

任务执行了很久，最后只得到一段建议

把目标改成具体文件或检查结果，例如差异表、修订稿、构建产物和验证报告；明确授权它读取和操作的范围。

结果文件有了，却不知道是否正确

回到任务开始前补上数量、格式、差异或测试标准；无法补出验收方法时，说明这个任务还不适合自动执行。

第一次就改了整个目录，出错后找不到起点

恢复到原件或版本控制状态，只选一个代表文件重做。每轮只改变一个变量，确认通过后再逐步增加文件数量。

判断任务是否成功，要看实际文件、差异和验证输出。只看Codex的总结，很容易忽略它没有执行或改错范围的情况。

决定扩大范围前检查这些

• 首个任务有明确输入、步骤和验收，Codex产出能被你复查，失败不会影响唯一原件或生产环境
• 输入文件、允许范围和禁止范围都已经写清楚。
• 完成标准能通过数量、差异、测试或人工清单判断。
• 小样失败时可以恢复，没有触碰唯一原件或生产环境。
• 已查看实际文件和验证结果，而不是只接受Codex的完成说明。

小样稳定后，可以一次增加一个变量，例如更多文件或多一个验证步骤。这样出了问题，仍能知道是哪一层范围导致的。