常见卡点与解法

Cursor 用顺手以后，你会发现卡点不一定来自“AI 不够聪明”。更多时候是任务边界、上下文、权限和项目状态没有管住。

这一页不讲高级技巧，只讲你在真实项目里很快会遇到的几类问题。遇到时先别急着换模型，也别连续发“继续修”，先判断问题属于哪一类。

AI 说理解了，但生成结果完全偏了

最常见的表现是：你让它改登录页，它顺手重写了注册页；你让它优化查询，它改成了另一个数据库访问方式；你说“美化一下”，它把组件结构和样式体系都换了。

这种情况通常不是一句“你理解错了”能解决的。先把偏差说具体：

你刚才的修改偏离了我的目标。

我需要的是：
- 只调整 LoginForm 的表单校验
- 保留现有样式和组件结构
- 不改注册页、不改 auth service

请先撤回或重新生成这次修改里超出范围的部分，然后只处理校验逻辑。

如果你还没接受 diff，直接拒绝这次修改更干净。然后重新发任务，把范围写窄：

@src/components/LoginForm.tsx

只修改这个文件里的校验逻辑。
邮箱必须是合法格式，密码不少于 8 位。
不要改 UI 文案，不要调整 CSS class，不要修改其他文件。

我自己的经验是，越是小任务，越要说“不改什么”。小任务最怕 AI 把它理解成一次顺手整理。

Agent 改了一堆不该改的文件

Agent 模式会自己探索文件、决定修改路径，这正是它强的地方，也是风险来源。你让它加一个搜索框，它可能同时改状态管理、组件拆分、测试配置，还顺手格式化了一批文件。

第一步不是继续让它解释，而是看 diff。先确认几件事：

• 哪些文件是任务必须改的
• 哪些文件只是格式化或重排
• 有没有删除、重命名、迁移这类高风险操作
• 生成的测试是否真的覆盖了这次行为变化

如果改动还没接受，拒绝超范围文件，再让它基于剩余范围继续。如果已经落到工作区，优先用版本控制查看差异，不要凭记忆手动删。

下次发 Agent 任务时，可以先要求它报计划：

我要给待办列表加搜索功能。

请先只分析，不要改文件。
输出你计划修改的文件列表，以及每个文件为什么需要改。
等我确认后再执行。

对于新功能，我一般会先让 Agent “列计划”，再让它动手。多花一分钟，能少很多清理 diff 的时间。

不知道什么时候该切模型

模型切换不需要神秘化。把它当成成本和可靠性的取舍就够了。

简单补全、改文案、补类型、小范围样式调整，用速度快、成本低的模型通常够用。涉及多文件重构、复杂 bug 定位、项目结构判断、数据库或鉴权逻辑时，换更强的模型更稳。

一个实用判断是：如果任务失败一次只是浪费几十秒，可以用快模型；如果失败一次会产生一堆难审的 diff，应该用更强的模型。

比如下面这种任务，不适合只图快：

帮我把订单模块从直接调用数据库改成 service + repository 分层。
要求接口行为不变，现有测试要继续通过。
请先解释现有调用链，再给迁移计划。

它需要理解结构、保持兼容、控制改动范围。模型能力不够时，常见结果是“看起来重构了”，但细节断掉。

上下文超限或上下文变脏

上下文超限不一定会弹出一个明确错误。你可能看到这些信号：

• AI 开始忽略你刚刚贴的约束
• 它反复引用很早之前的任务
• 回答变得泛泛而谈，不再贴合当前文件
• 它说要修改某个已经不相关的模块

这时候继续补充说明，效果通常有限。更好的做法是收缩任务，甚至新开对话：

我们重置一下任务。

当前只处理这个 bug：
@src/api/users.ts
@src/lib/db.ts

问题：GET /api/users 在用户为空时返回 500。
目标：返回空数组，并保留现有响应格式。
不要处理分页、权限、代码风格问题。

如果一个聊天里已经做过规划、重构、修 bug、写文档，后面再让它做精确修改，很容易被旧上下文影响。新开一轮，把必要文件重新引用，往往更快。

项目越做越乱

Cursor 不会自动替你保持项目整洁。项目变乱通常有几个来源：每次任务都“顺手优化”、Rules 写得太空、长期不看 diff、没有把已确认的结构沉淀到文档或规则里。

可以从一个小动作开始整理：每完成一个功能，问 AI 一次“这次改动有没有偏离现有结构”。比如：

请 review 这次改动：
- 是否新增了不必要的抽象
- 是否有文件放错目录
- 是否有和现有命名风格不一致的地方
- 只指出问题，不要直接修改

如果你发现同一种混乱反复出现，比如 API 请求散落在组件里，就把它写进 Rules：

不要在 React 组件中直接调用 fetch。
请求逻辑放在 `src/lib/api/`，组件只调用封装后的函数或 hook。

