Open Source 与能动浪潮
Source: Dev.to
为什么政策重要
虽然我们认识到 AI‑辅助工具（如 Copilot、ChatGPT 或 Claude）可以成为开发的强大助力，但它们也会促成“低投入”或“随机”的贡献，这些贡献增加了维护者的负担，却没有相应的价值提升。
为了乐趣 和 收益而阅读 AI‑生成的 PR
开源一个项目（或将其捐赠给基金会）通常有助于其长期存续和可持续性。如果你解决的问题具有相关性且贡献者能够找到你的项目，你很可能会受益于更多的关注和外部视角。
但随之而来的可见度也带来了…… 代理浪潮：AI‑生成的 PR 和社区渠道中的机器人。
关于 CloudNativePG
- 它是什么 – PostgreSQL 的 Kubernetes 运算符。
- 开源时间 – 2022 年 4 月，采用 Apache 2.0 许可证。
- 星标 – GitHub 上约 8 000 个，表明关注度很高。
- CNCF 状态 – 于 2025 年 1 月加入云原生计算基金会，成为 Sandbox 项目。（CNCF 成熟度等级：sandbox → incubating → graduated；每一步都带来更多使用和可见度。）
“Kubernetes 维护者阅读恶意评论”
本着娱乐性演讲 Kubernetes Maintainers Read Mean Comments 的精神——演讲者朗读最刺耳的 GitHub 评论——我们（CloudNativePG 一线 triage 成员）决定朗读我们在伪装成贡献的 AI 废话中遇到的最糟糕的内容，以 娱乐和获益 为目的。
以下是我们发现的几条“宝藏”。
1. Copilot PR
“我使用 Copilot 实现了这个修复，因为我根本不懂 Go。”
无可奉告。
2. Massive PR
一个 PR 改动 100 个文件，并新增近 23 000 行？不，谢谢。
3. 缺少 Issue 引用的上下文
AI 试图加入对某个 Issue 的引用，却没有正确的链接，也没有说明该 Issue 应该由 Renovate 管理的上下文。
4. 抱怨另一 AI 的版本锁定
AI 抱怨另一 AI 锁定了版本。
5. 冗余的测试建议
AI 建议添加一个测试来验证某函数已经有单元测试，却忽略了在 Issue 评论中讨论的需要添加的 E2E 测试。
要点
- 信号 vs. 噪声: AI 可能产生大量低价值的 PR，浪费维护者的时间。
- 政策很重要: 明确的 AI 内容政策有助于设定期望，降低维护负担。
- 人工审查仍然必不可少: 即使是高级模型也缺乏经验丰富的贡献者所具备的上下文感知能力。
如果你在自己的项目中遇到类似的 AI 生成噪声，欢迎在评论中分享你的经历！
AI 创建了一个 PR，内容基本与左侧的 PR（由一位维护者提交）相同，只是晚了四个小时。
AI 是否知道第一个 PR 并在未注明原贡献者的情况下直接复用？还是贡献者在提交自己的方案前未检查该问题是否已经解决？
还有：为什么会有这么多空格？
这些例子可能会让人发笑，但有些 PR 看起来很棒，直到测试中出现意外行为，而作者无法解释发生了什么，因为他们并没有编写这些代码。
更令人失望的是，在 LFX 导师计划中出现了大量虚假申请。该计划旨在赋能真实的人，为他们提供成长专业技能、晋升贡献者阶梯所需的工具。然而，我们却浪费了时间与完全不合格的申请者互动。
如果你是人类，请继续阅读
如果你想为 CloudNativePG 做出贡献，这里有几种参与方式：
- 浏览我们的 GitHub 组织 并挑选符合你兴趣和技能的议题。
- 加入 CNCF Slack；所有以
cloudnativepg为前缀的频道都是我们的。 - 查看 办公时间和开发者会议的日历。我们非常欢迎你的参与，所有会议记录都是公开的。