vibe coding 这个词最近在开发者圈子里火得不行。我第一次听到的时候还以为是什么新式蹦迪编程法后来自己试了几次才反应过来这其实是一种全新的工作姿势——你用自然语言把想法告诉 AIAI 帮你把代码写出来你负责判断方向、审查结果、收拾烂摊子。说白了编程的重心从“怎么写”转移到了“怎么描述、怎么把关”。这篇文章是“从零开始 vibe coding”系列的第一篇目标就一个手把手带你从一个模糊的 idea跑通一个能实打实演示的 demo。不用你之前有多少编程基础只要你脑子里有一个想做的玩意儿愿意把描述需求当成写作来练基本都能跟上。适合谁看想学编程但一直被环境配置、语法细节劝退的新手被需求反复折磨想快速验证原型的产品和设计师以及所有想用 AI 把点子变成现实的人。这个系列后面还会聊怎么把 demo 变成正经项目、怎么和团队协作但第一课我们先解决“从 0 到 1”这件事。1. vibe coding 到底是个什么东西1.1 我第一次接触 vibe coding 的场景我大概是去年底开始频繁被这个词刷屏的。最早提出这个说法的是前 OpenAI 研究科学家 Andrej Karpathy他在一次分享里用一种很放松的口吻描述了自己的编程状态不是像一个严谨的工程师那样逐行推敲而更像是在带着某种“氛围感”编程——你让 AI 主导具体的实现自己在旁边跟着节奏走遇到报错就贴给 AI 改改不动再贴一次改完接着跑。我第一次真正意义上的 vibe coding 是在做一个临时数据清洗脚本的时候。以前这种活儿我至少要花一下午查标准库文档、调正则表达式那次我直接把 CSV 文件的结构跟 AI 描述了一遍说清楚我要哪几列、输出成什么格式。AI 不到两分钟就给了完整 Python 脚本我拿真实数据跑了一遍除了时间字段的格式需要微调几乎一次通过。那一刻我挺感慨的以前写代码90% 的时间耗在“不知道这个函数怎么写”上现在这 90% 的时间全省下来了剩下那 10% 的判断和检查反而成了真正的核心工作。后来我特意试了些更复杂的场景让 AI 帮我搭一个带星级评分的展品展示页、把一个 Excel 宏改写成 Python 逻辑、甚至让它逐行解释一段我完全看不懂的底层 C 代码。结果都超出我的预期。我开始意识到vibe coding 不是简单的“用 AI 写代码”它更像是一种把“表达能力”和“判断力”转化为生产力的新方式。这也是我做这个系列的起点。1.2 它和传统编程的本质区别在哪里很多人一听 vibe coding 就觉得是“不学语法也能编程”这个理解不能说错但太表面了。我自己总结下来它和传统编程的区别其实体现在几个核心层面。第一是代码的所有权变了。传统编程里代码是你一行行敲出来的你对它天然有一种“亲儿子”般的熟悉感。vibe coding 里代码是 AI 生成的你更像是一个审稿人或者项目负责人你需要能看懂大方向、能检查逻辑漏洞、能判断 AI 是不是在胡说。说白了你的角色从“作者”变成了“主编”。第二是调试方式完全不一样。以前调试是看报错、搜资料、自己推理变量在哪一步出了问题。现在的调试流程是把报错信息整段复制给 AI再附上相关的代码片段和上下文AI 会给出修复方案甚至直接补齐代码。你只需要判断这个修复方案是否合理、有没有引入新问题。第三是对知识边界的容忍度不同。传统方式下没学过的东西就是不会不会就得停下来查。vibe coding 允许你“先跑起来再理解”你可以在不太懂某个框架的情况下先把 demo 做出来然后让 AI 给你解释里面每个关键节点在干什么。这非常像一个知识海绵式的学习闭环。当然任何事都有适用边界。我的原则是vibe coding 特别适合快速原型、个人工具、学习探索、非关键业务系统但像银行账号系统、自动驾驶控制、医疗设备软件这种高可靠性场景你最好还是老老实实做正规的代码评审和测试。这不是在唱衰 AI这是对工程负责。2. 从 idea 到 demo五步流程先搭起来2.1 第一步把模糊想法压缩成一句话几乎所有从 idea 出发的人第一步都会栽在一个坑里——脑子里明明有个很酷的点子但一打开对话窗口就不知道怎么描述。我见过太多人上来就写“帮我做一个 App”AI 反手给你产出一大堆泛泛的框架代码最后啥也跑不起来你就觉得 vibe coding 是骗人的。问题不在 AI在于你的 idea 还处于“一团雾”的状态。我自己的方法是强迫自己把想法压缩成一个句子公式大概是我要做一个“XX”产品形态给“XX”目标用户用用来解决“XX”核心问题最关键的功能是“XX”和“XX”。你可以不写出来但脑子里必须有这条线。举个对比。坏的描述是“我想做一个记录生活的软件要有日历、照片、日记、社交功能。”这种描述信息量约等于零。好的描述是“我要做一个纯本地运行的每日待办清单网页不需要登录打开浏览器就能用核心功能是每天列出最重要的三件事勾选完成没有做完的自动顺延到第二天。”你看这一句话里包含了产品形态、部署方式、核心功能、数据规则AI 拿到之后就非常清楚该产出什么。如果你连这一步都做不好我建议你别急着写代码先拿纸笔把这句话写出来改到你自己觉得顺嘴为止。因为这一句话不只是给 AI 看的也是给你自己看的——它能倒逼你把模糊的想法想清楚这是 vibe coding 里最值得练的基本功。2.2 第二步选工具别被 IDE 劝退很多新手卡在第一步不是不会写代码而是环境装不明白。以前学编程最恐怖的事情就是你要装 Java、配环境变量、搞定 IDE、理解项目结构然后才能写出一个“Hello World”。这些准备工作足以劝退一大半人。vibe coding 时代我的建议是先不要碰任何复杂工具链从一个轻量的编辑器 一个现代浏览器 一个 AI 助手开始。这里我必须认真推荐一下 IntelliJ IDEA 社区版。它完全免费不需要折腾激活码那套事对 Python、JavaScript、Java、HTML/CSS 都有不错的支持而且社区资料极其丰富你遇到任何问题几乎都能搜到解决方案。对 vibe coding 新手来说它作为“第一个 IDE”非常稳妥不会把时间浪费在折腾环境上。如果你做的是纯网页 demo那工具就更简单了IDEA 里新建一个静态项目写 HTML/CSS/JS浏览器直接打开就能看效果。不需要什么服务器、数据库、框架。先把最轻的路径跑通建立起正反馈后面再往重了加。2.3 第三步让 AI 先写第一版工具准备好之后接下来就是核心动作把你在 2.1 里压缩出来的那一句话扩写成一个 AI 能照着执行的任务描述。我建议的格式是背景 目标 技术栈限制 功能清单 验收标准。举一个我实际做过的案例——一个叫“每日三件事”的网页工具。我当时的 prompt 大致是“请用原生 HTML、CSS、JavaScript 做一个每日待办清单页面不需要任何框架和构建工具。页面包含一个输入框和一个添加按钮用户输入今天最重要的三件事每件事显示为一张卡片点卡片可以标记完成未完成的事项在第二天自动顺延。数据用 localStorage 保存。界面简洁主要使用卡片布局配色舒服。”这个 prompt 里有几个小心机第一我明确了“原生 HTML/CSS/JS”和“不要框架”这样 AI 不会给你整一个 React 项目让你骑虎难下第二我给出了具体的交互细节“点卡片标记完成”和“自动顺延”AI 就能写出具体的判断逻辑第三验收标准隐藏在描述里——打开就能用、数据本地保存、跨天自动重置。在让 AI 动手之前你还可以让它先给一个文件结构方案比如“你觉得这个功能分几个文件写比较合理”。通常它会告诉你一个 index.html 放结构和引用一个 style.css 放样式一个 app.js 放逻辑。这个结构很标准新手照着走不容易乱。2.4 第四步本地跑起来人工兜底AI 给出第一版代码之后你的第一反应应该是让它跑起来。怎么跑纯前端项目最简单的方式就是在项目目录下执行一个本地静态服务器。比如你装了 Python在项目文件夹里打开终端输入python -m http.server 8000然后浏览器打开http://localhost:8000就能看到页面。这一步我见过很多人忽略直接双击 index.html 文件然后发现 localStorage 在某些浏览器下报 SecurityError就开始怀疑 AI 写的代码有问题。其实不是代码问题是 file:// 协议下浏览器对本地存储有限制。所以老老实实起一个本地服务器再看效果这是 vibe coding 里的一个基础操作能帮你避开大量假报错。跑起来之后不要指望一次成功。你的流程应当是试用 → 发现问题 → 把问题和相关代码贴给 AI → 让它修复 → 继续试用。这里我特别提醒一点贴给 AI 的问题描述要具体不要只说“不工作”“有 bug”要把操作步骤、预期结果、实际结果、报错信息都写清楚。比如“我添加了三件事之后第二天打开页面昨天没完成的事项没有顺延到今天而是消失了。报错没有。这是我的全部代码……”信息越具体AI 的修复就越精准。2.5 第五步demo 要能“拿得出手”很多人的 demo 做出来后自己知道怎么玩但发给别人根本看不懂。你要记住demo 的核心价值是验证想法和说服别人所以它必须具备某种“展示性”。我通常做三件事第一准备一组润色过的示例数据。比如你做的是读书笔记工具不要空空白白地给人看直接放三本真实的书和几句走心的摘录别人点开一眼就知道这个工具有什么用。第二写一段 3 分钟以内的演示说明说清楚你解决了什么问题你做了哪几个关键功能。第三把它放到一个别人能访问到的地方。个人项目我用 Gitee 的 Pages 服务比较多国内访问快也能直接给同事朋友发链接。如果你想用 GitHub Pages 也可以流程差不多提交代码到仓库开启 Pages 服务等它自动构建完就得到一个公网可访问的 demo 地址。到这一步你其实已经走完了从 idea 到 demo 的全过程一个想法、一句清晰描述、一版 AI 生成的代码、一次本地调通、一个能分享的链接。别小看这五步里面每一步都有坑后面我会用真实案例详细拆。3. 工具选型与环境准备3.1 IDE 怎么选IntelliJ IDEA 社区版够用吗我在 2.2 里推荐了 IntelliJ IDEA 社区版这里必须把“为什么”说透。很多人被网上各种激活码教程误导以为不搞个旗舰版就亏了。但你冷静下来想想一个 vibe coding 新手要做的事情无非是写 HTML/CSS/JS、跑个小脚本、整理文件结构、看报错。这些活儿社区版完全够用。旗舰版多的功能主要是 Spring、Jakarta EE 等企业级框架的原生支持、数据库工具、前端框架的专业支持等。如果你要跑 Spring Boot 这种 JavaWeb 项目社区版确实没有 Spring Initializr 的向导但这不代表跑不了。我的做法是先用 start.spring.io 网站生成一个 Spring Boot 初始项目包下载解压后用 IDEA 社区版直接打开Maven 会自动拉依赖照样能开发。只是少了些自动补全的便利但 demo 阶段真的够用。所以我的结论很简单别在 IDE 上花冤枉钱社区版 正版授权比什么都有底气。如果你有学生身份或者开源项目还能申请 JetBrains 的教育授权和开源授权等于白嫖全家桶。找答案的时候也优先查官方文档和社区别去那些来路不明的“激活”网站安全第一。3.2 我的 IDEA 基础配置新装 IDEA 之后我一般会做三件事这几件事能显著减少日常卡顿和不解之谜。第一把界面语言改成中文。在插件市场搜索“Chinese Language Pack”装完重启就有中文化界面了对新手友好得多也方便你以后查资料时对应中英文菜单名。第二检查文件编码。在设置里把全局编码和项目编码都设为 UTF-8不然从别人那拉来的项目会出现中文乱码那时候你不一定第一时间想到是编码问题。第三配置本地预览方式。IDEA 社区版没有内置 Live Preview 那种高级功能但插件市场里搜“Live Server”装上就能一键预览 HTML 页面火狐之外 Chrome 也支持非常省事。另外有一个设置我强烈建议每个人都看一眼Help - Change Memory SettingsIDEA 默认堆内存有时候偏保守如果你经常同时开多个项目或者项目文件比较多可以把它调到 2048MB 甚至更高能明显减少“卡死”“自动关闭”的概率。这个操作很简单但很多人不知道后面就没有后面了。还有一个我很依赖的操作习惯版本控制。就算你是自己做 demo我也建议在最开始就把项目文件夹变成一个 Git 仓库。IDEA 里新建项目时可以顺手勾选 Git 初始化或者用命令行git init。它最大的作用不是让你协同开发而是让你可以随便改、随便折腾万一改崩了一条回退命令就能回到稳定状态。这个安全感在 vibe coding 里尤为重要因为 AI 生成的代码有时候真的会越改越乱你有一个“后悔药”才能放手去试。3.3 AI 编程助手怎么接入工具链的最后一块拼图是 AI 助手。现在市面上主流的接入方式分三类IDE 插件型、对话型、命令行型。IDE 插件型代表有通义灵码、GitHub Copilot、Codeium 等它们的共同特点是直接在编辑器里给你补全代码、生成函数、解释报错。对话型代表就是大家熟知的各类大模型产品比如 ChatGPT、Claude、豆包、Kimi 等你可以把代码贴进去描述需求它给你完整代码回来你复制粘贴到项目里。命令行型像 Warp 和 Cursor 这类工具是把 AI 揉进了终端和编辑器本身能直接按照你的指令改文件。我的建议是新手先以对话型为主插件型为辅。对话型的好处是上下文可控——你知道你问了什么、它回答了什么逻辑链条清晰。插件型自动补全很爽但它有时会“半截输出”对你这种还没有代码判断力的人来说反而容易制造困惑。等你跑通几个 demo 之后再上插件型提升效率。至于选哪家看你所在环境的使用习惯就好各家免费额度对个人自用一般够了。我自己的原则是不迷信国外工具国内外的都试试哪个顺手用哪个。重点是你要花半小时学会“如何把需求说清楚”这比纠结工具型号重要得多。4. 实操记录把一个“每日三件事”想法变成 demo4.1 需求描述给 AI 的 prompt 该怎么写前面讲的都是理论这一节我把“每日三件事”这个案例完整走一遍你直接照着抄就能复现。先看我在 3.2 里说的——把想法压缩成一句话。我的原始想法其实是“一个不用登录的、打开就能用的日计划小工具”经过压缩变成下面这个 prompt请用原生 HTML、CSS、JavaScript 做一个“每日三件事”网页应用不使用任何框架和构建工具。 功能 1. 页面顶部显示今天日期标题是“每日三件事”。 2. 中间有一个输入框和一个按钮输入文字后点击按钮加入今天的待办列表。 3. 待办列表最多三张卡片每张卡片显示文字和一个“完成”按钮点击后卡片变为置灰状态显示已完成。 4. 每天首次打开页面时系统检查日期是否变化如果是新的一天把昨天未完成的待办自动顺延到今天已完成的不保留。 5. 所有数据用 localStorage 保存持久化到本地。 视觉要求卡片式布局配色柔和字体清晰适配手机和电脑宽度的简单响应式。这个 prompt 看起来不复杂但它把功能边界、交互细节、数据规则、视觉约束都写清楚了。AI 拿到这种描述产出的第一版代码可读性就很高。我特别要提醒的是第 4 条日期相关的规矩一定要写得具体不然 AI 很可能就简单粗暴地写一个“每天清空”那不是你要的效果。4.2 生成代码与落地调试AI 给我的第一版回复包含三个文件index.html、style.css、app.js。我按照它的结构在 IDEA 里建好文件把代码填进去然后在项目目录下执行python -m http.server 8000浏览器打开页面发现基本功能都在输入内容、添加卡片、点击完成置灰、刷新不丢数据。说实话第一版能做到这个程度已经超出不少新手手写代码的水平。但紧接着我就发现一个隐蔽的 bug。我添加了三件事勾掉了一件然后我手动把系统日期改成第二天再刷新页面预期是昨天没完成的两件事顺延到今天已经完成的那件消失。实际结果是三件事全部消失包括没完成的。这明显不对。我把这个现象和全部代码贴给 AI附上一句“我怀疑是日期判断或者过滤逻辑出了问题”。AI 很快定位到原因它用toLocaleDateString()生成日期标记在跨天判断的时候有些浏览器的实现会在某些区域设置下产生格式不一致导致比较失败。修复方案是把日期标记改成toDateString()它是一个更稳定的标准格式与地区时区无关。这个修复其实一行就解决了。我会把你手头在 AI 给的代码里搜一下saveDate new Date().toDateString()就能看到类似语句如果日期部分出问题优先检查这里。这种“跑起来之后修 bug”的循环就是 vibe coding 的日常。你不需要自己推理所有逻辑但你得能描述清楚现象、提供足够上下文然后判断 AI 的修复是否靠谱。这个例子里的修复我验证过改动极小、风险低可以采纳。4.3 结果检查与美化功能跑通之后我进入收尾阶段。我会用一个检查清单过一遍三件套是否都正常新增、完成、跨天顺延刷新页面数据是否还在手机宽度显示是否不跑版如果 localStorage 被禁用的时候页面是否崩这个是我后来被坑出来的AI 生成的代码常常不考虑这种极端情况我让它加了一层 try-catch保证在浏览器限制存储时至少还能临时使用。然后进行美化迭代我叫 AI 把配色改成偏日系的浅米色给卡片加柔和阴影顺手加了一个暗色模式开关。这些修改在对话里都能几轮搞定。最后我会在项目里加一个简单的 README 文件写清楚这个 demo 是干什么的、怎么运行、用了什么技术。这不仅是给别人看的也是给你自己留档的——几个月后再看你会感激当初写了这几行说明。做完这一步一个可以拿得出手的 demo 就算完成了。5. 常见问题速查与爬坑心得5.1 IDEA 相关高频问题实录做 vibe coding 离不开 IDE我整理几个出现频次极高的 IDEA 问题按“现象-原因-解决”列出来这些我基本都亲手踩过。现象常见原因解决办法代码格式化失效按快捷键没反应编辑器 Formatter 被禁用或安装了风格冲突的插件检查Editor - Code Style - Formatter Control确保没有开启“禁用格式化”必要时File - Invalidate Caches / Restart清理缓存项目 target 目录存在但侧边栏看不到IDEA 默认把编译输出目录标记为“排除”在 Project 窗口右上角齿轮菜单勾选“Show Excluded Files”或到Project Structure - Modules - Paths里查看编译输出路径IDEA 频繁自动关闭或卡死堆内存不够或某个插件崩溃Help - Change Memory Settings调高内存查看Help - Show Log里的崩溃日志逐个禁用可疑插件报错transport error 202: send failed: permission deniedGit over SSH 的密钥权限有问题检查~/.ssh目录权限一般应为 700密钥文件 600在 IDEA 的 Git 设置里把 SSH executable 切到 OpenSSHGitLab 登录提示“版本低于 14.0 不支持”IDEA 新版本放弃了对老 GitLab 的兼容优先升级 GitLab 到新版本如果暂时不能升级改用 Personal Access Token 加 HTTPS 方式别在登录弹窗里死磕Merge 之后想回退合并后发现代码不对在 Git Log 里选中 merge 提交右键选择 Revert Commit如果想彻底丢弃也可以找到 merge 前的提交执行 reset但要注意这是改写历史社区版想跑 Spring Boot没有 Spring Initializr 向导去 start.spring.io 生成项目压缩包解压后用 IDEA 打开配置 Maven 自动拉依赖即可还有人问过从 Gitee 拉项目到 IDEA、导入外部 jar 包这类基础操作。前者用File - New - Project from Version Control粘贴仓库地址就行后者在Project Structure - Libraries - 里选 jar 文件或者用 Maven 的 dependency 声明我建议尽量走 Maven 方式依赖管理更干净。另外我想多说一句IDEA 的插件生态里什么都有有人甚至装了摸鱼看小说的插件正经程度我不予评价但它至少说明一件事——就算你想开发 IDEA 插件本身vibe coding 也能帮上忙。AI 可以带你读 JetBrains SDK 的 API、生成插件骨架代码入门门槛比想象中低。5.2 AI 生成代码的典型坑AI 写代码不是万能的我用的时间越长越清楚它的短板在哪里。第一个坑是“功能对但异常处理为零”。我让 AI 做一个小工具时它默认用户会正常使用不会考虑 localStorage 被禁用、JSON 解析失败、输入为空等情况。这些边界条件你不提它基本不会主动加。所以我的习惯是在 prompt 里加一句“请对关键操作做异常处理”或者审查代码时专门检查有没有 try-catch。第二个坑是“一次生成太多代码出问题找不到根”。如果你让 AI 一口气生成一个完整应用它可能给你几百行代码逻辑夹杂在一起报错了你都不知道是哪块的问题。我的做法是让 AI 分模块写比如先写数据存取逻辑再写界面渲染再写交互事件。每块都能跑再拼到一起。这样定位 bug 的范围就小很多。第三个坑是“幻觉 API 和过时语法”。AI 在训练数据里见过大量不同版本的接口有时候它会给出一个根本不存在的方法或者一个在新版本已经移除的用法。这种问题不会报明显的错但运行结果就是不对。我的应对是如果 AI 引用了某个不熟悉的 API我会让它补充它的文档来源和版本要求然后用搜索引擎验证。哪怕多花两分钟也比被它带进沟里强。最后还有一个容易被忽略的安全问题。AI 生成的代码里如果涉及到网络请求、数据库连接你要警惕它把密钥、密码写死进代码里。demo 阶段危害不大但它会养成坏习惯。我在每次项目收尾时会全局搜一下 password、token、secret 这些关键字确保没有敏感信息裸奔。5.3 其他领域嵌入式、桌面应用、智能体写到这可能有读者觉得 vibe coding 只适合做网页小工具。其实不是我在嵌入式、桌面应用和 AI Agent 方向都见过很好的实践。嵌入式圈子里有个很常见的场景拿到一块 STM32 开发板官方 SDK 里有一堆 demo 例程过去你得自己啃数据手册、查寄存器定义现在你可以直接把某个例程的代码贴给 AI让它解释每一个外设初始化在做什么或者让它帮你改一个定时中断的逻辑学习效率比死磕手册高得多。还有一些专业工具比如汽车总线仿真软件 CANoe 的 demo license 安装过程以前照着文档步骤都容易踩坑现在把错误信息贴给 AI 分析几分钟就能理顺。这其实就是 vibe coding 在硬件领域的应用——虽然不直接“写”硬件但它在帮你理解和使用硬件方面帮了大忙。桌面应用方向更直接。现在用 Tauri Rust 开发桌面 App 的开源示例在 GitHub 上不少以前我看到 Rust 的所有权模型和生命周期标注就头大现在我可以把项目克隆下来让 AI 逐行解释关键模块遇到编译报错整段贴过去让它修复。等于说以前那些“门槛极高”的技术栈在一个懂行的 AI 辅助下变得可以亲近了。如果你对 AI Agent 感兴趣那 vibe coding 更是主场。agno 这类智能体框架的官方 demo 项目就是天然的练手材料你让 AI 帮你写一个调用工具、读取知识库、输出流式回复的 agent它真的能撸出一个可运行的骨架你再往里填业务逻辑。当然这种场景技术复杂度高我不建议零基础的人直接冲先打好网页 demo 的基础再说。最后说点实际的跑通第一个 demo 之后你会获得一种特别实在的正反馈——“我居然真的做出来了”。我自己最大的感慨是以前学编程卡在配置环境和语法细节上现在 AI 把门槛搬走了剩下的核心能力变成了两件事你能不能把想法描述清楚以及你敢不敢在报错面前多试几次。根据我个人的经验vibe coding 最忌讳的就是“完美主义”。你不需要一次把所有功能做完也不需要理解每一行代码你要做的是让 demo 先滚起来然后一点点完善。我在做“每日三件事”这个 demo 的时候后面还让它加了标签分类、统计图表甚至生成了一个简易番茄钟都是几轮对话就搞定的事儿。这种迭代速度在传统开发方式里不敢想。这个系列下一篇我会聊怎么把 demo 推进到能长期维护的正经项目版本管理怎么组织、代码结构怎么收敛、怎么部署到服务器让别人真正使用起来以及怎么避免 AI 生成的代码变成难维护的“屎山”。先把眼前这个 demo 做出来后面的路咱们一步一步走。