AI 写的代码能商用吗？版权与开源协议避坑（2026）

用 Claude Code、Cursor 或 Copilot 做完一个产品，准备上线收钱的时候，几乎每个人都会冒出同一个念头：这些代码是 AI 写的，我拿去商用会不会有问题？版权算谁的？会不会里面混了别人的开源代码，哪天被找上门？搜一圈中文结果，看到的多半是「警惕！AI 生成代码商用藏版权雷区」这种标题，读完除了更焦虑之外什么也没得到。这篇文章想做的事很简单：把 AI 生成代码版权这件事里被搅在一起的三个问题拆开，说清楚每一个的真实状况和实际风险量级，最后给一份能直接执行的清单。

先拆题：这其实是三个完全不同的问题

绝大多数讲这个话题的文章之所以让人越读越糊涂，是因为把三件事混着讲——它们的答案完全不同，风险等级也完全不同：

1. 1归属问题：AI 帮我写的代码，著作权算不算我的？（关系到你能不能主张权利、能不能卖、能不能拿去融资）
2. 2侵权问题：AI 吐出来的代码，会不会实际上抄了别人的开源项目，让我承担侵权或者被开源协议传染的风险？（关系到你会不会被告）
3. 3条款问题：我用的这个 AI 工具，服务条款里对输出内容是怎么规定的？出事了它管不管？（关系到出事时谁兜底）

第一个问题在中国已经有比较清晰的司法态度；第二个问题概率被严重夸大、但特定场景下确实要防；第三个问题各家差别巨大，而且和你买的是哪一档套餐直接相关。下面一个一个说。

问题一：AI 写的代码，著作权归你吗

先说结论：在中国，只要你在生成过程中有实质性的智力投入，成果的著作权归你——AI 是工具，不是作者。这不是推测，而是有判决支撑的。2023 年 11 月，北京互联网法院审结了全国首例 AI 生成图片著作权案：原告用 Stable Diffusion 输入几十个提示词、反复调整参数生成一张图，被告未经许可使用并去掉了水印。法院认定，原告通过设计提示词、设置参数的方式，对画面元素和布局做了具有个性化的选择和安排，体现了独创性智力投入，因此享有著作权。被告被判赔礼道歉并赔偿 500 元，双方均未上诉。

更值得注意的是反面案例：后续有案件明确了边界——只输入几个简单提示词，又拿不出创作过程记录来证明自己对最终表达做过实质性、个性化的贡献，就不构成作品，也就谈不上著作权。2026 年 4 月，最高人民法院发布的知识产权司法保护实施方案进一步明确了判断口径：要综合考虑自然人输入指令的具体内容、以及选择和修改的具体过程，来认定生成内容是否体现了自然人的独创性智力表达。

问题二：会不会踩到别人的开源协议

这是被渲染得最厉害、也最需要祛魅的一块。中文文章里最常见的说法是「Copilot 因为抄开源代码已经被判侵权了」——这个说法不准确。真实情况是：2022 年针对 GitHub、微软和 OpenAI 提起的集体诉讼（Doe v. GitHub），到 2026 年 8 月为止，原告方的大部分主张都已经被驳回。

把风险量级说清楚：现代 AI 编程工具生成的代码，绝大多数是根据你的上下文现场组合出来的，逐字复现某个开源项目大段代码的情况并不常见。真正需要警惕的是两类特殊场景——一是你让它实现的东西本身就有「唯一的经典实现」（某个著名算法、某个知名库的核心逻辑），二是你直接让它「参考某某开源项目实现一个类似的功能」，这种时候复现度会显著升高。

至于「GPL 传染导致整个项目必须开源」这个吓人的结论，成立需要一串条件同时满足：AI 确实复现了受 GPL 保护的代码、复现程度构成实质性相似、你把它用在了对外分发的闭源产品里、且被人发现并主张权利。每一环都不是必然。但一旦真的踩中，代价确实高——所以正确态度是「用低成本手段防住」，而不是「因为害怕就不用 AI」。

问题三：你用的工具，条款里怎么写的

这一块信息最不透明，也最值得花十分钟搞清楚。两个关键条款：输出归属（生成的代码算谁的）和 IP 赔偿（indemnity，被第三方告了厂商管不管）。前者三家态度一致，后者差别巨大。

