Vibe Coding两天实测：用自然语言与Google AI Studio从零搭建小工具

最近我花了整整两天时间，把自己按进一个完全陌生的开发流程里：不直接写代码，全程靠对话，用自然语言把一个还算完整的小工具从零搭出来。工具用的是 Google AI Studio，玩法就是圈子里最近特别火的 Vibe Coding。两天下来最大的感受是：代码确实不是我一行的敲的，但我在这个过程中的思路压力比平时自己写代码还要大。

Vibe Coding 说白了就是"你动嘴、AI 动手"。你负责描述想要的东西，AI 负责把描述变成代码。Google AI Studio 正好把这件事的门槛压到了最低——不用装 Python、不用配 Node 环境、不用开本地编辑器，一个浏览器页面就能开始跑模型、调参数、叠提示词、生成可运行的前端页面。这篇文章想把这两天的实操原原本本记录下来：哪些环节是真的爽，哪些坑是真的深，以及什么样的人适合拿它来干活。

1. Vibe Coding 上车前，先搞清楚它到底在解决什么问题

1.1 代码不再是目标，需求才是目标

传统开发的路径是"需求 -> 拆解 -> 设计 -> 写代码 -> 调试"。Vibe Coding 把中间两层大幅压缩，你不再需要逐行告诉机器"声明一个数组、遍历它、把结果拼到页面上"，你只需要告诉 AI"我希望有一个页面，左边是输入框，右边是实时统计结果，统计规则是……"。它的底层逻辑是把编程从"表达逻辑"变成了"表达目标"。

这带来的第一个变化是心态上的：你不再担心语法错误和括号匹配，因为那些全被 AI 吞掉了。你真正要担心的变成了"我说的这个需求，AI 理解的和我想的是不是一回事"。我在第一轮测试里让 AI 生成一个"点击按钮后显示倒计时"的小组件，它很自然地做了一个 10 秒倒计时，但我实际想要的是"从用户输入的时间开始倒计时"。这 10 分钟差，恰恰就是需求描述的误差。

这个转变对两类人冲击最大。一类是从未写过代码的人，突然发现自己可以通过描述直接获得可运行的软件；另一类是写了多年代码的人，突然发现自己的核心竞争力从"手速"变成了"脑速"和"判断力"。对前者，Vibe Coding 是入口；对后者，Vibe Coding 是杠杆。

1.2 为什么偏偏是现在火起来：三个变化凑到了一起

Vibe Coding 这个概念不是全新的，但真正让它落地是最近一年多的事，原因有三个。

第一，模型上下文窗口大幅增长。早期对话模型只能记住一两轮对话，你让它改第三轮需求时它已经把第一轮忘了。现在的模型可以在一段连续对话里同时容纳需求描述、历史代码、报错信息、修改要求，这让"一边聊一边改"成为可能。

第二，代码生成质量进入实用区。以前生成的代码经常是伪代码级别的"仅供参考"，现在很多小型工具的生成结果可以直接运行，甚至已经到了"跑起来之后只需要微调"的程度。

第三，浏览器端 AI 工作台成熟了。Google AI Studio 这类产品把模型选择、参数调整、提示词测试、代码生成集成在一个页面里，不需要本地部署任何东西。这直接抹平了环境配置的门槛——要知道，以前让新手装一个开发环境就能劝退一半人。

1.3 Vibe Coding 不等于"不需要编程能力"

这是我最想纠正的一个误区。很多人把 Vibe Coding 理解成"躺着指挥 AI 干活"，其实完全不是这么回事。它只是把"写代码的能力"替换成了"判断代码的能力"。

你自己不写代码，但你得能看懂 AI 生成的代码有没有问题；你得能分辨它是在老老实实实现你的需求，还是在用一种看起来合理但实际跑不通的方式糊弄你；你甚至得学会在没有报错的情况下，凭逻辑判断某段代码是不是有隐患。这就好比你请了一个执行能力很强但偶尔会一本正经胡说八道的下属，你不需要亲手干活，但你必须能看出他交上来的东西是不是真的能用。

我在实操中明显感觉到，我平时积累的那些编程经验——变量怎么命名、函数怎么拆分、什么逻辑容易出并发问题——在审核 AI 产出时全部派上了用场。Vibe Coding 不是让编程能力归零，而是把编程能力变成"审核能力"。

2. Google AI Studio 的开箱体验：一个浏览器就能跑完的 AI 工作台

