继续Codex工作时应留下的记录：修改文件与验证状态

使用Codex工作时关闭窗口，或几天后重新打开同一项目，应先核实完成到了哪里。仅说“继续刚才的工作”，容易重新调查已解决错误，或将尚未验证修改当作完成。继续工作所需的不是复制全部长对话，而是连接当前文件状态与剩余判断的简短准确记录。本文介绍不依赖特定账号对话保存功能的交接方法。

先选择继续的对象

即使项目名称相同，当前文件夹、Git分支或已安装依赖不同，也不能直接沿用之前结果。例如，昨天在说明用项目修复settings界面保存错误，今天打开的却是另一分支的功能开发文件夹，应先确认之前修正在文件中。续作记录应包含本地路径、所用分支与最后核实的修改。路径变化时，应明确以新路径阅读，不要强制寻找旧路径。

目的也应写成一句。“解决设置保存问题”过宽；“修改后，使通知选项在刷新后仍保持已存值”，则能看出成功条件。如果同一对话混有样式修改或部署讨论，应选择当前继续的一个目的。目的变化，与旧错误复发不同。第一步是让阅读旧记录的Codex先对要解决的问题达成相同理解。

分别记录修改文件与验证

不要将“代码修改完成”与“用户行为核实完成”合成一行。即使已改文件，可能没运行测试，或服务器未启动，无法看界面。此时不是失败，而是仍需验证。记录应分别写修改文件、目的、检查命令、结果与直接观察的界面行为。命令除名称外，附上工作文件夹与条件，更便于复现。

假设说明用示例中，src/settings.ts负责输入值保存逻辑，src/settings.test.ts负责刷新后读取值的验证。两文件被修改，不意味着保存始终成功，断网或无权限情况仍可能未处理。可记录“正常保存案例检查通过，失败响应提示尚未核实”。不把旧成功扩大为整个功能保证，能准确确立下一步起点。

记录项目	良好记录示例	下一步使用的理由
目的	使通知设置在刷新后仍保留	减少重新定义完成条件的需要
修改文件	保存函数与对应回归检查文件	可先阅读相关代码的当前状态
检查范围	仅正常保存案例通过，失败响应未验证	避免夸大成功，并找到剩余条件
剩余任务	核实连接失败时的用户提示	优先处理未验证部分
限制	保持响应格式与原选项名称	减少影响其他功能的修改

下一步应读与无需读的资料

续作文档不是复制整个项目说明的地方，应优先记录会改变下一判断的资料。日志关注发生时间与直接相关消息，文档关注当前设置项目，代码关注修改函数与调用位置。长篇解释已废弃途径，可能让它看起来仍是可选方案。仅当废弃理由有助于避免重复错误时，才简写“此方式与原API冲突，因此不用”。

为交接准确，也应减少敏感资料。不要原样粘贴登录令牌或含真实客户姓名的日志，应改为保留错误类型的说明用值，并注明已替换。如果问题只在真实数据出现，应说明触发它的形式或长度，尽可能缩成最小案例。保留必要上下文，不是无条件发送更多资料，而是整理出可找到相关信息的结构。

恢复请求应从核实开始

以下是可复制并按自己文件名与条件修改的示例，不替代真实项目执行的命令或完成检查结果：“先阅读记录并与当前文件比较。如果不同，以当前文件为准说明差异。再仅继续修复剩余失败响应处理。保持正常保存路径与响应格式，能执行相关检查时，请留下运行结果。”

其中关键是与当前文件比较。记录是编写时的快照，其间可能有人修改。存在新修改，不意味着旧记录错误，也不必全部回退。应要求Codex阅读当前修改目的，并纳入新工作。为了不覆盖旧工作而继续，相比是谁创建，更实用的是确认当前代码承担什么作用。

说明用续作文档结构

文件名按团队易于查找方式决定即可。例如，handoff-notes.md可分标题记录日期、目标、当前状态、修改文件、验证、剩余任务与限制。该名称只是说明示例，并非官方要求的特殊文件。不要假设产品自动读取，应在恢复请求指定准确文件。仓库规则与任务进度目的不同，不应持续把一次性错误日志堆入永久规则。

留下记录后，应核实别人仅凭文档能否选择下一行动。“保存请求失败时，不保留成功提示，并检查重试按钮”，比“下一步完善错误处理”更好。但不要过度固定实现方式，保留从当前代码找到更简洁方法的空间，同时明确应观察结果与必须保持条件。

记录与当前状态冲突时

文档写检查通过，今天运行可能失败。此时不要删除记录再写通过，应保留检查日期与环境不同的事实，分别核实依赖、环境与代码变化。因命令未安装而无法执行，不同于代码检查失败。不能只看输出最后一行，应阅读在哪一步停止，才能准确选择下一工作。

服务器保存或部署等最后操作结果不明确时，应先读状态，再重复操作。本地文件编写与外部系统反映是不同状态。例如，创建文档不代表已在网站发布，发送请求也不代表保存已确认。续作文档应区分“文件准备”“保存尝试”“真实结果核实”，避免重复。此区分也适用于资料上传与重复任务，不限于代码。

常见问题

旧对话保留着，就不需要记录吗？ 即使可读对话，当前文件也可能变化，长对话还含废弃计划。简短最新记录说明继续的依据。产品对话保存与上下文处理可能变化，应查阅官方指南，而工作事实应通过文件和检查结果核实。

记录需要多长？ 按文件数量与剩余判断编写即可。简单错误几段足够，多模块修改可能需要关系表。比长度更重要的是下一工作人员能否找到复现条件与验证范围。完整日志可另存文件，并链接必要部分，使文档易读。

中间结果似乎错误，必须从头开始吗？ 先比较当前代码与目标，寻找错误范围。与其丢弃全部可用修改，补充缺失验证或修正局部错误可能更合适。确定保持什么后，在恢复请求注明范围。停止工作时，也应留下目的、真实修改、已确认结果与剩余条件，减少续作时从同一调查重复开始。

记录末尾可留下编写时间与下一项检查。例如，“截至下午3时，仅完成本地检查，下一步查看连接失败界面”，可避免将旧记录误为最新结果。下次工作结束后，将完成项目改为过去式，仅重新记录仍未完成部分。

官方资料与撰写依据

• OpenAI官方提示词指南
• OpenAI长时间工作指南

这是借助AI撰写的信息类文章。官方文档于2026年10月3日核查，以下示例为说明而设计，并不代表真实个人项目的执行成果或实测值。发布前会再次核实产品说明是否发生变化。