1.2 AI 代码补全时代：根据正在编写的内容提供建议

使用输入法时，刚打出“会议”，候选词里就可能出现“纪要”。代码补全也有类似的交互：开发者先写下一部分，工具结合附近代码提出后续建议，开发者决定是否采用。

AI 代码补全与传统补全的区别，在于建议的范围。传统工具通常提示已知变量、函数名或固定模板；生成式补全还可以根据注释和上下文，提出多行代码甚至一个函数的草稿。

补全怎样进入日常开发

GitHub Copilot 的技术预览发布于 2021 年 6 月，是这一阶段有代表性的产品。它将生成代码的能力放在编辑器里，开发者不需要专门切换到聊天页面。

本节讨论的是“在编辑位置提供建议”这种能力。今天许多补全产品也加入了聊天和智能体功能，因此不能把早期补全的限制当成整个产品的当前能力。

一次补全建议是怎样产生的

假设你写下一条注释：“筛选出已经完成的任务，并按完成时间排序。”工具可能结合当前文件中的任务结构，生成过滤和排序代码。

这段建议是否可靠，取决于它实际获得的信息：任务状态究竟叫 done 还是 completed？完成时间是数字还是字符串？没有完成时间的任务应如何处理？如果相关定义没有提供给模型，它就可能使用一个看起来合理、实际不存在的字段。

常见交互是以灰色文字显示建议，接受后才写入文件；也可以拒绝建议，继续自己输入。具体快捷键可以在所用编辑器中查询，不同产品的默认设置未必一致。

哪些地方适合补全

使用位置	适合的原因	接受前要检查什么
重复的数据转换	相邻代码已经展示了规则	字段名和空值处理是否一致
已明确规则的小函数	输入、输出和计算过程较清楚	边界条件是否遗漏
测试用例草稿	已有测试可作为格式参考	预期结果是否独立判断
注释和说明	能结合附近实现起草文字	说明是否与实际行为相符

补全对重复工作很有帮助，但它不适合替你决定尚未澄清的业务规则。例如“用户删除后保留哪些数据”需要先作出产品决定，不能把模型建议当作默认答案。

与补全协作的小习惯

先给变量和函数起清楚的名字，再写关键约束。例如，比起 process(data)，filter_completed_tasks(tasks) 更容易说明用途。名称本身也是模型理解任务的线索。

接受建议时，按一个可以理解的小片段推进。如果一次接受几十行却没有读懂其作用，后面出现错误就很难知道从哪里开始检查。对于条件判断，可以用一个满足条件、一个不满足条件、一个恰好等于边界的例子进行核对。

假设补全生成了 price > 100，需求却是“满 100 元”。拿 99、100、101 三个数试一下，就能发现中间那个例子不对。这比只看代码是否有红色波浪线更有效。

为什么还需要聊天和智能体

补全主要回答“这里接着怎么写”。当你还不知道该改哪个文件，或者需要讨论两种设计的取舍时，聊天更便于来回说明。若任务还需要修改多个文件、启动程序和读取日志，就需要工具执行与结果反馈。

这些能力可以在同一个编辑器里共存。熟悉项目的人可能大量使用补全；接手陌生代码时，先通过对话了解结构更合适；明确修改目标后，再让智能体执行。选择取决于当前任务，而不是必须逐代淘汰旧工具。

工具入口

• GitHub Copilot：了解补全及其他开发辅助功能。
• Continue：查看可配置的开发辅助方式。
• Tabnine：了解其编辑器集成和部署选项。

是否收费、支持哪些模型，以及数据如何处理，都应以所选版本的说明为准，不宜用“永久免费”或“绝不上传代码”概括整类工具。