额度消耗快，常见原因是任务在前几轮一直找方向。Codex 需要反复扫描文件、猜目标、修改以后再推翻。把第一次输入写得更可执行，通常比等重置更省事。
一次只交一个能验收的结果
把目标写成一个可见结果，再补修改范围和验收方法。比如让导航栏增加一个入口，并要求桌面和移动端都能点击，最后跑构建与浏览器检查。这样的任务比一句优化网站容易控制。
大型需求拆成几个能独立检查的阶段。每个阶段完成后提交一次，下一轮只继续未完成的部分。任务走偏时可以从最近的干净状态接着做，不必重新解释整套项目。
上下文只给会改变判断的材料
截图用来说明视觉状态，日志用来证明错误，文件路径告诉 Codex 去哪里找。三者各有用途。把整个项目的历史、几十张无关截图和长聊天记录一起塞进去，查找成本会更高。
先给最小材料。Codex 找不到根因，再补相邻文件和完整日志。涉及当前网页时，给出准确网址、视口和操作步骤。涉及代码时，说明仓库、分支和不能动的目录。
验证要跟着修改走
改完一小块就跑最相关的检查。测试失败时，把原始错误留在同一轮里处理。等到几十个文件都改完才构建，错误会混在一起，后续排查需要重新读取更多上下文。
视觉修改要打开真实页面。构建成功只能证明代码能打包，不能证明按钮可点、文字没挤坏、移动端没有横向滚动。
把高推理强度留给难题
改一行文案、补一个链接和机械替换，通常不需要最高推理强度。跨模块故障、复杂迁移和安全审计更值得用更强模型与更长推理。先用一个小步骤验证方向，再决定要不要提高强度。
收尾时留下接续点
记录已经完成的文件、测试结果和下一步。分支保持干净，提交信息写清行为变化。下次继续时，Codex 可以从确定状态开始，省掉重新盘点整个项目的消耗。
