34 · 常见反模式

Cursor 虽强，但用得不对，反而让效率更低、代码更烂、心态更崩。
本文梳理 8 种最常见的 Cursor 反模式，每个都配有真实翻车案例，帮你避坑。

目录

01 · 过度依赖 Agent 完成简单编辑

症状：修改一个变量名、调整一行 CSS、改一个函数参数——这些本来光标定位 + 手动改只需要 3 秒的操作，却打开 Composer/Ctrl+K 打一段提示词，等 AI 生成、再审查、再接受。

为什么这是反模式
Agent 调用有延迟（特别是走云端模型时），每次都要经历”发送请求 → 模型推理 → token 流式返回 → 渲染 diff → 人工确认”这个完整链路。一次简单编辑的”心理开销”会被放大 10 倍以上。久而久之，你会在潜意识里回避小修改——因为”开一次 AI 太麻烦了”。

真实案例

场景：需要把 utils.ts 里一个叫 fetchData 的函数改名为 loadUserData
开发者的做法：打开 Ctrl+K，输入 "把 fetchData 改名为 loadUserData"
AI 做了：改了这个函数，顺带"帮忙"改了返回值类型、添加了错误处理、
          重构了调用方代码——引入了 3 个新 bug
开发者花了 15 分钟：审查 AI 的额外修改、回滚不需要的变更

正确做法

• 单个符号的修改：直接编辑（Cmd+D 多光标、F2 重命名）
• 5 行以内的重构：手动改
• 只在”你不知道精确写法”或”改动涉及多个文件且逻辑复杂”时才用 Agent

心法：能用快捷键解决的，别让 AI 碰。 Cursor 最值钱的能力是”大跨度理解和生成”，不是”帮你省掉一次键盘敲击”。

02 · 不审查 AI 的更改

症状：AI 生成代码后，看都不看直接 Accept All，或者只扫一眼文件名就点了确认。

为什么这是反模式
Cursor 的模型不是你的结对编程搭档——它没有”理解你真实意图”的能力。它只是基于你的提示词和上下文做”最可能的补全”。这意味着：

• 它会自作主张添加你不需要的功能
• 它会引入微妙的安全漏洞（SQL 注入、XSS 无意识引入）
• 它会”修复”本来没坏的代码——而且改错
• 它会删除看似”未使用”实则正在运行的关键逻辑

真实案例

场景：在一个支付系统中，"优化订单查询接口"
开发者提示：把 getOrder 改成更高效的实现
AI 做了：重写了整个函数，删除了原有的金额校验逻辑（因为 AI 觉得 "校验没必要"）
结果：500 笔订单金额错误，线上事故
根本原因：开发者没有逐行审查 diff，直接点了 Accept

正确做法

• 永远在 Accept 之前审查 diff（Ctrl+Enter 查看详细改动）
• 逐文件审查，特别关注：被删除的行、被修改的条件判断、新增的依赖
• 对敏感逻辑（支付、鉴权、数据删除）的改动，必须手动跑一遍验证
• 使用 Cursor 的 “Show Diff” 功能而不是直接 Accept

审查清单

□ 是否有代码被意外删除？
□ AI 是否添加了未请求的功能？
□ 条件判断是否被反转或弱化？
□ 错误处理是否被移除？
□ 是否有新的安全风险引入？
□ 是否修改了不该修改的文件？

心法：把 AI 当成一个效率很高的初级工程师——它的输出永远需要 senior review。 不接受任何你没完全理解的代码。

03 · 提示词过于庞大

症状：一段提示词塞了 500 行需求描述，包括各种边界条件、性能要求、代码规范、历史背景——期望 AI 一次性全部理解和实现。

为什么这是反模式
所有 LLM 都有”注意力衰减”现象：提示词越长，每条指令被精确执行的概率越低。具体来说：

• 中间部分的指令最容易被忽略（“U 形注意力曲线”）
• 多条要求之间可能相互矛盾，模型会”自行取舍”
• 如果提示词超过模型上下文窗口，后半部分直接被截断
• AI 倾向于执行最后几条指令，忽略开头部分

真实案例

开发者提示：（800 字的一段需求）
"请帮我实现一个用户管理系统，包括注册、登录、密码重置、
多角色权限、操作日志、邮箱验证...具体要求：
1. 注册时验证邮箱格式...
2. 密码必须包含大小写...
3. 管理员可以...（以下省略 600 字）"

AI 实际做了：实现了注册和登录的基本功能
遗漏了：密码重置、操作日志、角色权限控制
原因：提示词太长，模型只关注了前两部分

