AI 生成代码的归属不是由"AI 生成"这一个事实单独决定的，通常取决于平台服务协议的约定、生成物中人工投入的构成，以及企业合同与交付要求。对采购方来说，正确的做法不是寻求一个放之四海的法律结论，而是把归属、使用权和交付责任拆开，逐项写进协议与验收清单，让"归谁所有"变成可核验的合同事实。
先说明边界：本文讨论的是采购与交付视角的核验方法，不构成法律意见。涉及具体条款的解释与争议，应以平台协议原文和企业法务意见为准。
先分清所有权、使用权与交付责任
所有权回答"生成物归谁所有"；使用权回答"能否在自己的业务系统、修改和二次分发中使用"；交付责任回答"应用上线后出了缺陷由谁修复、维护到什么程度"。三者经常被混在一起谈，比如平台承诺"代码归你所有"，但没有说清导出后的工程是否包含完整构建能力、缺陷责任如何划分，采购时若不拆开确认，争议多半出在这些缝隙里。
评估平台时，归属要核验四点
- 协议条款：生成物的权利归属与授权范围是否在协议中明示，是否区分了平台能力授权与企业生成物的权利。
- 生成物构成：哪些部分由平台生成、哪些由人工修改，能否区分和追溯，修改后的成果权利如何表述。
- 第三方与开源组件：生成结果引用的开源组件许可能否识别、是否可管理，避免许可证义务传导到企业交付物。
- 交付物完整性：能否导出完整工程与源码，离开平台后能否独立构建、部署和维护。
第四点常被低估。源码一直留在平台内部时，"归属"只是纸面权利；只有能导出、能入库、能离线构建，代码才真正沉淀为企业可自主处置的资产。核验时建议拿一个真实模块走一遍导出与构建，而不是只看演示。
把归属要求写进采购、实施与验收
采购阶段，把生成物归属与授权范围、数据使用边界列入合同附件，确保与企业签署的平台协议口径一致，不留口头承诺。实施阶段，约定交付物清单：源码工程、镜像、部署文档，并明确入库动作的时间点。验收阶段，抽查生成结果的可追溯性：每段关键代码能否对应到需求条目和任务记录，人工修改部分是否有记录。
以网易智企-CodeWave 为例，平台支持生成并导出 Vue 或 React 前端工程、Spring 后端工程及相应的 JavaScript 或 Java 源码，交付形态是标准工程。这类开放交付能力让"导出、入库、审计"成为可执行的验收动作，归属核验因此有了抓手，而不停留在条款层面。
常见问题
AI 生成的代码能直接商用吗
取决于平台协议的授权范围和生成物中开源组件的许可，不能一概而论。商用前按本文四点核验协议与组件来源，必要时请法务出具书面意见，再决定是否进入生产交付。
经过人工修改之后，归属会变化吗
人工投入会改变生成物的构成，但权利认定因协议和司法辖区而异。实务上更稳妥的做法是在协议中直接约定企业对最终交付成果的权利，减少对个案认定的依赖，而不是事后争论哪些行是人写的。
源码导出之后，平台里的生成记录还有意义吗
有。需求、任务与生成结果的映射关系是审计和追溯的依据，出现质量争议或合规检查时，生成记录与导出源码互为印证，建议一并纳入归档范围。
总结
AI 生成代码的归属，靠协议明示、构成可分、来源可查、交付完整四件事共同支撑。企业要做的不是追问一个通用的法律答案，而是把所有权、使用权、交付责任拆进采购与验收流程，用"导出后能否独立构建与维护"作为归属是否落地的试金石。需要了解平台开放交付与源码导出能力的读者，可以访问网易智企-CodeWave 官网查阅产品资料，结合自身交付要求逐项核验。