用 Copilot 一年后，我的代码质量变好了还是变差了？

01 从怀疑到离不开去年这个时候GitHub Copilot 刚在我们小组里小范围开放试用。我当时的态度是不屑一顾的——一个 AI 能懂多少逻辑代码补全不还是靠 IDE 的智能提示况且我学了几年 Java写过多少个项目什么场景没见过哪轮得到一个“实习生”来教我写代码。转折发生在一个赶课程设计 deadline 的周末。隔壁组的同学用 Copilot 十分钟写完了一个数据清洗工具而我还在翻 Apache Commons 的文档。那天晚上我提交了 Copilot 的试用申请。一年后的今天我每天写代码大概有 30%~40% 的内容是 AI 补全的。这篇文章想抛开那些“AI 取代程序员”的宏大叙事从一个普通计算机专业学生的视角聊聊这一年我踩过的坑、省下的时间以及它对代码质量真实的影响。02 那些 Copilot 让我“真香”的瞬间2.1 写单元测试它连边界值都想到了以前写单元测试是我最抗拒的活尤其是给课程作业补测试。自从用了 Copilot我的习惯变成了先写函数签名然后空一行敲个// test剩下的交给它。举个例子最近写一个计算折扣的方法javapublic BigDecimal calculateDiscount(BigDecimal amount, String userLevel) { // 空值检查 if (amount null || userLevel null) { throw new IllegalArgumentException(参数不能为空); } // 金额为0或负数直接返回原值 if (amount.compareTo(BigDecimal.ZERO) 0) { return amount; } // 根据会员等级计算折扣 switch (userLevel) { case VIP: return amount.multiply(new BigDecimal(0.8)); case GOLD: return amount.multiply(new BigDecimal(0.9)); default: return amount; } }我在测试类里敲Test然后写下注释java// 测试普通用户无折扣 // 测试VIP用户8折 // 测试金额为0的情况 // 测试传入null抛异常Copilot 生成的测试代码几乎覆盖了所有分支连BigDecimal的比较方式都处理对了。我只需要微调几个数值测试覆盖率直接从 60% 飙到 90%。2.2 写重复代码它比我记得牢做后端最烦的是写 DTO、写 Mapper、写 Feign 接口。以前靠复制粘贴改字段名总有漏改的时候。现在只要定义好实体Copilot 能顺着我的命名习惯把 getter/setter、构造器、Builder 全补出来。有次写一个二十多个字段的 VO我刚敲完第一个字段它直接给了我完整的类定义包括ApiModelProperty注解。虽然还得人工确认一遍但至少省了五分钟。2.3 写复杂 SQL它是个不错的参谋上周需要写一个统计报表 SQL关联五张表还有各种 group by 和子查询。我写了一版跑出来数据不对。然后在注释里写了一句sql-- 用窗口函数重写按部门分组取每个部门工资最高的前3名Copilot 给了两种实现虽然不完全符合业务但其中一种用ROW_NUMBER()的思路启发了我最后结合自己的需求改出来了。这种“半成品”帮助比直接搜 Stack Overflow 更高效。03 那些 Copilot 让我“翻车”的瞬间3.1 它生成过时 API今年初我在写一个 Spring Boot 3 项目Copilot 还在给我推荐spring-boot-starter-web的 2.x 版本并且用了WebMvcConfigurerAdapter这个类在 Spring 5 就废弃了。如果不注意直接复制就会埋坑。现在养成习惯每次它补全依赖或旧 API我都会下意识去官网确认一下版本。3.2 它不懂项目上下文Copilot 只能看到当前打开的文件不知道你整个项目的架构。有次它建议一个工具类方法里面用到了commons-lang3的StringUtils而我项目里统一用的是 Guava 的Strings。引入的依赖不一样直接编译报错。后来我学会在写关键代码前先把相关文件比如常量类、工具类也打开让 Copilot 多看到一些上下文。3.3 它太“热心”了有时候我只是想写一个简单的 for 循环它直接把整个业务逻辑都补完了而且补的是错的。比如我在写javafor (int i 0; i list.size(); i) { // 这里只需要打印日志 }Copilot 非要帮我补上“处理每个元素并存入数据库”的逻辑完全不是我想要的。现在看到它乱补直接按Esc拒绝或者改成手动模式。04 我是怎么“驯服”Copilot 的经过一年的磨合我总结了几条让 Copilot 更好用的经验4.1 写好注释比写好代码更重要Copilot 是根据注释和上文来猜的。你写“根据用户ID查询用户”它大概率给一个正确的实现你写“处理数据”它可能给一个千奇百怪的版本。我现在会刻意写意图明确的注释python# 输入用户ID列表输出用户名字典 {user_id: user_name} # 只返回状态为ACTIVE的用户名字全部大写这样生成的代码基本不用改。4.2 核心逻辑自己写体力活交给它业务核心、安全逻辑、复杂算法我坚持手写。工具类、测试数据、配置文件、重复的 CRUD放心交给 Copilot。人机分工明确效率最高。4.3 定期“喂”它好的样本如果项目里有自己封装的工具类我会在写代码时先引用它让 Copilot 看到。比如项目里统一用Result类返回Copilot 看到几次后生成的 Controller 方法就会自动返回ResultT而不是随便一个对象。4.4 永远保持怀疑每次它生成一段代码我都会问自己这段逻辑对吗有没有边界情况没处理性能怎么样有没有安全隐患把它当实习生需要复核。05 对团队协作的连锁反应5.1 代码 review 的重点变了以前在实验室项目里 review 主要看语法、规范、有没有低级错误。现在这些 AI 基本帮我们解决了review 更关注设计合理性、扩展性、AI 没考虑到的场景。有人开玩笑说现在 review 是“人帮人看 AI 写的代码”但我觉得这是好事。5.2 新人上手变快了去年新加入实验室的一个学弟两周就能独立写业务代码。他自己说Copilot 帮他省去了查 API 的时间可以更专注理解业务。但我们也会刻意让他手写一些关键代码防止过度依赖。5.3 安全隐患浮出水面有次 Copilot 生成了一段代码里面居然包含一个硬编码的阿里云 AccessKey假的。虽然那是测试密钥但也提醒我们AI 训练数据来自公开代码那些被误传的密钥也可能被学进去。我们在 CI 里加了一步静态扫描自动检测可能的密钥泄露和 SQL 注入。06 一年后的复盘代码质量到底变好了还是变差了这个问题很难一概而论我试着分维度说可读性变好了。AI 生成的代码通常遵循主流规范命名也相对合理。正确性没太大变化因为核心逻辑还是人写的AI 只是辅助。性能有点下降。AI 倾向于生成“能跑就行”的代码不会主动考虑性能优化。比如它可能用双层循环而不是用 Map这点需要人工优化。可维护性看情况。如果 AI 生成的部分符合团队规范维护性就好如果它用了团队不用的库或模式反而增加维护成本。缺陷率有所下降因为单元测试覆盖率上来了很多低级 bug 在测试阶段就被发现。整体而言我的结论是代码质量没有自动变好但 AI 给了我们更多时间去关注质量。原来花在重复劳动上的时间现在可以用来做设计、写测试、优化性能。07 给正在尝试 AI 编程的同学一些建议别怕它也别信它。把它当成一个经验丰富但偶尔会出错的搭档保持警惕。从重复劳动开始用。写测试、写文档、写配置这些地方试错成本低。团队要有规范。规定哪些场景可以用 AI哪些必须手写生成的代码如何审查。关注数据安全。敏感项目慎用云端 AI 工具或者用私有化部署的方案。别丢掉基本功。如果你连基础的语法和算法都不懂AI 生成的代码错在哪你都看不出来。08 未来会怎样AI 编程工具还在快速迭代。我最近在试用 Copilot 的聊天模式可以直接问它“这段代码有什么问题”它居然能指出潜在的 NPE。相信再过一两年AI 不仅能生成代码还能帮我们做代码审查、性能分析、自动重构。但有一点我越来越确信AI 不会取代程序员但会用 AI 的程序员可能会取代不会用 AI 的程序员。这不是贩卖焦虑而是工具演进的自然结果。就像当年从汇编到高级语言从记事本到 IDE每一次效率跃迁都会重新定义开发者的能力模型。我们能做的就是拥抱它驯服它让它成为我们手中的工具而不是反过来。