AI 生成代码的法律困局：责任、所有权与风险

责任流向按下 Tab 键的人

想象一下，你的 AI 助手刚刚生成了 200 行代码。从法律上讲，你可能连其中一行都不拥有；但同样从法律上讲，它上线后产生的每一个 bug，依然都要由你负责。这两句话之间存在一道鸿沟，而它将决定你明天合并代码时意味着什么。

这正是整个话题所处的鸿沟。生成代码的工具无法被起诉。模型无法被追责。供应商的合同早已用大多数开发者从未读过的措辞明确规定：责任会向下转移，最终落到按下 Tab 键的人身上。

真正值得关注的并不是这道鸿沟的存在，而是工程领域几乎没有人以它确实存在的方式来对待它。过去两年里，我们一直在庆祝生产力的提升，却只花了少得多的时间去思考：当开发速度遭遇版权索赔、合规审计或生产事故时，该怎么办。让我们逐一拆解：法院实际上作出了哪些裁决，你使用的工具在合同里到底写了什么，法律风险的悬崖在哪里，以及一个理性的工程团队该如何处理这一切——既不全面禁用 AI，也不假装这个问题不存在。

无人签署的责任交接

软件所有权曾经是一个已有定论的问题。你编写代码，雇主付钱让你编写代码，你的雇佣合同将版权转让给雇主，公司再按照自己偏好的许可证发布代码。其中只有三方——你、你的雇主和用户——彼此之间的界线十分清晰。如果出了问题，用户会向公司投诉，公司会查看提交历史，然后某个人会在一对一沟通中经历一场安静的谈话。

AI 助手将第四方塞进了这个关系中，而针对这一方的合同与其他任何一方都不同。模型没有签署你的雇佣协议。供应商并不参与你的发布流程。其最终用户许可协议并不像雇佣合同，而更像一份免责声明。你得到建议，保留建议，同时也保留了随建议而来的一切：bug、许可证义务、安全漏洞，以及未来监管机构决定审查这条建议如何进入代码库时产生的所有责任。

这种交接是悄无声息的。你的 IDE 中没有一个复选框写着“我接受对此次补全结果承担法律责任”。你只是按下了 Tab 键。这个界面被设计得像自动补全，而大多数开发者也会把自己对自动补全的心智模型延伸到它身上：编辑器只是帮助我更快地输入，代码仍然属于我，我对代码库的所有权没有发生变化。取决于你问的是什么问题，这种心智模型既几乎正确，又几乎完全错误。

法院实际上作出了哪些裁决

目前，美国法律图景的核心有两点，而开发者第一次听到这两点时通常都会感到意外。

第一点：在美国，获得版权保护需要有人类作者。这并不是一条新规则。早在 2018 年，正是同一条规则认定猴子无法对一张自拍照主张版权；但在 Thaler v. Perlmutter 一案中，它又经历了一次新的压力测试。该案涉及一张由 AI 系统在没有实质性人类输入的情况下生成的图像。2025 年 3 月，哥伦比亚特区巡回上诉法院维持了下级法院的裁决：1976 年《版权法》“要求所有符合条件的作品首先必须由人类创作”。没有人类作者，就没有版权。输出内容将进入公有领域。

第二点才是开发者真正身处的现实：美国版权局在 2024 年和 2025 年初一直试图为确实有人类参与的 AI 辅助作品划定界线。2025 年 1 月，版权局发布指导意见，指出只有当人类贡献了“足够的表达性元素”时，AI 输出才有资格获得版权保护。仅仅提供提示词是不够的，即使提示过程复杂且经过多轮迭代也不够。版权局报告引用的一则意见使用了一个比喻，给开发者带来的冲击远超预期：反复输入提示词就像转动轮盘。人类作出了选择，却没有以足够具体的方式控制输出中的表达性元素，因此不能被视为作者。

这个比喻比围绕它的具体措辞更重要。从版权角度来看，“按 Tab 接受”就是转动轮盘。“按 Tab 接受，然后重写四行代码、重构函数、添加一个护栏子句，并将其集成到你已经设计好的类中”，则属于另一种情况。正是在这里，人类贡献开始成为版权局所寻找的那种表达性控制。

实际后果是：如果从 AI 工具中生成的代码几乎未经修改，那么它可能不像你们高级工程师上周编写的代码那样，明确属于你的公司。它并非赃物，但也无法以通常能让雇主获得执法手段的方式取得版权。有人复制它时，公司无法提起诉讼，也无法将其作为一项可依法捍卫的资产来主张。公司可以发布、交付和修改它，但围绕它的法律护城河比公司认为的要浅。

