处理一个持续修改的项目时，需要先确认当前信息：最初说要改首页，后来改成只补帮助页；旧报错还在聊天里，代码却已经更新。直接说"继续"，下一步该依据哪一份要求，并不总是清楚。我会先整理一份短记录，再让 Codex 对照当前项目核实。
这份记录是自己维护的任务资料。文件名没有特殊作用，保存后仍要在指令里明确提供路径。本文的模板与例子为独立整理；文中只读命令在 macOS 的本地 Git 工作树运行过，没有进行模型任务或跨会话恢复实测。
一张表，留下现在仍然有效的信息
OpenAI 的 Best practices 建议给任务说明目标、相关上下文、约束和完成条件。基于这个原则，我把记录整理成下面几项：
| 要记录什么 | 怎样写得能核对 | 常见混淆 |
|---|---|---|
| 当前目标 | 预期行为、交付文件、完成条件 | 把已取消方案当成待办 |
| 代码现场 | 工作目录、分支、当前提交 | 把旧聊天里的目录当作当前位置 |
| 有效约束 | 允许改哪里、必须保留什么 | 省略后来补充的限制 |
| 已确认事实 | 证据路径、命令结果、记录时间 | 把推测写成已经验证 |
| 下一步 | 缺什么证据、先检查哪一项 | 把所有历史日志全文塞进来 |
这里没有固定字数要求。短记录如果缺少当前目标，仍然不够用；长记录如果混着旧决定，也会增加核对成本。完整日志可以保留在合适的位置，记录里只说明与本任务有关的证据去哪里找。
先看当前项目，再整理记录
在准备处理的 Git 项目目录中，可以先做这些只读检查：
bash
pwd
git status --short
git branch --show-current
git log -1 --oneline
git diff --stat
git diff --cached --stat这些输出回答位置、提交和改动概况。两条 diff 统计分别覆盖未暂存和已暂存的已跟踪变化；未跟踪文件还要结合 status 看。统计也不能替代具体差异或分支范围检查。准备公开截图时，路径和文件名也要检查是否需要脱敏。
用一个虚构例子试填
假设现在只修帮助页的空状态文案，之前提过增加搜索框，后来已取消。记录可以写：目标是替换空状态文字；搜索框方案已取消；相关证据在帮助页文件和页面入口；构建尚未运行；下一步先核对文案与预期是否一致。
这段记录没有把旧方案删得无影无踪，也没有继续把它算作待办。上周另一个提交的构建成功，不能变成本轮的检查通过。这只是示例，不是某个修复已经完成的证明。
可以复制的开场要求
text
请先读我指定的任务记录和项目说明。
先只读核对目录、分支、当前文件变化及证据。
列出与记录不一致的地方、有效约束和待确认项。
旧结论不要直接当作当前事实。
核对后从下一项最小检查继续，并记录实际结果。如果仍在解决同一个连贯问题，可以在原会话补充记录。官方资料也建议连贯工作保留在同一会话；不必为了套用模板反复另开。目标已经独立变化时，再单独组织任务。
记录会过期。需求改变、代码起点改变或检查完成时，需要更新相应字段与时间；没有重新核对的结果就说明其范围。它能帮助下一步找到事实，不能恢复进程、登录态或所有对话状态。
完整记录模板与检查步骤见 任务上下文包。资料依据：OpenAI Best practices，核对日期为 2026-10-15。