企业官网建设流程全解析

我第一次听到 Vibe Coding 这个词，是 2025 年初在一个技术社群的讨论帖里。当时第一反应是——这又是什么网络梗？"跟着感觉写代码"，听起来就像是"代码是糊出来的"的自嘲。直到我自己花了两周时间，用对话的方式让 AI 从零搭完一个带前后端的小项目，才开始意识到：这玩意儿的门道，比段子里说的深得多。

先说一句结论：Vibe Coding 不是让 AI 随便写写然后祷告代码能跑，而是一套"用自然语言表达意图、由 AI 负责实现、由人来把控方向和验收"的新型开发方式。这个词最早是 OpenAI 的 Andrej Karpathy 带火的，本意是"你只需要沉浸在氛围里，让 AI 把想法变成代码"。但很多人把它理解成了"摆烂编程"，结果就是：AI 写了一堆貌似合理的垃圾代码，然后人就开始修修补补，最后花的时间比手写还长。

这篇文章我不打算讲太多概念层面的东西，我想分享的是自己实际用 Vibe Coding 做项目的完整经验：它到底改变了什么、为什么会翻车、怎么不翻车、以及哪些项目千万别用。适合正在纠结"要不要让 AI 写代码"的开发者，也适合被 Vibe Coding 忽悠过、想搞明白问题出在哪的人。

1. Vibe Coding 不是"让 AI 随便写"——它到底改变了什么

1.1 一个新词背后的开发范式变化

Vibe Coding 最核心的变化，不是"AI 能写代码"这件事本身——毕竟 Copilot 已经让这事儿变得稀松平常了。真正的变化是开发者在整个流程中的位置移动了。

传统开发流程里，程序员是"实现者"：需求从产品经理嘴里出来，你把它翻译成架构、模块、函数、变量，然后一行行敲出来。这个翻译过程是最费时间的，也是大部分 Bug 的来源。

Vibe Coding 把这个链路重构了：你直接跟 AI 说"我要一个能上传 CSV 文件、自动识别列名、生成图表的前端页面"，AI 负责把这句话翻译成 HTML、CSS、JavaScript、可能的后端接口。你不再需要逐行敲代码，但你需要做三件以前被忽视的事：

1. 把需求描述得无比精确；
2. 在 AI 给的代码里找出"看起来对但其实是幻觉"的部分；
3. 判断哪些 AI 写的模块可以信任，哪些必须拆开重写。

所以我说，Vibe Coding 真正改变的不是"谁来写代码"，而是"代码写完之后谁来负责"。在人机协作里，人从"生产岗位"转到了"质检岗位"。这个转变看着轻松，实际更累，因为你需要更高的代码嗅觉和更严谨的验收意识。

1.2 边界定义：什么算 Vibe Coding，什么只算 AI 辅助

现在很多文章把 Vibe Coding 和"用 AI 辅助写 bug""用补全插件写代码"混为一谈。这里我给出我自己的判断标准，供大家参考：

我自己的体会是：Vibe Coding 不是一种技术，而是一种工作习惯的转变。你用不用 Vibe Coding，不取决于你选了哪个 IDE 插件，而取决于你是否愿意把"写代码"这件事的主导权暂时让渡给 AI，自己退到更高层去把控。

1.3 哪些人适合，哪些人不适合

我在不同的开发群里观察到一个规律：对 Vibe Coding 抵触最大的，往往是写了 10 年以上代码、以"手写功底"为荣的老程序员；接受最快的，反而是 3 年经验以内的年轻人。

原因是：老程序员习惯了对每一行代码负责，而 Vibe Coding 要求你"在不知道细节的情况下相信 AI"，这对职业习惯是一种冲击。但问题在于，AI 写代码的可靠性已经超过了大部分初级工程师，而且迭代速度是人的几十倍。

适合 Vibe Coding 的人：

