Databend AI 协作贡献政策解读：人与 AI 共同开发的规则、声明与质量门禁-酒店常州论坛

Databend AI 协作贡献政策解读：人与 AI 共同开发的规则、声明与质量门禁

【免费下载链接】databendData Agent Ready Warehouse : One for Analytics, Search, AI, Python Sandbox. — rebuilt from scratch. Unified architecture on your S3.项目地址: https://gitcode.com/GitHub_Trending/da/databend

导读：Databend 是一个面向分析与 AI 场景的云原生数据仓库（Data Agent Ready Warehouse），其官方仓库已把“AI 辅助开发”正式纳入协作规范。AI_POLICY.md定义了人类与 AI 在本仓库中共同贡献代码、测试、文档与评审讨论的行为边界：AI 可以参与，但每一项变更必须有负责任的“人类作者”。读完本文，你将掌握 Databend 允许/禁止的 AI 使用方式、PR 中必须填写的## AI assistance声明格式、提交前的自检清单，以及维护者如何审查 AI 生成的 PR。

一、政策定位：AI 协作不是口号，而是仓库规则

AI_POLICY.md位于仓库根目录，是 Databend 对“AI 辅助贡献”的官方立场文件。它与其姊妹文档构成一套完整的编码代理工作体系：

文档	角色
`AI_POLICY.md`（本文主体）	AI 辅助贡献与评审的社区规则：人类问责、AI 声明、什么情况会被关闭 PR
AGENTS.md + agents/	编码代理（coding agent）应如何在本仓库内工作
`.github/PULL_REQUEST_TEMPLATE.md`	PR 检查清单（CLA、摘要、测试、变更类型、AI 声明）
`.github/CODEOWNERS`	合并路径的领域评审人

其中AGENTS.md是仓库顶层工作指南，明确指出：编码代理可以直接开 PR，但每个 PR 必须指名一位读过完整 diff、能解释变更并回答评审问题的“负责任人类”，并填写 PR 模板中的AI assistance一节。agents/commit-and-pr.md进一步细化：Agent 打开的 PR 必须填写## AI assistance部分并指明负责人（@github-id），且在打开或更新 PR 前，必须把完整 diff 呈现给负责人阅读，未经人类阅读的代码不得请求评审。

政策明确：AI 只是工程工具，人类承担最终责任。这不降低质量标准，反而提高了作者在评审前过滤劣质输出的义务。

二、五大原则：AI 是工具，人类是负责人

政策开篇定义了五条核心原则，是理解后续所有条款的钥匙：

AI 是正常的工程工具——只要有助于提升质量或速度，使用模型、代理或 IDE 助手是被允许且鼓励的。
人类保持问责——谁打开 PR，谁就拥有这项变更：正确性、安全性、兼容性、测试以及后续修复。
理解是强制要求——如果你无法用自己的话解释这项变更，它就不具备提交条件。
评审者时间稀缺——把实际工作转嫁给维护者的低质量 AI 输出，通常会被关闭。
数据库语义需要证据——涉及 planner、executor、storage、meta 和 SQL 行为的变更，需要能够证伪实现的测试，而不是“感觉没问题”。

第五条原则与仓库的测试文化一脉相承：agents/debug-and-validation.md 要求“每个 planner、executor 或 storage 变更，在可确定性的情况下至少添加一个回归 SQL 文件及期望输出”，并主张期望输出必须来自独立来源（MySQL 等其他引擎、规格或手工计算），而不是从实现逻辑中反推。

三、允许的 AI 使用场景

政策明确允许使用 AI 做以下事情：

探索代码库并形成根因假设（root-cause hypothesis）
起草实现、重构、测试、文档和基准（benchmark）
生成多种备选设计方案供人类比较
辅助格式化、样板代码和机械性编辑
在开 PR 之前协助本地评审

在使用编码代理时，应遵循AGENTS.md及其链接的agents/文档（repository-structure.md、development-commands.md、coding-style.md、debug-and-validation.md、commit-and-pr.md、agents-md-alignment.md），优先运行最小的构建/测试循环，保持 diff 可评审，并把测试视为变更的一部分。

例如 development-commands.md 给出的常用命令就是“最小验证”路线的具体落地：make fmt（应用仓库格式化规则）、make lint（提交前运行 lint 检查）、make unit-test/make stateless-test/make sqllogic-test分别运行聚焦的测试套件，而make build仅用于本地调试构建。

四、禁止的行为：什么情况会导致 PR 被关闭

以下行为“通常会导致 issue/PR 被直接关闭，可能不展开讨论”：

1. 无主的自主贡献（Ownerless autonomous contribution）