卡点并不可怕。真正需要警惕的是你每次都靠“再让 AI 修一下”往前推，却不处理上下文、边界和项目约定。

常见卡点与解法

Cursor 用起来顺的时候很快，卡住的时候也会让人怀疑是不是自己不会用。问题通常不在“AI 不行”，而在任务边界、上下文、模式选择或项目状态没有处理好。

这页不讲大原则，直接按问题说处理方式。

AI 说理解了，但生成结果完全偏了

这种情况常见于任务描述太像愿望。

帮我优化这个页面，让它更好用。

AI 可能会改样式、拆组件、改交互，也可能加一堆你不需要的状态管理。它不是故意乱改，而是“更好用”没有可验证的边界。

处理方式是把偏差转成具体约束：

刚才的方向偏了。
我这次只想解决两个问题：
1. 表单提交后按钮要进入 loading 状态
2. 提交失败时显示接口返回的错误信息

不要调整布局，不要重命名组件，不要改路由。
相关文件是 @src/pages/Login.tsx 和 @src/api/auth.ts。

如果已经生成了不满意的 diff，先不要继续让它在错误结果上修。拒绝这次修改，重新给更窄的任务范围，通常比让它“改回来”更干净。

Agent 改了一堆不该改的文件

Agent 模式会自己搜索、规划和改文件。任务越大，它越可能把“顺手整理”也当成工作的一部分。

开始前就要限制范围：

只允许修改：
- @src/components/ProfileForm.tsx
- @src/lib/validators.ts

不要改样式文件，不要改接口层，不要重构无关代码。
完成后请列出实际修改过的文件。

如果它已经改多了，第一步不是继续聊天，而是看 diff。把不相关文件拒绝掉，只保留确实需要的改动。Git 工作区干净时更容易处理；如果你准备让 Agent 做较大任务，最好先确认当前没有一堆未提交的手工改动混在一起。

下次再交给 Agent 时，把任务拆小。比如不要说“重构用户中心”，改成“先只把 ProfileForm 的表单校验抽到 validators，不改 UI”。AI 的自主空间越小，误伤越少。

不知道什么时候切换模型

模型切换不用神秘化。你可以按任务风险来选。

小任务，比如补一个类型、改文案、解释一段简单代码，用较快的模型就够了。你要的是响应速度，不是长时间推理。

复杂任务，比如跨多个文件查 bug、设计模块边界、重构旧代码、判断安全风险，值得换成更强的模型。它慢一点，但更能处理上下文和取舍。

一个实用判断是：如果任务失败一次会让你花很多时间收拾，就用更强的模型；如果失败了只需要撤销一小段 diff，可以先用快模型试。

不要在同一个混乱对话里频繁切模型。模型变了，但脏上下文还在。遇到多轮偏航，先缩小上下文或新开对话，再考虑模型。

上下文超限或回答开始变散

上下文太长时，不一定会明确报错。更常见的信号是：

• AI 忘了你刚刚强调的限制
• 它开始复述旧任务
• 回答越来越泛
• 修改时漏掉关键文件

处理方式是压缩任务，不是继续补更多材料。

可以这样重开：

我们重新开始这个问题。
当前目标：修复订单列表分页错误。

只参考这些材料：
@src/pages/orders/index.tsx
@src/hooks/useOrders.ts
@src/api/orders.ts

已知现象：切到第 2 页后仍然显示第 1 页数据。
请先定位原因，不要直接改代码。

如果前面对话里已经有有用结论，把结论整理成 5 行以内带过去。不要把整段聊天复制进去。

项目越做越乱，Cursor 也越来越乱

当项目里有一堆临时文件、半成品组件、过期 Rules 和未清理的聊天上下文，Cursor 的输出会跟着变乱。它会参考你项目里的坏例子，也会把旧约定当成当前约定。

先检查三件事：

• Rules 里有没有过期内容
• 项目里有没有多个相似实现，让 AI 不知道该学哪个
• 当前工作区是不是混着多个任务的未完成改动

比如你同时有 UserCard.tsx、UserCardNew.tsx、UserCardCopy.tsx，再让 AI “参考用户卡片写一个团队卡片”，它选错参考对象并不奇怪。

解决办法不一定是大重构。先给项目一个最小秩序：

这次只参考 @src/components/UserCard.tsx，忽略 UserCardNew 和 UserCardCopy。
请按 UserCard 的 props 组织方式实现 TeamCard。
不要顺手清理旧文件。

等功能稳定后，再单独开任务清理重复文件。不要把“继续做功能”和“整理项目垃圾”混在同一个 Agent 任务里。

Cursor 的卡点多数都能从一个问题开始定位：它这次看到的东西，和你脑子里真正想让它看到的东西，是不是同一批？