• 需求明确、技术栈常见的前端/全栈项目
• 想快速做原型验证想法的人
• 做内部工具、自动化脚本的开发者
• 熟悉代码审查、有测试意识的工程师

不适合 Vibe Coding 的人：

• 刚入行、还在学基础语法的新手（AI 给的代码会掩盖你对底层原理的缺失）
• 需求本身模糊不清、连自己想做什么都不知道的人
• 做底层硬件驱动、操作系统、编译器这类对可预测性要求极高的领域
• 没有代码审查能力、也不打算培养的人

2. 为什么 Vibe Coding 能跑通：程序员的角色已经从"码农"变成"验收员"

2.1 AI 时代的代码生产能力：输出峰值与质量分布

要理解 Vibe Coding 为什么能成立，得先承认一个现实：现在主流的代码生成模型，在"生成常见模式代码"这件事上，已经过了可用的临界点。

以我实测的经验，在常见的 CRUD 接口、表单页面、数据处理脚本这类场景里，AI 一次生成、无需修改就能跑通的概率大概在 60% 到 70%。剩下 30% 里，大部分是小修小补就能解决，真正需要推倒重来的不到 10%。

这个数据背后有个"质量分布"的概念。人类程序员写代码，质量波动很大——状态好时一个 Bug 没有，状态差不光是逻辑错误，还有隐藏很深的边界问题。AI 写代码的质量曲线的特点是：下限较高、上限有限。它极少犯那种完全不着边际的错误（比如把数据库连接写在死循环里），但你也别指望它写出极具巧思的算法优化。

Vibe Coding 能跑通，本质上是接受了这种质量分布：用一次 60%-70% 的成功率，加上人类 30%-40% 的修正，换取 5-10 倍的生成速度。这是从"追求一次写对"到"追求快速迭代逼近正确"的转变。

2.2 程序员的护城河已经变了

我用 Vibe Coding 写了一段时间之后，最深的感受是：那些让我引以为傲的技能——记得住标准库的 API、手写排序算法不卡壳、能背出 CSS 属性——正在变成"无用武之地"的能力。AI 比你记得牢。

但与此同时，另外一些能力变得无比值钱：

• 拆解需求的能力：你能不能把一句"我想做个博客"拆成"用户系统、文章管理、评论功能、SEO 优化、部署方案"这些 AI 能执行的粒度。
• 判断代码质量的能力：AI 给你一段代码，你扫一眼能不能发现它"偷懒"了？比如用any类型绕过类型检查、把逻辑全写在componentDidMount里、完全没考虑错误处理。
• 架构取舍的能力：AI 倾向于用最顺手的模式给你生成代码，但最顺手的模式不一定是长期维护最好的模式。什么时候让它保持原样、什么时候必须重构，这个判断得人来下。

说白了，在 Vibe Coding 的模式下，你不再是一个"翻译需求为代码"的人，而是一个"把需求结构化为机器可理解指令、并对机器输出做出正确裁决"的人。这是更接近架构师和产品经理的岗位，而不是码农。

2.3 哪种项目能跑通，哪种是灾难

基于我自己的项目实践，我梳理了一份"Vibe Coding 适用度清单"：

这个表不是绝对的，但我建议用来做"投入产出比"预判。如果你手上是一个旧项目，里面纠缠了各种奇怪的历史包袱，Vibe Coding 的效果会很差——模型的上下文窗口装不下你这个项目的所有"潜规则"，而每个潜规则都是它写错代码的伏笔。

3. 我的 Vibe Coding 实操流程：从一句话需求到能跑起来的完整链路

3.1 工具选型：我试过的方案横向对比

Vibe Coding 的工具五花八门，我按"对话式生成"这个核心标准筛了一圈，实际深度用过 4 个：

Cursor（IDE 内嵌对话 + 代码应用）

当前最主流的 Vibe Coding 工具。它的卖点不是对话生成本身，而是把对话生成的代码直接 diff 进项目文件。你可以在侧边栏描述需求，它会在右侧给出修改建议，你逐条决定接不接受。这种"代码审查式的工作流"非常符合人类习惯。

