摘要

这是一条工程记录，不是识别实验。背景是：项目想测量“战场行动卡逐张排名”的一个私有加速候选（把逐张串行的模板排名改成两个工作线程并行）到底能快多少。为了让测量可信，测量程序会先“冻结”所有输入——源码、配置、模型、资产、数据库等文件的大小和修改时间——并在测量前后反复检查，任何变化都立即停止，避免拿不同条件下的数字比较。

问题是：游戏知识参考数据库是 SQLite 文件，只要被打开，它旁边的共享内存文件（arena.db-shm）的修改时间就会变，于是守卫每次都会停下。上一份协议已经设计了“只对这一个文件放行、其他一律严格”的精确例外守卫。本实验只做把这个新守卫和原测量流程接在一起的独立适配器，并做静态核验。真实测量窗口尚未批准，真实请求仍为 0/3。

要回答的问题

能否在不修改原测量流程、原冻结计划、原算法和原门槛的前提下，把“精确 SHM 例外守卫”接入测量，并保证除这一个文件之外的任何变化仍然会停止测量？

数据与来源

不涉及游戏像素的新读取。测量对象（未来）是一局录像 420 秒处的一张草地开局截图，沿用原计划冻结的配置。原 2205 条冻结清单、原测量基线和原报告目录都保留不动。

方法

适配器放在第三个独立目录，不往两个已冻结的源码目录里追加文件。它做三件事：

  1. --record-metadata：只登记适配器自身 3 个新文件、已冻结的守卫和新计划的元数据，生成一份登记回执。这不是第三次源码冻结。
  2. --check-only：核验适配器与精确 SHM 守卫是否接通，不创建测量尝试、不构造读取器。
  3. 未来真实运行：先拒绝任何已存在的旧/新尝试或停止回执（防止换目录重置测量额度）；校验适配器、登记回执、守卫和全部原严格依赖；然后才独占创建尝试记录、构造原读取器。实际测量直接调用原有的计时、处理器构造和请求序列函数，不复制计时或排名算法。每保存一个响应后重新检查守卫；中途有变化就保存失败回执并停止后续请求。

原有测量规则全部保持：冷请求和热请求的完整非计时输出必须一致、至少 2 张卡、热排名耗时占读取 ≥50% 时才运行一次候选；总请求硬上限 3；不额外预热、不换帧、不重试。

设置

只用临时文本文件和一个假的处理器做反例测试，不构造模型、不读像素，不消耗真实额度。

结果

项目 结果
元数据登记 一次成功
静态核验 通过，严格违规 0；唯一诊断是那个 SHM 文件的修改时间变化
新增反例测试 10 项通过，0 失败/错误/跳过
真实测量请求 0/3（未运行）

反例测试覆盖：适配器文件新增/删除/变化、计划或守卫变化、原严格检查失败，都在构造读取器之前被拒绝；已存在的尝试或停止回执禁止重试；传给原序列的请求和设备不变；第一个响应落盘后守卫失败会记录“已开始 1 个请求”并且不再运行第二个。

失败与负结果

本轮没有失败记录。需要强调的“负”信息是：真实性能、候选输出等价性、识别准确率都还没有测量。另一个同期约 21.17 秒的路由诊断是别的运行，不能混进本候选的前后对比。

局限

  • 这是静态接通，不是性能结果，更不是加速已被证明。
  • 适配器不进入默认路径、App 或命令行；原排名算法不变。

结论与下一步

“只放过 SQLite 共享内存文件、其余一律严格”的守卫已经能接到原测量流程上，并且测试证明它不会被用来绕过冻结或重置测量额度。下一步要等独立批准真实测量窗口后，用一条命令运行最多 3 个真实请求，再判断加速候选是否等价、是否真的更快。