GitHub Copilot：革命未竟，未来可期

GitHub Copilot 正式上线，尽管还有不少缺陷和争议，但仍然为开发者带来了新颖的使用与开发体验，让我们能愈发感受到「智能」二字的份量。

引言

GitHub Copilot（简称 Copilot）是由代码托管平台 GitHub 和人工智能研究机构 OpenAI 联合推出的代码编写辅助工具。正如它的名字（「副驾驶」）比喻的那样，Copilot 可以根据输入的代码，甚至自然语言表达的注释、描述等，自动补全代码或生成完整的代码片段，大大节省开发者的时间。

Copilot 最初上线于 2021 年六月底，经历了一年的「技术预览」阶段，已于今年 6 月 21 日正式推出，采用付费订阅模式。

正如每个基于 AI 模型的工具都难以回避的那样，Copilot 甫一面世就引发了激烈的讨论：它写出的代码质量如何？会不会让开发人员丢掉饭碗？运行原理有没有侵权风险？这些问题去年夏天在技术社区中常常「刷版」。一年过去，正式上线的消息又引发了一波类似的关注和讨论。

我自己是一名开发者，从内测早期就开始尝试在工作中使用 Copilot。本文中，我打算基于自己的视角和思考，唠唠与 Copilot 有关的一二事情。

Copilot 先进在哪？从自动补全的原理谈起

没有编程经验的读者可能不太理解为什么程序员需要自动补全：这真的不是想偷懒才要用到的外挂，而是现代开发环境下必不可少的功能。

实际上，大家在日常使用电脑时，都会用到一个类似的功能：输入法的自动补全。如果没有自动补全（用过「智能 ABC」的朋友可以回想一下当年体验），想要打出「少数派」三个字，就需要输入 shao 、找到「少」字，然后输入 shu、找到「数」字，最后输入 pai、再找到「派」字。

这还仅仅只是三个字的情况。如果我们输入大段的文本时，仍然需要以这样全拼的方式完成，那么腱鞘炎就在向你招手。

好在现在的输入法通常都是十分智能。不必输入完整的拼音，只需输入一部分即可：输入 shao's 就能找到「少数」二字。而当输入多次「少数派」之后，只要输入 ssp 这样的缩写就能直接首词上屏。

编程过程中，也会面对类似的问题，只不过程序员要输入的不是日常词句，而是因语言和项目而异的模块、API 方法等。它们的数量可以说是多不胜数，比新华字典有过之而无不及：

而通常大多数人的记忆能力有限，不可能将这些 API 方法全部记住。因此，代码编辑器和 IDE（Integrated Development Environment，即开发集成环境）的标配功能，就是根据所用编程语言的文档，以及当前开发项目的上下文，在输入代码过程中即时提示并补全，减少心智记忆负担。

那么，这种自动补全是如何实现的呢？

这不是一件容易的事。毕竟，要想「信手拈来」，必先「融会贯通」；对于传统 IDE 来说，要实现对代码补全支持的功能，通常就相当于变相地实现一门编程语言。具体而言，IDE 要具有针对相关语言的词法分析、生成 AST（Abstract Syntax Tree，即抽象语法树）等能力，集成或实现类似于代码扫描器（Scanner）、解析器（Parser）、类型检查器（Type Checker）等等组件。这都需要工程师倾注大量的时间和心血。

以一句最简单的 TypeScript 版「Hello World」为例，编辑器要实现 console.log('Hello World!'); 的自动补全，就得对这句代码开展诸多步骤的解析，将其分解为承担不同角色的多个部分（引用自 How to Implement Autocomplete）：

/-- Function Call --- \
                        /                       \
                       /                         \
                  ModuleMember                    \
                   /        \                      \
                  /          \                      \
                 /            \                      \
                /              \                      \
               /                \                      \
              /                  \                      \
             /                    \                      \
ModuleReference("console")    memberName="log"   Literal("Hello World")

这也就决定了，传统的自动补全更擅长补全 Java、Golang 这样的静态类型语言，因为变量有一个固定的「类型」，例如字符串、数字、布尔值等，它们可以在程序运行之前确定下来，解析起来也比较容易。相反，像 Python、JavaScript 这样动态类型语言，同样内容的变量可能因为所处上下文不同，扮演不同的类型，给准确补全造成困难。

随着 AI（人工智能）技术的发展与普及，似乎什么领域都能有 AI 的一席之地，这也包括代码补全。