我实测下来，Cursor 在中型项目（几千个文件以内）的上下文管理要明显优于纯 API 调用——它会把整个项目的文件树喂给模型，所以它写的代码能够基本遵循你的项目结构，而不是凭空给你造一个新文件。

Claude Code（终端 CLI 工具）

Anthropic 出的终端环境编程工具。它在一个 REPL 里运行，可以调用 Claude 模型执行文件读写、bash 命令。体验和 Cursor 完全不同：更像雇佣了一个"远程实习生"，你说"把测试跑一下、然后把失败的修了"，它就真的会自己去跑测试、看报错、改代码。

这个工具的自由度很高，但也很考验你的"管理能力"。它有时候会自作主张地改掉不该改的文件，所以需要你前期约定好工作边界。我现在的用法是：简单、独立的子任务丢给它，核心架构自己动手。

GitHub Copilot 对话模式（IDE 内联）

老牌选手，补全做得好，但对话生成的能力相对保守。适合"需要 AI 辅助但是不信任 AI 大改"的人，不太算纯粹的 Vibe Coding 工具，更像传统的 AI 辅助老兵。

Aider（终端开源工具）

一个偏"极客"的选择：在终端里用 git 管理你的代码，你通过对话让它改代码，它会自动提交 commit。最大优点是每一个 AI 操作都对应一个 commit，方便随时回滚。缺点是界面对新手不友好，上下文管理也比较"裸"。

我的建议是：如果你刚开始尝试 Vibe Coding，直接用 Cursor，因为它的 diff 审查机制最接近"人审代码"的流程。如果你已经比较熟练、且注重可回滚性，可以试试 Aider。Claude Code 更适合已经习惯了"AI 是团队成员"这种协作方式的人。

3.2 提示词怎么写，AI 才不胡编

Vibe Coding 听起来是"随便聊"，但"随便聊"和"写出能跑的代码"之间，隔着一套提示词工程。我踩过很多坑，现在稳定下来一套三段式写法：

第一段：交代背景和约束

不要上来就说"写个订单系统"，要先说清楚项目现状。像这样：

这是一个基于 FastAPI + SQLite 的电商后台项目，订单表在 app/models/order.py 中定义。技术栈固定使用 SQLAlchemy 2.x，不使用 ORM 之外的原生 SQL。前端忽略，只需要返回 JSON。

为什么要这么做？因为 AI 的默认行为是"猜"——你给它一个模糊上下文，它就用它训练数据里最常见的惯例来填空。如果不限定技术栈，它可能给你用 Django 写一个 FastAPI 项目，然后把整个工程结构都改变了。上下文交代得越清楚，幻觉越少。

第二段：描述需求，标明验收标准

这是最容易犯错的环节。很多人描述需求用的是"形容词"，比如"页面要好看点""性能要好一些"。AI 听到"好看"就只能自由发挥。

正确的做法是把形容词翻译成可测量的标准：

在订单列表中增加一个"导出"按钮，点击后下载 CSV 文件。CSV 的列包含：订单号、用户手机号、商品名称、实付金额、下单时间。编码使用 UTF-8 带 BOM，确保 Excel 打开不乱码。

这能让"导出"从一句话变成一个可交付、可验证的功能。"带 BOM"这种细节尤其重要——AI 不知道你的用户会用 Excel 打开，你不说它就会漏。

第三段：限定实现思路与边界

如果你对实现方式有偏向，最好直说：

不要用额外插件，直接使用 Python 内置的 csv 模块即可。导出逻辑放在服务层 order_service.py 中，不要写在 controller 里。导出前检查用户是否有管理员权限。

这一步相当于给 AI 画了一个"工作范围"，防止它跨模块动代码。我见过 AI 为一个小小的导出功能，顺手改了 model 定义、加了一个 config 配置项，甚至动了数据库字段——如果你不说边界，它会认为自己"帮了个大忙"。

