将《测试驾驶II》从超级任天堂移植到个人电脑，第五部分：让生成的证据具有明确意图
这个代码仓库中的下一个清理问题并不光鲜亮丽。
问题出在 git status 上。
截至3月19日，asmdump 已经具备了足够的考古工具，能够生成以下内容：
- 探针追踪记录
- 帧转储数据
- 序列清单
- 设计包
- 渲染器固定数据
- 游戏流程扫描输出
- 片头后期诊断信息
这已是不错的进展，但也带来了一种新的失败模式。如果一个逆向工程仓库每次实验都会生成数百个文件，那么“生成的”就不再是一个有用的分类。
有些生成的文件只是临时草稿。
有些则被提升为正式证据，文档和检查点都依赖它们。
还有些是本地中间运行结果，仅在一天内有意义，之后就该被清除。
如果仓库不能清晰地区分这些类别，进展就难以令人信服。
真正的问题在于模糊性
当前的移植计划已将可维护性视为首要执行路径，这是正确的决策。
问题不在于仓库缺少清理脚本，而在于工作区变得模糊不清：
-
tools/out目录中同时混杂着真实证据和一次性实验数据 - 模拟器输出可能堆积在可变的本地文件夹下
- 即使没有任何实质性改动，新的本地运行也可能淹没工作树
在这种项目中，这种模糊性是危险的。
这个仓库不仅仅是在构建一款游戏，更是在构建关于这款游戏的论证：
- 哪些帧行为已被理解
- 哪些产物具有权威性
- 哪些缺口仍未填补
- 哪些实验仅属草稿
如果工作树无法清晰传达这些区别，考古工作很快就会变得嘈杂混乱。
全面清理并非正确的解决方案
对于这类仓库，人们很容易想到一种诱人的清理方法：
“直接清空 tools/out。”
但在这里，这样做会是个错误。
tools/out 不仅仅是缓存目录，它还包含已被提升为正式证据的文件：
- SDL 运行时使用的序列清单
- 文档引用的证明包
- 渲染器固定数据
- 桥接层可见的片头产物
- OAM 差异报告——如今已成为特定片头后期帧的唯一真相来源
因此，正确的问题不是“我们如何删除更多输出？”
真正的问题应该是：
“我们如何在不教仓库删除自身证据的前提下，减少日常工作树中的噪声？”
这一区别至关重要。
在本次检查点期间，仓库整洁性工作直接暴露了这一边界问题：仅靠 tmp_* 和 test_* 这类命名约定是不够的，因为某些带有这些前缀的文件实际上已被有意纳入版本跟踪。这正是清理策略必须明确具体、而非仅凭愿望的原因所在。
检查点中的变更内容
2026年3月19日的仓库整洁性提交 8b2e3fc 使这一边界变得更加清晰。
这些变更本身很简单，但其背后的模型才是关键：
1. tools/out 现在默认被忽略
tools/out 下的新本地运行结果不再充斥 git status 的输出。
这看似微不足道，却极大地改变了日常工作流程。逆向工程和验证工具现在可以自由地输出本地工作数据，而无需假装每次运行都值得被提升为正式证据。
原本已在 tools/out 中被跟踪的文件仍保持正常行为。
这正是关键所在：仓库通过……
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