代理可以开 PR、更新分支、使用gh工具（详见 commit-and-pr.md），但禁止没有负责任人（accountable human）的 PR：每个 PR 必须指明一位作者方的人，读过 diff、能解释变更、会回答评审问题并负责后续修复。这个人不是评审者——评审者通过 CODEOWNERS 另行分配。
批量“扫荡式”PR（bulk drive-by PR），没有本地验证或对 Databend 模块边界的理解。

2. 用 AI 生成对话替代思考

把模型回复直接粘贴当作对维护者问题的回应
冗长、泛泛、高置信度但不对应具体代码或失败模式的评论
用 AI 替你辩护你自己都无法辩护的变更
例外：用 AI 翻译或润色你自己的推理是被鼓励的（例如用中文写、再发一份 AI 辅助的英文版），但想法必须是你的。

3. 敷衍提交（Slop submissions）

无法编译、基本 lint 失败、明显未被作者读过的 PR
只镜像实现的假测试或同义反复测试（fake or tautological tests）
巨大无关 diff、噪音重命名、或把“清理”混入行为变更
秘密泄露失败、许可证不兼容的粘贴代码、或无法解释的依赖变更

4. 绕过协作规范

大型语义或架构变更跳过 issue/RFC 讨论
无视 CLA、PR 模板、CODEOWNERS 评审路径或要求的测试证据

五、人类问责要求：每个 PR 都必须有一个“负责人”

代理打开的 PR 是受欢迎的，但每个 PR——无论怎么产生的——都必须有一位负责任的真人（PR 作者，或 bot 类 PR 在 PR 正文中指名的真人），他们必须：

读过最终 diff 的每一行。未读过的代码不得进入评审。如果 diff 大到读不完，说明它大到不该提交——请拆分它。

并且能够：

用平实的语言陈述用户可见或开发者可见的问题
解释为什么这个方案对 Databend 的架构是正确的
指出如果修复是错误的，哪些测试或手工验证会失败
回答评审问题，而不把回复外包给模型转录
承担生产风险：兼容性、升级/迁移、性能和数据安全

如果维护者询问时没有负责的真人回应，PR 可能被关闭——无论代码质量如何。这一要求与仓库的模块化现实相符：repository-structure.md 强调 Databend 是根植于Cargo.toml的多 crate Rust workspace，首先判断变更属于查询引擎（src/query/）还是元数据系统（src/meta/），再阅读最近的模块 README——负责人必须真正理解所触碰的模块边界。

六、提交前的自检清单：AI 生成代码的典型失败模式

政策特别提醒：生成的代码往往以手写代码很少出现的方式失败。请求评审前，负责人应专门对照以下清单走查 diff：

幻觉接口：调用本代码库中不存在、或行为与模型假设不符的函数、设置或 SQL 行为
看似合理实则错误的边界情况：NULL 处理、溢出、空输入、时区/精度、非 UTF-8——必须对照 Databend 真实行为验证，而不是依据模型记忆中的“数据库该怎样”
镜像实现的测试：用同一套逻辑反推期望输出的测试证明不了任何东西；期望值应来自独立来源（MySQL/其他引擎、规格、手工计算）
静默吞掉的错误：为让代码能编译而插入的unwrap_or_default、宽泛的match _ =>或丢弃的Result
无谓抽象与死代码：没有第二个调用者的 trait、泛型、helper 和配置旋钮；评审前删除
与行为不符的注释和命名：生成的注释常描述“意图”而非代码实际行为
与相邻代码的偏离：如果周边模块对同一问题有不同的成熟解法，跟随它，或解释为什么不

在评审前修复这些问题，是作者的工作；在评审中被发现，说明这个 diff 没有被读过。

七、AI 声明（必须填写）：`## AI assistance`一节

每个 PR 必须完成## AI assistance一节。这是进入评审的前提条件（review-entry requirement）：

如果 AI 实质性地参与了代码、测试、文档或 PR 摘要，描述协助类型和影响范围
如果没有超出普通自动补全、拼写检查或 linter 建议的 AI 参与，写None
描述工作，而非厂商：不要提及产品、模型或提供商名称

完整有效的示例：

## AI assistance - AI usage: An AI coding agent drafted the storage iterator patch; I reworked the error paths and added logic tests - Responsible human: @your-actual-github-id - [x] The responsible human has read every line of this diff and can explain each change

无实质性 AI 参与的 PR：

## AI assistance - AI usage: None - Responsible human: @your-actual-github-id - [x] The responsible human has read every line of this diff and can explain each change

声明只说明变更是如何产生的，不减轻负责任人的任何义务。对于高风险变更（catalog/meta、存储正确性、事务、planner 语义、安全边界），维护者还可能要求进行代码走查（walkthrough）。这份声明的实践形态可见于 commit-and-pr.md 的示例 PR 描述——其中 “AI assistance” 一节同样要求AI usage、Responsible human与已读 diff 的确认勾选。

