我用这3个Prompt模板让Cursor生成代码一次通过率从32%拉到81%
我花了三周时间，在同一个React项目里记录每次AI生成代码的通过率，终于找到了一套让Cursor稳定输出高质量代码的Prompt范式。32%到81%，差的不是AI的能力，是你组织需求的方式。
先看数据：32%是怎么来的
今年5月中我接手一个后台管理系统重构，技术栈React 18 + TypeScript + Ant Design 5。因为工期紧，项目一开始就计划用Cursor辅助编码。那时候我的Prompt大概长这样：
"用React写一个用户列表页面，带分页和搜索功能"
Cursor很听话，哗啦啦给我出了150行代码。问题来了：它自己发明的API，Antd里根本没有。分页组件的props名全部对不上号。TypeScript类型也乱标。编译直接报9个错误。
我把那段"一次通过"定义为：粘贴到IDE后零修改即可编译通过且功能跑通。
第一周的统计结果：87次生成，28次通过，通过率32.1%。
打脸来得很快。我原来以为Promp写得越随意AI越自由发挥，结果证明"自由发挥"和"胡说八道"在AI这里是同义词。
重新理解Prompt：你不是在提问，你是在交付需求
这个认知转变对我冲击很大。过去我一直把AI当成一个需要你解释问题的人，所以Prompt就写成问句或者模糊的愿望。实际上，Cursor这类编程AI的正确使用方式是：把它当成一个看不到你的屏幕、不知道你技术栈、不清楚你项目规范的新人开发者。你给它的信息越精确，它落地的代码越靠谱。
第三周我把Prompt改成了下面这个结构，通过率直接从32%拉到了81%。
模板一：组件级生成（通过率从32%提升到74%）
我把"用React写一个用户列表页面"改成了这样：
【当前技术栈】React 18.3 + TypeScript 5.5 + Ant Design 5.12
【当前文件路径】src/pages/UserManage/UserList/index.tsx
【已有依赖】antd/lib/table, @ant-design/icons/SearchOutlined,
antd/lib/input, dayjs@2.0
【类型定义-同目录 types.ts】
interface UserInfo {
id: string;
name: string;
email: string;
status: 'active' | 'disabled';
createdAt: string;
}
【API-同目录 api.ts】已导出:
fetchUserList(params: UserQueryParams): Promise<PageResult<UserInfo>>
【需求】实现用户列表页面：
1. 表格显示 name/email/status/createdAt 四个字段，status用Tag组件
2. 搜索栏：按name模糊搜索+status下拉筛选+日期范围筛选
3. 分页使用Antd Table内置分页，默认每页20条
4. 点击行跳转到详情页（路由 /users/:id）
5. 导出所有代码到当前文件，包含完整的import
这个模板拆开来说是五个关键块：
技术栈声明让AI不再自行发挥选择库。以前不写这个，Cursor会在代码里随机引入MUI、Chakra UI甚至它的幻觉库。
文件路径和已有依赖告诉AI当前项目上下文。Antd Table的导出来自哪个包，AI不需要猜。
类型定义和API是减少幻觉的核心。我发现AI编程出错最多的地方就是对接口和类型的假设。你把interface直接给它，它就不需要自己编。
**需求列表用"序号+具体描述"**而不是用自然段落。自然段落的歧义太大，编号列表+行为动词（显示/使用/点击/导出）直接把歧义消灭了。
实测数据：第二周同一个用户列表场景，按这套模板写的Prompt，20次生成15次一次通过，通过率75%。剩下5次失败集中在：3次分页事件绑定方式不兼容，2次日期选择器选了dayjs但用了moment的API——这些后来靠模板二解决。
模板二：约束豁免声明（通过率从74%提升到81%）
模板一解决了"生成什么"的问题，但没解决"不要生成什么"。经常遇到这种情况：让AI改一个服务层的函数，它顺手帮你把一个完全不相关的组件也改了，或者给每个函数都加上console.log。
第19天我开始在每个Prompt末尾加上约束声明块：
【禁止项】
- 不修改当前文件以外的任何文件
- 不在任何地方添加 console.log/debugger
- 不使用 any 类型（除非确实无法推断）
- 不引入未在上文声明的新依赖库
- 不改变已有函数的参数签名
这个块加入之后，通过率从74%又拉到了81%。别小看这7个点，它们覆盖的是AI的"过度热心"问题。Cursor这类工具在没有约束的情况下倾向于多做事，而编程里多做事大概率等于多出错。
一个细节：最后一条"不改变已有函数的参数签名"帮我避免了至少4次大规模重构。之前让AI给某个服务函数加一个日志拦截器，它顺便把整个文件8个函数的参数都加了logger?: Logger。项目里其他模块调用这些函数的地方直接炸了。
模板三：场景化RolePlay（适用于复杂逻辑）
对于纯CRUD页面，模板一二够用了。遇到复杂业务逻辑时——比如状态机、工作流、嵌套条件渲染——还需要加一个角色设定在前头。
你是一个精通React性能优化的高级前端工程师。当前代码的渲染性能出现问题，useMemo和useCallback使用不当。请分析当前文件的状态依赖关系，给出优化后的代码，要求：
[后面接模板一和二]
这个RolePlay经历了5个版本的迭代，最终稳定在最简洁的形式：身份+擅长领域+当前问题的一句话定性。不要写长篇大论的角色背景，AI不需要知道你"毕业于985计算机系，拥有8年大厂经验"，它只需要一个精准的领域锚点来激活对应的训练数据。
实测：复杂逻辑场景下，加了角色设定后一次通过率从41%（仅模板一+二）提升到68%。
三周实验的完整数据
| 周次 | 策略 | 生成次数 | 一次通过 | 通过率 |
|---|---|---|---|---|
| 第一周 | 随意描述 | 87 | 28 | 32.1% |
| 第二周 | +模板一 | 96 | 71 | 74.0% |
| 第三周 | +模板一+二 | 82 | 67 | 81.7% |
第三周额外测试了模板三的场景，不纳入上表（仅复杂逻辑场景，样本量较小，不做横向对比）。
写在最后
如果只能带一句话走，那就是：对AI写代码时，给它上下文、给它约束、给它退出边界。AI不是懒人工具，是效率放大器——但放大的前提是你得先把信号从噪声里分离出来。
模板拿走直接用，改一下技术栈就能适配你自己的项目。
