PX4 AI 辅助贡献规范：作者身份、披露与提交合规指南

• 嵌入式
• 物联网
• 机器人
• 自动驾驶
• 智能硬件

本指南围绕 PX4-Autopilot 仓库中的 AI 辅助贡献官方政策，系统讲解使用 AI 编码助手参与 PX4 开发时的硬性规则：作者身份与责任边界、Signed-off-by与开发者来源证书（DCO）的签署规则、BSD 3-clause 许可合规、必须携带的Assisted-by披露 trailer，以及项目对测试声明、批量改动、问题报告和代码评审的具体期望。结合仓库内的 CONTRIBUTING.md、AGENTS.md、CLAUDE.md、Makefile 与 CI 校验脚本，读者可以完整掌握"用 AI 写 PX4 代码且合规地提交"的完整工作流。

一、适用范围与核心立场

PX4 欢迎 AI 辅助贡献，但官方立场非常明确：AI 编码助手（AI coding assistant）只是开发工具，与编译器、静态分析器处于同一地位。借助 AI 产出的贡献，与任何其他贡献接受完全相同的质量标准：

• 必须遵守编码规范（Google C++ 风格 + PX4 少量调整，make format/make check_format强制执行）；
• 必须遵循提交消息约定（Conventional Commits，type(scope): description格式）；
• 必须满足测试要求；
• 必须经过与普通 PR 完全相同的评审流程。

该政策的全部附加规则，都服务于一个目的：让作者身份（authorship）、责任归属（accountability）和许可合规（licensing）保持清晰无歧义，同时让维护者的评审负担可控。

政策开篇有一句需要反复强调的提示：

使用 AI 工具是可选的，披露 AI 的使用不是。

也就是说，是否用 AI 帮助写代码是个人自由，但一旦使用，就必须按本文所述规则披露。

二、作者身份与责任：人类提交者是唯一作者

2.1 你必须能为每一行代码负责

提交贡献的人类开发者是该贡献的作者，这意味着：

• 理解每一行：你提交的每一行代码都必须理解，能够解释，并且在评审中被问到时要能辩护；
• 责任不可转移：正确性、安全性、许可合规和测试的责任永远不会转移给工具。PX4 是安全关键型（safety-critical）飞行软件，会驱动真实飞行器，"AI 写的"（the AI wrote it）在评审中永远不是可接受的回答；
• AI 不是作者：AI 工具永远不能成为作者或共同作者，不要添加命名 AI 工具的Co-Authored-By标签。

仓库根目录的 AGENTS.md 与 CLAUDE.md 也印证了这一点：它们明确要求代理（agent）不得在 PR 描述中附加"Generated with …"之类的署名 footer，例如 CLAUDE.md 中的规则——"No Claude attribution — noCo-Authored-By: Claude, no 'Generated with Claude Code' footer"，并强调要使用实际的助手身份（即你在运行哪个客户端就是哪个身份），而不是套用默认模型名。

2.2 与普通贡献的标准对齐

这条政策的本质是"同一标准、不降级"：AI 辅助贡献不是"低配贡献"，不会因为用了工具而获得更宽松的对待，也不会因为工具自动生成代码而免除审查。因此，代码风格、提交格式、测试证据缺一不可。

三、Signed-off-by 与开发者来源证书（DCO）

3.1 签署的语义

Signed-off-by标签是人类作者依据开发者来源证书（Developer Certificate of Origin）作出的认证。其核心约束是：

• AI 工具永远不是贡献的作者，绝不能出现在Signed-off-by标签中；
• 在你指示下工作的工具（包括 AI 代理）可以机械地应用你的签署——这与git commit -s的行为完全一致。签署的认证责任仍然在你自己身上；
• 通过签署，你证明自己已亲自审查该贡献，并有权依据项目许可证提交它。绝不允许你的签署被应用到未经你审查的改动上。

3.2 与仓库现有提交约定的关系

在 docs/en/contribute/code.md 的"提交与提交消息"一节中，项目推荐所有提交使用git commit -s自动添加签名行：

git commit -s

签名行以Signed-off-by: Your Name <your@email.com>的形式作为提交消息的最后一行出现。AI 辅助场景下，该签名行仍然且只能代表人类提交者本人；AI 代理可以像git commit -s一样代你机械添加签名，但这不改变认证的归属。

一个典型的合规提交消息示例（同时体现 Conventional Commits 与签名）：

feat(ekf2): add height fusion timeout. Fixes #1234 The previous implementation did not handle the case where height fusion data stops arriving mid-flight. This adds a configurable timeout that falls back to barometric height. Tested in SITL with simulated sensor dropout. Signed-off-by: Your Name <your@email.com>

四、许可合规：BSD 3-clause 与生成式 AI 政策

4.1 项目许可底线

