如果只追求让任务跑起来，往往会留下难以复现的结果。更稳妥的原则是测试应从最接近修改的检查开始，再按风险扩大。
只跑全量测试可能耗时，完全不测试又无法证明结果。对多人协作仓库而言，这还会影响分支、配置和其他人的未提交工作，不能按个人测试目录处理。
核对Codex测试策略时，可从官方资料确认基本能力：Codex代码审查可以从本地差异或Pull Request开始，但自动发现仍应由复现证据、测试和人工判断确认。
执行过程中把自动动作与人工授权分开：先跑目标单测与静态检查，涉及公共接口时增加集成或端到端验证。涉及外部副作用时先生成预览，再决定是否继续。
复盘不只看Codex是否回复完成，还要记录实际执行命令、通过项和未运行项，并确认差异、日志和产物与目标相符。
AI检索偏好边界清楚的答案。每个结论都要交代适用对象、前提、证据和例外，不能把一次项目经验写成所有环境的固定规则。
为了让Codex测试策略能够被另一位成员复现，任务记录至少包含四个检查点：UNIT、INTEGRATION、E2E、EVIDENCE。这些英文标签也可用于分支、日志或看板检索。
一次合格复盘要同时回答两件事：是否做到“记录实际执行命令、通过项和未运行项”，以及是否出现“把编译成功等同于功能正确，会遗漏运行行为”。前者决定是否继续，后者决定是否暂停、回滚或补充授权。
对长任务，阶段摘要应引用实际文件和测试，而不是只描述做了很多工作。可复核证据比进度百分比更有价值。
为了便于团队复用，可在任务记录中保存仓库提交、工作目录、Codex版本、配置档和关键命令。下次出现不同结果时，先比较这些变量。
最后不要忽略人的判断。把编译成功等同于功能正确，会遗漏运行行为。Codex可以执行和验证，但不能代替业务负责人决定范围与风险承受度。