生成式人工智能使用方针

本文档规定 PCL CE 项目开发与维护过程中使用生成式人工智能（Generative AI，以下简称 AI）工具的基本要求，包括使用披露、贡献质量、自动化行为、审查流程以及违规处理等内容。

PCL CE 允许贡献者合理使用 AI 工具辅助开发，但所有贡献仍须符合项目既有的技术规范、质量要求和贡献范围。AI 工具不能代替贡献者完成必要的理解、审查和验证工作，也不能代替维护者作出项目管理决定。

本方针适用于参与 PCL CE 开发、文档编写、问题报告、技术讨论及维护工作的所有人员。除非另有说明，本文中的“贡献者”也包括以贡献者身份参与项目活动的维护者。

🛑 重要 🛑

使用 AI 不构成拒绝贡献的唯一理由，但也不能作为降低质量要求或免除贡献者责任的依据。

不符合本方针的贡献可能会被要求修改或直接关闭。对于严重或反复违反规定的行为，维护者可以限制相关人员继续参与项目活动。

规范用语说明

本文中的规范性用语含义与 技术规范 保持一致：

用语	含义
必须 / 不得	强制要求，相关行为或提交内容必须严格遵守
应 / 不应	默认要求，除非有明确理由，否则应遵守
建议 / 推荐	非强制要求，但通常有助于提高贡献质量或降低维护成本
可以	允许的做法，可根据实际情况选择

一、适用范围与定义

1. 适用范围

本方针适用于 PCL CE 项目相关的公开贡献及维护活动，包括但不限于：

• 源代码、测试代码、配置文件和构建脚本；
• 代码注释、开发文档、用户文档及其翻译；
• 图片、图标和其他项目资源；
• Issue、Pull Request（以下简称 PR）、讨论及评论；
• Bug 报告、安全问题报告和技术分析；
• 维护者的代码审查、问题处理和其他项目管理活动；
• 使用 AI Agent 或自动化工具执行的相关操作。

对于 PCLC Docs 中直接涉及 PCL CE 的文档贡献，同样应遵守本方针。文档内容还须符合 PCLC Docs 的 编写规范。

本方针不限制与项目贡献及维护活动无关的个人 AI 使用行为。

2. 生成式 AI 的定义

本文中的生成式 AI 是指能够根据输入内容生成、补全、改写或分析代码、自然语言、图像及其他内容的人工智能系统。

常见使用形式包括：

• 使用 ChatGPT、Claude、DeepSeek 等工具生成代码或提供技术建议；
• 使用 GitHub Copilot 等工具进行基于语言模型的代码补全；
• 使用 AI 分析错误日志、查找问题原因或提出修复方案；
• 使用 AI 翻译、校对或改写自然语言文本；
• 使用 AI 生成图片、图标或其他资源；
• 使用具备自主规划和工具调用能力的 AI Agent 执行开发任务。

以下确定性工具及功能通常不属于本方针所指的生成式 AI：

• 基于语言规则或静态分析的传统 IntelliSense 补全；
• 代码格式化工具和静态检查工具；
• 按预定义规则执行的普通脚本；
• .NET 源生成器及其他确定性的编译期代码生成工具；
• 不使用生成式模型的搜索、重构和批量替换功能。

若某项工具功能实际依赖生成式模型，即使其表现形式与传统补全、搜索或重构功能相似，仍应按照本方针处理。

3. AI 使用的分类

为区分不同程度的 AI 参与，本文将相关使用方式分为以下两类。

类别	定义	常见场景
辅助性使用	AI 主要用于研究、分析、补全、翻译或校对，不直接承担主要实现工作	查阅技术资料、分析异常、少量代码补全、文本翻译
实质性使用	AI 生成或实质性改写了最终采用的代码、测试、资源或其他允许提交的内容	生成方法实现、重构现有模块、生成测试、制作图像资源

是否属于实质性使用，应根据 AI 对最终贡献内容的实际影响判断，而不是仅根据代码行数或工具使用次数判断。