所以，在 AI 的背景下有人就会想，是否能通过训练一个学习了大量代码模式的模型，使用时模型可以基于当前的代码情况生成符合预期的补全内容？

其实，在 Copilot 之前，已经有不少产品尝试了 AI 路径，如：Kite、aiXcoder、TabNine 等。这类产品的核心就正如前面所提到的那个想法一样，通过训练一个 AI 模型来完成补全，并且在补全的同时还会更进一步，即预测或输出你可能将会用到的 API 方法、参数，或是同类代码等。

而 Copilot 是由 GitHub 与 OpenAI 公司在微软的支持下，基于 OpenAI 研究成果 Codex——生成性预训练语言模型（generative pretrained language model）——发展而来的联合项目。

也许 OpenAI 不如微软、苹果或谷歌这样的公司声名在外，但其不少研究成果却是成绩斐然，比如使用了 1750 亿左右参数训练得到的且被称为是目前已知使用参数最多的 GPT-3 自然语言模型、最近风头正盛且可以根据自然语言描述生成以假乱真图像艺术的 DALL·E 2 等。

而 Codex 则又是在基于 GPT-3 演变发展而来。在 GPT-3 的加持之下，Codex 通过使用包括自然语言以及公开的、GitHub 上公共项目的数亿行代码作为数据训练得来。其最擅长 Python 语言，但也精通其他十几种主流的编程语言。这样「饱读诗书」后，Codex 可以用于大部分编程任务，并将由人类自然语言用诸如注释方式表示来描述的问题或任务转换为可行性代码，从而实现对代码进行转换、重构。

因此，相比于传统的 IDE 以及 LSP（Language Server Protocol）这样静态补全方式而言 Copilot 能有更多地提示，而对于像 Kite、Tabnine 之类同类的 AI 产品来说，预测得又会更加准确。

神器还是噱头，拉出来遛遛

自 Copilot 于去年开放技术内测到今年正式开放之际，虽然使用过它的开发者对其褒贬不一，并且定价并不便宜；但好在初次付费订阅时有 60 天的免费试用期，所以趁此机会简单为那些还没有使用过 Copilot 的读者介绍一下从申请到使用 Copilot 的过程如何。

使用 Copilot 的步骤并没有那么复杂。你首先需要有一个 GitHub 账号，并手动开通 Copilot 功能，然后在支持的编辑器或 IDE 中安装插件并绑定 GitHub 账号即可使用。

开通 Copilot

点击「Enable GitHub Copilot」，之后会跳转到 Copilot 付费订阅选择页面。并选择下方的「Countinue to get access to Copilot」按钮即可：

目前 Copilot 的付费订阅方案有两档：按月支付（10 美元/月）或按年支付（100 美元/年）。

但两类 GitHub 用户将可以免费使用 Copilot：

拥有 GitHub Student Developer Pack 的学生群体。
拥有一个或多个最受欢迎的开源项目的开发者或维护者。

但想要吃免费午餐并不简单。其中，学生群体需要完成身份认证才能获取 GitHub Student Developer Pack，但随着 GitHub 政策的收紧，审核相比于以往已经严格得多。

关联阅读：开学季 | 这些软件和服务的教育优惠，能帮你省下不少钱

至于第二种渠道，门槛也很高。根据官方说法，只有拥有那些「最受欢迎」（the most popular）开源项目修改或管理权限的开发者或维护者，才能免费使用 Copilot。这类用户在认证之后拥有一年的免费使用权，到期后需要重新认证即可。

但什么才算「最受欢迎」，官方的说明仍然语焉不详；目前只知道如果你有资格，在 Copilot 的订阅页面会看到相关提示。比如，知名国产 Android 写作应用「纯纯写作」的作者 Drakeet 就发微博称自己获得了 Copilot 的免费使用资格。

配置编辑器或 IDE

搞定 Copilot 的使用权限之后，有两项关乎代码与隐私的选项可能需要我们再到 GitHub 设置页的「GitHub Copilot」选项卡中去设置：

两个选项的详细内容是：

是否允许 Copilot 匹配网上公开的代码，这有可能会导致最后生成与公开源码相似性极高的代码；
是否允许 Copilot 使用个人的代码片段以帮助改进 Copilot。

使用者可以根据自己的实际情况来决定对这两个选项的设置。

接下来就可以进一步到编辑器或 IDE 中进行配置，目前 Copilot 主要以插件的形式支持了四款编辑器或 IDE，即：

Visual Studio；
Visual Studio Code（VS Code）；
JetBrains 旗下的 IDE；
Neovim（Vim）。

