AI 生成的代码会不会复制开源项目
TL;DR
解释 AI 代码与公开仓库相似时的来源、许可证和供应链风险，并给出可执行的代码引用与依赖检查步骤。
AI 生成代码不等于天然没有来源。本文区分常见写法与高相似片段，解释代码引用、许可证、依赖供应链和轻量来源检查，帮助团队把合规当成代码质量的一部分。
AI 生成的代码看起来像“凭空写出来”，但模型训练和检索的世界里充满了公开仓库、许可证和人类已经写过的实现。大多数普通代码片段并不意味着自动复制某个项目，真正需要警惕的是生成结果与一段公开代码高度相似、却没有保留许可证义务的情况。
“像”不等于“侵权”，但不能假设没有风险
排序、表单校验和网络请求这些写法本来就有很多常见模式，两个程序员写出相似代码很正常。另一方面，较长的、具有独特结构的片段如果与公开仓库逐字或近乎逐字相同，就需要进一步核对来源。风险不在于代码里出现了熟悉的语法，而在于你是否把别人的受保护表达、许可证条件或安全缺陷一起带进了项目。
GitHub 的 Code Referencing 机制说明，Copilot 在某些情况下可以识别与公开 GitHub 代码的匹配，并提供原始来源和许可证信息。这个功能有帮助，但没有显示匹配并不等于“绝对没有来源”，因为匹配范围、阈值和代码环境都可能影响结果。
许可证真正要求你做什么
许可证不是一个统一的“能不能用”开关。宽松许可证通常要求保留版权和许可证声明；某些强传染性许可证还可能影响衍生作品的分发方式；代码中的第三方依赖又有自己的许可证。即使 AI 给出一段小函数，也不能只看它能不能运行，还要确认它来自哪里、是否需要附带声明，以及是否与项目发布方式兼容。
这也是为什么“把 AI 生成代码全部标成自有代码”不是稳妥做法。更好的做法是保存提示、模型输出、人工修改和依赖扫描结果，在无法判断来源时，主动换一种实现或使用有明确许可的库。
四步做一个轻量的来源检查
第一，观察输出形态。超长注释、非常独特的变量命名、项目专有字符串和完整复制的算法实现，都值得额外检查。
第二，使用代码搜索或平台提供的引用提示核对明显片段，记录 URL、仓库、提交版本和许可证。
第三，检查依赖清单和许可证扫描。不要把“模型说这是常见库”当作事实，包名、发布者和维护历史都应在官方仓库或包管理平台确认。
第四，把结果写进团队流程。无法确认来源的代码进入隔离分支，先由开发者重写或替换，再合并到主分支。
AI 还可能带来供应链问题
模型有时会推荐并不存在的包名，或者把拼写相近的恶意包当成正确依赖。OWASP 的 Secure Coding with AI 指南特别提醒，攻击者可以注册看起来合理的名称，等待开发者或模型把它安装进项目。依赖的风险不只来自许可证，也来自包本身是否真实、是否有人维护、是否出现可疑脚本。
因此，安装前至少确认包是否存在、官方来源是什么、版本和维护者是否可信、安装脚本会做什么。生产项目还应锁定版本、使用审计工具并限制构建环境的网络和权限。
普通开发者可以做到的最低标准
不必为每一行代码建立复杂的法律档案，但要把可疑长片段、外部库和关键生成记录留下来。涉及商业核心、加密、协议实现和安全控制的代码，优先使用成熟且许可清晰的实现，并进行人工审查。
AI 让复用变得非常便宜，也让“代码从哪里来”更容易被忽略。把来源和许可证当成代码质量的一部分，才能让 Vibe Coding 的速度不会变成项目后期的合规账单。
