如果你正在用 Cursor 写代码大概率遇到过这种憋屈的场景你只想让它修一个 Bug它顺手把整个模块重写了你让它加一个新接口它把数据库字段、第三方 SDK 一并给你引了你问它改了哪些文件它列出一长串“顺手优化”的清单美其名曰符合最佳实践实际把你原来的架构设计推翻了大半。这种“自由发挥”在 AI 编程工具里太典型了。Cursor 的能力确实强强到很多时候你还没想清楚它已经把代码生成了可问题也恰恰出在这里——它越“主动”越容易越界。我过去一年在真实项目里被这种失控折腾了不少次后来总结出 7 条铁律把 Cursor 从“热情过头的实习生”调教成了“按规矩办事的协作者”。今天把完整的约束体系、话术模板和踩坑记录分享出来适合所有在用 Cursor、又不想让它把代码库搞乱的人。1. 先搞清楚 Cursor 为什么会“自由发挥”1.1 Cursor 失控的典型现场我最早用 Cursor 的时候犯过一个非常典型的错误让它“帮我把登录逻辑里的 token 校验补一下”它直接把整个 auth 模块的目录结构变了还新加了两个工具函数文件。代码能跑测试也能过但我的同事看到 diff 后一脸懵——说好的修一个点怎么多出来两百行改动这类失控不止一次。总结下来大概有这么几种常见形态范围失控只让改 A 函数它连 A 函数的调用方 B、C、D 一起改了理由是“保持调用一致性”。依赖失控明明用一个现有工具函数就能解决它偏要引入一个新包然后告诉你“这样更标准”。风格失控项目里原本是 2 空格缩进、函数式写法它按自己的偏好改成 4 空格、类封装导致整个文件的 diff 全是格式噪音。流程失控你还没确认方案它已经把代码写完你让它改完跑一下测试它说“应该没问题”。这些场景的本质不是 Cursor 智力不够而是它没有你的上下文。它不知道你的架构约束、不熟悉你的代码风格、不理解你的发布节奏它只知道“用户给了我一个目标我要尽量完整地完成它”。一个能力很强、又缺少约束的模型自然会倾向于把任务“做过头”。1.2 失控的根源模型机制与上下文窗口Cursor 底层是大型语言模型它的生成逻辑是概率性的不是编译执行式的。你给的任务越模糊它发挥的空间就越大它生成的代码越长越可能偏离你的真实意图。另一个关键因素是上下文窗口。哪怕 Cursor 在 Agent 模式下能主动读取文件、搜索代码它每次能“记住”的信息依然是有限的。对话一长早期提出约束可能就被后续内容冲淡了。我做过一个实验在一个会话里连续让它改了五个文件到第六个任务时它已经把第三条任务里的“不要改动 xxx 文件”这条要求完全忘掉了。所以指望 Cursor 自己“记住”所有约束是不现实的。你必须把规则变成显式的、可重复触发的契约在每次任务开始前重新声明或者固化到项目规则文件里让它每次读代码前先读规则。1.3 铁律的本质把隐性期待变成显式契约很多开发者对 AI 编程工具的态度是“它应该能理解我的意思”。但现实是它理解的是文本层面的意思而不是你脑子里那个包含潜台词的完整语境。你不说“不要改动文件结构”它就认为自己可以改你不说“先给出方案”它就默认可以边想边写。7 条铁律的出发点就是把这些隐性的开发习惯、工程纪律全部变成 Cursor 可执行的显式规则。每条铁律都对应一类具体的失控场景并且配套了可复制的话术和配置方法。2. 7 条铁律总览它们分别管住哪几类失控2.1 7 条铁律是针对三类乱象设计的我梳理了所有踩过的坑发现它们其实可以归纳为三类范围乱、手段乱、交付乱。7 条铁律就是围绕这三类问题设计的。范围乱对应的是“改哪、不改哪”的问题由铁律一、二、三来解决明确文件边界、先出方案、最小化改动。手段乱对应的是“怎么改”的问题由铁律四、五、六来解决给出验证方式、控制命令执行、对齐现有风格。交付乱对应的是“改完怎么交代”的问题由铁律七来解决输出变更清单、规范提交说明。这三层像三层过滤网每一层都在压缩 Cursor 的“自由发挥”空间。第一层防止它跑错方向第二层防止它在方向正确的前提下用过激的手段第三层防止它交付了但说不清楚、无法 review。2.2 铁律的落地方式Project Rules、.cursorrules 和请求内指令在 Cursor 里规则有三种落地方式我全都用过效果各异。第一种是.cursorrules 文件放在项目根目录。Cursor 会把这个文件作为项目级指令每次对话都会优先参考。我的经验是它适合放置通用性强的铁律比如“禁止自动安装依赖”“禁止重构现有代码”“所有改动必须给出测试方式”。这些规则与具体任务无关属于全局约束。第二种是Project RulesCursor 新版内置的功能可以在设置里针对当前项目配置规则支持更细粒度的路径匹配比如只对 src 目录生效。第三种是请求内指令也是我认为最可靠的一种。每发起一个新任务都在 prompt 里附带与当前任务相关的铁律。原因很简单全局规则在长对话里容易被稀释而请求内声明是每次都会参与生成的。重要任务我从来不在对话中段追加“别忘了不要改 xxx”而是直接开新会话把需求、约束、铁律一次性喂进去。2.3 优先级与区分场景不是所有项目都一视同仁需要强调的是7 条铁律不是在所有项目里都以相同权重生效的。个人试验性项目里我会放宽约束让 Cursor 自由发挥因为它可能帮我探索出意外的实现路径。生产项目、多人协作项目里7 条全开而且以最小改动、风格对齐、验证可执行这三条为最高优先级。老项目我会额外强化“禁止顺手重构”因为历史代码的脆弱性远超想象全新项目则不用太担心破坏既有结构重点是“先出方案再动手”。你可以把铁律看成一个可调节的约束框架而不是死板的教条。理解了每条铁律到底在防什么才能针对自己的场景做取舍。3. 逐条拆解7 条铁律怎么用、怎么配3.1 铁律一每次只处理我点名的文件这条最简单也最容易被忽略。很多人给 Cursor 下达任务时习惯说“帮我优化一下用户模块”这个“用户模块”在 Cursor 眼里是没有边界的——它可能会先搜索所有相关文件然后逐个修改。我现在的做法是任务下达时明确列出允许和禁止触碰的文件路径。比如背景用户登录后 token 校验失败的问题。 任务只修改 src/auth/token.ts 这一个文件定位校验失败原因并修复。 禁止修改或新增其他任何文件不需要改动 src/auth/login.ts不要重构调用逻辑。这条铁律的核心价值是让 diff 可控。你 review 代码时只需要看一个文件、一个改动点理解成本和出错概率都会大幅下降。很多人觉得这样太啰嗦但实际执行下来一个明确点名文件的任务比一个模糊任务省去了大量来回纠偏的时间。3.2 铁律二复杂改动先交方案确认后再动手这是对付“自作主张”最有效的一条。当任务涉及多个文件、影响面较大时我要求 Cursor 在写代码之前先输出方案包括涉及文件、每个文件的核心改动点、实现思路、潜在风险。比如新加一个导出功能我会这样描述需求把当前筛选结果导出为 CSV 文件。 要求先不要写代码先给出实现方案。方案中必须包含 1. 涉及哪些文件每个文件具体改动什么。 2. 导出逻辑放在哪一层为什么。 3. 如何处理大数据量下的内存问题。 4. 列出你认为的风险点以及规避方式。 等待我确认方案后再开始修改代码。为什么这条有效因为语言模型在长回答中容易出现“生成偏差”——一旦它从一开始就朝着某个方向生成代码后续很难自动纠正自己。先让它生成方案相当于把一次大的生成任务拆成两个小任务先产生计划再按计划生成代码。计划错了改计划的成本远低于改代码的成本。3.3 铁律三最小化改动禁止顺手重构与格式漂移这条主要应对“AI 式洁癖”。Cursor 经常会觉得现有代码“不够优雅”于是顺手修改变量命名、提取公共函数、把函数式改成类甚至调整整个文件的缩进风格。这些改动单看都没问题但混在一起会严重干扰 review。我把这条铁律写得非常细代码修改约束 1. 保持最小 diff。只修改任务必需的部分。 2. 禁止重命名现有变量、函数、类。 3. 禁止调整既有函数签名除非任务明确要求。 4. 禁止格式化未修改的代码区域。 5. 禁止提取公共函数、新增抽象层、变更文件结构。 6. 保持与当前文件一致的编码风格不要混用两种风格。格式化问题尤其烦人。Prettier 和 ESLint 都统一不了 AI 的“审美偏好”它总想在某个局部用不同的引号风格或者换行方式。所以我在 .cursorrules 里直接写死不要动用未被任务覆盖的代码区域一行都不要动。3.4 铁律四所有改动必须给出可执行的验证方式Cursor 生成代码后最常说的一句话是“应该没问题”。“应该”这两个字在工程里是最危险的词。我要求它每次修改都必须给出验证方案并且是具体到命令和预期结果的方案。比如它修了一个排序逻辑必须这样说运行npm test -- sort.test.ts测试用例sort by date desc应该通过或者运行curl http://localhost:3000/api/list?sortdateorderdesc返回对象数组的第一条应该是2024-05-01的记录。如果任务涉及编译和静态检查我会加一句修改完成后按顺序执行以下命令并贴出结果 1. npm run lint 2. npx tsc --noEmit 3. npm test 如果有任何一条失败先修复到全部通过再交付。这一条会显著提升 Cursor 生成的代码质量。因为它知道你会要求它执行验证它在生成时就会更谨慎减少那种“逻辑看着对但其实没跑过”的问题。3.5 铁律五装依赖和执行命令必须二次确认Cursor 的 Agent 模式有执行终端命令的能力这既是优势也是风险。它可能为了一个小功能顺手执行npm install axios甚至在你没注意的时候装了一整个工具链。我的策略是默认禁止自动执行任何命令尤其是涉及网络、安装、构建和提交类的命令。需要执行时必须先告诉我它计划执行什么命令、为什么执行、会产生什么影响等我批准后再执行。命令执行约束 1. 禁止执行 npm install / pip install / go get 等安装命令。 2. 禁止执行 git add / git commit / git push 等 git 命令。 3. 禁止执行删除文件、修改配置文件等不可逆操作。 4. 如需执行任何命令先列出完整命令和预期效果等待用户确认。依赖安装这件事值得单独强调。很多 AI 生成的代码会“习惯性”地引入新依赖但有些功能用现有依赖就能实现。我在实际项目里发现AI 大概有三分之一的情况会选择安装新包而其实项目里已经有类似的工具函数了。强制二次确认之后这三分之一里的大多数都被拦了下来代码库的依赖膨胀速度明显下降。3.6 铁律六代码风格向现有工程看齐而不是“最佳实践”Cursor 自带的最佳实践偏好有时候是灾难。它倾向于生成教科书风格的代码但真实项目往往是历史演化出来的有自己的约定和妥协。你让 AI 写的新代码跟旧代码风格不一致整个文件读起来就像两段拼接的补丁。我的做法是在任务开始时给 Cursor 指定一个“风格参考文件”。比如写代码前先阅读 src/services/userService.ts模仿它的命名习惯、注释方式、错误处理写法。 新代码必须与现有文件保持一致不要引入新的编码模式。 如果现有代码风格与最佳实践冲突优先遵循现有风格。这条铁律的效果非常明显。它会抑制 Cursor 那种“我要给你展示一个更好的写法”的冲动让它在既有框架里做增量。代码库的一致性本质上是可维护性的底线AI 不遵守的话Review 的人会很痛苦。3.7 铁律七交付必须附带变更清单与提交说明最后一条是关于交付。Cursor 完成一次任务后我会要求它输出一份简化版的变更报告格式固定如下## 变更清单 - 文件src/auth/token.ts 变更点修复 token 过期时间判断逻辑使用 Math.floor 消除毫秒误差 - 文件src/auth/__tests__/token.test.ts 变更点新增过期时间边界测试用例 ## 验证结果 - npm test -- auth通过5 个用例全部成功 - npm run lint通过 ## 风险说明 - token 解析逻辑的返回类型从 number 改为 string已同步调整类型定义这个清单的价值在于它强迫 Cursor 对自己产出的内容做一次回顾和梳理。很多模型在生成代码时是“局部到局部”并没有一个全局的自我检查环节。要求它输出变更清单等于在生成之后增加了一次自我 review。同时你拿到清单后可以快速判断它是否触碰了不该碰的地方节省大量的 review 时间。如果涉及 git 操作我会让它提供 commit message 建议而不是直接提交。这样既能保持提交信息的规范性又不会失去我的控制权。4. 套用铁律后的实战记录一个小需求从失控到可控4.1 同一个需求约束前后的对比拿一个实际改过的需求来做对比。需求是“给列表接口增加按创建时间倒序排序”。约束前我给 Cursor 的指令是“帮我把列表接口改成按创建时间倒序。”它做了什么它修改了 controller 层的排序参数处理顺带重构了 service 层的查询函数把原来的queryAll拆成了queryAll和queryPage还改了三个测试文件的数据结构。整个 diff 超过 300 行其中真正与排序相关的只有 5 行。约束后我给 Cursor 的指令变成需求list 接口新增按创建时间倒序排序。 涉及文件src/controller/list.ts、src/service/list.ts。 约束只允许修改这两个文件保持现有函数签名排序逻辑放在 service 层禁止格式化未改动的代码修改后执行 npm test 并贴出结果。结果非常干净两个文件一共改了 12 行测试通过review 在 3 分钟内完成。同样的需求约束前耗时要半天大部分花在理清它的改动上约束后只需要 20 分钟。这是我坚持这套规则最重要的理由省下来的不是生成时间而是理解时间。4.2 我把 7 条铁律写进 .cursorrules 的实际配置分享一下我目前在生产项目里使用的 .cursorrules 核心片段可以直接复制去用你是一个遵守工程纪律的资深开发者。在修改代码时必须遵守以下规则 ## 任务范围 - 只修改用户明确指定的文件禁止扩大影响范围。 - 如果任务涉及的文件边界不清晰先向用户确认而不是自行猜测。 ## 方案先行 - 复杂任务涉及 3 个以上文件、或影响公共逻辑必须先给出实现方案。 - 方案应包括涉及文件、变更点、实现思路、风险等待用户确认后再写代码。 ## 最小化改动 - 保持最小 diff不修改与任务无关的代码。 - 禁止重命名变量/函数/类禁止改变函数签名禁止调整文件格式。 - 新代码风格必须与当前文件中已有代码保持一致不要引入新的模式。 ## 验证要求 - 完成修改后必须给出验证方式和执行结果。 - 如果项目有测试必须运行受影响模块的测试并贴出结果。 ## 命令与依赖 - 禁止自动执行安装命令如需安装新依赖必须先说明理由并等待批准。 - 禁止自动执行 git 提交、推送、删除等不可逆命令。 ## 交付说明 - 完成时输出变更清单文件、变更点、验证结果、风险。这段配置的关键不是“字多”而是每一条都对应了一个我在真实项目中踩过的坑。写的时候尽量用否定句因为模型对“禁止做什么”的理解往往比“应该做什么”更强。4.3 没有完全覆盖到的“漏网之鱼”即便有了这套铁律我也遇到过它“钻空子”的情况。最典型的一类是它在遵循“最小改动”的同时把新逻辑写得过份复杂——为了不改动一个错误处理分支它在调用方额外套了三个 if 判断代码虽然没动旧逻辑但新逻辑的复杂度反而更高了。这类问题靠规则文本很难完全解决因为它是一种理解层面的偏差。我的补救方式是code review 时多留 10 分钟专门审视新增代码的复杂度遇到这种情况直接在回复里点明“这个 if 可以合并到原来分支里”让它在下次生成时参考修正。铁律不是一劳永逸而是持续互动的结果。5. 常见问题与排查手记5.1 规则写了但 Cursor 还是不听怎么办这是被问得最多的一个问题。我的排查顺序是这样的先确认规则是否渗透到了任务上下文里。如果你把规则写在 .cursorrules但当前会话是一个历史很长的对话早期内容已经占满了上下文规则很可能被截断。解决办法是新任务开新会话在新会话里重新声明关键约束。再确认是不是模式选择问题。Cursor 的 Agent 模式比普通 Chat 模式更激进自动执行的意愿更强。如果任务不需要多文件搜索和自动编辑我会用普通对话模式加 apply 按钮而不是一上来就用 Agent。最后确认是不是规则本身太模糊。“保持代码质量”这种话是无效规则“禁止新增第三个以上嵌套 if”才是可执行的描述。规则越具体模型越容易遵守。5.2 铁律太多会不会拖慢 AI 的产出速度确实会而且这是真实存在的代价。我现在的感受是约束带来的速度损失会被 review 效率提升完全覆盖。一个不守规矩的 AI 生成 100 行代码只要 30 秒但你要花两个小时去理解、调整、修复它引入的问题。一个遵守铁律的 AI 可能要多花 1 分钟做方案和整理清单但它的 30 行代码你 5 分钟就能看完并合并。所以我对速度的态度是让 AI 慢一点让自己快起来。如果要追求速度我会在小型、独立的探索性任务上关闭部分规则在核心业务代码上铁律一条都不少。5.3 Cursor 版本更新后规则失效怎么排查Cursor 迭代很快规则机制和模型行为都可能随版本变化。我遇到过几次 .cursorrules 优先级降低的情况表现为“之前遵守得很好某次更新后开始无视规则”。排查方法先看版本更新日志确认规则是否有相关的机制调整然后做一个最小复现——用一个只涉及一条铁律的小任务测试比如故意让它改一个明确禁止改的文件看它是否越界如果越界检查规则文件的格式是否仍然被正确加载必要时把关键约束同时写进 Project Rules形成双保险。还有一个细节新版本的模型可能对旧格式的指令理解变弱偶尔需要把规则的措辞改得更直白比如把“请遵守项目规范”改成“你必须1. 不修改除指定文件外的任何内容2. ……”这种强迫句。最后再分享一点个人体会。我之所以费这么大力气去约束 Cursor是因为我太清楚“看起来很快”和“真的可控”之间的区别了。AI 生成代码的速度越快代码库的状态就越取决于你定义规则的能力。那 7 条铁律本质上是把我和团队多年积累的工程习惯翻译成了模型能听懂的语言。这个翻译不是一次完成的而是每次踩坑后继续往里面补条款的持续过程。你不需要一次性把 7 条全部上齐先挑最近让你最头疼的两三条试试用起来、调一调慢慢就会形成你自己的版本。 
长河君 · 2026/9/8 4:51:24 · 阅读 1.2k 约束Cursor的7条铁律：让AI编程从失控到可控
如果你正在用 Cursor 写代码大概率遇到过这种憋屈的场景你只想让它修一个 Bug它顺手把整个模块重写了你让它加一个新接口它把数据库字段、第三方 SDK 一并给你引了你问它改了哪些文件它列出一长串“顺手优化”的清单美其名曰符合最佳实践实际把你原来的架构设计推翻了大半。这种“自由发挥”在 AI 编程工具里太典型了。Cursor 的能力确实强强到很多时候你还没想清楚它已经把代码生成了可问题也恰恰出在这里——它越“主动”越容易越界。我过去一年在真实项目里被这种失控折腾了不少次后来总结出 7 条铁律把 Cursor 从“热情过头的实习生”调教成了“按规矩办事的协作者”。今天把完整的约束体系、话术模板和踩坑记录分享出来适合所有在用 Cursor、又不想让它把代码库搞乱的人。1. 先搞清楚 Cursor 为什么会“自由发挥”1.1 Cursor 失控的典型现场我最早用 Cursor 的时候犯过一个非常典型的错误让它“帮我把登录逻辑里的 token 校验补一下”它直接把整个 auth 模块的目录结构变了还新加了两个工具函数文件。代码能跑测试也能过但我的同事看到 diff 后一脸懵——说好的修一个点怎么多出来两百行改动这类失控不止一次。总结下来大概有这么几种常见形态范围失控只让改 A 函数它连 A 函数的调用方 B、C、D 一起改了理由是“保持调用一致性”。依赖失控明明用一个现有工具函数就能解决它偏要引入一个新包然后告诉你“这样更标准”。风格失控项目里原本是 2 空格缩进、函数式写法它按自己的偏好改成 4 空格、类封装导致整个文件的 diff 全是格式噪音。流程失控你还没确认方案它已经把代码写完你让它改完跑一下测试它说“应该没问题”。这些场景的本质不是 Cursor 智力不够而是它没有你的上下文。它不知道你的架构约束、不熟悉你的代码风格、不理解你的发布节奏它只知道“用户给了我一个目标我要尽量完整地完成它”。一个能力很强、又缺少约束的模型自然会倾向于把任务“做过头”。1.2 失控的根源模型机制与上下文窗口Cursor 底层是大型语言模型它的生成逻辑是概率性的不是编译执行式的。你给的任务越模糊它发挥的空间就越大它生成的代码越长越可能偏离你的真实意图。另一个关键因素是上下文窗口。哪怕 Cursor 在 Agent 模式下能主动读取文件、搜索代码它每次能“记住”的信息依然是有限的。对话一长早期提出约束可能就被后续内容冲淡了。我做过一个实验在一个会话里连续让它改了五个文件到第六个任务时它已经把第三条任务里的“不要改动 xxx 文件”这条要求完全忘掉了。所以指望 Cursor 自己“记住”所有约束是不现实的。你必须把规则变成显式的、可重复触发的契约在每次任务开始前重新声明或者固化到项目规则文件里让它每次读代码前先读规则。1.3 铁律的本质把隐性期待变成显式契约很多开发者对 AI 编程工具的态度是“它应该能理解我的意思”。但现实是它理解的是文本层面的意思而不是你脑子里那个包含潜台词的完整语境。你不说“不要改动文件结构”它就认为自己可以改你不说“先给出方案”它就默认可以边想边写。7 条铁律的出发点就是把这些隐性的开发习惯、工程纪律全部变成 Cursor 可执行的显式规则。每条铁律都对应一类具体的失控场景并且配套了可复制的话术和配置方法。2. 7 条铁律总览它们分别管住哪几类失控2.1 7 条铁律是针对三类乱象设计的我梳理了所有踩过的坑发现它们其实可以归纳为三类范围乱、手段乱、交付乱。7 条铁律就是围绕这三类问题设计的。范围乱对应的是“改哪、不改哪”的问题由铁律一、二、三来解决明确文件边界、先出方案、最小化改动。手段乱对应的是“怎么改”的问题由铁律四、五、六来解决给出验证方式、控制命令执行、对齐现有风格。交付乱对应的是“改完怎么交代”的问题由铁律七来解决输出变更清单、规范提交说明。这三层像三层过滤网每一层都在压缩 Cursor 的“自由发挥”空间。第一层防止它跑错方向第二层防止它在方向正确的前提下用过激的手段第三层防止它交付了但说不清楚、无法 review。2.2 铁律的落地方式Project Rules、.cursorrules 和请求内指令在 Cursor 里规则有三种落地方式我全都用过效果各异。第一种是.cursorrules 文件放在项目根目录。Cursor 会把这个文件作为项目级指令每次对话都会优先参考。我的经验是它适合放置通用性强的铁律比如“禁止自动安装依赖”“禁止重构现有代码”“所有改动必须给出测试方式”。这些规则与具体任务无关属于全局约束。第二种是Project RulesCursor 新版内置的功能可以在设置里针对当前项目配置规则支持更细粒度的路径匹配比如只对 src 目录生效。第三种是请求内指令也是我认为最可靠的一种。每发起一个新任务都在 prompt 里附带与当前任务相关的铁律。原因很简单全局规则在长对话里容易被稀释而请求内声明是每次都会参与生成的。重要任务我从来不在对话中段追加“别忘了不要改 xxx”而是直接开新会话把需求、约束、铁律一次性喂进去。2.3 优先级与区分场景不是所有项目都一视同仁需要强调的是7 条铁律不是在所有项目里都以相同权重生效的。个人试验性项目里我会放宽约束让 Cursor 自由发挥因为它可能帮我探索出意外的实现路径。生产项目、多人协作项目里7 条全开而且以最小改动、风格对齐、验证可执行这三条为最高优先级。老项目我会额外强化“禁止顺手重构”因为历史代码的脆弱性远超想象全新项目则不用太担心破坏既有结构重点是“先出方案再动手”。你可以把铁律看成一个可调节的约束框架而不是死板的教条。理解了每条铁律到底在防什么才能针对自己的场景做取舍。3. 逐条拆解7 条铁律怎么用、怎么配3.1 铁律一每次只处理我点名的文件这条最简单也最容易被忽略。很多人给 Cursor 下达任务时习惯说“帮我优化一下用户模块”这个“用户模块”在 Cursor 眼里是没有边界的——它可能会先搜索所有相关文件然后逐个修改。我现在的做法是任务下达时明确列出允许和禁止触碰的文件路径。比如背景用户登录后 token 校验失败的问题。 任务只修改 src/auth/token.ts 这一个文件定位校验失败原因并修复。 禁止修改或新增其他任何文件不需要改动 src/auth/login.ts不要重构调用逻辑。这条铁律的核心价值是让 diff 可控。你 review 代码时只需要看一个文件、一个改动点理解成本和出错概率都会大幅下降。很多人觉得这样太啰嗦但实际执行下来一个明确点名文件的任务比一个模糊任务省去了大量来回纠偏的时间。3.2 铁律二复杂改动先交方案确认后再动手这是对付“自作主张”最有效的一条。当任务涉及多个文件、影响面较大时我要求 Cursor 在写代码之前先输出方案包括涉及文件、每个文件的核心改动点、实现思路、潜在风险。比如新加一个导出功能我会这样描述需求把当前筛选结果导出为 CSV 文件。 要求先不要写代码先给出实现方案。方案中必须包含 1. 涉及哪些文件每个文件具体改动什么。 2. 导出逻辑放在哪一层为什么。 3. 如何处理大数据量下的内存问题。 4. 列出你认为的风险点以及规避方式。 等待我确认方案后再开始修改代码。为什么这条有效因为语言模型在长回答中容易出现“生成偏差”——一旦它从一开始就朝着某个方向生成代码后续很难自动纠正自己。先让它生成方案相当于把一次大的生成任务拆成两个小任务先产生计划再按计划生成代码。计划错了改计划的成本远低于改代码的成本。3.3 铁律三最小化改动禁止顺手重构与格式漂移这条主要应对“AI 式洁癖”。Cursor 经常会觉得现有代码“不够优雅”于是顺手修改变量命名、提取公共函数、把函数式改成类甚至调整整个文件的缩进风格。这些改动单看都没问题但混在一起会严重干扰 review。我把这条铁律写得非常细代码修改约束 1. 保持最小 diff。只修改任务必需的部分。 2. 禁止重命名现有变量、函数、类。 3. 禁止调整既有函数签名除非任务明确要求。 4. 禁止格式化未修改的代码区域。 5. 禁止提取公共函数、新增抽象层、变更文件结构。 6. 保持与当前文件一致的编码风格不要混用两种风格。格式化问题尤其烦人。Prettier 和 ESLint 都统一不了 AI 的“审美偏好”它总想在某个局部用不同的引号风格或者换行方式。所以我在 .cursorrules 里直接写死不要动用未被任务覆盖的代码区域一行都不要动。3.4 铁律四所有改动必须给出可执行的验证方式Cursor 生成代码后最常说的一句话是“应该没问题”。“应该”这两个字在工程里是最危险的词。我要求它每次修改都必须给出验证方案并且是具体到命令和预期结果的方案。比如它修了一个排序逻辑必须这样说运行npm test -- sort.test.ts测试用例sort by date desc应该通过或者运行curl http://localhost:3000/api/list?sortdateorderdesc返回对象数组的第一条应该是2024-05-01的记录。如果任务涉及编译和静态检查我会加一句修改完成后按顺序执行以下命令并贴出结果 1. npm run lint 2. npx tsc --noEmit 3. npm test 如果有任何一条失败先修复到全部通过再交付。这一条会显著提升 Cursor 生成的代码质量。因为它知道你会要求它执行验证它在生成时就会更谨慎减少那种“逻辑看着对但其实没跑过”的问题。3.5 铁律五装依赖和执行命令必须二次确认Cursor 的 Agent 模式有执行终端命令的能力这既是优势也是风险。它可能为了一个小功能顺手执行npm install axios甚至在你没注意的时候装了一整个工具链。我的策略是默认禁止自动执行任何命令尤其是涉及网络、安装、构建和提交类的命令。需要执行时必须先告诉我它计划执行什么命令、为什么执行、会产生什么影响等我批准后再执行。命令执行约束 1. 禁止执行 npm install / pip install / go get 等安装命令。 2. 禁止执行 git add / git commit / git push 等 git 命令。 3. 禁止执行删除文件、修改配置文件等不可逆操作。 4. 如需执行任何命令先列出完整命令和预期效果等待用户确认。依赖安装这件事值得单独强调。很多 AI 生成的代码会“习惯性”地引入新依赖但有些功能用现有依赖就能实现。我在实际项目里发现AI 大概有三分之一的情况会选择安装新包而其实项目里已经有类似的工具函数了。强制二次确认之后这三分之一里的大多数都被拦了下来代码库的依赖膨胀速度明显下降。3.6 铁律六代码风格向现有工程看齐而不是“最佳实践”Cursor 自带的最佳实践偏好有时候是灾难。它倾向于生成教科书风格的代码但真实项目往往是历史演化出来的有自己的约定和妥协。你让 AI 写的新代码跟旧代码风格不一致整个文件读起来就像两段拼接的补丁。我的做法是在任务开始时给 Cursor 指定一个“风格参考文件”。比如写代码前先阅读 src/services/userService.ts模仿它的命名习惯、注释方式、错误处理写法。 新代码必须与现有文件保持一致不要引入新的编码模式。 如果现有代码风格与最佳实践冲突优先遵循现有风格。这条铁律的效果非常明显。它会抑制 Cursor 那种“我要给你展示一个更好的写法”的冲动让它在既有框架里做增量。代码库的一致性本质上是可维护性的底线AI 不遵守的话Review 的人会很痛苦。3.7 铁律七交付必须附带变更清单与提交说明最后一条是关于交付。Cursor 完成一次任务后我会要求它输出一份简化版的变更报告格式固定如下## 变更清单 - 文件src/auth/token.ts 变更点修复 token 过期时间判断逻辑使用 Math.floor 消除毫秒误差 - 文件src/auth/__tests__/token.test.ts 变更点新增过期时间边界测试用例 ## 验证结果 - npm test -- auth通过5 个用例全部成功 - npm run lint通过 ## 风险说明 - token 解析逻辑的返回类型从 number 改为 string已同步调整类型定义这个清单的价值在于它强迫 Cursor 对自己产出的内容做一次回顾和梳理。很多模型在生成代码时是“局部到局部”并没有一个全局的自我检查环节。要求它输出变更清单等于在生成之后增加了一次自我 review。同时你拿到清单后可以快速判断它是否触碰了不该碰的地方节省大量的 review 时间。如果涉及 git 操作我会让它提供 commit message 建议而不是直接提交。这样既能保持提交信息的规范性又不会失去我的控制权。4. 套用铁律后的实战记录一个小需求从失控到可控4.1 同一个需求约束前后的对比拿一个实际改过的需求来做对比。需求是“给列表接口增加按创建时间倒序排序”。约束前我给 Cursor 的指令是“帮我把列表接口改成按创建时间倒序。”它做了什么它修改了 controller 层的排序参数处理顺带重构了 service 层的查询函数把原来的queryAll拆成了queryAll和queryPage还改了三个测试文件的数据结构。整个 diff 超过 300 行其中真正与排序相关的只有 5 行。约束后我给 Cursor 的指令变成需求list 接口新增按创建时间倒序排序。 涉及文件src/controller/list.ts、src/service/list.ts。 约束只允许修改这两个文件保持现有函数签名排序逻辑放在 service 层禁止格式化未改动的代码修改后执行 npm test 并贴出结果。结果非常干净两个文件一共改了 12 行测试通过review 在 3 分钟内完成。同样的需求约束前耗时要半天大部分花在理清它的改动上约束后只需要 20 分钟。这是我坚持这套规则最重要的理由省下来的不是生成时间而是理解时间。4.2 我把 7 条铁律写进 .cursorrules 的实际配置分享一下我目前在生产项目里使用的 .cursorrules 核心片段可以直接复制去用你是一个遵守工程纪律的资深开发者。在修改代码时必须遵守以下规则 ## 任务范围 - 只修改用户明确指定的文件禁止扩大影响范围。 - 如果任务涉及的文件边界不清晰先向用户确认而不是自行猜测。 ## 方案先行 - 复杂任务涉及 3 个以上文件、或影响公共逻辑必须先给出实现方案。 - 方案应包括涉及文件、变更点、实现思路、风险等待用户确认后再写代码。 ## 最小化改动 - 保持最小 diff不修改与任务无关的代码。 - 禁止重命名变量/函数/类禁止改变函数签名禁止调整文件格式。 - 新代码风格必须与当前文件中已有代码保持一致不要引入新的模式。 ## 验证要求 - 完成修改后必须给出验证方式和执行结果。 - 如果项目有测试必须运行受影响模块的测试并贴出结果。 ## 命令与依赖 - 禁止自动执行安装命令如需安装新依赖必须先说明理由并等待批准。 - 禁止自动执行 git 提交、推送、删除等不可逆命令。 ## 交付说明 - 完成时输出变更清单文件、变更点、验证结果、风险。这段配置的关键不是“字多”而是每一条都对应了一个我在真实项目中踩过的坑。写的时候尽量用否定句因为模型对“禁止做什么”的理解往往比“应该做什么”更强。4.3 没有完全覆盖到的“漏网之鱼”即便有了这套铁律我也遇到过它“钻空子”的情况。最典型的一类是它在遵循“最小改动”的同时把新逻辑写得过份复杂——为了不改动一个错误处理分支它在调用方额外套了三个 if 判断代码虽然没动旧逻辑但新逻辑的复杂度反而更高了。这类问题靠规则文本很难完全解决因为它是一种理解层面的偏差。我的补救方式是code review 时多留 10 分钟专门审视新增代码的复杂度遇到这种情况直接在回复里点明“这个 if 可以合并到原来分支里”让它在下次生成时参考修正。铁律不是一劳永逸而是持续互动的结果。5. 常见问题与排查手记5.1 规则写了但 Cursor 还是不听怎么办这是被问得最多的一个问题。我的排查顺序是这样的先确认规则是否渗透到了任务上下文里。如果你把规则写在 .cursorrules但当前会话是一个历史很长的对话早期内容已经占满了上下文规则很可能被截断。解决办法是新任务开新会话在新会话里重新声明关键约束。再确认是不是模式选择问题。Cursor 的 Agent 模式比普通 Chat 模式更激进自动执行的意愿更强。如果任务不需要多文件搜索和自动编辑我会用普通对话模式加 apply 按钮而不是一上来就用 Agent。最后确认是不是规则本身太模糊。“保持代码质量”这种话是无效规则“禁止新增第三个以上嵌套 if”才是可执行的描述。规则越具体模型越容易遵守。5.2 铁律太多会不会拖慢 AI 的产出速度确实会而且这是真实存在的代价。我现在的感受是约束带来的速度损失会被 review 效率提升完全覆盖。一个不守规矩的 AI 生成 100 行代码只要 30 秒但你要花两个小时去理解、调整、修复它引入的问题。一个遵守铁律的 AI 可能要多花 1 分钟做方案和整理清单但它的 30 行代码你 5 分钟就能看完并合并。所以我对速度的态度是让 AI 慢一点让自己快起来。如果要追求速度我会在小型、独立的探索性任务上关闭部分规则在核心业务代码上铁律一条都不少。5.3 Cursor 版本更新后规则失效怎么排查Cursor 迭代很快规则机制和模型行为都可能随版本变化。我遇到过几次 .cursorrules 优先级降低的情况表现为“之前遵守得很好某次更新后开始无视规则”。排查方法先看版本更新日志确认规则是否有相关的机制调整然后做一个最小复现——用一个只涉及一条铁律的小任务测试比如故意让它改一个明确禁止改的文件看它是否越界如果越界检查规则文件的格式是否仍然被正确加载必要时把关键约束同时写进 Project Rules形成双保险。还有一个细节新版本的模型可能对旧格式的指令理解变弱偶尔需要把规则的措辞改得更直白比如把“请遵守项目规范”改成“你必须1. 不修改除指定文件外的任何内容2. ……”这种强迫句。最后再分享一点个人体会。我之所以费这么大力气去约束 Cursor是因为我太清楚“看起来很快”和“真的可控”之间的区别了。AI 生成代码的速度越快代码库的状态就越取决于你定义规则的能力。那 7 条铁律本质上是把我和团队多年积累的工程习惯翻译成了模型能听懂的语言。这个翻译不是一次完成的而是每次踩坑后继续往里面补条款的持续过程。你不需要一次性把 7 条全部上齐先挑最近让你最头疼的两三条试试用起来、调一调慢慢就会形成你自己的版本。