2.1 它到底是什么，适合 Vibe Coding 的哪些环节

Google AI Studio 是 Google 提供的浏览器端 AI 开发工作台，核心功能是让你直接在网页上调用 Gemini 系列模型，测试提示词、调整参数、生成内容，并且能看到模型的完整输出过程。和本地开发环境最大的区别是：你不用操心显卡、不用安装依赖、不用管理 API Key 的调用频率（基础使用免费额度就够个人折腾）。

对 Vibe Coding 来说，它适合三个环节。

第一个是快速验证想法。比如你有"做一个随机推荐菜品的按钮"这个想法，直接开一个会话描述清楚，往往不到一分钟就能拿到一段可运行的 HTML+JS 代码。这个验证速度在传统开发流程里是不可想象的。

第二个是提示词调优。AI Studio 的参数面板可以实时调整温度、随机性、输出长度等，方便你对比同一个需求在不同配置下的表现，找到最稳定的生成策略。

第三个是零散工具的生产。当你需要一把"临时用一次的螺丝刀"——比如把 CSV 转成 JSON、批量重命名文件、生成一份网页表格——用它生成脚本比手写快得多。

我之前也试过在本地 IDE 里装 AI 插件来辅助编程，但那种方式更适合"我在写代码、AI 帮我补全"的场景。而 Vibe Coding 需要的是一个更开放的对话空间，让我可以自由描述需求、调整方向、让 AI 返回完整代码块，AI Studio 这种独立工作台反而更契合。

2.2 第一次跑通：从打开浏览器到生成第一段代码的完整链路

第一次跑通的链路比我预想的短很多。打开 AI Studio 页面，选择模型——我建议新手先从主打速度、兼顾质量的默认模型开始，等需要处理长上下文或复杂任务时再切更大的模型——然后在输入框里输入第一句提示词。

我第一次输入的内容是：帮我写一个网页，页面上有一个按钮，点击后随机显示一句励志名言，名言存一个数组里，页面要好看一点。右边生成区立刻就返回了完整的 HTML 代码，包含了一个简单的样式和内联脚本。我把代码复制到本地保存为 .html 文件，双击打开，功能就通了。

第一次成功之后，我做的第一件事不是继续加功能，而是回头重新读了一遍 AI 生成的代码。这一步值得所有新手坚持：你不需要读懂每一行，但你至少要看到它用了什么标签、事件是怎么绑定的、数据是怎么存储的。这能帮你建立"AI 的代码长什么样"的基本感觉，后续排查问题时才不会抓瞎。下面是我第一次跑通时使用的提示词结构参考：

• 角色设定：你是一个资深前端工程师，代码要简洁、可维护；
• 需求描述：页面要有什么、交互是什么、数据来源是什么；
• 输出要求：返回完整可运行的 HTML 文件，内联 CSS 和 JS；
• 验收标准：打开页面后无需额外操作即可使用。

这套提示词结构看起来简单，但它直接决定了一轮生成的准确率。很多人抱怨 AI 生成的东西不可用，往往是因为需求里只写了"要什么功能"，漏掉了"做成什么形式"和"达到什么标准"。

2.3 参数面板里值得调整的三个旋钮

AI Studio 的参数面板是我觉得最容易被忽略的部分。很多人直接打开默认参数就开聊，其实里面几个旋钮对 Vibe Coding 的产出质量影响非常大。

第一个是 Temperature（温度），它控制生成结果的随机性。数值越高，回答越发散；数值越低，回答越确定。做代码生成时我强烈建议把它调低，因为你要的是稳定可控的逻辑，不是创意文案。实测下来，把温度控制在 0.2 到 0.4 之间，AI 生成的代码结构会更规矩，重复生成的结果差异也更小。

第二个是 Max output tokens（最大输出长度）。代码生成任务经常遇到一个尴尬：AI 生成的代码太长，输出被截断，后半段逻辑不完整。这时候把最大输出调高是最直接的解法。我的经验是，预估一段完整逻辑需要多长，就把上限设成预估的 1.5 倍，宁可冗余也不要中途截断。

第三个是 Top P 这个采样参数，它控制候选词集合的收窄程度。对于代码生成，我一般保持默认或适当降低，让结果更集中。和 Temperature 二选一去调就可以，两个同时压低容易让输出变得机械。

3. 一场完整的 Vibe Coding 实操：从一句中文需求到能用的页面

