Linux 内核开发者 Dave Hansen 近日在社区发表了关于如何使用 AI 工具的政策补丁。

Dave Hansen 表示，在过去几年中，AI 工具（包括 AI 驱动的编码辅助工具）在开发过程中的能力大幅提升。社区越来越多地成员在询问：当工具生成（或部分生成）内容时，贡献者应如何使用／披露这些工具。

因此他提交的补丁旨在为内核贡献中“工具生成内容”（tool-generated content）提供文档指南。这个文件并非完全新增规则，而是提供一个统一的预期标准。

这份补丁明确指出：贡献者使用工具生成内容时，应清晰披露使用方式，以便维护者／审查者能够有效审查。当然像拼写修正、格式化、变量重命名等小修改则不需要额外披露。

在变更日志、提交说明中，应注明哪些内容使用了工具、工具是什么、工具输入／提示是什么。

适用范围 (“In Scope” vs “Out of Scope”)

• 不适用的情况（Out of Scope）：

  • 工具仅用于极小改动，如拼写或语法修正、改写为祈使句、变量重命名、格式化代码等。

• 适用情形（In Scope）：

  • 当“重要内容”由工具而非人工撰写。例：一个新函数由大语言模型生成、一个文件完全由脚本生成、变更日志由 AI 编写。 

  • 在这些情形下，必须披露工具使用情况，包括工具名称、输入、生成的内容范围、人工的修改情况等。

具体指南

• 在提交时：遵循已有的贡献者认证规则（例如开发者证书 DCO）并同时遵守本“工具生成内容”指南。 

• 在变更日志／提交说明中，建议包括如下要素：

  • 使用了哪些工具？

  • 工具的输入是什么？（如：提示、脚本）

  • 工具生成了哪些内容？（例如：一个函数、一个 .c 文件、补丁注释）

  • 哪些部分为人工撰写／修改？并说明人工审核或修改的程度。 

• 维护者仍然保留对贡献的审核判断权：例如是否按常规处理，是否额外要求说明工具训练背景，是否建议更好的提示，而非直接代码变更。

Dave Hansen 在邮件强调，这不是新的强制限制，而是对既有期望的明确化：在 AI 辅助开发成为常态的背景下，透明度对代码质量与审核效率至关重要。维护者仍可基于实际情况要求更多信息或拒绝质量不达标的贡献。