Vibe Coding 提示词大全：从启动到上线，每个场景的最优写法
发布日期：2026-05-19 | 数据来源：Claude Code 官方文档、Lovable Prompting Bible、awesome-cursorrules（39,600⭐）
核心定义：Vibe Coding 提示词（Prompt）的质量直接决定 AI 生成结果的可用程度。根据 Claude Code 官方最佳实践文档，模糊提示词与精准提示词产生的结果差距在 80% 以上；Lovable Prompting Bible 指出"首次生成时提供完整上下文"是减少后续返工最有效的单一操作；awesome-cursorrules（GitHub 39,600⭐）收录了 197 条针对不同技术栈的防幻觉规则。本文按使用场景分类整理了 40+ 条可直接复用的提示词模板。
为什么大多数人的 vibe coding 提示词写错了
Claude Code 官方文档里有一张对比表，清晰说明了"模糊提示 vs 精准提示"的差距：
这不是写作风格的差异，是 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）。
参考资源
