摘要

这是一个“协议准备”记录，不是测量。

背景：项目准备对一张战场截图（某局录像第 420 秒的开局画面）做一次严格冻结的测速，比较一个并行的“行动条卡片排序（rank）”候选实现能否缩短读取时间。为了保证测量干净，测速前会登记所有相关文件（代码、资源、模型、数据库等）的大小、修改时间和文件编号，任何一个变了就停止（STOP），不自动重新冻结或重试；整个实验最多只允许 3 次真实请求。

结果，测速在发出第一个请求之前就停止了：游戏知识模块的数据库旁边有一个 SQLite 共享内存文件（arena.db-shm，数据库被打开时由 SQLite 自动维护），它的修改时间变了。本实验（编号见标题）只做一件事：写一份新协议，只允许这一个确切文件的元数据变化，其他一切仍保持严格。新协议的静态检查通过，但真实请求仍是 0/3，没有获得测量窗口。

要回答的问题

如何在不放宽其他任何检查、不重置请求额度的前提下，让测速不再被这个与识别无关的文件变化拦下？

数据与来源

  • 原测速计划冻结的 2,205 条文件清单、目录、请求、运行环境、模型和预算。
  • 原“首请求前停止”的回执：实际请求 0 次，没有 attempt 文件。
  • 唯一的游戏输入是原计划指定的一张 PNG；本实验没有解码它。

方法

新旧协议的差别：

项目 旧协议 新协议
确切路径 game_knowledge/reference_catalog/arena.db-shm 存在与否和大小/修改时间/文件编号必须相同 只有这一项的变化不触发 STOP，前后值另存诊断
其他 -shm 文件 严格 仍严格，不允许通配、前缀或扩展名例外
数据库本体和 WAL 日志文件 严格 原值保持；WAL 原来不存在而后来出现、消失，或变成 0 字节，都 STOP
原 2,205 条清单、请求、运行环境、模型、预算 已冻结 逐项复制，不用当前值更新基线
新协议自己的源码和旧证据 — 额外冻结它们的元数据
测量入口 原测速脚本指向旧计划 原脚本不改；新实验只有“准备/检查”，没有测量入口

其他规则：原测量目录里只要出现任何 attempt 或响应文件就 STOP，不能靠换输出目录重置 3 次请求额度；新计划和检查结果用“独占创建”写入，已有文件拒绝覆盖；STOP 时保存待审差异，不自动重冻或重试。

设置

准备脚本只读取文件元数据并做静态检查，不构造路由、读取器或模型，不解码 PNG 或视频。反例测试只操作 pytest 临时文本文件。

结果

一次实际静态检查：通过（STATIC_CHECK_PASS_NOT_MEASUREMENT_AUTHORIZATION），严格违规 0 项。唯一单列的差异就是那个共享内存文件：大小 32,768 字节和文件编号不变，只有修改时间变了。数据库、WAL 及其余原元数据都匹配，运行环境匹配，旧 attempt 和三个测量响应都不存在。

28 个反例测试全部通过，覆盖：这个确切文件变化/出现/消失只诊断；其他数据库的共享内存文件、同名文件出现在别的目录都拒绝；WAL 出现/消失/变化/0 字节拒绝；数据库、源码、配置、资源、模型、原图变化拒绝；运行环境、新协议源码、原失败回执改变拒绝；通配、删除原清单条目、改请求/预算/基线拒绝；旧 attempt 阻止重置额度；重复输出拒绝。

失败与负结果

本实验没有失败记录。原测速本身的“首请求前停止”是触发本实验的失败，完整保留。初版 26 个测试后又加了两个边界，最终为 28 个，两批不相加。

局限

  • 这只证明协议和当前元数据静态就绪，不证明性能提升、输出等价、识别准确率或默认接入。
  • 元数据一致不等于文件字节相同。
  • 真实请求仍为 0/3；要真正测速，需要负责方另外批准一个测量窗口，并把新守卫接入测速脚本。在那之前，原脚本仍会按旧规则停止。

结论与下一步

协议已准备好，可以在不放宽其他检查的前提下绕开这个与识别无关的数据库副产物。原测速的其余门槛（冷/热请求完整一致、读取成功、至少 2 张卡、热请求中 rank 占比 ≥ 50% 才跑一次候选）全部保持。下一步需要负责方安排实际测量窗口。