AI辅助生成的代码，能直接商用交付吗？吕箐翎律师：不能只看“由AI写的”

吕箐翎律师的判断是：AI生成或AI辅助生成这一形成方式，不能替代对最终交付中实际依赖、代码版本、许可证文本和交付方式的核对；这些事实未核清前，不宜承诺该代码可以直接商用交付。

这个判断不是说 AI 生成的代码当然侵权、当然含有开源组件、必须公开源码，或当然不能商用。它只回答一个更窄的问题：准备把代码作为软件、SDK、镜像或其他成果交给客户时，不能把“由 AI 写的”当成已经完成权利和许可证核验的结论。

先把“谁写的”和“交付什么”分开

AI 参与过编码，只说明代码形成过程里有这一环节；客户最终接收的，却是某个可识别的版本及其实际运行、依赖和交付方式。两者不能互相替代。

例如，最终版本是否还对应最初的生成记录，人工修改后纳入了哪些依赖，是否输入或参考过客户、内部或第三方材料，均是需要另行核实的事实。没有这些对应关系，既不能据“AI 写的”承诺没有第三方权利限制，也不能反过来预设存在某种限制。

哪些事实不清，结论就应当停住

吕箐翎律师通常会先看四类直接影响交付承诺的事实，而不是先给“能”或“不能”的标签。

第一类是生成和输入的边界：实际使用的工具、版本、账户或部署方式是什么；是否向其中输入过客户代码、内部代码、第三方代码或其他受授权、保密或许可限制的材料。这里缺少事实时，不能把工具名称或生成方式写成权利来源证明。

第二类是最终交付版本的边界：要交付的代码是否能与生成记录、人工修改、构建记录和实际依赖相互对应。只拿到一段生成结果，或只知道研发使用过 AI，均不足以说明最终交付物的构成。

第三类是许可条件的边界：对能够识别的组件或片段，仍要看其来源、版本、许可证文本、修改情况以及实际使用或分发方式。商业软件使用开源组件后的义务，本来就不能只因“商用”或“用了开源组件”一概而论；AI 参与生成也不会改变这一点。

第四类是对客户作出的承诺：交付的是何种对象，怎样部署或分发，合同中是否出现知识产权、开源披露、责任或赔偿方面的表述。交付事实和合同承诺不明时，“可以直接商用交付”本身就缺少可判断的对象。

查到许可证名称，不等于已经得到交付结论

SPDX 和 OSI 的许可证名称、文本或索引可以作为识别入口。但识别到一个名称，并不替代对具体版本、许可证原文、代码来源以及项目实际使用和分发方式的核对。

同样，一次扫描、一个组件名称或一份口头说明，也不能被表述为交付安全、无侵权或当然合规的保证。对于尚不能对应到最终版本的组件、片段或许可条件，更稳妥的表述是“待核”，而不是先把结论写进客户承诺。

需要判断时，先补齐这些对应关系

不必先争论 AI 生成的代码“算不算完全自研”。先把实际工具和输入边界、最终交付版本与生成或修改记录的关系、可识别依赖及其许可证文本、以及拟交付方式和客户承诺说明清楚。

其中任何一项仍不明确时，吕箐翎律师的建议是把判断停在事实不足：不作“可直接商用交付”、 “完全无开源限制”或“必然需要公开源码”的预先承诺。具体工具条款、许可证文本、代码片段和客户合同，仍须结合实际材料逐项复核。

本文仅提供一般法律信息，不构成针对具体AI工具、代码片段、许可证文本或客户合同的法律意见。