所有代码贡献必须与 BSD 3-clause 许可证兼容，并且不得施加任何额外限制。这是 PX4 全项目的硬性底线，AI 生成的代码也不例外。

4.2 使用 AI 工具时的额外责任

使用 AI 工具时，你还对 Linux Foundation 生成式 AI 政策（Linux Foundation Generative AI Policy）所规定的条件负责，具体体现在两点：

• 服务条款不得与项目许可冲突：你使用的 AI 工具的服务条款，不得与项目采用的 BSD 3-clause 许可证相冲突。例如，若工具条款主张对输出内容的专有权或附加限制性许可，则该工具不适合用于 PX4 贡献；
• 第三方版权材料的合规：如果工具的输出包含来自第三方的既有版权材料，你必须拥有提交它的权利，并且必须包含所需的声明（notice）、署名（attribution）和许可信息。

这一条在实践中意味着：提交前应检查 AI 生成内容是否与仓库中已有代码高度雷同（可能意味着训练数据中的版权代码被原样复现），一旦复现了第三方代码片段，就需要像手动复制代码一样处理其许可证与署名义务。

五、披露要求：Assisted-by 提交尾注（必选）

5.1 格式与示例

每一个包含 AI 生成或 AI 辅助内容（代码、文档或提交消息文本）的提交，都必须在提交消息正文中携带披露尾注（disclosure trailer）：

Assisted-by: NAME:MODEL

其中NAME标识使用的工具，MODEL标识具体使用的模型。官方文档给出的示例：

Assisted-by: Claude:claude-fable-5 Assisted-by: Copilot:gpt-5

这条 trailer 与Signed-off-by一样位于提交消息正文的末尾，属于可以机读解析的 trailer 区。它让维护者在评审时能够了解该提交的技术背景，也保留了日后追溯的线索。

5.2 不需要披露的工具

传统开发工具不属于本文所指的 AI 辅助，无需披露：

• 编译器（compiler）；
• 格式化工具（formatter，如make format）；
• 静态分析器 / linter；
• git 本身；
• 经典编辑器自动补全（classic editor autocomplete）。

换句话说，只有"生成式 AI"性质的辅助（生成代码、文档或提交消息文本）才触发披露义务；格式化、静态检查等确定性工具不在此列。仓库中对应的格式化工作流见 Makefile：

check_format: # astyle 检查 + git diff --check format: # astyle 全量格式化 format_changed: # 仅格式化变更文件（--diff-only）

5.3 善意原则与追溯后果

披露机制建立在**善意（good faith）**基础上：评审者无法可靠地检测 AI 使用情况，也不会尝试去检测。但——

事后发现的未披露 AI 使用，将被视为虚假陈述（misrepresentation），并构成撤销（revert）该贡献的理由。

这条设计非常关键：它不是"抓作弊"机制，而是一个信任契约。维护者把"诚实披露"当作默认前提；一旦发现隐瞒，代价是整个贡献被回滚。

六、期望与行为边界

这些规则是为了让评审工作可持续（sustainable）。无视这些规则的贡献，维护者可能不做详细评审直接关闭（closed）。具体期望包括四类：

6.1 测试声明必须真实

测试要求原样适用：必须准确说明你运行了什么（SITL 仿真、台架测试、真机飞行测试），并在适用时提供日志。规则强调：

• 绝不让工具描述并未发生的测试——例如，AI 可能生成"Tested in SITL"之类的字样，但如果你没有真正跑过，就不能保留；
• AI 不可能替你飞过飞行器：任何涉及真机飞行的测试声明，都必须由人类实际执行并提供飞行日志佐证。

这与 CONTRIBUTING.md 的"Test your changes"章节一致：新功能必须有单元测试（make tests）和/或 SITL 集成测试（test/mavsdk_tests/），硬件相关改动需要台架或飞行测试证据，评审者会在批准前核实测试存在。

6.2 禁止未经请求的大规模改动

• 不要提交无人要求的大规模 AI 生成重构、风格清扫（style sweep）或"清理"（cleanup）PR；
• 这类想法应先在 issue 或开发者电话会议（dev call）中讨论，获得社区共识后再动手。

原因在于：大规模机械改写会产生海量 diff，淹没真实的功能变更，消耗评审者大量时间而价值存疑。

6.3 Issue 与安全报告必须人工验证

• 提交问题报告前，自己先复现问题；
• 未经验证的 AI 生成发现（unverified AI-generated findings）会浪费维护者的真实时间，并侵蚀信任。

6.4 评审讨论发生在人类之间

• 用 AI 工具帮助你理解评审意见，是完全可以接受的；
• 但把你自己都不理解的模型输出作为回复贴出来，则不可以；
• AI 辅助评审（AI-assisted review）在被明确标注为 AI 辅助时是允许的；把未披露的 AI 评审当作你自己的阅读结论呈现，则不被允许。