例如，贡献者要求 AI 设计某个函数的完整实现，再手动输入或局部调整生成结果，仍属于实质性使用。

上述分类仅用于确定披露内容和审查要求。无论属于哪一类，均须遵守本方针。

二、基本原则与责任

1. 贡献者责任

贡献者始终是其提交内容的作者和责任主体。

无论 AI 参与程度如何，贡献者都必须：

• 理解本次修改的目的、实现方式及影响范围；
• 检查 AI 提供的信息、代码和技术建议是否正确；
• 确认提交内容符合项目的技术规范和现有架构；
• 完成与修改内容相适应的测试或验证；
• 能够解释关键实现、异常处理和已知限制；
• 对提交内容引入的错误进行必要的修正。

贡献者不得将 AI 生成结果作为不理解代码或无法解决问题的理由，也不得以“AI 建议如此实现”代替具体的技术论据。

维护者可以要求贡献者解释任意与其提交内容有关的技术问题。若贡献者无法说明关键实现，或无法证明修改已经过必要验证，维护者可以暂停审查或关闭相关 PR。

2. 人工审查要求

AI 生成或修改的内容必须经过贡献者本人审查后才能提交。

人工审查不应仅限于确认代码能够编译，或检查生成内容是否存在明显语法错误。

对于代码贡献，审查还应包括：

• 所使用的 API、类型和参数是否真实存在；
• 实现是否符合预期行为；
• 是否正确处理异常情况和边界条件；
• 是否重复实现项目已有功能；
• 是否引入不必要的抽象、依赖或状态；
• 是否影响既有功能、性能或兼容性；
• 是否存在与本次修改无关的代码变更。

对于 AI 提出的技术结论，应根据源码、官方文档、测试结果或其他可靠依据进行核实。

不得将 AI 输出直接视为已经验证的事实。

3. 质量标准

AI 辅助内容与其他贡献适用相同的质量标准。

使用 AI 不意味着相关内容可以降低测试、可维护性或文档质量要求；未使用 AI 也不意味着相关贡献可以免于正常审查。

贡献内容必须符合项目的实际需求，不应仅因为 AI 能够生成某种实现，就将其引入项目。

项目已经进入维护阶段，新增贡献仍须符合当前以问题修复和现有功能优化为主的维护方向。符合本方针不代表相关贡献必然会被接受或合并。

4. 贡献价值与维护成本

贡献者应尽量保证提交内容具有明确价值，且其审查与后续维护成本处于合理范围内。

对于需要大量维护者工作才能理解、验证或整理，但实际收益有限的贡献，维护者可以要求缩小修改范围、补充说明或重新实现。

尤其不应提交大量未经整理的 AI 生成内容，并要求维护者代替贡献者完成基础调试、代码检查或方案设计。

维护者没有义务为缺乏必要人工审查的贡献提供完整的逐行审查。

三、AI 使用披露

1. 基本要求

凡是在项目贡献或维护过程中使用了生成式 AI，均必须明确披露。

披露要求适用于所有相关 AI 使用，包括：

• 基于语言模型的少量代码补全；
• AI 辅助研究、问题分析和调试；
• AI 生成或实质性修改代码；
• AI 辅助翻译和语法校正；
• AI 辅助生成图片或其他资源。

仅使用传统 IntelliSense、确定性格式化工具或普通脚本时，无须按照本方针披露。

披露的目的是为维护者提供必要的审查上下文。披露 AI 使用情况本身不代表存在违规行为。

2. PR 标题中的模型标识

使用生成式 AI 辅助完成的 PR，必须在标题末尾添加模型标识，以便维护者直接从 PR 列表了解 AI 使用情况。

模型标识采用以下格式：

[模型名称-版本]

示例：

[DeepSeek-V4.1-flash]
[Claude-Opus-5.5]
[GPT-6.1-sol]

PR 标题仍须符合 技术规范 中的提交信息格式要求。

例如：

fix(download): 修复下载失败后的重试逻辑 [GPT-6.1-sol]

