三杯奶茶教你把Cursor变成靠谱搭档

“AI写代码不香？”——香，但你得先喂它菜单、配料和烹饪手册。

最近我们团队把Cursor当成每日例会的第四位同事。它负责整理需求、辅助开发、顺手再来一份回归检测。我们则负责把它从“实习生”培养成“靠谱合伙人”。以下是我们踩坑后的专业经验，包裹在刚好不过火的幽默里。

0. AI不是外包，是增强

请把Cursor当成聪明的新人：思路清晰、执行敏捷，但不知道你们的内部黑话。你要带着它逐步理解需求、梳理现状、订立规矩，再交给它写代码。这是整个实践的底层哲学。

1. 第一杯奶茶：用Cursor拆需求

1.1 喂它PRD，让它盘点要做什么

步骤就是——把PRD的链接扔给Cursor，然后严肃提醒它“只分析，不写代码”。好处是：

• 它会诚实地总结功能点，帮你快速抓住需求轮廓；
• 它会忠实地列出需要的实体、接口、表结构；
• 它不会忽悠你说“这些我都懂”，因为你会让它把思考写进 docs/技术设计.md。

提示词小贴士：明确说明不要涉及数据新建、保存。如果PRD没写清楚，你就摆事实讲逻辑；AI装糊涂，你就新开一个对话，把新版上下文全给它。

1.2 让它认识现有代码，别让新人乱翻仓库

Cursor对代码结构熟得很。我们借助 Mermaid Preview、Markdown Preview Enhanced 这类插件，给它丢 com.xxx.xxx.xxx.xxx.facade.SxxxxxxxxFacade#getxxxxxx 这样的切入口，让它画流程图、标注改动范围。它就像在教资考试面前拿着教材复习：不慌，但得有人翻页。

2. 第二杯奶茶：我们教它项目，换它递代码

生成代码之前，要填补PRD留下的空白，建立双方认可的“技术蓝图”：

• 统一命名规范：字段怎么叫、放在哪个包；
• 指定工具类、服务类的使用规则；
• 写清楚业务逻辑细节，必要时直接贴PRD原文；
• 有些流程没写明白？让Cursor先预留“TODO”，回头自己补。

我们在同一份功能分析文档上不断修订，直到AI和我们都点头：逻辑通顺、命名对味、边界明确。此时让Cursor“按功能点”生成代码，准确率会高得离谱。

顺便说一句，不要贪大求全。一次就盯一个功能点，把它写完、验证完，再进行下一个。拖到最后一口气生成全项目，相当于把同事的会议纪要压到周五晚上——灾难现场。

3. 第三杯奶茶：让Cursor陪你验收

3.1 改动范围盘点

老规矩，先来一句：

git diff origin/master > cr.diff

然后请Cursor阅读 cr.diff，写出改动总结。这就像让同事看代码改动，用一张白纸总结风险点。

3.2 代码规范巡检

我们贴心准备了 29 条检验规则，从“方法体不超 100 行”到“RPC 必须打 log”。要求Cursor逐条检查，还每条都开独立上下文，拒绝糊弄。结果是，它变成我们团队的“规范警长”，谁写忘了 log，AI第一时间喊“抓到证据”。

3.3 自测清单生成器

开发完了？把代码改动再喂给Cursor，让它列出自测用例表，覆盖：

• 正常流程；
• 边界输入；
• 异常处理；
• 状态校验。

输出形式是表格，包含编号、场景、预期。我们拿着表格测试，只需要在预期结果栏打钩，效率比“临时抓测试点”高多了。

4. 小结：人机协作闭环

• 拆需求：Cursor帮忙梳理PRD和存量系统，我们补全上下文；
• 写设计：我们主导技术蓝图，Cursor变身执行者；
• 做验证：Cursor提供改动摘要、自测清单，我们补脑补心补脚。

在这个“Cursor三杯奶茶策略”里，AI既不是魔法师，也不会替代开发。真正的价值在于：我们提问的能力、上下文管理的严谨性，再加上一点幽默和耐心。只要方法得当，AI就能成为那个永远不抱怨加班、还会主动写验收表的神队友。何乐而不为？