企业官网建设流程全解析

从今年年初开始，“vibe coding”这个词一直在我时间线上刷屏。一开始我也以为这只是又一个被炒热的流行标签，直到上个月我连续用这套方式从零做了三个小demo，才意识到它改变的确实不只是“写代码的方式”，而是“从脑子里一个模糊念头到屏幕上跑起来的东西”之间那段路的走法。这篇就聊聊我踩出来的完整路径：从idea到demo，工具怎么选，指令怎么给，迭代怎么跑，以及哪些地方会莫名其妙浪费掉你两小时。

1. 先聊清楚 vibe coding 到底在解决什么问题

1.1 什么是 vibe coding，它和普通“用AI写代码”有什么不一样

vibe coding 这个词最早被广泛传播，是 Andrej Karpathy 在一次分享里提到的。他用的说法很形象——你说不清自己在干嘛，就是跟着感觉走，一句话一句话地把需求喂给AI，让它把代码写出来，而你主要负责“看它跑起来没有”“哪里不对再告诉它改”。

很多人的第一反应是：这不就是让AI写代码吗？我早就这么干了。但琢磨一下会发现，vibe coding 的核心差别不在“用不用AI”，而在你把自己摆在什么位置。

传统用AI写代码，你的角色更像“审查者”：脑子里有一个明确的设计方案，知道要用什么框架、什么模块、什么数据结构，AI只是帮你把已知的逻辑敲出来，最后你一行行review。

vibe coding 不是这样。你更像是“产品经理加测试员”：脑子里只有一个粗糙的想法，甚至不知道这个想法应该用什么技术栈落地，你一边和AI对话，一边看它产出的结果，一边修正方向。AI负责“把想法用代码试出来”，你负责“判断这个方向对不对”。整个过程里，你会频繁写出自己不完全看得懂、但跑得通的代码——这是 vibe coding 最让人不适、也最让人上瘾的地方。

1.2 它真正降低的是“翻译成本”，不是“学习成本”

网上讨论 vibe coding 时，最常被误解的一点是：以为它可以让你完全不学编程就做出产品。我的实际体感是，它降低的绝对不是学习成本，而是从想法到可运行代码之间的翻译成本。

举个例子。我想做一个“在网页上给照片加滤镜的在线工具”。如果走传统路线，我得先确定：用纯前端还是前后端分离？图片处理放在浏览器端用 Canvas 还是上传到服务器？UI框架选什么？颜色矩阵怎么算？这些决策本身，对一个不熟悉前端生态的人来说，每一个都是一道门槛，随便选错一个方向，后面要推倒重来。

vibe coding 的路径完全不一样。我只需要说：做一个网页工具，用户上传一张照片，能在左侧选择几种常见滤镜，右侧实时显示出效果，可以下载处理后的图片。AI会直接告诉我用 HTML+CSS+JavaScript 加一个 Canvas 就能搞定，然后一篇一篇把代码吐出来。我不需要事先知道 Canvas 的 API，只需要在它跑起来之后点一点、看一看，说“这个复古滤镜太暗了，再提亮一点”“加一个滑动条控制模糊程度”。决策从“技术选型”变成了“产品体验判断”，这就是它在降低的那部分成本。

这也解释了为什么我建议有编程基础的人也别急着看不起它——它压缩的恰恰是写样板代码、搭工程结构、查文档这些最没创造性的时间，把精力腾出来放在产品感觉上。

1.3 vibe coding 不等于“放手不管”，你的审美和技术判断仍然值钱

我最开始尝试的时候犯过一个错误：把需求说得特别宽泛，然后等着AI给我一个完整项目。结果它给出一个能跑的网页，但代码里到处是重复的函数、魔数、臃肿的依赖，改一个小按钮样式都会牵一发动全身。那一刻我意识到，vibe coding 对“判断力”的要求其实更高了。

你需要能判断：AI给的方案是不是过度设计了；这段代码看起来不对劲的时候，是应该让它重构还是先跑通再说；以及最重要的——什么程度算“可以了”。这个东西靠感觉，但感觉是有门槛的。没写过代码的人可能觉得“能跑就行”，写过几年代码的人会知道“能跑”和“能改、能维护、能给别人看”之间差着一个银河系。所以我的个人结论是：vibe coding 不是零基础者的天堂，而是有经验者的杠杆。零基础用它，能做出来demo；有基础用它，才能做出来产品。

2. 从 idea 到 demo 的工作台：我目前用的这套组合及理由

2.1 工具不用多，三样就够：对话式IDE、AI助手、一个能跑的运行时

