Jellyfin发布LLM/AI开发政策指南

在过去一年左右，LLM 作为一种有用的开发工具的崛起是显著的。Claude Code 和 ChatGPT 这样的工具的强大性和灵活性为经验丰富的开发者和新手开发者都提供了许多功能。但这也带来了权衡。

从一开始，Jellyfin 项目就把代码质量放在首位——可读性、简洁性、简明性。这主要是由一个专注的团队通过手工努力推动的，其动力来自于对 Jellyfin 基于其上的代码的改进的渴望，那些代码非常脆弱、意大利面式代码随处可见，而且容易过度工程化导致复杂性爆炸。

我们看到越来越多的贡献者在 Jellyfin 生态系统中使用 AI，包括服务器端和客户端，同时也看到对 LLM 普遍的批评和担忧增加。此时我们制定这一政策，明确说明对可能使用 LLM 的社区内的贡献和互动，我们的预期和愿景。这些规则适用于我们所有的官方项目和社区空间。

直接通信中禁止 LLM 输出

LLM 输出在任何直接通信中是明确禁止的，包括以下内容：

• issues 或 comments
• feature requests 或 comments
• pull request bodies 或 comments
• forum/chat/等 posts 或 comments

简而言之，如果你发布这些内容中的任何一个，输出必须是你自己的言辞、解释、描述等，而不是 LLM 输出的逐字转储。我们期望你理解你发布的内容。违反此规则将导致违规项目的关闭/删除。

对于 LLM 辅助的翻译，如果你在用英语准确传达意图方面遇到困难，将作一个例外。请明确注明这一点（"我用 LLM 从 MyLanguage 翻译了这个"），并且如果可能的话，也用你的原始语言发布。

LLM 代码贡献的一般原则

LLM 代码贡献受到下面更细致的规则约束，但总体原则是"纯粹的'感觉编码'将被拒绝"和"你对你提交的内容负责"。我们将以这种方式进行审查。如果代码看起来很糟糕，它会因此被拒绝。

官方项目的 LLM 代码贡献

LLM 用于代码是有争议的，有很多解释的余地。这些指南是我们为了确保那些寻求使用这些工具作为正当辅助的知识渊博的开发者不被过度阻碍，同时也防止持续涌入的劣质贡献违反我们上述核心理念的最佳努力。这些适用于所有官方 Jellyfin 项目。

1. 贡献应该简洁专注。 如果 PR 声称针对 X，但同时也涉及无关的 Y 和 Z，它将被拒绝。这包括对无关功能的附带更改，这是措辞不当或过于宽泛的 prompt 的典型特征。同样，大型 PR 必须分解成多个小的、可管理的 commits，用于审查和历史记录的目的。

2. 必须坚持格式和质量标准。 过多无用的注释、意大利面式代码、空行上的空格等将被解释为纯 LLM 输出并被拒绝；你必须在提交前清理这些混乱。同时不要提交 LLM metafiles（例如 .claude configs）或任何其他编辑器生成的非代码文件。

3. 你必须审查输出，并能在 PR body 中解释——不使用上述 LLM 输出——正在改变什么以及为什么。 你的 PR body（以及如果适用的话，commit bodies）应该向其他开发者提供关于为什么做出改变的背景，如果你的名字在上面，我们要的是你的言辞和解释，而不是 LLM 的。如果你无法解释 LLM 做了什么，我们对这个改变不感兴趣。

4. 改变必须经过测试。 代码应该能够正确构建和运行，否则会被拒绝。你还应该明确测试被修改的功能。

5. 你必须能够且愿意处理审查反馈并根据需要实现建议的改变。 这在实践中意味着，如果你不知道改变了什么或为什么（见 #3），因此无法实现建议的改变或自己讨论它们，那么我们对这个改变不感兴趣。只是将审查者反馈转储到 LLM 中并期望输出的结果"足够好"是不行的。

6. 功能或重构需要对正在改变的内容和为什么改变有深入的理解。 对于我们的审查者来说，识别出在开发者不理解正在发生什么的情况下做出的改变是显而易见的。这些将被拒绝。如 #1 所述，PR 必须包含多个离散的 commits。在审查后，我们将酌情 squash commits。大型改变还必须遵循我们的其他开发政策（讨论、审查、实现、测试流程）。

7. 最终判断权始终在审查者手中。 如果你的 PR 因任何原因无法被合理审查（过度复杂、大小、squashed commits 等），它将被拒绝，这对 LLM 辅助的 PR 和非 LLM 辅助的 PR 一样适用。你将被要求将这样的 PR 分解成多个 PR，每个 PR 呈现一个专注、简洁的改变集合。

黄金法则是这样的：不要只是用一个模糊的感觉 prompt 在代码库上放松 LLM，然后按原样提交结果。 这是懒惰的开发，总是会从我们的角度产生质量差的贡献，我们根本不感兴趣这样的劣质代码。要么付出努力，要么请不要麻烦。再次，你可以自由地使用 LLM 来协助你，但不是作为代码改变的唯一来源。

社区中共享的 LLM 生成的工具、客户端等

你当然可以随意对你自己的非官方项目做任何你想做的事。然而，我们将对在我们社区内共享的此类项目强制实施以下规则。

1. 任何主要由 LLM 开发的项目应该明确标记为这样。 由用户自己决定这对他们是否可接受。如果你明显地为 LLM 辅助使用了一部分（例如文档、格式等），我们也倾向于披露。

2. 你必须尊重并遵循许可证。 如果你的项目基于现有代码，遵循其许可证不是可选的。你必须充分承认现有贡献者的所有贡献。不要篡改 Git 历史，不要将第三方未解决的改变作为你自己的提交（即通过复制代码然后提交）。这样做将导致不仅仅是拒绝，而是被我们的组织和社区禁止。我们对代码盗窃和不诚实的归属尝试有零容忍政策。

3. 对于社区成员，不要仅基于 LLM 生成的基础报告 LLM 生成的工具、客户端等，也不要参与反 LLM"猎巫"。 如上所述，这是允许的，由你决定是否"支持"所述工具/客户端/等。

我们（主持人）不会对第三方项目进行"LLM 警察"，通过吹毛求疵来尝试"找到 LLM 贡献"以遵循我们这里的规则；这是乏味的，是对我们的时间和努力的浪费。这在实践中意味着规则 #1 取决于作者，规则 #3 必须在这种精神下理解。如果你只是怀疑一个工具是由 LLM 生成的并违反规则 #1，那就踩踩脚/忽略它并继续。只有当我们看到明目张胆地破坏规则 #1 时，我们才会强制实施，但我们不会逐行通过代码进行"这是 LLM 生成的吗？"游戏。无论 LLM 与否，规则 #2 将始终被强制执行。