大概是去年年底，我开始认真地把 AI 编程工具用进日常工作里。在那之前，我也断断续续试过 GitHub Copilot、ChatGPT，但都是"试了几天觉得还行，然后忘了"的状态。真正让我开始认真对待这件事，是身边一个朋友跟我说：他一个人接了一个原本需要三四个人的项目，靠 Cursor 加 Claude Code 把它干完了。
我当时是半信半疑的。我做后端开发六七年了，写代码这件事对我来说很有节奏感——想清楚了再动手，写的时候手感很重要，这种事我总觉得 AI 介入进来会破坏掉什么。结果试了两三个月之后，我的想法完全变了。
不是变成了"AI 太厉害了程序员要失业"那种，而是变成了——哦，原来这玩意儿有点像是多了一个不知疲倦、知识面很广但有时候会莫名其妙出错的实习生。
先说 Cursor：确实好用，但有个学习过程
Cursor 是我用的第一个 AI IDE，本质上是一个魔改过的 VS Code。如果你是 VS Code 用户，切换进去几乎没有任何成本，界面一模一样，插件兼容，快捷键也基本一致。唯一不同的是，你多了一个侧边栏可以跟它对话，还有一个按 Tab 就能接受代码补全的功能——但这个补全比普通的自动补全要"聪明"得多。
刚开始用的时候，最大的惊喜是它的"代码库感知"能力。你问它一个项目里某个函数是怎么实现的，它不需要你把代码粘贴过来，它自己会去读，然后给你一个有上下文的答案。这在稍微大一点的项目里非常有用，因为很多时候你脑子里已经有思路了，就差把某个具体实现细节捞出来，以前要自己去翻文件，现在直接问。
但也不是没有坑。我遇到过几次很尴尬的情况：Cursor 给我生成了一段代码，乍一看完全没问题，甚至逻辑也对，但跑起来发现某个边界条件没处理。更烦的是，有时候它生成的代码风格和我项目里其他部分差很多，就好像换了个人写的，review 的时候很割裂。
后来我发现，这些问题很多都能通过写一个 .cursorrules 文件来缓解——就是给它一份"项目守则"，告诉它你们团队的编码规范，用什么框架，有哪些命名约定，等等。这份文件写得越详细，它生成的东西就越接近你想要的。这个发现让我意识到，AI 编程工具其实特别依赖你有没有把它当工具用好，而不是简单地把它丢那里然后期待奇迹。
Claude Code 是另一个维度的东西
Claude Code 和 Cursor 的感觉完全不一样。Cursor 是 IDE，你在里面写代码，它帮你补全和修改。Claude Code 是命令行工具，你给它一个任务，它自己去做。
第一次认真用 Claude Code 是在处理一个老项目的重构。那个项目大概有两万多行 Python，历史很长，代码风格非常混乱，有些模块几乎没有注释，有些函数名起得也很随意。我当时的任务是把其中一块核心逻辑从同步改成异步，影响的文件大概有二三十个。
我在 Cursor 里试了一下，发现有点吃力——它的上下文窗口撑不住这么多文件，每次都要我手动把相关文件 add 进来，而且改了一个地方之后，它有时候对另一个地方的理解就不一致了。后来我切换到 Claude Code，直接在项目根目录下运行，告诉它我要做什么，让它先分析一下影响范围，再给我一个修改计划。
它给出了一份相当详细的分析，列出了哪些文件需要改、改动的原因、可能的副作用，甚至还指出了几个我没注意到的地方——因为有些函数在多个地方被调用，而其中一个调用我完全忘了。确认计划之后，我让它开始执行，它一个文件一个文件地改，改完之后会告诉我每一步做了什么。
这个过程大概花了不到两个小时，以前我估计要搞两三天，而且我改完还得写测试确认没有引入新的 bug。Claude Code 在改的时候还顺带帮我更新了部分测试文件，这是我没有要求的，但它"觉得"应该这样做——而且基本上是对的。
当然，这中间也有失误。有一处它把一个变量名改错了，导致某个测试失败了。但我把失败信息粘给它，它很快就定位并修复了。
说实话，这次体验之后，我对 AI 编程工具的看法有了比较大的转变——它不是"帮你敲键盘的工具"，更像是"你可以分派任务给它的协作者"。
我现在的工作流是什么样的
折腾了将近一年之后，我逐渐稳定下来了一套自己的节奏，大概是这样的：
日常的小任务、快速实现、写函数、改 bug，我用 Cursor。这类任务对上下文的要求不高，Cursor 的即时补全非常流畅，感觉就像有人在你旁边帮你打字，但比你想得更快。
跨文件的大型重构、架构调整、分析复杂 bug 的根因，我用 Claude Code。这类任务需要它有全局视角，Claude Code 在这方面确实比 Cursor 更稳。
写文档、写注释、整理 API 说明，这个我基本上全交给 AI 了，因为这是最无聊的工作，也是 AI 做得最好的工作之一。
不过有一件事我是坚持自己做的：核心逻辑的设计和架构决策。AI 很善于实现，但"该怎么设计"这件事，我觉得还是要自己想清楚。让 AI 直接设计架构，容易出现"看起来合理但实际上对你的业务场景不对"的情况，这类错误比代码里的语法 bug 更难发现，也更难改。
📊 我个人的评估（基于将近一年的使用）
有几个坑，提前说一下，省得你走弯路
1. 别太信任它生成的测试
这个是我吃过亏的地方。AI 生成的单元测试，很多时候是"可以跑过的测试"而不是"真正有意义的测试"。它会倾向于生成一些覆盖率高但实际上测不到边界条件的测试用例，看起来绿了一片，但真的出问题了还是抓不住。
现在我的做法是让它生成测试之后，我自己再审一遍，重点检查：边界条件有没有测到、异常情况有没有覆盖、mock 数据是不是合理。这个过程比自己从头写测试要快，但不能省掉审查这一步。
2. 越大的任务，越要分步
刚开始用的时候，我喜欢把一个大需求整个甩给它，让它一次搞定。这样做很容易出问题——要么它中途迷路，要么它生成了一大堆代码，你根本不知道从哪里开始 review，出了问题也不好定位。
现在我的做法是拆任务。就算一个功能整体上只需要三十分钟，我也会分三步来做，每步完成之后确认一下，没问题再往下走。这样既保证了质量，出了问题也很好找。
3. 它对你的项目一无所知，得告诉它
AI 不知道你的项目背景，不知道你的业务逻辑，不知道你们团队的潜规则。你得在每次对话开始的时候，或者通过 rules 文件，把关键背景告诉它。这个感觉有点麻烦，但确实值得花这个时间。
我有一个习惯，就是给每个大项目维护一个简短的"AI 上下文文件"，里面写着项目概况、技术栈、主要模块说明、我们不用的一些方案（以及原因）。每次跟它开始一个新对话，我就把这个文件的内容粘给它，效果好很多。
4. 别指望它理解"隐性知识"
这个说起来有点抽象。所谓隐性知识，就是"这段代码为什么这么写，有一个说起来很长的历史原因"。AI 看到这段代码，只能从字面上理解，它不知道那个历史原因。
所以有些时候，它"优化"了一段代码之后，看起来更整洁了，但实际上把当时为了规避某个特定 bug 而写的绕路逻辑给删掉了。这种情况下，你如果没注意，直接接受了它的修改，可能过几天那个 bug 就回来了。
关于"程序员要失业"这个话题
我身边有人非常焦虑这个事，也有人完全不当回事。我自己的感受是：这两种态度都有点偏。
焦虑的那派人，往往是因为看到了一些"AI 一个人完成了整个项目"的案例，然后觉得人就没用了。但他们忽略了一件事：能够有效使用 AI 完成那些任务的人，本身通常是有相当强的技术背景的。AI 是把他们的能力放大了，而不是替代了他们。
不当回事的那派人，往往低估了 AI 能力提升的速度。去年能做到的事和今年能做到的事，差距已经非常大了。如果还停留在"AI 只能写写简单代码"的认知里，确实有点危险。
我觉得比较准确的描述是：AI 正在把程序员这个职业的"下限"提高，同时也在重新定义"中等水平的程序员"能做到什么。以前一个中等水平的程序员，工作上有很多时间是在处理重复性的事情——写 CRUD、写测试、改小 bug——这些事情 AI 现在越来越擅长了。如果你的工作主要是这些，那确实需要想想了。
但如果你能搞清楚"要做什么"、能 review AI 的产出、能在 AI 迷路的时候把它带回来——那你的价值不是降低了，而是提高了，因为你现在一个人可以做原来三四个人的工作量。
最后说几句
写这篇文章之前，我其实不确定要不要写——因为关于 AI 编程的文章已经太多了，很多都在讲同样的话。
但我发现很多文章要么过于乐观（"AI 完全改变了编程！"），要么过于消极（"AI 根本没法用于生产！"），很少有人说一些接地气的经验——比如我踩过哪些坑，哪些情况下 AI 真的帮了我，哪些情况下我觉得还是自己动手更快。
所以就写了这篇。如果你还没开始认真用 AI 编程工具，我的建议是：找一个你正在做的真实项目，花两个星期认真试一下 Cursor。不用做任何特别的准备，就按正常开发的节奏来，把你平时会做的事情都试着用它辅助一次。两个星期之后，你自己就会有判断。
我猜你不会失望的。当然，也不会觉得它是万能的。
本文基于作者个人将近一年的使用体验，工具版本为 Cursor 0.47 / Claude Code 1.x（2026年上半年版本）。工具迭代很快，部分细节描述可能与你当前使用的版本有所不同。
相关阅读