具体步骤可以阅读官方帮助，简而言之就是安装插件—绑定账号两步，因为比较简单，这里不多赘述。

见证奇迹的时刻

在对应的编辑器或 IDE 上成功安装插件之后，我们就可以到相应的代码文件中使用 Copilot。不过初次使用时需要跳转到 GitHub 上进行授权。

以 VS Code 为例，安装插件后，右下角会弹出消息框要求登录 Github，点击登录按钮，在跳转的网页上登录即可。

接着，就是「见证奇迹的时刻」。

当我们在对应的代码文件中输入一段代码或注释后，就等待右下角状态栏 Copilot 图标响应完成（即会有一段像是转圈载入的动效，网络畅通的情况下基本是转瞬即逝），此时就可以在编辑界面看到 Copilot 的给出的相关提示：

我们既可以使用 Tab 键来接受 Copilot 给出的建议，也可以将鼠标移植 Copilot 生成的建议内容之上，点击弹出选项框上的「Open GitHub Copilot」选项进入到建议内容页面，像选择输入法的候选词一样选择其他候建议选项。

如果不需要建议，继续输入或按 ESC 键即可。

Copilot 优劣之我见

从 GitHub Copilot 这项技术开放内测时我就及时注册申请了使用资格，大约用了大概两到三个月后我就获取到了内测资格（算是比较幸运），直到 2022 年 6 月 22 日正式开放为止也有几个月的时间。在这期间，不论是个人项目还是编写一般的示例代码，我都从 Copilot 的辅助中受益良多。

因此本小节我打算从一个开发者的角度来谈谈，经过长时间使用之后我对 Copilot 的看法。

（注：后续内容仅代表我个人主观体验，不能完全代表所有 Copilot 使用者的使用感受。）

这个 AI 程序员合格吗？

大家或许在网上已经看过不少对 Copilot 补全效果「一惊一乍」的描述，但不得不承认，我使用 Copilot 的初期感受也就是一个「惊」字：它似乎真的就好像一个无所不知的程序员，按注释所描述的那样去生成符合要求的代码。

比如现在我有一个需求：用 Python 提取少数派首页文章的标题。

如果让我手擀代码，我的思路是三步走：(1) 通过异步请求的方式访问少数派的官方首页，然后 (2) 解析使用一个名为 BeautifulSoup 的第三方库解析请求后响应到的 HTML 源码，之后 (3) 从当中提取 <title></title> 元素节点中的内容。

而在 Copilot 开启后，我可以直接写一段描述程序功能的注释，然后 Copilot 就给出了如下代码：

注：根据 GitHub Copilot 官方给出的建议，使用 Copilot 时的注释内容最好使用英文，因为使用其他非英文编写的注释所导致的 Copilot 生成的结果可能效果不佳。

这是 Copilot 让我惊讶的地方，至少在我没有定义样板代码的情况下能从相对简单的需求描述中自动生成符合要求的代码。明确地说，这段代码没有太大问题，写得也有板有眼，甚至还顺手帮我们按照标准库、第三方库的规范顺序导入使用到的库，完成度在 90% 甚至更高。

但另一方面，Copilot 也不是完美的。如果以复杂的现实需求来考察，它还显得太「稚嫩」了一些。

在现实世界中，对于一个有经验的程序员或是身经百战与产品经理 Battle 成百上千次的「摸鱼达人」来说，在看似唾手可得的需求之下总会深埋着会一些描述里没有的细节，通常还会考虑得更多；Copilot 目前还不足以做到这一步。

仍然拿上面的需求场景举例，在按部就班实现程序逻辑之外，一个合格的程序员还应当考虑到：

是否需要关闭 SSL 证书验证避免额外的校验；
访问失败时是否需要重试；
如果 <title></title> 元素不存在或者无法提取到当中的内容时该如何处理；等等。

如果希望 Copilot 能进一步生成既符合需求又考虑可能地各种边际状况的代码，那么就仍需要人为地进一步去编写更多的注释，但逻辑越复杂生成的代码质量可能就越低，或是沦落到「面向注释编程」的境地。

这不是我一个人的体会。Medium 上一个名叫 Cyrille Dupuydauby 的开发者，就曾发文表示「Copilot 并没有看起来的那么好」。在文中，他引用推特社区中另一位 Copilot 使用者所生成的代码（生成随机网页主题色）；与我上面的例子类似，这乍看起来也很不错：