对于仅使用 AI 辅助翻译的文档修改，也应添加模型标识：

docs: 修正安装指南中的英文译文 [Claude-Opus-5.5]

模型名称及版本必须根据实际使用情况填写，不得虚构或填写未经确认的版本信息。

若工具未提供所使用模型的准确名称或版本，可以使用能够明确识别该工具的名称代替，例如：

[GitHub-Copilot]

此时应在 PR 描述中说明无法确认具体模型版本。

若同一 PR 使用了多个模型，应优先在标题中标注对最终贡献影响最大的模型，并在 PR 描述中列出其他模型及其用途。标题长度允许时，也可以同时添加多个模型标识。

提交者可以在 Git 提交信息末尾保留相同标识，但不能以此代替 PR 标题中的标识。

提示

模型标识用于说明 AI 参与情况，不属于 PR 内容摘要的一部分。添加标识时，仍应保证标题能够简洁、准确地说明实际修改内容。

提交信息应继续遵守项目既有的长度限制及格式要求。

3. PR 描述中的使用声明

所有 PR 均必须明确声明 AI 使用情况，包括完全未使用 AI 的贡献。

建议通过 PR 模板统一填写以下信息：

### AI 使用情况

- 使用情况：未使用 / 辅助性使用 / 实质性使用
- 使用工具及模型：
- 使用目的：
- 涉及范围：
- 人工审查与验证：

其中：

• 未使用 AI 时，只需选择“未使用”，其余项目可以省略。
• 仅存在辅助性使用时，应说明工具和主要用途，无须逐项记录代码补全或每次模型调用。
• 存在实质性使用时，必须说明所使用的工具及模型、生成或修改的内容范围，以及完成的人工审查和验证。

对于无法确认的模型版本，应如实注明，不得自行推测。

实质性使用的披露应能够让维护者判断 AI 主要参与了哪些工作，以及相关内容是否经过必要验证。

以下内容通常无须提供：

• 完整的 AI 对话记录；
• 每次代码补全的具体内容；
• 与最终贡献无关的提示词；
• 模型内部推理过程；
• 包含个人信息、凭据或其他敏感内容的原始输入。

维护者可以根据具体情况要求补充相关信息，但不应要求贡献者公开可能造成信息泄露的内容。

4. 其他公开贡献的披露

对于不通过 PR 提交的 Issue、讨论和评论，也必须披露相关 AI 使用情况。

披露可以通过对应模板或简短说明完成，应至少包含所使用的工具或模型及其用途。

例如：

本报告使用 GPT-5.1 辅助分析异常日志，所述问题已由本人复现。

本评论使用 Claude 辅助翻译，技术内容由本人撰写并确认。

维护者在使用 AI 辅助形成公开审查意见或技术结论时，同样应披露相关使用情况。

仅在个人环境中使用 AI，且与项目贡献、公开反馈或维护决定无关的行为，不属于本节的披露范围。

5. 披露内容的真实性

贡献者不得隐瞒与本次贡献直接相关的 AI 使用情况，不得故意填写错误的模型信息，也不得将 AI 实质性生成的内容声明为仅经过少量补全。

在 PR 审查过程中新增使用 AI 的，应及时更新相应的披露信息。

若维护者对披露内容存在合理疑问，可以要求贡献者补充说明，但不得仅凭代码风格、文本措辞或 AI 检测工具的结果认定贡献者隐瞒使用情况。

四、不同类型贡献的要求

1. 源代码

AI 辅助生成或修改的代码必须符合项目现有的 技术规范。

提交者应优先使用项目已有的架构、工具方法和实现方式，不应仅因 AI 建议而引入新的抽象层、设计模式或第三方依赖。

以下内容不得直接提交：

• 使用不存在的 API、类型或参数的代码；
• 逻辑不完整、缺乏必要异常处理或存在明显行为错误的实现；
• 未经核实的外部代码或依赖；
• 与现有功能重复且没有明确必要性的实现；
• 未经整理的占位实现、无效分支或遗留调试代码；
• 作者无法解释其目的或行为的代码。