经常有人私信问我 vibe coding 要用什么“专业工具”，好像有什么神秘软件。实际上我跑通整个流程，靠的就是下面这三样：

我的主力是 Cursor，因为它的对话能和当前打开的文件、报错信息联动，不需要我把报错内容复制来复制去。如果你不想用 Cursor，VS Code 加 GitHub Copilot 或者下载任一一款支持 AI 对话的编辑器也一样，工具本身不是瓶颈，关键是你能不能把“想法”清晰地描述出来。

只有一个例外——如果目标就是写一个特别小的、纯前端的工具页（比如计算器、图片格式转换器），直接用 Claude 或 ChatGPT 网页版拿到代码，粘贴进 HTML 文件，双击用浏览器打开，连编辑器都省了。我在做那种“一次性小工具”时经常这么干，五分钟内搞定。

2.2 为什么我不建议从“新建空白项目”开始

很多跟我一样从传统开发走过来的人，第一次 vibe coding 会有个执念：让AI帮我搭一套完整的前端工程脚手架——Vite、React、路由、状态管理，一步到位。我一开始也这么想着，后来发现这是最容易翻车的开局方式。

原因在于，AI生成的代码规模越大，越容易出现“上下文漂移”。你问它“帮我初始化一个 React 项目”，它给你几十个文件；你再让它改某个组件的样式，它可能只改了目标文件，但另一个文件里 import 的东西和你的需求对不上，于是一个报错接一个报错。最糟的是，你还不知道哪儿错了，因为每个文件看起来都挺正常的。

后来我换了一套思路：先让AI给出一个最小可运行版本，甚至都不用文件拆分，直接在单个 HTML 文件里把核心逻辑跑起来。确认核心流程没问题之后，再让AI把“能跑的东西”拆解成“工程化的结构”。这个顺序和传统开发完全相反，但配合 vibe coding 的对话式节奏反而特别顺。

2.3 环境准备：Node.js 是默认选择，Java 或 Python 看场景

跑 demo 用哪个运行时，取决于你的目标形态，我在几个常用选项里做了对比：

• 网页工具/小应用：Node.js（配 npm）是默认选择，因为前端工具链都基于它，装组件、启动本地服务都方便。
• 数据处理/算法验证：Python 更省事，PYPI 生态里什么都有，一行 pip install 就装好依赖。
• 安卓 App / 后端微服务：Java（配 IntelliJ IDEA 或 VS Code）更合适，尤其是要做成能在手机上跑的 demo。IDEA 社区版就够用，不一定非得上旗舰版。

如果你不确定你的 idea 到底该用什么技术栈，可以把决定权交给AI。我自己常用的第一句开场白是：“我要做一个XX，这个场景最适合用什么技术栈？假设我是新手，给我一套最简单的起步方案。”AI会给一个推荐项，还会告诉你为什么，比你花一下午去论坛考古靠谱得多。

2.4 把版本管理从第一天就跟上，哪怕只有你一个人

这一点是我从一次惨痛经历里学到的：连着两天改一个 demo，第三天跑不起来了，但完全想不起前两天改了哪里、哪一步改坏了。从那以后我养成了一个习惯——每完成一个可运行的小阶段，就提交一次 commit。哪怕只有我一个人开发，Git 仓库也是必须的。

用 vibe coding 还有一个额外的好处：因为每次改动都是对话驱动的，提交信息可以直接用对话里的那句指令，比如“add photo filter feature”。下次想让 AI 回滚到某个状态，或者问它“为什么这个功能这样实现”，直接翻 commit 记录和对应的对话，效率非常高。我见过不少人做完 demo 之后后悔没建 repo，希望看到这篇的你别踩同一个坑。

3. 实操全过程：从“我想做一个记账小程序”到跑起来

3.1 第一轮对话，把抽象想法“翻译”成AI能执行的指令

这节我拿一个我最近做的真实案例来演示：一个给个人用的记账小程序。整个过程我几乎没有手动写过代码，每一行都是跟AI聊出来的。

第一轮我给的指令是这样：

我想做一个记账小程序，用在浏览器里。主要功能：添加一笔支出（金额、分类、备注、日期），按分类和月份查看账单列表，能统计某个月的总支出。先不用登录和数据库，数据保存在浏览器本地就好。请给我最简单的实现方案，最好一个文件就能跑起来。

