[Feature] [Doc] 更新贡献指导

[ToobLac]

概述 | Summary

更新贡献指导，使其对 PR 的提出与推进具有约束与指导意义，并能成为维护者处理 spam PR 的根据。

原因 | Reason

现在的 Contributing.md 只是作为对环境配置和一些变量的介绍，对 PR 贡献不具有指导意义。同时随着 AI Code Agent 的发展，HMCL 仓库中涌现出一大批纯 vibe 的无效 PR，造成了一定困扰。

根据 #6598 中的讨论，我认为，无论是否将 AI spam 看作恶意的、无论要针对其采取何种措施，对贡献指导进行与时俱进的更新都是必要的。这样能够减少因标准不统一产生的争执，增强社区凝聚力。

详情 | Description

• 明确 vibe coding 有关条款，对纯 vibe PR 进行明确限制
• 对 PR 的不同种类内容（新功能/问题修复/重构）分别进行限制，明确什么样的 PR 值得做、值得审，让维护者和贡献者都能将时间精力花在更有意义的内容上
• 明确 PR 格式 关于改进 HMCL 仓库维护的意见 #4921 (comment)

---

最后明确以上内容全都不是 AI 生成的，虽然我感觉我说话确实有点像 AI（（（

欢迎各位积极讨论

[3gf8jv4dv]

其实我早就想起草，但忙于其他事情加上一些顾虑暂时搁置了。

偶尔也隐隐感觉，肯定会有一个「蝴蝶」引发这场讨论，只是没想到来得这么快。

我抽时间尽早起草一个草稿吧。同时大伙有兴趣的，可以先找找其他项目的 Contributing.md 参考。

[3gf8jv4dv]

补充一下我的看法。我认为 Contributing.md 不仅局限于贡献者 (包括 issue 和 PR 作者)，而且也要对维护者有一些约束。

[TheWhiteDog9487]

emmm看描述最后有可能变成很严肃的那种文书？
我不太清楚各位想要的最终结果长啥样，但是我先提出一个意见。

除非绝对必要，否则这种文档不应该过于冗长，也不应该看起来给人带来很严肃的感觉。

理由是过于冗长的文本会大幅降低人类读完的...耐心？举个例子，某个Wiki打开编辑页面会弹出一个编辑守则，虽然初心是好的，但是看到总共三十多个规则还是直接把我这个没参与过贡献的人吓跑了。
故此，我认为这样的文档做到明确大致的规则即可，太详细的话会产生一定程度的负面影响。

[3gf8jv4dv]

emmm看描述最后有可能变成很严肃的那种文书？

不知道其他人怎么想，但我也不太希望看到那种风格的。

除非绝对必要，否则这种文档不应该过于冗长，也不应该看起来给人带来很严肃的感觉。

这点我是非常赞成的 🙏

[ToobLac]

除非绝对必要，否则这种文档不应该过于冗长，也不应该看起来给人带来很严肃的感觉。

严肃性我觉得还是要有的，但是严肃也不代表要冗长。

另外这里的严肃不是指官方/大企业文书那种正式性，而是要让阅读者能感受到这是一份有效力的文件，类似社区公约

[WhatDamon]

对于贡献文档 Vibe Coding 方面，我让 AI 整理了一下，分享一下思路：

1. AI is fine（接受 AI）：明确项目接受 AI 贡献，但一定要说明这不是无条件的
2. Human-in-the-loop（人类在环）：贡献者原则上必须理解并验证所有提交内容，强调理解是底线，至少知道代码在干什么
3. You own what you submit（你对你提交的内容负责）：贡献者对 AI 辅助开发的部分承担全部责任，不应该，也没有理由推卸到 AI 身上
4. Quality more than quantity（质量高于数量）：质量优先，保证代码基本鲁棒性，禁止 Slop（一定要单列一个章节说明什么是 Slop）

另外还有一个相对不是特别重要，但是值得考虑的是透明度：是否要求指出使用了什么 AI 工具、模型，在哪里指出（若要求披露，我个人倾向于 PR 而不是代码中披露）

还有就是，如果可以，在 AGENTS.md 中告诉 LLM，如果用户给的需求特别潦草，或者对部分细节有疑问，一定要追问，如果用户让 AI 自己看着办，无论如何都一定要拒绝，来尽可能避免那些愚蠢的面向结果 Vibe Coding（这反映的是不会用 LLM）

https://github.com/melissawm/open-source-ai-contribution-policies 里面给了不少开源项目的 AI 政策信息，可以作为参考

具体对 Slop，我结合自己 Vibe Coding 的 deslop 经验，也让 AI 整理了一下分享：

1. Simplicity First（简洁优先）：能用最少的代码解决的问题，就不该用冗余的代码解决，复用优于重写，精简优于堆砌
2. Cohesion & Granularity（内聚与颗粒度）：模块之间保持低耦合，模块内部保持高内聚，每个 PR 聚焦单一问题，每个模块承担明确职责
3. Every Line Matters（每一行都有价值）：代码库中不应存在无意义的死代码，每一行被提交的代码都必须有明确的存在理由和实际用途
4. No Oversights in the Logic Chain（逻辑链无疏漏）：每一行代码的逻辑都应该是经过深思熟虑的，疏漏可以原谅，但系统性疏忽不可接受
5. Comments That Matter（注释有意义）：垃圾注释比没有注释更糟糕，应该没人愿意看 i += 1 后面跟的注释是 // i 在这里 +1 吧，当然 JavaDoc 也需要注意

另外我还建议引入惩罚机制：基本上就是轻度提醒一下，如果贡献者听取了，那不妨碍接下来的工作；如果严重并且多次这么干，建议采取严重警告，对于他的 PR 优先当纯 AI 写的且无人类在环对待，直到问题改善；如果再变本加厉就限制贡献，甚至可以像 Ghostty 那样直接公示这些“罪大恶极”之人

另外就是上面所有的原则应该也应同时适用于维护者，而非单一限贡献者

还有语气方面，不建议过于严肃，最好的情况是对 AI 贡献欢迎语气，原则问题上保持坚定语气

---

顺便一说，上述的帮助我整理思路的 AI 模型是 DeepSeek V4 Flash 0731，这样说一下算是践行了“透明度原则”吧。总之欢迎从我这里挑刺（看看按照这个逻辑可以钻什么空子），反驳一些可能不太适合的（有些点可能过于理想化了），或者继续补充

按照我的思维，AI 不是不动脑子解决问题工具，理想化来说，最好是能够在 Vibe 过程中有所收获，学习到点东西

[Minecraft269]

不是广告 是真心推荐

看了来自 WhatDamon 的思路 关于

Simplicity First（简洁优先）

我有一个仓库推荐一下 andrej-karpathy-skills 这是一个插件(SKILL) 是一个SKILL文件 它可以让你的Agent只写有用的代码 不写冗余代码 这个SKILL不像其它的一些比较大的PLUGINS(superpowers mattpocock-skills) 它仅有一个有效文件