一旦跨越国界，情况就会发生变化。英国自 20 世纪 80 年代末以来，就在 1988 年《版权、外观设计和专利法》第 9(3) 条中明确规定了“计算机生成作品”，并将作者身份赋予“为创作该作品作出必要安排的人”。印度采用了类似的做法。欧盟则正通过《人工智能法案》进行一次更具雄心的重新界定，我们稍后会再谈到它。重点在于：目前并不存在一个统一的全球答案。同一个团队在伦敦办公室使用同一个模型、在同一周编写的同一段代码，可能会比在旧金山编写时拥有更清晰的所有权归属。

你的工具合同实际上写了什么

以下这句话出自 GitHub 的 Copilot 产品特定条款，承担了其中绝大部分法律作用，却从未有人在 AI 采用会议上引用它：

“You retain all responsibility for your Code, including Suggestions you include in your Code or reference to develop your Code.”

这句话同时做了两件事。它交给了你一样东西：GitHub 表示不会对建议主张所有权，因此这些建议不会成为与你的代码库相竞争的权利主张。它也把另一样东西交给了你：伴随这些建议而来的一切法律风险。训练数据带来的开源许可证义务。其他开发者因其代码与建议相似而提出的版权主张。建议本身存在的缺陷。供应商的条款明确规定，你有责任判断使用某项输出是否需要取得第三方许可证，并遵守任何此类许可证。

如果你像开发者阅读 README 文件那样阅读 GitHub 的客户协议，只快速浏览安装说明，就会错过这句话。如果你像律师那样阅读它，这句话就是整份文件的核心。

这种合同结构并非 Copilot 独有。几乎所有 AI 编程助手的条款中都存在相同模式：供应商放弃对输出的所有权主张，客户承担对输出的责任。之所以都会采用这种模式，是因为只有这种结构才能让供应商继续运营。设想另一种情况：供应商保证每一条建议都不承担任何许可证义务、不包含 bug，也不会受到版权质疑。他们不可能对一个以整个 GitHub 公开语料库为训练数据的模型作出这种承诺。因此，合同将风险推给唯一可能对其进行评估的一方：合并代码的人。

模型无法阅读你的代码库所适用的许可证条款。供应商不知道你的行业受哪个监管机构管辖。IDE 不知道你正在开发的是个人兴趣网站，还是支付处理系统。责任唯一能够锚定的位置，就是合并按钮所在之处。

入职培训中无人提及的赔偿保障缺口

接下来，合同开始变得令人不安，而大多数工程组织架构在这里都存在盲区。

如果你使用的是 Business 或 Enterprise 计划，GitHub 确实会针对建议提供知识产权赔偿保障。如果 Copilot 复现了他人的代码片段，导致你因侵犯版权而被起诉，Microsoft 将依据其客户版权承诺介入，为你抗辩并支付损害赔偿金。整个行业的情况也大致相同：大多数主流 AI 编程工具都会在企业级套餐中提供某种形式的赔偿保障。

如果你使用的是 Individual 计划，这些保障一概不适用。你得到的是同一个模型、同样的建议和同样的风险面，却没有任何法律保障。如果法院最终裁定 Copilot 向你建议的某段代码实质性复制了他人采用 GPL 许可证的代码，那么真正面临麻烦的人将是你本人。

这件事之所以不仅仅与律师办公室有关，是因为大量专业软件仍由这样的团队交付：工程师使用个人 Copilot 订阅，原因可能是公司尚未完成标准化，也可能是某人在公司采用企业版套餐的六个月前就已经注册，或者只是因为他们更喜欢个人账号的设置。这些工程师编写的代码会进入公司的代码库，而公司以为自己因为付费购买了 Enterprise 就享有赔偿保障，但这项保障实际上并不涵盖通过个人订阅生成的建议。

工程负责人几乎从不审计这一点。采购团队以为 Enterprise 合同涵盖一切。开发者不知道合同会根据生成建议所使用的订阅类型划定界限。CISO 通常只有在诉讼找上门时才会发现这个问题。

一套清晰的问责体系要求每个 IDE、每台开发者机器和每个共享环境都使用提供赔偿保障的套餐。“我们购买了 Enterprise”并不等同于“所有进入我们代码仓库的建议都来自 Enterprise”。

65 词素过滤器及其无法捕获的内容