3.1 需求拆分：把一句话变成可验证的里程碑

纸上谈兵说完了，来点实际的。我第二天的实操项目是做一个"时间记录工具"：每天有几件事要打卡，记录每件事花了多少分钟，最后能按日期查看汇总。选中这个项目是因为它有清晰的数据结构、基本的交互逻辑、以及一点状态管理的复杂度，能完整测试 Vibe Coding 的边界。

我没有直接跟 AI 说"帮我做一个时间记录工具"，这句话太模糊了，AI 大概率会自由发挥做出一个"你觉得差不多但完全不是你要的东西"。我先在草稿纸上把它拆成了四个里程碑：

• 里程碑一：静态页面骨架，有事件列表和时间输入框，能手动添加一条记录；
• 里程碑二：数据本地保存，刷新页面后记录不丢失；
• 里程碑三：按日期筛选和汇总，展示当天总时长；
• 里程碑四：视觉优化，适配手机，按钮布局顺手。

每个里程碑独立跟 AI 对话，而不是在同一个会话里连续追加需求。这一点很重要：对话一旦变长，后面加入的模糊需求会把前面的清晰上下文稀释掉，AI 很容易改着改着把老功能改坏了。

3.2 分阶段对话：让 AI 一次只完成一块，反而最快

进入实操后，我按照拆好的里程碑逐步推进。第一个里程碑的提示词是：帮我做一个网页应用，达到以下要求：左侧是一条事件列表，每个事件有一个名字和一段备注；右侧有一个表单，可以输入事件名称和时间消耗（分钟）；点击添加后，事件出现在列表中，用一个 delete 按钮可以删除它；不要使用任何外部框架和库，纯 HTML/CSS/JavaScript 实现；返回完整代码。

这一轮 AI 生成得很快，代码结构清晰，页面能正常添加和删除记录。我没有急着让它做第二个里程碑，而是把生成的代码保存下来，新开一个会话，把代码贴进去，然后追加需求：在刚才这段代码的基础上，添加 localStorage 持久化功能，让页面刷新后记录仍然存在。注意这里的关键操作是：我没有说"加持久化"，而是明确指定了技术方案（localStorage）和验收标准（刷新后仍存在）。指定技术方案的目的是减少 AI 的自由发挥空间。

第三个里程碑是筛选汇总。我仍然新开会话，把已有的完整代码贴进去，要求它添加日期维度：每条记录在添加时自动带上当天日期；页面顶部提供一个日期选择器；选中某一天后，列表只显示当天的记录，并在下方显示当天总时间。到这里，核心功能就齐了，整个过程大约花了三十分钟，其中大部分时间花在整理需求描述上，真正等代码生成的时间反而不长。

3.3 粘贴报错、截图反馈：用上下文告诉 AI 差在哪里

实操过程中不全是顺利的。到了加日期筛选功能时，AI 生成的代码在点击日期切换时，事件列表没有反应。我第一反应不是自己看代码定位，而是直接把控制台里的报错信息复制出来，连同相关代码片段贴回对话里，要求它解释报错原因并给出修复方案。

这里有个值得分享的技巧：出现问题时，不要只说"不行，修一下"，而是把报错信息、代码上下文、你期望的行为、当前实际行为这四件事完整给到 AI。比如我贴的是：运行时报了 TypeError: Cannot read properties of undefined (reading 'filter')，这段代码是你刚生成的，我期望点击日期时过滤列表，但现在整页白屏。请先解释这段代码哪里错了，再给出修复后的完整代码。

AI 的回答很直接，问题是它在日期选择器的 change 事件里引用了未初始化的数据数组。修复后的代码增加了判空逻辑。这个经历说明，把错误上下文完整抛给模型，比抽象地描述"它不工作"有效得多，因为模型不是靠猜到你在想什么，而是靠观察具体输入来理解问题的。

4. 从"能跑"到"能交付"：Vibe Coding 迭代中避开的那些坑

4.1 模型"自信地编造"是最隐蔽的坑

用 Vibe Coding 最头疼的不是逻辑写不出来，而是模型用理所当然的语气输出了一段引用了一个根本不存在的 API 的代码。这种情况在它的回复里被你察觉之前，你很容易直接复制去用，然后被运行时报错砸得一头雾水。我在测试 localStorage 相关功能时，AI 生成了一段调用某个自定义封装函数存储数据的代码，但那个函数在前面的代码里从来没出现过——AI 自己造了一个。

