我用一句话描述了一个产品，48小时后它真的跑起来了——但中间有3次我差点把电脑砸了

"我想做一个能根据心情推荐 BGM 的网页小工具。"

就这一句话。没有原型图，没有技术文档，没有任何代码基础。

48小时后，这个工具真的在浏览器里跑起来了：输入你现在的心情，它会推荐一首歌，配上歌词片段和一句话的情绪注解。

但我没告诉你的是——中间有三次，我盯着屏幕上一模一样的报错信息，已经开始怀疑这条路根本走不通。

这篇文章不是来告诉你"Vibe coding 有多神奇"的。网上这类文章已经够多了。我想告诉你的是：它在哪里会卡死你，以及你该怎么过那几个关口。

---

Google I/O 2025 说了什么？（先说背景，然后我们直接进实操）

今年的 Google I/O，Vibe coding 第一次被明确推上主舞台。Jules（Google 的 AI 编程 Agent）、Gemini in Android Studio、Project IDX 的深度集成——这些工具集中亮相，传递的信号非常清晰：

自然语言 → 可运行产品，正在成为真实的开发范式，而不只是 PPT 上的愿景。

但发布会看完，你可能和我一样：兴奋了五分钟，然后不知道从哪里开始。

所以我决定自己照着这个思路做一遍，把过程完整记录下来。

---

我做了什么？一个真实的 Demo 过程还原

产品定义

需求就一句话："根据用户输入的心情关键词，推荐一首 BGM，附上歌词片段和情绪注解。"

技术栈我没有指定，让 AI 自己决定。最后的结果是：纯前端 HTML + JavaScript，调用 OpenAI API 生成推荐内容。不需要后端，不需要数据库，浏览器直接打开就能用。

完整的 Prompt 序列

我用的不是一个 prompt，而是一套有节奏的对话序列。这是很多人第一次尝试 Vibe coding 时最容易忽视的事情——你不是在"下命令"，你是在"导演一场对话"。

第一轮 prompt（定义产品边界）： 
我想做一个网页小工具，用户输入一个心情关键词（比如"焦虑"、"想念某人"、"莫名开心"），

页面返回：


1. 一首适合这个心情的歌曲名 + 歌手


2. 这首歌的一句歌词


3. 一句话的情绪注解（为什么这首歌适合这个心情）



技术要求：


  • 纯前端实现，单个 HTML 文件，不需要后端
    • 

  • 调用 OpenAI API（gpt-4o-mini 即可）
    • 

  • 界面简洁，移动端友好
    • 

  • 不需要登录，不存储任何数据
    • 



请先给我完整的 HTML 文件，包含所有 CSS 和 JS。


API Key 我会自己填入，在代码里用 YOUR_API_KEY 占位。
关键点：这个 prompt 有三个层次——功能描述、技术约束、交付形式。缺少任何一层，AI 给你的结果都会偏。

第一轮跑完，我拿到了一个完整的 HTML 文件，在浏览器里打开，填入 API Key，第一次测试就成功了。

但这只是开始。

---

最容易卡死的三个关口

卡点①：第一个 Prompt 写得太"虚"

这是 90% 的人第一次尝试 Vibe coding 时踩的坑。

卡死版 prompt（真实案例）： 
帮我做一个音乐推荐网站

AI 会给你什么？一个"框架"。有 React，有路由，有数据库 Schema，有用户系统——但一行都跑不起来，因为它假设你会自己补全所有依赖和配置。

对比一下这两个 prompt 的输出差异：

| 维度 | 卡死版 | 能跑版 | | 交付形式 | 多个文件 + 配置说明 | 单个可运行 HTML | | 依赖 | npm install 一堆包 | 零依赖 | | 第一次能跑 | 几乎不可能 | 大概率可以 | | 适合阶段 | 有环境的开发者 | 第一次尝试的任何人 |
能跑版 prompt 的核心公式：
我想做什么（功能）+ 用什么技术（约束）+ 交付什么形式（单文件/可直接运行）

如果你是零基础，永远先要求"单个 HTML 文件"。这一个约束，能让你的成功率从 20% 提升到 80%。

---

卡点②：AI 改了 A，坏了 B——陷入 Bug 循环

这是最让人崩溃的体验。你让 AI 修一个按钮的样式，它顺手把你的 API 调用逻辑也重写了一遍，然后报错了。你让它修报错，它又动了别的地方。

为什么会发生这种事？

因为大多数 AI 模型在修改代码时，倾向于"重新理解整段代码然后重写"，而不是"精准定位问题然后最小化修改"。它不是在给你打补丁，它是在重新盖房子。

应对策略：分层提交 + 局部锁定

我在这个项目里踩过一次这个坑：让 AI 优化界面动画时，它把我的 API 请求函数从 async/await 改成了 Promise 链，结果错误处理逻辑全乱了。

后来我总结出一套"局部锁定"的 prompt 写法：

下面我会给你当前的完整代码。

我只需要你修改 [具体函数名/具体区域] 这一部分。


其他所有代码，包括 API 调用逻辑、样式、HTML 结构，


请保持完全不变，一个字符都不要动。


修改后，请只输出被修改的那个函数，不要输出完整文件。

