Codex反覆修改與測試耗用大量 Token，作者整理出避免循環返工的方法

最近用Codex，老金就一直在等。

测试没过，它改一下，再测，还是没过，那就接着改。

我看着它忙，心想这一轮总该交活了吧，结果它自己又续上了。

真是屡试不爽，屡试的是它，不爽的是我。

等太久了，感觉很不对劲儿，我就让它统计了一下Token用量，看看都花哪儿了。

看完结果，只想骂娘。

反复分析、修改这些来回，已经吃掉了大量Token。我在这儿耐心等待，它在那儿耐心消耗，耐心倒是都没白费。

这哪是普通的坑，巨坑Pro Max啊。

可要说干脆别测了，我也不敢。省下检查之后，交给我一个不能用的，那更坑。

不过等完最怕的是这种情况：已通过237272个测试✅ ，再一点击运行，Error xxx，无法启动。

我XXXX！（屏蔽字）

老金这两天去翻了翻相关讨论，看看有没有人也碰上了，后来又怎么收的场。

比如这个老哥也吐槽过，简单任务做一大堆测试，额度是不是都耗在这儿了？

另一个兄弟也说，改个小功能，却塞进一堆检查和测试。

有个同时用Codex和Claude的哥们，后来就不陪它一直猜了。

他是先把问题重现出来，看报错，也看最近改了什么，找到哪一步开始出错，再做最小修改、检查结果。

这个咱能一步步跟着做，先让AI闭嘴别墨迹，然后问问它，下一轮到底准备查什么。

先让它停下猜，看看手里已经有什么

假设你让AI做个整理文件的小工具，点导出没反应，就叫它修。

它改了一遍，文件是有了，打开一看，里面毛线都没有，那你就得让它看内容在哪一步没写进去。

把下面这段发到当前对话，让它先翻已有记录。

别一问做过什么，它为了回答你，又做一遍，那就是赔了衣服再赔裤衩了。

回复拿到手，再看缺什么、查到了什么、准备接着做什么。

这些信息，才是我们做判断的标准。

# 先暂停，保留现场
安全暂停后续修改和重跑，不强行打断正在写入数据的操作。
只读已有记录，说明最近的失败、已试办法、新发现及依据。不知道原因就直说。

# 分清已知和未知
列出已通过检查的命令、结果及适用状态，不为补记录重跑。
相关代码、依赖、配置、测试数据或环境变化时，标明需重验的部分。
结合报错和最近改动，只提一个有理由的复现、定位或修复动作。缺材料就列明，先不执行。

# 用量只报实账
有记录就报来源、时间范围和Token数。只有总量就报总量。
无记录不猜分步消耗、费用或套餐余额。

它要是说缺样本文件，你就先把文件给它，说明放在哪儿。

你这边还没上传，它那边已经找了几轮，再找下去，也不能无中生文件啊。

要用的外部服务连不上，就先处理连接。恢复不了先停，等材料和连接齐了，再让它看刚才那一步能不能做。

它要是查到导出拿到的就是空数据，准备顺着往前找，看看内容在哪一步丢了，那就可以继续。

答案还没找到没关系，总得知道下一步往哪找。

最怕几个旧办法轮着试，还测的是同一个报错，那就很麻烦。熟能生巧没看见，倒是熟能生耗了。

Anthropic做内部代码审查时，也专门处理过这种反复修、反复查的问题。他们用了几条防止来回折腾的办法，三轮后退一步重新想方案，前几轮之后重点复查新改动，同类错误一起处理，提过的问题不重复刷屏。

团队报告，这些调整前后，需要五轮及以上审查才能通过的比例，从8.9%降到了1.5%。

Vox又把类似思路整理成了给AI的四条要求，其中一条更直接，同一个问题修两次还没好，就先停下来汇报。咱也可以把两次设成自己的叫停点，先看看试过什么、卡在哪儿，再决定怎么继续。

两次没修好，先停下来换个想法，不是把失败改成通过。

它要是说，这项检查之前通过了，只是现在想再确认一遍，那就让它把记录找出来。