开发者：反复修改提示词重试了 5 次，每次都有不同遗漏
总耗时：原本预期 30 分钟，实际花了 2 小时

正确做法

• 一个提示只解决一个问题
• 复杂功能拆分成多个步骤，逐步递进
• 每个提示控制在 200 字以内（中英文皆可）
• 使用伪代码 / 结构化格式而非大段自然语言

✅ 好的做法：
"Step 1：新增用户注册接口 POST /api/register
  - 参数：email, password, name
  - 校验：邮箱格式、密码强度、邮箱唯一
  - 返回：userId, token"

"Step 2：为注册接口添加邮箱验证码逻辑..."

❌ 坏的做法：
"帮我做一个完整的用户系统，功能包括注册登录密码重置权限管理..."

心法：提示词像代码一样——短小、单一职责、可组合。 一个 hint 只做一件事，做对了再进入下一步。

04 · 忽略上下文限制

症状：在同一个对话里连续对话几十轮，上下文越堆越多，AI 开始”失忆”——忘记了你之前提到的需求、用错了之前定义的类型、反复问已经确认过的问题。

为什么这是反模式
每个模型都有上下文窗口（Claude 200K、GPT-4 128K）。当对话累积到接近上限时：

• 最早的信息被”挤出”注意力范围
• AI 对中后段内容的注意力衰减
• 生成质量断崖式下降——不是慢慢变差，而是突然”变傻”
• 响应变慢（模型需要处理更多的 token）

真实案例

场景：使用 Cursor Chat 开发一个电商后台，连续使用同一个对话
第 1-10 轮：顺畅，功能逐步实现
第 15 轮：AI 开始忘记之前定义的数据模型，重新生成不一致的接口
第 20 轮：AI 使用了一个小时前刚被废弃的旧函数名
第 25 轮：AI 在新增功能时破坏了已实现的功能
开发者：没意识到是对话过长，继续在同一个对话里 debug
最终：浪费了半天时间，最后新建对话后问题消失

正确做法

• 每完成一个独立功能就开启新的对话
• 当一个对话超过 15-20 轮时，主动检查上下文质量
• 如果发现 AI 开始”忘记”已确认的内容，立刻开启新对话
• 在新对话中附带必要的上下文（关键类型定义、当前文件内容）
• 使用 @file 和 @folder 让 AI 直接读源文件，而非在对话中复述
• Cursor 的对话不是”越久越好”——它是”越精越好”

🚩 需要开启新对话的信号：
□ AI 重复问已经确认过的问题
□ AI 使用了不存在的函数或变量
□ AI 生成的代码风格与之前不一致
□ 对话超过 20 轮
□ 响应速度明显变慢
□ AI 开始出现自相矛盾的逻辑

一个实用的习惯：每完成一个”Checkpoint”（一个功能模块写完、测试通过），Cmd+N 开启新对话。把上一个对话中需要用到的关键信息，用 @ 引用文件的方式带过来。

心法：对话上下文是有限资源，珍惜每一轮。 把 Cursor 的对话当作”短期记忆”而非”项目文档”。

05 · 选错模型

症状：用轻量模型做复杂任务、或用重模型做简单任务。最常见的是在 Agent 模式下一直使用 Claude Haiku 写复杂业务代码，结果质量惨不忍睹。

为什么这是反模式
Cursor 提供了多种模型选择，各有擅长的场景：

用 Haiku 做复杂业务逻辑，你得到的是”看起来合理但一跑就炸”的代码。用 o1 改一个 CSS 颜色，你会付几倍的延迟和成本。

真实案例

场景：用 Cursor Agent 模式开发一个多层缓存的工具库
开发者选择：Haiku（因为"快"）

结果：
- 第 1 次：Haiku 生成了基本的 get/set，但没有过期逻辑
- 第 2 次：加了过期逻辑，但并发读写不安全
- 第 3 次：加了锁，但死锁了
- 第 4 次：修正了死锁，但内存泄漏
- 第 5 次...（以此类推）

切换到 Sonnet 后：一次生成，基本可用，微调两轮即通过测试

总耗时对比：
- Haiku：8 轮交互 + 1.5 小时 + 大量挫败感
- Sonnet：1 轮 + 10 分钟

另一个反面案例（选太重）：

场景：修改一行 CSS 把按钮颜色从蓝色改成红色
开发者选择：o1 mini（等待推理时间 15 秒）
实际耗时：30 秒（15 秒等待 + 5 秒审查 + 10 秒确认）
手动修改所需时间：2 秒

正确做法

