Cursor 总是改错文件，先别急着换模型。更常见的原因是上下文给错、仓库索引不完整、Rules 太泛，或者一次性让 Agent 做了过大的任务。处理这类问题要先缩小搜索范围，再把团队规则写成可执行约束。

先确认它看的代码是不是对的

同名组件、旧目录、生成文件和历史实验代码，很容易把 AI 编辑器带偏。开始前先明确目标文件、入口路径和不能动的目录。如果你知道问题来自 src/components/search，就不要只说“修搜索框”。把相关文件加入上下文，删掉无关打开标签，必要时重建项目索引。Cursor 的 官方文档把 Rules、Agent、MCP 等能力放在一起讲，实际使用时最关键的是让上下文少而准。

Rules 不要写成愿望清单

很多 Rules 失效，是因为它们写得太像口号，比如“代码要优雅”“保持架构一致”。更有效的规则应该能被检查：API 请求统一走哪个封装、哪些目录只读、组件命名怎么做、测试文件放哪里、禁止修改生成产物。Cursor 的 Rules 文档适合用来沉淀这些长期约束。

把大任务拆成两轮

当你让 Cursor 同时“重构、修 bug、补样式、加测试”，它最容易扩大改动范围。更稳的方式是第一轮只让它定位：列出候选文件和判断依据，不改代码；第二轮再允许它改 1 到 3 个文件，并要求说明为什么不碰其他文件。这个小动作能明显减少“顺手改错”的情况。

提交前看三个信号

第一，看 diff 是否集中在问题相关文件；第二，看它有没有改动配置、锁文件、生成文件；第三，看测试或运行截图是否对应你的原始问题。只要发现它绕到无关目录，先撤回那部分改动，再补充路径约束和 Rules。Cursor 不是不知道项目结构，它需要你把项目里最容易误判的地方标出来。