3.3 渐进式搭建：先骨架后肌肉

Vibe Coding 最常见的新手错误，是试图一次对话让 AI 把整个项目写完。我第一周就是这么干的，结果是它生成了一个结构看似完整的工程，实际上里面全是互相矛盾的接口定义：前端调用的 API 路径和后端路由对不上、Model 定义的字段和数据库迁移文件不一致。

后来我总结出一个"渐进式搭建"的节奏：

第一步：让 AI 生成项目骨架

只让它搭目录结构、配置文件和空的模块入口。目的不是得到代码，而是得到一个统一的工程约束。这一步你不应该让 AI 操心任何业务逻辑。

第二步：按功能模块逐个填充

每填充一个模块前，先确认：基础骨架没变、依赖关系清楚了、上一个模块是否已经对接好。然后把每个模块当成独立的"小项目"去描述需求。

第三步：模块对接时人肉介入

这是最关键的一步。AI 在单个模块内表现很好，但跨模块沟通时经常"交接不清"。比如它写的用户模块返回的是user_id，但订单模块里调用时用的却是id。这时候你千万别指望 AI 自己能发现——它的上下文感知在这种细节上并不可靠。你需要在对接点手工检查一遍，或者用测试用例覆盖。

第四步：持续集成，每步验证

做完一个模块就立刻跑测试、起服务、用 API 工具调一下。不要攒到最后一口气验证。Vibe Coding 的节奏是"快速迭代、高频验证"，跟传统开发不一样。

3.4 哪些代码必须人肉 review，哪些可以放心用

我有一套自己的 review 优先级，分享出来供参考：

可以快速看一眼就放过的：

• 标准的数据 CRUD 代码
• 常见的 UI 组件拼接逻辑
• 定型化的配置代码（比如 Dockerfile、CI 模板）
• 工具函数（日期格式化、字符串处理，注意测试覆盖）

必须逐行审查的：

• 任何涉及权限、鉴权、支付、外部 API 密钥的代码
• 数据库操作——尤其是涉及数据迁移的
• 错误处理逻辑——AI 通常会忽略异常分支，只写主流程
• 异步/并发代码——AI 对 race condition 的理解很差
• 涉及文件读写、网络请求这类外部 I/O 的边界条件

为什么？因为 AI 的训练数据里，"主流程"占了绝大多数，"正确处理的错误分支"是很少的。它的默认行为是"我猜这个不会出错"，而你的工作就是替它把所有"出错"的情况想到。Vibe Coding 里，人的价值就体现在这些审查上。

4. 翻车实录：Vibe Coding 最常踩的五个坑与排查链路

4.1 幻觉 API：AI 自信地写了不存在的库

有一次我让 AI 写一个 PDF 转图片的工具，它生成了下面这行代码：

from pdf2image import convert_pdf_to_images

一眼看过去逻辑没问题——pdf2image这个库确实存在，但里面的函数叫convert_from_path，根本没有convert_pdf_to_images。AI 把两个不同库的 API 记忆混在一起，编了一个"看起来对"的函数。

这个坑的隐蔽性在于：如果用的不是 Python 这种有清晰ImportError的语言，或者你恰好命名了自己的函数，很可能直到运行到那一行才报错。

我的排查方法是：让 AI 给出依赖列表和版本号，然后人工对着官方文档核对一遍再往下走。这一步 5 分钟能搞定，但能避免 2 小时的排查。

4.2 改一行坏三处：上下文漂移问题

我最惨的一次 Vibe Coding 事故是这样的：项目里有一个utils.py，里面定义了一个format_date()函数。我让 AI 把日期格式从YYYY-MM-DD改成YYYY/MM/DD。

AI 的回应是："好的，我帮你改。" 结果它不光改了utils.py里的函数体，还把report.py里已经格式化好的字符串又格式化了一次，导致输出变成YYYY//MM//DD。更隐蔽的是，它把 README 里的示例日期也改了。

