P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/HHX_01

前言

不知道你们用Cursor写代码有没有过这种崩溃时刻——

让它给Spring Boot加个接口，方法是写出来了，单元测试没影，OpenAPI文档没更，连路由命名都跟项目里其他接口画风割裂，像半路捡来的。

改来改去半小时过去，你一拍大腿：我自己手写都写完了！

还有重构goroutine那段更绝，它好心把你channel换成WaitGroup，逻辑看起来天衣无缝，结果藏了个竞态条件。你盯着diff看五分钟，眼睛都快瞅瞎了才揪出问题，血压直接拉满。

我用Cursor踩了一年坑，总算摸出规律：这玩意儿输出质量好不好，7分看你怎么问，3分看模型本事。不是Cursor不行，是你给的信息太模糊，它只能瞎猜。

一、先把任务边界焊死，别让它自由发挥

技巧1：别再说“帮我改一下”，你当它会读心啊

“改一下”这三个字，对Cursor来说就是开放式命题，全靠脑补。你说“优化下性能”，它都不知道是解决N+1还是减内存，可不就给你整个半成品嘛。

**反面教材：**帮我改一下这个接口，性能搞高点。

**正确姿势：**重构OrderService.getOrderList()，就干一件事：解决N+1查询。要求：用@EntityGraph替换懒加载，只查order和orderItems；方法签名别动；别加新缓存；改完顺手补单元测试。

目标、约束、验收标准全给齐，它不用猜，直接照着清单干，出错概率直接砍半。Go开发也一样，别说“解决goroutine泄漏”，得说清哪个goroutine、啥场景漏、能不能用context.WithTimeout，精准打击才有用。

技巧2：别哐哐粘贴代码了，@一下比啥都强

很多人写Prompt，上来粘两百行代码。先不说挤不挤上下文，你粘的是快照啊朋友！你这边刚改了两行，它还拿着老版本在那写，能对才怪。

Cursor的@符号就是干这个的，直接让它读当前文件，省token还精准。常用的就这几个：

• @文件名：精准指定某个文件，日常用得最多
• @Codebase：不知道代码在哪，让它全库搜
• @Docs：拉官方文档，防止它整过期语法
• @Web：实时查最新资料，版本兼容啥的
• @Git：看最近提交，找锅用

**反面教材：**粘200行代码：帮我给这个类加缓存

正确姿势：@OrderRepository.java @CacheConfig.java 给findByUserId加Redis缓存，key格式按CacheConfig里的规范来，TTL30分钟，空值防穿透。

不用粘代码，它自己读文件，连命名规范都能自动对齐，省老事了。

技巧3：一定要说清楚“什么不能动”

Cursor默认是“热心肠”模式，你让它加个方法，它可能顺带给你重命名变量、调格式，连你故意留的逻辑都给改了，主打一个画蛇添足。

尤其是gRPC生成的stub代码，你要是不说，它说不定都敢给你改了，到时候proto重新生成直接白干，哭都来不及。

**反面教材：**帮我在PaymentService里加个退款方法

**正确姿势：**在@PaymentService.java新增refund方法。约束：现有方法签名和逻辑一概别动；类字段不许改；异常处理跟charge方法保持一致。

加上约束段，它就知道这是“只增不改”的活，不会瞎折腾。Go项目同理，把“不改interface”“沿用errors.Wrap风格”“不引新包”写上，你review diff的时间能少一半。

二、复杂任务别硬上，拆解开稳得一批

技巧4：复杂活先开Plan Mode，别上来就干

直接让它改复杂逻辑，它就是边想边写，写着写着方向就偏了。等你发现的时候，改了一堆不该改的，回滚都麻烦。

Plan Mode就是把“想”和“做”拆开，Shift+Tab就能切，先出计划，你审完没问题再执行。

**反面教材：**帮我把UserService里的数据库调用改成异步的
结果它把强一致的调用也改异步了，坑死人。

正确姿势：[Plan Mode] 把@UserService.java的数据库调用改异步。先告诉我：哪些方法该改异步、哪些必须同步（说理由）；用CompletableFuture还是Spring @Async；事务会受啥影响。

它会给你出个Markdown计划，你觉得不对直接改，删错的加漏的，再点执行。比写完再改高效一万倍，计划还能存起来下次用。

技巧5：一次只干一件事，别用“并且”串一堆

有人写Prompt，跟报菜名似的：加限流、改响应格式、再加日志。你以为是打包优惠，实则它注意力分散，每件事都做不透彻。

上下文窗口就那么大，塞的事越多，出错概率越高。分开来，每次聚焦一件事，质量稳太多。

**反面教材：**帮我给这个接口加限流，并且改成统一响应格式，再加上日志

