AI 写出的代码到底归谁：版权、雇佣关系与开源污染风险

Claude Code、Cursor、Codex 这一类代理式编程工具已经进入真实交付流程。代码可以由模型规划、生成、迭代，再由开发者审查、测试、合并。工程效率确实提高了，但法律归属并没有因为工具更强而自动清晰。

AI 辅助代码的归属通常取决于三个问题：

是否存在足够的人类创作性贡献，从而形成可受版权保护的作品
即便存在版权，该权利是否已经因雇佣关系或 IP 转让条款归属于雇主
生成结果是否夹带了开发者看不见的开源许可证义务，尤其是 GPL/LGPL 一类传染性许可证

这三个问题都与代码质量无关。代码写得再好，也不改变其法律状态。

有一个高度浓缩这些问题的现实案例：2026 年 3 月 31 日，Anthropic 因一个缺失的配置文件，在一次常规软件更新中意外公开了约 51.2 万行 Claude Code 源代码。天亮前，这份代码已经被镜像到 GitHub；早餐前，就有人借助 AI 工具将整个项目改写为 Python，名为 claw-code 的仓库单日达到 10 万 GitHub stars，刷新纪录。随后出现了 DMCA 下架请求，也随之引出了一个尖锐问题：

如果一套代码主要由 AI 写成，发布方是否真的拥有它的版权？如果这类代码本身未必受版权保护，DMCA 下架请求又是否站得住脚？

这个问题并不只属于大公司。任何在生产环境中交付 AI 辅助代码的团队，都会碰到同一组判断。

版权的起点：只有人类创作才受保护

当前可把握的法律基线非常直接：版权只保护由人类创作的作品。

美国版权局长期坚持这一立场，DC Circuit 在 Thaler 案中也支持了这一原则。2026 年 3 月，美国最高法院拒绝受理 Thaler 的上诉。这里需要区分一件事：不受理上诉，不等于最高法院对下级法院推理作出全国性背书；它只意味着下级法院判决维持有效，版权局的现行立场没有被推翻，也还没有法院明确走向相反方向。

因此，按目前相对稳定的法律框架看：

主要由 AI 生成、缺乏实质性人类作者贡献的内容，不具备版权保护资格
这一点在原则上较稳定
但对于 AI 辅助编程场景中的“多少人类参与才算足够”，仍未形成最终明确的裁判标准

Thaler 案真正解决了什么，没有解决什么

Thaler 案的边界需要看清：

该案涉及的是一幅完全没有人类参与的作品，申请人直接把 AI 系统列为唯一作者，也没有主张任何人类创作贡献
该案对象是视觉艺术，并非 AI 编程工具输出的代码

所以，这个判决并没有直接回答“人和 AI 协作写出的代码，何时具备版权”这一更难的问题。它提供的是一条推理路径，而不是面向代码的直接先例。

对代码的直接含义

如果某段代码由 Claude Code、Cursor 或类似工具生成，而开发者只是直接接受、没有做有意义的修改，这段代码很可能谁都不能主张版权。

后果并不抽象。如果竞争对手直接复制这段代码，权利人未必能获得版权法上的救济。它在法律效果上可能接近“公有领域”，尽管工程团队主观上并不会这样理解。

关键标准：有意义的人类作者身份

决定一段 AI 辅助代码是否受保护的核心短语，是 meaningful human authorship，即“有意义的人类作者身份”。

版权局并没有把它量化成“至少人工修改 30%”或“至少改 200 行代码”这种标准。法院和监管判断更看重的是：人类是否作出了真实的创作性选择。

典型可作为证据的行为包括：

选择系统架构
决定保留什么、拒绝什么
重构生成结果，使其符合特定设计目标
明确约束模块边界、状态管理、错误处理方式
基于工程意图重写关键实现而不是机械接受输出

单纯给模型下达目标，通常不够。真正关键的是是否主导了作品的构造方式。

代理式工作流中的灰区

在 agentic workflow 里，这条线比看起来更难划。

一个常见场景如下：

开发者输入一句提示：build a rate limiting module for the API
工具自行规划方案，生成 5 个文件，迭代 3 个版本
开发者检查输出、跑测试、执行合并

在这个流程里，人类的贡献可能包括架构意图和最终批准。但这些贡献是否足以在法庭上构成“有意义的人类作者身份”，目前并没有确定答案。

较稳妥的判断只能分层看：

实质性重定向和重构过的模块：较可能成立
逐字接受、几乎未改的输出：较可能不成立
介于两者之间的部分：不确定

正在形成中的判断标准

围绕这个中间地带，争议还在继续。

