AI 改完代码，告诉你“测试通过”。你准备让它接着做，另一轮检查却又报出问题：这次到底算不算完成？如果手里只有一句“已修复”，下一步该继续还是该停，其实很难判断。
10月29日，我在梳理自己的 AI 项目时就遇到了这样的情况。负责统计 AI 用量的脚本改过后，自测通过了，换一轮检查却又发现漏计。项目还不能恢复开发，得先弄清楚：这个“通过”，到底证明了什么？
数字变小，先别急着让 AI“对上账”
这次排查的起点很具体：统计起点没变，后一次采集到的累计用量，竟然比前一次少了。
只读检查找到的原因是，同一个会话的记录分在多份日志里，采集器却只读当前指向的那一份。旧记录还在磁盘上，只是没一起算进去。打个比方，就像账本翻到了新一页，你只加这一页的金额，却把它当成整本账的总额。
我批准的修复范围因此很小：找齐属于同一会话的日志，核对来源，再读取。旧快照保留，统计起点和原有计算规则不改。自测结果显示，多日志读取和路径切换等场景通过了。
如果你也遇到前后数字对不上的情况，可以先让 AI 说明：两次统计读的是不是同一批数据，旧记录是否还在，哪些记录没有参与计算。先查范围和来源，比直接要求“把数字修正确”更容易看出问题落在哪里；改小了读取范围，也可能得到一个看似正常的结果。
测试通过，究竟是哪一部分通过？
修复后的独立复核，又发现了一处漏计：用量记录采用某种合法的 JSON 转义写法时，会被静默跳过，返回的结果却仍被标为完整。可以先把 JSON 理解为记录数据的一种文本格式；这次测试中的输入是合法的，读取程序却没有正确处理它。
这个反例已经复现，但真实生产日志里是否出现过这种写法，还不知道。因此，不能拿测试里的失败去推算实际漏了多少用量，也不能因为其他场景通过，就把这次验收算作通过。
自己测过，不等于独立验收通过。对这次修改，自测和另一轮复核给出了不同范围的结果，两份都要保留。下一步需要处理的是已经发现的漏计缺陷，而不是把原先的“通过”写得更肯定。
下次收到 AI 的完成回执，你可以直接补一句：
请写清楚：这次改了哪里；实际用什么输入、运行了什么测试；哪些情况没覆盖、还有哪些失败。把自己的测试与另一轮复核分开，不要只给我一个“通过”。
看回执时，重点对照你真正要用的输入。这次通过的是隔离数据下的一部分场景，真实环境的可靠读取和历史记录覆盖仍没验证完整。即使修掉眼前这个反例，也不能顺手宣布所有历史用量都已核清。
一张清楚的图，也可能停在昨天
我当天还用了 archify，把10月28日的审计结果整理成架构、任务流程和职责分工图解。它把这些关系放在同一页里，方便对照，但里面的迁移方案当时还没有启用。
我接着问：这张图会跟着开发进度更新吗？答案是，目前不会自动同步。也就是说，图可以讲清方案，却不能单凭它判断今天哪个任务已经完成，更不能代替验收记录。
如果你也用图解整理 AI 项目，可以先要求页面写明“依据哪天的记录、由谁更新、是否自动同步”。看见“完成”，再找到对应的验收结果；找不到的，就保留为待核实。这样用图，才不容易把方案画好了误当成项目做完了。
换新会话接手时，也可以沿用同一个办法：交接已改内容、实际检查结果和剩余问题，别只转述一句“上个 AI 已经做好了”。
我的项目目前仍在暂停：合法转义漏计还要处理并重新验收，真实环境的可靠读取和历史记录覆盖也没有验证完整。如果你也卡在“AI说完成了，却不知道能不能继续”这一步，下次可以直接要求：“请把这次改动、已经验证的输入范围，以及剩余失败一起交给我。”拿到这些，再决定要不要让它往下做。
发表回复