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

Author: DecompHub
Updated: 2026-10-10
Language: zh-Hans
Canonical: https://decomphub.com/zh-cn/guides/contributing-to-decompilation

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

[找到项目后](/zh-cn/guides/finding-decompilation-projects)，以它自己的工具、分支和贡献规范为准。DecompHub 帮助发现项目，不分配任务，也不代表维护者。

## 确认环境适合

在[“我能帮忙”](https://app.decomphub.com/zh-cn/help)中可以填写可用的 macOS、Windows、Linux 环境。这是私密的匹配偏好，不保证仓库能在你的机器上构建。

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

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

## 先阅读贡献规则

查找 `CONTRIBUTING`、仓库文档和评审流程。[GitHub 的说明](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)介绍了这些规范的展示位置。

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

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

## 留下可复现的基线

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

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

## 选择能提供证据的贡献

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

[objdiff](https://github.com/encounter/objdiff)提供本地比较流程。优先使用所选仓库要求的工具，不要仅因熟悉而额外引入另一套系统。

## 提交聚焦的改动

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

不要把首次贡献扩展成无关文件的大清理。若项目安静或已归档，应查看官方后继或继续开发的分支。未收录的仓库可[提交官方 URL](https://app.decomphub.com/zh-cn/submit)；测量含义见[进度报告指南](/zh-cn/guides/understanding-decompilation-progress)。