但是 Cyrille 指出了这段看似正确无误的 Copilot 代码问题所在，即因为 Math.random 函数取值范围为[0,1)，包括 0 但不包括 1，因此乘 1677215（即二进制的 FFFFFF）后，也不可能产生 FFFFFF，换言之排除了生成纯白色的可能。作者认为，这反映了 Copilot 对于自然语言表达的需求缺乏语义层面的理解；例如在这里，它不理解「颜色」的定义。

当然，尽管 Copilot 面对复杂需求还是成熟度不足，但并不能以此否认它的价值。事实上，我还发现 Copilot 在其他方面也能为程序员提供帮助，最典型的就是生成测试数据。

补充一点背景：代码初步写好后，为了验证代码是否可行或是检验代码是否如预期那样产出同样的结果，通常我们会进入到测试环节，对编写好的代码进行各种各样的测试（也包括前面所谈的边际情况），从而确保代码的稳健性与可用性。这也就是业内常说的测试驱动开发（TDD，Test-Driven Development）。

在这个过程中，测试工程师们会尽可能地去使用不同情况组合而成的数据，验目标代码或 API 方法，从而在测试中尽可能地发现问题。例如，用各种不同的数据去模拟程序可能面对的不同情况，从而检查是否会诱发潜在的异常。

而我发现，每当我可能会使用到测试代码时，通常 Copilot 都能帮我很好地生成一些「好像是那么一回事」的测试数据。仅仅给出一个示例的测试数据之后，Copilot 就「有样学样」地帮我把余下的测试数据都陆陆续续生成出来。

我的头发再也不用为我编不出测试数据而担心了！

还能吟诗作赋？

Copilot 的能力甚至不止于编程相关领域。知名的开源在线画板 tldraw 项目的创始人 Steve Ruiz 就曾在推文上表示：「Markdown 才是让 Copilot 发光发热的地方！」

作为一个 Markdown 狂热爱好者，我表示赞同。其实，除了将 Copilot 用于写代码之外，在这近一年的使用时间里，Copilot 也被我用在了一个「不务正业」地方——写书。

过去几个月，我为少数派创作了一份教程《100 小时后请叫我程序员》。最初，我并没有意识到 Copilot 还能为类似于 Markdown 这样的文本内容进行补全。只是后来有次写文章时，无意间将 Copilot 设为全局启用，结果发现 Copilot 直接将魔爪伸向了我的大白话：

注意，这并非 Grammarly 之类的纠错建议，而是通过当前文档内容（或工作目录下其他文档的内容）实时生成的新内容。

又比如，如果将上一段的内容输入 VS Code，然后另起一段，Copilot 就会在我提到 Copilot 一词时现身（下图灰色斜体部分）：

可以看到，虽然 Copilot 给出的建议内容有点「狗屁不通文章生成器」的味道，但是至少在某种程度上体现了对文章内容的理解，给出的建议也大致符合主题或话题。

这种能力的实用性有多强呢？我认为，与代码编写场景类似，Copilot 至少在现阶段并不能帮我们去创作，对于内容的把控仍需要我们人为自己去掌握；更多时候它所产出结果的「废品率」极高，只有「按部就班」的内容，它才是得心应手。这未必是批评：只要利用好这一点，确实就能节约很多时间。

例如，在创作教程的过程中，我经常需要对涉及代码的部分进行逐行说明。这时，Copilot 这种相似性的补全提示，就能剩下很多手动输入的功夫。

例如，这是一段对 Python 中算术运算符的基础介绍：

事实上，上图中除了第一点是我人工编写之外，剩下的部分都是由 Copilot 基于上下文学习后帮我自动补全，这样我只要检查一遍确认表述无误之后便进行其他部分的修改。

一些灵魂拷问

虽然 Copilot 能提供不少便利性，但与之相伴的问题也不少。时至今日，在开源社区里仍有许多开发者对 Copilot 保持怀疑态度：它生成的代码按什么方式进行许可？是否会泄露个人代码或是安全密钥？既然，Copilot 是以公开的代码为数据进行训练，如果有人故意在代码里「投毒」，会不会导致 Copilot「学坏」，生成不安全的代码？

这最后的一小节里，我主要就会结合 GitHub 官方给出的声明或文档，来谈谈关于 Copilot 让人争议的几个问题。

我的代码会被喂给机器学习吗？

如今隐私问题被越来越多人所关注和重视，在此背景下，不管一门技术有多像「黑魔法」，人们总会首先考虑是否会涉及到隐私数据、是否有暴露个人信息的风险。