解决这类问题没有捷径，但有低成本的做法。

第一，重要功能生成后，别急着往下走，先在本地运行一遍。这是最有效的幻觉杀招，错误暴露得越早，修复成本越低。

第二，怀疑幻觉时，直接让 AI 解释它引用的某个函数、某个 API 的出处和运行逻辑。如果它开始含糊其辞，基本就是编的。

第三，给提示词里注入版本约束，比如"不要使用任何外部依赖""只使用标准库""如果你引用了某 API，请标注它的来源文档链接"，这能有效压制 AI 的发挥型编造。

这个表格里的四种情况我两天里全遇见了，每一次都是靠"本地运行 + 追问解释"双管齐下才发现的。别指望 AI 一次生成零缺陷代码，那概率比中彩票还低。

4.2 需求描述越具体，返工越少，不信也得信

同一个需求，两种描述方式，返工率差距至少三倍。"帮我把页面做得好看一点"和"页面整体使用浅灰背景，卡片用白底和圆角阴影，标题用 20px 字重 600，按钮放在右下角且间距不小于 16px"完全是两种产出。前者的结果全凭 AI 当时的心情，后者的结果则基本符合预期。

我整理了一份对比，方便你不踩这个坑：

• 模糊描述："做一份个人简历页面"——AI 大概率给你一个居中堆叠的复古模板；
• 具体描述："做一份适合移动端浏览的个人简历页面，顶部是姓名和联系方式，下方依次是技能列表、项目经历、教育背景；技能用进度条展示，项目经历用卡片展示；背景使用白底配浅蓝单色装饰；字体使用系统默认字体，不用引入外部字体。"

看到差别了吗？前者是你跟 AI 说"给我一个东西"，后者是你跟 AI 说"按这套规格给我做"。Vibe Coding 的本质是需求工程，你描述得越接近一份技术规格说明书，AI 的交付质量就越稳定。可以这样理解：你在把脑子里的画面转化成 AI 能理解的语言，这个转化步骤省不得。一旦省了，后面会花更多时间去返工。

4.3 对话式开发的上下文管理：别让记忆变成负担

Vibe Coding 的对话式开发有个隐蔽陷阱：随着对话轮数增加，上下文越来越长，AI 对早期信息的注意力会被稀释。到后面你让它改某个细节时，它可能已经忘了最初定义的数据结构。我在做时间记录工具时，到了第三个里程碑就明显感觉到，AI 生成的代码开始和之前的存储结构对不上了。

我的解决方法是"新会话 + 老代码"：每次开始新里程碑，就把上一版完整代码粘贴到新会话里，重新说明当前目标。这个方法有三个好处。第一，上下文被重置到一个干净的状态，模型只看到当前的代码和当前的需求；第二，每次粘贴代码时，我不得不重新阅读一遍完整代码，相当于顺手做了一次代码审查；第三，如果新方案跑不通，可以快速回退到"上一个会话的状态"，不会因为上下文污染导致连环改错。

还有一个更进阶的妙招：在结束一个里程碑时，让 AI 生成一段"变更摘要"。比如：请用三行话总结现在这个网页的完整功能、数据结构和已知限制。下次新会话时，直接把这段摘要连同代码一起作为上下文，AI 就能快速进入状态，不用重新读一遍所有代码。

4.4 代码审查不能省：让 AI 检验 AI

Vibe Coding 做完功能之后，还差最后一步：复读。我的习惯是代码生成后不做任何修改，直接复制到 AI Studio 的一个新会话里，然后发送一条审查指令：请仔细审查这段代码，指出所有可能的问题，包括逻辑错误、潜在报错、性能问题和命名混乱，不要修改代码，只输出审查意见。这一步走完，往往能发现一些生成时忽略的边界情况，比如用户输入了负数、空字符串、连续快速点击会触发重复添加，等等。

有些读者可能会觉得，让 AI 检查 AI 是在自我表演，但实测下来效果明显。原因是：生成和审查是两个不同的上下文模式。生成模式下，模型关注"怎么把需求转化成代码"；审查模式下，模型关注"代码是否存在缺陷"。同一个模型在这两种模式下的输出差异很大，审查模式更容易暴露代码里的逻辑窟窿。

5. 进阶思考：Vibe Coding 项目管理和边界意识

