COSMIC 收紧 AI 贡献规则：买的是可验收交付，不只是生成的代码

COSMIC 当前的 Pull Request 模板明确排除 LLM 生成的代码、注释和描述，还要求贡献者理解修改、能够回应审查、完成测试，并按要求确认贡献来源。这个规则在 10 月初受到新一轮关注。本文核验的是仓库目前的模板，没有确认它的首次生效日期，也不把它扩大为 System76 所有项目的统一禁令。

对购买 AI 开发服务的创始人来说，这件事揭示了一个具体问题：文件能运行，与目标接收方愿意并且能够接受这份交付，是两种不同的承诺。供应商可能很快做出一个好用的集成，却无法按依赖项目的规则把修复提交给上游。演示里没有出现的长期维护责任，就这样落到了你的产品上。

本文面向非技术创始人、AI 应用构建服务和依赖第三方仓库的小团队。重点是先明确交付要到哪里，再定义什么叫完成。你可以直接复用文中的验收说明表，记录每份产物由谁接收、遵守什么规则、来源可以如实说明到什么程度，以及被拒收后由谁维护。

核心判断是：AI 构建服务应承诺边界清楚、有人支持的交付，不能因为测试通过就承诺上游一定接受。下文主要是建议采用的产品与采购做法，并非 COSMIC 的实测结果，我们也没有向该项目提交测试性贡献。

1. 接收方规则是另一类交付要求

Pull Request，简称 PR，是请求另一个仓库纳入你的修改。它与把代码留在自己的项目里不是一回事。贡献规则决定接收方会考虑什么样的提交；软件许可证规定使用和分发的权限与条件。两者可能同时影响一份代码，但不能相互替代。

COSMIC 模板对生成内容的范围写得很明确。把描述改成人工撰写，不会让生成的代码符合要求；测试通过或增加人工审查，也不会改变它原本如何产生。正确做法是停止这条提交路径，遇到真正模糊的情形时按项目允许的流程澄清，或者选择在权利和运维上都成立的其他交付路线。不要把改写措辞当成修复来源的方法。

不同项目的要求确实不同。LLVM 的政策允许在人工审查和负责的前提下使用工具，要求对大量工具生成内容保持透明，并禁止没有人工批准就自主发布。它还限制在专门供新人学习的问题上使用 AI。这些是 LLVM 自己的条件，不能拿来替代 COSMIC 的条件。

创始人需要问的是：为了让产品计划成立，这份修改最终必须去哪里？如果是客户控制的仓库，就看客户的要求；如果是上游，就看上游的要求；如果只在自己的产品里维护，则要评估自己的维护能力。

演示往往把这些差别藏起来。它展示临时环境里的功能，却没有展示接收方同意承担后续工作的证据。在宣布完成之前，请供应商补上这项缺失的承诺。目标接收方也是交付计划的依赖，只是它不会出现在应用的依赖包清单里。

2. 应用交付和上游接受要分别验收

假设供应商同时提供三种结果：把应用部署到你的账户、由你的团队维护一个修改过的依赖，以及把修改贡献给上游从而免去自有补丁。三种结果的责任人和失败条件都不同。把它们合成一个“集成完成”勾选框，会掩盖还没结束的工作。

GitHub 的贡献指南把 Fork 与 PR 介绍为向其他项目提出修改的流程。流程提供的是提出请求的方式，并不保证修改会被合并。这一点应写进客户看得到的交付范围。

建议把验收拆成三个事件。第一，应用在约定环境里正常工作。第二，客户拿到源码、部署访问权限，以及足以维护约定行为的解释。第三，如果计划包含上游贡献，外部项目实际接受了提议。第一项成功，不能悄悄替代第三项。

如果上游接受是可选项，要说明等待期间怎么维护、被拒绝后怎么办；如果是必需项，被拒绝就是依赖受阻，不能改口说交付已经完成。供应商也不能代表维护者保证回复时间、审查结果或未来版本发布日期。

一个有用的范围说明可以是：“我们能通过这个临时补丁交付应用，但上游是否纳入尚未确认。在替换或接受之前，由指定负责人按约定支持范围维护。”这种说法没有演示时那么漂亮，却能帮助采购方比较真实选项。