AI 辅助修改应保持最小必要范围，不应混入大量与实际目标无关的重命名、格式化、代码迁移或重构。

若 AI 生成的方案明显偏离项目既有实现方式，应优先检查是否可以采用更简单的方案，而不是直接将生成结果引入项目。

2. 代码注释

新增注释应主要说明实现原因、特殊约束或不易直接从代码判断的行为。

不得为自解释的代码添加大量重复性说明，也不得新增与实际代码行为不一致的文档注释。

以下做法通常不应采用：

• 为简单赋值、条件判断或方法调用逐行添加说明；
• 使用没有实际信息量的分节注释或装饰性横幅；
• 添加未经确认的参数、返回值或异常说明；
• 保留 AI 生成的占位 TODO、FIXME 或待实现说明；
• 在原有代码风格不需要注释的地方添加大量重复描述。

代码注释属于项目技术文档的一部分。注释内容应由贡献者根据实际实现自行编写，AI 可以用于翻译或语法校正，但不得代替贡献者解释其不理解的代码。

3. 测试代码

AI 辅助生成的测试必须验证实际行为，不应仅为满足覆盖率或使 CI 通过而添加测试。

新增或修改测试时，应遵守以下要求：

• 测试应检查具有实际意义的行为或结果；
• 测试中的断言必须能够有效验证预期行为；
• 对于问题修复，应尽可能验证测试在修复前能够发现问题，并在修复后通过；
• 不应重复覆盖已有测试已经充分验证的相同场景；
• 不应过度依赖与测试目标无关的内部实现细节；
• 测试风格应与同一项目或目录中的现有测试保持一致；
• 不应仅因 AI 建议而引入新的测试框架或依赖。

不得通过无理由地修改断言、跳过测试、删除既有测试或降低测试要求来掩盖实现错误。

若确有必要修改或删除既有测试，必须说明原测试覆盖的行为、修改原因，以及调整后如何保证相关行为仍然得到有效验证。

对于无法编写自动化测试的场景，应说明已经采用的其他验证方式。

不得声称未实际执行的测试已经通过，也不得使用 AI 生成的虚假测试结果作为验证依据。

4. 文档及其他公开文本

面向项目成员和用户的公开文本必须由贡献者本人撰写。

AI 仅可用于翻译已有人类原稿，或进行拼写、语法及不改变原意的语言校正，不得代替贡献者起草或实质性改写公开文本。

本要求适用于：

• PR 标题、描述及审查回复；
• Issue、讨论及其评论；
• Git 提交信息；
• 开发文档、用户文档和发布说明；
• 代码注释及其他技术说明。

不得直接提交 AI 生成的长篇说明、问题报告、技术评论或文档正文，也不得仅通过少量删改将其作为人工撰写的内容提交。

允许使用 AI 辅助查阅资料、分析技术问题或检查文本错误，但贡献者必须自行确认相关信息，并使用自己的语言组织最终内容。

AI 辅助翻译的文本必须经过人工校对，确保技术术语、语义和上下文准确，不得引入原文中不存在的事实或结论。

公开文本应符合项目既有的文档风格，使用简洁、准确的表述。

以下内容不应出现在正式贡献中：

• 缺乏具体信息的概括性段落；
• 重复表达相同内容的冗余列表；
• 没有依据的技术结论或主观评价；
• 与项目实际情况不符的通用化说明；
• 大量不必要的保留性措辞；
• 明显不符合上下文的翻译或术语使用。

维护者应根据文本的准确性、信息量、可理解性及实际内容进行审查，不应仅凭措辞风格推断其是否由 AI 生成。

5. Issue 与问题报告

使用 AI 辅助分析 Bug 或安全问题是允许的，但报告者必须自行核实相关结论。

Bug 报告应尽可能包含：

• 实际发生的问题及预期行为；
• 受影响的版本和运行环境；
• 可执行的复现步骤；
• 已经确认的实际结果；
• 必要的日志、截图或其他证据。