注意我在这句话里做了几件事：说清了产品边界（记账、支出、分类、月份统计）、说清了技术要求（浏览器、本地存储、不登录、不用数据库）、说清了交付约束（最简单、一个文件能跑）。AI 秒懂，给了我一个用 HTML + CSS + JavaScript + localStorage 的方案，然后一整个文件就出来了。

有一个细节值得说：如果你第一轮就说“帮我做个记账App”，AI 会立刻往重了做——给你脚手架、给你后端、给你数据库配置，然后你在配置环境上耗费一小时。“最简单、一个文件、先跑起来”这些限制词，是 vibe coding 里最重要的魔法词。

3.2 让“错误”成为你的下一步指令来源

跑起来之后，第一个版本是这样的：表格能添加支出，列出明细，按日期排序，顶部显示总支出。但我试了一下之后，发现两个问题：第一，分类是自由输入的，导致“吃饭”和“餐饮”成了两个分类，统计结果就乱了；第二，没有“编辑删除”功能，输错了只能删掉本地缓存重置。

我没有自己动手改代码，而是直接把我的感受发给AI：

现在有两个问题：1. 分类必须是固定的几个选项，不要自由输入；2. 每条记录要能编辑和删除。分类我先用这么几类：餐饮、交通、购物、娱乐、居住、其他。

AI 把 HTML 里的输入框换成了下拉选择器，给每条记录都加了编辑和删除按钮。整个过程大概三分钟。这个节奏非常典型——你不是在“指挥”AI写代码，而是在“验收”它写出来的东西，然后把“验收意见”反馈回去。用传统开发的心态，你会觉得这像在开一个需求变更会；用 vibe coding 的心态，这就是最自然的工作流。

3.3 迭代从“能用”到“像样”：样式与交互细节的调优

核心逻辑跑通以后，我开始提视觉和交互上的要求。这些要求如果写成传统的 UI 设计稿，没两页纸下不来，但在 vibe coding 里就是几句大白话：

界面设计得清爽一点，整体风格偏日式极简，不要用默认的表单样式。月份统计的部分用卡片展示，支出分类不同的颜色。移动端也要能正常看。

AI 在原来的文件里动了 CSS，加了几段响应式布局，配色换成了低饱和度的感觉。浏览器里刷新一下，整个观感立刻不一样了。第二轮我又追加了：支出金额输入框要带货币符号，月份切换用左右箭头，底部的统计数字要突出显示。这些细碎的调优，如果全都走“提需求-排期-开发-测试”的流程，没有一周拿不下来，用 vibe coding 一边聊一边改，半小时就妥了。

这里有个经验我要特别强调：一次不要提超过三到五个修改点。我试过一次给AI列十个问题，它改完以后有一半没改对，有些地方还改出新的 bug。后来我改成每轮聚焦三五个点，改完立刻验证，通过之后再提下一批，成功率直线上升。看起来很慢，实际反而快。

3.4 数据与持久化：一个容易踩的坑

记账小程序跑到第二周，我遇到一个问题：浏览器 localStorage 里的数据被我不小心清了，所有记录都丢了。虽然只是测试数据，但这也提醒了我——本地存储不等于持久化存储，刷新网页还在，换个浏览器、清个缓存就没了。

如果你做的 demo 只是给自己验证想法，localStorage 够用了；但如果想分享给别人试用，或者数据稍微重要一点，就得让AI把存储层换成“后端数据库”。我当时的路子是：让AI在本地跑一个最小的 Node.js 后端服务，数据存到 SQLite 文件里，前端通过接口读写。听起来很“重”，但AI只需要几分钟就搭好了，而且整个过程没有让我手动安装数据库、写建表语句——全部靠对话完成。

这也是 vibe coding 一个隐藏的好处：你可以渐进式地给 demo“加厚度”，从纯前端到带后端，从本地存储到数据库，每一步都有可运行版本兜底，不至于一开始就被工程复杂度劝退。

4. 我在 vibe coding 路上踩得最疼的几个坑

4.1 “上下文越权”问题：AI 改着改着就丢了前面的需求

这是我最常遇到的坑，也直接决定了你对 vibe coding 的体验是好是坏。AI 的注意力窗口虽然是有限的，但实际上的瓶颈在于：当你的项目文件越来越多、对话轮数越来越长，AI 很容易“只盯着你最后这句话”，而忘了最开始定下的约束。

最典型的一幕：我在一个项目早期约定“不要引入第三方 UI 框架，用原生 CSS”。到了第五轮，我让它加一个弹窗组件，它直接引了一个 UI 库，install 了一堆依赖。我当场就有点哭笑不得——你不能说它错，但它违反了项目最底层的约定。

