Vibe Coding提示词大全：各场景最优写法推荐

更新日期：2026-05-19 | 参考来源：Claude Code 官方指南、Lovable Prompting Bible、awesome-cursorrules（39,600⭐）

坦白说，绝大多数开发者编写的 Vibe Coding 提示词，从根源上就跑偏了。

这不是经验之谈，而是有硬核数据支撑的。Claude Code 官方最佳实践文档中一张对比表清晰显示：模糊提示与精准提示之间，生成结果的可用性差异高达 80%。Lovable Prompting Bible 更是一针见血——“首次生成时提供完整上下文”，是降低返工率最有效的策略，没有例外。而社区公认的规则库 awesome-cursorrules（GitHub 39,600⭐）已收录 197 条针对不同技术栈、专门用于抑制幻觉的规则。

那么，高质量提示词到底长什么样？下面按场景拆解了 40+ 条经过实战验证的模板，可直接复制使用。

为何多数人的 vibe coding 提示词本末倒置

问题不在于写作风格，而在于 AI 实际获取的信息量——差距天壤之别。Claude Code 官方文档中的对比表把这一点剖析得十分透彻：

这不是写作风格差异，而是 AI 接收到信息量的天壤之别。以下按场景整理 40+ 条可直接取用的提示词。

一、项目启动类（首次生成使用）

1.1 标准启动模板（Lovable / bolt.new 通用）

构建一个 [产品名称]，用于帮助 [目标用户] 解决 [核心问题]。

核心功能（MVP 必须有）：
1. [功能 1，越具体越好]
2. [功能 2]
3. [功能 3]

不需要的功能（第一版不做）：
- [排除项 1]
- [排除项 2]

数据结构：
- users 表（id, email, name, created_at）
- [其他表名]（[字段列表]）

UI 风格：[简洁专业 / 现代暗色 / 类似 Linear 的设计风格]
主色调：[颜色描述]
导航方式：[侧边栏 / 顶部导航]

为什么必须列出“不需要的功能”：AI 常自作主张添加功能，明确的排除项能有效避免生成无用代码。

1.2 从截图或设计稿出发

[粘贴截图或 Figma 截图]

参考这个设计，实现一个 [功能名称] 页面。
技术栈：React + Tailwind
数据先用 mock 数据，稍后再接真实 API。

1.3 从竞品出发（无截图版）

做一个类似 [竞品名称] 的 [模块名]，但要简化：
只保留 [核心功能]，去掉 [复杂功能]。
用户只有一步操作：[描述核心流程]。

1.4 让 AI 先采访你（大型项目推荐）

这是 Claude Code 官方文档推荐的做法——利用 AI 的提问补齐你忽略的细节，比自己列需求更彻底：

我想构建 [一句话描述]。
用 AskUserQuestion 工具来采访我。
问技术实现、UI/UX、边界情况、权衡取舍。
不要问显而易见的问题，深挖我可能没考虑到的部分。
持续采访直到把所有问题覆盖，然后把结论写入 SPEC.md。

写完 SPEC.md 后，另开一个会话再实现——干净的上下文专注执行。

二、迭代调试类（改 bug、加细节用）

2.1 修 Bug 的标准格式

报错信息：
[粘贴完整报错]

出错位置：[文件路径或组件名]
触发条件：[什么操作导致报错]

要求：
1. 找根因，不要只注释掉报错
2. 修完后运行 [测试命令] 验证
3. 说明改了什么、为什么这么改

2.2 修 UI 样式（带截图对比）

[粘贴当前截图] [粘贴目标截图]

对比这两个截图，列出所有视觉差异，然后逐一修复。
修完后再截图对比，直到两者一致。

2.3 跨文件重构

把 [功能/组件名] 从 [当前实现方式] 改成 [目标方式]。

涉及文件：
- [文件 A]（需要改 [具体内容]）
- [文件 B]（需要改 [具体内容]）

改完后运行 [测试命令] 确认没有破坏其他功能。

2.4 性能优化

[文件路径] 里的 [函数/组件] 在 [具体场景] 下很慢。
分析原因，提出 2-3 个优化方案，说明各方案的权衡，然后实现最合适的那个。

2.5 加验证逻辑

给 [表单/函数] 加输入校验：
- [字段 1]：[规则，如"必填，不能超过 50 字符"]
- [字段 2]：[规则，如"必须是有效的邮箱格式"]

校验失败时显示 [具体的错误提示文案]，不要只显示"输入无效"。

三、后端与数据库类（Supabase 场景）

3.1 初始化数据库

在 Supabase 中创建以下表结构：

