前言
从 2021 年 Github Copilot 的横空出世，GPT-4 点亮了 AI 编程助手的第一缕曙光，再到 Cursor + Claude 3.5、Windsur + Agent，最后是今年的 Claude Code 加上各家的编程代理（Coding Agent Cli）。四年多来，AI 对程序员的影响是显著的，已经成为一种大趋势。我在这几年的使用过程中也有一些感悟或者说技巧，今天就和诸位分享一下。
从副驾，到主驾
Copilot 在中文里的意思是「副驾驶」。微软在 2021 年给 Github Copilot 的定位相当准确，彼时的 Agent 技术还无法做到像 2025 年这样随意的多轮工具调用，只能进行隐式的代码续写（补全）。我一开始也只是把 AI 融入到代码补全里，并没有想过要进一步融入我的工作流。
第一个转折点在于 Cursor + Claude 3.5。Cursor 的「Edit」和 「Composer」模式结合 Claude 3.5 Sonnet，让我们第一次看到 AI 在代码编写中扮演了部分主驾的角色。模型会自主调用工具，编辑器会对比形成差异，程序员只需审查完成后，点击 「Apply」即可。
正好当时的 Cursor 可以免费使用，我便开始尝试这套组合，让 AI 在实际项目上编写功能。在实际体验中，对于不需要太多上下文感知的逻辑功能（如算法、逻辑抽取、代码重构），它展现出很好的效果。但对于需要更多上下文来编写的功能（如基于非公开库的 API 调用、网络请求 API），AI 的表现就很一般，仍然不能完全把方向盘交给它，大部分逻辑还是需要我来编写。
这种情况一直持续到了 2025 年初，直到 Claude Code 的发布。
Claude Code 不同于 Cursor，它没有使用检索增强生成（RAG）等传统技术，而是把方向盘交给模型，就像 Agent 一样。当你提供一些需求后，它会自动调用工具，像人类一样搜索和定位需要修改的代码，再调用工具继续更改。
这种效果实在是惊艳到我了，我便开始大量使用 Claude Code。实践证明，由于它的深度代码库理解和自主解决复杂任务的能力，开发效率得到了极大的提升。它不再仅仅是「补全」或「修改」，而是能够端到端地处理一个完整的开发工作流，从理解需求、定位文件，到实现功能、生成测试，甚至还能自动处理 Git 工作流并解决冲突。 这标志着 AI 在编程领域，开始从一个「副驾驶」，逐渐转变为能够独立掌控方向的「主驾驶」。
方向盘不能完全交给 AI，Code Review 依然重要
虽然到 Claude Code，Codex 等 Coding Agent，AI 的编程能力貌似已经能开始取代程序员了，实际是这样吗？
我体验下来，有几点是目前的 Coding Agent 的缺陷（短时间无法改善）：
复杂架构的设计
AI 在架构设计这块，不能说是一塌糊涂，也可以说是相当糟糕了。对于实际不会太多代码的入门程序员，结合 Vibe Coding，在迭代过程中，逐渐会形成很多代码，AI 倾向于无组织地把代码堆砌到几个文件中，没有一个合适的架构来分层归类和组织代码。
本质上，AI 只会编写大家都在用的「样板代码」，因为它学习了海量的开源代码。但架构设计是高度依赖具体业务场景和未来发展预期的权衡，涉及性能、可扩展性、可维护性等非功能性需求的思考。 AI 无法实际理解你的功能所需要的架构，也无法预见未来的技术选型，常常会给出看似炫酷但并不符合实际的方案，或者在不同功能模块间采用不一致的设计模式，导致架构混乱。
幻觉与难以发现的 Bug
我们都知道, AI 会产生「幻觉」。在代码领域，这表现为捏造不存在的 API、调用了错误版本的库函数或类，传递不正确的参数到库的函数，或者一本正经地写出逻辑上完全不通的代码。更麻烦的是，AI 有时会引入一些非常微妙的逻辑错误或边界情况处理的遗漏，这些 bug 很难通过单元测试发现，往往需要对业务逻辑有深入理解才能识别。这类幻觉，除非引用最新的文档，已存在的类似逻辑的代码，很难彻底根除。
对于开发者来说，调试自己不熟悉甚至没有亲自编写过的、由 AI 生成的复杂逻辑，其难度和耗时远超自己从头开始写。这类幻觉在 Agent 的持续迭代下，其隐患在被不断的放大，随着迭代次数的增加，问题会越来越严重，最终可能导致整套程序崩溃。
这意味着，Code Review 依然重要。我们在实际编写业务逻辑时，还是需要仔细查看 AI 生成的代码，有时候它就会跑偏了，调用什么不符合当前版本的函数啥的…
我自己的使用方式
前面也说到了，AI 在算法，固定逻辑，或基于公共库进行部分业务逻辑的编写上很不错。但是在某些时候依然会有幻觉，或者架构设计不完善，导致生成的代码难以维护等。我也总结了几条使用的方式，如下：
- 提供代码优于文档
项目库的文档，有时候并不是确定性的，可能随着版本的更新会过时，或者没有详细的编写某些函数的作用。因此，在多数情况下，提供已实现逻辑代码，总是优于提供某个项目的文档。这些逻辑代码可以是你项目里面已有的部分代码，或者是在 Github 等其他地方的开源代码。AI 能参考这些已有代码的实现，来为你的项目生成更符合你项目需求的代码。
- 具体修改，圈定范围
无论是生成业务逻辑，或者修复业务 bug。尽量先由你来定位代码需要增加，修改，删除的位置。这些位置可能是一整个文件，或者一个类，甚至是一个函数或者一个方法。你需要将这些指定的位置（以及这些逻辑可能依赖的外部库或者代码）给 AI，并圈定这些范围，详细描述需要修改的逻辑。让 AI 只在这些区域内进行代码的生成或者修改，避免它修改到其他位置，也可以让它不弄乱你的代码架构设计。
- 架构设计由你自己来
将自己定位为架构师和决策者。由你来搭建项目的骨架，定义好模块、接口和数据结构。把具体的、独立的实现细节交给 AI 去填充。
例如，你设计好了一个 Service 类和它的方法签名，再让 AI 去实现这个方法内部的具体逻辑。
这样既能保证整体架构的质量和一致性，又能利用 AI 提升编码效率，实现「人类负责思考，AI 负责执行」的最佳协作模式。
结语
使用 AI Coding 这几年，我意识到，「协作」依然是目前使用 AI 最好的方式。无论是定义一堆 SPEC 文件，还是各种提示词工程让 AI 能写出维护性更高的代码，本质上都是想让需要程序员协作的部分，一点或者大部分都转交给 AI 自己实现。
实际证明，这些东西效果并不够好。与其恐慌会被 AI 取代，还不如和 AI 一起协作，才能有更好的架构设计，更快的业务产出。
