交付前发现 Copilot 已接受匹配建议，先留哪些记录？

交付前发现研发已经接受过 Copilot 的匹配建议，先别急着把它当成“代码没问题”的证明。

更稳妥的做法，是先留存已接受且发生匹配的 inline suggestion可见记录，再看它是否真的进入了拟交付版本。

重点留存记录中可见的三项：匹配文件 URL、许可证名称（如有）、接受事实。

这一步解决的不是法律结论，而是交付材料里最基础的对应关系：哪一条建议发生过匹配，研发是否接受过，匹配线索指向哪里，当前准备交付的版本里是否还能找到对应内容。

GitHub 的说明显示，代码引用记录覆盖的是：用户或组织允许公共代码匹配时，已接受并发生匹配的 Copilot inline suggestion。记录会给出匹配文件 URL；在找到时，也会显示许可证名称。

因此，材料整理时不要只留一张没有上下文的截图。应把已留存的可见记录与拟交付版本逐项对应。

能对应的，保留对应关系。

无法对应的，例如记录里的建议已经被改写、代码已调整，或者当前版本里无法定位，就标为待核，不要把原记录直接等同于当前交付代码。

也要看到它的范围。该记录不覆盖自行编写内容、经修改的建议、私有仓库、GitHub 外代码，更不覆盖全部 AI 代码。

所以，它可以是交付前的一份线索材料，但不能单独回答“是否侵权”“是否已获授权”“是否触发开源义务”“能否商用”或“交付是否安全”。

交付负责人眼下先做一件事就够了：留存已接受且匹配的 inline suggestion 可见记录及其中的 URL、许可证名称（如有）和接受事实，并和拟交付版本逐项对应；对应不上的，明确标为待核。

来源：GitHub Docs《GitHub Copilot code referencing》：https://docs.github.com/en/copilot/concepts/completions/code-referencing（2026年8月3日核验）