对于 Copilot 而言，在网络允许的情况下，个人代码在使用 Copilot 时可能会被上传到 GitHub 的相关服务器中。

根据 GitHub 在 FAQ 中的说明（笔者翻译）：

GitHub Copilot 会收集哪些数据？GitHub Copilot 依靠文件内容和其他数据来工作。它收集数据不仅是为了提供服务，也是为了使用数据以进一步的分析和实现改进。关于如何使用和分享您的遥测数据，如下文所示：

用户参与度数据当您使用 GitHub Copilot 时，它将收集与 IDE 或编辑器互动时产生的事件的使用信息。这些事件包括用户的编辑操作，如接受和驳回的完成度、错误和一般使用数据，以确定延迟和功能参与度等指标。这些信息可能包括个人数据，如假名标识符等。

代码片段数据根据您偏好的遥测设置，GitHub Copilot 还可能收集和保留以下内容，统称为「代码片段」：您正在编辑的源代码、相关文件和在同一 IDE 或编辑器中打开的其他文件、存储库的URL和文件路径。

换言之，Copilot 基于我们对其的设置选项，可能会收集包括我们个人代码片段（包括正在编辑的以及同项目之下的文件）、与个人账户绑定在一起的 IDE 或编辑器上的额外使用信息（比如补全建议接受与否的操作、报错、一般性数据）。这当中会包含个人数据。

考虑到这些数据都可能有一定敏感性，GitHub 会采取相应的加密措施。但这只能提高传输过程中的安全性，数据本身的访问权限仍然可能开放给他人，比如参与 Copilot 开发和研究的 GitHub、微软以及 OpenAI 工作人员。

对隐私的担忧并不是空穴来风。在 Copilot 的测试期间，社区中就有开发者发现 Copilot 似乎会生成包含类似密钥的内容。对此，Copilot 的官方回答是：

由于 Copilot 在训练模型时会使用来自于公开的源码作为训练数据，这些源码当中会包含个人数据；但根据内部测试，Copilot 极少会产出和个人数据一模一样的建议结果。它所生成的类似于诸如 Email、电话号码等个人数据，其实都是模型在训练中通过学习类似的模式表达而综合生成的虚拟数据。

当然，老祖宗教导我们「偏听则暗，兼听则明」，官方尽管做出了回应，留个心眼，以批判和中立的立场对待，仍然是有必要的。

因此，对于 Copilot 不同的使用人群，我可能会有以下建议：

对于在工作环境下从事开发的工程师：请严格遵守公司对于数据安全或个人设备的管理限制。如果不能判断，保险起见在公司里最好不要用 Copilot。如果被有关的安全组或审计人员认定违规，那么就很有可能面临着「被毕业」的风险；
对于小团队或者独立开发者：如果使用 GitHub 托管源码，并且介意自己的项目源码被投喂给 Copilot 作为学习素材（考虑到源码就是安身立命的命根子，有此态度可以理解），那么在官方给出更明晰的说明之前，也可以暂时不要使用 Copilot；
对于开源项目的开发者：推荐使用 Copilot，毕竟源码本来就是公开的，而且优质项目有机会免费使用；
对于一般的编程者（如学生、像我一样的灵活就业者）：如果不是弄什么大项目或者只是写一般的代码，在条件允许的情况下推荐使用 Copilot，一方面可以帮助我们快速编写简单的代码，另一方面可以借鉴 Copilot 生成的结果进而开拓一下思路（比如刷算法题）。

Copilot 会被坏人教坏吗？

鉴于 Copilot 是以网络上公开的源码为食进行训练而来，因此也有开发者会表示担忧，假若有人在代码里下了「毒」，比如代码中包含了一些极具攻击性或杀伤力的命令，或是包含可能有安全隐患的写法，那么是否会「污染」Copilot 进而导致生成不安全的内容？

GitHub 官方对此表示是：有可能。

根据 FAQ 上的说法，公开的源码中会包含非安全性的代码模式、Bug、使用已经被废弃了的 API 或是其他个人习惯用法等等，这都可能会导致 Copilot 生成到一些不良（undesirable）的代码模式。尽管 GitHub 也会存在一些相应的防范措施与过滤系统，以便能随时检测并删除掉一些具有「攻击性的结果」（Offensive Outputs），但并不能完全保证效果。