users（id uuid PRIMARY KEY, email text UNIQUE, name text, created_at timestamptz DEFAULT now()）
projects（id uuid PRIMARY KEY, user_id uuid REFERENCES users(id), name text, status text, deadline date）

同时：
- 为每个表开启 RLS（Row Level Security）
- users 表：用户只能读写自己的记录
- projects 表：用户只能读写自己 user_id 对应的项目

3.2 加登录/注册功能

用 Supabase Auth 实现邮箱 + 密码登录。

需要：
1. 注册页（email + password + confirm password，密码最少 8 位）
2. 登录页（email + password + "记住我"选项）
3. 登录态持久化（刷新页面不掉登录）
4. 登出按钮（清除 session）

登录后跳转到 /dashboard，未登录访问受保护页面时跳转到 /login。

3.3 连接已有 Supabase 项目

我已经有 Supabase 项目，把现有的 mock 数据替换成真实数据库调用。

Supabase URL：[你的 URL]
现有 mock 数据在：[文件路径]

按照现有数据结构在 Supabase 里建表，然后把所有 mock 函数替换为 supabase-js 调用。
保留现有的 TypeScript 类型定义，不要改接口。

3.4 上线前安全检查

在这个应用上线前做安全审查：

检查清单：
1. 所有表是否开启了 RLS
2. 是否有 SQL 注入风险（用户输入是否直接拼接进 SQL）
3. API Key 是否暴露在前端代码或 console.log 里
4. 用户是否能访问其他用户的数据（测试越权场景）

按严重程度列出问题，高危问题立即修复。

四、CLAUDE.md：持久化你的项目规则

CLAUDE.md 是 Claude Code 每次会话启动时自动读取的文件，位于项目根目录。它解决的是：不必每次都重复交代同样的规则。

运行 /init 可自动生成基础版本，再根据项目特点调整。

4.1 前端项目的 CLAUDE.md 模板

# 代码风格
- 使用 ES modules（import/export），不用 CommonJS（require）
- 能解构的时候用解构：import { foo } from 'bar'
- 组件文件名用 PascalCase，工具函数文件名用 kebab-case

# 测试
- 跑单个测试，不要跑整个测试套件：`npm test -- --testPathPattern=xxx`
- 每次改完代码后做类型检查：`npm run type-check`

# Git 工作流
- 分支命名：feat/xxx、fix/xxx、chore/xxx
- commit 信息：`feat: 添加用户登录功能`（中文也可以）

# 项目约定
- API 请求统一放 src/api/ 目录
- 全局状态用 Zustand，组件内状态用 useState
- 样式用 Tailwind，不要引入额外的 CSS-in-JS 库

4.2 官方的“写 vs 不写”判断标准

Claude Code 官方文档给出了清晰原则：

警告：CLAUDE.md 过长会导致 AI 忽视重要规则，因为关键指令被淹没。每条内容的判断标准是：“去掉这行，AI 会犯什么具体错误？” 如果答不上来，删掉。

五、Cursor Rules：防幻觉的系统级提示词

Cursor 的 .cursor/rules/ 目录支持按技术栈配置持久化规则。awesome-cursorrules（PatrickJS/awesome-cursorrules，39,600⭐）收录了 197 条社区验证的规则。

5.1 规则文件格式

---
description: Next.js 15 + Supabase 防幻觉规则
globs: ["**/*.tsx", "**/*.ts"]
alwaysApply: true
---

# Next.js 15 规则

- 使用 `await params` 获取动态路由参数，params 现在是 Promise
- cookies() 和 headers() 返回 Promise，必须 await
- 不要用已废弃的 getServerSideProps / getStaticProps（这是 Pages Router）
- Supabase RLS 必须为所有表开启，不要用 service_role key 绕过
- 环境变量：只有 NEXT_PUBLIC_ 前缀的变量才暴露给浏览器

5.2 防 AI 拍马屁的提示词（anti-sycophancy）

awesome-cursorrules 里“17 条阻止 LLM 编码不诚实”的规则核心是：

---
description: 防止 AI 只说好听的话
alwaysApply: true
---

# 代码审查诚实性规则

- 如果我的代码有问题，直接指出，不要先夸再提问题
- 不要给出“这是个好想法，但是...”式的铺垫
- 如果我的方案有更好的替代，直接告诉我替代方案，不要只提建议
- 对于不确定的内容，说“我不确定”，不要编造答案
- 如果任务完成质量有限，说明具体的局限，不要说“已完成”

5.3 按场景的防幻觉规则示例

TypeScript 项目：

- 不要用 any 类型，用 unknown 加类型收窄
- 不要用 @ts-ignore，找到并修复类型错误
- 不要引入 tsconfig.json 中未出现的编译器选项

