企业官网建设流程全解析

WiiCompiled 是用静态重编译把《马里奥赛车 Wii》（Mario Kart Wii）原生移植到 PC 的开源项目——没有模拟器、没有 JIT，运行时不存在任何 PowerPC 指令。如果你想向它提交代码，这份 WiiCompiled 社区贡献指南会讲清楚两件事：如何写出一次通过审查的 PR，以及项目为何坚持「零AI滥作」原则。

📌 项目速览：代码都放在哪里

动手之前，先花一分钟认识仓库结构，你的 PR 大概率落在前两个目录：

[!TIP] 完整构建流程见 translator/README.md，macOS 用户有专门的逐步教程 docs/building-macos.md。

🧭 贡献前必读：四条总纲

CONTRIBUTING.md 只有不到 60 行，但每一条都是硬规则，核心是「短版本」四条：

1. 代码按质量评判，不按来源评判——不关心代码是怎么产生的；
2. 你必须能理解并解释你提交的每一行；
3. PR 描述和审查回复必须出自你本人，不得由 AI 生成；
4. 凡是触碰游戏行为，标准只有一个：与真机行为一致。

🤖 「零AI滥作」原则：AI 辅助的边界在哪里

这是 WiiCompiled 最有辨识度的贡献规则，原文的立场非常干脆："AI slop 和 human slop 享受同等待遇"——低质量代码无论来自 AI 还是人类，一律不合入。

但这不等于禁止使用 AI 工具。README 中明确写道：项目自身在开发中使用了 AI 编码工具。区别在于，AI 生成 ≠ AI 负责。使用 AI 工具时，CONTRIBUTING.md 划定两条红线：

• 必须能解释你的改动。审查者问"这一行为什么存在""这个函数在做什么"，如果你答不上来，PR 会被关闭。"是 AI 写的"不构成解释。
• PR 描述必须自己写。描述的存在意义是让审查者知道"你改了什么、为什么改"。生成式描述的特征是"什么都描述了，什么都没解释"，这类 PR 同样会被关闭。

一句话总结：AI 是你的打字加速器，不是你的责任人。

✅ 如何写出一次通过审查的 PR

把 CONTRIBUTING.md 的 Pull Requests 小节拆解成可执行清单：

• 1 个 PR = 1 个变更。保持聚焦，小 PR 审查快，捆绑式大 PR 是审查噩梦；
• 说清 what 和 why。有对应 issue 就引用它；
• 影响游戏行为的改动，准备好证据。目标是与真机行为完全一致，审查时你可能需要用真机对比、运行日志等手段证明改动没有偏离原版游戏；
• 平常心对待审查意见。"针对代码，不针对人 :)"——这是原文里的说法。

另外两个容易踩的坑：

• 别修原版游戏自带的 bug。目标是"和真机行为一模一样"，只报这个移植版与原版的差异（详见 README.md 的 FAQ）；
• 别搞错项目的边界。WiiCompiled、Wheel Wizard、Retro Rewind 等生态项目各自独立开发，各有各的贡献规则和 AI 使用规则，这边适用的条款不自动适用到那边。

🔨 动手前：本地跑通构建与测试

好消息是：WiiCompiled 的默认测试套件不需要游戏数据、不需要任何二进制文件、甚至不需要宿主 C++ 编译器，改翻译器代码的门槛非常低。

环境要求（见 translator/README.md）：

• .NET 8 SDK
• CMake ≥ 3.16 + Ninja
• Clang / LLVM（随附构建使用 LLVM-MinGW，目标x86-64-v3）

三步验证环境：

# 1. 构建翻译器 dotnet build translator/Translator.sln -c Release # 2. 跑默认测试套件（无需游戏文件） dotnet test translator/Translator.sln -c Release

测试覆盖解码器、IR/SSA、代码生成辅助、合成输入解析器、项目清单加载等，详见 translator/tests/README.md。测试细节建议先读这一份再提交 PR。

🚫 红线清单：这些绝不能进 PR

1. 绝、不、要在 PR、issue 或项目任何地方包含 Nintendo 代码、资源或游戏数据——原文明确写着"No exceptions"；
2. 贡献即同意代码以GPL v3.0（LICENSE）授权，与项目其余部分一致；
3. 需要游戏文件时，只使用自己合法导出的干净 PALRMCP01光盘镜像，仓库和发行版中不含任何任天堂资产。

📚 延伸阅读

按这套规则来的 PR——小而聚焦、描述是自己写的、每行代码你都能解释、行为改动有证据——基本就是 WiiCompiled 社区期待的"通过审查的样子"。祝你第一次 PR 顺利合入！