代码没动，运行条件也没变，不能它失忆一次，你就陪它重考一次。

可要是相关代码或运行条件变了，就得让它说清哪些检查受了影响，该补的得补。

知道下一步做什么，再让它动手

下一步能做了，还得看它准备改多大。

还是那个导出问题，你让它修一下，它却准备把页面重做、文件处理换一套，再加几个以后可能用上的选项。问就是以防万一。

眼前这个一还没做好，它先把万一都安排上了。

怕你以后不好扩展，多拆几层。怕你以后功能不够，多加几项。未来是看见了，可你的文件还没出来呢。

先让它把这些以后再说的活拿掉，回到这次导出。无关的旧问题可以列出来，别看见一个就顺手修一个。

前面那个问测试是不是耗尽额度的帖子下面，就有个老哥说过，一个简单迁移任务被AI越做越大，后来他把任务收回来，自己一步步引导，才做完。

OpenCode团队也把要求写进了自己的项目规则：要为假设中的问题增加复杂度，先说清具体问题和代价，再征求同意。已有的实现能用，就接着用，修个功能不用从盘古开天辟地开始。

改之前，还可以让它在这次相关的代码里找一遍，同一个原因是不是在别处也出了问题。确认是同一根因、也在这次范围内，就一起处理，别这回补一个，下回又认领一个。

改哪里说清了，再看检查怎么做。只改导出，先查导出。要是改到了其他功能也在用的地方，就把受影响的功能一起查，交接时再完成项目要求的检查。

Gemini CLI自己的项目规则，就把清理、安装、构建和测试那套最重检查，留到代码实现任务结束再跑。中间出了错，先用针对性的检查找原因，不用每动一下就全家总动员，也不能全攒到最后才查。

已经检查过、结果还有效的，不用重来。该补的检查照做，别把省下的工夫变成用户后面的麻烦。

这次查哪里、改哪里、怎么检查都对上了，再发下面这四条。它要是又绕回同一个问题，就按约定停下来，不等你再盯着喊停。做完则交实际结果和验收步骤，可别只交一份更加宏伟的下一步计划。

# 1. 只改本次相关问题
按确认方案继续，保留可恢复版本，复用已有实现。
无关旧问题只列出，不顺手修或加功能。扩大范围先问我。
涉及真实用户数据、破坏性操作或额外付费，先确认。

# 2. 先找同一根因
用报错和已有证据定位，不凭猜测修改。
在本次相关范围内搜索同根因、同模式的问题，确认后一起做最小修复，不全仓替换。

# 3. 每轮复查受影响的部分
重点审查本轮改动，按需读相关上下文和调用链。
已解决且未受影响的问题不重复提，未解决项继续跟踪。
复用有效检查，受影响功能和交接检查按项目要求补全。
不删失败测试、不跳过必要检查、不放宽通过条件、不隐藏错误。
做完说明改动、实际检查结果、未确认项，并给我验收步骤。

# 4. 同一问题两次没修好，先停
安全暂停后续修改和重跑，不强行中断正在写入数据的操作。
报告已试办法、实际改动、剩余失败和需要我决定的事，等我确认再继续。
同样失败且没有新证据，不必等满两次就该停。

它说修好了，把刚才做不成的事再做一次

它说修好了，你就点一次导出，下载、打开，看看内容是不是你要的，格式之类的有没有问题。

顺手还得再试一下一两个原来常用的功能，别赶上买一送一，导出修好了，附赠一个上传失败。

Google的测试资料讲过一种情况：有的检查管得挺细，代码内部换个写法，它立刻报错。至于结果对不对，它倒没管。

放到这个导出工具上，咱要的是该导出的内容真进了文件。

注意不能哪个测试报错，就把哪个删掉。你是让它解决问题，不是让它把系统给删了。

还有个兄弟吐槽过，搜索明明失败了，程序却返回没有搜索结果。

你还以为关键词没选好，换个词，再搜，搜不到，再换，软件出个问题，倒是把你练成了同义词词典。

