上周三下午同事老张在群里发了一张截图Cursor 把一个项目里根本不存在的getUserInfoById函数写进了代码还煞有介事地补上了注释和异常处理。他甩了一句这玩意儿就是人工智障。我让他把当时的对话记录发过来问题一眼就看清了他只丢了一句帮我加个查询用户的功能没说改哪个文件没说项目用的哪套数据访问封装更没提团队对返回值的约定。模型当然只能靠猜。这个场景我在带团队做 AI 辅助编码 的两年里见过太多次。Cursor 这类工具的能力上限确实很高但它不会读心。它每次真正能看见的东西是有限的你打开的文件、你主动引用进去的内容、项目根目录下配置的规则文件以及它自己建立索引后召回的代码片段。你给的信息越模糊它能发挥的想象空间就越大幻觉自然越多。所以这篇不打算再讲一遍 Cursor 怎么下载安装、怎么点开对话框——那类内容网上已经泛滥了。我想聊的是更值钱的那部分怎么组织上下文怎么设计提示词怎么在动老代码的时候不翻车以及怎么把界面和模型调成顺手的状态。这套方法我自己跑了很久也带着团队二十来号人一起用过踩过的坑都写在下面你可以直接抄也可以按自己项目的脾气改。1. 先搞清楚模型在编辑器里到底看见了什么很多人对 Cursor 的期待是它应该知道我整个项目。这个期待本身没错但知道是有前提的。理解它获取信息的三个来源是后面所有技巧的地基。搞不清楚这一点你写再花哨的提示词也是白搭。1.1 三个信息源打开的文件、索引召回、你主动喂的内容第一个来源是你当前打开的文件和光标附近的代码。这部分是强上下文模型看得最清楚权重也最高。你在OrderService.java里问这个方法的边界条件对不对它默认就在这个文件里找答案。第二个来源是项目索引。Cursor 会扫描你的代码库建立一套可检索的索引然后在你提问时按相关度召回若干片段。注意这里的词是召回——不是全量加载。召回靠的是相似度匹配所以如果你的命名很随意比如一堆util1、helper2召回质量会断崖式下跌。这也是为什么我总跟团队强调命名规范在 AI 时代不只是给人看的也是给索引看的。第三个来源是你主动提供的内容用引用的文件、粘贴进来的报错栈、贴进去的接口文档。这是最可控、最精准的一路。老手和新手最大的差别往往就体现在这一路上——新手指望索引自动找到老手直接把关键文件点到模型脸上。1.2 上下文窗口的有效容量其实远小于标称值现在动不动就是几十万 token 的上下文窗口看着很唬人。但我在实践中发现真正有效的容量要打个大折扣。原因有两个一是模型对长上下文中间部分的注意力天然衰减业界叫lost in the middle开头和结尾的信息记得牢中间那一大坨容易被忽略二是无关内容会稀释相关内容的权重你塞进去十份不相干的文件反而会干扰它对关键文件的判断。我做过一次很朴素的对比测试同一个改动任务一次只给三个核心文件加一段接口说明另一次把二十个文件全进去。前者一次过后者反复纠正了四五轮还改错了一个不相干文件的逻辑。从那以后我就定了条规矩——单次对话引用的文件不超过五个能三个解决就绝不给四个。提示判断该给哪些文件的标准不是可能相关而是这次改动一定会碰到的。前者会把范围撑爆后者才是精准打击。1.3 我第一次翻车的经历把整个仓库喂进去说个具体教训。有次要重构一个订单状态流转的逻辑我想着让 AI 全面了解背景就把整个订单模块三十多个文件全引用进了对话然后让它给重构方案。结果它给的方案里把两个功能重复但职责不同的类合并了还自作主张删掉了一个看似没用到、实际上被反射调用的方法。这个坑不怪模型怪我把全景图当成了决策依据。后来我换了做法先让它在只读模式下帮我梳理调用链我自己确认哪些是死代码、哪些是框架反射调用的再把确认过的结论连同三五个核心文件交给它出方案。同样的任务第二轮一次就对了而且改动范围比我原本预想的还小。真正读懂代码这件事本质上是你先读懂再教它读懂而不是全丢给它让它替你读懂。这个顺序颠倒了后面全是麻烦。2. 把项目喂给 Cursor 的三层上下文策略搞清楚信息源之后接下来就是怎么系统性地喂。我把它分成三层长期不变的规则、中期可检索的索引、短期精准的对话上下文。三层各管各的事别混着用混着用就乱。2.1 规则文件把项目的家规一次性写进去Cursor 支持在项目里放规则文件用来告诉它这个项目的约定。这是投入产出比最高的一步写一次之后每次对话都自动生效。我在规则文件里通常固定写这几类内容技术栈和版本框架、语言版本、构建工具的关键版本号避免它按老版本的 API 给建议。目录结构与职责边界哪个目录放什么哪些层之间允许互相调用。比如Controller 只做参数校验和编排业务逻辑一律下沉到 Service。命名与风格约定包名、类名、方法名的命名习惯注释语言异常处理方式。禁止事项不许引入新依赖、不许改公共接口签名、不许用某个已经被废弃的工具类。我见过太多人写完规则就不管了结果规则里还留着上一代框架的说明模型照旧按错的来。我的习惯是每个季度花二十分钟过一遍规则文件删掉过期的补上新增的。这份文件本身就是项目的一份活文档。2.2 索引不是万能的命名质量直接决定召回质量如果你的项目命名一团糟别指望索引能救你。我做过一个粗略的对照两个功能类似的服务一个方法叫calculateDiscount另一个叫doCalc2。当我问优惠计算逻辑在哪里的时候前者几乎每次都能被准确召回后者十次里有七八次找不到。所以我会给团队一个很朴素的建议AI 时代写代码命名要像写搜索关键词一样写。方法名里带上业务动词和业务名词别用handle、process、do这种万能词。这不只是为了 AI三个月后你自己回头看也全靠它。另外索引对注释也敏感。关键类和方法上写一句清晰的中文或英文说明能显著提升召回命中率。注释别写成这个方法用于处理数据这种废话写成根据用户等级和历史订单量计算阶梯折扣折扣上限 30%信息密度完全不一样。2.3 对话级别的上下文一次只解决一个模块的问题到了具体对话这一层我的原则是一次对话只服务一个明确目标。想让 AI 顺手把日志格式也改了、把单测也补了看着省事实际上每一次追加需求都在污染上下文前面聊过的无关内容会持续干扰后面的判断。我通常这么组织一次对话先用一句话说清楚目标和边界比如只改OrderService里的支付回调逻辑不动其他文件。再给出必要的背景通常是 2 到 4 个文件加上关键接口的说明。最后提出验收标准比如改完后同类异常要统一走BizException并且保持原有日志格式不变。一件事结束了就开新对话。别舍不得上下文这东西越干净越值钱。层级作用范围更新频率典型内容规则文件整个项目每季度过一遍技术栈、目录约定、禁止事项索引召回全仓库检索随代码自动更新依赖命名和注释质量对话上下文单次任务每次任务重置核心文件、接口说明、验收标准3. 可复用的提示词骨架从帮我写到按约定改提示词这件事被过度神话了。网上流传的各种魔法提示词大多没什么用真正管用的是结构清晰、约束明确、验收可查。我用的模板很简单四个部分任务、背景、约束、验收。下面拆开讲最后给一套可以直接抄的模板。3.1 任务描述一句话说清改什么而不是做什么功能新手喜欢写帮我实现一个优惠券功能这属于产品需求不是编程任务。老手会写在CouponService里新增applyCoupon方法输入用户 ID 和优惠券码输出折扣金额或抛出业务异常。差别在哪前者要模型自己拆需求拆的过程中它会补大量假设后者你已经拆完了它只需要填实现。你要把脑力活留给自己把体力活交给它。这不是不信任 AI而是决策权本来就该在人手里。3.2 约束条件把不许做什么写清楚比写要做什么更重要模型最大的问题不是不会写而是太爱自由发挥。所以约束这一块我写得比任务描述还细。常见的约束项不许新增第三方依赖。不许修改已有方法的签名。数据库访问必须走现有的XxxRepository不许直接拼 SQL。异常统一使用项目里的BizException错误码从常量类取。保持现有代码风格缩进、命名、注释语言与所在文件一致。这些约束看着琐碎但每一条都对应着一类真实翻车。我印象最深的一次是没有限定不许新增依赖结果模型为了省事引了一个 JSON 库进来而我们项目里已经有一个封装好的工具直接导致打包体积多了一兆多代码审查时才被发现。3.3 验收标准让 AI 自己先检查一遍写完实现不等于写完任务。我会在提示词里加一段验收标准让它给出结果前自己核对。这一段能拦下相当一部分低级错误。举个例子改一个查询接口时我会写验收标准1. 入参校验覆盖空值和越界2. 分页参数默认值与原实现一致3. 返回结构与原接口完全兼容字段名不变4. 不产生额外数据库查询沿用原有查询方法。模型看到这种明确的检查项会主动回头比对比你说帮我仔细检查一下有效得多。仔细一点这种话它理解不了具体到字段名和查询次数它才理解得了。3.4 一套完整的提示词模板下面这套我用了很久改改就能用【任务】 在 文件路径 的 方法名 中 具体改动。 【背景】 - 相关文件文件 A 的职责、文件 B 的职责 - 调用方约定谁在调用、期望的输入输出 【约束】 1. 不新增依赖不改动已有公共方法签名 2. 数据访问统一走 Repository 名 3. 异常使用 异常类名错误码取自 常量类 4. 代码风格与所在文件保持一致 【验收】 1. 可验证的检查项一 2. 可验证的检查项二 3. 可验证的检查项三 【输出要求】 先说明改动点再给完整方法代码不要省略中间部分。这套模板最大的好处是省事。你把它存成代码片段每次填空就行不用临场组织语言。团队里新人上手也是靠它两周基本就能写出质量稳定的提示词。注意不要在提示词里写以上之前说的那些这类指代模糊的话。AI 的记忆没有那么可靠每次把关键约束复述一遍成本很低收益很高。4. 改老代码比写新代码难让 AI 安全动刀的操作流程写新功能的时候AI 犯错最多是浪费时间。但改老代码的时候它犯错可能直接搞出线上事故。这一块我踩的坑最密也总结出了最固定的一套流程核心思路就一句先侦察再动刀每步留退路。4.1 先做只读侦察别急着让它写代码面对一个自己不熟的老模块我第一步永远是让 AI 梳理现状明确告诉它只读不要改任何代码。通常让它输出这样几样东西目标方法的调用链谁调用了它它又调用了谁。相关的数据模型和字段含义。代码里能看出来的隐含约定比如某些参数为 null 时的特殊处理。这一步的价值在于把我以为变成文档里能看到。很多时候我自以为知道某个字段的用途让 AI 一梳理才发现它被两个完全不同的入口以不同语义使用。这种发现如果发生在改动之后代价就大了。4.2 影响面分析问清楚改了会波及谁侦察完现状下一步是分析影响面。我一般会问三个问题如果改这个方法哪些调用方受影响有没有测试覆盖这段逻辑有没有和它同名或功能相近的方法容易混淆。这一步经常能挖出惊喜。有一次我准备改一个看起来没人用的工具方法让它帮我查调用方结果发现它被一个定时的对账任务间接调用那个任务每天凌晨跑一旦签名变了就会静默失败。这种链路靠人肉翻代码几乎找不到交给索引去查反而又快又准。如果项目测试比较全我会让 AI 顺便列出应该覆盖但还没覆盖的场景作为回归清单。4.3 小步提交给每一步留好回滚点改动阶段我坚持两个原则。第一一次只改一件事改完立刻本地跑一遍。第二每次改动前确认工作区是干净的改完先看 diff 再决定是否提交。具体流程大概是先让 AI 给出实现方案和改动清单我审方案方案没问题让它按清单改但要求逐文件改每改完一个文件停下来让我确认。这个停下来很关键很多工具默认一口气改完一大片等你看清楚的时候已经混在一起了。逐文件确认能让你始终掌握改动边界。改动中间出现意外的时候我从不试着一层层往回退直接git checkout回到干净状态重来。上下文脏了跟模型聊下去只会越来越偏。4.4 常见翻车现场与对应处理现象真实原因处理方式改了不该改的文件没限定改动范围索引召回带进了无关文件提示词里明确文件路径白名单删掉了看起来没用的方法模型看不到反射调用、配置驱动调用提前让它列出调用方人工确认引入了新依赖没写禁止新增依赖的约束约束段固定写死逻辑对了但风格突变没要求跟随文件原有风格加一条风格与所在文件一致反复改还是不对上下文污染前面对话干扰后面对话开新对话重新组织最小上下文这张表里的每一条我都是真金白银踩出来的。尤其是最后一条很多人最大的问题是舍不得关对话觉得前面聊了那么多记录不能浪费。恰恰相反聊得越久越该关。5. 把手头的工具调顺界面、模型与隐私的取舍工具用得顺不顺很大程度取决于有没有把它调成自己习惯的样子。这部分偏配置但同样是实践的一部分尤其对刚上手的人前半小时的配置体验直接影响后面愿不愿意继续用。5.1 界面语言中文界面到底值不值得切不少人纠结要不要把界面切成中文。我的建议是界面语言按你自己阅读效率最高的来没必要因为别人都用英文就硬扛。日常操作就那么几个菜单中文界面上手更快减少前期的认知负担。设置入口通常藏在首选项里有个语言选项切换后重启生效。要注意的是界面语言只影响菜单和按钮文案不影响它生成代码所用的语言。代码里的注释和命名用什么语言取决于你的项目约定和你在规则文件里怎么写的跟界面语言完全是两码事别混淆。如果你的团队代码注释统一用中文就在规则文件里明确写注释使用中文比在界面上折腾语言设置有用得多。5.2 模型选择与额度分配贵的模型用在刀刃上不同模型的能力和消耗差别很大。我的分配逻辑很朴素需要理解大范围上下文、做跨模块推理的时候用好模型格式化、写注释、补简单单测这种活用快模型就够了。具体到日常我大致是这么分的架构梳理、复杂重构方案、疑难 bug 定位用好模型一次想清楚。常规功能实现、单元测试、代码解释中等模型够用。改注释、调格式、简单重命名快模型追求速度。额度有限的话最容易浪费的地方就是用贵模型干小事。反过来在关键决策上省额度是最不划算的一次判断失误带来的返工成本远超那点额度。5.3 隐私与本地部署什么情况下值得折腾如果项目涉及敏感数据或闭源要求严格本地部署模型是个可选项。我的经验是本地模型适合承担那些不联网也能干的活写注释、补文档、解释一段代码、生成简单的测试桩。复杂推理和跨模块分析本地模型的体验目前还是有明显差距。另外一点心得先把规则文件写清楚再考虑本地部署。很多人上来就折腾本地环境配了半天发现效果不理想其实问题不在于模型部署在哪而在于根本没告诉模型项目是干什么的。上下文做得好中等模型也能给出可用的结果上下文做得差最强的模型也只能瞎编。场景推荐做法理由敏感代码的分析本地模型 明确规则数据不出本地复杂重构方案强模型 精简上下文需要跨模块推理补注释与文档快模型批量处理任务简单追求效率新项目上手先写规则文件一次投入长期受益6. 让这套流程沉淀下来从个人技巧到团队习惯一个人用得爽不算本事能让整个团队稳定产出才算。这一部分是我花时间最多的地方也是我见过的团队里最容易忽略的环节——大家各自摸索各自的提示词重复踩同样的坑经验完全没法传递。6.1 把提示词和规则文件纳入版本管理这是个很小的动作效果却很明显。我们在仓库根目录建了一个专门的目录放两类文件一类是项目规则所有人共用另一类是常用提示词模板按场景分文件比如新增接口修 bug写单测各一个。好处有三个。新人入职第一天就能用上团队积累的经验不用再从零摸索。提示词改进了能同步给所有人不会出现只有老王会写提示词这种局面。规则文件跟着代码走代码变了规则也能一起评审和更新。我踩过的一个坑是一开始只在文档平台放了一份提示词结果半年后没人看了因为大家写代码时不会主动打开另一个平台。放进仓库就不一样随手就能打开改起来也有记录。6.2 代码审查里怎么用 AI边界在哪AI 参与代码审查我持谨慎欢迎的态度。我们的做法是先让 AI 做一遍机械性检查再由人做判断性审查。AI 擅长的是那些有明确规则的事命名是否一致、异常是否统一处理、有没有明显空指针风险、日志格式是否规范、测试是否覆盖了新增分支。这些交给它又快又不容易漏。人不该让位的是判断性的事这个抽象是否合理、这段逻辑放在这一层对不对、这个改动会不会影响别的业务语义、这个方案半年后还好不好维护。这些问题没有标准答案AI 给出的意见往往似是而非照单全收反而容易改出问题。我个人的习惯是每次审查前先让 AI 列一份需要重点看的地方然后逐个自己判断而不是直接让它给结论。6.3 我自己坚持的几条硬规矩用了两年多我总结出几条不太会变的规矩写在这儿供参考第一不理解的代码不合并。AI 生成的每一行我都要能说清楚它为什么这么写。说不清楚的要么搞懂要么重写。这条听起来笨但能挡住绝大多数隐患。第二关键路径人工写。涉及资金、权限、数据一致性这类逻辑我自己动手AI 只用来做检查和补测试。不是不信任工具是这类逻辑的出错代价太高不值得赌。第三每次任务开新对话。这条前面说过但值得再强调一次它是我所有习惯里收益最高的一个。第四规则文件当活文档维护。每个季度过一遍过期内容删掉新约定补上。这份文件的寿命比任何一个提示词都长。最后分享一个小技巧当你发现某个提示词效果特别好的时候别只看结果回头想想是哪个部分起了作用。我自己的模板就是一次次这样拆出来的从最早的一整段大白话慢慢收敛成任务、背景、约束、验收四段式。这个过程没有捷径但每一次优化都能复用很久。Cursor 这类工具还在快速变化今天的技巧明天可能就过时了。但有一点不会变你能不能把一个任务讲清楚决定了工具能帮你到什么程度。把上下文管好、把约束写清、把验收定死这三件事做扎实换什么工具都不会太差。