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 声明、什么情况会被关闭 PRAGENTS.md agents/编码代理coding agent应如何在本仓库内工作.github/PULL_REQUEST_TEMPLATE.mdPR 检查清单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 另行分配。批量“扫荡式”PRbulk 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 修复证据EvidenceBug 修复切实可行时包含回归测试Planner / executor / storage 行为在结果可确定时添加或更新带期望输出的逻辑测试或相应套件性能声明包含前后测量数据而非轶事PR 模板中的 “No Test — Explain why” 需要真实理由而不是图省事本地验证Local validation先运行最小相关检查交付前再升级到更强验证计划落地的 Rust 变更不得提交已知的 clippy/format 失败如果全工作区验证成本过高说明你运行了什么、还有什么未覆盖沟通Communication为人类写 PR 摘要动机、行为变更、风险、验证仅在必要时引用模型输出放入 blockquote 并附上自己的解读让讨论具体化紧扣文件、测试和失败模式这些门禁在仓库工具链中有直接对应物make lint会运行格式化、clippy 与仓库 lintermake test运行默认 CI 测试矩阵coding-style.md 要求 Rust 代码遵循rustfmt.toml4 空格缩进、100 列宽并通过cargo clippy -- -D warningsPython 工具满足 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 辅助开发的开发者而言遵循这份政策不仅是合规要求更是让你的贡献更快获得维护者信任的捷径。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
