跳至主内容
非官方测试版翻译

本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →

Jellyfin LLM/"AI"开发政策

过去一年左右，LLM 作为开发工具的崛起势头迅猛。Claude Code 和 ChatGPT 等工具的强大功能和灵活性，为经验丰富的开发者和新手开发者都提供了诸多便利。但这并非没有代价。

Jellyfin 项目自诞生之初就高度重视代码质量——可读性、简洁性和精炼性。这主要依靠专业团队的辛勤付出，旨在修复项目所继承的原始代码库（恕我直言）的严重缺陷：极其脆弱、结构混乱如意大利面、且存在过度设计的复杂性。

我们观察到 Jellyfin 生态系统中使用 AI 的贡献者数量激增（涵盖服务器和客户端），同时也注意到对 LLM 的普遍质疑和担忧。特此制定本政策，明确说明我们对社区内可能使用 LLM 的贡献和互动的期望。这些规则适用于所有官方项目和社区空间。

通用准则​

  1. 严禁在任何直接沟通中使用 LLM 生成内容，包括：

    • 问题或评论
    • 功能请求或相关评论
    • PR 正文或评论
    • 论坛/聊天室等平台的发帖或评论

    简言之，发布任何上述内容时，必须使用自己的语言进行解释说明，而非直接粘贴 LLM 的输出。我们希望您理解自己发布的内容。违反此规则将导致相关条目被关闭/删除。

    若您难以用英语准确表达，LLM 辅助翻译可例外处理。请明确标注（例如"我使用 LLM 从母语翻译此内容"），并尽可能同时发布原始语言版本。

  2. LLM 生成的代码贡献需遵守下文详细规定，但核心原则是"纯凭感觉的编码将被拒绝"且"您需对提交内容负责"。我们将据此审查。若代码质量低劣，将直接予以拒绝。

向官方项目提交的 LLM 代码贡献​

使用 LLM 生成代码存在争议且解读各异。本指南旨在确保：熟练开发者合理使用这些工具时不受过度限制，同时防止违反核心理念的低质量贡献泛滥。此政策适用于所有 Jellyfin 官方项目。

  1. 贡献内容应精炼且专注。若 PR 声称解决 X 问题，却涉及无关的 Y 和 Z 部分，将被拒绝。这包括对无关功能的意外修改——通常是提示词表述不当或过于宽泛的典型表现。同样，大型 PR 必须拆分为多个小型可管理的 commit 以便审查和追溯。

  2. 必须严格遵守格式和质量标准。冗余的无意义注释、面条式代码、空行多余空格等现象将被视为纯 LLM 输出而拒绝；提交前您需清理这些痕迹。同时切勿提交 LLM 元文件（如 .claude 配置文件）或其他编辑器生成的非代码文件。

  3. 您必须审查输出结果，并能在 PR 正文中不使用 LLM 生成内容的情况下解释改动内容及原因。PR 正文（及 commit 信息）应为其他开发者提供变更背景，既然署您之名，我们需要您本人的阐述而非 LLM 的套话。若您无法解释 LLM 的改动意图，我们不会接受此变更。

  4. 所有变更必须经过测试。代码应能正确编译运行，否则将被拒绝。您还需明确测试被修改的功能。

  5. 您必须能够且愿意处理审查反馈，并根据要求实施建议的修改。实际应用中，如果您不了解具体修改内容或原因（参见第 3 条），从而无法亲自落实建议修改或参与讨论，我们将拒绝接受此类变更。简单地将审查反馈丢给 LLM 并期待输出结果"足够好"的做法是不可取的。

  6. 功能开发或重构需要开发者深入理解变更内容及其原因。审查者能明显识别出开发者在不理解代码逻辑情况下进行的修改，此类提交将被拒绝。如第 1 条所述，PR 必须包含多个独立提交。审查后，我们将视情况压缩提交记录。重大变更还需遵循其他开发政策（讨论、审查、实施、测试流程）。

  7. 审查者始终保留最终决定权。若您的 PR 因任何原因（过度复杂、规模过大、提交记录压缩不当等）无法被合理审查，都将被拒绝——无论是否使用 LLM 辅助均适用此规则。您将被要求将此类 PR 拆分为多个独立 PR，每个提交仅包含一组聚焦且简洁的变更。

黄金法则如下：切勿仅凭模糊的凭感觉的提示就放任LLM修改代码库，然后原封不动地提交结果。这是懒惰的开发行为，在我们看来必然会产生低质量贡献，我们对这类劣质内容毫无兴趣。请付出切实努力，否则请勿提交。再次强调，您可以自由使用LLM作为辅助工具，但绝不能将其作为代码变更的唯一来源。

社区分享的 LLM 生成工具/客户端等​

您当然可以自由处理非官方个人项目。但在社区内分享此类项目时，我们将强制执行以下规则：

  1. 任何主要由 LLM 开发的项目必须明确标注。用户有权自行决定是否接受此类项目。若您显著使用 LLM 进行辅助开发（如文档编写、代码格式化等），我们同样建议进行披露。

  2. 您必须遵守许可证要求。若项目基于现有代码开发，遵循其许可证非可选。您必须完整标注所有贡献者，不得篡改 Git 历史记录，也不得将未决的第三方变更作为自己的提交（例如复制代码后直接提交）。违反此规则将导致项目被拒，并可能被逐出组织及社区。我们对代码窃取和恶意署名行为采取零容忍政策。

  3. 社区成员不得仅因项目由 LLM 生成就进行举报，也不得发起反 LLM 的"猎巫行动"。如前所述，此类项目允许存在，您可自行选择是否"支持"相关工具/客户端等。

  4. 管理员不会对第三方项目扮演"LLM 警察"，通过吹毛求疵来"寻找 LLM 贡献痕迹"——这是枯燥且浪费资源的。实践中，第 1 条规则由项目作者自主执行，第 3 条规则亦应据此理解。若您仅怀疑某工具违反第 1 条，请点踩/忽略即可。仅当我们发现公然违反第 1 条时才会干预，但我们不会逐行审查代码玩"这是否 LLM 生成？"的猜谜游戏。无论是否涉及 LLM，第 2 条规则都将强制执行。