我用 Cursor 写了三个月代码，终于敢说实话了
Cursor 不是银弹，但它确实改变了我的工作方式。这篇文章聊聊真实的生产环境体验，包括踩过的坑和有效的 workaround。
# 我用 Cursor 写了三个月代码，终于敢说实话了
Cursor 发布那天，我以为是又一个 Copilot 换皮。毕竟 GitHub 已经做了 AI 代码补全，JetBrains 也搞了自己的插件，市场看起来已经饱和了。
结果三个月后，我发现自己每周花在代码审查上的时间从 8 小时降到了 3 小时。不是因为它写得多好，而是因为它确实有些东西不一样。
先泼冷水：它不是银弹
很多人看到教程里那种"描述需求→一键生成完整模块"的场景，以为 AI 编程助手已经成熟到可以替代初级开发者了。我第一周也有这种错觉，直到我把 AI 生成的代码直接推到生产环境。
那段代码能跑，单元测试全过，接口文档写得比我还漂亮。但问题是：它用了一个过时的加密库，而那个库三年前就出了安全漏洞。我的代码审查机制完全没拦下来——因为我当时正忙着看 AI 写的优雅架构，压根没细看依赖版本。
这段经历教会我一件事：**AI 生成的代码，安全性审查必须人工做，而且要比以前更仔细。**
真正有用的场景
重构 legacy 代码
这是我用 Cursor 最爽的场景。公司有个五年前的 Node.js 服务，代码里混着 CommonJS 和 ES Module，错误处理要么 try-catch 要么 Promise.catch，回调地狱和 async/await 共存。
我用 Cursor 的 Editor 模式，输入：
将以下代码重构为纯 async/await 风格，使用统一的 ErrorHandling 包装类，
保持对外接口不变。注意：不要引入新的外部依赖。
它确实做到了。代码量减少了 40%，结构清晰了很多。但有个细节我差点被坑：它把几个关键的异常处理块合并了，导致某些边界情况的错误信息丢失。幸好我在 code review 时仔细对比了原始代码和重构后的代码，发现了这个问题。
**教训：重构时，对比变更 diff 比看最终代码重要得多。**
写测试用例
这是 Cursor 另一个真正省时间的地方。以前的流程：写业务代码 → 发现边界情况 → 写测试 → 发现新的边界情况 → 改代码 → 改测试。
现在：用 Claude 3.5 Sonnet 作为 backend，我选中一段代码，按 Cmd+K 说"生成边界测试用例"，它会列出各种 edge case 并生成对应的测试代码。
质量不是 100%——有些测试写得过于机械，缺少真实业务场景的考虑。但作为起点，它把那些"我知道应该测但懒得写"的边界情况都列出来了。
理解陌生代码库
接手新项目最怕什么？看代码。以前我花两三天理解一个模块的架构，现在用 Cursor 的 Chat 模式，直接问它"这个模块的核心职责是什么"、"数据流怎么走"，它能快速给出框架级别的解释。
当然，解释不一定完全准确，但作为导航地图很有用。我先让它给个概览，然后自己深入看关键代码，效率提升明显。
配置建议
Cursor 的配置直接影响使用体验。分享几个我试过觉得有用的设置：
**1. 模型选择**
**2. 快捷键习惯**
**3. 自动补全设置**
关闭"Auto insert completions"，改为手动触发。自动插入经常打断思路，而且补全质量不稳定，手动控制更好。
什么时候不用 Cursor
不是所有场景都适合 AI 辅助。以下情况我倾向于手写：
总结
Cursor 不是替代程序员的工具，它是放大程序员能力的杠杆。用得好，效率翻倍；用不好，生产事故翻倍。
关键是要理解它的边界：它擅长模式匹配和代码生成，不擅长安全审查和架构设计。把合适的任务交给合适的工具，这才是成熟的做法。
三个月用下来，我的代码审查清单里多了一项："检查 AI 生成代码的依赖版本和安全漏洞"。这个习惯比任何 AI 工具都重要。