不得将 AI 对源码或日志的推测直接作为已经确认的问题提交。

对于 AI 辅助发现的潜在安全问题，报告者应自行检查相关代码和触发条件，并通过项目指定的安全报告渠道提交必要信息。

若暂时无法复现，应明确说明尚未确认的部分，不得虚构复现过程或将推测描述为确定事实。

禁止使用 AI 批量生成重复、无实际依据或未经核实的 Issue。

6. 图片及其他资源

项目允许在符合版权、质量和实际需求的前提下使用 AI 辅助制作图片、图标或其他资源。

提交者必须确认资源符合项目的使用要求，并对其内容及来源承担责任。

不得提交：

• 存在明显错误或不符合实际用途的生成资源；
• 无法确认使用权限的第三方素材；
• 未经授权使用的商标、标识或受保护内容；
• 含有不应公开的信息或具有误导性的资源。

对于使用 AI 生成的资源，应在提交说明中注明使用工具、生成内容范围和必要的后期处理情况。

五、贡献规模与审查要求

1. 提交前检查

所有贡献均应在请求维护者审查前完成必要的自行检查。

对于代码 PR，提交者应至少能够说明：

• 本次修改解决的具体问题；
• 主要实现方式及其选择原因；
• 修改涉及的功能和可能产生的影响；
• 已完成的测试或其他验证；
• 尚未解决的问题或已知限制。

对于实质性使用 AI 的贡献，还应说明相关生成内容经过了哪些人工检查。

如果贡献缺少理解修改所必需的信息，维护者可以要求补充说明，并暂缓进一步审查。

2. 大型 PR 的判定

满足以下任一条件的 PR，应按照大型 PR 处理：

• 单个 PR 新增或修改的代码超过 200 行；
• 单个 PR 涉及超过 5 个 .cs 或 .xaml 文件。

代码行数按 PR 差异中的新增行和删除行合计计算，而不是仅计算净增加的行数。

对于自动生成文件或其他纯机械性修改，维护者可以根据实际情况决定是否将其纳入上述规模计算，但相关变更仍须接受必要审查。

上述限制以整个 PR 为单位。将大型修改拆分为多个 Git 提交，不会改变 PR 的整体审查规模。

3. 大型 AI 辅助贡献

对于超过上述规模限制，且包含实质性 AI 生成内容的 PR，原则上应先拆分为多个可以独立审查、验证和合并的较小 PR。

拆分后的每个 PR 应具有明确目标，并尽量避免与其他尚未合并的 PR 产生不必要的依赖。

不得仅通过拆分提交记录、隐藏无关修改或其他形式规避规模要求。

若技术原因导致修改无法合理拆分，提交者应在请求正式审查前说明原因，并获得维护者同意。

维护者可以要求作者补充更详细的实现说明和验证结果，或逐步讲解相关代码的执行流程与关键逻辑。

未经必要整理和验证的大型 AI 生成贡献可能会被直接拒绝。

4. 严格审查的触发条件

满足以下任一条件的 PR，应进入严格审查流程：

• 修改规模超过本节规定的界限；
• 涉及账户认证、凭据处理、更新器、签名校验或下载完整性等安全敏感逻辑；
• 删除、重构或大幅调整既有测试；
• 维护者认为当前贡献存在明显的审查或后续维护成本问题；
• 维护者根据实现复杂度、风险或 AI 参与程度认为有必要进行额外验证。

实质性使用 AI 的贡献必须完成详细披露和相应的人工验证，但不一定因使用 AI 本身而要求完整的严格审查流程。

例如，经过充分验证的少量 AI 辅助代码可以接受常规审查；涉及安全敏感逻辑的修改，即使规模很小，也可能需要严格审查。

5. 严格审查流程

进入严格审查的 PR，应根据维护者要求完成以下工作：

1. 将可以独立处理的修改拆分为较小的 PR，或说明无法拆分的原因。
2. 补充变更动机、主要实现方式和影响范围。
3. 提供与修改内容相适应的测试结果及验证方式。
4. 对关键逻辑、异常处理和失败边界进行说明。
5. 根据维护者反馈修改实现或补充必要证据。

