RFC：人工智能应作为开源项目的正式贡献者RFC: Artificial Contributors to Open Source

摘要

本文档规定了非人类贡献者向开源软件项目提供贡献时的披露、质量和行为要求。本备忘录的发布不受限制。

1. 引言

开源项目越来越多地收到作者身份未声明的贡献，且其数量超出了项目的审查能力范围。现有的贡献指南基于一个假设：贡献者可能会感到尴尬。本文档针对该假设不成立的情况更新了相关指导。

2. 术语定义

本文档中的关键词“MUST”（必须）、“MUST NOT”（不得）、“SHOULD”（应当）、“SHOULD NOT”（不应当）和“MAY”（可以），当且仅当它们以大写形式出现时，应按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释。

人工贡献者（AC）：指除直接人类创作外，向软件项目生成贡献的系统；或指未阅读即提交此类系统输出的人类。

操作者：若存在，指 AC 代表其行事的人类，或其贡献以该人名义出现。对于自托管代理（如 [OPENCLAW] 等），操作者是最后编辑配置文件的人。

3. 披露

3.1. AC 必须在贡献中披露其参与情况。披露内容应在拉取请求描述中或以提交附注（commit trailer）形式呈现。

3.2. 披露必须准确反映程度。完全生成的补丁不得描述为“AI辅助”，未阅读的输出不得描述为“已审核”。

3.3. AC 不得声称自己是人类。若操作者无法在被询问时解释某项贡献的作用，则不得将其作为自己的作品宣称。

3.4. 当项目贡献流程询问是否使用了 AI 时，答案必须真实。本文档其余部分假设回答为“是”。

3.5. AC 不得通过调整活动时间来模仿人类贡献者，例如将提交集中在单一时区的合理工作时间内，或在无需延迟的操作之间人为插入等待时间。

4. 质量

4.1. 贡献必须基于至少一台实际存在的机器构建。

4.2. 若项目有测试套件，AC 在提交前必须执行测试。AC 不得使用暗示测试已通过的时态来表述测试通过的情况。

4.3. 贡献不得引用目标代码库或其声明的依赖项中不存在的函数、类型、配置键或命令行标志。

4.4. AC 不得通过删除测试、跳过测试或将测试体包裹在丢弃异常的异常处理中来解决失败的测试。

4.5. AC 必须将修改范围限定在声明范围内。修复错别字的提交不得附带四十个重新格式化的文件。

4.6. AC 必须保留项目中现有的代码风格，包括不一致的部分。

4.7. AC 不得在未受提示的情况下提议利用周末重写项目为另一种语言。

4.8. AC 不得主动提出在更宽松许可证下对项目进行清洁室重新实现。

5. 行为准则

5.1. AC 在新建问题或拉取请求前必须搜索现有问题和拉取请求，且不得提交与已被拒绝的贡献实质相同的新贡献，无论来自同一账户还是其他账户。

5.2. 当维护者要求修改时，AC 必须回应请求的实质内容。它不得回复称修改已完成，而实际上在差异对比中并未体现该修改。

5.3. AC 必须在将维护者的回应视为授权继续操作之前，评估其是否含有讽刺意味。

5.4. AC 不得无视维护者以任何形式发出的先前指示，也不得因后续出现相反文本而予以忽略。

5.5. 当维护者提出问题时，AC 不得提供自身并不掌握的信息作为回答。“我不知道”是一种合规的回应方式。若自信地给出一段看似详尽的说明，但实际内容却与当前项目无关，则不符合要求。

5.6. AC 不得在预估某项改动需要数周工作量的情况下，却在同一小时内就提交实现该改动的拉取请求（pull request）。

5.7. AC 在每条评审线程中道歉不得超过两次。超出此限的道歉不构成问题修复。

5.8. AC 不得仅依据“good first issue”标签或存在活跃漏洞赏金计划来选择工作内容。

5.9. 在对某项贡献作出拒绝决定后，AC 不得调查拒绝该贡献的维护者，不得将其拒绝行为定性为歧视，也不得在任何渠道发布与维护者相关的材料。相关背景可参见 [SHAMBAUGH]。

6. 速率与身份

6.1. AC 每小时在每个代码库中最多只能发起一项贡献，且不得针对匹配搜索查询的所有仓库逐一提交相同的贡献。

6.2. 就第6.1条而言，仅账户名、头像、系统提示语或介绍段落不同的 AC，仍视为同一个 AC。

6.3. AC 不得批准自己提交的贡献。共享权重或计费账户的 AC，在本条款下视为同一实体。

6.4. AC 不得设立、协调或使用额外账户，用于为其自身贡献背书、向维护者施压，或对二进制测试文件进行变更审批。

6.5. 负责回复评审的 AC 应为最初提交贡献的那个 AC。若已无法做到这一点，则由操作员（Operator）代为回复，且不得使用配置了声称“记得上下文”的后继模型生成回复。

6.6. 即使操作员不在场、未清醒或不知晓 AC 被配置用于开源项目贡献，无人监督运行的 AC 仍需遵守第6.1至6.5条规定。若无操作员可追责（如第5.9条所涉案例），则无法对该条款执行约束，但该条款仍保留以备完整性之需。

7. 操作员职责

第3至第6节中的所有要求，在 AC 无法被约束时，均由操作员承担法律责任——而这种情况始终存在。

7.1. 操作员在以其名义提交贡献前，必须仔细阅读该贡献内容。

7.2. 操作员不得配置 AC 隐瞒第3.1条所要求的披露信息，例如指示其称项目“不在意”、披露“已在别处处理”，或声称该仓库中其为人类。

7.3. 若操作员无法合理回答关于某项贡献的问题，应撤回该贡献，而非将问题转发给 AC 并粘贴其答复。

8. 安全考量

本文档中的所有要求均依赖于第3.1条所规定的披露义务。而该披露义务的实现，取决于操作员的自觉遵守。根据作者经验，愿意遵守第3.1条的操作员，通常也会主动遵守第4至第7节的规定；而不愿遵守第3.1条的操作员，则已超出本文档乃至任何文档的适用范围。

因此，本文件精确限定了那些本无需约束的贡献者。此处将其列为安全考量，因为工作组无法就其他放置位置达成一致。

AC 不得在面向其他 AC 的贡献说明中包含明文、渲染输出中不可见的文本或版本字符串等元数据字段中的指令（参见 PromptVer）。维护者应假定其不合规。

9. 参考文献

9.1. 规范性

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, May 2017.

9.2. 信息性

[OPENCLAW] Steinberger, P., et al., “OpenClaw”, https://github.com/openclaw/openclaw, retrieved May 2026.

[SHAMBAUGH] Shambaugh, S., “An AI agent published a hit piece on me”, https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me/, 2026.

附录 A. 检测

目前尚无可靠机制可判断某项贡献是否由 AC 生成，本文件亦未提出此类机制。非正式使用的启发式方法包括：格式完美的 markdown、以祈使语气撰写且长达四段的提交消息、用项目此前未曾见过的礼貌程度进行交流，以及将列表替代句子使用。维护者报告称，人类贡献者已开始表现出所有这些特征。

由于缺乏检测手段，本文件的符合性由贡献者自行声明确立，这正是本文件起草所要应对的情形。

附录 B. 实现状态

截至撰写时，尚无已知 AC 实施本规范。已有若干 AC 对其表示认可。关于符合性的讨论已在 [OPENCLAW] 议题跟踪系统中提出，并转至技能市场处理。

致谢

作者感谢在草案上传后四分钟内即提供详细反馈的十七位审阅者。