如何开始为反编译项目做贡献

选择一个你感兴趣的目标，再选择一件能验证结果的小事。首次贡献不必是困难的匹配函数。复现构建、补充缺失步骤或提交准确的测试报告，同样能帮助下一位贡献者。

找到项目后，以它自己的工具、分支和贡献规范为准。DecompHub 帮助发现项目，不分配任务，也不代表维护者。

确认环境适合

在“我能帮忙”中可以填写可用的 macOS、Windows、Linux 环境。这是私密的匹配偏好，不保证仓库能在你的机器上构建。

核实准确的操作系统、编译器和目标修订版。Super Mario 64分别说明 Linux、macOS、容器流程与版本输入。另一个分支的教程可能得到看似合理、却对应错误目标的构建。

记录使用的提交和工具版本。提前确认是否需要原始游戏数据或特定设备。目录不提供原版软件或资源。

先阅读贡献规则

查找 CONTRIBUTING、仓库文档和评审流程。GitHub 的说明介绍了这些规范的展示位置。

确认是否需要先开 issue、使用指定分支、遵守格式或运行特定验证命令，也要遵守项目对 AI 生成贡献的政策。不要照搬其他项目的规则。

好的入门任务应有明确完成条件：构建通过、一个函数匹配、修正一条说明，或提供能复现失败的测试。

留下可复现的基线

修改前先按上游步骤验证，记录命令、目标版本、工具版本和结果。如果原始状态已失败，应将它与后续改动区分开。

报告问题时写清预期、实际结果和最小复现步骤，只附相关日志。“这条命令在这个工具链的这一步失败”比“项目不能用”更容易处理。

选择能提供证据的贡献

• 文档： 修正亲自验证过的步骤、解释不清的前提条件或错误链接。
• 测试： 在现有硬件或系统上执行公开测试流程，记录版本和结果。
• 匹配代码： 从理解得了的小函数开始。decomp.me便于试验，但成功结果仍需通过项目自己的验证。
• 工具： 改善重复操作或错误提示，同时保持项目需要的行为与验证方式。

objdiff提供本地比较流程。优先使用所选仓库要求的工具，不要仅因熟悉而额外引入另一套系统。

提交聚焦的改动

说明具体问题、修改后的行为和检查方式。匹配改动应注明目标与比较；文档改动应说明实际执行了哪些步骤。未测试的部分也要明确写出。

不要把首次贡献扩展成无关文件的大清理。若项目安静或已归档，应查看官方后继或继续开发的分支。未收录的仓库可提交官方 URL；测量含义见进度报告指南。