维护者可以要求贡献者以自己的语言解释具体代码路径、关键分支、数据流和设计选择。

解释可以通过 PR 评论、技术说明或其他双方认可的方式完成，不要求必须使用实时会议或视频演示。

严格审查中的关键问题未得到解决前，相关 PR 不应合并。

至少应有一名负责审查的维护者确认已经理解相关重要变更，并认为现有验证足以支持合并。

6. 审查成本过高的贡献

对于贡献的审查及后续维护成本与其预期价值明显不相称的情况，维护者可以认定该贡献存在审查成本问题。

常见情况包括：

• 为简单问题引入明显不必要的大规模重构；
• 使用大量抽象或辅助代码实现原本较简单的功能；
• 重复实现已有功能，但没有说明实际收益；
• 提交大量未经验证、需要维护者逐项排查的实现；
• 修改范围远超实际问题所需；
• 作者持续无法说明实现方式或提供有效验证。

此类判断不以是否使用 AI 为前提。

维护者应说明主要问题，并可以要求贡献者缩小范围、重新整理或补充验证。

若相关问题无法得到解决，或继续审查已缺乏合理价值，可以关闭对应 PR。

7. 审查标签

为方便管理相关 PR，维护者可以使用以下标签：

标签	含义
AI 辅助	贡献者已披露使用 AI，仅表示使用情况，不代表存在违规
需要解释	当前修改需要作者补充技术说明或完成实现说明
成本过高	当前贡献的审查及维护成本与实际价值不相称，需要重新整理或评估

标签用于标识当前审查状态或相关信息，不应直接作为处罚依据。

其中，需要解释 可以在作者完成必要说明后移除；成本过高 可以在作者有效缩小修改范围、补充验证或解决主要问题后移除。

六、AI Agent 与自动化

1. 允许的辅助操作

贡献者可以在人工监督下使用 AI Agent 执行本地开发任务，包括：

• 阅读和分析源码；
• 搜索调用关系和相关实现；
• 提出修改方案；
• 生成或修改本地代码；
• 执行本地构建、测试及静态检查；
• 整理供贡献者自行审查的技术信息。

使用 Agent 完成上述工作，不免除贡献者的理解、验证及披露义务。

提交者必须检查 Agent 对文件进行的实际修改，不得仅根据 Agent 的完成报告判断任务已经正确执行。

2. 禁止自主执行的操作

未经明确的人类操作和确认，不得允许 AI Agent 自主执行以下行为：

• 创建或提交面向项目的 PR；
• 创建 Issue 或发布讨论；
• 发布 PR 审查评论及其他公开回复；
• 批准、合并或关闭 PR；
• 代表维护者作出项目管理决定；
• 执行超出授权范围的仓库管理操作。

不得通过简单地自动确认 Agent 的操作请求，规避上述人工参与要求。

由人类主动发布的内容仍须符合本方针的公开文本编写要求，不能仅因为经过人工点击就视为已经完成必要审查。

3. 提交身份与签名

项目要求 Git 提交具有有效签名。

提交者不得将个人签名私钥交由 AI Agent 持有、管理或用于自主签署提交。

不得将个人访问令牌、仓库管理凭据或其他敏感凭据直接提供给未经适当限制的 Agent。

所有需要贡献者身份确认的提交和发布行为，必须由具备相应权限的人类参与并承担责任。

4. 自动化例外

项目已有的确定性自动化流程不受上述自主 Agent 限制，包括预先配置的构建、测试和其他常规 CI 任务。

由维护者明确批准、具有固定执行范围和责任人的自动化操作，可以根据实际需求单独处理。

此类例外不代表允许自主 Agent 不受限制地创建贡献、发布评论或修改项目内容。

使用 AI 的自动化流程仍须符合相关的安全、信息保护和质量要求。

5. 维护者使用 AI

