企业官网建设流程全解析

vibe coding 这个概念最近被讨论得很多，简单说就是让你用自然语言描述需求，让 AI 编程工具把代码生成出来。它不是让你完全不懂编程，而是把“写代码”变成“提需求、看结果、改描述”。很多新手问我的第一个问题不是功能有多强，而是：我完全没有基础，真的能靠 vibe coding 跑通一个项目吗？

这篇第三期，我不打算继续聊概念，直接回到实操。我会按自己实际测试时的顺序，讲清楚你需要准备什么、按什么流程跑、结果怎么验证、出问题先查哪里。尽量把话说得直接一些。涉及具体平台、版本和参数的地方，我都按通用流程来写，你落地时以自己的环境为准。

1. 先确认 vibe coding 解决的是需求转代码，不是自动做产品

vibe coding 的准确理解，应该是“用自然语言驱动代码生成”，而不是“把脑子里的产品想法直接变成一个成熟软件”。它最擅长的，是把已经想清楚的功能需求，快速变成能运行的原型页面、组件、函数和接口调用。至于这个需求本身合理不合理、边界条件有没有漏、数据权限怎么设计、出现异常怎么处理，这些还是需要人来判断。

很多新手一开始就让它“做一个像某 App 一样的完整应用”，结果生成出来的东西要么很大很空，要么运行报错。原因不是 AI 能力不够，而是这个需求本身就超出了自然语言生成的合适粒度。vibe coding 更适合拆开做：先做一个登录页，再做列表页，再做详情页，再把数据连起来。

1.1 自然语言生成代码的能力边界

先说清楚它能做什么、不能做什么，后面少踩坑。

能做的：

• 根据描述生成 HTML、CSS、JavaScript、TypeScript 页面。
• 生成常见框架的组件和页面结构，比如 React、Vue 这类前端框架。
• 完成简单的数据过滤、排序、统计、表单校验逻辑。
• 调用常见接口，处理返回结果，展示成页面。
• 生成 Node.js 脚本、命令行工具、数据处理脚本。

不能完全依赖它的：

• 产品需求拆解。模型不会帮你判断“这个功能是不是用户真正需要的”。
• 复杂的权限模型。比如多角色、多租户、细粒度权限，AI 生成出来通常很浅。
• 安全性设计。登录、加密、支付、防注入，这些必须由有经验的人再过一遍。
• 架构和性能规划。小 Demo 能跑和线上几百人同时用是两回事。
• 边界条件和异常处理。它经常只回答“正常情况”下的代码，用户输入异常、网络超时、数据为空时，逻辑可能就不完整。

所以我在实操时，会把 vibe coding 定位成“一个随叫随到、写代码很快的助手”，而不是“产品经理 + 架构师 + 测试工程师”的合体。

1.2 三种用户，三种不同的玩法

我见过三类人用 vibe coding，结果差别很大。

完全没有编程基础的人，适合从单页小工具开始。比如一个待办清单、一个记账页面、一个倒计时工具。这类项目文件少、逻辑简单、效果直观。先跑通一个，建立“自然语言 → 可运行页面”的体感，再往复杂项目走。

有一定编程基础的人，可以让它生成组件和函数，然后自己审查逻辑。重点不是看它写的每行代码，而是看输入输出是否一致、边界情况是否覆盖。遇到不满意的地方，直接用自然语言指出来，让它改。

已经是开发者的人，更常见的是用 vibe coding 做原型验证、写一次性脚本、生成后端 CRUD 代码、生成测试数据。这类人不太关心代码能不能跑通，更关心生成速度和自己改起来顺不顺手。

不管你是哪类，记住一个核心判断：vibe coding 的效率来自“快速生成 + 快速验证”的循环，而不是“一次生成、永久正确”。

2. 起步前准备：环境、平台、目录和需求描述

第一次使用，不用把环境搞得太复杂。很多在线平台打开浏览器就能用，这是最低门槛。真正决定能不能顺利跑起来的，往往是需求描述和验证方法。

2.1 在线平台是最低门槛