如果你阅读 GitHub 的安全文档，会发现一项名为重复代码检测过滤器的功能。该过滤器会将建议与 GitHub 上的公开代码进行比对；如果某条建议包含大约 65 个或更多词素的代码片段（约 150 个字符，相当于一到两段密集代码的长度），并且与公开代码足够相似，这条建议就会被阻止。管理员可以在企业级别启用该过滤器，而且大多数合理的采用指南都会建议你保持启用。

当团队讨论 Copilot 的许可证风险时，这个过滤器是被引用最多的缓解措施。它也极好地体现了“某项功能确实存在”与“这项功能解决了问题”之间的差距。

65 个词素的阈值并非随意设定。它是召回率与实用性之间的权衡。如果过滤器阻止所有与公开代码匹配的三词元序列，那么它几乎会阻止 Copilot 的每一条建议，因为三词元序列几乎出现在所有开源项目中。因此，阈值被设在远高于这个水平的位置，处于这样一个区间：匹配更可能源于有意的相似，而非偶然的雷同。这是合理的设计。代价是，任何低于该阈值的内容都会未经筛选地通过。

一个包含 30 个词素、与某个 GPL 许可代码仓库中的片段完全一致的函数体，可能直接进入你的代码库，而过滤器根本不会发现它。一个包含 50 个词素的惯用写法、常见算法实现、解析器片段或序列化辅助函数，可能与数十个代码仓库中的内容完全相同，却始终没有越过那条界线。该过滤器并未声称能够捕获所有内容。它声称能够捕获长篇幅的近似重复代码，因为这些内容最有可能构成版权主张的依据。短篇幅内容则处在灰色地带，连法律本身都尚未确定“实质性相似”究竟意味着什么。

这正是你需要做出可辩护判断，而非追求完美判断的地方。过滤器确实有帮助，但将其视为完整解决方案则无济于事。应当把它看作收件箱中的垃圾邮件过滤器：有用，往往能在不引人注意的情况下做出正确判断，但它无法替代“不打开陌生人发送的附件”这一基本原则。

监管机构不关心代码是谁写的

美国围绕版权的讨论聚焦于所有权。欧洲的监管讨论则聚焦于结果责任，其框架确实有所不同。

三项欧盟立法正在汇聚成一些从业者所说的“合规三位一体”：AI Act、Cyber Resilience Act（CRA）和 Product Liability Directive（PLD）。每项立法都从不同角度处理 AI 问题。AI Act 按照风险类别监管 AI 系统；CRA 对联网产品施加网络安全义务；PLD 则规定包括软件在内的缺陷产品责任。它们都有一个共同假设：监管机构不关心你的代码是由人类、AI 工具、承包商，还是一小队经过训练的雪貂编写的。他们关心的是最终进入市场的产品。

2026 年 8 月 2 日是大多数开发者会听说的关键日期。届时，AI Act 的许多实质性义务将开始生效，包括针对 AI 生成内容的透明度要求和正式的执法权力。单纯使用开发辅助 AI，一般不会使系统本身被归入高风险类别，但将 AI 用于员工评估或关键组件生成等用途则完全可能。分类取决于系统在现实世界中的用途，而非使用了什么工具来协助编写它。

更艰难的转变在于它所隐含的文化变化。在 AI 助手出现之前，“代码是否经过谨慎编写”与“产品是否安全”这两个问题大致指向同一件事：编写代码的人同时也是对代码负责的人。引入 AI 助手后，这两个问题可能逐渐分离。即使每个审查 diff 的人都发誓自己认真读过代码，产品仍然可能不安全。监管机构不会接受“这是 AI 建议的”作为解释，就像他们不会接受“这是承包商写的”一样。产品是你交付的；责任也由你承担。

一旦接受这一点，这套框架其实非常清晰。令人不安之处来自一种尚未完全成形的预期：人们以为 AI 工具附带某种分布式责任，因为模型是由供应商训练的，所以供应商也应该分担责任。事实并非如此。合同中明确规定并非如此。监管机构也礼貌地拒绝创造这种共同责任。

没人提醒你的文化问题

在法律文本之外，还有一种更隐性的模式正在悄悄削弱工程团队内部的问责意识，而且它与合同毫无关系。

研究 AI 辅助开发的学者已经开始记录一种大多数资深工程师早已感受到的现象：AI 助手生成的代码往往没有得到与人类手写代码同等谨慎的审查。审查者花在这类代码上的时间更少，指出的问题也更少。他们更容易直接放行一个能够编译且看起来合理的函数。部分原因是疲劳：如今需要审查的代码比以往任何时候都多，因为过去限制产出的打字瓶颈已经消失。部分原因是隐性的信任：模型读过的代码比任何在世的审查者都多，因此它的输出会在无意识中获得一点权威加成。还有一部分原因仅仅来自界面设计：接受建议是默认操作，拒绝建议则需要额外操作。