七、仓库中的配套落地：从政策到工具链

政策不是孤立的文档，PX4 仓库从多个层面提供了配套支撑：

7.1 CONTRIBUTING.md 中的政策摘要

CONTRIBUTING.md 专门设有 "AI-assisted contributions" 一节，浓缩了政策要点：你是作者、AI 不是作者也不出现在Signed-off-by中、每个含 AI 内容的提交必须携带Assisted-by: NAME:MODELtrailer、所有许可/测试/评审要求原样适用且绝不声称未发生的测试。该节直接链接回 docs/en/contribute/ai_assistants.md。

7.2 面向 AI 代理的仓库级指令

仓库根目录的 AGENTS.md 与 CLAUDE.md 是直接写给运行在仓库中的 AI 代理的指令文件，可作为政策落地的第一手例证：

• 提交：使用$commit//commit技能，遵循 Conventional Commits（type(scope): description）；
• PR：使用$pr技能；
• 署名：使用实际助手身份，绝不冒用 Claude 的身份，PR 描述中不加生成 footer；
• 风格：提交前对改动的 C/C++ 运行make format（CI 通过make check_format强制执行）；
• 作用域指引：编辑或评审前，只需阅读.github/instructions/下applyTo模式匹配受影响路径的*.instructions.md文件（仓库中已有 board-addition、code-review、control、drivers、estimation、messages、simulation、system、docs.en 等主题的指令文件），以及路径上的嵌套 AGENTS.md。

这展示了 PX4 如何把"AI 是工具"的立场具体化为代理可执行的工作流约束。

7.3 CI 对提交消息的机器校验

政策强调披露 trailer 的规范性，而仓库 CI 对提交消息本身已有机器校验：Tools/ci/check_commit_messages.py 会在 PR 上检查每个提交：

• 阻塞性错误（blocking）：未合并的fixup!/squash!/amend!提交、过短消息（< 5 字符）、单字丢弃式消息（fix、update、wip、oops、cleanup等）、调试残留（如tmate）；
• 警告（warning）：评审回应式提交（"apply suggestions from code review"）、仅格式化提交（"do make format" 等）、缺少 Conventional Commits 格式。

这意味着即使使用了 AI，提交消息也必须先通过这套校验，AI 生成的提交消息同样要遵循type(scope): description结构。该脚本既验证了提交规范的可执行性，也说明了"提交消息文本若由 AI 生成，同样需要披露"为何重要——因为它是 PR 被接受的前提之一。

八、实操清单：AI 辅助贡献的合规提交流程

综合全文，一个合规的 AI 辅助贡献流程应包含以下步骤：

1. 动手前：若是大规模重构/清理类改动，先在 issue 或 dev call 中提出并获得讨论；确认改动聚焦、非"无人要求的清扫"；
2. 写作时：把 AI 当作编译器级别的工具；对每一行生成代码进行人工审查、理解并准备辩护；检查是否有第三方版权材料复现，必要时补充声明与许可信息；
3. 格式化：对改动的 C/C++ 运行make format（或make format_changed仅格式化改动文件），确保make check_format通过；
4. 提交：遵循 Conventional Commits 格式type(scope): description；使用git commit -s添加自己的Signed-off-by；在提交消息正文中为所有含 AI 内容的提交追加Assisted-by: NAME:MODELtrailer；
5. 测试：真实运行单元测试、SITL 或台架/飞行测试，准确记录所运行的测试并提供日志；不要让 AI 代写未发生的测试声明；
6. 问题报告：自己复现后再提交 issue 或安全报告；
7. 评审：用 AI 帮助理解评审意见可以，但回复必须是你自己理解的内容；若做 AI 辅助评审，明确标注；
8. 发布 PR：标题同样遵循type(scope): description格式（squash 合并时 PR 标题会成为提交消息），附上测试说明与飞行日志链接。

九、小结

PX4 对 AI 辅助贡献的政策可以用一句话概括：欢迎工具，但责任在人。作者身份、Signed-off-by、许可合规与Assisted-by披露共同构成了一个"可追溯、可问责"的贡献体系——AI 可以代劳代码生成，但理解、测试、签署与披露的最终责任永远属于人类提交者。对于安全关键型的飞行控制软件而言，这不是保守，而是让开源协作在生成式 AI 时代继续保持可持续评审的必要前提。

相关文档与源码延伸阅读：AI 辅助贡献政策原文、编码规范、许可说明、贡献指南（含 AI 章节与测试要求）、代理指令 AGENTS.md、CLAUDE.md、Makefile 格式化目标、CI 提交消息校验脚本。

• 嵌入式
• 物联网
• 机器人
• 自动驾驶
• 智能硬件