VkingAICursor 用了三个月，我把这些坑都踩了一遍
三个月实战经验：从过度信任到理性使用，一个 React 开发者的 Cursor AI 深度使用报告
# Cursor 用了三个月，我把这些坑都踩了一遍
三个月前我开始用 Cursor 做 React 项目。从最初的"这也太神了吧"到后来的"这玩意儿怎么又在胡说八道"，经历了一个完整的期望值曲线。今天聊聊那些官方教程不会告诉你的事。
先说结论
Cursor 很强，但前提是你得知道怎么跟它配合。把它当个不会累、反应快、但偶尔会犯蠢的初级工程师看待，你的心态会好很多。如果你指望它能独立完成复杂任务，那你大概率会失望。
Tab 补全的正确打开方式
刚开始我基本每个建议都按 Tab 接受。一周后发现代码里出现了一堆莫名其妙的函数调用——看起来逻辑通顺，实际跑起来全是坑。
典型场景：
// Cursor 建议的
const result = await fetchData().then(res => res.json());
// 实际上我的 API 返回的就是对象，不需要 .json()
// 而且 fetchData 内部已经处理了错误，这里再 then 会吞掉异常
教训：**Tab 之前先用眼睛扫一遍**。Cursor 的上下文窗口有限，它看不到你 20 行之前的那个 helper 函数到底做了什么。养成习惯，每次补全至少检查三秒，这比事后调试要省时间得多。
另一个坑是它特别喜欢补全错误处理：
// 它很喜欢这样写
try {
const data = await fetch(url);
return data;
} catch (error) {
console.error(error);
return null;
}
看起来很完整对吧？但在我当前的项目里，返回 null 会导致下游一连串的 null check 报错。我更希望它抛出异常让上层处理，而不是静默失败。这种"看起来很安全"的代码，反而是最难调试的。
Composer 模式的实战经验
Composer（Ctrl+I）是 Cursor 的杀手级功能，能一次性生成或修改多个文件。用好了是真香，用不好就是灾难。
**什么时候用 Composer：**
**什么时候不要用：**
一个真实案例：我让 Composer 帮我加一个 loading 状态。它确实加了，但顺手把我的 useEffect 依赖数组改了，导致无限循环。问题是它改的那行代码跟我描述的需求半毛钱关系都没有，纯粹是"顺手优化"。从那以后我用 Composer 之前都会先 commit，改完再 diff review。
Chat 模式的正确用法
Chat（Ctrl+L）我主要用来做这几件事：
**1. 读我不熟悉的代码**
把文件 @ 进去，问它"这段逻辑在干什么"。它解读代码的能力比补全要靠谱得多，因为不需要预测未来，只需要理解现有内容。我接过好几个祖传代码项目，靠 Cursor Chat 快速搞清了整体架构。
**2. 写单元测试**
这个场景意外地好用。给它一个函数，让它写测试用例，通常能覆盖到我想不到的边界情况。唯一要改的是它的断言风格——它喜欢用 expect(...).toBe(...)，但我习惯 assert.strictEqual，每次都要手动改。
**3. 解释错误信息**
把报错堆栈扔进去，让它分析可能的原因。这个命中率挺高，特别是遇到那些 Google 都搜不到结果的奇葩错误。
那些让我翻车的瞬间
**案例一：置信度过高**
有次调试一个性能问题，Cursor 信誓旦旦地告诉我是因为我没有用 React.memo。我信了，加了 memo，问题没解决。后来发现是第三方库的版本问题。它会基于模式匹配给出"看起来合理"的建议，但不会告诉你这只是它的猜测。
**案例二：过时的最佳实践**
它建议我用 componentWillMount 做初始化。哥们，这是 2026 年，React 18 都出来多久了。它的训练数据有截止时间，有些"最佳实践"已经变成了反模式。
**案例三：上下文断层**
我在一个文件里定义了类型，另一个文件里用 Cursor 补全。它完全不知道那个类型的存在，自己造了一个结构相似但字段名不同的类型。编译时才发现类型不匹配。解决方案：用 @ 把类型文件加到上下文里，或者手动复制粘贴类型定义。
付费值不值？
我买了 Pro 版，每月 20 美元。对我这个高频用户来说值，因为：
如果你只是偶尔用，或者主要写特别定制化的业务逻辑，免费版够用了。Pro 版的优势在于更快的模型和更长的上下文，这对大型项目帮助大。
几个实用设置
// settings.json 里我改了这些
{
"cursor.aiProvider": "anthropic", // Claude 比 GPT 更稳
"cursor.maxTokens": 4096, // 限制生成长度，避免它写太多
"cursor.autoSaveAfterApply": true, // Composer 改完后自动保存
"cursor.excludePatterns": [
"**/node_modules/**",
"**/.next/**",
"**/dist/**"
] // 排除构建产物，减少干扰
}
还有个隐藏技巧：在项目根目录放个 .cursorrules 文件，定义你的编码规范。比如：
Use TypeScript strict mode
Prefer arrow functions
No console.log in production code
Use Tailwind CSS for styling
这样 Cursor 会尽量遵循你的风格，生成的代码更一致。
和 GitHub Copilot 对比
两个我都用了挺长时间。简单说下区别：
**Copilot：**
**Cursor：**
我现在主力用 Cursor，因为多文件编辑和项目级上下文对我帮助更大。但如果是纯补全场景，Copilot 的准确率还是要高一点。
给新手的建议
2. **永远 review 它的输出**：不要因为它是 AI 就盲目信任。至少扫一眼逻辑对不对
3. **用 @ 明确上下文**：它不会自动知道你刚在另一个文件里写了什么，用 @文件名 把相关信息带进来
4. **学会拒绝**：Tab 不是必须按的。觉得它的建议不对，就继续写你的
5. **不要让它做重大决策**：架构设计、安全策略、性能优化方向，这些还得靠自己
6. **定期更新**：Cursor 更新挺勤快，新版本往往有不错的改进
最后
Cursor 是个好工具，但归根结底是工具。它能加速你的工作，但不能替代你的判断。把它当辅助，而不是拐杖。
会用的人能翻倍效率，不会用的人可能反而被带坑里。差距不在于工具本身，在于你知不知道自己想要什么，以及能不能识别它给的答案对不对。
技术再进步，工程师的核心能力始终是理解问题、分析方案、做出判断。AI 只是把实现速度提上来了，本质的思考还是得靠人。
写这篇的时候我问 Cursor："你觉得 AI 会取代程序员吗？"
它回了一段很官方的话，什么"AI 是工具，人类是主宰"之类的。挺聪明的回答——知道什么该说，什么不该说。
你看，这就是我说的：它能模仿，但还没到能真正思考的程度。用它，别信它。