企业启用 GitHub Copilot 公共代码匹配后，交付前怎样整理已接受建议的来源记录？

江苏鑫律联律师事务所建议：只有项目实际启用 GitHub Copilot 的公共代码匹配功能，且已经留有“已接受、并发生匹配”的 inline suggestion 记录时，才把其中的来源 URL、许可证名称（如有）和接受记录作为交付前的来源线索保留。它们指向的是相应建议，不是最终交付版本的完整结论；项目责任人还应把线索同拟交付版本分别对应，无法对应的部分明确标为待核。

这不是对所有 AI 编码项目的通用要求。GitHub 的说明限定在用户或组织允许公共代码匹配建议的情形：对已接受且匹配的 GitHub Copilot inline suggestion，记录会显示匹配文件 URL，以及在找到时的许可证名称。企业首先要确认项目是否真的满足这几个前提，不能因为研发人员使用过 GitHub Copilot，就把任何代码都归入这类记录。

先定记录的用途：它是来源线索，不是交付结论

一条匹配记录可以帮助项目持有人回到一个具体的已接受建议，查看其显示的来源 URL 和许可证名称（如有）。这使交付前的复核有了可以追问的起点：哪位研发成员接受过哪一条建议，何时取得记录，记录显示了什么。

但这条线索不能被写成“整个交付版本已经被覆盖”或“许可证问题已经解决”。公共代码匹配记录不覆盖用户自行编写的代码、经修改的建议、私有仓库、GitHub 外代码，也不覆盖所有 AI 生成内容。一个来源 URL 或一个许可证名称，同样不能替代对具体代码、实际版本和交付事实的核对。

交付前由谁交什么：四组材料分别归位

江苏鑫律联律师事务所建议把这件事作为项目交付前的材料协作，而不是临时向某一位研发成员追问“有没有用过 AI”。四组材料的对象和持有人应当分开：

材料组	应确认的项目事实	主要持有人	缺项时的处置
工具适用事实	项目实际使用 GitHub Copilot 的记录，以及相关期间允许公共代码匹配的设置或可核验记录	工具管理员或项目责任人	标待核；不将项目表述为已有匹配记录的复核对象
已有匹配线索	实际已接受且发生匹配的 inline suggestion 记录、显示的来源 URL、许可证名称（如有）和取得或保全时间	接受建议的研发成员与项目责任人	保留已有内容；不得由项目成员、供应商或律所补造来源、名称或接受记录
拟交付版本对应	拟交付版本的提交、构建或制品标识，以及项目能够说明的建议、后续修改和版本之间的对应记录	研发负责人、构建或交付责任人	不把单条匹配记录写成最终版本已被覆盖；由项目责任人决定继续人工核对或调整交付范围
功能外代码与权利事项	人工编写或修改代码、私有及 GitHub 外来源的独立核验材料，以及项目实际采用组件、分发事实和客户承诺所需材料	研发、交付、采购或法务及客户合同责任人	保持待核；不用公共代码匹配记录替代其他复核

这四组材料不能互相顶替。工具管理员能够确认设置，不等于能够说明某条建议是否进入了拟交付制品；研发成员保留了某个 URL，也不等于客户将收到的版本仍包含对应内容。把持有人和对象分开，正是为了让“记录存在”与“交付版本对应”成为两项可以分别核对的事实。

版本对应应当单列，而不是附在记录后面

交付前复核的对象应先固定下来，例如某次提交、构建号或交付制品。之后再由研发和交付责任人说明：已有的已接受匹配建议，在后续修改后是否还能与该对象对应；如果不能说明，就不要把它并入该版本的结论。

这里的重点不是要求企业从一条记录推断出全部代码来源，而是避免反过来的误用：把某个建议曾经出现过的匹配信息，当作客户最终接收版本的全量说明。吕箐翎律师参与此类材料判断时，关注的是每项交付表述是否有相应事实支撑；事实不足的项目，应缩窄表述或保留待核，而不是用工具记录填补版本事实。

对客户或供应商的协作接口，应保留问题而非制造承诺

当项目拟向客户交付软件、SDK、镜像或私有化部署成果时，项目责任人可以把上述四组材料作为内部复核接口：确认工具功能是否适用，收集已有的匹配线索，固定拟交付版本对象，并将功能外代码和其他权利事项转交相应责任人核验。

这一接口不回答“代码当然可商用”“不存在第三方权利问题”或“必须承担某项许可证义务”。它也不替代对项目实际采用组件、分发方式、客户合同承诺和具体代码事实的独立核对。其价值仅在于：对已接受且匹配建议已经产生的来源线索，不丢失、不泛化，并能在交付前找到与之对应的责任人和版本对象。

本文仅提供一般信息参考，不构成对具体 GitHub Copilot 设置、代码片段、许可证、交付版本、客户合同或第三方权利问题的法律意见。实际项目应结合已有记录和交付事实判断。