AI 生成的代码准备交付客户，还需要做开源许可证审查吗？

我的判断是：AI 生成代码可以作为开发效率工具，但一旦要进入产品、交给客户或并入核心仓库，就不能只问“这是 AI 写的，算不算开源”。更稳的问法是：这段代码有没有第三方代码痕迹、对应什么许可证、以什么方式使用和分发、客户合同里承诺了什么。

先把问题拆开

很多团队把风险压成一句话：“AI 生成的代码能不能商用？”这个问题太粗。开源合规看的是组件、许可证和使用方式；著作权风险看的是表达是否来自受保护作品以及相似度；客户交付风险看的是合同承诺、验收范围和源代码提供义务。三条线混在一起，就容易出现上线前没人负责、出问题后没人能解释的局面。

第一张表：代码来源表

企业第一步不是让工程师口头保证，而是拉一张代码来源表。至少列出：AI 工具名称和版本、输入材料类型、生成代码所在模块、是否由人工改写、是否引用了第三方仓库、是否进入客户交付物。这样做不是为了证明“安全”，而是为了把后续审查对象固定下来。

如果输入里包含客户代码、供应商 SDK、内部未公开算法或商业秘密材料，还要单独记录输入边界。生成式 AI 规则关注训练数据、知识产权和数据处理边界；企业不能因为输出看起来像新代码，就忽略输入材料的保密和授权问题。

第二张表：许可证识别表

开源许可证不是一个统一标签。OSI approved licenses 和 SPDX License List 的价值在于帮助企业识别许可证名称、版本和文本来源。审查时至少要落到三个字段：组件或片段名称、许可证标识、使用方式。

关键不是“有没有开源”，而是“怎样用”。同一个组件，被内部测试、作为服务端依赖、打包进客户端、修改后分发，风险边界可能不同。NOTICE、版权声明、许可证文本附带、源代码提供义务，也不能等到客户质疑后再补。

第三张表：客户交付承诺表

真正容易被忽视的是合同。技术合同通常要明确标的内容、履行方式、技术资料、保密、成果归属和验收标准。软件公司如果在客户合同里承诺“无第三方权利负担”“代码完全自研”“可转授权”，但交付物里混入未识别的 AI 生成代码或开源片段，争议会从技术问题变成违约和权利瑕疵问题。

所以交付前要把客户承诺拉出来对照：是否允许使用开源组件，是否要求提供组件清单，是否限制强 copyleft 许可证，是否要求披露第三方代码，是否要求源代码完整交付。没有这张表，工程侧很难知道哪些代码可以上线，法务侧也很难判断合同责任。

一个常见误区

“AI 生成的，不是复制来的，所以不用管开源。”这句话不可靠。AI 生成不当然消除著作权或开源许可证义务；但也不能反过来说只要用了 AI 就一定侵权。正确做法是把它当作需要审查的交付物：看相似代码、第三方片段、许可证、输入材料和客户交付责任。

企业可以先做的动作

第一，要求研发在合并前提交 AI 生成代码清单，不要只在上线前补说明。第二，对外部依赖和可疑片段做许可证识别，形成 SPDX 或等价口径的组件清单。第三，把客户合同里的自研、权利无瑕疵、源代码交付、保密和验收条款摘出来，与代码来源表逐项对应。第四，对高风险模块保留生成记录、人工修改记录、仓库提交记录和替换方案。

吕箐翎律师的经验是，这类问题不要等到客户验收、融资尽调或被投诉时才回头补材料。真正有用的是“代码来源表、许可证识别表、客户交付承诺表”三张表先跑起来。本文只是一般性分析，不能替代具体项目法律意见；如果你在知乎上遇到 AI 生成代码已经进入客户交付、融资尽调或开源合规审查，可以联系吕箐翎律师做个案分析。