**正确姿势：**分三次来：
第一次：给接口加限流，每秒100次，超限抛异常，别的不动
第二次：把返回值改成ApiResponse格式，参考已有写法
第三次：加INFO日志，记入参和耗时

改完一步看一步diff，比混在一个commit里好review多了。

三、质量风格怎么对齐？别描述，给例子

技巧6：别让它“风格一致”，直接甩个参考文件

“跟项目风格保持一致”这句话，说跟没说一样。啥叫一致？命名、注解、异常处理，哪方面一致？它全靠蒙。

不如直接给它一个现成的好例子，告诉它参照哪几点，比你描述半天管用。

**反面教材：**帮我写个新Repository，风格跟其他的一致

**正确姿势：**参照@OrderRepository.java的结构，新建RefundRepository。参照这几点：@Repository注解位置、findBy前缀命名、@Transactional加在哪、错误用Optional返回。新类要这几个方法：findByOrderId、findByUserId、save。

Go也一样，甩个写得好的handler过去，说“按这个模式写”，比你列十条注意事项准多了。

技巧7：把验收标准写死，让它知道啥叫“做完了”

Cursor默认标准是“能编译就行”，你不说清楚，它写个能跑的就交差，测试、边界情况一概不管，妥妥的半成品。

把验收标准一条条列出来，它会照着逐条核对，你最后直接检查这几条就行，不用自己想漏了啥。

**反面教材：**帮我写个分页查询接口

**正确姿势：**在@OrderController.java写GET /orders分页接口。验收标准：

1. page从1开始，pageSize默认20
2. pageSize超100返回400
3. 返回PageResponse，带total、pages、data
4. 补三个测试用例：正常、边界值、非法参数
5. Swagger注解写全

Go场景也能用，比如“benchmark压1万次p99小于5ms”“go vet和staticcheck全过”，可量化的标准才有用。

四、避坑神技，减少无效返工

技巧8：对话聊飘了就重开，别死磕

一个对话聊多了，上下文堆得满，Cursor就开始失忆，重复修过的问题，或者扯之前的话题，跟喝多了似的。

这不是bug，是上下文窗口的物理极限，别硬掰。直接开新对话，用@Past Chats把有用的历史带过去，重新聚焦。

**反面教材：**不对！我之前说过要用CompletableFuture的！你怎么又忘了！

**正确姿势：**开新对话，引用之前定好方案的对话，直接说：按之前定的CompletableFuture方案，给findOrdersByUserId加3秒超时，超时抛指定异常。

一个对话干一件完整的事，干完就开新的，稳定性直接上去。

技巧9：写代码前先列假设，别让它瞎猜

信息不全的时候，Cursor会自己脑补假设，但它的假设往往跟你想的不一样。比如你说加邮箱验证，它默认发真实邮件，有效期15分钟，失败返400；结果你要的是测试SMTP、5分钟、返422，全对不上。

让它先把假设列出来，你确认完再写代码，花1分钟，省10分钟改代码。

**反面教材：**帮我给用户注册加邮箱验证

**正确姿势：**实现邮箱验证前，先列你的假设：用什么发邮件、验证码有效期、已验证用户重复触发怎么处理、验证失败返回什么状态码。列完等我确认再写。

一条条核对过去，方向错不了。

技巧10：常用规范写进规则文件，别每次重复敲

如果你每次Prompt都要写“用SLF4J别用System.out”“接口返回用ApiResponse包装”，纯纯重复劳动。

这些通用约束，直接写进.cursor/rules下的.mdc文件，Cursor会自动加载。比如Java后端规范，把日志、返回值、异常、测试规范全写进去，以后就不用每次都提。

要是某次需要例外，比如某个方法要本地try-catch，就在当次Prompt里说清楚本次例外就行。规则管通用，Prompt管特例，分工明明白白。

最后唠两句实在的

这10招每次都要用？当然不用。改一行日志用第一招就够，复杂架构改动再上Plan Mode，团队协作规范多用规则文件。按需取用，不是堆得越多越好。

Prompt越长越好？别扯。“不改方法签名”是有用信息，“你是顶级Java工程师”纯废话。要信息密度，不要字数。

还有人说Cursor固执不听劝，别在一个对话里反复掰扯。开新对话，把约束和为啥不能那么写的理由说清，它基本就不会跑偏了。

说白了，Cursor不是你肚子里的蛔虫，是个接需求干活的协作方。你需求写得清楚，约束给得到位，验收标准明确，它输出就准；你甩一句“帮我改改”，它就只能给你猜一个答案。

把这几招用熟，你会发现不是Cursor变好用了，是你会提需求了。以后再有人抱怨Cursor写的代码垃圾，你就把这篇甩给他——多半是他Prompt写得太随缘。

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/HHX_01