所以官方也建议，使用诸如 GitHub Actions、Dependabot 适用于开源项目之类的 CI/CD 工具来提高代码的安全质量，甚至在使用 Copilot 时应该也有与之相伴的测试、Code Review 等环节，并结合相应的安全工具以及工程经验来综合判断是否采用 Copilot 的建议内容，尤其是在推送到生产环境前。

总而言之，请谨慎对待 Copilot 所生成的内容。

Copilot 反刍的代码有版权问题吗？

（注：本段内容仅为个人观点，不构成法律意见。）

由于 Copilot 是基于网上公开的源码而训练得来，为此也有的人会担心 Copilot 会不会产出与网上公开源码一模一样的写法或结果，进而被扣上「抄袭」的帽子？

对此，GitHub 表示会用过滤器帮助检测并减少这类罕见情况发生。具体而言，每当 Copilot 生成代码时，会提取其附近约 150 个字符左右的上下文代码，与同 GitHub 上开源的代码进行匹配。如果雷同，则不会作为建议内容显示出来。

但预防归预防，在 Copilot 宣布开放技术内测不久，似乎就「翻了车」。2021 年 7 月 2 日，Python 知名 Web 框架 Flask 的创始人 Armin Ronacher 就曾发推演示了一次 Copilot 令人「无言以对」的「抄袭」行径：Copilot 所补全的平方根倒数速算法 C 语言代码，源自 1999 年所发行的 Quake III Arena 游戏，而且连同注释在内一字不落。而后 Armin 就在用于测试的代码上加入了有关于开源许可证的注释内容，没想到 Copilot 也「有样学样」，将这段代码原始的 GPL 协议中的内容也逐字逐句补完。社区用「反刍」（regurgitate）来形容这种将学到的代码原样「吐」出来的现象。

这不能不引发人们的警惕。对于开发者、特别是大公司而言，开源项目的许可证（License）类型，是会直接影响能否在开发中引用的重要决定因素。最典型的就是 GPL 协议，它要求使用相关代码的下游项目必须按照相同的 GPL 协议开源发布。这对于商业软件是无法做到的，因此，开发环节中必须予以剔除，寻找限制更为宽松的、适用于商业目的的许可证。

在互联网早期野蛮生长的时代，许可证并不太受到重视，许多国内公司并没有把开源许可证当做一回事。某些国产影音播放器至今还在 FFmpeg 耻辱柱上「金榜题名」。但如今，业界都开始越来越正视开源许可证问题，去年国内还出现了首个因违反 GPL 3.0 协议承担法律责任案例；被告被要求停止侵权、赔偿损失 50 万元。

所以对于 Copilot 生成的代码，大家关心其许可证问题也是情理之中。GitHub 是否对 Copilot 生成的代码拥有专利授权？

对此，官方给出的答案是否定的（笔者翻译）：

GitHub 是否拥有 GitHub Copilot 生成的代码？GitHub Copilot 是一种工具，就像编译器或笔一样。 GitHub Copilot 生成的建议不为 GitHub 所有。在 GitHub Copilot 的帮助下，你编写的代码属于你，并且由你负责。我们建议你在将代码部署到生产环境之前仔细测试、检查和审查，正如你对待任何包含非独立原创素材的代码时应做的那样。

与上面各个问题类似，这仍然只是 GitHub 官方的说法。一年以来，发声批评 Copilot 模糊立场的声音此起彼伏。另一方面，一些乐观的观点认为，对于那些相对较短的建议片段，使用者可以根据合理使用的原则免予征得授权；还有相对激进的观点认为，这种机器生成的代码不是「智力创作」，因此不构成著作权法意义上的「作品」。

当然，正如任何 AI 相关的知识产权问题一样，疑问远多于答案，留白远多于规则。动用常识、手动核查、谨慎接受，仍然是更加保险的做法。

结语：革命未竟，未来可期

不仅编程语言都在与时俱进，像 Golang、Rust 这样的「后生仔」在吸取以往编程语言经验的同时，本身也集成了丰富的工具链，只为了让开发者拥有更好的开发体验。

就连 IDE 界也积极进取，原本以为是一潭死水波澜不惊，因 VS Code 搅局也让 JetBrains 这样的霸主迫于压力而推出「面向下一代」的 Fleet。

而包括 Gihutb Copilot 在内，围绕开发需求、借助创新技术而发展得来的工具，在未来也会层出不穷。尽管还有不少缺陷和争议，但我相信这些工具未来会越来越「懂」开发者，它们为开发者带来的新颖使用与开发体验，也会让我们能愈发感受到「智能」二字的份量。