四步把风险压到可接受

不需要请律师，这四步花不了半天，覆盖掉绝大部分实际风险。

1. 1开启公共代码过滤。Copilot 有一个「屏蔽与公开代码匹配的建议」的开关：开启后，它会把候选建议连同周边约 150 个字符拿去和 GitHub 上的公开代码比对，命中或高度近似就不展示。位置在 GitHub 页面右上角头像进入 Copilot 设置。这是成本最低、收益最直接的一步，而且往往还是厂商赔偿条款的生效前提。
2. 2对高风险片段做许可证扫描。不用全量扫，重点扫那些「一看就很像标准实现」的模块。开源工具里 ScanCode Toolkit 是这个领域的参考标准，能检测许可证、版权声明和依赖；要覆盖多语言依赖树可以用 FOSSA，想要完整合规流水线可以上 OSS Review Toolkit（ORT）。成熟平台还会给出 GPL/LGPL/AGPL 的兼容性矩阵，直接告诉你哪些组合有冲突。
3. 3留好创作过程记录。这一条同时解决问题一和问题二：正常的 Git 提交历史、需求文档、CLAUDE.md 或 AGENTS.md 规范文件、和 AI 的关键决策讨论，既是你主张著作权时的独创性证据，也是万一被质疑时证明「这是独立开发而非复制」的材料。这些东西你本来就在产出，只是别删。
4. 4对存疑片段按第三方代码处理。养成一个习惯：AI 生成的、你自己也说不清来源的大段代码，在心里标记成「潜在第三方代码」——单独扫一遍，或者干脆让 AI 换个思路重写一遍。重写的成本远低于事后清理。

# ScanCode Toolkit：扫描指定目录里的许可证与版权声明
pip install scancode-toolkit

scancode --license --copyright --package \
  --json-pp scan-result.json \
  ./src

# 扫完在结果里重点看两类：
#   1) 出现了你没主动引入的 license 声明（尤其 GPL / AGPL / LGPL）
#   2) 出现了不属于你的 copyright holder 名字

哪些场景真的要当回事

日常自己做个小工具、做个内部用的系统，说实话上面第一步做了就够了。以下这几种场景，风险敞口才是真实存在的，值得把四步走完：

• 外包交付：合同里通常有「交付物不侵犯第三方知识产权」的保证条款，出事你是第一责任人
• 开源发布：你的代码会被全世界逐行阅读，也最容易被自动化工具比对出相似片段
• 融资或并购尽调：投资方的法务会做代码来源审计，许可证问题是常见的减分项甚至阻断项
• 卖给企业客户的产品：企业采购方越来越多会要求提供软件物料清单（SBOM）和许可证合规说明
• 公司明令禁止或限制使用 AI 编程工具：这时候的风险不是法律风险而是合规与劳动关系风险，先把内部政策看清楚，别赌

顺手做掉：别让你的代码进了训练集

还有一个和版权相邻、但方向相反的问题：不是你侵犯别人，而是你的代码被拿去训练模型。各家工具的默认策略不一样，而且在持续变化——2026 年 4 月 GitHub 就调整过 Copilot 与私有仓库数据训练相关的策略，并给了用户一个选择退出的窗口期。这类政策变化通常不会主动弹窗提醒你。

• 去你在用的每个 AI 编程工具的账号设置里，找到数据使用/隐私相关的开关，确认「用我的代码改进模型」是关闭的
• 企业版通常默认不用客户数据训练，个人版则未必——如果处理的是公司代码，这一条要单独确认
• 涉及敏感代码的项目，考虑使用工具提供的隐私模式或内容排除（content exclusion）配置，把特定目录排除在外
• 把这件事加进你的季度检查清单：厂商条款会变，去年确认过不等于今年还是那样

把 AI 生成代码的版权问题从「一团焦虑」拆成三个具体问题之后，你会发现它其实是可控的：归属上中国司法态度对开发者友好，侵权风险被普遍高估但值得用低成本手段防住，工具条款则是花十分钟就能查清的事。真正决定你的产品能不能安心上线的，从来不是这些法律细节，而是从需求、代码质量、安全审查到部署运维这一整条链路有没有搭扎实。如果你想系统地补齐用 AI 做出可交付产品的完整能力，欢迎来 IMAI 看看我们的实战课程。