Vibe Coding 的效果，很大程度取决于你给 AI 的上下文质量。同样是“帮我修 Bug”，一句模糊指令可能只换来一段猜测；一段包含报错、触发条件、目标文件和验证命令的提示词，则更接近把任务交给一位能独立推进的工程师。
这不是文案技巧，而是工程协作方式：你给出的边界越清楚，AI 越不容易自作主张。
为什么大多数提示词效果不好
低效提示词通常有三个问题：
- 只描述愿望，不描述验收标准；
- 只说“做什么”，不说“不做什么”；
- 只给结论，不给上下文和约束。
例如，“把 dashboard 做得好看一点”很难执行；“参考这张截图，保持现有数据结构不变，用 Tailwind 调整 dashboard，并在完成后列出与截图的差异”就明确得多。
好的 Vibe Coding 提示词至少包含四类信息：任务目标、上下文、约束条件、验证方式。
一、启动新项目：先把范围框住
第一次生成项目时，AI 最容易“加戏”。你没有明确排除项，它就可能自动加登录、支付、后台、通知、图表，最后生成一个看似完整但很难维护的半成品。
推荐模板：
构建一个 [产品名称]，帮助 [目标用户] 解决 [核心问题]。
第一版只做这些功能：
1. [功能 1]
2. [功能 2]
3. [功能 3]
第一版不要做：
- [排除项 1]
- [排除项 2]
数据结构：
- users: id, email, name, created_at
- projects: id, user_id, name, status, deadline
UI 风格：[简洁专业 / 暗色科技 / 类 Linear]
技术栈：[React + Tailwind + Supabase]
完成后说明如何本地运行。
“不要做什么”非常关键。它能减少无关依赖、过度封装和没有必要的页面。
二、从截图或竞品出发：让 AI 有参照物
如果你有截图、Figma、竞品页面，提示词可以更短，但验收标准要更明确。
参考这张截图，实现 [页面名称]。
要求：
1. 技术栈使用 React + Tailwind；
2. 数据先用 mock，不接真实 API；
3. 保持响应式布局；
4. 完成后列出当前实现与截图仍存在的差异。
没有截图时，也可以用竞品描述，但要说明“简化哪些部分”：
做一个类似 [竞品] 的 [模块]，但第一版只保留 [核心流程]。
去掉社交分享、复杂筛选和付费功能。
用户从进入页面到完成任务不超过 3 步。
三、修 Bug：把“猜问题”改成“定位问题”
修 Bug 的提示词应像一张工单，而不是一句抱怨。
报错信息：
[粘贴完整错误]
触发条件：
[执行了什么操作 / 输入了什么数据 / 运行了什么命令]
相关文件：
- [文件路径 A]
- [文件路径 B]
要求：
1. 先找根因，不要只屏蔽报错；
2. 修复后运行 [测试命令]；
3. 最后说明改了什么，以及为什么这样改。
关键是完整错误和触发条件。只给“构建失败了”，AI 往往只能从常见错误里猜。
四、改 UI：用差异清单替代审美描述
“好看一点”“现代一点”“高级一点”都不是工程标准。更稳定的写法是让 AI 先列差异，再逐项修复。
这是当前截图：[粘贴]
这是目标截图：[粘贴]
请先列出所有视觉差异，包括间距、字号、颜色、圆角、阴影、对齐、响应式表现。
然后逐一修改。
完成后再次对照差异清单，说明哪些已修复，哪些因为现有限制暂未处理。
这类提示词适合 Cursor、Claude Code、Codex CLI 等能读写项目文件的工具。
五、数据库和后端：先写安全边界
涉及数据库时，提示词不能只写表结构，还要写权限和边界。
在 Supabase 中创建以下表：
projects:
- id uuid primary key
- user_id uuid references users(id)
- name text
- status text
- created_at timestamptz default now()
要求：
1. 开启 RLS；
2. 用户只能读写自己的 projects；
3. 所有写入在服务端校验；
4. 不要在前端暴露 service_role key；
5. 写完后给出验证越权访问的测试步骤。
安全要求越早写进去，后面返工越少。特别是 RLS、API Key、越权访问和输入校验，应该在第一版就纳入提示词。
六、持久化规则：把重复要求写进项目文件
每次都提醒 AI “不要用 any”“测试放 tests 目录”“提交前跑类型检查”，效率很低。更好的方式是把稳定规则写入项目级说明文件。
Claude Code 常用 CLAUDE.md，Codex CLI 常用 AGENTS.md 或 codex.md，Cursor 可以使用 .cursor/rules/。规则应短而具体：
# 项目规则
- 使用 TypeScript strict 模式，不要引入 any。
- API 请求统一放在 src/api/。
- 修改后运行 npm run type-check。
- 不要修改 legacy/ 目录。
判断一条规则是否值得写入，可以问自己：删掉它，AI 会犯什么具体错误？如果答不上来，就不要写。
七、防幻觉：让 AI 承认不确定
编码 Agent 最大的问题之一，是在不确定时编造文件、API 或依赖。可以在规则中加入反幻觉约束：
- 不确定时明确说不确定，不要编造。
- 修改前先确认文件存在。
- 不要引入 package.json 中不存在的依赖，除非明确说明原因。
- 如果测试无法运行，说明原因，不要声称已通过。
这类规则对大型代码库尤其重要，因为 AI 很容易根据常见项目结构猜路径。
八、上下文管理：长会话不要硬撑
连续纠正两三次仍然跑偏时，继续在同一个长会话里修补，效果往往会变差。更好的做法是清理上下文，重新给出精简但完整的任务描述：
之前尝试过 [方向 A]，失败原因是 [原因]。
请不要再沿用这个方向。
现在改用 [新方案]：
[完整需求]
验收标准：[测试命令 / 截图 / 输出结果]
对复杂系统，可以先让 AI 调查，再让它执行。调查阶段只汇报结论，执行阶段再改代码，能显著降低上下文噪音。
快速参考
| 场景 | 提示词重点 |
|---|---|
| 启动项目 | 目标用户、核心功能、排除项、数据结构 |
| 修 Bug | 完整报错、触发条件、相关文件、验证命令 |
| 改 UI | 当前截图、目标截图、差异清单 |
| 加后端 | 表结构、权限、校验、越权测试 |
| 安全检查 | RLS、注入、密钥、日志、权限 |
| 防幻觉 | 不确定就说明、先确认文件、不要编造依赖 |
| 收尾 | 文件清单、测试结果、已知问题、下一步 |
FAQ
Q：提示词越长越好吗？
不是。长但无重点会稀释关键信息。好的提示词是“必要信息完整，约束清楚，验收标准明确”。
Q：为什么要写排除项？
因为 AI 倾向于补全它认为合理的功能。排除项可以限制范围，减少不必要的依赖和页面。
Q：规则文件应该写多长？
一般 20 到 40 行就够。每条规则都应该能对应一个具体错误，否则容易变成噪音。
Q：国内使用多模型做 Vibe Coding 时，API 怎么统一？
如果需要在同一套工作流里切换 Claude、OpenAI、Gemini 或国产模型，可以评估 Code80（https://code.ai80.vip）这类统一入口，重点看协议兼容、模型列表、价格和日志策略。
总结
Vibe Coding 的核心不是“让 AI 自由发挥”，而是把任务拆成可执行、可验证、可回滚的工程指令。提示词写得好，AI 更像协作工程师；提示词写得模糊，AI 就只能靠猜。
最通用的公式是：背景 + 目标 + 约束 + 排除项 + 验收标准。把这五项写清楚，返工会少很多。
评论前必须登录！
立即登录 注册