过去一年，随着 GitHub Copilot、Claude、GPT 系列模型以及各类本地化代码助手的普及，「AI 写的代码到底归谁」从学术讨论迅速演变为工程团队日常面临的现实问题。一位开发者在 Copilot 的补全提示下按下 Tab 键接受了一段二十行的实现，这段代码随后进入公司核心仓库并随产品分发——此时，版权归属、许可证合规、侵权风险这三条线同时被触发。本文尝试从法律框架、模型训练机制、开源许可证交互以及工程实践四个层面，系统梳理这一争议的核心争点，并给出可落地的应对建议。

一、争议的起点：AI 生成物是否构成「作品」

版权保护的前提是存在「人类作者的独创性表达」。这是伯尔尼公约体系与包括中国《著作权法》在内的多数国家立法共同坚持的原则。问题的关键在于：当代码由模型生成时，人类贡献了什么？

目前业界大致形成三种立场。第一种认为，用户通过提示词（prompt）表达了对功能、结构、风格的取舍，这种「选择与编排」构成独创性贡献，生成物可视为用户作品。第二种认为，模型输出具有不可预测性，用户的控制力有限，不满足独创性要求，生成物应进入公有领域。第三种折中立场则主张按「人类参与程度」分层判断：高度具体的提示、多轮迭代修改、后续人工重构，都可能提升人类贡献的比重。

司法实践尚未给出统一答案。美国版权局在 2023 年的多份决定中明确，纯 AI 生成内容不受版权保护，但人类对 AI 输出进行实质性选择、编辑和编排的部分可以受保护。中国法院在涉及 AI 生成图片的个案中，曾以「是否体现人的智力投入」作为判断标准。对开发者而言，这意味着一个务实的结论：不要指望「AI 生成」本身带来清晰的权属，而应通过人工介入的程度来主动构建可主张的创作痕迹。

二、训练数据：模型「读过」的代码如何影响输出

版权争议的另一面在输入端。主流代码模型多在 GitHub 等平台的海量公开仓库上训练，其中包含 GPL、AGPL、MPL 等 copyleft 许可证下的代码，也包含大量无许可证声明的私有项目。这带来两个层次的隐忧。

其一是「记忆与复现」风险。研究者在特定条件下可以让模型逐字输出训练语料中的片段。若生成结果与某段 GPL 代码高度相似，而该代码被用于闭源商业产品，就可能构成许可证违约甚至侵权。GitHub 曾推出 Copilot 的重复代码过滤器，并承诺对符合条件的诉讼提供法律保护，但这并不免除使用者自身的合规审查义务。

其二是「衍生作品」的定性难题。模型权重是否构成对训练数据的衍生，目前各国尚无定论。美国法院在若干训练数据诉讼中倾向于要求原告证明具体侵权输出，而非仅凭「模型见过我的代码」主张权利。这一举证门槛对权利人不利，但也提醒开发者：风险不在于模型训练本身，而在于你实际引入仓库的那段代码。

三、开源许可证的交互：copyleft 与 AI 补全的冲突

这是工程实践中最容易踩坑、也最需要制度化处理的环节。设想一个典型场景：团队在开发闭源 SaaS 产品时使用 AI 助手，助手补全了一段与某 AGPL 项目结构相似的实现。AGPL 的传染性要求网络服务提供者公开源代码，一旦被认定为衍生作品，整个服务端代码可能面临披露义务。

需要区分几种情况。若生成代码与受 copyleft 保护的代码在表达上实质相似，风险最高；若仅思想、算法层面相似而表达不同，通常不构成侵权，因为版权保护表达而非思想。但「思想与表达」的边界在代码领域本就模糊，函数签名、数据结构、控制流的组合方式都可能成为争点。

对使用 MIT、Apache-2.0 等宽松许可证代码的场景，主要义务是保留版权声明与许可证文本。AI 生成时往往剥离了这些元信息，若开发者直接采纳而不追溯来源，就可能违反归属要求。实践中建议建立「AI 代码来源标注」机制：对疑似来自训练语料的片段，记录模型、提示词、生成时间与人工修改记录，为后续审计留痕。

四、平台条款：你签的用户协议已经分配了部分权利

多数开发者忽略的一点是，AI 编程工具的服务条款本身就在分配权利义务。GitHub Copilot 的条款规定，用户对其输出负责，GitHub 不主张对建议代码的版权，但也不保证其非侵权性。部分商业模型提供商则明确保留对输出的某些权利，或限制将输出用于训练竞品模型。

这意味着「版权归谁」在很大程度上取决于你使用的工具与订阅层级。企业采购时应重点审查三类条款：输出所有权归属、侵权赔偿（indemnification）范围、以及是否允许将代码用于模型再训练。后者尤其关键——若企业代码被回传用于改进模型，可能造成商业秘密泄露，这已超出传统版权范畴，进入数据治理领域。

五、工程侧的落地建议

法律框架短期内难以尘埃落定，工程团队更应建立可操作的防线。以下措施按成本从低到高排列，建议至少落实前三项。

第一，建立 AI 代码准入清单。 明确哪些仓库、哪些模块允许使用 AI 辅助，核心算法与涉及 copyleft 依赖的模块建议禁用或强制人工重写。将策略写入贡献指南（CONTRIBUTING.md），并在 CI 中加入检查。

第二，强制来源标注与人工复核。 要求开发者在提交信息或 PR 描述中标注 AI 参与程度，对 AI 生成比例较高的变更安排第二人审查。审查重点不是风格，而是是否存在与已知开源项目的实质相似。

第三，引入相似度扫描。 在 CI 流水线中集成代码克隆检测工具，对新增代码与公开语料库做比对，命中高风险片段时阻断合并。这类工具无法覆盖全部训练数据，但能拦截明显的逐字复现。

第四，保留创作过程证据。 记录提示词、迭代历史、人工修改 diff。一旦发生权属争议，这些记录是证明人类独创性贡献的关键材料，也是主张「独立创作」抗辩的基础。

第五，法务前置介入高风险项目。 对涉及核心知识产权、拟申请专利或对外授权代码的项目，在立项阶段即评估 AI 使用边界，必要时选择提供侵权赔偿承诺的商业工具，并购买相应的知识产权保险。

结语：不确定性中的确定性

AI 生成代码的版权争议，本质上是工业时代的版权框架面对概率性生成技术时的适配困难。短期内，立法与判例都难以给出终局答案，开发者不应等待「规则明确」再行动。可以确定的是三点：人类贡献越具体、过程记录越完整、来源审查越严格，权属主张就越稳固、侵权风险就越可控。把 AI 当作一位能力很强但背景不明的协作开发者——用它提高效率，但对它交付的每一行代码保持审查与留痕的习惯，这是当前阶段最理性的工程姿态。