维护者可以使用 AI 辅助源码分析、技术研究、问题排查和内部审查。

但 AI 不能代替维护者作出合并、关闭、处罚或其他项目管理决定。

维护者必须核实 AI 提供的审查意见，不得直接将未经确认的模型结论作为要求贡献者修改的依据。

公开发布的审查意见和项目管理回复必须由维护者本人撰写。AI 仅可用于翻译或语法校正，并按本方针披露相关使用情况。

不得使用 AI 检测器或模型推测的结果，作为认定贡献者违规的唯一依据。

七、版权、安全与内容真实性

1. 版权与许可证

AI 生成内容不应被默认视为没有版权限制，也不应因其生成方式而免于项目已有的许可证要求。

提交者必须确认引入的代码、资源和依赖符合对应文件或目录适用的许可证及其他相关要求。

PCL CE 主仓库的许可证以仓库实际声明为准。其中，Plain Craft Launcher 2/ 目录适用其单独声明的许可条件，其他目录适用仓库所声明的 Apache-2.0 许可证。

对于文档及其他仓库，应遵守各自适用的许可证。

不得：

• 在未核实来源和许可条件的情况下复制 AI 提供的外部代码；
• 将受许可证限制的第三方内容伪装为 AI 原创内容；
• 擅自删除或修改原有版权声明及许可证信息；
• 引入无法确认使用权限的图片、图标或其他资源；
• 使用 AI 编造来源、作者、许可证或授权信息。

如果 AI 建议引入第三方依赖，提交者必须自行确认其实际存在、维护情况、用途及许可证兼容性。

若无法确认相关内容具有合适的使用权限，应避免将其提交到项目中。

2. 敏感信息保护

不得将未经授权的敏感信息提交给第三方 AI 服务。

相关信息包括但不限于：

• 用户账号、访问令牌和身份认证凭据；
• 私钥、签名材料及其他安全凭据；
• 包含个人信息的日志或配置；
• 尚未公开的安全漏洞信息；
• 不应向第三方公开的项目资料。

在使用 AI 辅助分析日志、配置或错误报告前，必须检查并移除不应外传的信息。

即使相关数据由 AI 工具自动读取或上传，使用者仍须对信息保护承担责任。

3. 内容与证据真实性

所有向项目提交的技术事实、测试结果和问题证据都必须真实、可核实。

严禁使用 AI 伪造或篡改以下内容：

• 错误日志及终端输出；
• Bug 复现步骤或复现结果；
• 测试记录和 CI 运行结果；
• 性能基准数据；
• 截图、录屏或其他用于证明问题的材料；
• 第三方文档、引用及技术依据。

AI 可以辅助分析真实数据，但不得生成虚假数据并将其作为真实执行结果提交。

对于推测性结论，必须明确说明尚未验证的部分。

故意伪造或篡改证据属于严重违规行为，维护者可以直接采取限制参与等措施。

八、违规处理与复核

1. 基本处理原则

维护者应根据具体违规行为、影响范围及贡献者的配合情况决定处理方式。

处理决定应尽可能基于可以明确指出的事实，例如：

• 缺少必要的 AI 使用披露；
• 提交内容不符合技术或质量要求；
• 作者无法解释关键实现；
• 未完成必要验证；
• 使用 Agent 执行禁止的自主操作；
• 伪造技术证据或泄露敏感信息；
• 反复提交明显不符合要求的贡献。

不得仅凭“代码看起来像 AI 生成”或 AI 检测工具的结果作出处罚决定。

2. 要求修改

对于能够纠正的一般性问题，维护者通常应先要求贡献者修改。

例如：

• 遗漏模型标识或使用声明；
• PR 描述缺少必要的验证信息；
• AI 辅助代码存在明显但可以修正的质量问题；
• 修改范围过大，需要进一步拆分；
• 作者尚未完成必要的技术说明。

维护者可以在要求修改后暂缓审查，直到相关问题得到解决。

3. 关闭贡献

存在以下情况时，维护者可以关闭相应 PR 或 Issue：

