Copilot 使用一年后，代码质量真的变好了吗？

Copilot 生成的测试代码几乎覆盖了所有分支，连 BigDecimal 的比较方式都处理对了。我只需要微调几个数值，测试覆盖率直接从 60% 飙到 90%。

写重复代码，它比我记得牢

做后端最烦的是写 DTO、写 Mapper、写 Feign 接口。以前靠复制粘贴改字段名，总有漏改的时候。现在只要定义好实体，Copilot 能顺着我的命名习惯把 getter/setter、构造器、Builder 全补出来。

有次写一个二十多个字段的 VO，我刚敲完第一个字段，它直接给了我完整的类定义，包括 @ApiModelProperty 注解。虽然还得人工确认一遍，但至少省了五分钟。

写复杂 SQL，它是个不错的参谋

上周需要写一个统计报表 SQL，关联五张表，还有各种 group by 和子查询。我写了一版，跑出来数据不对。然后在注释里写了一句：

-- 用窗口函数重写，按部门分组，取每个部门工资最高的前 3 名

Copilot 给了两种实现，虽然不完全符合业务，但其中一种用 ROW_NUMBER() 的思路启发了我，最后结合自己的需求改出来了。这种'半成品'帮助，比直接搜 Stack Overflow 更高效。

那些 Copilot 让我'翻车'的瞬间

它生成过时 API

今年初我在写一个 Spring Boot 3 项目，Copilot 还在给我推荐 spring-boot-starter-web 的 2.x 版本，并且用了 WebMvcConfigurerAdapter（这个类在 Spring 5 就废弃了）。如果不注意，直接复制就会埋坑。

现在养成习惯：每次它补全依赖或旧 API，我都会下意识去官网确认一下版本。

它不懂项目上下文

Copilot 只能看到当前打开的文件，不知道你整个项目的架构。有次它建议一个工具类方法，里面用到了 commons-lang3 的 StringUtils，而我项目里统一用的是 Guava 的 Strings。引入的依赖不一样，直接编译报错。

后来我学会在写关键代码前，先把相关文件（比如常量类、工具类）也打开，让 Copilot 多看到一些上下文。

它太'热心'了

有时候我只是想写一个简单的 for 循环，它直接把整个业务逻辑都补完了，而且补的是错的。比如我在写：

for (int i = 0; i < list.size(); i++) {
    // 这里只需要打印日志
}

Copilot 非要帮我补上'处理每个元素并存入数据库'的逻辑，完全不是我想要的。现在看到它乱补，直接按 Esc 拒绝，或者改成手动模式。

我是怎么'驯服'Copilot 的

经过一年的磨合，我总结了几条让 Copilot 更好用的经验：

写好注释，比写好代码更重要

Copilot 是根据注释和上文来猜的。你写'根据用户 ID 查询用户'，它大概率给一个正确的实现；你写'处理数据'，它可能给一个千奇百怪的版本。

我现在会刻意写意图明确的注释：

# 输入：用户 ID 列表，输出：用户名字典 {user_id: user_name}
# 只返回状态为 ACTIVE 的用户，名字全部大写

这样生成的代码基本不用改。

核心逻辑自己写，体力活交给它

业务核心、安全逻辑、复杂算法，我坚持手写。工具类、测试数据、配置文件、重复的 CRUD，放心交给 Copilot。人机分工明确，效率最高。

定期'喂'它好的样本

如果项目里有自己封装的工具类，我会在写代码时先引用它，让 Copilot 看到。比如项目里统一用 Result 类返回，Copilot 看到几次后，生成的 Controller 方法就会自动返回 Result<T>，而不是随便一个对象。

永远保持怀疑

每次它生成一段代码，我都会问自己：这段逻辑对吗？有没有边界情况没处理？性能怎么样？有没有安全隐患？把它当实习生，需要复核。

对团队协作的连锁反应

代码 review 的重点变了

以前在实验室项目里 review 主要看语法、规范、有没有低级错误。现在这些 AI 基本帮我们解决了，review 更关注设计合理性、扩展性、AI 没考虑到的场景。有人开玩笑说，现在 review 是'人帮人看 AI 写的代码'，但我觉得这是好事。

新人上手变快了

去年新加入实验室的一个学弟，两周就能独立写业务代码。他自己说，Copilot 帮他省去了查 API 的时间，可以更专注理解业务。但我们也会刻意让他手写一些关键代码，防止过度依赖。

安全隐患浮出水面

有次 Copilot 生成了一段代码，里面居然包含一个硬编码的阿里云 AccessKey（假的）。虽然那是测试密钥，但也提醒我们：AI 训练数据来自公开代码，那些被误传的密钥也可能被学进去。

我们在 CI 里加了一步静态扫描，自动检测可能的密钥泄露和 SQL 注入。

一年后的复盘：代码质量到底变好了还是变差了？

这个问题很难一概而论，我试着分维度说：

• 可读性：变好了。AI 生成的代码通常遵循主流规范，命名也相对合理。
• 正确性：没太大变化，因为核心逻辑还是人写的，AI 只是辅助。
• 性能：有点下降。AI 倾向于生成'能跑就行'的代码，不会主动考虑性能优化。比如它可能用双层循环而不是用 Map，这点需要人工优化。
• 可维护性：看情况。如果 AI 生成的部分符合团队规范，维护性就好；如果它用了团队不用的库或模式，反而增加维护成本。
• 缺陷率：有所下降，因为单元测试覆盖率上来了，很多低级 bug 在测试阶段就被发现。

整体而言，我的结论是：代码质量没有自动变好，但 AI 给了我们更多时间去关注质量。原来花在重复劳动上的时间，现在可以用来做设计、写测试、优化性能。

给正在尝试 AI 编程的同学一些建议

1. 别怕它，也别信它。把它当成一个经验丰富但偶尔会出错的搭档，保持警惕。
2. 从重复劳动开始用。写测试、写文档、写配置，这些地方试错成本低。
3. 团队要有规范。规定哪些场景可以用 AI，哪些必须手写，生成的代码如何审查。
4. 关注数据安全。敏感项目慎用云端 AI 工具，或者用私有化部署的方案。
5. 别丢掉基本功。如果你连基础的语法和算法都不懂，AI 生成的代码错在哪你都看不出来。

未来会怎样？

AI 编程工具还在快速迭代。我最近在试用 Copilot 的聊天模式，可以直接问它'这段代码有什么问题'，它居然能指出潜在的 NPE。相信再过一两年，AI 不仅能生成代码，还能帮我们做代码审查、性能分析、自动重构。

但有一点我越来越确信：AI 不会取代程序员，但会用 AI 的程序员可能会取代不会用 AI 的程序员。这不是贩卖焦虑，而是工具演进的自然结果。就像当年从汇编到高级语言，从记事本到 IDE，每一次效率跃迁，都会重新定义开发者的能力模型。

我们能做的，就是拥抱它，驯服它，让它成为我们手中的工具，而不是反过来。