Allen v. Perlmutter 一案中，Jason Allen 对版权局拒绝登记其作品提起挑战。他为作品编写了 600 多条详细提示，并在 Photoshop 中继续编辑。版权局承认 Photoshop 编辑部分具有人类创作属性，但仍拒绝对 AI 生成的基础元素给予登记。该案尚未得出最终结果，但它很接近“人类参与达到何种程度才足够”的核心争点。

另一个更具操作性的先例是 Zarya of the Dawn。版权局对其中人类创作的文字给予登记，但拒绝对 Midjourney 生成的图像部分授予保护。这个处理思路对软件开发有现实意义：AI 辅助代码库中，人类写出的部分可以与生成部分分离看待，分别判断是否受保护。

因此，真正值得保留的，不只是代码文件本身，还包括：

架构设计文档
ADR
详细 commit message
提示词记录
显示开发者主动重定向模型输出的会话日志

这些材料本身就可能构成可被识别的人类创作表达。

雇主很可能已经拥有相关权利

在讨论代码是否具备版权之前，常常还有一个更现实的问题：即便具备版权，它是否已经不是开发者个人所有。

work-for-hire：职务作品规则

版权法里有一个成熟原则：work-for-hire。对于员工在受雇范围内完成的作品，雇主通常被视为法律上的作者和权利人。

这意味着，只要代码是在以下条件下形成：

工作时间内
工作项目中
工作设备上
依照岗位职责产出

那么即使代码由手写、AI 生成，或两者混合完成，权利通常都归雇主，而不是开发者个人。

合同条款往往比默认规则更宽

现实中，很多劳动合同不会停留在法定默认规则，而是通过 IP Assignment、Intellectual Property、Work Product 等条款把范围继续扩张。

高风险表述通常包括：

“任何使用公司设备或资源完成的工作成果”
“雇佣期间形成的任何发明或开发成果”
“借助公司许可工具完成的软件”

第三类对 AI 编程尤其敏感。假如公司为团队购买了 Claude Code、Cursor 或 Copilot 许可，而开发者在个人项目中继续使用同一套公司许可工具，那么即便项目是在下班时间完成，宽泛的 IP 转让条款也可能让雇主提出权利主张。

“上下文感知”可能被雇主拿来扩张解释

一个典型争议场景是这样的：开发者白天用 Claude Code 处理公司项目，晚上和周末继续做自己的健身记录应用；随后公司更新 IP 政策，主张所有借助 AI 辅助完成的成果都归公司所有，理由是 IDE 中打开过公司代码，AI 工具具有“上下文感知”能力，输出因而属于公司 IP 的派生作品。

这种说法从法律逻辑上并不牢固。IDE 中看得见附近文件，不等于输出当然构成派生作品；模型生成本质上是概率式模式补全，不等于对相邻源码的直接复制。但只要合同条款写得足够宽，这类主张就会具备相当强的表面正当性，足以在争议中制造成本。

侧项目的最低风险做法

如果打算做个人项目，至少应做到工作流隔离：

使用个人账号
使用个人机器
使用个人付费工具
不在个人项目中调用公司授权的 AI 编程服务
不让个人项目与公司仓库、公司 IDE 上下文、公司云资源发生交叉

这不是形式主义，而是后续权利证明的基础。

最容易被忽视的问题：开源许可证污染

即便代码归属清楚，也不代表可以放心发布。AI 编程工具的另一个风险是：生成结果可能带着开发者看不见的开源许可证义务。

风险来自训练数据

AI 编程工具在海量公开代码上训练，其中包含 GPL、LGPL 等 copyleft 许可证代码。此类许可证的特点不是“要求署名”这么简单，而是附带会向下游传播的义务。

对 GPL 类许可证，可以先把几条底线记清：

如果分发的软件是 GPL 代码的派生作品，通常必须以相同许可证公开源代码
即使开发者不知道嵌入的代码来自 GPL 仓库，也不当然免责
“我不知道”通常不是违反 copyleft 义务的抗辩理由

真正的法律风险在“实质性逐字复制”

这里必须区分两类情况：

情况	风险判断
AI 生成了功能相似、思路相似的实现	风险较低，通常不足以直接构成侵权
AI 生成了与 GPL/LGPL 代码实质性逐字相同的片段	风险显著，可能触发版权和许可证问题

关键标准不是“看起来像不像”，而是是否存在substantial verbatim reproduction，即实质性的逐字再现。

如果一个 AI 工具从训练数据中复现了大量 GPL 代码，而这些内容被直接放进商业产品中，又没有按 GPL 要求开放源代码，那么即便开发者从未接触过原始仓库，也可能已经制造出 copyleft 违规。

问题在于：肉眼通常看不出来。
不扫描代码库，就无法知道生成结果落在“功能相似”一侧，还是“逐字复制”一侧。

社区争议已经把问题暴露出来