• 贡献者未按要求修正明显问题；
• 作者无法解释重要实现；
• 提交内容缺乏实际价值或不符合项目维护方向；
• 多次修改后仍然无法达到必要质量要求；
• 继续审查需要投入明显不合理的维护成本；
• 贡献存在不能通过常规修改解决的严重问题。

对于缺乏基本验证、明显不符合贡献要求或存在严重违规行为的内容，维护者可以直接关闭，无须重复进行完整技术审查。

关闭时应尽可能说明主要原因或引用对应规定。

4. 限制参与

对于严重或反复违反本方针的行为，项目可以限制相关人员继续参与仓库活动。

适用情况包括但不限于：

• 持续提交大量未经审查的 AI 生成内容；
• 反复规避披露或审查要求；
• 使用 Agent 批量发布 Issue、PR 或评论；
• 故意伪造日志、测试结果或其他证据；
• 故意泄露敏感信息；
• 在明确警告后继续进行相同违规行为。

对于情节严重的行为，可以跳过一般修改或关闭流程，直接采取相应措施。

具体限制范围和处理方式应根据实际影响及项目管理权限确定。涉及组织级封禁的操作，应由具有相应权限的管理人员按照组织管理要求执行。

5. 处理决定的复核

贡献者对处理决定存在异议时，可以说明具体理由并请求维护者复核。

复核时应优先考虑相关规则是否正确适用，以及原处理决定所依据的事实是否充分。

必要时，可以由未直接参与原处理的其他维护者协助复核。

提出复核请求不代表原处理决定自动撤销，也不意味着项目必须接受原有贡献。

6. 例外处理

对于确有技术必要、且无法完全遵循一般流程的特殊情况，贡献者可以在提交前向维护者说明原因并申请例外。

例外应针对具体贡献及明确的技术问题，不应作为长期规避本方针的方式。

维护者可以对修改规模、审查方式或验证要求作出适当调整，但不得因此免除作者责任、内容真实性、许可证及信息安全等基本要求。

附录：常见使用场景

使用场景	是否允许	主要要求
使用 GitHub Copilot 补全少量代码	允许	披露 AI 使用，检查补全内容
使用 AI 查询 API 用法	允许	披露使用情况，自行核实技术结论
使用 AI 生成一个完整方法	允许	详细披露、人工审查并完成验证
使用 AI 生成大量代码后直接提交	不允许	必须先理解、整理并符合规模与审查要求
使用 AI 分析维护者的审查意见	允许	作者必须理解问题并自行确认修改
直接将审查意见交给 Agent 自动修改并回复	不允许	不得跳过人工理解、验证和交流
使用 AI 翻译本人撰写的文档	允许	披露使用情况，人工校对译文
使用 AI 起草 PR 描述后直接提交	不允许	PR 描述必须由本人撰写
使用 AI 生成文档正文后简单修改并提交	不允许	不能以少量修改代替人工撰写
使用 AI 辅助分析 Bug 日志	允许	披露使用情况，人工确认分析结果
使用 AI 生成未经验证的 Bug 报告	不允许	不得将推测冒充已确认的问题
使用 AI 辅助编写测试	允许	验证测试有效性，不得伪造运行结果
使用 AI 辅助生成图标	有条件允许	核实版权、质量和使用权限
使用 Agent 在本地修改代码	允许	人工监督，提交前检查所有修改
使用 Agent 自主创建 PR 或发布评论	不允许	公开贡献与交流必须由人类负责
使用 AI 辅助维护者审查	允许	核实模型结论，人工作出决定并披露

本方针自正式发布之日起适用于新创建的贡献，以及生效后进行实质性更新的既有贡献。

项目可以根据维护需求及 AI 工具的发展情况修订本方针。涉及贡献者义务、禁止行为或违规处理方式的实质性修改，应通过正式文档更新发布。

与本方针有关的技术规范、PR 模板和贡献说明应保持一致。若其他文档中的旧 AI 使用要求与本方针不一致，以本方针为准。