我用 Cursor 三个月后，发现它最大的坑不是bug，而是你的脑子

# 我用 Cursor 三个月后，发现它最大的坑不是bug，而是你的脑子

写这玩意之前，我其实犹豫了一下——Cursor 的 AI 又没欠我钱，我干嘛要吐槽？

但三个月下来，我算是明白了：Cursor 本身没毛病，问题是太多人把它当成「写代码外挂」，结果越用越懒，最后连自己写的代码都认不全了。

先说一个真实场景

上周我在重构一个老项目，代码大概是 2019 年写的，Python 过渡期的产物，注释还是用中文写的（那会儿团队流行这个）。我把其中一个模块丢给 Cursor 让"重构一下"，它给我生成了个看似很优雅的新版本，用了解耦和依赖注入。

我看了两分钟，觉得不错，就接受了。

然后跑测试，全挂了。

原因很简单：那个模块有个隐式全局状态，代码里四处都有引用，但 Cursor 在重构时根本没意识到那些引用的存在——因为它只看了那个模块本身。

我把这个问题记下来了，后来每次让 Cursor 重构大模块，我都会先手动扫一遍引用关系。这不是 Cursor 的问题，是我自己偷懒了。

最大的坑：你以为你懂了，其实你没懂

Cursor 给你的代码，看起来都很干净。格式化完美，命名规范，甚至注释都帮你写好了。

但问题是：它会帮你写出"看起来对"的代码。

有一次我写一个数据处理管道，Cursor 生成了一个很漂亮的链式调用版本。我直接用了，跑起来也没报错。直到有一天数据量上来，内存直接爆了。

那个链式调用里有个隐式的 lazy evaluation 问题，Python 的 generator 在中间某一步被物化了，但 Cursor 没有告诉我。如果是我自己写，我可能会注意到这点——但因为代码是它写的，我跳过了这个思考过程。

**记住：AI 给代码的时候，不会告诉你它跳过了什么。**

几个我觉得有用的实战技巧

1. 不要一次性问太多

很多人让 Cursor 写一个完整的类，或者一次重构整个模块。这个做法基本是在赌博。

我现在的做法是：把问题拆到最小粒度。比如"帮我把这个函数改成异步的"，而不是"帮我把这个模块改成异步架构"。

前者 Cursor 能处理好，后者它大概率会遗漏边角情况。

2. Tab 接受之前，快速扫一眼变量名

这是个很实用的习惯。Cursor 生成的代码，逻辑往往是对的，但变量命名有时候会让你迷惑——它喜欢用 data、result、temp 这种万能词。

如果你花 5 秒钟看一眼变量名，确认它们是"人话"而不是"机器话"，能省很多后续 debug 的时间。

3. 让它解释，而不是只让它写

这个技巧是我后来才悟出来的。

与其问"帮我写个 Redis 缓存层"，不如问"我现在有个问题：XX，你觉得应该怎么设计缓存层？"

让它先说思路，你再决定要不要让它写代码。这样你能保持对架构的掌控，而不是被动接受一个你不完全理解的黑盒。

什么时候应该关掉 Cursor

说实话，不是所有时候都适合用 AI 辅助写代码。

当你需要写一个很核心的业务逻辑，而且这个逻辑涉及到很多业务上的边界条件时，我通常会关掉 AI，自己慢慢想。

Cursor 擅长的是：帮你写样板代码、帮你做简单的重构、帮你写测试用例。它不擅长的是：帮你做有业务深度的设计决策。

如果你发现自己在写核心逻辑时频繁依赖 AI 生成，而且每次生成都需要花更多时间去看懂它写的东西——那可能不是 AI 的问题，是你自己对该模块的理解还不够深。

这时候停下来，去读一遍相关代码，比继续问 AI 有用得多。

总结

Cursor 是个好工具，但前提是你得知道它的边界在哪里。

它不是你的外脑，它只是你的结对编程伙伴。伙伴会犯错，会遗漏，会给出看起来很对但实际上有问题的答案。

你得负责审查。这不是负担，这是你作为工程师的基本功。