AI生成代码里的开源依赖怎么核查？从依赖树到许可证与NOTICE检查指南

AI生成代码进入仓库后，依赖可能来自项目清单、锁文件，也可能通过其他包间接引入。发布前应同时核查依赖和被复制、改写的代码片段。扫描器适合发现线索，但不能单独判断某个项目是否满足发布义务。

第一步：固定待检查的版本并列出依赖

先记录准备提交或发布的代码版本、所用包管理器，以及安装依赖的方式。优先使用项目实际采用的锁文件，例如JavaScript项目中的package-lock.json、pnpm-lock.yaml或yarn.lock；Python项目则检查项目使用的锁定文件或依赖清单。不要只依据AI生成的说明文字或未提交的本地环境作判断。

清单要区分直接依赖和传递依赖：前者由项目明确声明，后者是其他依赖继续引入的包。使用包管理器的依赖树或清单导出功能，并在与发布流程一致的环境中执行。例如，npm项目可查看完整依赖树：npm ls --all --json。保存输出，并与清单文件和锁文件对应核对。若锁文件缺失、与清单不一致，先查明实际安装和构建使用的版本，再进行许可证复核。

第二步：核对包名、版本、来源和许可证

对每个包记录准确的包名与解析版本，避免把同名包、不同发行源或不同版本当作同一项。检查包管理器记录的注册表、仓库地址或其他来源信息；若项目使用私有镜像、Git地址或本地包，也要记下具体来源和对应提交或归档。

许可证字段可作为初筛信息，但不能代替原始材料。将包元数据中的许可证标识与该版本随附的LICENSE、COPYING等文件以及上游仓库中的许可证文本核对。标识缺失、文本找不到或两者冲突时，标记为待确认，不要根据包名或常见用法猜测。还应留意许可证文件是否随发布归档提供，以及项目代码中是否包含单独复制的第三方片段。

第三步：确认声明和NOTICE文件如何处理

逐项查看适用的许可证及相关文件，确认发布时是否需要保留版权声明、附带许可证文本或NOTICE内容。并非每个依赖都要求同一种处理方式；应根据具体许可证文本、项目分发方式和修改情况判断。需要保留的声明应与对应组件和版本关联，避免只把来源不明的文字拼入一个文件。

留存本次检查的依赖清单、锁文件、扫描报告、许可证文本副本，以及包版本和来源信息。对Git来源可记录提交标识；对归档包可保存文件校验值。这样在更新依赖或复查发布包时，能够说明当时核对的是哪个版本和材料。

第四步：把复查放进持续集成

在持续集成中，对锁文件或依赖清单变更触发清点和许可证扫描，并将新增、升级或来源变化的包列为人工复核项。发布前再检查实际打包内容，确认声明和NOTICE文件与所包含的依赖相符。扫描结果可以指出许可证标识缺失、风险提示或清单变化，但其数据库覆盖范围和识别能力有限，不能作为法律结论。

实际审查还要结合项目用途、代码修改方式和发布场景。遇到许可证文本与元数据不一致、来源无法确认或义务难以判断的情况，先暂停将该依赖纳入发布，并向项目维护者核实；涉及重要发布决定时，可寻求专业法律意见。将这套流程重复用于每次依赖变更，比只在AI最初生成代码时检查一次更可靠。