尧图网站建设 
嵌入式物联网机器人自动驾驶智能硬件【免费下载链接】PX4-AutopilotPX4 Autopilot Software项目地址https://gitcode.com/gh_mirrors/px/PX4-Autopilot点击查看免费下载本指南围绕 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 Commitstype(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 与开发者来源证书DCO3.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 youremail.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 youremail.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 trailerAssisted-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静态分析器 / lintergit 本身经典编辑器自动补全classic editor autocomplete。换句话说只有生成式 AI性质的辅助生成代码、文档或提交消息文本才触发披露义务格式化、静态检查等确定性工具不在此列。仓库中对应的格式化工作流见 Makefilecheck_format: # astyle 检查 git diff --check format: # astyle 全量格式化 format_changed: # 仅格式化变更文件--diff-only5.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或清理cleanupPR这类想法应先在 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 Commitstype(scope): descriptionPR使用$pr技能署名使用实际助手身份绝不冒用 Claude 的身份PR 描述中不加生成 footer风格提交前对改动的 C/C 运行make formatCI 通过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 辅助贡献流程应包含以下步骤动手前若是大规模重构/清理类改动先在 issue 或 dev call 中提出并获得讨论确认改动聚焦、非无人要求的清扫写作时把 AI 当作编译器级别的工具对每一行生成代码进行人工审查、理解并准备辩护检查是否有第三方版权材料复现必要时补充声明与许可信息格式化对改动的 C/C 运行make format或make format_changed仅格式化改动文件确保make check_format通过提交遵循 Conventional Commits 格式type(scope): description使用git commit -s添加自己的Signed-off-by在提交消息正文中为所有含 AI 内容的提交追加Assisted-by: NAME:MODELtrailer测试真实运行单元测试、SITL 或台架/飞行测试准确记录所运行的测试并提供日志不要让 AI 代写未发生的测试声明问题报告自己复现后再提交 issue 或安全报告评审用 AI 帮助理解评审意见可以但回复必须是你自己理解的内容若做 AI 辅助评审明确标注发布 PR标题同样遵循type(scope): description格式squash 合并时 PR 标题会成为提交消息附上测试说明与飞行日志链接。九、小结PX4 对 AI 辅助贡献的政策可以用一句话概括欢迎工具但责任在人。作者身份、Signed-off-by、许可合规与Assisted-by披露共同构成了一个可追溯、可问责的贡献体系——AI 可以代劳代码生成但理解、测试、签署与披露的最终责任永远属于人类提交者。对于安全关键型的飞行控制软件而言这不是保守而是让开源协作在生成式 AI 时代继续保持可持续评审的必要前提。相关文档与源码延伸阅读AI 辅助贡献政策原文、编码规范、许可说明、贡献指南含 AI 章节与测试要求、代理指令 AGENTS.md、CLAUDE.md、Makefile 格式化目标、CI 提交消息校验脚本。赞分享嵌入式物联网机器人自动驾驶智能硬件【免费下载链接】PX4-AutopilotPX4 Autopilot Software项目地址https://gitcode.com/gh_mirrors/px/PX4-Autopilot点击查看免费下载相关推荐Ray 的 AI 辅助贡献规范与实践读懂 AGENTS.md正确提交 AI 协作 PRRay 的 AI 辅助贡献规范与实践读懂 AGENTS.md正确提交 AI 协作 PR Ray 是一个高流量、多语言混合的 AI 计算引擎仓库C 核心人工智能分布式训练强化学习任务调度模型推理服务后端PicoClaw 贡献开发全指南从 Fork 到合入的协作流程与 AI 辅助贡献规范PicoClaw 贡献开发全指南从 Fork 到合入的协作流程与 AI 辅助贡献规范 PicoClaw 是一个社区驱动的开源个人 AI 助手项目目标是构建人工智能AI 应用AI Agent交互助手工具调用MCP ClientsAgent 记忆Gradle 构建工具的 AI 辅助贡献政策人机协作边界、披露规则与审查实践Gradle 构建工具的 AI 辅助贡献政策人机协作边界、披露规则与审查实践 本篇指南围绕 Gradle 仓库根目录的 AI_POLICY.md https:构建工具开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PX4 AI 辅助贡献规范：作者身份、披露与提交合规指南
嵌入式物联网机器人自动驾驶智能硬件【免费下载链接】PX4-AutopilotPX4 Autopilot Software项目地址https://gitcode.com/gh_mirrors/px/PX4-Autopilot点击查看免费下载本指南围绕 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 Commitstype(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 与开发者来源证书DCO3.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 youremail.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 youremail.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 trailerAssisted-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静态分析器 / lintergit 本身经典编辑器自动补全classic editor autocomplete。换句话说只有生成式 AI性质的辅助生成代码、文档或提交消息文本才触发披露义务格式化、静态检查等确定性工具不在此列。仓库中对应的格式化工作流见 Makefilecheck_format: # astyle 检查 git diff --check format: # astyle 全量格式化 format_changed: # 仅格式化变更文件--diff-only5.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或清理cleanupPR这类想法应先在 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 Commitstype(scope): descriptionPR使用$pr技能署名使用实际助手身份绝不冒用 Claude 的身份PR 描述中不加生成 footer风格提交前对改动的 C/C 运行make formatCI 通过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 辅助贡献流程应包含以下步骤动手前若是大规模重构/清理类改动先在 issue 或 dev call 中提出并获得讨论确认改动聚焦、非无人要求的清扫写作时把 AI 当作编译器级别的工具对每一行生成代码进行人工审查、理解并准备辩护检查是否有第三方版权材料复现必要时补充声明与许可信息格式化对改动的 C/C 运行make format或make format_changed仅格式化改动文件确保make check_format通过提交遵循 Conventional Commits 格式type(scope): description使用git commit -s添加自己的Signed-off-by在提交消息正文中为所有含 AI 内容的提交追加Assisted-by: NAME:MODELtrailer测试真实运行单元测试、SITL 或台架/飞行测试准确记录所运行的测试并提供日志不要让 AI 代写未发生的测试声明问题报告自己复现后再提交 issue 或安全报告评审用 AI 帮助理解评审意见可以但回复必须是你自己理解的内容若做 AI 辅助评审明确标注发布 PR标题同样遵循type(scope): description格式squash 合并时 PR 标题会成为提交消息附上测试说明与飞行日志链接。九、小结PX4 对 AI 辅助贡献的政策可以用一句话概括欢迎工具但责任在人。作者身份、Signed-off-by、许可合规与Assisted-by披露共同构成了一个可追溯、可问责的贡献体系——AI 可以代劳代码生成但理解、测试、签署与披露的最终责任永远属于人类提交者。对于安全关键型的飞行控制软件而言这不是保守而是让开源协作在生成式 AI 时代继续保持可持续评审的必要前提。相关文档与源码延伸阅读AI 辅助贡献政策原文、编码规范、许可说明、贡献指南含 AI 章节与测试要求、代理指令 AGENTS.md、CLAUDE.md、Makefile 格式化目标、CI 提交消息校验脚本。赞分享嵌入式物联网机器人自动驾驶智能硬件【免费下载链接】PX4-AutopilotPX4 Autopilot Software项目地址https://gitcode.com/gh_mirrors/px/PX4-Autopilot点击查看免费下载相关推荐Ray 的 AI 辅助贡献规范与实践读懂 AGENTS.md正确提交 AI 协作 PRRay 的 AI 辅助贡献规范与实践读懂 AGENTS.md正确提交 AI 协作 PR Ray 是一个高流量、多语言混合的 AI 计算引擎仓库C 核心人工智能分布式训练强化学习任务调度模型推理服务后端PicoClaw 贡献开发全指南从 Fork 到合入的协作流程与 AI 辅助贡献规范PicoClaw 贡献开发全指南从 Fork 到合入的协作流程与 AI 辅助贡献规范 PicoClaw 是一个社区驱动的开源个人 AI 助手项目目标是构建人工智能AI 应用AI Agent交互助手工具调用MCP ClientsAgent 记忆Gradle 构建工具的 AI 辅助贡献政策人机协作边界、披露规则与审查实践Gradle 构建工具的 AI 辅助贡献政策人机协作边界、披露规则与审查实践 本篇指南围绕 Gradle 仓库根目录的 AI_POLICY.md https:构建工具开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考