Cursor 升级到 3 之后我第一时间就切过去当主力编辑器了。如果你还只把它当成一个带补全的记事本那确实有点浪费——真正拉开效率差距的不是某个“神秘按钮”而是你怎么组织任务、怎么写提示词、怎么设置验证回路。这篇文章把我用 Cursor 3 跑了两个月的核心打法整理成 6 大最佳实践覆盖从上下文管理、任务拆分到代码回滚和测试验收的完整链路适合正在用 AI 写代码、但总觉得生成质量不稳定的开发者参考。1. 先用懂版本变化再谈最佳实践1.1 Cursor 3 到底变了什么Cursor 3 这一代最明显的变化不是界面变好看而是它从一个“输入提示词、输出代码片段”的工具变成了一个能自己读文件、改项目、跑命令、看报错并继续迭代的 Agent。这个转变听起来简单实际上改变了整个使用逻辑以前你是“逐行喂指令”现在你更像是在“带一个实习生”只需要把目标说清楚再给它必要的边界和反馈。我在实际使用中的感受是3.x 版本里有几个能力值得认真对待多模型切换更顺滑同一个问题可以快速换不同模型对比不用来回复制粘帖。Agent 模式会在一个会话里反复读文件、修改、执行命令错误信息会被自动带回到上下文里。规则文件.cursor/rules可以固定项目级约束比每次口头强调要可靠得多。Checkpoint 机制能对 AI 的改动做快照改乱了可以快速回滚。这些能力单独拿出来都不算“颠覆”但组合起来完全可以把一个人的小项目开发节奏提上去一大截。前提是你得知道怎么用。1.2 最佳实践不是功能堆砌而是工作流控制很多人拿到新工具的第一反应是把所有功能都用一遍但“会用”和“用好”是两回事。我总结这 6 条实践时反复在问自己一个问题它究竟在解决什么不确定性上下文不完整导致 AI 瞎猜——用规则文件和显式上下文解决。任务范围过大导致改完这边坏那边——用任务拆分和分步验证解决。AI 改错方向导致返工——用先出方案再动手解决。AI 大幅度改动导致不敢放手——用 Checkpoint 兜底解决。生成的代码没有约束导致质量失控——用测试先行和人工审计解决。所以这篇文章讲的不是“6 个让你变强的黑科技”而是一条完整的控制链先给 AI 足够信息再限制它的行动范围然后让它有计划地执行每一步都有反馈最后再用测试和审查兜住质量底线。下面我把每一条展开讲。2. 六条最佳实践地图你该在哪个环节用力先把六条实践放在一张表里方便你对照自己的使用场景实践解决什么问题适用场景上手难度1. 用 Agent 模式而不是简单问答AI 只能单点改代码无法跨文件闭环改动涉及多个文件、需要跑测试低2. 把项目上下文做成显式规则资产AI 反复问技术栈和规范上下文被稀释长期维护的项目、团队协作中3. 让 AI 先出方案再写代码方向性错误改完发现不是你要的新功能、重构、不熟悉的代码库低4. 任务拆小每步都可验证一次改太多报错后难以定位所有复杂功能开发中5. 靠 Checkpoint 兜底AI 改乱了想回退但不想丢后续工作实验性改动、大范围重构低6. 测试先行生成代码必须人工审计代码能跑但逻辑边界不安全涉及外部命令、文件、权限、网络高这六条的优先级也是从前往后的。最开始用 Cursor 3 时先把第 1 条和第 2 条落实你的生成质量就会明显提升。等你对 Agent 的行为模式熟悉了再叠加 3 到 6 条形成完整的闭环。我自己经历的过程是一开始只顾着让它“快点写”后来发现真正影响效率的是“写之前和写之后”。3. 实践一把简单问答切换到 Agent 模式3.1 Ask、Edit 和 Agent 的分工Cursor 3 里不同模式适合不同任务很多人最大的问题就是让它们干不擅长的事。Ask 模式适合“解释这段代码在干什么”“这个函数会不会有并发问题”它只回答不动手适合做代码阅读理解。Edit 模式适合“把某个函数改成异步”“把这里的变量名统一”改动范围小、目标明确。Agent 模式适合“跨文件改动”“帮我新增一个接口并跑通测试”“修一下这个报错它在前端调接口失败”它需要自己读文件、修改、执行命令并且在失败后自动继续尝试。我的建议是凡是需要两个以上文件配合、或者需要运行命令验证的改动直接用 Agent 模式。你把它当问答工具用反而会因为它不会主动查代码而得到一堆“看起来对但根本不存在”的函数。3.2 Agent 模式的任务描述模板Agent 模式也不是随便写一句“帮我加个功能”就能用好的。我给自己总结了一个描述模板实测下来可以大幅减少跑偏背景当前项目是 xxx技术栈是 xxx。 任务请实现 xxx 功能入口文件在 xxx。 约束 1. 只修改 src/modules/report 目录下的文件不要动公共组件。 2. 输出格式保持现有 JSON 结构不变。 3. 改完后运行 npm run test:report并把结果贴回来。 4. 如果发现现有实现与需求冲突先停下来问我不要擅自重构。这个模板看起来啰嗦但它把背景、任务、边界、验收方式、异常处理都写清楚了。尤其是第 4 条非常重要——AI 在 Agent 模式下有很强的“自作主张”倾向碰到它认为不合理的代码会顺手重构结果就是明明一个小需求diff 却大得吓人。3.3 观察 Agent 的闭环过程第一次用 Agent 模式处理一个五六个文件联动的需求时我是有点惊讶的。它会先读相关的入口文件、组件、接口定义然后给你一个简短的执行计划再开始改。改完它会自己跑测试测试失败了会读错误信息再回去改代码而不是把报错丢给你。这时候你不需要盯着每一行输出但一定要在任务描述里给它一个“验收标准”。我有一次让它迁移一个旧的数据处理脚本它跑完之后告诉我“所有测试通过”但我加了一条要求“必须对比迁移前后的采样输出”它才意识到旧脚本里有一个四舍五入的边界没处理好。验收标准越具体AI 的自我纠错就越有意义。4. 实践二把项目上下文做成显式规则资产4.1 .cursor/rules 里放什么很多人每个新会话都要重新跟 AI 介绍项目这其实是最低效的用法。Cursor 3 支持项目级规则文件你可以把每次都要重复说的东西固化下来。我的项目根目录下会有这样一个.cursor/rules/project-rules.mdc--- description: 项目通用开发规则 globs: [**/*.ts, **/*.tsx] --- - 技术栈React 18 TypeScript 5 Vite禁止引入未列入 package.json 的依赖。 - 状态管理统一使用 zustand不要新增 redux。 - 接口请求全部走 src/api/request.ts 里的封装禁止在组件内直接 fetch。 - 组件文件名使用 PascalCase工具函数使用 camelCase。 - 修改公共组件前先检查所有引用处避免破坏现有页面。 - 提交前必须运行 pnpm type-check 和 pnpm lint。注意第一行的globs字段它可以限定这个规则作用于哪些文件。如果你同时有前端和后端代码建议拆成多个规则文件而不是塞在一个里面。这样 AI 在处理后端文件时不会被前端的规则干扰。4.2 规则文件之外每次还要“喂”什么规则文件解决的是长期约束但每个任务的目标和背景仍需要你在提示词里说清楚。我在实际操作中的经验是不要靠记忆向 AI 口头描述项目结构而是让它直接读关键文件。你可以这样开头请先阅读 README.md、src/api/request.ts、src/pages/report/index.tsx 这三个文件理解现有报表页面的数据和请求方式然后开始实现导出 Excel 功能。这么做的原因是AI 对文件内容的理解远比你转述更准确而且它读文件的过程会自己建立上下文后续修改时不会频繁跑偏。规则文件是“长期记忆”任务描述是“短期指令”两者缺一不可。4.3 规则文件的实际效果我一开始没太在意规则文件总觉得每次说一遍就行。直到有几次让 AI 生成新页面它异常执着地用了any类型还绕过统一请求封装直接 fetch我才意识到人在反复写提示词时会疲劳AI 在长对话中也一样越到后面越容易忘记早期的口头约束。把规则写进文件之后效果立竿见影。尤其是globs配合使用AI 每次处理相关文件都会自动加载对应规则不需要我再重复“项目里不能用 any”“接口必须用封装”这些车轱辘话。这块投入的成本很低长期收益非常高属于我建议第一个做的“基础设施”。5. 实践三让 AI 先出方案再写代码5.1 两步式提示先方案后执行大多数时候AI 生成代码跑偏不是因为不会写而是没有想清楚就动手。Cursor 3 的 Agent 模式效率越高这个风险越大。它可能三分钟就把一个错误方向的方案实现完了你还要花半小时拆掉重来。所以我一直用两步式提示。第一步只让 AI 出方案明确告诉它“不要改代码”先不要改任何代码。 请分析当前 src/services/order.ts 中的订单创建逻辑我要增加一个“优惠券分摊”功能。 请给出 1. 需要改动的文件和函数清单。 2. 数据流从接口入参到数据库写入的变化。 3. 需要新增的测试用例。 4. 你认为存在的风险点。 等我说“继续”再开始写代码。这个提示的关键是最后一句“等我说继续再开始写代码”。没有这句话AI 大概率会在给完方案后顺手把代码改了又回到老路。5.2 你需要在方案里确认什么拿到方案之后我不会逐行看代码而是重点确认几个点改动范围是不是只动了该动的地方有没有顺手“优化”不属于本次任务的逻辑数据流新增的参数如何穿过各个函数类型定义是否一致风险点有没有影响现有调用方、有没有忽略边界情况测试策略它准备怎么验证测试用例是否能覆盖核心场景有一次我让 AI 在订单模块里加优惠券分摊它的方案写得很好但藏在第 4 条风险点里提到一句“现有订单快照表缺少优惠字段建议迁移表结构”。如果我没看方案直接让它写就会多出一个数据库迁移的意外改动。方案先行就是为了让你有机会在“动手之前”拦截这种范围蔓延。5.3 方案被否决怎么办方案被否决很正常不代表 AI 能力不行。直接告诉它哪里不符合预期让它重新出方案。比如“不要把优惠字段加到订单主表放到明细表里因为历史订单不能回填”。这个反馈本身也是上下文的一部分能让后续实现更精准。如果 AI 连续两次方案都不对我建议停下来重新检查你提供的背景信息是否足够。大多数时候不是它理解力差而是你忘了告诉它某个约束。这时候把“为什么不能改主表”的原因写清楚比反复催促更有效。6. 实践四任务拆小每步都可验证6.1 一个可验证任务的标准很多人在 Cursor 3 里遇到的问题是任务越大AI 越容易“一本正经地胡说八道”。本质原因是上下文窗口有限改动十几个文件之后它自己也可能忘了前面改过什么。我判断一个任务是否适合交给 AI 的标准是三条有明确的输入和输出比如“根据表单数据生成 Excel 文件”。影响范围可控比如“只新增一个模块但不改现有接口”。改完可以通过一个命令验证比如“运行 pytest tests/test_reports.py -k export”。如果任务不满足这三条就先拆。拆任务不是简单地把一句话切成三句而是按“可验证的闭环”来拆。一个闭环结束后你能拿到明确结果再开始下一个闭环。6.2 一个具体的拆解示例我之前用 Cursor 3 重写一个内部报表服务需求听起来不大但实际涉及数据清洗、聚合查询、Excel 导出、接口返回、前端下载五个环节。一股脑丢给 Agent 的结果是它改了三个文件后运行测试报错信息已经分不清是哪个环节造成的。后来我拆成了这样任务 A把原始 CSV 的清洗逻辑单独做成模块并输出一份采样结果文件。任务 B实现按日期范围聚合的查询函数用固定输入写完单测。任务 C写 Excel 导出工具类确认列宽、表头、样式符合模板。任务 D把 ABC 接到 FastAPI 接口上返回下载流。任务 E前端加一个导出按钮联调并验证大文件下载。每个任务之间都有一个明确的“产物”比如采样文件、单测结果、Excel 文件。我可以快速验证对不对再进入下一步。实际执行下来整个过程比我手动写快很多而且几乎没有出现“改完 A 忘了 B”的情况。6.3 为什么拆小能降低幻觉拆小任务还有一个隐藏好处每次对话的上下文更短AI 需要“记住”的内容越少生成的代码就越稳。就好比让实习生一次处理一件事他能做得有模有样让他同时处理十件事他一定会开始编造没验证过的接口和变量名。如果你已经把一个复杂需求一次性丢给了 Agent发现它逻辑开始混乱不要继续在同一个会话里疯狂补提示词。直接开一个新会话把已经明确的部分整理好再让 AI 从下一个子任务开始经常比在原会话里“修正”更高效。7. 实践五靠 Checkpoint 兜底敢让 AI 放手改7.1 Checkpoint 与 Git 的区别很多开发者的第一反应是AI 改乱了用 Git 回滚不就行了但实际场景里频繁使用 Git 回滚成本很高尤其是当你只想撤销 Agent 最近的几次改动、保留之前的代码时Checkpoint 会更加轻量。Cursor 3 的 Checkpoint 机制相当于给 Agent 的每一步改动打快照。我理解它的定位是“微观回滚”而 Git 是“宏观记录”。一个典型场景是Agent 在一次会话里改动了五个文件其中三个改得不错两个改坏了。我想保留那三个文件的成果只回退坏的两个。用 Git reset 会比较麻烦用 Checkpoint 可以更细粒度地回退到某个改动步骤之前。7.2 我的实际用法在让 Agent 执行大范围任务之前我会先确认当前状态能快速恢复。建议的顺序是先手动git commit一次保证代码库有一个干净基线。在 Cursor 3 里开启新会话让 Agent 开始改。每个子任务完成并验证通过后留意 Checkpoint 状态相当于暗自记下“这一步是好的”。如果之后改动跑偏直接回滚到那个好的 Checkpoint而不是整个会话推倒重来。全部完成后用 Git diff 仔细审查一遍再 commit。要点是Checkpoint 不能替代 Git。它解决的是“操作过程中的快速撤销”但不提供多人协作所需的提交记录和代码评审信息。最终能进入项目历史的一定应该是经过审查的 Git 提交。7.3 什么情况下不要依赖 CheckpointCheckpoint 也不是万能的。我在两个场景里会特别谨慎跨会话协作如果多个会话并行改同一个项目Checkpoint 只能回滚当前会话的改动不能处理其他会话带来的冲突。需要代码评审的工作流Checkpoint 不产生 commit message也没有 diff 描述团队协作时还是要回到 Git flow 上。所以我的建议是个人探索阶段放心用 Checkpoint凡是需要交付给别人的代码一律以 Git 提交为准。8. 实践六测试先行生成的代码必须经过人工审计8.1 让 AI 先写测试的好处“测试先行”在 AI 编码场景下多了一层意义测试就是你对 AI 的需求说明书。你让 AI 先写测试相当于把模糊的“帮我实现一个功能”变成了具体可运行的期望。这个过程会逼你想清楚输入、输出、异常情况也能让 AI 在实现时有一个明确的对标物。我比较喜欢用这种提示请不要实现功能。 先为 src/utils/formatPrice.ts 编写单元测试覆盖以下场景 1. 数字带两位小数。 2. 千分位格式化。 3. 负数输入。 4. 字符串数字输入。 5. NaN 和 Infinity 抛错。 写完测试后运行一次确认测试因为函数不存在而失败然后停下来等我下一步指令。这招非常有效因为测试失败本身证明了测试真的在起作用。AI 在后续生成实现时也会因为“有个测试在盯着”而更倾向于写符合预期的代码而不是自由发挥。8.2 人工审计边界这几类代码必须看即使测试全过我也坚持要人工 review 生成的代码尤其是下面几类调用外部命令的代码比如exec、subprocess、shell()任何命令拼接都需要人工确认。文件路径操作尤其是涉及删除、覆盖、移动文件的代码一旦路径写错后果很严重。权限和鉴权相关比如登录校验、接口权限判断AI 容易漏掉边界条件。网络请求和数据库查询需要确认超时、重试、事务、SQL 注入等细节。密钥和敏感信息AI 有时会不自觉地把 token 或连接字符串打进日志里。一句话总结凡是影响安全、并发、数据的代码不能只靠“测试通过”来判断必须人工逐行看。AI 生成的代码更像是“初稿”不是“终稿”。8.3 一条可复用的验收流程我每次用 Cursor 3 完成一个功能都会走一遍固定流程1. Agent 先写测试明确需求。 2. Agent 实现功能。 3. 运行完整测试确认通过。 4. 我手动审查 git diff重点看安全、边界、依赖变化。 5. 必要时补充一两个我自己的测试用例。 6. 最后提交 Git。这套流程看起来很常规但配合 Cursor 3 的高效生成能让“快”和“稳”同时成立。我不相信 AI 生成的代码可以免检但我相信通过测试和审查两条线可以把它的错误率压到可控范围。9. 高频问题排查与避坑实录9.1 常见问题速查表现象可能原因处理方式Agent 改了不该改的文件任务描述里没有明确改动边界在提示词中加“只修改 xxx 目录不要动 xxx”生成代码反复报同一个错一次给的任务太大上下文已混乱开新会话拆成子任务带上最新报错信息回滚后丢失后续新改动只依赖 Checkpoint没有手动 Git 提交每个稳定点主动 commitCheckpoint 只是过程工具规则文件不生效路径写错、globs 不匹配、没重启会话确认文件在项目根目录 .cursor/rules 下并重启 CursorAI 忽略“不要改公共组件”这类约束口头提示被长对话稀释把硬约束写进项目规则文件而不是只靠提示词Agent 说测试通过但功能不对测试覆盖不足或它只跑了一部分测试指定“运行完整测试命令”并人工 review 测试用例质量9.2 我踩过的三个坑第一个坑是过度依赖单一会话。曾经让同一个 Agent 会话从头到尾实现一个完整功能结果越到后面它越容易忘记最初的约束甚至重复定义同名函数。后来我养成了“一个会话只做一个可验证闭环”的习惯问题减少很多。第二个坑是规则文件写得太笼统。一开始只写“代码风格统一”AI 根本不知道具体是什么风格。后来改成“组件文件 PascalCase、工具函数 camelCase、禁止 any”它才能真正执行。规则文件要足够可操作不要写“正确的废话”。第三个坑是让它全自动改完后再去看 git diff发现改动量巨大。现在我会在任务描述里加一句“尽量保持最小改动不重构无关代码”并且每次让 Agent 改完主动列出改动清单我先看清单再决定是否接受。最后再分享一个小技巧每完成一个子任务我会把 Cursor 3 给出的问题和解决过程简单记录在项目里的AI_NOTES.md里。这个文件本身也是给后续 AI 会话看的它能避免同样的坑在下一个任务中重新踩一遍。工具再聪明也需要你帮它建立“记忆”而工作流就是最好的记忆载体。