这个 prompt 有两个关键动作：明确边界（只动哪里）+ 限制输出（只给我改动的部分）。

养成这个习惯之后，我的 Bug 循环频率下降了大概七成。

---

卡点③：Demo 能跑，但接 API/部署时断掉

这是最多人放弃的地方。

Demo 在本地跑得好好的，一换到真实 API 环境或者尝试部署，各种奇怪的问题开始出现：

  • CORS 报错
  • API Key 明文暴露在前端代码里被浏览器拦截
  • 网络请求超时，但不知道是代码问题还是网络问题
  • 部署到 GitHub Pages 之后，API 调用全部失败
这里我要说一句实话：很多读者卡在这里，其实不是代码问题，是 API 访问不稳定导致的。你不知道是自己写错了，还是请求根本没发出去。

我自己测试这个 Demo 用的是 [api.884819.xyz](https://api.884819.xyz)，国内直连、兼容 OpenAI 格式，新用户注册即送体验 token，省去了环境配置的心理负担——尤其适合你刚想跑通第一个 Demo、还不想在网络问题上花时间的阶段。国产模型（Deepseek、千问等）完全免费，没有月租，按量付费，对新手非常友好。

部署前的 5 项最小可行检查清单： 
## Vibe Coding Demo 部署前检查清单


  • [ ] 1. API Key 是否已从代码中移除，改为环境变量或用户输入？
    • 

  • [ ] 2. 在浏览器控制台（F12）确认没有 CORS 报错？
    • 

  • [ ] 3. 网络请求是否有超时处理（timeout + 友好的错误提示）？
    • 

  • [ ] 4. 在手机浏览器上测试过一次？（移动端往往有意想不到的问题）
    • 

  • [ ] 5. 断网状态下打开，是否有降级提示而不是白屏？
    •

这 5 项，每一项都是我踩过的真实坑。

---

哪些环节必须"人类接管"？

Vibe coding 最大的认知误区，是把自己当成"验收员"，以为 AI 全程负责，自己只管最后点头。

这个心态会让你越用越挫败。

真正高效的 Vibe coding，你的角色是导演，不是观众。有几个节点，AI 无法替你做判断：

节点一：需求拆解的粒度

AI 能执行你的指令，但它不知道你真正想要的是什么。"做一个音乐推荐工具"和"做一个单页面、零注册、输入心情关键词就能用的音乐推荐工具"——对 AI 来说是完全不同的两个任务。

需求拆解是人的工作，不是 AI 的工作。

节点二：中间态的验收标准

每一轮 AI 生成之后，你需要判断：这个阶段性结果，是否符合我的预期？是继续推进，还是回退重来？

这个判断没有标准答案，完全取决于你对产品的理解。AI 不会主动告诉你"这里可能有问题"，它只会执行。

节点三：安全和隐私的最终检查

如果你的产品会上线给别人用，有几件事必须人工确认：

  • API Key 是否会暴露给用户？
  • 用户输入的数据是否会被记录或传输到第三方？
  • 是否有明显的注入攻击风险？

AI 生成的代码在这些方面往往是"能跑但不安全"的。这不是 AI 的错，它只是在完成你的需求描述——而你的需求描述里通常没有提安全。

正确的心智模型：AI 是你的高级实习生，执行力超强，但判断力需要你来补足。你不需要会写代码，但你需要知道自己要什么、不要什么。

---

给不同阶段读者的行动路径

如果你是小白

只做一件事：跑通一个最小 Demo。

不要贪功能，不要想着第一次就做出一个"完整产品"。选一个你真正感兴趣的小需求，用上面的 prompt 公式，先让它在浏览器里跑起来。这一步本身就是突破。

如果你已经跑通过 Demo

开始关注 prompt 的"约束层"设计。

光描述需求是不够的，你需要学会在 prompt 里加入技术约束（用什么框架、不用什么框架）、交付约束（输出格式、文件结构）、行为约束（不要动这部分代码）。约束层越清晰，AI 的输出越可控。

如果你有 API 接入需求

先解决访问稳定性，再谈代码质量。

很多人在这个阶段卡住，不是因为代码写错了，而是因为根本不知道请求有没有发出去。用一个稳定的 API 接入点（比如 [api.884819.xyz](https://api.884819.xyz)，兼容 OpenAI 格式，注册即用），先把这个变量排除掉，再去 debug 代码逻辑。

---

最后说一句

Vibe coding 没有让开发变得"无脑"。

它让开发变得"可以开始"。

这个区别很重要。你还是需要思考，需要判断，需要在关键节点接管。但你不再需要在"怎么搭环境"和"这个语法怎么写"上耗掉所有的耐心和热情。

对大多数有想法但不会写代码的人来说，这已经足够了。

---

这次我做的是一个"单人能跑"的 Demo。

>

但下一个问题更有意思：如果你想让 AI 帮你做一个"别人也能用"的产品——上线、分享、收集反馈——工作流会完全不同。

>

部署策略、用户反馈闭环、如何用 AI 快速迭代真实用户的需求——我正在整理这套流程。下篇见。

---

本文由8848AI原创，转载请注明出处。关注8848AI，带你从零开始学AI。

#VibeCoding #AI编程 #GoogleIO #人工智能 #AI教程 #8848AI #Prompt技巧 #零基础学AI