现在有不少在线 AI 编程平台，像 Vercel AI 这类服务，常见流程都差不多：注册登录 → 新建项目 → 选择 Web 应用模板 → 在对话框里写需求 → 平台生成项目文件 → 在线预览 → 导出或关联代码仓库。

这里我只说通用流程，因为不同平台的入口、模板名称、免费额度、套餐价格都不一样。第一次用时，先看官方文档，确认三件事：

1. 免费额度能生成多少项目。
2. 是否支持导出完整代码。
3. 预览环境有没有资源限制，比如请求超时、并发限制、存储上限。

在线平台适合学习、原型验证和快速演示。它的好处是省去本地环境配置，你在浏览器里就能看到结果。缺点是长期项目开发时，你可能还是要把代码拉到本地，用 Git 管理版本。

注意：在线预览能跑，不代表本地一定能跑。导出代码后，先按项目里的说明文件检查依赖和运行命令。

2.2 本地运行要准备什么

如果你要把项目拿到本地改，或者最终要部署，那就需要补基础环境。

前端项目最常见的要求是 Node.js 和 npm。Windows、macOS、Linux 都可以，关键是安装的 Node.js 版本不要太老。你可以先用命令确认：

node -v npm -v

能正常输出版本号，说明基础环境没问题。如果提示命令不存在，就去 Node.js 官网下载当前稳定版安装。安装过程我自己一般不勾选额外组件，保持默认即可。

然后把生成的项目下载或复制到本地，进入项目目录：

cd your-project npm install npm run dev

npm install是安装依赖包，npm run dev是启动本地开发服务。启动成功后，终端通常会显示一个本地访问地址，比如http://localhost:5173或http://localhost:3000。浏览器打开这个地址，能看到页面就说明本地运行通过。

有一个容易忽略的点：项目里可能还会使用 Git。建议从一开始就在项目目录里执行git init，每次改完代码做一个提交。这样后面改坏了可以回退，不怕 AI 生成的代码把项目弄乱。

2.3 需求描述怎么写才不容易翻车

需求描述是 vibe coding 里最重要的输入。描述清楚，生成的代码大概率可用；描述含糊，生成结果就容易飘。

我建议用这个模板：这个东西是什么 + 给谁用 + 有什么功能 + 每个功能怎么交互 + 数据存哪里。不一定每句都按顺序写，但关键信息不能少。

对比一下：

我写需求描述时，会把功能控制在 3 到 5 个以内。比如“新建笔记”一个点，“编辑笔记”一个点，“删除笔记”一个点，“保存到 localStorage”一个点。不要一次要求 20 个功能，否则生成代码会很长，出问题后很难定位是哪里坏了。

如果 AI 生成的结果和预期不一样，不要急着否定，而是补充描述。比如“删除按钮要加二次确认”“标题超过 20 个字要省略”。这种小步修正，比一次性推翻重来更省时间。

3. 一条最稳的 vibe coding 实操流程

我测试过不少次 vibe coding，现在固定下来的流程是：最小页面 → 预览验证 → 小步迭代 → 落到本地工程。这套顺序看起来很保守，但对小白来说最稳。

3.1 先做一个最小可运行页面

不要上来就挑战完整项目。第一步只提一个最小需求：一个页面，包含标题、一个按钮、一个输入框、一个文本显示区域。

比如：

帮我生成一个空白网页，页面标题是“我的第一个 vibe coding 项目”，页面上有一个输入框和一个按钮，点击按钮后，把输入框里的文字显示在页面下方。

这个需求很小，但已经覆盖了页面结构、事件绑定、数据读取和展示四个基本环节。成功标准很清楚：

• 页面能打开。
• 输入文字后点按钮，文字显示出来。
• 浏览器控制台没有报错。

先跑通这个最小闭环，再继续加功能。这个习惯能帮你把“功能问题”和“工具问题”分开。

3.2 预览、点按钮、看控制台

生成代码后，先做三件事。

第一，预览页面。看页面布局是否正常，有没有元素重叠、按钮不显示、文字乱码。

