让 Cursor 给你的 Spring Boot 服务加一个接口它给你写了个方法但没有写测试也没有更新 OpenAPI 文档路由规则也跟项目里其他接口风格不一样。改了一圈还不如自己写快。或者让它重构一段 goroutine 代码结果它把你的 channel 改成了 sync.WaitGroup逻辑倒是通了但引入了一个新的竞态条件。你盯着 diff 看了五分钟才看出哪里不对。我用 Cursor 写代码一年多踩过的坑让我得出一个结论Cursor 给出的答案质量70% 取决于你怎么问30% 才是模型本身的能力。不是 Cursor 不够好——是你给它的信息不够好它只能乱猜。下面 10 个技巧每一个都附有原理解释和 before/after 对比。全是后端场景没有废话。10 个 Cursor Prompt 技巧速查图10 个技巧按场景分类按需取用技巧 1给任务加边界不要说「帮我改一下」原理「改一下」对 Cursor 来说是个开放指令它会基于上下文推测你的意图。推测错了给你的就是半成品。边界越清楚推测空间越小输出越准。Before坏 Prompt帮我改一下这个接口让它性能好一些After好 Prompt重构 OrderService.getOrderList() 方法目标减少 N1 查询。要求用 EntityGraph 替换懒加载只拉 order orderItems不改方法签名不引入新的缓存层改完后在同文件里补充对应的单元测试第二版明确了目标N1、约束不改签名、不加缓存还追加了验收条件补测试。Cursor 不需要猜你想要什么直接按清单执行。这个技巧在 Go 场景下同样成立。比如让它处理 goroutine 泄漏你需要告诉它哪个 goroutine、在什么条件下泄漏、是否允许引入 context.WithTimeout而不是「帮我解决 goroutine 泄漏问题」。技巧 2用 符号引入上下文而不是粘贴代码原理把代码粘到对话框会快速占满 context window而且模型看的是你粘进来的快照不是文件的最新状态。filename 让 Cursor 直接读当前文件更省 token语义更准。Cursor 的 符号有 8 种类型后端最常用的是这几个 类型 适用场景文件名 引入某个具体文件如 OrderService.javaCodebase 让 Agent 全库搜索相关代码不知道在哪就用它Docs 引入官方文档防止 Cursor 用过期 API 语法Web 实时查网上的最新信息比如框架 changelogGit 引用最近的提交做「这次改动有什么问题」分析Before坏 Prompt[粘贴了 200 行代码]帮我给这个类加一个缓存层After好 PromptOrderRepository.java CacheConfig.java在 OrderRepository 里给 findByUserId 加 Redis 缓存缓存 key 格式参考 CacheConfig 里已有的命名规范TTL 30 分钟缓存穿透用空值处理不需要粘贴代码Cursor 会读文件当前状态。有命名规范的文件也引进来它会自动对齐风格。Cursor 符号速查后端工程师最常用的 5 种图 符号 5 种类型及使用频率速查技巧 3告诉 Cursor「什么不要动」原理Cursor 默认是「完成任务型」如果你不说清楚边界它可能顺手动一些它认为可以改的地方比如重命名变量、调整格式、改掉你故意保留的逻辑。Before坏 Prompt帮我在 PaymentService 里加一个退款方法After好 Prompt在 PaymentService.java 里新增 refund(Long orderId, BigDecimal amount) 方法。约束不修改现有任何方法的签名和逻辑不改变类的字段异常处理风格跟 charge() 方法保持一致加了「约束」段之后Cursor 知道这是个「只增不改」的任务。这个技巧在 gRPC stub 代码里尤其重要——你的 proto 生成代码不能被它改动必须显式告知。对于 Go 项目常见的约束是「不改 interface 定义」、「不改 error 类型沿用项目里的 errors.Wrap 风格」、「不引入新的 package」。把这些写进 Prompt你 review diff 的时间至少减一半。技巧 4用 Plan Mode复杂任务先出计划再执行原理直接让 Agent 执行复杂任务它会边想边写容易写到一半改方向或者漏掉你以为它会做的步骤。Plan Mode 把「规划」和「执行」拆开你可以在执行前检查并修改计划把不对的地方提前拦下来。激活方式在 Agent 输入框按 Shift Tab 切换到 Plan Mode。Before直接执行帮我把 UserService 里的同步数据库调用改成异步的Cursor 直接开始改你发现它把某些需要强一致的调用也改异步了回滚起来很麻烦。AfterPlan Mode 先出计划[Plan Mode] 把 UserService.java 里的数据库调用改成异步。需要先告诉我哪些方法应该改异步哪些必须保持同步理由用什么异步方案CompletableFuture 还是 Spring Async事务处理会有哪些影响Cursor 会生成一份 Markdown 计划列出它打算做的事。你审查后可以直接编辑计划——删掉不该改的方法加上你遗漏的约束然后再点执行。这比事后 review diff 要高效得多。计划可以保存到 .cursor/plans/ 目录下次接着做或者交给队友都方便。技巧 5一次只做一件事不要用「并且」连接两个任务原理Cursor 的上下文窗口是有限的。一个 Prompt 里塞两件事它会同时处理但注意力被分散两件事都做得不彻底。分成两次对话每次聚焦一件事输出质量明显更高。Before坏 Prompt帮我把这个接口加上限流并且把响应体改成统一的 ApiResponse 格式还有加一下日志After分三次做第一次OrderController.java给 getOrderList 接口加 RateLimiter 注解配置每秒最多 100 次请求超限时抛 RateLimitException不要动其他逻辑确认没问题后第二次OrderController.java ApiResponse.java把 getOrderList 的返回值改成 ApiResponseList参考 OrderController.java 里 createOrder 方法的返回格式第三次只给 getOrderList 加 SLF4J 日志记录入参和执行时间日志级别 INFO每次改完看一下 diff确认无误再做下一步。这比一次 commit 里三件事混在一起好 review 得多。技巧 6提供「好例子」而不是描述「我想要的风格」原理「风格一致」这种描述太抽象Cursor 无法量化。给它一个已有的好代码作为参照它会对齐格式、命名惯例、注释风格不需要猜。Before坏 Prompt帮我写一个新的 Repository 类风格要跟项目里其他 Repository 一致After好 Prompt参照 OrderRepository.java 的结构帮我新建 RefundRepository.java。要参照的点Repository 注解位置方法命名规范findBy 前缀Transactional 的使用位置错误处理用 Optional 返回新类需要的方法findByOrderId, findByUserId, save这个技巧在 Go 里也一样好用。给它看你项目里一个写得比较好的 handler然后说「按这个模式写一个新的」比你用文字描述「用 error wrapping、注意 defer 关闭资源、记得加 trace log」准多了。技巧 7明确指定验收标准让 Cursor 知道「做完」是什么意思原理Cursor 不知道你的完成标准是什么它给你一个能编译过的代码就会停下来。把验收标准写进 Prompt它会主动补全测试、处理边界情况而不是给你半成品。Before坏 Prompt帮我写一个分页查询接口After好 Prompt在 OrderController.java 里实现分页查询接口 GET /orders。验收标准支持 page从 1 开始和 pageSize默认 20参数pageSize 超过 100 时返回 400 错误返回 PageResponse包含 total、pages、data 字段在 OrderControllerTest.java 里补充三个测试用例正常分页、边界值、非法 pageSizeSwagger 注解完整Operation、Parameter这种写法里有「完成标准清单」Cursor 会逐条对照。你最后可以直接 review 这五条是否都满足不用自己去想还缺什么。Go 场景下验收标准可以是「benchmark 测试在 10000 次请求下 p99 5ms」、「用 go vet 和 staticcheck 都能通过」、「TestXxx 函数覆盖 happy path 两个 error path」。技巧 8上下文失焦时开新对话用 Past Chats 带走需要的部分原理一个对话里积累了太多内容后Cursor 的注意力会分散开始把早前讨论的方向和现在的任务混在一起产生奇怪的输出。这不是 bug是 context window 的物理限制。判断标准当你发现 Cursor 开始重复之前修过的问题或者它的输出和你几条 Prompt 之前讨论的东西相关但和当前任务无关时就该开新对话了。操作方式开一个新的 Composer 窗口用 Past Chats 引用你需要的历史对话片段在新对话里补充当前任务的完整上下文Before继续在失焦对话里挣扎
让 Cursor 给你的 Spring Boot 服务加一个接口它给你写了个方法但没有写测试也没有更新 OpenAPI 文档路由规则也跟项目里其他接口风格不一样。改了一圈还不如自己写快。或者让它重构一段 goroutine 代码结果它把你的 channel 改成了 sync.WaitGroup逻辑倒是通了但引入了一个新的竞态条件。你盯着 diff 看了五分钟才看出哪里不对。我用 Cursor 写代码一年多踩过的坑让我得出一个结论Cursor 给出的答案质量70% 取决于你怎么问30% 才是模型本身的能力。不是 Cursor 不够好——是你给它的信息不够好它只能乱猜。下面 10 个技巧每一个都附有原理解释和 before/after 对比。全是后端场景没有废话。10 个 Cursor Prompt 技巧速查图10 个技巧按场景分类按需取用技巧 1给任务加边界不要说「帮我改一下」原理「改一下」对 Cursor 来说是个开放指令它会基于上下文推测你的意图。推测错了给你的就是半成品。边界越清楚推测空间越小输出越准。Before坏 Prompt帮我改一下这个接口让它性能好一些After好 Prompt重构 OrderService.getOrderList() 方法目标减少 N1 查询。要求用 EntityGraph 替换懒加载只拉 order orderItems不改方法签名不引入新的缓存层改完后在同文件里补充对应的单元测试第二版明确了目标N1、约束不改签名、不加缓存还追加了验收条件补测试。Cursor 不需要猜你想要什么直接按清单执行。这个技巧在 Go 场景下同样成立。比如让它处理 goroutine 泄漏你需要告诉它哪个 goroutine、在什么条件下泄漏、是否允许引入 context.WithTimeout而不是「帮我解决 goroutine 泄漏问题」。技巧 2用 符号引入上下文而不是粘贴代码原理把代码粘到对话框会快速占满 context window而且模型看的是你粘进来的快照不是文件的最新状态。filename 让 Cursor 直接读当前文件更省 token语义更准。Cursor 的 符号有 8 种类型后端最常用的是这几个 类型 适用场景文件名 引入某个具体文件如 OrderService.javaCodebase 让 Agent 全库搜索相关代码不知道在哪就用它Docs 引入官方文档防止 Cursor 用过期 API 语法Web 实时查网上的最新信息比如框架 changelogGit 引用最近的提交做「这次改动有什么问题」分析Before坏 Prompt[粘贴了 200 行代码]帮我给这个类加一个缓存层After好 PromptOrderRepository.java CacheConfig.java在 OrderRepository 里给 findByUserId 加 Redis 缓存缓存 key 格式参考 CacheConfig 里已有的命名规范TTL 30 分钟缓存穿透用空值处理不需要粘贴代码Cursor 会读文件当前状态。有命名规范的文件也引进来它会自动对齐风格。Cursor 符号速查后端工程师最常用的 5 种图 符号 5 种类型及使用频率速查技巧 3告诉 Cursor「什么不要动」原理Cursor 默认是「完成任务型」如果你不说清楚边界它可能顺手动一些它认为可以改的地方比如重命名变量、调整格式、改掉你故意保留的逻辑。Before坏 Prompt帮我在 PaymentService 里加一个退款方法After好 Prompt在 PaymentService.java 里新增 refund(Long orderId, BigDecimal amount) 方法。约束不修改现有任何方法的签名和逻辑不改变类的字段异常处理风格跟 charge() 方法保持一致加了「约束」段之后Cursor 知道这是个「只增不改」的任务。这个技巧在 gRPC stub 代码里尤其重要——你的 proto 生成代码不能被它改动必须显式告知。对于 Go 项目常见的约束是「不改 interface 定义」、「不改 error 类型沿用项目里的 errors.Wrap 风格」、「不引入新的 package」。把这些写进 Prompt你 review diff 的时间至少减一半。技巧 4用 Plan Mode复杂任务先出计划再执行原理直接让 Agent 执行复杂任务它会边想边写容易写到一半改方向或者漏掉你以为它会做的步骤。Plan Mode 把「规划」和「执行」拆开你可以在执行前检查并修改计划把不对的地方提前拦下来。激活方式在 Agent 输入框按 Shift Tab 切换到 Plan Mode。Before直接执行帮我把 UserService 里的同步数据库调用改成异步的Cursor 直接开始改你发现它把某些需要强一致的调用也改异步了回滚起来很麻烦。AfterPlan Mode 先出计划[Plan Mode] 把 UserService.java 里的数据库调用改成异步。需要先告诉我哪些方法应该改异步哪些必须保持同步理由用什么异步方案CompletableFuture 还是 Spring Async事务处理会有哪些影响Cursor 会生成一份 Markdown 计划列出它打算做的事。你审查后可以直接编辑计划——删掉不该改的方法加上你遗漏的约束然后再点执行。这比事后 review diff 要高效得多。计划可以保存到 .cursor/plans/ 目录下次接着做或者交给队友都方便。技巧 5一次只做一件事不要用「并且」连接两个任务原理Cursor 的上下文窗口是有限的。一个 Prompt 里塞两件事它会同时处理但注意力被分散两件事都做得不彻底。分成两次对话每次聚焦一件事输出质量明显更高。Before坏 Prompt帮我把这个接口加上限流并且把响应体改成统一的 ApiResponse 格式还有加一下日志After分三次做第一次OrderController.java给 getOrderList 接口加 RateLimiter 注解配置每秒最多 100 次请求超限时抛 RateLimitException不要动其他逻辑确认没问题后第二次OrderController.java ApiResponse.java把 getOrderList 的返回值改成 ApiResponseList参考 OrderController.java 里 createOrder 方法的返回格式第三次只给 getOrderList 加 SLF4J 日志记录入参和执行时间日志级别 INFO每次改完看一下 diff确认无误再做下一步。这比一次 commit 里三件事混在一起好 review 得多。技巧 6提供「好例子」而不是描述「我想要的风格」原理「风格一致」这种描述太抽象Cursor 无法量化。给它一个已有的好代码作为参照它会对齐格式、命名惯例、注释风格不需要猜。Before坏 Prompt帮我写一个新的 Repository 类风格要跟项目里其他 Repository 一致After好 Prompt参照 OrderRepository.java 的结构帮我新建 RefundRepository.java。要参照的点Repository 注解位置方法命名规范findBy 前缀Transactional 的使用位置错误处理用 Optional 返回新类需要的方法findByOrderId, findByUserId, save这个技巧在 Go 里也一样好用。给它看你项目里一个写得比较好的 handler然后说「按这个模式写一个新的」比你用文字描述「用 error wrapping、注意 defer 关闭资源、记得加 trace log」准多了。技巧 7明确指定验收标准让 Cursor 知道「做完」是什么意思原理Cursor 不知道你的完成标准是什么它给你一个能编译过的代码就会停下来。把验收标准写进 Prompt它会主动补全测试、处理边界情况而不是给你半成品。Before坏 Prompt帮我写一个分页查询接口After好 Prompt在 OrderController.java 里实现分页查询接口 GET /orders。验收标准支持 page从 1 开始和 pageSize默认 20参数pageSize 超过 100 时返回 400 错误返回 PageResponse包含 total、pages、data 字段在 OrderControllerTest.java 里补充三个测试用例正常分页、边界值、非法 pageSizeSwagger 注解完整Operation、Parameter这种写法里有「完成标准清单」Cursor 会逐条对照。你最后可以直接 review 这五条是否都满足不用自己去想还缺什么。Go 场景下验收标准可以是「benchmark 测试在 10000 次请求下 p99 5ms」、「用 go vet 和 staticcheck 都能通过」、「TestXxx 函数覆盖 happy path 两个 error path」。技巧 8上下文失焦时开新对话用 Past Chats 带走需要的部分原理一个对话里积累了太多内容后Cursor 的注意力会分散开始把早前讨论的方向和现在的任务混在一起产生奇怪的输出。这不是 bug是 context window 的物理限制。判断标准当你发现 Cursor 开始重复之前修过的问题或者它的输出和你几条 Prompt 之前讨论的东西相关但和当前任务无关时就该开新对话了。操作方式开一个新的 Composer 窗口用 Past Chats 引用你需要的历史对话片段在新对话里补充当前任务的完整上下文Before继续在失焦对话里挣扎
)
)
