这次 PStack 内部分享题目定成了《我怎么用 Cursor》。起因是组里有人问我写业务代码这么快是不是全靠 AI 补全我说不只是补全真正拉开差距的是把 Cursor 当成一个能读仓库、能跨文件改代码的协作者而不是一个高级自动补全插件。这篇分享我不谈软件下载和安装也不搬运官方文档只讲我自己每天怎么配规则、怎么下指令、怎么控制它不把代码改坏。适合正在用 Cursor、但还没完全信任 Agent 模式的开发者也适合团队里准备统一 AI 编程规范的人。1. 先说结论我为什么从编辑器切换到了 Cursor1.1 原来的工作流卡在哪在换到 Cursor 之前我的日常开发工作流其实很传统打开编辑器靠语言服务看类型错误靠片段补全写重复代码遇到不熟悉的模块就 CtrlShiftF 全局搜索。这套打法业务稳定期没问题可一旦遇到四五个文件的联调、接口字段改名、测试补充这类活时间马上就不够用。最典型的一个场景是重构。比如把某个模块的错误处理从回调改成 Promise我可能要先找到所有调用方再逐个改签名接着跑测试看哪里漏了。整个过程机械、重复、容易出错而且特别消耗注意力。注意力一旦被这些琐碎事吃掉真正需要思考的业务设计反而没时间做了。所以我的核心诉求不是“少打字”而是把那些已经想清楚、但实现起来很磨人的工作交给工具。1.2 Cursor 解决的是哪一类问题Cursor 和其他编辑器的最大区别不是补全更快而是它能基于整个代码仓库回答问题和动手改代码。它会把当前项目索引起来我提问时可以直接引用文件、目录或者某个符号它给出的答案往往带着项目里真实存在的代码而不是泛泛的模板。举个例子我接手一个没看过代码的服务端模块时只需要问“订单模块里超时未支付的状态是在哪里更新的”它会直接定位到方法并解释调用链。这种能力我之前要么靠人带要么靠一遍遍读代码现在效率确实高了不少。所以我把 Cursor 的定位总结成三句话能读代码能改代码能解释代码。补全只是它能读代码之后顺带产生的副作用不是核心价值。1.3 它不适合所有人说句实在话它并不适合所有场景。如果项目本身几乎没有变化或者你只是想找一个稳定的编辑工具换不换都无所谓。再比如团队对代码安全要求极高不允许把源码片段发送到外部模型服务那这时候首先要考虑的就不是功能而是合规边界。另外如果你是刚入行的新手我不建议把所有代码都丢给它生成。因为写代码最需要练的就是“从需求到结构”的拆解能力AI 能帮你加速但不能替你把这一课学掉。最好的用法是让它做你的资深同事而不是做你的外挂。2. 初始化配置拿到 Cursor 后第一件事做什么2.1 项目级规则文件怎么写很多人装完 Cursor 就直接开写这其实浪费了最有价值的功能。项目级规则文件是让 AI 在进入项目的一瞬间就理解上下文的关键。我建议在项目根目录建.cursor/rules目录把约定写进去比每次对话前重复说明要靠谱得多。我自己最常用的一套规则长这样# 项目约定 - 本项目使用 TypeScript禁止使用 any 绕过类型检查 - 新增代码必须包含必要的错误处理不允许静默吞异常 - 组件统一放在 src/components 下页面组件用 index.tsx 导出 - 所有对外接口的入参和返回值必须写 JSDoc - 不要修改生成的产物文件包括 dist、build 目录 - 提交前不要删除调试日志而是先询问是否保留这些规则不是摆设它会参与每一次补全和对话。当我让 Cursor 改代码时它会优先按照这些约束输出。这比写 Prompt 时反复强调“请遵守项目规范”有效得多因为项目规范已经变成它的默认背景知识了。2.2 全局规则与项目规则的分工全局规则放个人偏好项目规则放团队约束。比如我自己的全局规则里写着“变量命名使用语义化名称不要用 temp、data 这类无意义词”这是我个人的风格。而项目规则里则写的是“本仓库使用 monorepo包管理器为 pnpm新包必须包含入口文件”这是所有协作者都必须遵守的底线。分工清楚能避免一个很烦的问题如果项目规则混入了太多个人偏好换电脑或者别人接手时会莫名其妙。团队协作时项目规则应该像代码评审标准一样写清楚最好大家商量着定而不是某个人偷偷加一堆自己的习惯。2.3 模型和请求量控制Cursor 的模型选择会影响效果但不是越贵越好。日常补全和简单的行内编辑我用快速模型就够了复杂重构、跨文件分析和讨论设计问题才用更强的模型。这就像日常买咖啡和招待朋友去咖啡馆不是一个预算没必要每次都把请求拉到最高档。我这里说的控制请求量不是省字数而是控制上下文复杂度。很多情况下模型回答质量差不是因为模型不够聪明而是因为它要在冗长的上下文里猜我到底想干什么。所以小改动用轻量模式大任务开长上下文模式这个习惯能省很多时间。2.4 快捷键调整别照搬网上有很多“必设快捷键”清单我看了看真正有用的就几个接受补全、行内编辑、打开对话、终止生成。其余花哨的按键组合反而容易按错。我自己的建议是先按默认方案用一周把出现频率最高的操作记下来再单独调整那几个键。有一点要特别提醒手速快的时候容易误触“接受全部改动”。我在刚用的时候就是因为顺手按了回车结果一下子改了五个文件不看 diff 直接提交差点把结构调整也一起带上。所以我的习惯是凡是涉及多文件改动接受之前一定要先看一眼摘要。3. 我每天都在用的三种交互模式3.1 Tab 补全不是普通自动补全Tab 补全是我的日常主力但它的体验和传统自动补全完全不同。传统补全只能猜我接下来要输入哪个符号、哪个变量名而 Cursor 的 Tab 补全会结合当前文件和仓库上下文补出一整段符合项目风格的新代码。我常用的场景是写重复性组件。比如项目里已经有一个列表页我再写第二个列表页时只要把接口路径和字段名敲出来剩下的渲染逻辑、 loading 状态、空态判断它都能照着已有模式接下去。质量虽然不是每一条都完美但两条补全里至少有一条能直接用稍作修改就够。不过这里有个前提必须给它足够的信号。如果函数名、变量名还没写清楚补全就容易跑偏。我一般在写函数名时就先把函数职责定准比如buildOrderFilterParams它就知道下一步要构造订单筛选参数了。这也逼着我先把命名想清楚反而提升了代码质量。3.2 CtrlK 行内编辑适合小步改代码行内编辑适合针对一小段代码做精确修改。我会选中一个函数然后输入“重构这段逻辑去掉重复的 try-catch改为统一错误处理函数”。它只改动选中的范围所以风险可控改完能快速在旁边的 diff 里看变化。这个模式的关键是“小步快跑”。一次只改一个方法、一个组件、一个判断分支确认没问题再继续。千万不要选中一个 300 行的文件然后说“帮我优化一下”它大概率会把整个文件重写一遍diff 大得没法审出了问题也难定位。我比较常用的是配合/fix指令当一段代码有语法错误或者类型错误时选中报错区域让它修复。这种任务边界清晰几乎不会拖泥带水。3.3 Chat 与 Agent复杂任务怎么拆Chat 适合问问题、解释代码、讨论方案Agent 则适合让它真正动手改代码。我的使用原则是能 Chat 说清楚的事情不着急开 Agent一旦开 Agent就要把任务拆到它能一口气完成的程度。什么叫“能一口气完成”比如“把用户列表改成支持分页”是一个中等任务涉及列表组件、接口层、类型定义和空态展示。更好的写法是分成三步第一步在 src/services/user.ts 里增加分页参数类型并修改查询接口 第二步修改 src/components/UserList.tsx 的加载逻辑保留原有搜索功能 第三步补全分页加载更多的测试用例风格参考同目录下的其他测试这样每一轮的改动范围都有限中途出问题我能马上发现不用等它把全仓库都折腾一遍再回头排查。3.4 一个从需求到实现的小案例举一个最近实际发生的例子。需求是在订单管理后台加一个“按状态筛选”的交互我当时的做法是先把需求背景写清楚再指给它相关文件订单管理页在 src/pages/orders/index.tsx 当前已经有列表查询和状态字段但没有筛选逻辑 请先阅读订单接口类型定义 src/types/order.ts 然后给列表页增加状态筛选下拉框切换时重新拉取第一页数据 保持现有组件风格不要引入新的 UI 组件库它读完文件后很快给出了实现方案在页面顶部加下拉框状态变化时重置页码并调用查询接口。我检查后只调整了一个字段名整体思路完全合理。关键在于我给了明确的文件路径、边界和风格约束它才没有自由发挥。4. Agent 模式下的任务拆解与上下文管理4.1 问题越具体Agent 越靠谱Agent 模式看起来能“自动思考”但如果需求模糊它会自己脑补一堆假设。比如我说“优化一下登录逻辑”它可能把 token 过期、多端登录、密码加密全都重构一遍最后 diff 巨大我根本不敢提交。后来我把写法改成登录逻辑存在 src/auth/login.ts 当前的问题是登录接口失败时错误提示没有区分网络错误和账号不存在 请只修改错误处理部分保留原有流程这一版比之前的收敛了很多。要让 Agent 靠谱最重要的不是它的模型多强而是我给了多少有效的上下文和边界。需求描述越接近“验收标准”它的输出越接近我能直接用的代码。4.2 控制在上下文里放什么Agent 默认会读取当前打开的文件、相关文件和规则但如果我在聊天里同时挂了好几个文件它处理时就会分散注意力。我的经验是每次对话只引用和当前任务直接相关的三到五个文件其他全部让它自己按依赖关系去找。用快捷键引用文件时也讲究精确。不要一次性十个文件那是把风险摊开了。我会先让它读入口文件和类型定义看完确认逻辑后再让它去拉具体实现。这样它的每一步都有依据而不是在一堆文件之间做猜测。4.3 让 Agent 自己搜索代码而不是我指路刚用 Cursor 时我喜欢把所有文件路径都喂给它像个导航员一样一步步带路。后来发现完全没必要因为 Agent 本身能搜索仓库。我应该告诉它“去找负责用户权限校验的函数”而不是亲手把文件路径贴出来。这看起来是小事但对效率影响很大。让它自己搜索一方面能训练它对仓库结构的理解另一方面我少做一次定位操作。更重要的是它找到的内容往往比我凭记忆找的还准确因为它能从符号引用、调用关系、目录命名等多个角度一起搜索。4.4 多文件改动时的边界控制多文件改动是 Agent 最容易翻车的地方。我现在的做法是在提示词里明确标注“允许修改文件清单”和“不允许修改的部分”请只修改 src/features/profile 目录下的文件 不要动 src/api 下的请求封装如果接口有问题请先向我报告这相当于给它画了一个工作区。越界时会主动停下来问我而不是越过边界乱改。这样一来我评审代码时只需要关注特征目录内的改动不用再担心它顺手把公共依赖也改了。我还习惯于在一次大任务开始前先用 Git 标记当前状态。等它改完一轮任务我会直接对比 diff不符合预期就让它撤销。这个过程不用任何插件只要保持“每次只接一轮改动”的节奏就不会乱。5. 代码评审与重构用 Cursor 做质检5.1 让 Cursor 先做静态检查我会不定期让 Cursor 对某个文件做一轮把脉式检查不直接改任何代码只输出发现的问题。提示词大概是请对 src/modules/payment/index.ts 做一次代码评审 按严重程度分组列出问题逻辑错误、潜在异常、风格问题、测试缺失 不要修改代码只输出问题和建议这个动作帮我减少了很多低级 bug。它特别擅长发现“接口可能为空”“变量只在某个分支赋值”“异常被吞掉没上报”这类问题。虽然它偶尔会误报但大部分判断是合理的我再逐条确认就行了。5.2 重构时的最小 diff 原则重构是好事但我吃过亏让 Cursor 顺便调整了组件结构、改了命名、又顺手优化了性能结果 diff 变成一锅粥出了问题都不知道是哪一步引入的。所以我现在严格坚持最小 diff 原则。比如需要调整一个函数的抽参逻辑我会明确说“只提取公共逻辑不改行为不调整命名”。如果它提出额外建议我先记下来等主任务完成后再单独开一轮去处理。这样每一轮改动都可追溯代码评审的同事也不会骂我。5.3 用 Chat 做解释性问答代码评审不只是找错还要理解为什么要这么写。特别是接手别人代码时很多实现背后都有历史原因直接改容易踩坑。我会让 Chat 先解释一段代码的意图再列出它依赖的外部条件。前段时间我看一段老旧的轮询逻辑代码写得非常绕正准备重构。我先把这段代码丢给 Chat问它“这个轮询为什么没有清理定时器是一直只执行一次还是有意为之”。它的回答帮我理解了原作者的思路也避免了一次不必要的重构。解释能力在这里价值很大它相当于一个随时在线的代码向导。5.4 核心逻辑必须人工把关不管 Cursor 有多厉害涉钱、权限、数据处理这类核心逻辑我最后一定自己过一遍。它不会主动做安全审计更不会为你承担线上事故。我的方式很简单对它改过的核心文件逐个方法看一遍确认没有放开权限校验、没有把敏感信息打日志、没有引入第三方依赖。代码可以快但判断不能快。把“快”留给重复劳动把“慢”留给关键判断这是我和 AI 协作的基本分工。6. 不要太依赖Cursor 容易翻车的几个场景6.1 大版本升级和依赖变更模型训练数据里的知识往往有滞后性。让 Cursor 写某个最新版本框架的代码时它有可能会按旧版本的 API 输出看起来挺像回事编译才暴露问题。我的对策是遇到不熟悉的依赖升级先把官方变更日志或者迁移文档贴进对话让它基于文档去改写代码而不是基于记忆生成。这简单几步节省的调试时间远超想象。6.2 外部服务集成和配置涉及外部服务的对接时它可能会凭印象写出标准示例代码却忽略了项目里真实的服务商配置。轻则环境变量名对不上重则把生产配置写错。我现在凡是接外部服务相关需求都会先把对方提供的接入文档摘要放进去再让它结合项目现有配置处理。如果它引用了项目里不存在的参数我会直接打断并让它重新核实。比自己测试浪费一轮时间好得多。6.3 性能优化里的“想当然”性能优化是 Cursor 最容易给人“虚假信心”的场景。它看到双层循环就建议加缓存看到复杂表达式就建议拆开。但很多性能问题并不在那段代码上真正瓶颈可能在数据库查询、资源加载甚至布局渲染。我现在会让它先分析瓶颈依据而不是直接优化。比如我会说“这段接口响应较慢但还没有做压测请先帮我在代码里标注可疑点不要直接改”。等我有数据以后再针对具体热点做优化它才真正帮得上忙。6.4 安全和合规敏感代码安全相关的代码我基本不让它独立完成。比如权限校验、支付回调验签、文件上传类型限制这些地方一旦出错不是代码质量问题而是事故。就算它写的流程看起来完整我也必须自己追一遍每个 if 分支。安全底线可以通过规则文件提醒它但不能通过规则文件免除审查。规则里我会写上“涉及权限校验时必须显式检查当前用户身份”但它是否严格执行仍然需要我确认。AI 是我的工具不是我的负责人。7. 进阶玩法把 Cursor 变成团队协作的一部分7.1 自定义指令设置里的自定义指令相当于一个幕后助手我平时会写一些跨项目的偏好比如“回答问题时先给出结论再补充细节”“如果建议删除代码必须说明删除理由”等。这些指令会影响到我每一次对话的输出风格。团队协作时我更建议把约定放在项目规则里而不是个人设置里。因为自定义指令只属于某一个人的账号别人提交代码时根本看不到。真正能让大家一致的是项目仓库里的规则文件它跟着代码走谁拉到代码都一样。7.2 沉淀自己的 Prompt 模板用得多了以后我会把自己反复用的好提示词存成模板放到一个单独的目录里。比如写单测的模板我基本固定为请为 src/utils/format.ts 中的 formatPrice 函数编写单元测试 要求 - 测试框架使用 Vitest - 用例放在同目录下的 __tests__ 文件 - 覆盖正常输入、边界值、异常输入三类场景 - 不 mock 内部纯函数只 mock 外部依赖存模板的意义在于稳定输出。如果每一次都临时想措辞质量会上下浮动。按模板走十次里有九次的产出是达标的。7.3 批量小任务我用得比较多的是“批量但没有创造性”的任务比如给所有对外接口补充校验参数、统一错误码格式、给每个组件补默认值。这些事传统做法是逐个文件改费时间又枯燥交给 Agent 很合适。批量任务最关键的是先做一个小样。我会先让它改一个文件检查完全没问题后再让它继续处理剩余文件。这样避免它以错误的方式重复处理了一百个文件。批量任务最怕的不是慢而是方向从一开始就跑偏了。7.4 持续复盘对话历史我会定期翻一翻和 Cursor 的对话历史把那些“我一开始描述不清、它猜不到、后来换措辞才成功”的例子整理出来看看自己表达上的问题。很多时候不是它笨而是我给出的信息不足以支撑它动作。复盘之后我会把常用指令不断迭代。比如我发现说“帮我改一下这个接口”太模糊现在我会直接说“把入参里的 userId 改为从上下文中获取并保留原有校验逻辑”。表述习惯改掉了生成的代码质量也跟着提升。8. 常见问题与排查技巧实录8.1 它改到一半停下来怎么办Agent 在长任务中偶尔会中断常见原因包括响应过长、需要确认信息或碰到了它认为的边界。我的处理方式是先看它停在哪一步如果只是继续执行下一步就让它接着做如果它停下来是因为发现了与我描述不一致的地方我会先确认后再让它继续。千万不要在没看停在哪个文件的时候就直接点重试。那样它可能会从头再来或者跳过中间步骤反而浪费更多时间。8.2 上下文太多导致答非所问如果对话历史已经很冗长它可能把前面早该遗忘的信息又翻出来导致答非所问。我的习惯是一旦发现它开始引用无关内容就新建一个对话只带上当前任务最关键的文件路径和需求描述。这听起来像是自己麻烦了点但效果立竿见影。新的上下文越干净它的判断越直接。8.3 生成的代码不符合项目规范最常见的原因是项目规则没配或者配得太粗。靠对话里一句“请遵守代码规范”几乎没用只有项目规则文件里写清楚每次生成时才会默认生效。另外可以主动让它跑一遍检查工具。比如告诉它“用项目里的 lint 规则检查你的改动”它通常会先看配置文件再改。就算不能自动跑命令它也能照着规则自查一遍。8.4 补全质量突然下降如果之前补全很准突然变得不准了先别怪模型。检查一下是不是当前打开了很多无关文件导致上下文被无关代码占满了。我一般会关掉暂时不用的标签页只保留当前修改文件和相关依赖文件补全质量通常马上回来。还有一个容易被忽略的原因我改了函数名但没改引用处代码上下文存在矛盾信号它自然不知道往哪个方向补。这时候先手动消掉编译错误再试补全。8.5 问题定位与排查速查表现象可能原因处理方式Agent 改了无关文件上下文里挂载了太多文件重开对话明确允许修改的目录代码风格不统一项目规则文件缺失在 .cursor/rules 里补充约定补全越来越慢/不准无关文件打开的太多清理标签页收缩上下文建议使用不存在的 API模型记忆过期贴最新文档让它基于文档改写批量任务越改越乱没有先做单文件小样先改一个文件验证再继续批量核心逻辑被改动提示边界不清晰声明禁止修改区域或文件最后再分享一个我自己的小习惯每次用 Cursor 完成一轮较大的修改我都会在对话里让它用两三句话总结一下它做了什么。这个总结会直接变成我提交说明的草稿省掉不少回忆上下文的时间。这不算什么高级技巧却是我个人用得最频繁、收益最直接的一个操作。