将《测试驾驶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 中被跟踪的文件仍能正常工作。
这才是关键所在：代码仓库通过……
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
