AI 在开源项目（Postgres）中应扮演怎样的角色？

作者：Alastair Turner，开源数据库爱好者。

原文：https://percona.community/blog/2026/02/26/responsible-ai-for-oss/，Feb 26, 2026

爱可生开源社区翻译，本文约 1500 字，预计阅读需要 5 分钟。

最近，AI 给开源维护者、审阅者乃至贡献者带来的压力一直是新闻热点。我不想再赘述这方面的要点。如果想了解 Postgres 的具体情况，以及低质量 AI 输出如何影响贡献者，可以阅读 Tomas Vondra 最近在其博客上发表的一篇 精彩文章[1] ，其中引用了 Robert Haas 去年在蒙特利尔 PGConf.dev 大会上的一次 精彩演讲[2] 。我在此不再赘述文章内容，这两篇文章篇幅都很短，非常值得一读。

Robert Haas - VP, Chief Database Scientist at EnterpriseDB | LinkedIn

引发我思考本文其余部分的关键点是：

• 低质量的 AI 评审不仅浪费时间，也浪费时间，不仅仅是 AI 的粗糙之处。
• AI 最擅长代码审查，所以代码审查会最先进行，但概念审查应该先进行。

今天 Postgres 也发布了一个非周期性版本。此次发布是因为两周前发布的版本中引入的一些安全修复被发现会导致功能和性能下降。从积极的一面来看，这表明更长的公开补丁审查流程确实能够发现一些原本容易被忽略的问题。然而，总体而言，减少非周期性版本发布，避免给维护者和用户带来不便，会更好。

这两种思路的联系在于审查。审查任何 Postgres 版本周期中包含的安全补丁显然是不同的。那么，如果它的不同之处更适合 AI 辅助呢？

我们知道 AI Coding Agent 可以为此过程做出贡献，因为最近就有一个 Agent 做到了。可惜的是，有点晚了。今天这个非周期性版本中修复的一些问题是，一位贡献者某天早上打开他的 AI Coding Agent，并让它告知他有哪些新补丁时发现的。其中一些补丁在推送到 Postgres 的 Git 源代码控制系统后，对大多数贡献者来说都是新出现的，因为它们是安全补丁，之前没有在公开邮件列表中讨论过。您可能会听到人们用通用漏洞披露（CVE）的缩写来指代这些修复所针对的问题，CVE 是记录这些安全报告的程序。

毋庸置疑，这并非仅仅是下载 Claude Code 或 Gemini Code Assist，安装，然后就能大获成功。要真正发挥这些工具的价值，需要付出大量的努力：设置项目特定的环境至关重要，尤其对于像 Postgres 这样长期运行的项目而言，它有着一些根深蒂固的编码风格。提出正确的提示词也需要对问题领域有相当的理解。此外，还需要人工判断输出的质量。最基本的判断是：是否将代码助手的输出进行代码审查、直接丢弃，还是需要进一步调查。

前两项，也就是纯粹的技术性问题，在首次尝试使用智能 AI 作为编码助手时几乎不可能实现。这是一类全新的工具，每个人都需要学习。然而，讽刺的是，那些更具备第三项特质——判断力——的人，反而更有可能放弃早期的实验，因为这些实验并没有带来任何价值。正是由于人们忽略了第三项工作，才导致 AI 最终被视为开源项目的负担。这并非什么新鲜事，早在我们将大型语言模型应用于代码分析之前，就已经存在确定性的静态分析工具，而它们的误报多年来一直在补丁审查过程中造成大量噪声干扰。

在上面我链接的演示文稿中，罗伯特列出了补丁审查的四个关键高层次原则：

• 从全局入手
• 一致性至关重要
• 做一个悲观主义者
• 践行维护精神

这两个原则中的中间两个，即 一致性 和 悲观主义，最容易受到 AI 干预，也是审查安全补丁最重要的两个原则。

当一段代码被提交后，全局决策和维护原则方面的决策就已经做出。如果之后发现这段代码会使 Postgres 用户面临安全风险，那么审查解决方案就变成了从各个角度对新代码可能造成的影响进行悲观评估。正是在这方面，Claude Code 不仅在上述案例中发现了回归问题，还创建了一个小型复现示例来触发该问题。

编写和审查安全补丁是一项极其繁琐的工作。Postgres 领域的顶尖专家们负责编写和审查这些补丁，但由于任何有关潜在漏洞的信息都需要严格控制，因此这个团队规模很小。修复的时间表也可能非常紧迫。这两个因素都限制了协作和多阶段审查的机会。在这种情况下，引入额外的 AI 眼睛来审查这些补丁可能非常有用。

由真正了解问题领域的人员进行设置、提示和审查，AI Coding Agent 可以就审查安全补丁时需要考虑的问题和回归提供有价值的建议。在小范围内，这不会增加工作量，而是在无需协调更多人员的情况下，为小型团队提供额外的审查资源。AI 辅助可能不会在首次使用时节省时间或提高质量，甚至可能在第七次审查时也无济于事 。经过一些设置工作，以及人员学习如何改进设置后，一个或两个（由不同提供商配置）的 Agentic AI 助手很可能能够避免再次发布非周期性版本。这将是一项重大胜利。∎

参考资料

[1]

推荐文章: https://vondra.me/posts/the-ai-inversion/

[2]

引用演讲: https://www.pgevents.ca/events/pgconfdev2025/schedule/session/254-committer-review-an-exercise-in-paranoia/

本文关键字：#人工智能 #开源项目 #Postgres #翻译

《技术译文系列》

DBA 的未来？八位行业先锋的年度圆桌讨论

2026 年，优秀的 DBA 需要具备哪些素质？

区分 FUD 和现实：MySQL 真的被放弃了吗？

如何使用 MySQL AI 构建应用程序？

没有好的数据，人工智能就毫无用处

MySQL 和 MariaDB 版本管理的历史背景及差异

AI 如何与我的数据库对话？MySQL 和 Gemini

向量注入？AI 时代数据库新威胁：风险、数据库防护与最佳实践

✨ Github：https://github.com/actiontech/sqle

📚 文档：https://actiontech.github.io/sqle-docs/

💻 官网：https://opensource.actionsky.com/sqle/

🔗 商业支持：https://www.actionsky.com/sqle