第二，实际点一下按钮，测试交互。输入内容不要太复杂，先输入“hello”这种简单文本。看显示结果是否和预期一致。

第三，打开浏览器的开发者工具，也就是控制台。右键页面选择“检查”，或按 F12，切到 Console 面板。如果页面上某个操作没反应，控制台通常会显示红色报错。把报错信息复制下来，直接发给 AI 工具，让它根据报错修改代码。

这一步非常关键。很多新手看到页面“没反应”，就以为 AI 生成错了，实际上可能是数据没存成功、按钮事件没绑定、或者浏览器报了一个小错。控制台是你和代码之间的沟通窗口。

3.3 小步迭代，一次只改一个点

最小页面跑通之后，再开始加功能。我建议每次只加一个需求点。

比如先加一个“清空按钮”：

在原来的页面上再加一个“清空”按钮，点击后清空输入框和下方显示的文字。

等这个功能验证通过，再加“删除某条记录”“编辑某条记录”“按日期排序”。每次只改一个点，出现问题时，问题范围很小，很容易定位。

不要做这些操作：

• 一次性把“增加搜索、增加标签、增加语音输入、增加暗黑模式”全部丢给 AI。
• 让 AI 连续生成多个页面，中间不验证。
• 页面报错后，不贴报错信息，只说“不行，重写”。

这些做法会极大降低 vibe coding 的效果。代码越长，工具越难一次性处理好所有逻辑。

3.4 从在线项目落到本地工程

在线预览验证通过后，把代码落到本地。一般平台会提供下载按钮，或者可以直接复制生成的文件内容。如果平台能关联 Git 仓库，更推荐直接推送到仓库里，然后再 clone 到本地。

本地运行最常见的错误，我之前提过，就是依赖安装失败或启动失败。遇到这类问题，先看报错信息，再看 Node.js 版本和项目依赖版本。比如某个依赖只支持新版 Node.js，而你本地还在用旧版本，就会报错。

不要把“本地跑不起来”直接等同于“AI 生成的代码是垃圾”。大部分情况是环境问题：依赖没装上、版本不对、缺少配置文件、端口被占用。

注意：改完代码后，如果页面表现和预期不一致，先刷新页面并清一下浏览器缓存，再判断是不是代码逻辑问题。

4. 判断生成结果：质量、运行速度、资源占用

vibe coding 生成的项目，不能只看“能不能打开”。能用、好用、扛得住批量使用，是三个不同标准。我一般从几个维度判断。

4.1 生成质量看什么

第一个维度是功能完整性。需求里提到的新建、编辑、删除、保存，每个功能都要能跑通。少一个都不算完成。

第二个维度是逻辑正确性。比如编辑一条数据，修改后列表里的数据是否同步更新；删除一条数据，其它数据是否错位；保存到 localStorage 后，刷新页面数据是否还在。这些都需要手动验证。

第三个维度是代码可读性。打开生成的文件，看变量名是不是有含义，函数是不是拆得清晰。如果整个页面只有一个巨大的文件、几千行代码堆在一起，后面你会很难维护。可以让 AI 重构：“把代码拆成几个函数，每个函数只做一件事”。

第四个维度是异常处理。比如输入框为空时点保存，会不会报错；接口返回失败时，页面有没有提示。很多 AI 生成的代码默认用户“输入正常”，这种默认在真实项目里不够用。

4.2 运行速度和资源占用看什么

小工具无所谓，但项目变大之后，就要关注性能和资源占用。

• 页面打开速度：浏览器加载页面需要多长时间。如果超过 3 秒，优先看图片是不是太大、请求是不是太多。
• 构建速度：本地执行npm run build或者在线平台构建项目要多久。构建时间过长，常见原因是依赖包太多或配置没优化。
• 内存占用：打开任务管理器或系统监视器，看浏览器和 Node 进程的内存占用。如果内存持续飙升，可能是代码里循环有问题或数据量过大。
• 网络请求数量：打开控制台的 Network 面板，看页面加载时发起了多少个请求。请求过多也会拖慢速度。

