2026 年 4 月，知名跨平台游戏开发库 SDL（Simple DirectMedia Layer）正式实施了禁止 AI 生成代码贡献的策略，成为开源社区应对大语言模型代码提交风险的最新案例。这一策略不仅涉及贡献者协议的更新，更与 GitHub 的代码签名验证机制形成联动，为开源项目提供了一套可供参考的工程实践范式。
策略背景与核心条款
SDL 项目在 2026 年 4 月通过 GitHub Issue #15350 公开讨论后，由维护者 Ryan C. Gordon（网名 Icculus）主导创建了 AGENTS.md 文件，明确规定了 AI 生成代码的禁止条款。该政策的直接导火索是社区发现部分近期贡献可能使用了 Claude Code、GitHub Copilot 等 AI 工具，且在代码审查过程中出现了 AI 生成的痕迹。
政策核心条款包括以下要点：首先，明确界定 “AI” 涵盖大语言模型范畴，包括 ChatGPT、Claude、Copilot、Grok 等工具；其次，规定 AI 不得用于生成贡献代码，但可用于辅助识别代码问题；再次，强调 AI 生成代码基于来源不明的训练数据，可能与项目的 Zlib 许可产生冲突；最后，要求所有 Pull Request 提交者确认其为代码作者并同意按 Zlib 许可证贡献。
PR 模板的工程实现
除 AGENTS.md 之外，SDL 项目还在 Pull Request 模板中新增了贡献来源确认机制。PR #15353 合并后，提交者需要在 PR 界面勾选确认框，声明所提交的内容不包含来自 AI 或其他外部来源的代码。这种将政策嵌入工作流程的设计，使得政策执行从被动审查转向主动声明。
从工程实现角度看，PR 模板的修改涉及。github/PULL_REQUEST_TEMPLATE.md 文件的更新。该模板在贡献者提交 PR 时强制展示确认选项，虽然不涉及技术层面的代码审查，但通过流程约束形成了政策威慑。对于实际违反政策的情况，项目维护者保留在审查阶段拒绝贡献的权力。
代码签名验证的补充作用
SDL 项目的 AI 禁止策略并非依赖单一技术手段，而是与 GitHub 的提交签名验证机制形成互补。GitHub 支持 GPG、SSH 和 S/MIME 三种签名方式，对提交进行密码学验证。当提交者使用已绑定的签名密钥提交代码时，GitHub 会显示 “Verified” 标记，使审查者能够确认提交者的身份真实性。
然而，需要明确的是，GitHub 的签名验证机制本身并不区分代码是人类作者还是 AI 生成。它验证的是 “代码确实来自持有该密钥的人”，而非 “该人是否使用 AI 生成了代码”。因此，签名验证在这一场景下发挥的是辅助而非主导作用：通过确认贡献者身份，为事后追溯提供依据，但不直接实现 AI 代码的自动检测。
开源项目的工程参考要点
对于希望实施类似策略的开源项目，SDL 的实践提供了以下工程化建议：
政策文档化：创建 AGENTS.md 或 CONTRIBUTING.md 章节，明确 AI 工具的使用边界。文档应具体列举允许和禁止的使用场景，避免模糊表述带来的执行歧义。
流程嵌入：在 PR 模板、CI/CD 流水线或贡献检查表中加入政策确认环节。自动化流程的引入可以降低维护者的审查成本，同时形成贡献者的合规意识。
签名机制建议：鼓励贡献者配置提交签名，虽然这不能直接阻止 AI 代码提交，但可以建立贡献者身份与提交行为的关联记录，为后续审计提供基础。
社区教育：SDL 在政策中特别指出 AI 倾向于 “幻觉” 问题，这要求项目在实施禁令的同时，帮助贡献者理解政策背后的技术原因，避免简单的一刀切引发社区抵触。
实践中的局限性
需要正视的是，SDL 的政策在技术上难以实现绝对防御。AI 生成代码的识别本身是难题，项目目前主要依赖贡献者主动声明和人工审查。由于大多数开源项目缺乏对提交内容的自动化 AI 检测能力，政策的执行效果在很大程度上取决于社区成员的自觉配合。
此外，政策对 “AI 辅助” 与 “AI 生成” 的边界定义也需要持续完善。SDL 允许使用 AI 识别问题，但如何界定 “识别问题” 与 “生成解决方案” 之间的界限，在具体操作中可能产生争议。
资料来源：Phoronix 报道（https://www.phoronix.com/news/SDL-Says-No-To-AI-LLMs）