codex-token-saver

Codex Token Saver

优化工作流时，不得削弱正确性、验证、安全性或用户要求的结果。将节省 Token 作为次要约束：绝不能仅为减少用量而跳过必要的文件、来源、测试或审批。

选择最轻量且有效的干预措施

更改工作流之前，先找出实际的浪费：

• 反复读取未变更的项目上下文；
• 其他进程仍在运行时频繁轮询；
• 冗长的对话中还保留着已过时的决策；
• 能力过强或成本过高的模型在处理范围明确的机械性工作；
• 方向偏移、推测性扩展或反复返工。

仅采取下方相关措施。对于简短且范围明确的任务，不要额外增加流程负担。

复用上下文，而不是反复读取

• 将持久性上下文与不断变化的证据分开。持久性上下文包括项目目的、架构、编码规范、固定约束和标准命令。变化中的证据包括新要求、编辑内容、失败信息、日志和测试结果。
• 如果已有简洁且可信的持久性摘要，就复用它。只重新读取可能发生变化的文件或章节，或当前决策实际依赖的内容。
• 打开大型文件之前，先搜索符号和路径。优先使用定向范围和聚焦查询，避免通读整个目录或文档。
• 如果正确性取决于当前文件内容，就不要依赖记忆。做出无需重读的判断之前，先检查时间戳、差异、搜索结果或相关源文件。
• 对于大型文档，如果布局无关紧要，只提取一次可搜索文本。如果图像、表格、分页或格式会影响任务，则保留并检查原文档。

高效等待长时间运行的工作

• 优先采用事件驱动等待，或当前工具支持的最长安全等待间隔，避免频繁执行无结果的轮询循环。
• 如果上一次操作已返回可复用的会话或单元格标识符，就不要反复调用空输入或轮询操作。
• 当外层执行调用包装了内层等待时，应为外层调用留出足够时间，以便接收内层结果，并预留合理缓冲。遵循平台当前的上限和更高优先级的指令；不要硬编码当前环境禁止的间隔。
• 在确实需要长时间等待时，按照当前环境要求的频率，向用户简要更新进度。

为长期项目设置检查点

对于跨越多个阶段或可能在另一个任务中继续的工作，仅在持久化有用且写入属于任务范围时，才在项目中创建或更新 DEV_STATE.md。内容应精简且客观：

# Development State

## Goal
## Verified current state
## Decisions and reasons
## Files changed
## Tests and results
## Next action
## Blockers or open questions

• 记录已验证的状态，而不是对话记录。
• 删除已被取代的计划，不要不断累积。
• 如果检查点与之冲突，以代码仓库和测试结果为准。
• 恢复工作时，先阅读检查点，再检查验证其是否仍然有效所需的文件。

在获准的情况下按难度分配工作

如果可以选择模型或委派任务，且已获准这样做：

• 将目标含义不明确的解读、架构决策、任务分解和最终整合交给最合适的强模型。
• 给成本较低的模型分配范围明确的任务，并说明输入、输出、约束和验收检查，例如定向审查、隔离实现或测试失败分类。
• 如果协调或返工的成本可能更高，就不要仅为节省 Token 而委派。
• 绝不要假设当前模型价格或配额倍率。如果建议涉及成本，应使用 OpenAI 官方最新文档进行核实。
• 遵循环境对使用子 Agent 和更换模型的授权规则；本技能不会授予启动 Agent 或更换模型的权限。

防止偏离和返工

• 如果执行偏离了请求，就停止无效分支，重新说明目标和当前证据，然后从最小的有效下一步继续。
• 如果产品提供单独的旁支对话，且答案不需要保留在主要历史记录中，就不要让临时的旁支问题干扰主要实现上下文。
• 优先采用满足所述需求的最简单实现，先构建可运行的最小版本，再考虑可选扩展；适当时使用成熟的依赖项，并避免造成可预见维护负担的捷径。
• 不要反复重试同一个失败操作，而不检查失败原因并调整方法。

报告结果

完成后，简要说明哪些优化实质性地改变了工作流、为确保正确性仍阅读或测试了哪些内容，以及还有哪些不确定之处。除非根据实际使用数据进行测量，否则不要声称节省了某个百分比的 Token。