上个月我让 Cursor 帮忙给订单列表加一个分页功能它很“贴心”地顺手把整个列表组件从 Options API 重构成了 Composition API还把我精心调好的 loading 状态删了。那一刻我意识到问题不在 Cursor 不够聪明而是我从来没告诉过它什么叫“够了”。在 AI 写代码这件事上Cursor 的能力边界已经够大真正拉开效率差距的是你会不会给它划边界。这篇东西不聊安装、不聊汉化就聊我在实际项目里踩坑踩出来的 7 条铁律每一条都是拿真实事故换的希望能让正在用 Cursor 写业务的你少走几个月的弯路。1. 先搞清楚 Cursor 为什么会「自由发挥」很多人第一次用 Cursor 的时候感觉像是请了一个精通全栈的高级工程师坐在旁边。你用自然语言描述需求它在几秒内改完文件、贴出 diff、甚至顺手补了测试。这种体验太顺滑了以至于你会本能地认为Cursor 是“听懂”了你的需求才动手的。但用过一段时间你就会发现它经常干出一些你觉得匪夷所思的“自作主张”。要管住它你首先得理解它为什么会这样。1.1 「自由发挥」不是 bug是 LLM 的默认行为C u r s o r 背后的 GPT/Claude 这类大模型本质上是一个“按概率续写下一个最合理的 token”的系统。你给它需求文本它并不是在执行一段明确指令而是在做一种非常高明的“文本接龙”——它根据你的描述以及在上下文里看到的所有代码、注释、历史对话推断“最可能接下来应该出现的代码内容”。换句话说它做的每一个动作在它自己的“概率模型”里都是最合理的。它并不觉得自己在自由发挥它觉得它在严格完成任务。这就带来一个核心认知你不能用“对人类下属提需求”的方式去要求它你得用“给一个聪明但缺乏常识的实习生写任务书”的方式去约束它。实习生至少知道“老板没让我改的东西不要动”而 Cursor 没有这个常识。在你的 prompt 里没有明确写“禁止改动其他文件”的那一刻起它就有概率认为“顺手重构”也是任务的一部分。1.2 三种最常见的翻车现场我把自己和身边同事的“事故报告”归纳了一下Cursor 的“自由发挥”基本逃不出这三种形态翻车类型典型表现后果越界修改只需要改一个函数它顺手改了同文件里的另一个函数或重命名了接口字段回归 bug排查极费时间过度设计你让它加个按钮它给你引入一个状态管理库还封装了一层抽象简单问题复杂化代码量膨胀遗忘约定前面说好“用 Composition API”干了一会儿它中途改用 Options API风格撕裂可维护性下降这三种问题出现的时候大多数人第一反应是骂一句“这 AI 真蠢”然后手动改回去。但你骂它没用因为它的生成逻辑是每次都是概率采样下一轮对话它已经忘了你骂过它。这就是为什么“事后纠正”永远不如“事前约束”有效——你要把规矩做成某种机制而不是指望它记住你的情绪。1.3 为什么「聊着聊着就失控」是最隐蔽的坑最隐蔽、最容易忽略的失控原因其实是会话上下文太长。Cursor 的单次对话是有上下文窗口的但当一整个会话里塞了几十轮交互早期的约束——技术栈、风格要求、禁止事项——会被后面的内容逐渐稀释。模型对上下文中间部分的内容注意力最弱这是有研究结论支撑的。你把规则写在第一轮进行了 40 轮对话后规则在上下文中被挤到了中间位置它的“记忆”已经不清晰了。所以接下来这 7 条铁律本质上全是围绕一个目标把约束前置、可见、可持续。不依赖 Cursor 的“临场发挥”而是让它在动手之前就明确知道边界在哪。2. 铁律一一个会话只允许有一件事这条铁律是我从连续三天的崩溃里提取出来的。那段时间我让 Cursor 在同一个会话里依次解决了“改接口 error message”“调表格列的宽度”“加了筛选功能”“帮我看另一个模块的 bug”。到了第四个任务时它开始对着第一个任务里已经废弃的接口结构写代码像是“失忆”了。我后来才明白一个会话里塞进来的目标越多每个目标获得的注意力就越稀薄它就越容易把 A 任务里的旧方案带到 B 任务里去。2.1 判断会话该不该“退休”的标准我现在的习惯是在任何一次对话说到一半的时候停下来问自己一个问题如果现在打断这个会话我能不能用三句话让一个新会话完整接手这件事如果不能说明会话里已经混入了太多不属于它的内容是时候开新会话了。开新会话不是承诺之前的收敛反而会让你在每个子任务上都得到“满血状态”的 Cursor。2.2 新会话怎么“交接”才不会丢失上下文很多人不开新会话是怕重新解释一遍太麻烦。其实不用全盘重述你只需要做两件事第一把旧会话里已经定稿的关键结论 / 代码路径复制到新会话的第一条消息里第二用直接引用那几个核心文件而不是把大段代码贴进来后面第 8 条会细讲。这样交接成本不超过两分钟但换来的效果是 Cursor 对当前子任务的注意力和执行力都大幅提升。2.3 我踩过的具体事故印象最深的一次我在一个会话里让它改登录模块的 token 刷新逻辑后来又在同一个会话里让它调一下仪表盘图表的颜色。它改完图表颜色之后居然“顺手”把 token 刷新逻辑里一个条件判断条件也给反转了而且完全没提。如果我不是做的 code review这个 bug 会直接带上生产环境。你别指望 AI 在长会话里做人肉记忆管理这个职责必须你来承担。3. 铁律二把规矩写进文件别靠嘴说如果你已经学会用 Cursor 写代码写了一段时间你可能会有一种感觉每次开新会话都要重复一遍“不要动其他文件”“请用 TypeScript”“不要引入新依赖”太累了。而且就算你说了它偶尔还是“记不住”。这时候你需要把那条“每天重复交代的话”变成项目里的静态文件。3.1 rules 文件到底放在哪新版 Cursor 支持在项目根目录下建.cursor/rules/目录在里面放.mdc格式的规则文件。旧版习惯是根目录放一个.cursorrules文件逻辑是一样的。无论哪个版本它的原理都是在每次会话开启 / 执行任务时把规则文件内容自动注入到模型上下文中相当于给 Cursor 戴了一个“长期记忆装置”。如果你用的是团队项目强烈建议把这个目录提交到 Git。这样每换一个新同事、每开一个新会话规则都会强制执行。这也是“机制”和“口头约束”的本质区别口头约束靠 Cursor 猜机制约束靠自动加载。3.2 一份能直接抄的规则文件模板我自己用的规则文件大致长这样你可以按项目实际情况改# 项目管理规则 ## 技术栈约定 - 前端统一使用 Vue 3 TypeScript Vite - 禁止新增图片处理相关的第三方依赖如有需要先和团队确认 - 组件命名使用 PascalCase文件名使用 kebab-case ## 代码边界 - 禁止修改 src/api/ 目录下的任何文件 - 禁止修改未在任务描述中提及的文件 - 禁止顺手重构、重命名与当前功能无关的变量或函数 ## 工作方式 - 所有修改必须先给出计划和改动文件清单等待确认后再继续 - 一次只完成一个任务每完成一个独立功能点就停下来等待确认 - 不要自动添加注释除非代码含义确实晦涩这里有一个很重要的设计原则规则文件里的每一条都必须是 AI“可检验”的。什么叫可检验“代码要写得好”这种形容词它不知道怎么执行但“禁止修改 src/api 下的所有文件”它可以对照文件路径直接判断。写规则的时候你脑子里要有一个标准“如果 Cursor 违反这条规则我能不能一眼看出来”如果能这条才有用。3.3 规则不是越多越好要定期“砍需求”规则文件写得太长也有问题——上下文里塞满规则留给实际业务代码的空间就少了。我的习惯是一条规则如果在过去一周没有触发过“拦截违规”的作用就删掉它。规则文件应该像一个严格但简洁的律师而不是一个喋喋不休的复读机。4. 铁律三任务越窄产出越稳我发现很多人的 prompt 写得像产品需求文档一个大段落在里面又是背景、又是目标、又是附加要求。这种 prompt 看起来很完整但 Cursor 会从里面“提炼”出它自认为的重点然后开始执行。你以为你说了“只需要加一个筛选按钮”它却把“筛选按钮”理解成了“优化筛选功能的整体体验”。4.1 “顺手优化”是代码事故的第一大来源说一个真实反例。我让 Cursor 在用户列表页加一个日期范围筛选它在实现过程中“顺手”把筛选组件的样式从原生 select 换成了自定义组件又顺手改了分页逻辑里的变量名。最后它交付的 diff 里和需求真正相关的改动只占 40%其他全是它觉得“这样更好”的改动。而它的“更好”并没有经过功能验证直接引入了两个边界条件的 bug。4.2 任务描述里的“边界词”怎么用后来我开始在任务描述末尾固定加一个“边界条件”块效果立竿见影。基本结构是需求在订单列表页增加“按日期筛选”功能筛选条件为下单时间。 范围仅修改 src/views/OrderList.vue 和 src/composables/useOrderFilter.ts。 禁止不要改其他任何文件不要修改订单状态字段不要新增第三方依赖不要重构现有加载逻辑。 完成标准筛选后的列表按日期倒序展示URL query 中带筛选参数。你看同样是给 Cursor 一个筛选功能第二版它几乎没有越界行为。不是因为它变聪明了而是因为我从“说人话”变成“下规格”——把所有它可能“发散”的窗口都堵死了。4.3 小技巧让 AI 先复述需求再开工还有一个我觉得特别实用的动作在任务描述最后加一句“请先用 50 字以内复述你对需求的理解确认无误后直接开始”。这是一个低成本但是极高频的“炸弹拦截器”。很多误解在它动手之前就已经可以被你发现了。我试过最离谱的一次它把“订单列表导出 CSV”理解成了“把订单列表里所有字段导出成 6 种不同格式”。如果没让它先复述那一次它大概要白干半小时。5. 铁律四先出方案再允许动手这大概是所有铁律里最“反直觉”的一条。多数人用 Cursor 的兴奋点就在于“话说完代码就出来了”如果你让它先给方案再动手感觉效率会降低。但事实上我算过一笔账让 Cursor 先输出方案通常只需要多花 30 秒但如果不做这一步它很可能一头扎进错误方向30 分钟后你才发现全跑偏了再让它重写。哪个更耗时一目了然。5.1 用一句话把 Cursor 切成“方案先行”模式在 Cursor 的 Chat 面板里新版有 Plan Mode 之类的模式切换也可以直接在 prompt 里强制要求。我常用的 prompt 是请先不要写任何代码。分析一下这个需求涉及哪些文件、每个文件需要做哪些改动、是否会影响现有接口和数据结构。输出一份改动计划包含文件清单、风险点。我确认后你再开始写。这句话说完Cursor 就会从“上来就改代码”切换成“先出一份目录和施工图”。你审核施工图的时候完全可以做到 1 分钟内判断方向对不对。方向错了就让它调整成本极低。5.2 审查方案时重点看这四个维度方案拿回来以后不要只看个寂寞。我审查计划时的关注点非常固定改动范围是否最小化如果它说需要改 8 个文件但需求明明只涉及 2 个一定要问一句“为什么另外 6 个也要动”。是否引入新依赖我遇到过它为了一句“格式化时间”就准备引入一个日期库。问它能不能用现有工具函数实现它完全能搞定。是否破坏现有对外接口特别是涉及接口层、数据库字段、组件 props 的改动必须在方案里明确标注。是否理解了数据流让它把从“数据源头”到“UI 展示”的完整链路说一遍这是检验它有没有真懂需求的最佳方式。5.3 方案审批不是走形式是人与 AI 的“对齐仪式”如果你只是让 AI 输出方案然后看也不看直接说“开始吧”那这一步就白做了。方案的价值不在那个文档而在“人机对齐”这个仪式本身。它把你脑中的预期和 Cursor 的理解放在同一张桌面上任何分歧都在动手前暴露。后续的代码生成不过是在给这份已经被验证过的计划填肉而已。6. 铁律五代码生成之后必须当面“问审”方案对完了代码也生成了很多人的反应就是“哇好快直接提交”。这是用 Cursor 最危险的一个动作。我见过太多人把这个工具当成“最终代码来源”而忽略了一个事实AI 写的代码和其他人写的代码一样需要被 review。你不 review它就是在盲飞。6.1 盲信 AI 的代价我付过做过一次很惨的让 Cursor 实现一个“文件上传进度条”功能它确实在 UI 上显示了一个进度条代码也能跑通。我以为万事大吉结果第二天客户反馈大文件上传会显示“进度到 120%”然后卡住。我打开代码才发现它直接把Math.round(percent)里的上限处理去掉了又因为小数精度问题把最终状态搞渲染乱了。这种问题如果我当时带着“怀疑”去看代码一眼就能发现。但因为“它生成的代码能跑”我就放松了审查。6.2 一句话让 AI 自证清白现在我的审查动作是强制的每次 Cursor 生成完代码我都先不跑而是先发一句“请逐条解释你这次改动的内容尤其是那些不是需求直接要求的部分理由是什么”。然后我对着 Cursor 的 diff 视图一行一行看。它讲不清楚的地方多半就是有风险的“自由发挥”。实践下来它会主动承认“这里我加了个防抖主要是怕频繁触发”这时候你就能判断这个防抖到底要不要。如果是它擅自加的直接让它删掉。6.3 我的审查追问清单下面是我几乎每次都要问 AI 的几个问题你也可以直接复制这里为什么用let而不是const这个变量后续会被重新赋值吗这个错误处理走的是什么路径异常会被吞掉吗这段代码的时间复杂度是多少如果列表数据量到 10 万条会怎样有没有哪段改动涉及公共函数或公共组件会不会影响其他调用方你有没有改掉我没让你动的代码如果有把理由列出来。这套“质问式审查”不是不信任 AI恰恰是真正把它当成一个“正在实习的同事”。你越认真 review它下一次的产出就越收敛因为审查过程中你会不断发现它没被约束住的“自由发挥”然后回到第 3 条把新见识写进 rules 文件形成一个正向循环。7. 铁律六小步提交给每次失误留后路接手大型项目的时候最恐怖的场景不是 Cursor 改错而是它一口气改完 10 个文件、改错了两处你还不知道错在哪。Git 能看 diff但 10 个文件的 diff 里夹杂着它自己的重构你根本分不清哪里是“需求的改动”哪里是“它觉得好的改动”。这时候别说追究责任你连回滚都难——因为你不知道回滚到哪个 commit 才安全。7.1 “一口气改完 10 个文件”的惨痛教训我有一回让 Cursor 实现“订单导出 CSV”的功能它特别“高效”地一次性创建了exportService.ts、OrderExport.vue、改写了useOrderList、顺带在utils里加了一个文件下载工具。跑起来倒是没报错但我 review 到第二遍才发现下载工具里用的文件名编码方式会导致中文乱码。这时候我已经没办法让它“只回滚 download 工具”因为它把所有改动都混在同一个对话里我需要手工挑出那一块单独修。7.2 把大任务拆成里程碑让 AI 分批交付现在我让 Cursor 做任何一个大于一文件的任务都会把它拆成若干个里程碑并且在 prompt 里明确要求请按以下顺序分步实施每完成一步就停下来等我确认不要一口气改完所有文件。比如说订单导出功能我会拆成第一步新增exportService.ts里的 CSV 生成函数第二步在订单列表页加导出按钮并关联该函数第三步处理中文文件名编码和下载交互。每一步它做完我看 diff、测试、提交再告诉它继续。这样做的好处是万一第三步有问题我可以只回滚第三步不影响前两步的成果。回滚的成本被压到最低。7.3 回滚不是认输是工作流的一部分很多开发者用 Cursor 翻车后第一反应是“那就手动改回来”然后花大量时间纠结在怎么修补上。我的态度是如果回滚比修补更快就毫不犹豫回滚。你让 AI 重新实现一个子任务成本远比在混乱的 diff 里做外科手术低。小步提交的核心作用就是让你随时拥有“重新来一次”的权限。8. 铁律七控制投喂的上下文防患于未然我见过最极端的用法是有人把一个有几万行代码的大型项目整个塞给 Cursor然后说“帮我看一下这段逻辑有没有 bug”。你觉得给的信息足够多它就能更懂你实际恰恰相反——它收到大量无关代码后注意力会被分散甚至被某些无关模式带偏。给它“够用但不超标”的上下文才是高效的投喂姿势。8.1 弄清 Cursor 的“参照范围”在 Cursor 的对话框里如果你不主动任何文件它主要靠当前打开的文件和你切到 Chat 面板时的焦点来推断上下文。但如果你开了 Agent 模式它会拥有更大的自主检索能力自动扫描项目里相关文件并有机会直接改文件。这个能力好用但也是“自由发挥”的最大温床。我的建议是在 Agent 模式下每一步动笔前要求它先列出“我准备读取并修改这些文件请确认”。如果它列出的文件里有几个你不认识就让它解释。把它检索范围变成可控的而不是让它整个项目里随便逛。8.2 用 精准引用而不要“全选粘贴”当你需要 Cursor 参考具体代码时直接用引用文件路径比粘贴一大段代码更精准。比如请参考 src/api/order.ts 里的接口定义在 src/views/OrderList.vue 中增加一个导出按钮。这样 Cursor 能清楚知道哪些文件是它的“输入范围”。如果它还需要查看某个类型定义它会自己用去查你再决定是否允许。整个上下文就像做一个“最小知识集”不给它多余选项它自然就没机会发散。8.3 “够用就好”三步法我自己总结了一个三步法适用于大多数日常开发第一步明确告诉它“只读哪些文件”用引用通常不超过 5-8 个文件。第二步告诉它“只改哪些文件”这个范围通常等于需求直接涉及的文件数一般 1-3 个。第三步如果调试时发现信息不够再逐步追加“你可以额外查看 xxx 文件”的许可而不是一次性全放开。这样做最大的好处是你从头到尾都知道 Cursor 看了什么、动了什么。真出了问题你也能精确还原它的“决策路径”而不是面对一片混沌。9. 七条铁律串起来一次真实任务的完整操作流讲了七条你可能会觉得有点多记不住。别急实践中的它们其实是一条丝滑的流水线。我拿最近做一个“商品列表增加库存预警状态”的需求举例完整跑一遍给你看第一步我会新建一个会话在消息开头用一两句话交代项目背景然后用引用商品列表组件、商品接口定义和状态枚举文件。背景里顺手附一句“遵守项目 rules 文件”。这对应铁律二和铁律七。第二步在需求描述里写清楚“要什么效果、范围只改哪几个文件、禁止顺手改什么”并在结尾加一句“先复述需求再给方案不要直接写代码”。这对应铁律三和铁律四。第三步它给出方案后我对着四维清单快速扫一遍重点看有没有碰我不让它碰的文件、有没有引入新依赖。确认没问题后我再说“方案可以按顺序实施每完成一个文件就停下来等我确认”。这对应铁律四和铁律六。第四步它每交付一个文件我都在 diff 面板里逐段过并用“这里为什么这样写”逼它解释。有说不清楚的要么让它改要么让它回滚重写。这对应铁律五和铁律一。整套流程走完我把最后的代码提交标准实践里git commit信息会写“feat: 商品列表增加库存预警状态Cursor 辅助生成已人工 review”。如果团队里有人后来踩到坑还能通过 commit 追溯到这是 AI 生成过的代码排查思路也会更明确。你可能会问这么多约束叠在一起用 Cursor 还有意义吗我的体验是意义更大。因为这七条铁律砍掉的不是 Cursor 的能力而是它那些“自作主张”带来的返工成本。你花在写规则、审方案、看 diff 上的时间远远少于当初处理它乱改代码带来的调试时间。安上这些约束之后Cursor 才真正从一个“话多手欠的实习生”变成了一个“靠谱但需要你盯着的同事”。它依然是效率神器只是从今往后由你来定义什么叫“够了”。