价格讨论也会因此更准确。一个低价开发方案，如果留下期限不明、无人支持的补丁，可能不如一个使用原有依赖、功能稍少的方案。应比较的是完整支持责任，而不是哪条路线生成的代码更多。

3. 来源要靠记录，不能靠检测分数

这里的“来源记录”指产物如何产生、经过什么处理：是人工编写、工具生成、在已有成果上修改，还是经过了哪种审查。“看起来像人写的”并不能回答这些问题。

Developer Certificate of Origin，开发者来源证书关注贡献者依据什么条件，可以按指定许可证提交成果，以及相关贡献会留下公开记录。它既不是 AI 质量分数，也不表示所有接收方都允许所有生成方式。来源确认、目标项目规则和功能审查应分别处理。 Linux 内核关于编程助手的指南提供了另一个具体例子：相关贡献需要由人承担责任，并按要求注明工具协助。即使生成内容经过大量编辑，接收方也可能要求这些信息。请遵循具体项目的表述，不要设计一个标签就认为适用于所有仓库。

购买开发服务时，应让供应商在制作过程中保留简洁的来源记录。交付前才凭记忆回补，很容易漏掉 AI 生成的注释、引用的片段或自动写出的说明。无需保存每一条私人提示词，但要记录受影响的产物、相关参考材料、所用协助、审查负责人，以及会影响验收的不确定项。

无法确定来源时，就写“未知”。不要因为交期紧，把未知改成已经核验的声明。应限制交付目的地，或通过合适流程替换来源不明的产物。涉及重要且未解决的权利或合同问题时，应由相关专业人员作出判断后，再决定是否能作出所要求的确认。

对 AI 构建平台而言，这也是产品设计问题。导出页面如果引导客户确认一个平台本身尚未核实的来源，就容易造成误解。应展示真实记录，让有责任能力的人评估目标接收方要求的声明。生成工具不能创造一段并不存在的制作历史。

4. 人工负责必须有能力，不能只勾选

人工审查要有价值，负责的人就必须能解释修改、调查异议并支持结果。创始人不需要成为编译器工程师，才能识别这项能力是否缺失。让交付负责人解释一个具体失败情形，并展示会影响哪些行为。

登录功能可以问会话过期后怎么办；导入流程可以问部分失败时用户看到什么；修改过的依赖可以问下次升级与补丁冲突时谁处理。这些问题检查的是对后果的掌握，不是技术词汇量。

GitHub 对 Agent 功能的负责任使用说明指出，自动审查可能遗漏问题，也可能产生不准确的反馈。采购时应据此划清边界：AI 审查能帮助发现疑点，但它没有提出问题，并不等于已经有人承担维护，也不证明可以上线。

为产物指定负责人，并安排缺席时的替补。记录两者能够做到什么：复现问题、找到部署版本、解释修改、修订实现，以及恢复原先可工作的状态。如果供应商每次遇到追问，都只能再把问题交回同一个生成器，支持承诺仍然不确定。

小团队可以在采购批准前，购买少量相关领域的工程审查时间；也可以把范围缩小到有人能够理解的组件。一个规模小、解释得清楚、有人接手的适配，通常比一个看起来强大却无人熟悉的子系统更容易持续维护。

不必要求所有人理解每一行代码。应按后果匹配专业能力，如实分配技术责任。创始人负责采购和发布决定；合格审查者负责约定范围内的技术判断。如果剩余义务超出双方能力，双方都必须能够拒绝验收。

5. 把生成后的审查与维护成本算进去

生成便宜，不表示审查免费。一份贡献可以很快产出，却让接收方付出超过其收益的工作。GitHub 的开源贡献指南强调理解项目、适当沟通，以及让贡献对社区有用。对应用采购方而言，这意味着供应商应减少下一位接手者的负担。

使用事前成本表，而不是编造节省比例。记录制作、专业审查、接收方要求的修改、部署验证、预计补丁维护，以及验收失败后的替换工作。未知项单独列出。估算不是实测，上游的回复和审查时间也不能由你单方面排进日程。

下面是决策参考，不是 benchmark：

