驾驭 AI 编程：我的 Copilot 使用心得
AI 编程助手已经流行了几年，身边的同事对它的评价两极分化——有人觉得它是革命性的生产力工具，有人觉得它就是个高级自动补全，写出来的代码一堆坑。我自己用下来，感觉这两种评价都有道理，关键在于你有没有找到正确的使用姿势。
AI 写代码是什么感觉
第一次用 GitHub Copilot 的时候，那种感觉有点像突然多了一个结对编程的同事——一个打字速度极快、什么语言都懂、但偶尔会信心十足地胡说八道的同事。
它能在你写注释的瞬间补全整个函数，能帮你记住那些永远记不住的 API 参数顺序，能把你脑子里模糊的意图翻译成代码。但它也会一本正经地生成不存在的函数，或者给出看上去合理实则有细微 bug 的实现。
所以使用 AI 编程的核心问题不是「它能不能写代码」，而是「你能不能判断它写的代码是否正确」。
它真正擅长的事
用了一段时间，我大概归纳出 AI 最能发挥作用的几个场景：
1. 重复性代码
各种 CRUD、序列化/反序列化、测试用例的脚手架——这类代码逻辑简单但写起来耗时，交给 AI 最合适。它的输出基本可以直接用，顶多改几个字段名。
2. 陌生的库或语言
需要临时写一段不熟悉的语言（比如平时写 Java 的人需要调一段 Python 脚本），或者查一个不常用的库的用法，AI 比翻文档快多了。它给出的示例代码通常足够工作，即使版本有点旧也能快速 adapt。
3. 思路整理
把你想实现的功能用自然语言描述出来，让 AI 给出一个实现框架，哪怕最终代码全部重写，这个过程也帮你理清了思路。这有点像跟人讲解问题时，讲着讲着自己就想明白了。
4. 写测试
给已有代码生成单元测试是 AI 的强项。它能快速覆盖各种边界情况，省去很多枯燥的体力活。
它会踩的坑
AI 最容易出问题的地方：
「幻觉」式自信：它偶尔会编造不存在的 API、返回已经废弃的用法，并且语气一点不虚。这是最危险的，因为代码看起来完全合理，只有运行才会报错。对于自己不熟悉的领域，一定要验证它给出的关键 API 是否真实存在。
跨文件上下文缺失：大多数 AI 工具的上下文窗口有限，当项目变大，它对整体架构的理解会变差，生成的代码可能和项目现有的模式、命名规范对不上。
过度自信的重构：让 AI 重构一段复杂逻辑时，它倾向于给出「看起来更优雅」的版本，但可能丢失了原版本处理的某个边界情况，而这个边界情况往往是当初被某个 bug 逼出来的。
我现在的使用方式
经过一段时间摸索，我现在大概是这样用的：
把 AI 当草稿工具，不当最终答案。 让它先写出一个版本，我再在上面改。通常改出来的代码比我从零开始写要快，但比直接用它输出的要可靠。
用自然语言说清楚约束条件。 写 prompt 的时候不只说「实现 XXX 功能」，还要说「使用 XXX 库」「不要引入新依赖」「需要处理 null 的情况」——约束越清晰，输出越可用。
核心逻辑自己写，边缘代码交给 AI。 业务核心逻辑、架构设计、性能敏感的部分，我倾向于自己写，因为出了问题我得能 debug。但是日志格式化、配置文件解析、工具类这些，全扔给 AI。
用 AI 来 review 自己的代码。 写完一段代码，把它贴给 AI 问「这段代码有什么潜在问题」，有时候能发现一些自己没想到的边界情况。
AI 改变了什么
我觉得 AI 真正改变的，不是「写代码的速度」，而是「启动一件事的门槛」。
以前想尝试一个新技术，光配环境、读文档、写出第一个 Hello World，可能就要花掉半天。现在这个启动成本大幅降低了，AI 可以带你快速到达「能跑起来」的状态，剩下的才是真正要思考的东西。
对于有经验的工程师来说，这意味着可以更快速地探索和实验。但对于刚入行的人，我觉得还是要警惕——如果一开始就完全依赖 AI，会错过很多建立基础直觉的机会，而这些直觉正是判断 AI 输出好坏的前提。
最终，驾驭 AI 编程和驾驭任何工具的道理是一样的：你得先足够了解这个领域，才能知道这个工具在帮你还是在坑你。