我的应对方案是两招：

• 开新会话时，把项目简介和关键约定重新粘一遍。我常驻一个PROJECT_CONTEXT.md文件，里面写清楚“这个项目是什么、技术栈是什么、哪些约定不可违反、当前完成到哪一步”，每次开新对话或让AI做较大改动前，先把这个文件贴给它。
• 不要在一个对话里做太多不相关的事。“修登录逻辑”和“改首页样式”这两件事放在同一个对话里，AI在改后者的时候很可能把前者改坏。分开对话，各自独立，出问题也容易定位。

4.2 能跑 ≠ 安全：AI 生成的代码里可能存在隐藏雷

vibe coding 轻松愉悦的氛围会让人放松警惕，但我在用 AI 写的代码里发现过不少让我后背发凉的细节。最吓人的一次：我让它写一个图片上传功能，它直接把上传接口拿来做图片处理，且没有限制文件类型和后缀，等于别人可以往我的服务器传任何文件。要知道我本来只是想要一个“个人相册”demo。

从那以后我养成了一个强制习惯：只要涉及用户输入、上传、登录、支付、数据导出这类敏感功能，哪怕demo也必须让AI详细解释这段代码在干什么，有没有安全风险，然后我再单独针对安全性篏一轮对话，问“这个接口有没有注入风险”“这个文件上传有没有校验”。如果你对安全不熟，至少记得一句：不要让 AI 生成的和用户数据相关的接口裸奔。

另外，API 密钥和 token 的问题也值得说一句。AI 有时会把一个硬编码的 key 直接写到代码里，而你还不知道它是什么。我一般做完 demo 之后，会全局搜一下api_key、secret、password这类词，看看有没有不该出现的东西。真有的话，立刻删掉，用环境变量替代。

4.3 不要盲目“重构”：AI重构会让你的项目陷入循环崩溃

我犯过的最浪费时间的一件事：贪图“代码质量”，让AI把一个能跑的小项目拆成多目录多模块的工程化结构。它拆到一半，import 路径乱了，好几个文件报红。我让它修，它改了这个文件，另一个文件又报错，最后进入“按下葫芦浮起瓢”的循环，整整耗掉一个下午，最后我不得不从之前的 commit 回滚。

我的教训是：demo 阶段不要追求工程化，跑通 > 结构。如果确实要重构，务必在重构前提交一次 commit，然后让AI一次只移动一个模块，每个模块移动后都跑一遍原有功能，确认没问题再动下一个。慢是慢了点，但至少不会掉进循环。

4.4 判断一个 idea 适不适合用 vibe coding 快速出 demo

经过这阵子的尝试，我总结出哪些想法适合、哪些不适合用 vibe coding 做，供你参考：

我个人的建议是：刚开始学 vibe coding，从“工具类网页”入手是最稳妥的。这类项目技术栈成熟、AI 生成的方案不容易跑偏，而且给你带来的正反馈非常及时——通常十分钟内就能看到能用的成品。

4.5 给新手的 v0 到 v1 练习清单

如果你已经跃跃欲试，我给你一套从小到大、从易到难的练习题，都是我自己练过的路径：

1. 做一个在线计算器（纯前端，用一个 HTML 文件）
2. 做一个待办事项列表（加入 localStorage 持久化）
3. 做一个 Markdown 预览页面（输入左边，渲染右边）
4. 做一个简单的记账页面（加入分类和月份筛选）
5. 做一个用公开 API 的查询工具（比如查天气、查汇率）

每做完一个，都试着用对话让AI加一个新功能，然后观察它是怎么在原有代码上做改动的。积累到第五个，你会发现你在给 AI 下指令的时候，已经不再是一个“只会描述现象的外行”，而是能说出“请把数据层和渲染层分开”“请用函数封装这段逻辑”这些真正的行话了。到这一步，你就已经摸到 vibe coding 的门道，不再是被 AI 带着走，而是你在带着 AI 干活。

我个人在实际操作里最大的体会是：vibe coding 这把火，烧掉的不是程序员的价值，而是“从想法到demo之间那些磨磨蹭蹭的等待时间”。以前一个念头落地，先考虑三天、再搭建一周、再写三周，等真正跑起来的时候，热情已经凉了一半。现在从 idea 到一个能点击、能交互、能给别人看的 demo，通常就是一个晚上的事。这个速度带来的最大变化不是产出多了，而是你愿意去尝试那些以前觉得“不值得做出来”的小想法了——而很多大东西，恰恰是从这些小想法里长出来的。