自行维护并非一定不合适。如果团队接受责任，并且有权使用和分发相关成果，它可以是合理的临时选择。问题出在供应商把它卖成不需要维护的结果。

交付后继续记录真实投入：审查时间、澄清轮次、升级工作和未解决问题。不能因为低报价把这些项目排除在比较之外，就让它自动胜出。同样，也不必给简单配置修改套上与安全敏感依赖修改一样的流程。过程的规模，应与下一位接手者实际需要验收的工作相匹配。

6. 具体场景：演示有用，交付目的地却不成立

设想一家名为 HarborDesk 的服务。非技术创始人正在购买一个用于客服工作流的桌面配套应用，供应商通过对某个 COSMIC 组件生成补丁，在演示中实现了希望得到的行为。这只是说明采购问题的假设场景，不是已有 COSMIC 集成案例，也不是我们测试过的产品。

供应商最初说，上线后会把补丁提交上游，因此客户无需自己维护。创始人要求提供接收仓库及其当前贡献规则。查到模板之后，团队发现原先的上游路线无法如实满足“不含生成内容”的声明。

这时，再测一次演示是在回答另一个问题。它可能证明功能能运行，却无法解除交付路线受阻。创始人需要的是责任明确的替代方案，不是更强烈地宣称代码质量很好。

第一种选择是使用现有支持接口，接受功能范围稍窄的体验。第二种是合法保留自有适配，指定维护人，并安排替换节点。第三种是委托真正合适的独立实现，由合格人员审查其来源与义务。把生成的补丁或描述重写一遍，并不能证明符合贡献条件；规则适用不清时，应如实说明产生方式后再澄清。

最终决定取决于客户需求。如果该桌面行为是已签署试点的必要条件，有支持的临时适配可能值得在限定范围内试用。如果它只是视觉体验上的加分项，缩减范围可能更划算。创始人应比较用户后果和持续支持，而不是因为舍不得漂亮演示而保留原计划。

HarborDesk 的验收记录应写明所选路线、维护负责人、什么升级会触发重新审查，以及哪些结果从未承诺。这样，后续团队就不容易又把“上游总会接受”当成默认前提。

7. 为每个目的地填写交付验收说明

可复用的产物是一份简短说明，针对每次重要交付填写。它是本文建议的工作模板，不是 COSMIC 要求。应与源码和支持约定一起交付，让下一位接手者分清哪些责任已接受，哪些只是期望。

不要把这张表理解成每一行都必须变绿的清单。“上游尚在审查，本次试点接受自有维护方案”可以是诚实的限制性结果。“来源未知，但确认是人工编写”则不成立。

交接前，让接收方读完说明，并用自己的话讲出剩余责任。这是理解检查，不是免责签字。如果客户认为供应商维护补丁，而供应商认为客户自己负责，就必须在验收前消除分歧。

重要规则有条件时保留快照或具体版本。只有一个动态链接，日后可能看到完全不同的政策。提交或续约时重新检查；旧记录只能说明当时看过什么，不能代表永久许可。付费客户项目也不应自动照搬开源规则，应使用客户实际同意的要求。

8. 产品状态必须对应已有证据

AI 应用构建工具可以明确区分：已生成、已在指定范围内审查、已交付客户、已外部提交、已被外部接受，以及已纳入生产支持。这些状态应来自可观察事件，而不是模型对完成情况的自信描述。

“已提交”需要真实提交记录；“已接受”需要接收方决定；“有支持”需要负责人和约定范围；“已审查”需要具体版本与检查内容。证据缺失时，展示较窄的状态，不要一律写成“完成”。

对仓库交付而言，GitHub 的受保护分支文档介绍了必需审查、状态检查，以及代码变化后撤销过期批准等设置。它们有助于保留技术审查边界，但不会自动判断来源声明是否真实，也不能覆盖接收方贡献规则。

具体做法是把这些控制与交付说明连接起来。发生实质修改后，更新产物记录，并指出哪些验收证据需要重做。一条注释可能不影响运行，却影响生成内容规则；一个依赖变化可能不改变可见功能，却改变支持责任。