问题不在于这些反应中的任何一种单独看来不合理，而在于它们叠加后会使问责减少，而不是增加。diff 的长度翻了一倍，审查的仔细程度却减半；通常会对防御性空值检查提出尖锐问题的人，此时正忙着滚动查看接下来的三条建议。每行已合并代码所获得的人类注意力下降了，发现缺陷、许可证问题或模型没有意识到自己正在犯下的细微授权错误的概率也随之降低。

这并不是反对 AI 工具的论点。它只是大多数团队尚未绘制在仪表盘上的那条缺失指标：如果我们产出的代码更多了，我们是否也在按比例进行更加仔细的审查，还是因为代码量迫使我们放宽了审查？没人会公开提出这个问题，因为那会拖慢进度。而上面提到的监管框架，也无法帮你逃避这个问题的答案。

一套有效的问责模型是什么样的

你无法通过一条 Slack 消息解决这些问题。仅靠一份政策文档也无法解决，除非这项政策确实改变了代码进入代码仓库的方式。真正妥善处理这些问题的团队会做四件平淡无奇的事情，其中没有一件称得上巧妙。

他们让套餐归属变得简单乏味。每位开发者、每个共享环境以及每个使用 AI 助手的 CI runner，都采用提供赔偿保障的套餐。公司工作不存在使用个人订阅的后门。这是一个采购层面平淡无奇的决定，却能通过一个动作弥合大部分缺口。

他们默认启用重复代码过滤，并确保其状态可验证。过滤器在管理控制台中启用，并像 SSO 强制执行一样被纳入定期安全审查。它不是某个人可能在某个周二随手切换过的设置，而是一项经过审计的控制措施。

他们在代码审查中像对待第三方依赖一样对待 AI 生成的代码。对于模型生成的新代码，资深工程师会在思维上采用与对待 2014 年从 Stack Overflow 答案中复制粘贴的代码相同的方式。你会问：我是否理解这段代码的作用？我是否知道它可能来自什么样的许可证？如果没有模型可以让我把责任推给它，我是否愿意在这段代码上签下自己的名字？这个问题将整套伦理与法律机制压缩成了一句话，让审查者能够真正内化。

他们会明确指定负责人。每个 PR 都有一名对其中代码负责的人类。不是模型，不是供应商，也不是“团队”。而是一个有名有姓的人——如果代码出了问题，他会接起电话。如果你的工具让人很难记住由谁负责 AI 代码占比较高的 PR，那么这就是一个值得解决的流程问题，因为上述其他所有框架都只有在责任链末端落实到具体姓名时才能发挥作用。

注意：这些都不需要法务团队或合规官参与。前三个步骤只是管理控制台中的设置，以及评审检查清单里的一句话。第四个步骤是一种文化规范，而优秀的团队对人工编写的代码早已有这种规范。AI 带来的唯一新情况是：由于代码量增加了，你不能再跳过其中任何一步。

贯穿全文的那句话

如果你只记住本文的一件事，那就记住这句话：每一条 AI 建议，都相当于来自一个匿名第三方的贡献；它读过互联网上的每一个开源项目，你无法对它进行访谈，而你的合同已经明确将它排除在责任链之外。

这并不是停止使用 AI 助手的理由，甚至也不是放慢使用速度的理由。这只是这种关系的真实形态。软件工程中的摩擦之所以不断回到这一点，是因为这种形态不会自行消解。法院正在逐渐形成共识，供应商早已围绕它制定合同，而监管机构也即将开始执行相关规定。

如果这也能算好消息的话，那就是：答案从来都不在模型里。答案存在于工作流中那个本应最枯燥、也最严谨的环节——由人类查看 diff，并决定是否合并。这个环节从未像现在这样重要。要处理整个代码所有权问题，团队成本最低的做法，就是确保这个环节仍然存在，并且保持与 AI 每分钟提供两次建议之前同样的审慎程度。

合并提交是你写下的。它就归你负责。

附言：感谢你花时间阅读这篇文章！文中表达的观点和看法均为我个人所有。英语并非我的母语，因此我会使用 AI 帮助修正语法，让文章表达得更清晰、更易读。如果仍有任何地方读起来略显生硬，感谢你的理解！

最初发布于 nazarboyko.com。

部分评论可能仅对已登录的访客可见。请登录以查看所有评论。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。