Copilot 用了一年，聊聊它对我写代码的真实影响

作为一个日常开发重度依赖 GitHub Copilot 的程序员，聊聊一年来使用它的真实感受：效率提升、代码质量、以及一些被忽略的副作用。

我是怎么用 Copilot 的

我是 2025 年初开始用 GitHub Copilot 的，中间也试过 Cursor 和其他一些 AI 编程助手。一年用下来，现在 Copilot 已经变成我 IDE 里不能少的一个插件了。

简单说说我的使用场景：补全日常代码、写单元测试、解释一段看不懂的代码、重构建议。

效率提升是真的

先说正面影响，效率确实提升了。以前写一个"定义实体类 -> 写 Repository -> 写 Service -> 写 Controller"的完整流程可能要 40 分钟，用了 Copilot 之后大概 20 分钟搞定。

省下来的时间，我可以花在更有价值的事情上——比如想清楚业务逻辑、写更多边界情况的测试。

探索新技术的门槛也降低了。之前我想学 WebFlux，但对反应式编程那一套不太熟。有了 Copilot 之后，我可以一边看它生成的代码，一边理解每一行在做什么。

副作用也是真的

但用久了，我也发现一些不太好的迹象：

1. 有时候会变懒

遇到一个逻辑不算太复杂的函数，我第一反应不是自己想怎么写，而是等它给我补出来。长此以往，我担心自己独立写代码的能力会不会退化。

2. 它的代码不一定对

Copilot 会写那种"看起来很对，但运行起来有问题"的代码。有一次它给我生成了一段并发相关的代码，逻辑错了，我没仔细看就提交了，后来在线上出了问题。

这件事给我的教训是：**AI 写的代码，你也要像审查同事的代码一样审查它。

3. 风格不一致

同一个项目里，我自己写的代码是一种风格，Copilot 补的是另一种风格。团队协作时这会让代码看起来"不是一个人写的"。

我的一些使用建议

用了一年，我总结了几条我觉得有用的经验：

1. 用好注释驱动：在方法上方写清楚你要做什么、入参出参是什么、有什么异常情况。写得越清楚，Copilot 补出来的代码质量越高。
2. 给它上下文：如果你有特定的工具类已经存在，把相关的文件打开，Copilot 会去读这些文件的内容，生成的代码会更贴合你的项目。
3. 不要盲目信任：尤其是涉及数据库、事务、并发、安全的代码，一定要自己过一遍。
4. 保持手写代码的习惯：我给自己立了一个规矩——每天至少手写 100 行"有价值的代码"。

写在最后

AI 编程助手对我来说，已经不是一个"要不要用"的问题了，而是一个"怎么用好"的问题。它就像计算器——你不能因为有了计算器就不学算术，但你也不能放着计算器不用去手算长除法。

**保持独立思考，合理利用工具，这是我一年来最大的体会。