ecogetaway/oss-ai-contribution-policy

开源的开放贡献模式正在实时关闭。AI 辅助的贡献让维护者被大量看似合理的提交所淹没，而他们无法低成本地验证这些提交——项目正通过关闭那扇花了三十年才开启的大门来作为应对措施。 本仓库定义了一个**草案**形式的机器可读结构——**`ai-contribution-policy.yml`**——它允许项目以一种人类、CI、代码托管平台和 AI 编程代理均可读取的形式，一次性声明其 AI 贡献策略。它建立在一个核心设计决策之上：**验证，而非检测。** # OSS AI 贡献策略 **出处。** 属于 **OSS Infrastructure Initiative**（Sanjay C. 和 Aniruddh Raghavendra）的一部分。完整作品集请见 [配套项目](#companion-projects)。 _状态：早期阶段 —— schema v0.1 已起草，**九**个已验证的目录条目，首个案例研究已完成。详见 [FAQ](FAQ.md)。_ _借助 AI 辅助起草和研究；每一条事实陈述在发布前均经过与原始来源的独立验证。_ ### 请先尝试此操作 | 优先级 | 操作 | | --- | --- | | **1. 首要** | 将一个 [YAML 示例](spec/examples/)作为 `ai-contribution-policy.yml` 复制到你的仓库根目录 —— 详细步骤见 [ADOPTION.md](ADOPTION.md) | | **2. 次要** | 在辩论理论之前，请先阅读[策略目录](policy-catalogue/)（九个已验证条目） | | **3. 然后** | [添加一个目录条目](policy-catalogue/TEMPLATE.md)（约 15 分钟）或提交 `schema-feedback` / `pilot` issue | 请**不要**求人给仓库加星。有用的信号是复制的 YAML、目录的 PR 或对 schema 的批评。 ## 本仓库中使用的术语 - **策略文件** = `ai-contribution-policy.yml`，本项目定义的机器可读标准 - **披露** = 贡献者说明 AI 在贡献中扮演了什么角色 - **证明** = 贡献者确认具体的验证步骤（“我运行了测试”、“我理解每一行代码”） - **目录** = 已映射的、按项目划分的现有 AI 贡献策略语料库 - **案例研究** = 对真实项目与 AI 辅助贡献发生冲突的结构化书面分析 ## 问题所在 维护者是数字基础设施承重的关键人群，而 AI 生成的贡献量如今已成为导致他们职业倦怠的首要驱动因素。可见的受害者是公开的且在不断累积：curl 在大量 AI 生成的报告涌入下结束了其漏洞赏金计划；Ghostty 和 tldraw 限制了外部 pull request；Jazzband 解散了。每一次关闭都切断了一条公共资源自我更新的途径。 这种损害同时降临在三个群体身上： 1. **维护者** —— 几千人承担着与软件（嵌入在银行、医疗、政府和通信系统中）不成比例的重担，现在正花费他们最稀缺的资源（审查注意力）去筛选看似合理的垃圾信息。 2. **善意贡献者，尤其是新人** —— 如果没有披露和验证标准，负责任的 AI 辅助工作就会连同垃圾内容一起被一眼拒绝。来自全球南方、学生和转行的人正是最受益于 AI 辅助、也最受一刀切禁令伤害的群体。 3. **所有下游用户** —— 关闭的贡献 pipeline 会降低几乎所有人都在使用的软件的安全性和可维护性。 不管怎样，各个项目都在保护自己——使用几十种互不兼容的、手工制定的策略，埋没在 CONTRIBUTING 文件、issue 模板和博客文章中。防御手段是存在的。但缺乏一个**标准结构**。 ## 为什么是现在 - 趋势线正在活跃：每拖延一个月，就会有另一个项目关闭外部贡献而不是去管理它。 - 共识性的修复方案已经零星存在——披露加上人工验证——但还没有可以在其上运行的机器可读原语。 - 下游已经出现了一个修复市场：商业服务现在每次参与收费五位数，将 AI 生成的 codebase 重构回可维护状态（例如，[Slopfix](https://odra.dev/slopfix/)，一家拥有三名工程师的咨询公司，根据测量的代码减少目标收费约 1 万美元/周；获取于 2026-07-11）。当*疗法*都已经在出售时，标准化*在贡献边界进行预防*的案例就不言自明了——其成本仅为一个策略文件和一条审查途径。 - AI 编程代理越来越多地在采取行动之前读取仓库文件。标准的策略文件是在生成 pull request *之前*（而不是之后）有效的第一道防线。 - 机构的资金和注意力（OpenSSF 的 AI 完整性承诺、代码托管平台层面的兴趣）伴随着这个问题而来。建立一个有证据支持、社区拥有的标准——而非供应商拥有的标准——的窗口现在已经打开。 ## 10 分钟内采用 完整的采用前后对比：[`ADOPTION.md`](ADOPTION.md)。常见问题解答：[`FAQ.md`](FAQ.md)。 1. 复制一个符合你立场的示例——[宽松](spec/examples/oss-ai-contribution-policy.ai-contribution-policy.yml)或[严格](spec/examples/illustrative-strict-project.ai-contribution-policy.yml)——到你的仓库根目录作为 `ai-contribution-policy.yml`。 2. 编辑四项内容：你的项目名称、你针对各项资产的**立场**、你要求的**证明**，以及在**未披露**时的处理方式。 3. 将 `last_reviewed` 设置为今天并提交。从 CONTRIBUTING.md 链接到它。 这就是全部的采用成本。你的策略现在位于一个可预测的位置——无论是对于贡献者、CI，还是对于在行动前读取仓库文件的 AI 代理。如果你采用了它，请[告诉我们](https://github.com/ecogetaway/oss-ai-contribution-policy/issues)——早期采用者将塑造 schema v0.2。 ## 提议的标准 三个工件，按依赖顺序排列： ### `ai-contribution-policy.yml` 位于仓库根目录的文件——与 LICENSE、CODEOWNERS 和 SECURITY.md 同级——声明： - 项目针对各类资产（代码、文档、翻译、媒体）的**立场**：允许披露、受限或禁止 - 要求进行何种**披露**及其表达方式（PR 复选框、commit trailer） - 贡献者必须作出哪些**证明**（运行测试、理解更改、逐行审查输出） - 在**未披露**时会发生什么，清晰陈述，而不是在愤怒的评论区被发现 草案 schema：[`spec/ai-contribution-policy.schema.yml`](spec/ai-contribution-policy.schema.yml)，工作示例见 [`spec/examples/`](spec/examples/)。 ### 2. 贡献者途径 关于善意贡献者如何遵守的规范：披露角色、验证证明、提供证据。其设计使得遵循它比逃避它*更容易*，并且使得首次贡献者无需阅读辩论帖子也能成功。 ### 3. 证据基础 一个不断增长的现有按项目划分的策略目录（[`policy-catalogue/`](policy-catalogue/)）和针对真实冲突的深度案例研究（[`case-studies/`](case-studies/)）——从而让 schema 编码的是项目真正需要的东西，而不是听起来合理的东西。 **目前：** 九个目录条目（每个条目均在捕获日期与原始来源进行核对）。通过 good-first-issue 扩展目录是最快的帮助方式。 | 项目 | 立场 | 独特特征 | | --- | --- | --- | | [Ghostty](policy-catalogue/ghostty.md) | 允许披露 | 担保系统；公开谴责名单；禁止 AI 媒体 | | [LLVM](policy-catalogue/llvm.md) | 允许披露 | `Assisted-by:` trailer；禁止自主代理 | | [curl](policy-catalogue/curl.md) | 允许披露 | 对安全报告的规定更严格；漏洞赏金计划于 2026 年 1 月结束 → [案例研究](case-studies/curl-bug-bounty-closure.md) | | [Godot](policy-catalogue/godot.md) | 允许披露 (代理) | 直接针对 AI 代理本身的策略 | | [NetBSD](policy-catalogue/netbsd.md) | 除非升级否则禁止 | LLM 输出“被假定为受污染”；核心批准例外 | | [QEMU](policy-catalogue/qemu.md) | 禁止 | 源于 DCO/版权出处的禁令 | | [servo](policy-catalogue/servo.md) | 禁止 | 四个经过论证的理由；明确的重新审查条款 | | [Gentoo](policy-catalogue/gentoo.md) | 禁止 | 2024 年委员会投票；打包工作除外 | | [tldraw](policy-catalogue/tldraw.md) | 对外部 PR 关闭 | 彻底关闭途径，被描述为暂时性的 | **为什么是验证，而不是检测：** 每一种基于检测的方法都是一场检测方必败的军备竞赛。无论模型变得多么强大，对人工审查、测试和理解的证明始终具有意义。正是这一决定使得该标准免于在发布之初即告过时。 ## 谁将受益 | 群体 | 对他们而言改变了什么 | | --- | --- | | 维护者 | 一个已声明的策略取代了每个 PR 的争论；不匹配的贡献在消耗审查注意力之前就被过滤掉 | | 善意贡献者 | 一条可见、可实现的途径——披露与验证——取代了猜测或被一眼拒绝 | | 新贡献者 | 入门通道保持开放；一刀切的禁令被明确的、可达到的期望所取代 | | AI 编程工具 | 一个他们的代理可以在生成 PR *之前*读取的文件，使策略合规自动化 | | 代码托管平台和基金会 | 一个可以原生展示的标准结构，就像今天的 SECURITY.md 被展示一样 | | 下游用户 | 保持开放和经过审查的贡献 pipeline，而不是关闭或不堪重负 | ## 这是什么 / 这不是什么 | 这是什么 | 这不是什么 | | --- | --- | | 一个机器可读的策略标准和贡献者途径 | 一个 AI 检测工具或军备竞赛参与者 | | 一个证据基础：编目的策略和评分的案例研究 | 一篇评论文章或某个项目泛化的意见 | | 社区拥有，Apache-2.0，致力于走向标准化机构 | 供应商的切入点或贡献面前的付费门槛 | | 一种在 AI 压力下保持贡献途径开放的方法 | 对 AI 辅助的禁令——或对未披露使用的认可 | ## 维护者原则 该标准由维护者建立并为维护者服务，基于三项承诺： 1. **验证重于检测。** 我们从不问“这是 AI 写的吗？”——一个无法回答的问题。我们问“有人工验证过吗？”——一个可回答的问题。证明的是人类行动：运行了测试、检查了行为、理解了每一行代码。 2. **清晰重于复杂。** 策略文件必须能在十分钟内写完，在一分钟内读完。任何需要律师或委员会来填写的字段都是我们要移除的字段。 3. **开放重于守门。** 成功的标准不在于这个标准过滤掉了多少，而在于它放行了多少善意的贡献者。如果一个策略文件只能说明“不”，即使它在语法上是有效的，那也是该标准的失败。 ## 路线图 **阶段 1 —— 证据（当前）。** 将目录扩展到最初的九个已验证条目之外；编写额外的锚点案例研究（候选者包括 Ghostty、tldraw、Jazzband）；发布让该模式无可辩驳的实地报告。 **阶段 2 —— 标准。** 针对 schema v0.1（在此起草）根据目录进行加固：每个字段都必须通过映射到真实项目已经在手工做的事情来赢得其存在的理由。与之同步的还有贡献者途径规范。 **阶段 3 —— 试点。** 2-3 个仓库采用该策略文件；测量在采用前后，到达维护者审查环节的不匹配贡献量以及首次审查的中位时间。每季度发布，包括负面结果。 **阶段 4 —— 机构化。** 向一个成熟的标准化机构（类似 OpenSSF 的工作组）提议成立一个工作组，以便该标准能够比这个仓库活得更久。在代码托管平台中原生展示该文件是最终目标。 ## 试点邀请 如果你维护着一个接收 AI 辅助贡献的仓库——无论是欢迎的、不欢迎的还是未披露的——我们希望有 2-3 个试点项目采用 `ai-contribution-policy.yml` 并让我们测量发生了什么变化。试点将获得：编写其策略文件的帮助、已记录的基线数据，以及作为该标准联合设计者的公开荣誉。请使用 `pilot` 标签打开一个 issue，或查看置顶的试点 issue。 ## 治理与后续步骤 - **许可证：** Apache-2.0。该标准保持开放和社区拥有；这是一个设计约束，而不是偏好。 - **决策：** 在本仓库的公开 issue 中记录，schema 的变更设有评论期。随着维护者小组的形成（有偿维护者联合设计是获得资助的路线图的一部分），schema 权限将转移给它。 - **长期归宿：** 这个仓库是孵化器，而不是终点。阶段 4 提议在试点产生值得标准化的证据后，将该标准纳入一个成熟的机构（类似 OpenSSF 的工作组）。 - **下一步具体计划：**目录扩展到九个已验证条目之外；更多的案例研究；开放对 schema v0.1 逐字段的审查以征询意见。见 [FAQ](FAQ.md) 和 [ADOPTION.md](ADOPTION.md)。 ## 预期问题 详见完整的 [`FAQ.md`](FAQ.md)。简短版本： **这难道不又是一个关于 AI 和开源的观点吗？** 不——它首先是一个目录。九个项目的策略已根据实时的原始来源进行了验证，一个深度的案例研究，以及一个每个字段都必须映射到真实项目已经在手工做的事情的 schema。在证据不足的地方，文档都作了说明。 **为什么不直接检测 AI 生成的贡献呢？** 检测是一场检测方必败的军备竞赛。无论生成能力变得多强，对*人类行动*的证明始终具有意义。 **那些完全禁止 AI 贡献的项目怎么办？** 草案对立场保持中立。`prohibited` 是一等公民——机器可读的“不”比被埋没的“不”更有用。 **这究竟如何执行？** 社会性证明（类似 DCO）加上针对未披露 AI 的已声明处理方式——而不是作者身份证明。详见 [FAQ](FAQ.md)。 **谁来决定标准里包含什么？** 目前在这里通过公开 issue 决定；一旦试点产生证据，长期归宿将打算定在一个成熟的机构。这个仓库是孵化器，而不是宝座。 ## 相关工作 - arXiv 的 AI 贡献策略分类法和 RedMonk 的策略目录描述了该领域——两者都不拥有机器可读的原语。本项目构建了该原语，并引用了这两者。 - DCO 和 CLA 工作流证明了在开源中大规模进行按贡献证明是可行的。 - SECURITY.md 的历史就是采用的模型：一个简单的文件，一个清晰的结构，然后是代码托管平台的原生展示。 ## 配套项目 三个仓库，一种方法：记录某个贡献领域在真实仓库中究竟是如何失败的，然后构建证据表明缺失的最小机器可读基础设施。每个领域的采用都会增加其他领域的可信度。 | 领域 | 仓库 | 构建的内容 | 成熟度 | | --- | --- | --- | --- | | 国际化 | [oss-language-inclusion](https://github.com/ecogetaway/oss-language-inclusion) | 翻译字符串的贡献证据 + `i18n-security-lint` CI 工具 | 最成熟的；方法已在 CACM Blog 和 DevOps.com 上发布 | | 无障碍 | [oss-accessibility-inclusion](https://github.com/ecogetaway/oss-accessibility-inclusion) | 如何审查无障碍 PR；审查评分标准 + 草案 `a11y-signals.yml` | 活跃 | | AI 贡献 | [oss-ai-contribution-policy](https://github.com/ecogetaway/oss-ai-contribution-policy) | 机器可读的 `ai-contribution-policy.yml` 标准（验证重于检测） | 早期证据收集阶段 | Licensed under Apache-2.0.

标签：AI规范, 开源治理, 数据管道, 标准化, 社区治理, 软件工程, 配置规范, 防御加固