Linux 内核社区正在讨论生成式 AI 使用政策
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 辅助开发成为常态的背景下，透明度对代码质量与审核效率至关重要。维护者仍可基于实际情况要求更多信息或拒绝质量不达标的贡献。