不必让创始人阅读内部 Agent 轨迹。展示受影响的承诺即可：“审查后补丁发生变化，技术验收需重新确认”，或者“上游纳入未确认，本次发布依赖临时维护方案”。同时写明下一步与负责人。

有用的导出，还应包含离开构建工具后所需的源码和操作说明。如果客户只能请求工具再生成一次，交付仍可能依赖供应商服务。应在采购范围里写清这项依赖，不要把一个文件压缩包等同于完整的运维独立性。

9. 承诺交付前，先讨论失败时如何决定

在销售依赖外部验收的功能前，做一次简短的桌面推演即可，不需要真的向外部项目提交。目的在于检查证据或接收条件变化时，团队能否作出合适决定。

第一，代码测试通过，但接收方连生成的描述也禁止。负责人能否找出受影响产物，并停止不符合要求的交付？第二，另一个项目允许 AI 协助，但要求披露。团队是否保留了真实来源，还是到最后才编一个标签？

第三，补丁由自己维护，下一次依赖升级把它破坏了。谁调查、验证哪些用户行为、修复期间能否发布缩减版本？第四，上游拒绝提议。客户是否会知道支持计划发生变化，还是仪表盘依旧显示完成？

第五，人工审查的是旧版本，构建工具随后重新生成了实现。团队能否找到获批版本，并确定需要重新审查什么？第六，供应商无法联系。替补人员能否理解补丁目的和客户后果，而不必从一条新提示词重新开始？

每个回答都应留下决定与缺失能力，不要因为讨论听起来乐观就标记通过。没有维护负责人，依赖该补丁的发布应暂缓或移除相关功能；来源未知，相关确认就仍未解决；外部接受是可选项，则责任清楚的有限路线仍可能成立。

推演检查的是建议工作流程，不是模型智能。不要把它当成 AI 构建工具已经符合 COSMIC 或其他社区要求的证明。它的价值是在仍能调整采购与产品范围时，揭示演示原本会隐藏的具体责任。

10. 什么时候值得使用，什么时候不必完整套用

当交付依赖外部接受、特殊的依赖修改、客户的来源要求，或超出文件生成范围的支持承诺时，这份说明最有用。采购方即使无法亲自检查技术修改，也可以要求合格负责人和能读懂的决策记录。

如果只是使用普通接口做一个随时可丢弃的个人实验，完整填写可能过重。记录它的有限用途即可，不要暗示它已获准交付客户或作为外部贡献。关键是承诺给谁、交付会造成什么后果，而不是流程中有没有出现过 AI。

这份说明不能证明全部权利，不能检测每一段生成内容，不能要求维护者合并，也不能让无人支持的补丁自动变得安全。它同样不表示“禁止 LLM 贡献”就等于禁止使用相关软件。这些问题需要实际目的地、许可证、合同与合格判断。本文核验当前政策实例，并提出采购方法，没有报告验收率、客户节省金额或实验性能。

今天可以先挑出一个交付物：它的后续支持是否依赖某个尚未确认的外部事件？请供应商提供目的地、来源记录、负责审查的人，以及被拒收后怎么办。比较普通接口、自有支持适配和缩减功能三条路线，只批准团队真正能承担剩余义务的一条。

COSMIC 这次受到关注，是因为它让隐藏责任变得具体。长期的产品价值，则在于接收方能按自己的规则理解并维护成果。规模稍小但能被接受的交付，可能比一个更大、却无人同意接手的生成产物更值得购买。

参考资料

以下资料于 2026 年 10 月 5 日核验。现行规则可能变化，提交前请再次确认。八份资料分别支持论证的不同部分，并非同一事件的八篇转述。

1. COSMIC 当前 PR 模板：本文热点依据及产物范围。
2. LLVM AI 工具使用政策：带条件允许工具协助的另一种规则。
3. Linux 内核 AI 编程助手指南：人工责任与协助声明。
4. 开发者来源证书 DCO 1.1：来源确认的实际含义。
5. GitHub：向项目贡献：通过 Fork 和 PR 提出修改。
6. GitHub Agent 功能负责任使用说明：自动协助与审查的限制。
7. 开源指南：如何贡献：理解社区及提供有用贡献。
8. GitHub：受保护分支：技术审查控制与过期批准。