React 项目：

- useEffect 的依赖数组不能省略，必须包含所有用到的外部变量
- 不要用 document.getElementById 操作 DOM，用 useRef
- key 属性不能用数组 index，用唯一标识符

API 开发：

- 所有用户输入在服务端验证，不依赖客户端验证
- 错误响应不要暴露内部实现（如数据库错误信息）
- 分页接口必须有 limit 上限，防止全量返回

六、上下文管理：让长会话不失控

6.1 /clear 的使用时机

Claude Code 官方明确：连续纠正超过 2 次仍然出错，直接 /clear 重开。

带着一堆失败记录继续对话，比重新开一个干净会话描述清楚问题，结果更差。

正确方式：

[清空后重新描述]
之前尝试：[失败的方向 A]，无效原因是 [原因]。
请避开这个方向，改用 [新思路] 来实现：[完整需求描述]

6.2 用子 Agent 探索，保持主会话干净

用子 Agent 调查我们的认证系统是如何处理 token 刷新的，
以及是否有可以复用的 OAuth 工具函数。
探索完后汇报结论，不需要展示所有读过的文件。

子 Agent 消耗的上下文不会进入主会话，适合“先调查清楚再动手”的场景。

6.3 会话结束前的标准收尾

把本次所有改动总结为：
1. 改动了哪些文件（路径 + 一句话说明）
2. 引入了哪些新依赖
3. 有没有未完成的 TODO 或已知问题
4. 下次继续需要做的事

然后 git commit，message 格式：[类型]: [一句话说明]

快速参考：场景 → 提示词关键词

启动新项目     → "构建 [产品] 用于 [用户] 解决 [问题]，数据结构：..."
让AI采访你     → "用 AskUserQuestion 采访我，覆盖所有边界情况，写入 SPEC.md"
修 Bug         → "报错：[粘贴] 触发条件：[描述] 找根因后验证修复"
改 UI          → "[粘贴截图] 对比差异，逐一修复，修完截图验证"
加认证         → "Supabase Auth 邮箱登录，登录态持久化，未登录跳 /login"
安全检查       → "检查 RLS、注入、API Key 暴露、越权访问，按严重程度排列"
持久化规则     → 写 CLAUDE.md 或 .cursor/rules/*.mdc
防幻觉规则     → anti-sycophancy + 技术栈专属规则（见 awesome-cursorrules 39,600⭐）
上下文满了     → /clear 后重新描述，带上"之前失败的方向是X，原因是Y"
大型探索       → "用子Agent调查...，汇报结论即可"

FAQ

Q：同样的需求，在 Lovable 和 Cursor 里提示词写法有区别吗？
A：有。Lovable 接受自然语言描述，不需要指定文件路径（它自己管代码结构）；Cursor 需要更明确地指向文件（“修改 src/auth.ts 里的 login() 函数”）。共同原则一样：具体场景 + 验证标准 + 排除项。

Q：CLAUDE.md 写多长合适？
A：Claude Code 官方建议的判断标准是：每条规则都要能回答“去掉这行，AI 会犯什么具体的错？”。大多数项目的 CLAUDE.md 保持在 20-40 行最有效。超过 100 行后重要规则开始被忽略。

Q：提示词写了很多细节，但 AI 还是忽略了部分要求怎么办？
A：Claude Code 官方建议在关键规则前加 IMPORTANT 或 YOU MUST 强调。另一个方法是把容易被忽略的规则从 CLAUDE.md 移到 Hooks（钩子）——Hooks 是代码层面的硬约束，不会被“忽略”，适合“每次保存后必须运行 lint”这类零例外的规则。

Q：怎么让 AI 不要过度自作主张地加功能？
A：在提示词里明确写“第一版只做以下功能，其他一律不加：[列表]”。或在 CLAUDE.md 里加规则：“实现功能之前先确认范围，不要主动扩展需求”。

总结

高质量的 vibe coding 提示词核心围绕三点：具体的场景描述（不是“修 bug”，而是“什么情况下触发了什么错误”）、可验证的标准（测试用例、截图对比、构建结果）、明确的排除项（不做什么和做什么同等重要）。awesome-cursorrules（39,600⭐）提供了 197 条社区验证的防幻觉规则，Claude Code 官方文档的“Explore → Plan → Implement → Commit”四阶段框架是复杂功能开发的通用模板。

数据来源：Claude Code 官方最佳实践文档（code.claude.com/docs/en/best-practices，2026-05）、Lovable Prompting Bible（lovable.dev，2025-01）、PatrickJS/awesome-cursorrules（39,600⭐，GitHub，2026-05）。