将 Test Drive II 从 SNES 移植到 PC，第5部分：让生成的证据变得有意

Source: Dev.to

这个仓库中下一个需要清理的问题并不光鲜亮丽。
它是 git status。

到 3 月 19 日，asmdump 已经拥有足够的考古工具，能够生成：

• 探针跟踪
• 帧转储
• 序列清单
• 设计包
• 渲染器夹具
• 游戏玩法‑扫荡输出
• 后期‑引导诊断

这算是很好的进展，但也带来了新的失效模式。如果一个逆向工程仓库在每次实验中 生成数百个文件，那么“生成的”就不再是一个有用的类别。

• 有些生成的文件是一次性废弃的临时文件。
• 有些是被提升为正式证明工件的文件，文档和检查点依赖它们。
• 有些是本地的中间运行产物，只在一天内有意义，随后应当消失。

如果仓库没有让这些类别一目了然，进展就会变得更难以信任。

真正的问题是歧义

当前的移植计划现在把可维护性视为一条一等的执行轨道，这是正确的决定。

问题 不在于 仓库缺少清理脚本，而在于工作区已经变得模糊不清：

• tools/out 同时包含真实的证据和一次性实验
  • 模拟器输出可能会堆积在可变的本地文件夹下
  • 即使没有任何实质性变化，新本地运行也可能淹没工作树

这种歧义在类似的项目中是非常危险的。这个仓库不仅仅在构建一个游戏；它在构建关于游戏的 论点：

• 哪些帧行为是已理解的
• 哪个制品是权威的
• 哪个缺口仍然存在
• 哪个实验仅是草稿

如果工作树无法传达这些区分，考古工作很快就会变得嘈杂。

大规模清理本会是错误的修复

对于像这样的仓库，有一种诱人的清理方案：

“直接删掉 tools/out。”

在这里这样做会是个错误。tools/out 不仅仅是缓存，它还包含 已提升的证据：

• SDL 运行时使用的序列清单
• 文档引用的证明包
• 渲染器夹具
• 桥接可见的引入产物
• 现在作为特定后期引入帧真相来源的 OAM‑delta 报告

因此正确的问题 不是 “我们如何删除更多输出？”
正确的问题是：

“我们如何在 不 让仓库自行删除其证据的前提下，减少每日工作树的噪声？”

这一区别很重要。

在本次检查点期间，仓库卫生工作实际上直接暴露了边缘情况：仅靠 tmp_* 和 test_* 之类的命名约定并不足以解决问题，因为有些带这些名称的文件是有意被追踪的。这正是清理策略必须 明确 而非仅仅是愿景的原因。

检查点的更改

仓库清理提交 8b2e3fc（2026‑03‑19）让这一界限更加明确。更改本身很简单，但背后的模型才是关键。

1. tools/out 现在默认被忽略

• 新的本地运行产生在 tools/out 下的文件不再充斥 git status。
• 已经被跟踪的 tools/out 文件仍然保持正常行为。

这才是关键点：仓库 没有 停止支持已提升的生成产物。它停止了把每个新生成的文件都立刻当作有意义的工作树噪声的假设。

2. 提升现在是显式的

如果一个新的 tools/out 产物确实应该成为仓库证据集的一部分，则现在需要使用 git add -f 进行有意的操作。
这比被动提升更健康。证据应当因为团队决定它是权威的而被提升，而不是因为它恰好在一次实验后出现。

3. 清理保持保守

生成产物清理器现在会处理明显的临时输出，例如未跟踪的：

• tmp*
• test_*
• 旧的 smoke / makecheck / designtest 产物

但它 会跳过任何已跟踪的路径。这层保护比额外的模式更重要。它意味着清理器可以回收可丢弃的杂乱，而不会悄悄删除已提升的证明产物。这是该仓库的正确取舍。清理的目的是提升对证据层面的信任，而不是抹去它。

为什么这对实际移植工作很重要

这并不是为了形式而做的例行工作。当前的技术阻塞点仍然是同样的硬性问题：

• 关闭 958..977 引导缺口
• 修复 986+ 最终画面合成缺口
• 继续用原生回调/状态回放替换采样的吸引段落
• 不断收紧银行和回调合约

这些任务都依赖于能够回答一个乏味但关键的问题：

“我现在应该信任哪个构件？”

在本检查点之后，仓库在回答这个问题上处于更好的位置。工作模型现在更加清晰：

• 已跟踪的生成构件 → 有意的证据
• 未跟踪的生成运行 → 本地工作状态
• 清理 → 删除临时文件，而非证据

这使得后期的考古工作成本更低，因为浪费在重新评估文件是否为：

• 当前的
• 过时的
• 权威的
• 可丢弃的

这在项目拥有多个同步进行的层面时尤为重要：

• ROM 考古
• C/SDL 运行时回放
• 桥接提取
• 渲染器验证
• 游戏帧追踪

没有卫生措施，这些层面会相互混淆。有了卫生措施，它们则会相互强化。

下一个清理目标是可移植性

此检查点并未完成整个清理路线；它仅关闭了一个重要的切面：生成的证据现在更加有意图。

路线图中接下来的可移植性工作仍然清晰：

• 从已发布的脚本和 Makefile 中移除硬编码的个人 Mesen 路径
• 保持验证输出的隔离性和可复现性
• 继续对 … 进行 intro‑side 考古

（…计划的其余部分将在下一个检查点继续。）

更清晰的工作流

那是正确的顺序。

仓库首先需要停止对每个本地生成的文件发出警告。现在它可以继续让推广的工具更少机器特定化。

为什么这值得完整检查点

类似的项目常常低估清理工作，因为它并不会直接产生更好的帧。
那是短视的想法。

当仓库的输出表面不清晰时，之后的每一次成功都更难被信任。当提升是明确的而清理是保守的时，仓库在区分以下方面会变得更好：

• 证据
• 草稿
• 进展
• 噪声

这种区分是产品的一部分。

对于基于逆向工程的移植项目，目标不仅是让帧看起来正确。目标是使这些帧背后的推理易读、可复现且易维护。

这个检查点使仓库朝着该方向前进。