Databasus 展示了在大型开源项目中使用 AI 的示例
Source: Dev.to
请提供您想要翻译的具体内容（文本），我将把它翻译成简体中文并保持原有的格式、Markdown 语法以及技术术语不变。谢谢！
开源项目日益在开发工作流中采用 AI 工具
但当你的项目处理诸如数据库备份、加密密钥和生产环境等敏感数据时，“快速迭代、敢于破坏”的做法就不可行了。
Databasus，一款用于 PostgreSQL、MySQL 和 MongoDB 的备份工具，最近发布了一篇关于他们如何使用 AI 的详细说明——这是一堂关于在安全关键项目中负责任采用 AI 的示范课。
开源项目中的 AI 透明度问题
许多开源项目在未披露的情况下悄悄集成了 AI 生成的代码。有的甚至采用“vibe coding”，让 AI 在几乎没有人工验证的情况下编写完整功能。对于处理猫咪照片或待办事项列表的项目，这或许还能接受。
但对于管理包含敏感客户数据的生产数据库的工具来说，风险截然不同。
Databasus 处理数据库凭证、备份加密以及数千个团队每日使用的生产系统访问权限。一次安全漏洞就可能导致多个组织的敏感数据泄露。正是这种现实迫使维护者明确 AI 使用的边界并公开记录。
Databasus 将 AI 作为开发助理的方式
该项目将 AI 视为 验证和增强工具，而非代码生成器。你可以在项目 README或官网 FAQ中阅读完整的 AI 使用政策。
下面是他们将 AI 用途细分为具体使用场景的方式：
| AI 使用类型 | 目的 | 人工监督 |
|---|---|---|
| 代码审查 | 验证质量并搜索漏洞 | 开发者审查所有发现 |
| 文档编写 | 整理注释并提升可读性 | 开发者批准所有更改 |
| 开发协助 | 提供思路和备选方案 | 开发者完成最终实现 |
| PR 验证 | 人工审查后进行二次检查 | 开发者作出最终批准决定 |
AI 从不自行运行；每一条建议都必须经过开发者验证后才能进入代码库。
Databasus 不 使用 AI 的场景
项目对 AI 的限制设有严格边界：
- 不进行自主代码生成 —— AI 不会编写完整的功能或模块。
- 不接受 “vibe code” —— 快速生成的、缺乏深入理解的 AI 代码会被拒绝。
- 不接受未经验证的建议 —— 每一行 AI 提出的代码都必须经过人工验证。
- 不接受未测试的代码 —— 无论来源如何，所有代码都必须具备测试覆盖。
AI 生成的代码会受到与初级开发者代码同等的怀疑。无论代码来自 AI、外部贡献者还是核心维护者，都必须遵循相同的质量标准。
捕获低质量代码的质量门，无论来源如何
Databasus 通过多种自动化和人工检查来强制代码质量。相同的标准同样适用于人类编写和 AI 生成的代码。
| 质量门 | 目的 | 适用对象 |
|---|---|---|
| 单元测试 | 验证单个组件的功能 | 所有代码（包括 AI 生成的） |
| 集成测试 | 确认系统各部分协同工作 | 所有代码 |
| 静态分析 | 检测潜在的安全漏洞和代码异味 | 所有代码 |
| 代码审查 | 人工检查实现细节和安全性 | 所有代码 |
| CI/CD 流水线 | 自动化构建、测试和部署 | 所有代码 |
注意：以下内容在原文中被截断，翻译仅覆盖已提供的部分。
Source: …
| 检查类型 | 目的 | 范围 |
|---|---|---|
| 行为 | 所有代码更改 | |
| 集成测试 | 测试组件交互 | 所有功能 |
| CI/CD 流水线 | 自动化测试和代码检查 | 每次提交 |
| 人工代码审查 | 架构和安全性验证 | 所有拉取请求 |
| 安全扫描 | 识别漏洞 | 整个代码库 |
两种“糟糕的人类代码”和“AI 风格代码”如果不符合这些标准都会被拒绝。
经验丰富的开发者监督的角色
自动化检查能够捕获许多问题，但人工判断仍然至关重要。Databasus 强调由在大型安全项目中拥有丰富经验的开发者进行验证。这种监督会评估：
- 架构决策和长期可维护性
- 工具可能遗漏的安全影响
- 边缘情况和失败场景
- 代码可读性和文档质量
- 生产负载下的性能特征
快速的问题解决和安全漏洞响应时间表明，这种监督在实践中是有效的。
为何此方法对敏感项目重要
数据库备份工具位于基础设施安全的关键节点。它们读取生产数据库、处理加密密钥，并存储包含敏感信息的备份。若备份工具被攻破，可能导致组织整个数据资产泄露。
因此，Databasus 采用 保守的 AI 方法：
- 信任需要赢得 – 该工具在生产环境中运行，能够访问敏感数据。
- 失败会带来后果 – 备份失败或泄露会影响真实业务。
- 合规要求 – 许多用户在严格的监管框架下运行。
- 企业采纳 – 大型组织在部署前会审查安全实践。
AI 政策和质量门框架为任何安全关键的开源项目提供了实用的蓝图。
AI透明度与代码质量
ache 2.0 license 允许任何人检查代码，但只有当代码本身可维护且经过充分测试时，检查才有意义。未经适当验证的 AI 生成代码会削弱这种透明性。
其他项目的实用经验
Databasus 为关注安全的开源项目在采用 AI 时提供了一个模板。关键原则：
- 公开记录 AI 的使用 – 不要让用户猜测安全关键代码是否涉及 AI。
- 明确划定边界 – 在开发流程中定义 AI 能做和不能做的事项。
- 保持质量标准 – 对所有代码（无论来源）都适用相同的要求。
- 要求人工验证 – AI 的建议只能用于参考，决策仍需人工完成。
- 投入自动化测试 – 让计算机捕获错误，以便人工专注于架构设计。
- 优先考虑可维护性 – 今日的 AI 快捷方式会成为明日的技术债务。
这些原则在提升 AI 生产力的同时，也满足了生产系统的安全需求。
在AI拒绝与AI依赖之间的中间路径
一些项目完全拒绝使用 AI，担心代码质量下降。另一些项目在没有任何防护措施的情况下拥抱 AI，直接交付模型生成的代码。Databasus 展示了一条中间道路，既能利用 AI 的优势，又能保持质量标准。
对比概览
| 方法 | 代码质量 | 开发速度 | 安全风险 |
|---|---|---|---|
| 不使用 AI | 取决于开发者 | 较慢 | 取决于实践 |
| 无约束的 AI | 通常较差 | 初期快速 | 高 |
| Databasus 方法 | 高（强制执行） | 适中 | 低（已验证） |
在稍慢的开发速度换取更高的质量和更低的风险的权衡，对处理敏感数据的项目来说是合理的。
开源社区可以学习的内容
Databasus 在主 README 中发布了其 AI 使用政策，确保每个用户和贡献者都能看到。这种透明度有多重作用：
- 用户信任 – 部署者知道 AI 并未自主生成安全关键代码。
- 贡献者指引 – 新贡献者在提交代码前了解质量期望。
- 行业领导 – 其他项目可以在制定自己的 AI 指南时参考此政策。
- 问责制 – 公开文档对遵循声明的实践形成压力。
该项目还在 issue 和讨论中解答 AI 相关问题，表明他们认真对待社区关注。
Conclusion
AI 工具正在改变软件开发，开源项目必须决定如何负责任地整合它们。Databasus 展示了在不牺牲代码质量或安全性的前提下，利用 AI 提升开发者生产力的可能性。
关键的洞见是把 AI 当作 需要监督的初级开发者，而不是全知全能的编码神谕。这意味着：
- 对所有 AI 建议进行人工验证。
- 完备的测试覆盖。
- 对所有代码（无论来源）统一执行质量标准。
对于在生产环境中处理敏感数据的项目而言，这种审慎的做法不是可选的，而是必需的。Databasus 表明，负责任的 AI 采用包括：
- 公开记录实践。
- 保持严格的质量门槛。
- 决不让 AI 在安全关键代码上自行运行。
其他开源项目——尤其是涉及安全、基础设施或敏感数据的项目——应当学习此案例。AI 拒绝与 AI 依赖之间的中间道路是存在的，也是生产级开源软件的正确选择。