• 日常开发：默认使用 Claude Sonnet
• 简单补全 / 快速问答：Haiku（Inline completion 默认就是 Haiku，合理）
• 复杂算法 / 系统设计：o1 / o3-mini
• 纯文本 / 文档：Haiku 或 GPT-4o
• 改一个颜色 / 修一个变量：手动改，不开 AI

心法：为任务选模型，而不是为习惯选模型。 Sonnet 是你最可靠的日常搭档，Haiku 是”查个资料而已别搞太正式”，o1 是”让我先想清楚再动手”。

06 · 不使用 .cursor/rules

症状：每次开启新项目，都要花大量时间让 AI 理解你的技术栈偏好、代码风格、项目结构——然后下一个项目又得重复一遍。

为什么这是反模式
.cursor/rules 是 Cursor 给 AI 的”长期记忆”。它定义了这个项目的一切规则：

• 技术栈声明（React 18? Vue 3? 用 Zustand 还是 Redux?）
• 代码风格（命名规范、文件组织方式、组件粒度）
• 架构约定（目录结构、路由模式、状态管理模式）
• 测试要求（用什么框架、覆盖率目标、mock 策略）
• API 约定（错误格式、认证方式、版本控制）

没有 rules 相当于每次让 AI”盲猜”你的喜好。同一类错误它会反复犯，同一类约定你得反复强调。

真实案例

项目 A（没有 .cursor/rules）：
- 每次新增组件，AI 都用 Class Component（开发者用 Function Component）
- 每次状态管理，AI 都用 Redux（项目用的是 Zustand）
- 每次写样式，AI 都用 CSS Modules（项目用的是 Tailwind）
- 开发者每天花 20 分钟修改 AI 的风格错误
- 项目周期 3 个月，累计浪费 ~20 小时

项目 B（有 .cursor/rules）：
- 新建对话后，AI 立刻遵循项目规范
- 风格错误减少 90%
- 提示词也从每轮"用 Tailwind + Zustand + 函数组件..."
  简化为"实现用户列表页面"

如何建立有效的 rules：

// .cursor/rules/project.mdc
---
description: 项目技术栈与编码规范
---

# 技术栈
- Framework: Next.js 14 (App Router)
- State: Zustand
- Styling: Tailwind CSS
- Data Fetching: TanStack Query
- Testing: Vitest + Testing Library

# 编码规范
- 使用 TypeScript，严格模式
- 组件使用箭头函数 + React.FC 类型标注
- CSS 类名用 kebab-case
- Git commit 前缀: feat/fix/chore/refactor/docs

# 目录结构
- /app: 页面路由（App Router 约定）
- /components: 共享组件（按特征分组）
- /lib: 工具函数和纯逻辑
- /hooks: 自定义 Hooks
- /types: 全局类型定义

// .cursor/rules/api-patterns.mdc
---
description: API 调用模式与错误处理约定
---

// 所有 API 调用遵循以下模式：
// 1. 使用 TanStack Query 的 useQuery/useMutation
// 2. 错误统一使用 AppError 类型
// 3. 成功响应格式: { data: T, message: string }
// 4. 错误响应格式: { error: { code: string, message: string } }

心法：先写 rules，再写代码。 投资 30 分钟定义 rules，后续能省几十个小时。每个项目的第一个 commit 就应该是 .cursor/rules。

07 · 不做 Diff 审查直接提交

症状：AI 生成代码 → 直接 git add . → git commit → push。从头到尾没有审查过 Cursor 到底改了哪些文件、每一行变更是否合理。

为什么这是反模式
这比”不审查 AI 更改”更危险——不审查 AI 更改至少还在 Cursor 界面内看到了 diff（虽然你可能没仔细看），但直接提交意味着：

• 你错失了最后一次”人类判断”的机会
• AI 可能修改了不应该改的文件（配置文件、环境变量、依赖声明）
• AI 可能引入了调试代码（console.log、测试 token、硬编码的 API Key）
• 你无法在团队 Code Review 时解释每一行改动的意图

真实案例

场景：修复一个登录页面的样式问题
开发者：在 Cursor 中让 AI 修复样式 → AI 生成 → Accept → 
        git add . → git commit -m "fix login page style" → git push

实际上 AI 额外做了：
1. 修改了 .env.local（添加了不存在的变量）
2. 修改了 package.json（添加了一个未使用的依赖）
3. 在 api 层添加了一个测试用的 console.log 输出敏感信息
4. 修改了登录逻辑（不仅仅是样式，还改了认证流程）

结果：代码合入后，登录功能在 staging 环境异常
排查 3 小时后发现：AI "顺便"改了一个 redirect URL

正确做法