2026 年初，围绕 chardet 的一次社区争议把这个问题摆到了台前。有人借助 Claude 将 chardet 这类 Python 字符编码库重写，并以 MIT 许可证重新发布，主张这是一个“clean room”实现，因此不受原 LGPL 约束。

真正的争议点不在“是否重写”，而在：

如果模型训练时见过 LGPL 代码库
输出又再现了其中实质性逐字段落
那么这种输出能否被视为“无许可证负担”的新作品

这一问题还没有得到法院的最终裁判。确定无疑的只有一点：对 GPL 代码的逐字复制，不会因为复制动作经由 AI 完成就自动免责。

哪些是确定的，哪些还在争议中

可以把现状分成三层。

已相对确定的部分

缺乏人类作者身份的作品，通常不具备版权保护资格
work-for-hire 规则不因为代码由 AI 生成而失效
对 GPL 代码的逐字复制会触发许可证义务，复制方式并不改变这一点

尚未被最终裁判解决的问题

在代理式编程工作流中，人类参与到什么程度才足以形成有意义作者身份
AI 输出再现训练数据模式时，何种程度会被认定为“逐字复制”

纯粹仍属推测的部分

这些问题是否会在短期内大量进入法院并形成稳定判例

现实中，大量版权争议并不会真正诉至法院。更常见的落点是：

并购尽调
机构融资审查
企业客户采购审计
内部合规排查
离职后的权利争议

可以立即执行的四项动作

这部分不需要律师介入，工程团队就能开始做。

1. 对 AI 辅助代码库做许可证扫描

常见工具包括：

FOSSA：覆盖全面，企业中较常见
Snyk Open Source：适合研发流程集成，可接 GitHub
Black Duck：并购尽调场景中很常见

这些工具通常会：

扫描代码库
标记与已知开源项目相匹配的代码
给出对应许可证类型
提示潜在合规义务

如果已经在交付商业软件，却从未做过这一步，实际是在凭假设运营。

2. 系统保存人类创作贡献的证据

证明“有意义的人类作者身份”的材料，很多本来就在正常研发流程里，只是经常没有被有意识保留。

建议重点保留：

Commit message：记录改了什么、为什么改，而不是只写功能名
Prompt log / 会话记录：保留做出重大结构决策时的提示词和多轮交互
设计文档 / ADR：尤其是早于代码生成的那些文档
评审记录：显示哪些方案被拒绝、哪些方案被重定向

例如，下面两种提交信息的证据价值差异很大：

Add rate limiting module

Restructured Claude-generated module architecture, rejected initial state management approach, and rewrote error handling from scratch

前者只能说明提交了代码。后者能说明人类对架构、取舍和具体实现做了创作性判断。

3. 在做侧项目前，先读劳动合同中的 IP 条款

重点搜索这些词：

intellectual property
IP assignment
work product

阅读时要特别区分不同表述的宽窄：

条款措辞	风险范围
`work product created during employment hours`	相对较窄
`work product created using company resources`	更宽
`relating to the company's business`	有业务关联限制
`any software development`	非常宽
`company-licensed tools`	对 AI 编程工具最敏感

如果条款过宽，而又确实准备独立开发，现实中的选择通常只有三个：

在开始前争取书面 carve-out
彻底改用个人设备、个人账号、个人付费工具
接受潜在争议存在，并自行承担后果

4. 商业发布前，核对所用服务计划的法律条款

如果使用 Anthropic 服务，需要核对 anthropic.com/legal 上不同计划的条款，重点看输出归属和知识产权赔偿范围。

目前差异主要在这里：

消费者条款（免费与 Pro）：输出通常分配给用户，但知识产权 indemnification 范围较窄
商业条款（API 与企业版）：输出分配给用户，并会针对授权使用服务及其输出引发的版权侵权主张提供更完整的抗辩与赔偿安排

对于商业产品，若仍使用免费或 Pro 计划完成关键代码生成，需要意识到赔偿保护存在缺口。

还要注意一点：即便是商业条款中的 indemnification，也通常不能替代代码库自身的开源许可证治理。如果问题来自 GPL 污染，下游合规责任仍然主要在交付方自己。

工程团队真正需要建立的不是“信心”，而是证据链

有一个值得认真对待的现实：连构建 AI 编程工具本身的公司，都未必能在所有场景下干净利落地证明其 AI 辅助代码的版权状态。

这说明问题不在于“AI 写代码是否合法”，而在于当交易、争议、审计真的到来时，谁手里有足够清晰的证据链。

同样发布一个产品，两种团队的法律位置并不一样：

一种是直接接收数千行 AI 输出，未经实质审查就合并
一种是持续记录设计决策、保留重构痕迹、隔离雇佣与个人工作流、定期做许可证扫描

最终差异不在工程产物表面，而在可证明性。

参考资料

关于

关注我获取更多资讯

📢 公众号

💬 个人号