AI 时代的开源维护
AI 确实改变了软件开发的格局。 比以往任何时候都更多的人利用 AI 为他们使用的项目贡献补丁。 对我来说，这是一件好事，因为更多人会贡献补丁而不是分叉项目或不修复问题。 主要问题是，AI 使代码生成变得快速，但在维护代码库方面几乎没有改进。 在本文中，我们将重点介绍 Kubernetes 社区如何适应 AI 辅助编码的世界。
这一旅程的第一步是制定 AI 政策。这看似平凡且官僚，但有许多 PR 陷入了关于 AI 使用的讨论。 AI 政策有助于引导围绕项目对 AI 立场的讨论，并为贡献者提供明确的信号，指导他们如何负责任地使用这些工具。
Kubernetes AI 政策
Kubernetes 项目已制定 AI 辅助贡献的明确指南， 在创新与问责之间取得平衡。 这些政策旨在保持代码质量并确保人工监督，同时承认 AI 工具可以成为开发过程中有价值的辅助手段。
透明为先
贡献者必须披露何时使用 AI 工具协助创建 Pull Request。 在 PR 描述中简单声明如 "This PR was written in part with the assistance of generative AI" 即足够。 这种透明度有助于审查者理解上下文并进行适当的审查。
人工问责
虽然 AI 工具可以提供帮助，但人类贡献者仍然对每一项更改负全部责任。该政策明确禁止：
- 将 AI 列为提交的共同作者
- 在提交中使用 AI 共同签名
- 添加 "assisted-by" 或 "co-developed" 等尾部信息将工作归功于 AI
这不是为了削弱 AI 作为工具的作用——而是为了保持明确的问责制。 如果出现问题，需要有一个人理解原因并能够修复它。
共同作者的 CLA 强制执行
CNCF 提供了一个工具 来验证每个 Pull Request 上的贡献者许可协议。 AI 代理无法签署这些贡献者许可协议，因此项目采取的一项强制执行措施是为共同作者启用 CLA 检查。 这向审查者提供了一个标志，表明该 PR 尚未准备好合并。
必须有人工参与
这可能是该政策最关键的方面：审查者期望与人类互动，而不是与 AI。 贡献者不能依赖 AI 来回复审查评论。 如果你无法亲自解释 AI 帮助生成的更改，你的 PR 将被关闭。 这一要求确保知识转移发生，并确保贡献者真正理解他们提交的代码。
验证义务
贡献者必须通过代码审查、测试和个人理解来验证 AI 生成的更改。 代码能够运行还不够——你需要知道它为什么能运行并能够维护它。
这些政策反映了对 AI 的成熟态度：将其作为工具拥抱，但永远不要让它取代人类的判断、理解或责任。
自动化 AI 审查
有许多工具可以帮助审查代码。AI Pull Request 工具引入了治理挑战， 因此社区承担的首要任务之一是记录流程， 说明引入新 AI 工具需要什么。 这些工具的主要评估标准之一是找到愿意在 kubernetes-sigs 仓库中试用它们的维护者。 Kueue、JobSet 和 Agent-Sandbox 一直在试验这些工具，以为维护者提供更多支持。
Copilot
许多维护者开始使用的一个工具是 GitHub Copilot。 CNCF 为维护者提供访问权限， 因此这最终成为许多人开始使用的第一个工具。 它在调整审查方面提供了一些良好体验，但该工具也存在一些成长的烦恼。 社区采用的最大障碍是依赖贡献者拥有 Copilot 许可证。 只有维护者能够请求 Copilot 审查，社区无法实现 Pull Request 的自动化审查。 AI 审查工具的目标之一是提供一种维护者无需请求的自动化审查工具。 这表明需要组织控制，而不是依赖贡献者拥有访问权限。
CodeRabbit
在 2026 年年中，Kubernetes 社区已向几个项目推出了 CodeRabbit。 与 Copilot 一样，需要进行一些调整以提供更好的审查，但总体反馈是积极的。 该工具有很多配置可用，其中最有趣的用途之一来自 agent-sandbox。
AI Pull Request 工具可以作为质量门控。贡献者至少可以获得快速抽查审查，而无需等待维护者。 agent-sandbox 已在 PR 上添加标签，以反映仍需要解决 AI 工具的一些评论。
下一步
现实情况是，在开源项目中利用 AI 是一个积极探索的领域。 社区可以使用你的帮助来调整审查工具、评估工具或评估 AI 领域的新兴技术。
我们正在更多探索的一些领域：
- 使用 AI 技能减少维护者倦怠。
- AI 辅助对失败测试进行分类。
- 有助于 Kubernetes 运营方面的技能。
This is a mirror of the original article.