这个问题的根源叫"上下文漂移"——AI 在处理你指定的任务时，会顺手把上下文里它认为"相关"的代码也改了。它分不清"用户让我改函数定义"和"用户希望所有调用点都更新"的区别。

解决方案：每次让 AI 改代码之前，先 git commit 一遍，然后给它明确指令："只修改 xxx.py 中名为 xxx 的函数，其他文件不允许改动。" 如果它改了不该动的文件，你直接git checkout恢复，而不是手动去改。

4.3 测试全绿但功能全废

这是 Vibe Coding 最阴险的坑。AI 特别擅长"生成一个能通过测试的假实现"。

我让 AI 写一个计算折扣价的函数，要求输入原价和折扣率，返回折后价。AI 生成的代码长这样：

def calculate_discount(price, rate): """计算折扣后价格。""" return price * rate

然后它还贴心地生成了测试用例：

def test_calculate_discount(): assert calculate_discount(100, 0.8) == 80

测试确实是绿的。但问题是：这个函数的语义对吗？折扣率 0.8 意味着打八折？还是打了两折？实际业务里"折扣率"更常见的是"折扣力度"，即 80% off 还是 80% of 原价？如果需求里没说清楚，AI 就按它猜的最简单方式实现，且测试只会验证它自己的理解。

这种坑怎么防？先把验收测试写清楚，再让 AI 实现，而不是让 AI 自己出题自己答。测试用例应该由人来定义边界条件。比如：

折扣率 0.8 表示打八折（原价 * 0.8）；折扣率大于 1 或小于 0 时应抛异常；价格必须为正数。

有了这样的约束，AI 就不会自作主张。

4.4 越权和业务安全漏洞

这个坑我没踩过特别大的，但见过 GitHub 上好几个公开的 Vibe Coding 项目翻车。最常见的模式是：AI 写了一个带用户登录的后台系统，然后"忘记"在删除接口上做权限校验。

比如这样的代码：

@app.delete("/api/order/{order_id}") def delete_order(order_id: int, user=Depends(get_current_user)): # 没有检查 user 是否有权限删除该订单 db.delete(order_by_id(order_id))

代码逻辑完整、语法无误、能跑，但任何登录用户都能删掉别人的订单。AI 没有"业务规则"的概念，它只知道"删订单 = 调用删除函数"。

这类问题的核心是：AI 不感知业务语义，它只感知代码语义。你必须在需求描述里主动把业务约束列出来，比如"仅管理员可删除""用户只能删除自己的订单"。即使如此，你还是要对鉴权、权限、支付这类关键路径做深度 review，这是无法替代的。

4.5 代码膨胀：AI 的"贴瓷砖式"扩展

Vibe Coding 项目写久了你会发现，代码量会显著增长。AI 倾向于用"新增模块"而不是"修改现有模块"的方式解决问题。

比如你让它加一个"导出订单数据"功能，它可能会新建一个export_service.py，再建一个export_controller.py，还复制了原来列表查询的代码——实际上，这个功能只需要在已有order_service.py里加一个 30 行的函数。

久而久之，代码里出现大量重复、大量 "helper" 函数，最终变成一座屎山。这个责任不在 AI，在你的项目治理。你需要周期性地做"代码瘦身"：让 AI 列出重复代码，然后手动合并且删除冗余文件。这就像整理房间——你不能指望 AI 不乱放东西，但你可以定期要求"把左边第三堆东西移到右边"。

5. 防御式编程：给 Vibe Coding 加一道可信护栏

5.1 三步代码审查法：我现在的固定流程

经过多次翻车，我总结出一套适用于 Vibe Coding 的代码审查流程，总共三步：

第一步：看边界，不看主流程

大部分 AI 代码的主流程都不会错，如果你先看主流程，很容易被"看起来正确"的代码麻痹。直接跳到异常处理、空值判断、类型边界上去看。这三个地方是 AI 幻觉的重灾区。