我建议不要一开始就纠结性能。先把功能跑通，再根据数据量和实际使用情况判断要不要优化。如果只是做一个给自己记笔记的小工具，过度优化没意义。

4.3 参数调整的通用思路

不同平台和本地项目会有一些参数需要理解。常见的有：

• 端口号：本地开发服务默认使用某个端口，例如 3000、5173 或 8080。端口被占时会提示，可以改用其它端口。
• 构建命令：在线平台部署时，通常要求填构建命令和输出目录。前端项目一般是npm run build，输出目录可能是dist或build。
• 环境变量：如果项目需要连接数据库、接口地址、密钥，一般会放在.env文件里。AI 生成代码时会引用这些变量，但不会替你填真实值。
• 超时时间：如果页面请求接口比较慢，要看请求超时设置。默认超时太短，接口还没返回就报错了。

这些参数我建议在同一个项目里先写死测试，等熟悉之后再用环境变量管理。不要第一次就在多个配置之间来回改。

5. 跑不起来、结果不对时的排查顺序

vibe coding 一定会遇到报错。问题不在于会不会报错，而在于你用什么顺序排查。我自己总结了一套顺序，先现象，再输入，再环境，再参数，最后才怀疑工具本身。

5.1 先把现象归成四类

可以把问题分成四类，处理方式不一样。

• 页面打不开：白屏、404、一直转圈。优先看启动命令是否正确、端口是否正常、构建是否成功。
• 页面打开了，但点按钮没反应：优先看控制台报错，再看按钮事件是否绑定、函数是否被正确定义。
• 功能有反应，但数据不对：比如新增后列表不更新、结果计算错误。优先看数据结构和逻辑处理部分。
• 界面显示混乱：样式不对、布局错位。优先看 CSS 是否引入、样式是否有冲突、生成结果是否缺少响应式处理。

先确认现象，排查范围就缩小了。不要一上来就怀疑“AI 把整个项目写错了”。

5.2 按“输入 → 环境 → 参数 → 工具”的顺序查

我的排查顺序是这样的：

1. 先看报错信息。把控制台、终端、平台日志里的报错复制下来，找到第一行报错位置。
2. 再看输入。检查需求描述里提到的功能点有没有遗漏，生成的文件是否完整，引用的文件路径是否正确。
3. 再看环境。确认 Node.js 版本、依赖安装情况、文件权限、端口占用。
4. 再看参数。确认平台配置、构建命令、输出目录、环境变量是否填写正确。
5. 最后再看模型或工具本身。如果前面都正常，只有某一个非常冷门的功能不支持，才有可能确实是工具能力边界。

按这个顺序，大部分问题都能在第三步之前解决。很多“看起来像代码逻辑错误”的问题，其实是路径拼写错了、依赖没安装、或者端口被占用。

5.3 三个典型的翻车案例

案例一：npm install报ERESOLVE unable to resolve dependency tree。这种情况经常是某个依赖的版本冲突。不用急着删除整个项目，先检查报错里提示的包名和版本，尝试安装报错中提到的兼容版本，或者让 AI 根据 package.json 修复依赖版本。

案例二：数据保存失败。如果项目用的是浏览器 localStorage，直接通过file://协议打开本地 HTML 文件，某些浏览器会限制存储功能。运行方式改成npm run dev，通过本地服务地址访问，通常就好了。

案例三：接口返回undefined。AI 假设了某个返回字段，但实际接口返回的字段名不一样。这种情况不是修改页面，而是先打开控制台的 Network，找到对应请求，看 Response 结构，再把真实字段名发给 AI，让它重新调整解析逻辑。

排查时要有耐心。不要连续追问 AI 十次“为什么还不对”，却不提供任何报错信息。每次贴出完整报错，并说明你做了什么操作、期望结果是什么、实际结果是什么，这样工具才能给出有用修改。

6. 从单次生成到项目落地：批量、工程化和鸿蒙场景

