如果你本周交付了代码，其中部分很可能由 AI 完成。代码的法定所有权归属问题，比大多数开发者想象的更加模糊。答案取决于三个与技术本身无关的因素：人类是否做出了足够的创作性决策来确立著作权、雇佣合同是否已将成果分配给雇主、以及模型是否从 GPL 许可的训练数据中悄悄污染了你的代码库。
法律基线：只有人类创作才能获得著作权
美国版权局在 2025 年 1 月确认了这一原则，最高法院在 2026 年 3 月驳回 Thaler 案上诉时维持了这一立场。主要由 AI 生成且缺乏有意义人类著作权的作品不具备著作权保护资格，这一规则现已在最高司法层面得到确认。
这意味着什么？如果 Claude Code 或 Cursor 生成的代码你未经有意义的修改即予以采纳，可能任何人都不享有著作权。如果竞争对手复制了该代码，你可能无法寻求法律救济，因为该代码在事实上已进入公有领域。
决定代码是否受保护的关键短语是「有意义的人类著作权」。版权局刻意拒绝用百分比或修改次数来量化这一标准，因为法院寻找的是人类做出真正创造性决策的证据：选择架构、决定拒绝什么、重构输出以适应特定设计。仅向模型指定一个目标是不够的，如何指挥作品的构建方式才是关键。
雇佣合同与工作成果归属
在思考代码是否具有著作权之前，存在一个更直接的问题：即便具有著作权，它实际上属于你吗？
你的雇佣合同几乎必然规定你在工作中构建的任何东西都属于雇主。版权法中这一原则被称为「职务作品 doctrine」。根据该原则，雇员在雇佣范围内创建的任何代码均归雇主所有，雇主被视为法定作者，无论代码是手写、由 Claude Code 生成还是两者的组合。在工作时间、使用工作项目、使用工作设备使用 AI 编码工具，不会改变成果的归属方。
大多数雇佣合同走得比该原则的默认规定更远。寻找合同中名为「知识产权」「IP 转让」或「工作成果」的条款。如果条款包含以下任何表述，几乎肯定涵盖你 AI 辅助创建的代码：使用公司设备或资源创建的任何工作成果、雇佣期间创建的任何发明或开发、使用公司许可工具创建的任何软件。第三个表述尤其值得关注：如果你的雇主为团队许可了 Claude Code、Cursor 或 Copilot，而你使用这些相同工具构建副业项目，即使在你自己时间构建的，广泛 IP 转让条款也可能赋予雇主对该项目的权利。
开源许可证污染风险
即使你拥有 AI 生成的代码，你可能已经用你看不见的开源许可证污染了它。AI 编码工具在大量公共代码上训练，包括在 GPL、LGPL 和其他 copyleft 许可证下许可的代码。Copyleft 许可证带有随代码传播的特定义务：如果你分发的软件是 GPL 许可代码的衍生作品，你必须在同一许可证下发布你自己的源代码。即使你不知道自己纳入的代码是 GPL 许可的，「我不知道」也不是 copyleft 违规的抗辩理由。
当 AI 工具生成的代码与其训练数据中的 GPL 许可代码高度相似，而你将该代码商业发布而未发布源码时，你可能已创建了 copyleft 违规，即使你从未接触过原始仓库。2026 年初的 chardet 争议使这一点具体化。一位开发者使用 Claude 重写了 chardet（一个 Python 字符编码库），并以 MIT 许可证重新发布，辩称 AI 重写是绕过原始 LGPL 许可证的「洁净室」实现。社区争论的法律问题是：如果 Claude 在 LGPL 许可的代码库上训练，其输出反映了从该代码学到的模式，输出能否被视为无许可证？新兴的法律共识可能是不能，假设它可以会为任何商业发布该代码的人带来重大责任。
代码血缘追踪的工程化实现路径
鉴于上述法律不确定性，工程团队需要建立系统性的代码血缘追踪机制。这不仅是为了满足合规要求，更是为了在潜在纠纷中证明人类创造性贡献。以下是工程实现的关键维度。
版本控制策略层面，提交信息的设计至关重要。「添加限流模块」无法证明人类创造性贡献，而「重构 Claude 的模块架构、拒绝初始状态管理方案、从头重写错误处理」则是有效的证据。建议团队建立提交信息规范，要求区分 AI 生成的代码片段与人类重写的部分，并在提交信息中明确标注修改意图。分支策略应支持独立的审查轨迹，使人类决策节点可追溯。
提示词与交互日志归档是第二个关键维度。Claude Code 和 Cursor 均保留交互历史，工程团队应建立机制定期导出或备份这些会话记录，特别是那些包含重大架构决策的会话。更进一步，可以建立结构化的决策日志，在代码旁边记录 prompting 策略、拒绝的方案及其理由。这些文档化的决策轨迹，在著作权争议中具有重要的举证价值。
许可证扫描集成是第三个必要措施。在持续集成流程中嵌入开源许可证扫描是工程实践的基本要求。FOSSA、Snyk Open Source 和 Black Duck 是当前业界成熟的选择，扫描工具应配置为在合并前触发阻塞策略，针对 GPL、LGPL、AGPL 等 copyleft 许可证设立明确的告警阈值。扫描结果应与代码血缘记录关联，追踪可能的许可证污染来源。
anthropic 计划层级选择是第四个实践要点。对于商业发布场景，免费版和 Pro 版的 IP indemnification 覆盖范围较窄，API 和企业版提供更全面的版权侵权诉讼辩护。如果使用免费或 Pro 计划为商业产品提供 AI 辅助代码，indemnification 差距是真实存在的。生产级部署应选择适当的协议层级。
实践参数与监控清单
工程团队在实施代码血缘追踪时，可参考以下具体参数：提交信息中人类决策描述占比建议不低于 30%；提示词日志保留周期不少于项目活跃期加两年；许可证扫描应在每次合并请求时执行，阻断包含高风险 copyleft 许可证的代码进入主分支；anthropic 商业计划的 IP indemnification 条款应在项目启动阶段与法务确认。
代码血缘追踪不是单一工具能解决的问题，它需要版本控制实践、文档规范、扫描流程和合同管理的协同。在 AI 辅助开发日益普及的当下，工程团队越早建立这些追踪机制，在面对著作权归属争议时就越处于更有利的位置。记录创造性贡献的开发者与不加审查直接合并三千行 Claude 输出的开发者，即使交付了相同的产品，在法律地位上存在实质性差异。
参考资料
- US Copyright Office: Copyright and Artificial Intelligence (Part 2: Copyrightability)
- Doe v. GitHub, Inc. — Ninth Circuit appeal
- Anthropic: Usage Policy and Terms of Service