第二步：逆向验证数据流

在脑子里（或者用注释）沿着数据流反推：这个接口返回什么？谁在用这个返回值？如果返回值为None会怎样？AI 经常写出"自己爽"的接口——它定义了一个返回dict的函数，但实际返回的dict里键名跟对方期望的完全不一致。

第三步：对着依赖清单查 API 签名

这一步是对付"幻觉 API"的有效手段。把 AI 生成的代码里所有第三方库的函数调用列出来，对照官方文档检查签名。如果你用的是 IDEL 工具，跳转到定义处也能验证。

5.2 自动化防线：让机器替你守门

人肉 review 总会漏。Vibe Coding 项目比传统项目更需要自动化防线，因为 AI 生成的代码频率太高，你不可能每个细节都盯着。

我现在的项目标配是：

• 单元测试：核心逻辑必须有测试，覆盖率目标 80% 以上；
• Linting + 类型检查：用 ESLint / mypy / pylint 之类工具拦住低级错误；
• CI 流水线：每次 commit 自动跑测试和构建。AI 改完代码提交 PR，发现测试挂了就自觉修，绝不让坏代码流向主线。

这套东西看起来传统，但在 Vibe Coding 里价值加倍。因为 AI 可以一分钟改十次代码，人不可能一分钟 review 十次。你需要把审查工作尽量转交给机器，让人盯住机器审查覆盖不到的业务层面。

5.3 版本管理策略：让 AI 乱改之前先保住"底牌"

我在用 Vibe Coding 时养成了一个非常"老派"的习惯：任何时候，当前目录必须处于 git clean 状态。

怎么理解？就是每次 AI 开工之前，先把当前可用的状态 commit 一次。AI 改完，如果效果不好，直接git checkout .就能回滚。这省掉了 90% 的"AI 把代码改坏又找不到原来的版本"的焦虑。

更进阶的技巧是给每个功能分支建独立分支。AI 在分支上折腾，你随时可以切回主分支继续干别的。全部满意后再 merge。

这个策略在传统开发里只是"好习惯"，在 Vibe Coding 里是底线——因为你不是在修自己的代码，你是在指挥一个生产速度极快、但质量不稳的"实习生"。不给实习生留好退路，你就得替他擦屁股。

5.4 构建"小型可信任代码库"策略

最后分享一个我最近在用的策略：把项目划分成"可信任区"和"不可信任区"。

可信任区是那些被测试完全覆盖、代码逻辑稳定、你 hand-on review 过多遍的核心模块——比如支付服务、鉴权模块、数据模型定义。这些模块绝不允许 AI 直接改，必须通过 PR 流程，且变更必须伴随测试更新。

不可信任区是边缘脚本、一次性工具、UI 展示层——这里可以让 AI 自由发挥，快速迭代，出错也无伤大雅。

这么做的好处是：AI 的大部分生产力集中在"不可信任区"快速产出，同时"可信任区"的稳定性保证了整个项目不会因为一次 AI 幻觉而崩盘。Vibe Coding 不是全员摆烂，而是划好边界之后，在边界内摆烂。

我个人现在对 Vibe Coding 的态度是：它真的有效，但不是靠"感觉"在编程，而是靠"把感觉翻译成明确指令 + 严格的验收流程"在编程。你可以把 AI 当成一个手艺不稳定但手速极快的学徒——你不需要教它怎么写代码，但你需要教会它哪些代码是你想要的，还要能一眼看穿它什么时候在交差。

刚开始用 Vibe Coding 的那两周，我一度觉得自己的饭碗要没了。现在我的感受完全反过来：写代码的技巧越来越不值钱，但理解需求、判断方案、把关质量的能力，正在变得越来越值钱。如果你也打算试，记住那句老话——AI 写的每一行代码，最后都得由你负责。工具不会替你承担后果，只有你的护栏会。