能恢复就恢复，恢复不了就把失败说清，你就能做判断了。

下次开工，别让它又从头来过

这次做完了，以后还得复用。要不换个项目，它又重新认识一次项目，你又重新讲一遍人生。

社区里有人给长任务留记录，把目标、检查证据和是否完成分开。

他后来反馈，忘记原目标、把模拟测试当成真实完成的情况少了，可AI还是会继续加设计、加测试。

记性变好了，手还挺勤，勤到该收工了还得给自己找点事。

记录不要写成长篇回忆录，留下目标、检查结果、没解决的事和下一步就行，恢复任务时先读完再做。

然后还有这种情况，没变过的数据，刚查完又查。

只用一次的简单逻辑，先拆出一堆零件，看起来眼下拆得挺细，大坑是以后改一次，还得挨个照顾。

这个老哥就分享过几条规则，少做重复检查，也别太早把简单事情拆复杂。

当然，外部新进来的数据，该查还得查，咱是让它别多此一举，不是把必要的那一举也省了。

前面那四条是让它继续处理这次修复，下面这份是给以后定默认规则，已经把四条合进去了。可以整段复制给Codex，让它补进项目正在使用的AGENTS.md，这是留给AI看的项目做事要求。

合并完开个新会话，让它确认读到了，然后开始你原来的任务。只是以后照这个做，可没让它现在就给全项目大扫除。

# 本次只更新规则文件
把下面规则增量合并到本项目当前生效的AGENTS.md，保留已有规则，有冲突先问，不整份覆盖。
只改规则文件，不据此修改项目代码。完成后报告文件位置和改动。

# 范围与实现
先找已有实现，只做本次任务，无关旧问题只列出。
新增依赖、换方案、扩大范围或为假设需求增加复杂度，先确认。
动手前在相关范围查同根因、同模式的问题，确认后一起最小修复，不全仓替换。
简单且只用一次的逻辑不提前抽象。确有复用、复杂细节或独立职责时再拆。
已验证且未变化的数据不重复验证。跨新信任边界仍验证，保留权限检查，类型断言不能替代验证。

# 错误与检查
捕获错误须能恢复、补充上下文再抛出，或明确响应失败。保留必要清理，不伪装成功。
按需求行为测试，复用有效结果，保留不同风险和真实流程的必要检查。
每轮重点审查新改动，按需读相关上下文，不重提已解决且未受影响的问题，未解决项继续追踪。
不删测、不跳过必要检查、不放宽条件、不隐藏错误来换通过。
同一问题两次修复仍失败，安全暂停并报已试办法、改动、剩余失败和待决事项，确认后再继续。
同样失败且无新证据可提前停，不强行打断数据写入。

# 长任务续接
简记目标与验收、已检查命令和结果及适用状态、未解决项、下一步。恢复先读。
相关代码、依赖、配置、测试数据或环境变化时重判验证范围。模拟测试通过不记成真实流程已验收。

这些做法要是以后反复用，也可以整理成Skill。

老金的Kim_Service里有个meta-skill-creator，用来创建和改进技能，常用步骤留下来，不用每次从头交代。

地址在GitHub上搜Kim_Service就行，使用方法也简单，直接人话说，使用meta skill creator，帮我创建XXXXX，并告诉我触发方式。

写在最后

以前看AI一直在跑，很容易这样想：再等等吧，说不定下一轮就好了。

这次研究完，老金觉得，再等可以，总得先知道它准备干什么。

如果还在原来的几种猜法里打转，就得先把记录拿出来。

信息足了，咱才能判断下一步怎么做。

而不是在AI那个记忆力低下的框架里，翻来覆去的测同一件事。

谢谢你读我的文章。

如果觉得不错，随手点个赞、在看、转发三连吧🙂

如果想第一时间收到推送，也可以给我个星标⭐～谢谢你看我的文章。

开源知识库（实时更新 交流群）：
https://my.feishu.cn/wiki/OhQ8wqntFihcI1kWVDlcNdpznFf