我见过太多人骂 Cursor 是个“人工智障”生成的代码跑不通改了一处别的地方崩了有时候还一本正经地给你编造一个根本不存在的 API。但你问他怎么用的十有八九都是一股脑把需求往对话框里一扔然后等着奇迹发生。先交代一下背景。我日常主力编辑器已经切到 Cursor 大半年了早期踩过的坑一点不比你们少。后来我慢慢摸清楚了一件事AI 写代码失控大部分时候不是模型不行是你没有给它划定边界。它像一头嗅觉灵敏但没什么纪律性的猎犬你不给它绳子它就满山跑。所以我把过去几个月实践中真正管用的方法沉淀成了 7 条铁律。用上之后AI 生成代码的返工率肉眼可见地降下来了我不用再像个监工一样时刻盯它的每一行输出。这篇文章不聊那些花里胡哨的提示词技巧就聊我实际每天都在用的 7 条规矩。每条规矩我都会讲清楚背后的逻辑给你可以直接抄的模板顺便告诉你哪些地方容易翻车。适合所有觉得 AI 写代码“不听话”的人尤其是刚上手 Cursor、还没建立起自己协作节奏的开发者。1. 先从根上理解AI 为什么会“自由发挥”想管住 Cursor得先搞清楚它为什么会失控。这不是什么玄学问题本质上就是上下文管理与约束条件失效。1.1 大模型的工作方式决定了它必须“猜”Cursor 底层的模型就像那种很聪明但有点过度自信的实习生。你给它一个需求它会根据它见过的海量代码模式去预测你大概率想要什么。问题就在于“大概率”不等于“就是”。你只说了“把用户列表做成分页”它可以猜你是想要前端分页、后端分页、游标分页还是滚动加载。每个方向写的代码完全不一样它只能赌一个。如果你不告诉它边界在哪它就只能自由发挥。这个情况在技术圈里有个专业说法叫“幻觉”。AI 会一本正经地生成一个根本不存在的函数参数或者把一个已经被废弃的 API 写得像模像样。因为它不是在查文档它是在做基于概率的文本生成。它不知道那个 API 已经改了它只知道那段代码在训练数据里看起来非常合理。这就是为什么你经常会看到 Cursor 自信满满地给你写出一个session.query(User).all()而你用的明明是 SQLAlchemy 2.x 的新语法。1.2 越大的上下文越容易“捡了芝麻丢西瓜”还有个特别反直觉的坑当你的项目变得很大的时候你给 Cursor 塞进去的资料越多它反而越容易出错。原因也很直接现在的模型虽然有很长的上下文窗口但注意力机制天然会更关注开头和结尾的内容。你的需求藏在第 30 个文件之后它可能只记住了前面的几个文件直接把你的核心要求给漏了。我有一次让它重构一个支付模块它参考了项目里另一个完全不相关的日志模块的代码风格给我生成了一堆完全不着调的东西。不是它笨是它在那么多文件里根本分不清哪个是核心约束。所以核心原则第一条就出来了信息不是越多越好关键是给对、给精。1.3 你要管的是“输入”和“验收”不是“过程”想明白上面两点你就会意识到一个残酷的事实你不可能靠“盯着代码”来管住 AI。它生成代码的过程对你是不可见的你盯得再紧也没用。你能做的是两件事控制它读什么、写什么以及事后严格验收。这就是“铁律”思想的本质。我所有的规矩都是围绕这两个环节设计的。2. 铁律一只喂“刚好够用”的上下文别把整个项目塞给它很多人用 Cursor 的第一步就错了按下Cmd Enter把整个项目索引都加进对话里然后跟 AI 说“帮我重构一下”。这不是在帮 AI这是在害 AI。你以为给了它全部信息它就能做出最优决策实际上它只会在大海里捞针。2.1 建立“最小上下文”意识我把这个原则叫“最小上下文”——刚好够 AI 理解当前任务所需的信息量多一份不要少一份不行。比如你要改一个用户注册接口你得给它看的是这个接口的当前实现、路由定义、数据模型。最多再加一个调用方的示例让它搞清楚数据是怎么被消费的。别给它看整个 service 层更别让它看那些跟当前任务八竿子打不着的工具函数。实操的时候我通常用 Cursor 的file引用功能把要改的文件加进来而不是把整个文件夹拖进去。这个操作看起来简单但很多人没意识到背后的威力。当你主动选择文件的时候你其实是在帮 AI 做第一轮信息筛选——你已经告诉它“任务相关的代码就这些别东张西望”。这比任何提示词都管用。2.2 在项目根部维护一个 AGENTS.md 或者 CLARIFY.md建议你在项目根目录放一个AGENTS.md用几句话描述项目的技术栈、目录结构、编码规范和常用的构建命令。Cursor 会自动读取这个文件作为全局约束。这相当于给 AI 立了一份“员工手册”它每次进项目都会先读一遍。你可以写清楚“本项目使用 TypeScript 严格模式禁止 any”、“后端接口统一走 /api/v1 前缀”、“不要修改 migrations 目录下的历史文件”。不用写很多几条关键的就行重点是让它有据可依。这个文件最值钱的地方在于它把那些你大概率会在每次对话里重复叮嘱的内容做了一次性固化。你以后跟 Cursor 对话就不用每次都说“记得用 pnpm 啊”这种废话了省下来的精力可以干点更有意义的事。2.3 上下文失控时的紧急制动还有一种情况得单独提醒一下聊着聊着你发现 Cursor 开始答非所问了或者它引用的代码根本不是当前版本甚至引用了项目里不存在的文件。这时候别犹豫最简单的处理方式是新建一个对话重新整理上下文。别试图在同一个已经乱掉的对话里把它“救回来”这个成本远高于重新开一局。当然新建对话也意味着你要把刚才的上下文再喂一遍。这时候AGENTS.md的价值就更明显了——你开新对话之后只要引用相关文件它读一下全局规则就立刻回到状态不用从头解释一遍背景。3. 铁律二把大象装进冰箱一次只让 AI 做一件小事AI 写代码最让人血压飙升的场景是什么你让它“帮我实现一个完整的购物车功能”它咔咔给你生成八百行代码各种状态管理、缓存策略、异常处理全给你安排上了。你以为赚到了结果一跑全是 bug而且你不知道从哪开始查——因为代码根本不是你写的你对它的内部逻辑一无所知。别把 Cursor 当成一个能一口吞掉大象的巨蟒它就是一只胃口有限的鸟你得把食物切成它能吞下的小块。3.1 任务分解的正确姿势我现在会把一个功能拆成多个原子级别的任务每个任务只做一件事。比如“购物车功能”我会拆成第一步定义购物车的 TypeScript 接口和数据库模型第二步实现添加商品到购物车的服务端接口第三步实现删除购物车商品的服务端接口第四步用 React Query 封装前端的购物车状态第五步在结算页接入购物车数据实现数量增减交互每一步做完我都要跑一下测试或者手动验证确认没问题再进入下一步。这样即使某一环节出了问题我也能立刻定位。你们可以算一笔账一次性让 AI 生成一个完整功能看起来省事但一旦代码行数超过几百行出错率是指数级上升的。拆成了十个小任务每个任务之间是独立的就算其中一个失败了其余的部分还是可以用的。3.2 任务粒度参考标准我个人的经验是一个任务的预期改动量最好控制在 50 行以内。超过这个量AI 出错的概率就开始明显抬高。不是说 AI 写不了长代码而是它很难在长代码里保持前后一致。变量命名、状态传递、边界条件……它很容易写到后面忘了前面。用工程领域的一句话就是模块化设计。你让 AI 生成的代码越模块化它的可维护性和正确率就越高。因为每个模块之间是松耦合的就算它的实现方式跟你想的不一样你也能轻松地把它替换掉。3.3 配套利器Todo List 任务清单Cursor 在 Agent 模式里自带一个 Todo List 功能你可以让它先把任务拆成一个清单然后逐项执行。我会主动要求它把工作计划列出来确认无误后再让它动手。这样做有两个好处第一逼它先想清楚再动手第二你可以在它开始前修正计划的方向避免它一头扎进错误的方案里。我在实际使用中还会让 Todo List 里的每一项对应一个具体的文件或模块。完成一项就划掉一项进度一目了然。如果某项任务卡住了我也可以明确告诉它“只重做这一项其他保持不动”不至于连带破坏掉已完成的部分。4. 铁律三把规则写进 .cursorrules别指望 AI 记住你的口头要求我见过很多人明明在对话里说过“用 UTC 时间存储”过一会儿 AI 又给写了一个new Date()直接塞进数据库。你骂它不听话但换个角度想对话上下文那么长它早就忘了你十分钟前那句轻描淡写的交代。这时候你就需要一个“仪式化”的载体来固化规则.cursorrules就是干这个的。4.1 .cursorrules 到底是什么.cursorrules是放在项目根目录或者全局用户目录下的一个规则文件里面写的是你希望 AI 在代码生成时始终遵守的规范。它和AGENTS.md有点类似但侧重点不同。AGENTS.md更像项目说明文档而.cursorrules则更像“编程风格与约束条例”。两者可以共存前者描述“项目是什么”后者定义“代码应该怎么写”。我的.cursorrules文件里一般会包含这几类内容技术栈约束必须使用 pnpmReact 版本是 18样式方案用 Tailwind 3命名规范组件使用 PascalCase方法使用 camelCase常量使用 UPPER_SNAKE_CASE禁止事项禁止使用 any禁止在 useEffect 里直接写异步请求禁止修改公共类型定义常用模式错误处理统一走 error-boundary日期处理一律使用 dayjs4.2 写规则的两大原则写这个文件也要把握分寸。第一规则要尽量具体可执行不要写“写出高质量的代码”这种废话AI 不知道什么是高质量。你要写的是“函数超过 80 行必须拆分”、“禁止使用嵌套三元表达式”这种有明确判断标准的规则。第二规则数量要克制别搞成一本五百页的规范手册。经验是控制在 20 条以内超过这个量AI 的注意力会被分散该遵守的反而可能被忽略。我之前踩过一个坑我在.cursorrules里写了“禁止在服务端组件中使用浏览器 API”但因为我没说明项目里哪些是服务端组件AI 还是照样把window对象往代码里怼。后来我补了一句“前端目录 app 下的所有组件默认是服务端组件除非文件开头标注 use client”它才终于不再犯傻。所以规则一定要跟项目实际情况绑定不能写成放之四海而皆准的空话。4.3 全局规则 vs 项目规则Cursor 支持全局规则也就是你所有项目都会生效的规则。我建议把那些跨项目通用的个人偏好放全局比如“注释使用中文代码使用英文命名”、“禁止使用 await 循环改用 Promise.all”。而把跟具体技术栈强相关的内容放项目级.cursorrules里。这样切换项目的时候规则也能无缝切换不会把上一个项目的规范带到新的项目里产生冲突。有一个细节得注意.cursorrules对已有的对话不生效。你修改完规则文件之后必须新建一个对话AI 才会重新加载最新的规则。如果你在旧对话里继续聊它用的还是旧规则这也是很多人觉得规则文件没用的原因之一——不是没用是你没用对时机。5. 铁律四给足“锚点”让 AI 先读关键代码再动手Cursor 最让人头疼的一种行为是你让它改 A 模块它却把不相关的地方全重构了一遍。你以为它在帮你优化实际上它是在“自由发挥”。这种问题的根源在于你没有给 AI 足够的“参照物”。它不知道你项目的代码风格长什么样不知道你习惯怎么写它就按照自己脑子里的模板来。5.1 先模仿再创造我现在的习惯是让 AI 动手之前先指定一个或多个“锚点文件”。所谓锚点文件就是项目中具备代表性的、风格规范、结构清晰的代码我让 Cursor 先读一下这些文件模仿它们的写法去实现新功能。这相当于给 AI 一份“字帖”让它照着练字而不是自己独创一种字体。举个例子我要让 AI 在这个项目里新增一个订单列表页面。我不会直接说“帮我写一个订单页面”而是说“参考 src/pages/user-list/index.tsx 的写法新建一个订单列表页面数据结构换成订单模型表格列换成订单相关字段”。它照着写出来的东西大概率跟项目里的现有代码高度一致从命名到布局到组件拆分方式都像同一个开发者写出来的。5.2 关键文件的锁定与保护除了给锚点还得学会锁文件。Cursor 的 Agent 模式会扫描整个项目然后自作主张地修改它认为相关的文件。这很危险。我会在对话里明确告诉它“本次只允许修改这几个文件其他文件一律禁止改动。”你也可以在.cursorrules里设置全局保护名单比如所有的 buid 配置文件、CI/CD 脚本都属于“只读禁区”。有一次我让它做性能优化它直接把next.config.js给改了加了一堆缓存策略。结果我根本不知道它改了配置直到部署之后发现 CDN 缓存异常排查了一下午才发现是这个文件被动过。从那以后我就把所有配置文件都列入了保护名单。你管住了它动文件的手就断掉了它“自由发挥”最大的源头。5.3 用 diff 模式逐行审查Cursor 在生成代码的时候会展示一个 diff 视图让你逐个文件查看改动内容。很多人嫌麻烦直接点了 Accept All这正是失控的入口。你至少得花三十秒扫一遍每个文件的改动范围确认它没有改超出任务范围的东西。尤其是当你看到它突然新建了好几个额外文件的时候基本可以确定它又跑偏了直接 Reject 掉让它重新来。我个人的习惯是所有改动必须经过 diff 审查才能合入。哪怕是我自己写的代码提交之前也要过一遍 diff。这不是效率低下这是职业习惯。你把 AI 当成一个协作者它写的代码就是别人提交的 PR你不能不 review 就直接合并到主干。6. 铁律五设置“安全围栏”——构建、测试、格式检查一个都不能少不管你把上下文控制得多好AI 还是可能生成语法错误、类型错误或者跑不通的代码。这几乎无法避免。所以你需要一套自动化的“安全围栏”让那些低级错误根本不至于流到你的工作区。6.1 让 AI 在生成代码后必须自测在指令里强制要求 AI 完成代码之后执行验证命令。比如它会跑pnpm type-check、pnpm lint、pnpm test等等。我会明确告诉它“代码实现完成后运行类型检查命令如果有报错修复后再返回结果”。这件事价值极大能帮你过滤掉八成以上的低级错误。不过要注意一个坑Cursor 执行命令的时候有时候输出它是看不懂的或者它会过早地停止等待输出。我的经验是给命令加上-- --no-watch之类的参数确保它跑的是单次检查而不是持续监听模式。另外如果项目里有专门的make check或npm run check这种一键命令建议优先使用因为把多个检查串起来可以降低它遗漏某项检查的概率。6.2 测试就是 AI 的“刹车片”如果你希望 AI 能放心大胆地重构前提就是你有一层测试能兜底。有了测试AI 重构完之后你直接跑一遍测试通过就合并不通过就打回去。这比人工盯着代码靠谱多了。我强烈建议你先把关键路径的测试补齐了再放开手脚用 AI 写代码。我见过有人在没有测试的情况下让 AI 重构整个服务端结果线上直接 502。后来它们长记性了先花了一周把核心链路用测试覆盖起来再让 AI 去碰那坨老代码。这就是工程顺序的区别。测试不是用来测 AI 的是用来自救的。6.3 强制格式化确保代码风格统一AI 生成的代码风格可能跟你的 Prettier 配置不一致这会导致提交时的代码格式混乱。你可以在.cursorrules里规定“生成代码后必须运行 pnpm run format”也可以依赖提交阶段的 lint-staged 自动格式化。我更推荐后者——让格式化成为 git 提交流程的一部分不管谁来提交代码都要先过格式这一关这样你的代码库风格永远是统一的。7. 铁律六建立“后来居上”的追责机制——Git 是你的后悔药即使前面几条铁律都执行到位了AI 还是有可能给你埋下一个隐蔽的坑——比如它把一个函数改成等价但性能更差的写法或者无意中破坏了一个边界用例。这时候你最大的底气不是它的代码写得有多好而是你能随时回到上一个稳定版本。7.1 每次 AI 动手之前先分出一个干净的基线我的习惯是每次让 Cursor 动手术之前先把当前工作区整理干净确保没有未提交的改动。然后 checkout 一个新分支比如feature/ai-cart-refactor在这个分支上跟 AI 协作。这样做的好处是不管 AI 改成什么样你都可以随时切回主分支那里永远有一个稳定的版本。有人可能会觉得这太麻烦了但你们算一笔账万一 AI 把项目搞得一团糟你在主分支直接开发的成本远高于多建一个分支的成本。这个分支成本几乎为零但它是你的后悔药尤其适合做激进重构的时候。没有后悔药你就只能眼睁睁看着项目的花洒被 AI 拧下来。7.2 用 Git 做“分卡回滚”还有一个小技巧当 AI 在一个会话里完成了多个文件的修改而你想把其中某一个文件恢复到修改前的状态可以用git checkout -- file精确回退单个文件。或者用git diff看一遍改动结合git restore做局部还原。Git 的细粒度控制能力是普通代码编辑器完全提供不了的所以趁早习惯命令行操作为好。如果 AI 已经提交了一堆 commit而你想整体的退回去就先git log --oneline找到你动手之前的那个 commit然后git reset --hard回去。眼神不好的话建议用git reflog找回历史别被 reset 后“丢失”的提交吓到。7.3 每次提交信息写清楚省的以后猜AI 提交代码的时候通常会自动生成 commit message但是这些 message 往往太含糊了比如fix bug或者update code。前期看还好等两周之后你回头看 log完全不知道这个 commit 干了什么。我一般会要求 AI 提交时遵循固定的格式type(scope): description比如feat(cart): implement delete cart item API。这属于规范化的老生常谈但和 AI 协作时格外重要——因为 AI 生成的代码你不会每一行都记得commit message 就是你日后检索这些代码的方法。8. 铁律七让 AI 先“说”再做强制它生成计划最后这条铁律我的私心认为是最能提升 AI 可控性的一条。它很简单在让 AI 动手写任何代码之前强制要求它先输出一份完整的实施计划。这个计划里要包含它准备改哪些文件、每个文件做什么改动、改动涉及哪些依赖、有没有潜在风险。8.1 计划先行避免闷头乱搞你可能会觉得多此一举但实际上这一步的价值超乎想象。因为当 AI 需要把它的思路用文字写出来的时候它其实是把内部推理过程外显化了。你会立刻看到它有没有误解你的需求有没有计划外的想法。如果它有你可以在它动手之前纠正——这个纠错成本远比它写完了你再去改低得多。我之前让 Cursor 实现一个文件上传功能它在计划里写了一句“将使用 S3 作为存储并使用预签名 URL 直传”。但项目的现状是文件先上传到本地服务器再由后端统一迁到 OSS。如果我不要求它先给计划它可能就直接按照 S3 那套思路写了完了以后整个上传流程跟我预期完全不同。所以我看到计划的第一时间就打断了它重新说明了现状它才回到正确的路线上来。8.2 计划的表述规范我会让 AI 用具体动词来描述计划里的每一个动作比如“修改src/api/upload.ts新增uploadFile函数”、“在pages/upload/index.tsx插入文件解析逻辑”。尽量不要让它写“优化上传性能”这种含糊其辞的计划项。你看到哪一步不对直接说“这一步不要”它就会立刻调整方案。有一个常见痛点有些 AI Agent 在输出计划之后直接开干根本不给你审查的时间。这时候可以在指令里加一句“先不执行只把计划发给我我确认后你再继续”。执行力强的 Agent 就会停下来等待你的指令。同理你也可以在确认计划的时候顺便提一句“不要修改任何文件等我确认”。8.3 把计划变成你的“施工蓝图”最终你手里那份经过确认的计划就是你跟 AI 之间的“合同”。后续如果它偏离了计划你直接指着计划说“你答应的不是这样”。这时候对话记录里那份计划就是证据既是对 AI 的约束也是你审视最终结果的标准。你不再是一个被动的旁观者而是拥有全程掌控权的甲方。9. 避坑指南高级用法里的那些隐性陷阱铁律说完了最后再分享几个我用 Cursor 的过程中不那么容易察觉但危害很大的坑希望能帮你少走几个月的弯路。9.1 “偷看”其他文件导致的游走Cursor 的 Agent 模式下AI 为了达成任务会主动搜索项目里的相关文件。这个行为是一把双刃剑它确实能帮你找到一些关键代码但它也会找到一些并不该看的文件并因此改变实现方式。比如你让它改前端组件它突然翻到了后端接口定义然后自作主张地把前端调用的接口地址改了——它觉得它是在帮你对齐实际上它破坏了一个本该由后端保证的接口协议。解决方案就是在指令里把边界划死。明确告诉它“你只能在src/frontend目录下寻找与任务直接相关的文件禁止读取src/api目录下的类型定义”。如果它真的需要跨目录的信息让它先问你而不是自己查。9.2 多文件改动下的“连锁崩坏”AI 改 A 文件的时候需要引用 B 文件里的某个函数但它怎么知道 B 文件里那个函数的签名在改之前是什么现实情况是它经常自己脑补。这种连锁引用的崩溃在 AI 一次改动超过一个文件的时候非常容易爆发。我的经验是尽量让 AI 在一个会话内只处理单一文件如果确实涉及多文件就按文件依赖顺序一个一个地改而不是并行改。9.3 提示词泄露与公共模型的风险Cursor 的提示词泄露这个事在社区里传得很广。意思是你放在.cursorrules和对话里的内容理论上可能会被发送给模型服务商甚至被用于模型训练。如果你在代码里写了密钥或者内部敏感信息是有相当风险的。解决方案就是永远不要把任何敏感密钥或者不可公开的业务逻辑写进.cursorrules更不要在对话里粘贴生产环境的配置。另外如果你用的是 Cursor 的免费版或者个人版建议把“隐私模式”打开让 Cursor 不要用你的数据做训练至少求个心安。9.4 Cursor 的“免费额度续杯”幻觉很多刚上手的人会被 Cursor 的免费额度吸引用完了就换号或者找人代充。说实话这类操作又烦又有隐藏风险账号被限流不说还有可能遇到“too many computers used within the last 24 hours for the same cursor account”这种提示一天之内动不动就无法启动。你要是真的想长期用还是自己评估一下付费账本如果只是偶尔体验与其天天琢磨额度问题不如把它当一个正常工具用省下折腾的时间多写点好代码。10. 一次实战拆解多语言工具类重构铁律说再多不如看一次完整实战。我拿最近做的一个小工具类重构来演示一下这些铁律是怎么组合使用的。10.1 任务背景与初始状态我要重构的是一个处理时间字符串的工具模块它最初的实现里混合了 UTC 和本地时间导致后端存储的时间格式混乱。整个项目是基于 Node.js 和 TypeScript 的。在最开始我把相关文件锁定并且准备好了该模块的单元测试确保重构前后行为一致。10.2 对话步骤实录我打开 Cursor提供了一个明确的指令“你现在要重构src/utils/time.ts现状是混合使用了 UTC 和本地时间出现了时区不一致的问题。先用几句话说明重构计划不要动手。项目规则见根目录.cursorrules。”Cursor 很快就返回了一项简洁的计划统一使用 dayjs 的 UTC 插件、时间存储统一走 ISO8601 UTC 格式、移除本地时间的直接引用、更新相关的测试用例。我确认了计划然后补充了一句“开始执行但只允许修改src/utils/time.ts、tests/time.test.ts和package.json如果必要不要动其他文件。”它改完代码后我让他跑类型检查和测试反馈回来两处类型错误它自己尝试修复了一处另外一处问我是否要将某个函数签名保持兼容。我给了明确答复它顺利通过测试。我用 diff 审查了一下改动发现整体符合预期就直接合并进了主分支。这几个步骤看起来平淡无奇但里面每一步都踩在铁律上最小上下文、任务拆解、规则文件、锚点、安全围栏、Git 分支、计划先行。全部组合起来之后AI 基本上没有给我带来意外的“惊喜”。10.3 结果分析这个重构任务如果换做我自己手动写恐怕得花一个小时。用这套铁律协作我大概只花了十五分钟。而且我全程没有出现那种提心吊胆的感觉因为每一步的风险都被提前锁住了。11. 常见问题排查速查表最后整理了一张速查表覆盖了我在使用过程中遇到的典型情况以及对应的处理方式。现象可能原因排查方法解决办法AI 修改了不在任务范围内的文件上下文过大Agent 主动探索查看 diff 里的文件列表在指令里锁定允许修改的文件清单生成的代码风格跟项目不一致缺少锚点文件检查是否指定了参考文件提供同类模块的现有实现作为锚点提示词在对话中途失效上下文过长注意力漂移观察是否从某一步开始跑偏新建对话把规则文件重新加载测试通过但线上有 bug测试覆盖不足补充边界用例把关键路径的测试补齐再让 AI 重构AI 引用不存在的 API训练数据过时/幻觉查看生成的 import 路径让它先运行类型检查修复后再返回Cursor 提示账号设备限制设备数量超过官方策略换回常用设备别频繁在机器之间切换认准主设备生成的代码改了配置文件未设置保护名单查看 config 类文件的 diff把配置文件加入.cursorrules的非临时保护区我的个人感受是用 Cursor 写代码这件事本质上是你和 AI 之间的一场协作谈判。你越早建立起自己的规则库越早把工程化的思维引入对话AI 就越能发挥正常的水平。它不是魔法它只是一台功率很高的发动机你要做的是给它铺好路而不是指望它自己越野翻山。最后再分享一个小技巧如果你刚开始用这 7 条铁律不要一次性全部铺开很可能会手忙脚乱。先挑一条你觉得最痛的点用起来。比如你常常被 AI 乱改文件搞崩溃那先把“锁定文件清单”用上。等这一条变成肌肉记忆再下一条。慢慢地你会在某一天突然发现原来不是 Cursor 乱来是我以前没教会它怎么好好干活。