八、AI 辅助 PR 的质量门禁

AI 辅助的变更仍须满足 Databend 常规贡献期望：

范围（Scope）

优先小而可评审的 PR，而非代理产出的巨型 diff
把机械性再生成与语义变更拆分
不要把顺手重构混入 bug 修复

证据（Evidence）

Bug 修复：切实可行时包含回归测试
Planner / executor / storage 行为：在结果可确定时，添加或更新带期望输出的逻辑测试（或相应套件）
性能声明：包含前后测量数据，而非轶事
PR 模板中的 “No Test — Explain why” 需要真实理由，而不是图省事

本地验证（Local validation）

先运行最小相关检查，交付前再升级到更强验证
计划落地的 Rust 变更，不得提交已知的 clippy/format 失败
如果全工作区验证成本过高，说明你运行了什么、还有什么未覆盖

沟通（Communication）

为人类写 PR 摘要：动机、行为变更、风险、验证
仅在必要时引用模型输出，放入 blockquote 并附上自己的解读
让讨论具体化，紧扣文件、测试和失败模式

这些门禁在仓库工具链中有直接对应物：make lint会运行格式化、clippy 与仓库 linter；make test运行默认 CI 测试矩阵；coding-style.md 要求 Rust 代码遵循rustfmt.toml（4 空格缩进、100 列宽）并通过cargo clippy -- -D warnings，Python 工具满足 Ruff 默认值，Shell 脚本通过shfmt -l -w往返。

九、维护者与评审者指南：评审变更，而非工具

合并前至少有一位人类读过 diff。AI 评审 bot 的批准不计入此要求——它们是助手，不是评审者
把人类注意力放在正确性、数据安全、兼容性、性能和测试充分性上
优先用检查作者理解的问题，而不是交给 CI 处理的风格吹毛求疵。对高风险区域，一个探究性问题（“当快照过期时这个分支为什么安全？”）胜过十个琐碎问题
先读测试：验证它们确实会失败，且期望输出来自独立来源而非实现本身
如果 PR 看起来是 AI 生成且低质，要求更精炼的摘要、测试或缩小的 diff；如果作者无法参与讨论，就关闭它
领域 CODEOWNERS 是其领域内的权威
可以使用 AI 辅助评审，但合并决定必须由人类做出

十、安全、许可证与保密

你有责任确保贡献材料的许可证兼容性——无论内容是手敲的还是生成的
不要以会导致其落入仓库的方式，把专有代码、私有客户数据、凭据或内部机密粘贴进 prompt
对安全敏感区域（认证、授权、多租户隔离、沙箱 UDF 边界）保持高关注度，无论代码如何产生

这与仓库实际能力相对应：Databend 宣称“Python Sandbox”与多租户能力，因此 UDF 沙箱边界等安全区域在政策中被单列为高关注区；AI_POLICY.md明确要求无论代码来源如何，这些区域都按高关注度审查。

十一、与其他文档的关系与例外处理

若针对某个 PR 的维护者指导与本文件冲突，以维护者对该 PR 的明确指导为准，如果该例外应当成为政策，再在本文件中提出更新。这种“例外须显式记录”的风格同样出现在 agents-md-alignment.md 中：当AGENTS.md、低层文档与仓库实践不一致时，先记录冲突并点名存在张力的来源（维护者指导、AGENTS.md、低层文档、仓库实践），再决定更新哪一层。

十二、执行机制与速查版

执行方面：维护者可要求修改、要求人类澄清、要求更多测试，或关闭违反政策的 PR；重复的低质或无人值守的 Agent 刷屏可能导致贡献被阻止；而解释清楚、有测试、可评审的善意 AI 辅助工作是受欢迎的。

政策最后给出速查版（Short version），可视为提交前的最简心智模型：

Use AI freely. 大胆使用 AI。 Read every line before you submit. 提交前读每一行。 Submit only what you understand, can test, and can defend. 只提交你理解、可测试、能辩护的内容。 Do not waste reviewer time with unattended slop. 不要用无人值守的敷衍内容浪费评审者时间。

结语：在 Databend 中与 AI 协作的正确姿势

综合来看，Databend 的AI_POLICY.md把“AI 辅助开发”从口号落地为一套可执行的工作流：AI 可以起草、评审前自检、开 PR，但每一项进入仓库的变更都必须有一位读过每行 diff、能解释、能测试、能辩护的人类作者。配合AGENTS.md与agents/下的六份细则文档，这套政策构成了从探索代码库、形成根因假设、最小化验证、填写 AI 声明到接受人类评审的完整闭环。对希望在 Databend 仓库中实践 AI 辅助开发的开发者而言，遵循这份政策不仅是合规要求，更是让你的贡献更快获得维护者信任的捷径。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析