# 提交前的强制流程
1. git diff --stat           # 先看改了哪些文件（有没有不该动的）
2. git diff                  # 逐行审查所有变更
3. 对每个增删改行问自己：   # "这是我预期的吗？"
4. 对 AI 额外修改：          # 要么理解并接受，要么 git checkout 还原
5. 只有确认无误后才提交

实用工具

• git diff --cached：审查已 staged 的变更
• Cursor 自带的 SCM 面板：可视化 diff，支持按文件逐行审查
• git diff --word-diff：对大段文本改动更清晰
• Cursor + vscode 内置 GitLens：每一行都知道是谁改的

心法：你不审查的 diff，终将在代码 review 或线上事故中被审查。 与其让别人发现你的问题，不如自己先看一遍。

08 · 把 Agent 当作万能的

症状：把光标当作全栈外包团队。让 AI 从零开发整个功能、整个模块、甚至整个项目。期待 AI 能理解你的”没说出来的需求”。

为什么这是反模式
Cursor 的 Agent 模式确实很强，但它有几个根本局限：

• 它不真正理解你的业务：它不知道你的用户是谁、你的商业模式是什么、哪些功能是核心、哪些是锦上添花
• 它没有长期记忆：一次对话结束后，它对项目的理解归零
• 它不会做架构决策：它只会选”最常见的做法”，而不是”最适合你项目的做法”
• 它不会对代码负责：出了问题，是你来修，不是 AI

真实案例

场景：一个创业团队用 Cursor Agent 开发 MVP
做法：给 Agent 一个完整的 PRD，让它从零构建整个后端

结果：
- 第 1 周：进展神速，生成了大量代码
- 第 2 周：开始出现冲突（AI 不记得之前的设计决策）
- 第 3 周：代码质量急剧下降（上下文爆了）
- 第 4 周：陷入"改 bug 引入新 bug"的死循环
- 第 5 周：不得不重写 60% 的代码

教训：AI 写代码的速度是人类的 10 倍，但制造债务的速度也是 10 倍

如果这样拆分：
- 架构设计：自己主导，AI 辅助验证
- 核心逻辑：自己写关键部分，AI 补全模板代码
- 测试：AI 写测试用例，人工 review 边界条件
- 文档：AI 生成初稿，人工补充业务上下文
→ 3 周内完成，代码质量可控

正确的人机协作分工

心法：Cursor 是你手中的剑，不是替你上战场的将军。 最强的组合是”人类的判断力 + AI 的执行力”。你负责想清楚”做什么、为什么”，AI 负责”怎么写、怎么改”。

反模式速查表

五个心法模型

把上面的反模式提炼成五个心法，贴在屏幕前：

1. 快捷键优先

能用快捷键解决的事，别让 AI 碰。F2 重命名、Cmd+D 多光标、Opt+Shift+↓ 复制行——这些肌肉记忆比 AI 快 10 倍。

2. Junior Engineer 原则

把 AI 当成一个效率极高的初级工程师。它写代码快，但你得 review。它不懂业务，你得讲清楚。它不会对结果负责，你来负责。

3. 单一职责提示

一个提示只做一件事。100 字以内的提示，执行率 90%+。500 字以上的提示，执行率不到 50%。

4. 对话有寿命

一个对话超过 20 轮就该”退休”了。新建对话的成本远低于在失效上下文里继续挣扎。每完成一个功能点就 Cmd+N。

5. 你才是架构师

AI 擅长写代码，不擅长做架构决策。目录结构、数据流设计、技术选型——这些是你的领地，别让给 AI。

总结

Cursor 是当前最强大的 AI 编程工具之一，但工具越强，用错的代价越大。这 8 种反模式的核心根源是一个问题：

你是在用 AI 增强自己的编程能力，还是在用 AI 替代自己的编程判断？

• 如果你用 AI 做你做不了的事（复杂 API 对接、不熟悉的框架、跨文件重构）——恭喜你，用对了。
• 如果你用 AI 做你本该会的事（改变量名、写简单函数、查语法）——在退化。
• 如果你用 AI 替你思考（架构设计、代码审查、需求拆解）——在制造技术债务。

正确的姿势是双向的：你的判断力在增长，AI 的执行力在增长。任何一方偷懒，另一方都补不回来。

下一篇：35 · Cursor 工作流实战 —— 从需求到上线的完整 AI 辅助工作流，涵盖需求分析、架构设计、编码实现、测试验证、Code Review 全流程。
敬请期待。

本文发布于 2026-07-03 · 字数约 4,200 字 · 觉得有用的话欢迎分享给团队