vibe coding 跑通一个小项目后，很多人会想：能不能一次生成多个页面？能不能把它当成正式项目的开发方式？在鸿蒙这类特定生态里能不能用？这些需求都真实，但需要调整玩法。

6.1 批量生成时要管理的输入输出

批量生成不是“打开 10 个窗口，同时让 AI 干活”。它需要一套统一规则。

我见过一个比较靠谱的做法：先建一个需求清单文件，每一行描述一个页面或功能，命名规范统一。例如：

然后按清单逐个生成。每生成一个，先验证，再进入下一个。不要一次性要求同时生成 20 个文件，否则输出目录、文件命名、相互引用很容易乱。

批量任务里，失败重试和命名一致是比“生成速度”更重要的指标。要确认每个文件都有明确的输出位置，生成失败时能单独重试，而不是全部重新生成。

6.2 Demo 变成项目需要补的东西

AI 生成的小 Demo 和正式项目差得比较远。如果你想把 vibe coding 用于更正式的开发，至少要补这些：

• 错误处理：所有接口调用和用户输入都要有失败提示。
• 日志：在关键操作点输出日志，方便排查问题。
• 配置管理：接口地址、用户信息、密钥等不能硬编码在页面里。
• 版本控制：用 Git 管理代码，每个功能点单独提交。
• 目录结构：按功能拆分页面、组件、工具函数和配置文件。

我建议让 AI 先生成第一版，然后做一轮“工程化改造”：“把接口请求统一封装到 api 目录，把通用组件拆到 components 目录，加上基础错误提示”。这轮改造能让项目结构清晰很多。

注意：AI 生成的项目可以帮你快速搭建，但代码审查不能省。尤其是涉及账号、支付、用户数据的功能，一定要让有经验的人把关键逻辑过一遍。

6.3 鸿蒙环境下 vibe coding 的实际边界

鸿蒙应用开发近两年热度很高，很多人在问 vibe coding 能不能用于鸿蒙。要分层看。

如果目标是生成页面布局和基础交互代码，AI 确实可以辅助生成 ArkTS、ArkUI 风格的页面结构，类似用自然语言描述控件、列表、点击事件。这部分作为学习和原型验证是可行的。

但如果目标是编译成能在鸿蒙设备上运行的正式应用，那就要明确边界：AI 工具不一定知道你本地的 SDK 版本、设备 API 级别、签名配置和工程目录结构。它生成的代码经常是“看起来像 ArkTS，但一编译就报错”。你需要在 DevEco Studio 里自己完成工程导入、依赖补齐、签名配置和模拟器运行。

遇到编译错误时，直接把错误信息贴给 AI，让它按工程实际环境改。但有一个前提：你要能看懂编译错误是哪一层的。比如“找不到模块”“方法不存在”“属性名写错”，这几种错误处理方式完全不同。

如果完全没有开发经验，又想直接上手鸿蒙应用，我不建议跳过编译环境直接靠 vibe coding。它的作用只是加速代码生成，不能替代对鸿蒙工程结构的基本理解。

6.4 长期玩法的核心建议

用 vibe coding 的时间越长，我越觉得它改变的是“开始一个项目的成本”，而不是“把一个项目做完整的成本”。以前你写一个页面可能要半小时，现在可能 3 分钟就有第一版。但后续的调试、维护、功能扩展、异常处理，工作量依然存在，只是从“敲代码”变成了“审代码、测逻辑、提修改要求”。

所以长期来看，真正重要的是三件事：

1. 学会把大需求拆成小需求。这是 vibe coding 能否持续高效的关键。
2. 学会看报错信息并准确反馈给工具。报错信息越完整，修改效率越高。
3. 保持对代码逻辑的审查习惯。AI 生成代码不是你项目的最终答案，只是第一版草稿。

最后说一句我个人很认同的总结：vibe coding 真正降低的是从 0 到 1 的手感门槛，而不是从 1 到 10 的工程质量门槛。想靠它做出长期维护的正式产品，依然要补齐工程习惯、代码审查和测试验证。先把最小样例跑稳，再把需求拆小，这个顺序比任何技巧都管用。