1. 一次改崩模块的复盘Cursor为什么总爱自由发挥1.1 事故现场我只是说了句优化一下先讲个真实翻车案例。上个月我接手一个老项目的维护需要修一个分页查询接口。当时抱着AI 这么强这种小活直接让它干的心态在 Cursor 里把相关代码框选起来敲了一句这个接口有点慢优化一下。Cursor 给出的结果很漂亮代码变短了命名变优雅了还加了个缓存。我心里刚冒出AI 编程真香的念头然后联调直接崩了——它把分页参数从page/pageSize改成了current/size顺手把返回结构里的total键名改成了totalCount。前端拿不到数据后端报字段不存在一个小优化搞成了事故。这事不能怪 Cursor 笨。它的核心逻辑是基于上下文预测最可能的后续内容我说优化一下它当然会朝着更规范、更好看、更通用的方向使劲。但我要的根本不是一次重构我只是想要它把查询慢的那个LIKE %xx%换成索引能命中的写法。问题出在沟通我给了一条没有任何边界的指令AI 只能自由发挥。后来我把同样一个需求换了一种说法重新发给 Cursor五分钟就改完了而且一行多余代码都没加。区别只在于指令里有没有边界。我把这两年的使用经验整理了一下发现管住 AI 写代码不自由发挥核心就是 7 条铁律。1.2 AI自由发挥的三个触发点复盘那场事故后我专门记录过一段时间看哪些时刻 Cursor 最容易自作主张。总结下来是三个触发点第一个触发点是模糊动词。优化一下改进一下提升一下看着办适当调整这类词本质上是把决策权完整交给了模型。模型不知道你的优化是省内存还是省流量不知道你的改进是改逻辑还是改风格它只能挑一个它认为最合理的方案执行。合理不等于正确这是自由发挥的第一大来源。第二个触发点是没指定作用范围。帮我把这个函数改好——这个好字到底落在哪个文件是否允许改调用方是否允许改接口签名如果这些没说Cursor 会默认你希望彻底解决问题于是它把该改的不该改的全碰了一遍。尤其是当一个函数被多个地方调用时它为了让改动自洽会顺手把底层类型、上游参数一起改掉连带一场连锁反应。第三个触发点是没定义完成标准。你心里想的是只要返回结果正确就行但 Cursor 认为正确且优雅且性能最优且顺带补了注释才算完成。它做完了还很有成就感你却要花半小时清理它多出来的杰作。这三个触发点凑在一起就会得到我那次事故的完整版本模糊的需求、不受限的范围、没有验收条件。1.3 问题的根子在沟通契约不在模型看清这三个触发点之后我的第一个想法是换更强的模型是不是就没事了。实测下来模型能力提升确实能减少低级错误但解决不了自由发挥的问题。因为在给定模糊指令的情况下越是聪明的模型越会给出一个看起来非常自洽的扩展方案。这就像带新人如果你跟一个聪明的新人说把这个活动页做一下优化得好一点他大概率会做成他认为最好的样子——灯效拉满、组件拆得细碎、数据流全部抽象一遍。你觉得这不是你想要的但他真的很委屈因为是你让他发挥的。所以问题的根子不在模型够不够聪明在于人机之间缺少一份沟通契约。Cursor 确实强在能听懂自然语言但这恰恰是陷阱你越是用闲聊语气给它下需求它越是会按自己的理解补全空白。你需要做的是反过来——把需求当成一份可执行工单来写把边界、范围、验收条件全部写清楚。我在那次事故之后给自己定了个原则凡是下发到 Cursor 的任务禁止出现优化改进随便这类没有度量标准的词凡是涉及改代码的指令必须先写明作用文件和允许改动的范围。这两点也是我要说的第一条和第二条铁律的雏形。2. 铁律一、二给每一条指令画好边界线2.1 铁律一范围必须精确到文件与函数第一条铁律很容易理解但很难做到每条改代码的指令都必须写明具体文件、具体函数、具体要改的逻辑点而不是描述一个宽泛目标。比如你要 Cursor 改分页问题最低限度的指令是打开 src/api/user.ts 里的 getUsers 函数把 SQL 查询中的全表扫描改成走索引只改这一处不要动其他函数。这比优化一下接口强一百倍。为什么因为只改这一处直接切断了它想替你做全局规划的冲动。模型在预测代码时会倾向于生成一个局部最小满足的改动当你的范围足够明确它的满足感就建立在只改这一处之上。我自己常用的写法是把允许改动区和禁止改动区都列出来。比如在 src/utils/request.ts 的 buildUrl 函数内修改 query 参数拼接逻辑。允许修改 buildUrl 函数内部的实现。禁止修改函数签名、修改调用方、修改其他函数。注意这里我特意加了禁止修改函数签名。如果不加这一条很多情况下 Cursor 会因为内部逻辑变动而顺手把参数也改了。负向指令极其有用因为它是在主动堵住模型最喜欢走的捷径。这一条刚执行时会觉得麻烦觉得我都说这么细了还不如自己写。但你坚持一星期就会发现Cursor 的产出质量和可控性完全是两个档次。把说清边界当成一种投资它省下的是你 review 代码的时间和返工成本。2.2 铁律二用任务卡替代口语化需求第一条铁律解决改哪里第二条铁律解决怎么说清楚。我的做法是不再用自然语言连续聊需求而是每次任务都填一张任务卡。任务卡长这样目标这个任务要达成的最终效果一句话讲清楚范围涉及的文件、函数以及明确禁止触碰的区域约束技术选型、性能指标、兼容性要求上下文相关的代码位置、已有函数、数据流说明验收什么样算完成可以用哪些用例验证写任务卡的过程本质上是逼自己先想清楚需求的过程。我发现自己很多次调试不顺根本不是 Cursor 写错而是我自己的需求根本是矛盾的既要兼容老接口又希望参数名改成新风格——这种需求填进任务卡的约束栏一眼就能看出冲突。任务卡怎么给到 Cursor直接贴在对话里或者写在项目根目录的TASKS.md中让它先读再改。只要上下文准确完整模型乱发挥的空间就被压到最小。我见过不少讨论 Cursor 怎么设置中文、怎么汉化、怎么安装的教程其实那些都是工具层面的问题真正拉开使用效率差距的往往是这种怎么跟它说需求的问题。2.3 可复制的任务卡模板与示例对比下面是我现在每天都在用的一套模板你可以直接抄。## 任务卡 目标修复 src/services/order.ts 中 createOrder 函数的库存扣减 bug多用户同时下单时不应出现超卖。 范围 - 涉及文件src/services/order.ts - 允许修改createOrder 函数内部的库存校验与扣减逻辑 - 禁止修改函数签名、其他文件、数据库表结构 约束 - 保持现有事务注解不变 - 不使用分布式锁优先使用数据库条件更新UPDATE ... WHERE stock count - 保持错误消息格式与现有业务一致 上下文 - createOrder 当前通过先 SELECT 后 UPDATE 的方式扣减库存并发场景下存在超卖风险 - 映射表OrderMapper.updateStock 方法已存在位于 src/mapper/OrderMapper.ts 验收 - 用两个 Mock 请求同时创建订单库存仅允许扣减一次 - 库存不足时抛业务异常异常码为 STOCK_NOT_ENOUGH - 不影响订单创建链路中其他逻辑把这段丢给 Cursor它产出的东西基本上不会跑偏。对比一下原来我那种优化一下接口的写法任务卡额外花费的时间不超过三分钟但省下的排查时间往往是半小时起步。我还特意做过一个对比实验同一个登录模块的小需求分别用帮我完善一下登录逻辑和上面的任务卡格式发给 Cursor。第一种写法它给了 120 行代码增加了 3 个自定义 hook、抽取了 1 个工具类、改了 1 个接口返回结构。第二种写法它只改动了登录表单校验分支和错误提示总共 18 行。同样一个模型输出质量的天壤之别只来源于指令形式的不同。3. 铁律三、四让AI先想清楚再动手而且只做最小改动3.1 铁律三先讲方案后写代码第三条铁律是在任何改动之前强制 Cursor 先输出问题分析 改动方案 影响面评估。等方案通过了再让它写代码。这一步表面上多了一个来回实际是把最容易自由发挥的环节从代码阶段提到了方案阶段。你在方案阶段拦住一个坏思路成本是一句话你在代码写完后再推倒重来成本是几十分钟。两者差了一个数量级。具体命令可以这样写先不要写代码。请先分析以下问题并用四段式回答 1. 问题定位目标代码当前的行为和存在的问题。 2. 改动方案你计划如何改精确到函数级别。 3. 影响面这个改动会影响哪些调用方、哪些测试用例。 4. 风险点改动可能引入什么问题以及如何规避。 方案通过之前不要输出任何代码。很多 Cursor 用户觉得这个要求多余。但我踩过一次坑一次要做环境变量读取的逻辑改造我没有要方案直接让它改它把配置读取方式从process.env改成了ConfigService封装然后为了让整个项目风格统一它顺便改了十几个文件。后来我回滚完耐心让它先给方案它自己写出来的方案反而是最小侵入保留现有读取方式只在启动时增加校验。你会发现当模型被迫用语言阐述思路时它对合理性的要求会显著提高而且你可以在它动手前就砍掉那些它本来要做的顺手优化。这个习惯对 AI Agent 类工具尤其重要。如果你平时还会用其他 AI 编程 Agent 处理复杂任务这条铁律一样适用永远先要决策再要执行。3.2 铁律四开启最小变更模式禁止顺手重构第四条铁律是让 Cursor 在执行阶段保持最小变更模式。我常用的指令是仅输出达到目标所需的最小 diff。不要重构现有结构不要格式化未修改代码不要新增与需求无关的参数不要顺手升级依赖。如果必须修改函数签名才能完成请先停下来向我说明。这条指令里最有用的部分是不要后面的内容。因为模型天生的倾向是让代码更整齐,这是它训练过程中被强化的偏好。你不明确禁止它就一定会顺手把缩进改了、把变量名统一了、把上一个开发者留下的旧风格纠正了。这些看起来无关紧要的改动恰恰是 code review 里最让人头疼的东西——它污染了 diff让真正有用的改动被淹没在格式噪音里。实际执行时我还会让 Cursor 把改动以before / after的形式列出来方便我 review。比如修 bug 时它应该告诉我原来第 45 行是这样的改成这样。这时候我会重点看它的改动是不是真的只有这些如果 diff 里混入了不相干的内容我会直接喊停。3.3 最小变更vs顺手重构对比表我们用一个实际例子来说明最小变更和顺手重构的区别。需求是修复日期格式化函数在undefined输入时抛异常的问题。维度最小变更模式自由发挥模式目标改动在formatDate函数开头加一个空值判断返回空字符串重写整个日期处理模块额外动作无改用 dayjs 替代原有原生 Date 逻辑新增依赖无package.json 新增 dayjs影响函数1 个4 个调用方连带修改Review 难度高diff 只有 3 行低但合并风险高回归成本只需跑原有用例需要全部重测我自己用最小变更模式跑了两个月最大的感受是代码 review 的体验从到处救火变成了扫一眼就过。不是代码变简单了而是 diff 变得可预期。你只关心那几行改动不用担心它偷偷重构了底层的什么结构。4. 铁律五、六把完成的标准提前到动手之前4.1 铁律五每个任务都带一份Done清单第五条铁律来源于一个现象Cursor 说改完了但实际它没达到你的预期。这不是它在撒谎而是它认为的完成和你认为的完成不是同一个概念。解决方式很简单在任务卡里加入 Done 清单用可验证的语句定义完成的标准。比如完成标准npm run test中新增的两个并发测试用例通过。库存不足时接口返回 400 和STOCK_NOT_ENOUGH。原有 15 个订单相关用例全部通过未修改任何一条既有断言。Done 清单最大的价值不是给 AI 看的是给你自己看的。当验收标准被写下来你会在下发任务时就发现需求里含糊不清的地方。比如性能优化这种目标很难写进清单你会被迫改成接口 P95 响应时间从 800ms 降低到 300ms 以下。一旦有了这个数字Cursor 也不会再给出那种看起来很专业但没有实际收益的伪优化。我通常在写完 Done 清单后会把整个任务卡从头读一遍问自己如果按这个标准完成我真的满意吗如果有一丝到时候再说的感觉说明清单还没写透。先把这个感觉消掉再发指令。4.2 铁律六一次会话只允许做一件事第六条铁律是关于任务粒度的一次 Cursor 会话、一次对话、一次任务只围绕一个目标展开。比如你今天有 3 个需求修登录 bug、加导出功能、优化首页加载速度。千万不要把这三件事塞进同一段对话里。哪怕它们都涉及同一个文件我也建议拆开做。原因有两层。第一层是上下文污染。Cursor 在对话中会同时维护所有历史信息。如果你前 20 句在聊登录 bug后 5 句突然转到导出功能模型会同时被两套上下文干扰。它很容易在实现导出功能时沿用登录模块的思路去设计状态管理然后给你来一套统一的事件分发器。你只想要一个导出按钮它给你造了一个框架。第二层是行动目标的混淆。AI 的默认策略是一次对话一个连贯动作。当你在一个会话里塞进多个目标时它不会自然地隔离这些目标而会尝试寻找它们之间的共性进而用一个统一方案解决所有问题。这恰恰是最危险的自由发挥。你犯错的概率和一次交给它的任务数量成正比。所以我现在的工作方式是每完成一个小任务就提交一次代码、清空一次 Cursor 的上下文新建会话然后再开下一个任务。很多人抱怨 Cursor越聊越笨大概率就是上下文里积累了太多跟当前任务无关的历史信息这类污染大多数是任务不纯导致的。4.3 验收前移的实际收益把 Done 清单和任务粒度结合在一起最明显的感受是返工率断崖式下降。以前让 Cursor 改个接口来回三轮是常态第一轮它写完了但没写测试你去催测试第二轮它写了测试但断言写错你又去改第三轮它发现断言需要改函数返回结构又动了主逻辑。而现在因为任务卡里提前写了不影响原返回结构它第一轮就会避开那些需要大改的路径因为 Done 清单明确写了新增两个并发测试用例它自己就知道要在主逻辑之外补上测试。与其事后一遍遍纠偏不如在需求下发的瞬间把标准说清楚。从时间账来看每次多花 3 分钟写标准换来的是至少 20 分钟的返工成本。这个杠杆太划算了。5. 铁律七立负面清单把危险动词写进项目规矩5.1 铁律七禁用模糊动词改用精确动作第七条铁律就是把导致自由发挥的危险动词列成负面清单从源头上堵死。这条看似最简单但执行起来最难因为它对抗的是你多年养成的说话习惯。我自己的危险动词清单如下你可以参考危险词为什么危险替换成优化一下没有定义什么算优将 P95 响应时间降低到 300ms 以下改进没有定义改进方向将报错提示补充为包含具体参数名重构重构的边界和兼容性未定义提取 validateInput 函数保持外部行为不变看看没有明确要看什么列出 order 模块中所有写操作的位置顺便 / 顺手最典型的自由发挥引子删除这个词如果它不该出现尽量 / 随便 / 都可以等同于放弃了你的决策权删除这个词给出唯一选择这些词只要出现在提示词里Cursor 就会把它当成可以在更大范围内行动的授权信号。反过来如果你删掉这些词改用明确动作AI 的执行路径会收敛很多。比如优化一下登录流程改成把登录表单的校验分支拆成三个独立函数分别处理账号格式、密码强度、验证码有效期效果完全不同。我还会在每条提示词末尾加上一句话如果发现需求表述含糊请先向我确认不要自行假设。这句话能拦截一批它以为你就是要这样做的情况。5.2 用.cursorrules把铁律固化到项目里如果我不用重复发这些约束而是让 Cursor 每次都记住呢可以把铁律写进项目的.cursorrules文件。这是 Cursor 原生支持的项目级规则配置放在项目根目录后每次会话都会自动加载。我项目里的.cursorrules目前长这样# Cursor 项目规则 ## 修改纪律 - 只修改用户明确指定的文件和函数。 - 禁止主动修改其他文件即使你认为应该一起改。 - 禁止修改公开函数的签名。 - 禁止格式化或重排未在任务范围内出现的代码。 ## 输出要求 - 写代码前先分析问题并列出方案等待确认。 - 默认输出最小 diff不做重构不做性能优化除非明确要求。 - 不要新增依赖。 ## 沟通要求 - 如果需求存在含糊之处必须向用户提问不要自行假设。 - 禁止使用顺手顺便优化了一下这类想法作为改动理由。 ## 完成标准 - 如果任务中包含测试要求必须运行测试并展示结果。 - 报告改动时用 before/after 形式展示。这个文件写完之后我相当于把 7 条铁律中的大部分都固化到了工具层面。之后哪怕我偶尔偷懒只用一两句话下发任务.cursorrules也会帮我把底线兜住。不过要提醒的是.cursorrules不是万能的。它就像一个公司章程员工平时会遵守但在压力大、目标多的时候可能还是会越界。所以它只能作为辅助核心还是前面几条铁律在指令层面做约束。6. 当AI还是越界时怎么紧急熔断与纠偏6.1 熔断操作先回滚再复盘别打补丁就算有了上面 6 条铁律Cursor 偶尔还是会越界。毕竟它是概率模型上下文一复杂某些规则可能就被遗忘了。这时候最关键的不是生气而是掌握熔断操作。我的第一原则是一旦发现 Cursor 改了计划外的东西立刻回滚不要试图在坏代码上打补丁。很多人的下意识是提交一个反向修复让 Cursor 把之前多改的文件改回来。这个操作看着合理实际上是在给模型叠加新任务它很可能为了修复又引入新的改动造成二次污染。正确做法是先用版本控制回滚# 放弃当前所有改动回到上一个提交 git checkout -- . # 如果已经 commit用 revert 撤销 git revert HEAD回滚之后清空 Cursor 当前会话重新用任务卡格式下一条新指令。这不是小题大做——让 AI 在脏上下文里做纠错是最容易产生连环 bug 的场景。回滚看似粗暴实际上是最短路径。6.2 用Diff Review堵住最后一道门如果回滚太频繁说明前面几道防线出了问题。所以我的第二道保险是在合入代码之前永远花两分钟看一次git diff。这一步不是走过场。每次我用 Cursor 改完代码都会先跑一下git diff --stat看总览里到底动了哪些文件。如果发现任务卡里没提到的文件出现在列表里立刻警觉。然后我会盯一下关键文件的 diff重点不是看每一行而是看有没有结构化改动——比如函数签名变了、变量名被整体替换了、导入的依赖变了。这些是隐蔽的越界改动普通逻辑 review 不一定能发现。我自己亲测的流程是git diff --stat看到统计的瞬间就能判断这一轮是否干净。如果发现异常文件被改直接回滚重来只有改动完全在预期范围内才继续深入 review 具体逻辑。把最后一关设在 diff review你就不需要时刻盯着 Cursor 的每一步动作心理负担会小很多。它自由发挥一次的成本也变高了——反正过不了 diff 这一关。7. 我现在的日常7条铁律串成一条完整工作流7.1 一个需求从开始到提交的完整链路最后分享一下我现在完整跑一个需求的标准流程。假设我要让 Cursor 给订单模块加一个按状态筛选的功能第一步我会新建一个 Cursor 会话先写任务卡。目标、范围、约束、上下文、Done 清单一次写完明确注明只改 src/pages/order/list.tsx 和 src/api/order.ts其余不动。第二步让 Cursor 先给方案不写代码。我会在方案里重点看它是否准备改接口返回结构。如果它说为了筛选需要后端接口增加 status 参数,这是合理的如果它说顺手把列表组件改成虚拟滚动,我会直接划掉要求只做筛选。第三步方案确认后让它以最小变更模式改代码。它给出 diff 后先跑git diff --stat确认改动只落在预期文件里。第四步按照 Done 清单逐项验收跑相关测试、检查类型、确认没有改动调用方。全部通过后commit 提交然后关掉这个会话再开下一个任务。这套流程跑下来单个小需求大约 10 到 15 分钟其中大头反而花在写任务卡和 review 上真正让 Cursor 写代码可能只需要两分钟。效率看似没有一句话让 AI 写百行代码那么震撼但出来的东西干净、可控、能维护是能直接进生产环境的代码。7.2 这些铁律真正改变的东西回头再看这 7 条铁律你会发现它们本质上是同一件事把人类在团队协作中最基本的沟通规范运用到了人机协作中。范围要清晰、目标要单一、方案要过审、变更要最小、标准要前置、表达要精确、越界要熔断。这些规则放在任何一位工程师带新人的场景里都是成立的。Cursor 遵从这些规则后从一个才华横溢但容易跑偏的实习生变成了一个稳重可靠的结对编程伙伴。我个人最深的体会是管住 Cursor 的核心不是限制它而是降低它理解你的难度。模型能力再强也需要交互方把话说清楚。你把信息熵降下来它的表现自然稳定。现在很多人还在争论 AI 编程到底能不能提效、能不能替代工程师我自己的答案是它能不能提效很大程度上取决于你愿不愿意先把需求边界想清楚。如果你也正在被AI 写的代码总是超出预期困扰不妨从今晚开始先禁掉优化一下这个词再用我上面的任务卡模板下一个小需求试试。大概率你会回来感谢铁律三。