装上Cursor的第一周我差点把它卸载。原因特别丢人我输了一句“帮我优化一下登录页面”它兴冲冲地回了我一堆抽象概念什么“提取hooks”“拆分组件”“提升可维护性”可我的页面该卡还是卡该报错还是报错。后来我才反应过来问题不在模型在我输入框里那短短一行 prompt——你给它的信息直接决定了它回报你的质量。这篇内容整理自我在两个真实项目里用Cursor干活的经验总结成6条能直接上手的Prompt“心法”。它们的目标只有一个帮你突破“模型很聪明但就是不干活”的瓶颈。每条心法我都会给出失败案例、改写模板和实际效果适合刚接触Cursor的小白也适合已经用了一段、总觉得隔靴搔痒的老手。至于界面语言设置、下载安装这类话题一篇教程就能解决这里不再重复。1. 先定位瓶颈Cursor的三种模式、三个误区与一条主线很多人用不好Cursor第一反应是怪模型不够强但实际上是你没搞清楚它到底有几种工作方式每种方式对Prompt的要求完全不一样。1.1 Cursor的三套工作模式对Prompt的要求完全不同Cursor表面上看是一个编辑器其实它把AI编程拆成了三个入口Tab补全。这个模式默认开启你写代码时它自动预测下一段内容。它几乎不需要你写显式Prompt但可以通过改文件头注释、写清楚的函数名、留下TODO来影响它的预测。很多人忽略这个入口其实它才是提效最猛的地方因为它没有“等待成本”。行内编辑快捷键是⌘K / CtrlK。你先选中一段代码再输入指令它只在选中的范围内改。这个模式适合单一、明确的小任务比如“给这个函数加日志”“把这里的循环改成filter”。因为任务范围已经被选中代码锁死Prompt反而不需要写太长重点说“改成什么”就行。Chat与Agent快捷键是⌘L / CtrlL和⌘I / CtrlI。Chat适合提问和讨论Agent则能自主读取文件、搜索代码库、运行命令、跨多个文件改动。这里是最容易翻车的入口因为它的能力和自由度高你得像给实习生派活一样把任务说明白。很多人从头到尾只用Chat还指望它像Agent一样“自动搞定一切”那自然会失望。先搞清楚自己在哪个入口再说Prompt怎么写。1.2 三个几乎人人踩过的使用误区第一个误区把Cursor当搜索引擎。你不贴文件、不给报错上下文直接问“为什么我的登录页白屏”它能给你的只有一堆泛泛的排查建议。这不能怪它它连你的代码长什么样都不知道。第二个误区一个对话干三天。上午用同一个对话窗口让Cursor改了个弹窗下午让它加接口晚上再让它重构模块。等你要它“保持之前的规范”时它早就把最初的约束忘得差不多了因为上下文越长早期指令越容易被稀释。这属于典型的不会管理对话。第三个误区对生成结果完全不设防。它改完代码你直接点接受不看它动了哪些文件、删了哪些逻辑。等到测试挂了才发现它顺手把另一个文件的命名风格统一改掉了。模型是概率生成的它天然会“顺手多做一些事”你不设边界它就会越界。1.3 一条主线Prompt的本质是降低模型的“瞎猜系数”把上面三个误区串起来看你会发现核心问题只有一个你给模型留了太多需要猜的地方。模型没有“隐身记忆”你不给它看相关代码它就只能按照概率推断一个最可能的答案你不给它边界它就会把“优化”理解为它认知里的优化而不是你心里的优化。我把这套逻辑类比成带实习生。你跟实习生说“把登录页弄好”他一定会手足无措但如果你给他一份任务书写清楚背景、位置、目标、约束和验收标准他就能按图索骥。Cursor也是一样后面所有心法本质上都是在教你写这份“任务书”。2. 心法一把“帮我优化一下”改写成能验收的任务书这个心法听起来最简单做起来最难。因为大多数人习惯用口语化的模糊指令比如“帮我优化这个表单”“让这个页面好看一点”你爽了模型懵了。2.1 模糊Prompt的失败过程我替你踩过了我最早让Cursor改一个表单校验逻辑指令只有一句话“帮我优化这个表单。”结果它把整个表单从受控组件改成了非受控组件把错误提示文案全换了一套还顺带把提交逻辑重构了。表面上看确实“优化”了但业务测试全部炸掉我花了一晚上回滚。问题出在“优化”这个词上。它能指性能、可读性、架构、UI、用户体验模型没有能力读取你的真实意图它只能选一个它认为最优的方向发挥。一旦方向选错输出越精美你收拾烂摊子的成本越高。2.2 五段式任务书模板直接复制就能用后来我把Prompt拆成五个固定部分效果稳定了很多背景项目用的什么技术栈/在哪个模块下工作 位置具体文件路径函数名/行号 目标用可观察、可度量的方式描述要什么效果 约束明确禁止或不可触碰的事项 验收你如何判断它做的是对的举个例子。我把“帮我优化表单校验”改成项目是 Vue3 TypeScript现在是登录页 src/views/login.vue 的 handleSubmit 函数负责校验。 当前问题邮箱格式错误时只有点击提交才会提示。 目标用户输入完邮箱、失焦后立刻显示校验消息并把焦点定位到第一个错误字段。 约束不要引入第三方库不要修改模板结构不要改动接口字段。 验收请输出修改后的完整 handleSubmit 函数并在注释里列出你改的三个点。这条Prompt跑出来的结果基本一次就能用。因为它把所有模糊空间都填死了模型不需要替你决定“优化”的含义。2.3 同一个需求两种写法效果真的天差地别我把同样的问题分别用两条Prompt跑了一遍。模糊版回了一段非常优雅的抽象设计建议提到要抽取validator类和hook但没给出任何能直接落地的代码我怀疑它根本没读我的表单逻辑。任务书版则老老实实改了handleSubmit在失焦事件里加了对应字段的校验还特意标注了“我只改了校验触发时机没有动校验规则本身”。这两种结果的差距不在于模型智商而在于你给它的约束密度。模型在信息越少的时候越倾向于“自由发挥”因为自由发挥是它的本能不是它的缺陷。2.4 验收标准怎么定才算不模糊写验收时有三个关键词可执行、可回滚、可解释。可执行验收标准不能是“代码变好看”而必须是“失焦后显示提示”“调用接口后关闭加载态”这种能直接测的行为。可回滚所有改动要在Git的diff里清晰可见别让它一次性改十几个文件否则你连回滚都不知道滚到哪里。可解释要求模型在回复里说明“我改了什么、为什么改、影响面是什么”。这个习惯能逼着它收敛也方便你审查。尤其是行内编辑模式我习惯在指令末尾加一句“如果还改了其他无关部分请明确指出来”。这句话不复杂但能有效避免“顺手牵羊式的重构”。3. 心法二先喂上下文再下指令别让Cursor盲人摸象如果说心法一解决的是“话说不清”那心法二解决的就是“信息给不够”。很多人在Chat里让Cursor改代码只发一句话连文件名都不给然后抱怨它改得不对。问题是它根本不知道你的项目里有哪些文件代码长什么样它只能靠猜。3.1 为什么上下文比模型智商更影响结果模型是概率生成器它不具备“隐身记忆”。你打开Cursor时它确实会索引你的项目但Chat里的模型并不会自动把你整个代码库读一遍它只会看到你主动引用或者粘贴的内容。换句话说你在让它干活之前得先帮它把眼睛睁开。我常用的类比是远程Debug同事在另一个城市你只发一句“这段代码报错了”他再牛也只能让你先贴报错截图。Cursor也一样你别指望它隔空读取你的bug现场。3.2 四种喂上下文的姿势按场景选我把常用的方式整理成一张表方便你对照方式适合场景注意事项引用文件明确知道要改哪个文件每次引用2到4个太多会稀释注意力codebase检索不确定文件在哪让模型全局找成本高、结果可能掺入无关内容先用来定位再换成具体文件直接粘贴截图UI布局、样式、动效问题一张截图胜过几百字描述但要保证截图清晰粘贴报错栈/日志运行时错误、接口异常去掉敏感信息保留关键调用链和错误码你可能会觉得codebase很省事但它有一个副作用它检索出来的上下文可能包含很多相关性很低的文件模型会平均分配注意力最后反而抓不住重点。我的做法是先用codebase把文件定位出来然后立刻换成具体的文件引用再开始正式任务。3.3 一份好上下文的组织模板这里给出一个我反复在用的问题描述模板问题现象登录后跳转首页白屏 报错信息Uncaught TypeError: Cannot read properties of undefined (reading redirect) 复现步骤输入正确账号密码 - 点击登录 - 跳转 /home - 白屏 相关文件src/router/index.ts, src/views/Home.vue, src/store/user.ts 已尝试在router.beforeEach里加了console.log确认redirect字段是undefined这份模板的关键在于你不仅告诉它“哪里出问题”还告诉它“你已经做了哪些尝试”。模型看到你已经排除掉的选项不会浪费时间去重复排查能直接往更深处走。这一点是我实测下来提升最大的一处。3.4 上下文的剂量控制不是越多越好喂上下文容易走两个极端要么一点也不给要么把整个项目拖进去。正确做法是把“定位信息”放在最前面“具体任务”放在最后面。模型对开头和结尾的注意力远高于中间所以你要把最重要的文件路径写在第一行把真正的指令写在最后一行中间才是辅助说明。如果某个文件特别大比如几千行的service文件不要整个进来而是指出关键行号区间或者先把文件里相关函数的结构贴出来。上下文要像压缩包不能像流水账。4. 心法三把大任务拆成子任务链戒掉“一口吃个胖子”看到Cursor能Agent式自动驾驶很多人会忍不住把整个功能直接甩给它指望它“一条龙”搞定。我就这么干过然后等来的不是成品而是一堆半成品和几个不知道从哪里冒出来的错误。4.1 巨型Prompt为什么总是滑铁卢原因有两个。一是上下文窗口有限你塞进去的需求量超过模型能稳定处理的范围它就会在中间部分“迷失”把前面的要求忘掉。二是注意力漂移当一次任务包含10个目标时模型会倾向于平均用力结果每个目标都做得不深。我把它类比成你让新来的实习生“把公司的官网改好点”这句话包含的需求量可能是几十项正常人听完只会发呆模型也一样。它需要的是可以一步步执行的任务链。4.2 拆任务的标准每个子任务必须能独立验证拆分不是随便把一句话切成几句而是要按照“分析→方案→实现→验证”的路径走。我强烈建议前两步只让模型动嘴、不动手。比如你让它做一个新功能第一轮Prompt可以是“先读 src/features 下的现有模块结构梳理出跟当前功能相关的文件和模式输出一份实现计划不要写任何代码。”等它输出计划后你来判断方案是否合理再让它进入第二阶段“按计划实现第一个子任务创建数据表结构完成后停下来告诉我改了哪些文件。”每轮只干一件事每件事都能独立验证。这样即使下一步出错你也能精确定位到是哪一环节的问题而不是面对一大团改动无从下手。4.3 实战案例一个点赞功能拆成四步走我最近给一个内容社区加点赞功能拆了四步每一步用的是独立对话。第一步让它读现有的文章详情页面和API层代码输出数据模型设计思路不写代码。第二步让它新增点赞表和对应的接口改完先停给我看接口签名。第三步让它写前端按钮和交互逻辑绑定到文章卡片上。第四步让它生成对应测试用例并检查是否还有遗漏的边界条件。每轮Prompt里我都加了同一句“完成当前步骤后停下来把改动文件列表和改动点发给我等我确认后再继续下一轮。”这个“停下等我确认”的意识非常关键它把Agent从“自动驾驶”切成了“半自动驾驶”你没松手之前它不会乱飙。4.4 Agent模式下的暂停点设计用Agent模式时你可以在任务书里直接设定暂停点比如“每完成一个文件就停下汇报”或者“先做A和B做完之后不要做C等我看过结果再说”。模型会照做除非你明确说“全部做完”否则它天然会倾向于一口气干到底。还有一个技巧如果任务特别复杂我第一轮会先让它“只读不改”梳理文件结构列计划。等计划确认后才允许写代码。这一步看起来浪费了一轮交互实际省掉了后面无数次的返工。5. 心法四给Prompt装好护栏管住模型的自作主张模型越权修改是几乎所有Cursor用户都会遇到的坑。你可能只是让它修一个类型错误结果它把整个文件的命名风格都改了或者给你引入了一个根本不存在的工具函数。5.1 “改超范围”是概率模型的默认行为你不能怪它“蠢”因为模型本质上是在做概率预测。当你没有明确禁止某件事时它就会把这件事看作是可选范围然后选一个它认为最“顺眼”的方案。比如修类型错误时它觉得“顺便把变量名统一成驼峰”会让代码更好但你这部分代码正准备给别人交接你根本不想动它。看清楚这一点之后我就养成了一个习惯把“禁区”直接写进Prompt。5.2 四类禁区要显式声明我总结出四类最常见的越界每种都对应一句模板文件禁区“只修改src/api/user.ts不要碰其他文件。”接口禁区“保持函数签名和返回类型不变只改函数体。”依赖禁区“不要引入任何新的第三方包或插件。”逻辑禁区“业务规则不变只修这个报错。”再叠加一句万能兜底“如果过程中你觉得需要改动范围之外的东西先停下来告诉我等确认后再继续。”这句话能在绝大多数场景下拦住模型让它从“自由发挥”切回“听指挥”模式。5.3 项目级规则文件才是治本方案每次在Prompt里写禁区依然有遗漏的时候。治本的办法是把常见边界写进项目级规则文件。Cursor支持项目规则配置你可以创建一个.cursorrules文件或者在新版设置的Project Rules里维护一份规则清单。我的项目规则里常年躺着这几条所有修改必须符合现有ESLint规则不要新增npm包除非先说明理由不要改变现有函数的公开签名遇到不确定的需求先列出方案再动手。这些规则会作为系统级提示词注入每次对话相当于给模型戴上了长期护栏不用每次重复。5.4 兜底手段强制它先报备再动手如果某个会话的模型特别“野”我会在开新对话时用一句特殊的Prompt“先分析当前需求列出你准备修改的文件和理由不要直接改代码。等我批准后再开始。”这一步等于给模型加了一个“行动前审批”流程效果立竿见影。配合Git使用就更稳了。每次生成前先看一眼当前分支是干净的生成后如果发现越界直接git checkout回滚不需要跟模型争论。工具是用的不是供着的该回滚就回滚。6. 心法五把Chat当版本库用对话要切片、要归档我发现很多人把Cursor的Chat当成了可以无限往下聊的聊天软件一个对话窗口能开一个星期。这在早期模型还能勉强应付一旦上下文变长它就会开始“失忆”你提过的约束它转头就忘。6.1 长对话为什么会越聊越乱根本原因是上下文累积。每轮对话都会把前文所有内容继续传给模型越聊越长越长的上下文里早期指令的权重会被后来的内容稀释。这就好比你跟同事连着开三个小时的会前半小时说的事情他大概率已经不记得了。更现实的问题是当对话内容接近上下文窗口上限时模型甚至会开始丢信息回答质量和稳定性明显下降。这时候你不是在提效是在跟一个越来越健忘的模糊机器搏斗。6.2 单任务单对话切换任务就开新窗我的经验是每完成一个可验证的改动就主动开新对话。哪怕新任务和旧任务在同一个模块里也建议开新窗把关键背景重新喂一遍。开头那一轮重复的路程代价远低于在乱糟糟的长对话里继续坚持。开新对话时第一句就固定为“本次任务xxx验收标准xxx约束xxx。相关文件已用引用。”这样即使你隔天再回来也能一眼看出这个对话是干嘛的而不是翻半天历史记录。6.3 每次产出先审diff再提交Cursor生成改动后不要直接点接受先在右侧的Diff视图里看清楚它改了哪些文件、删了哪些逻辑。尤其是它顺手改的那几个“无关文件”十有八九就是你未来测试挂掉的伏笔。审完diff没问题就让Cursor帮你写一条commit信息再手动执行git commit。这个习惯本质上是在管理你的“后悔药”。如果你把三个任务混在一个长对话里一次性接受Git历史就会变成一锅粥真要回滚都不知道该回到哪一步。6.4 一套可复用的切片归档工作流我现在的工作流固定成四步你可以直接抄新需求来了开新Chat写下背景、目标、约束、验收四要素。Cursor干完一小步打开Diff审查没有越界就让Cursor写commit信息然后提交。遇到搞不定的疑难问题把报错、相关文件路径、已经尝试过的方法存成一个markdown笔记。下一次要继续做同一个功能先开新Chat把笔记内容粘进去再接着跑。坚持一周之后你会发现git log里每一条提交都能对应到具体需求排查问题的时候只需要顺着历史往回翻比在对话里反复翻找靠谱得多。7. 心法六用参考代码当Prompt少说形容词多给“参考项”最后这个心法是我用得最晚但提升最明显的让模型模仿现有代码而不是用语言描述你要的风格。很多人不知道模型在“模仿”这件事上远比“理解抽象描述”厉害。7.1 为什么一个示例胜过一百个形容词你说“代码写好看一点”它不知道你觉得的好看是什么。你说“按UserService的风格写”它就知道你需要什么。因为代码风格是一个高维度的东西包括命名习惯、错误处理方式、注释风格、分层方式你用文字很难完全描述清楚但给出一段真实代码模型立刻就能学到那个“手感”。这跟让设计师做图是一样的你跟他说“高级一点”他会无从下手但你给他一张参考图他就会快速对齐。Prompt里带示例本质上是给模型一张“参考图”。7.2 参考代码从哪来最直接的来源就是项目里已有的模块。比如你要新增一个订单服务那项目里大概率已经有一个用户服务它的分层、API命名、错误处理都可以作为参考范本。你只需要在Prompt里同时两个文件然后说“仿照user.service.ts的风格写order.service.ts”剩下的模型自己会发挥。如果项目里没有现成参考你还可以在Prompt里粘贴一段你最喜欢的代码片段明确告诉它“这是我希望达到的风格”然后让它在目标场景里套用。这有点像给模型喂了一个few-shot示例效果比堆一堆形容词稳定得多。7.3 带参考的Prompt实战这是我最近一个真实任务里的Prompt写法参考 src/services/user.service.ts已用引用的实现方式 在 src/services/order.service.ts 中新增 OrderService。 要求 1. 使用相同的HTTP client实例不要新建连接 2. 错误处理风格与UserService保持一致统一抛业务异常 3. 方法命名和注释风格一致 4. 不引入任何新的第三方依赖 每个方法开始前先写一行注释说明用途写完一个方法就用分割线隔开。跑出来的结果几乎是“无需修改”就能合入代码库的。相比之下如果我只说“新增一个OrderService风格跟现有代码保持一致”它大概率会自作主张用另一种写法写一遍然后你需要花时间改回来。7.4 把示例积累成团队的“提示词方言”这个心法更进一步的应用是把好用的Prompt和对应的参考文件沉淀下来。我们团队维护了一个docs/prompt-examples.md里面记录着“问题描述参考文件最终可用的Prompt模板”。新同学进组不需要啃一个月代码先看这份文件再让Cursor照着已有风格写上手速度会快很多。我自己还会在每一次“生成结果特别满意”的时候把那段Prompt单独存下来放在个人的收藏夹里。一年下来这份收藏夹会变成非常私有的“项目方言集合”别人拿不走但你的Cursor就是比别人的好用。工具不会替你做决定但它替你跑腿的能力完全取决于你表达得够不够清楚——这大概是我从Cursor身上学到最大的一件事。