5.1 什么项目适合 Vibe Coding，什么不适合

经过这两天的完整实操，我开始对 Vibe Coding 的适用范围有了清晰认知。它不是银弹，但有相对明确的适用边界。

适合的场景：单次原型验证、内部小工具、个人项目、教学演示、一次性数据清洗脚本。这些场景的特点是：需求变化快、对代码结构的长期维护要求低、出错后的代价可控。我用它做时间记录工具时就发现，从想到做的时间压缩到了几十分钟，这比传统的搭环境、建项目、写代码的流程快出一个量级。

不适合的场景：需要严格审计的业务系统、对并发和安全性有硬性要求的后台服务、需要多人长期协同维护的代码库、以及任何涉及用户资金和数据隐私的场景。这类项目需要的不是快速生成，而是严格的过程管理和可追溯的决策记录，Vibe Coding 的"快速产出+难以保证一致性"正好是反面。在这些场景里，AI 可以作为辅助，但你绝不能把核心逻辑完全交给对话流凭空生成。

我的判断原则很简单：项目越大，手写代码和人工架构设计所占的比例就应该越高。Vibe Coding 负责的是把想法变成代码的那一段距离，而不是把代码变成可用于生产系统的整个过程。

5.2 让 AI 输出可维护代码的几个实用小习惯

哪怕你只拿 Vibe Coding 做原型，养成几个小习惯也能省掉大量返工时间。

第一，在提示词里显式要求代码结构。我在每个语义模块开始前，都会补充一句：函数请使用有意义的命名，并在关键函数前添加注释说明其作用和参数。这个操作成本几乎为零，但对后续的可读性提升巨大。

第二，要求 AI 拆解复杂度。如果需求涉及多步逻辑，明确要求它先列出实现方案，再逐段编码。例如：请先给出你的实现思路，包括数据结构和主要函数划分，确认后再开始写代码。这一招可以有效避免 AI 一锅端的无序输出。

第三，定期让 AI 整理现状。前文提过的新会话摘要技巧就属于这一类。每个阶段性任务结束后，花一分钟让 AI 总结当前代码的功能和后续建议，相当于给项目做了一次即时快照。后面一旦加进垃圾代码，你有清晰的回退基线。

第四，对最核心的算法逻辑进行人工复核。在时间记录工具里，日期过滤和时间汇总就是核心逻辑。我没有直接信任 AI 生成的代码，而是手动读了一遍，确认它的时间计算没有把跨天记录搞混。这种人工复核不需要覆盖所有代码，抓住最关键的那一两处就足够。

5.3 从 Vibe Coding 到 Vibe Collaboration：人机分工的长期视角

两天的完整实操下来，我认为 Vibe Coding 最值得推崇的价值，不是"AI 替我写了代码"，而是"AI 让我把更多精力放在判断和决策上"。在我做时间记录工具的过程中，最有创造性的部分——拆里程碑、定验收标准、判断哪个功能先做——全是我完成的，AI 完成的是把这些决策翻译成代码。这个过程让我更清楚地看到了自己的分工：我是定义问题的人，AI 是解决问题的人。

顺着这个视角往下想，Vibe Coding 迟早会演化成一种更自然的"人机协作"模式，协作的重点不再是你给我一段提示词、我给你一段代码的线性交换，而是你描述意图、我识别边界、你修正方向、我优化细节的来回磨合。我的时间记录工具后来加了两个小功能，每次我都是先自己想清楚"目的是什么、边界在哪里、怎么验收"，再去找 AI 实现，这比逆向让 AI 自己发挥要顺手得多。

这套习惯的内化过程并不复杂：花一两周时间，用 Vibe Coding 做三四个小工具，你就能切身感受到"需求拆解"和"代码实现"之间那道曾经被混为一谈的界限。这也是我建议每一个对 Vibe Coding 感兴趣的人去做的第一件事——别先纠结选哪个模型、调什么参数，先找一个你熟悉的小需求，完整跑一遍。这个体验，比任何别人的经验都更能帮你判断这套玩法适不适合你。

最后再分享一个这几天摸索出来的私人心得：Vibe Coding 的高频使用会让传统的"手写代码手感"退化，但读代码的能力不会退。所以你如果想长期保持竞争力，可以刻意保留一些"纯手写"的时间，尤其是在处理核心算法时。两手交替，速度与手感都能保住。这大概就是新工具时代里，程序员最好的一种平衡方式了。