企业官网建设流程全解析

最近圈子里最热的词，一个是 vibe coding，一个是 AI 辅助编程。我重度用了差不多三个月，最大的感受是：写代码这件事，已经从"我亲手敲键盘"变成了"我和 AI 轮流敲键盘"，而且后者往往更快、更省心。如果你还没找到节奏，这篇就是我在真实项目里摸出来的那套方法、踩过的坑和最后的判断标准。适合所有想用 AI 提效的程序员，也适合那些"会描述需求但不太会写代码"的产品、运营和独立开发者。

1. 从"复制粘贴"到"vibe coding"：我心态上的三个转变

vibe coding 这个词最早流行起来的时候，很多人以为它指的是"随便哼两句就让 AI 把整个项目写完"。我实际用下来发现，它的内核其实是一种分工关系的重构：程序员从"每一行代码的执行者"变成"方向的制定者和质量的守门人"。不是不写代码了，而是写的代码从"亲手实现"变成了"描述、验收、纠偏"。

1.1 第一个转变：从手写代码到审阅代码

以前我写一个功能，脑子里先过一遍数据流，再想 API，再想边界条件，最后才动手。vibe coding 之后，我的工作顺序完全反过来了：先让 AI 出一版，我对着需求文档逐行审。刚开始我很不习惯，总觉得 AI 写的代码不是"我的代码"，后来我意识到，审阅代码本身就是一种深度理解——你反而要更清楚地知道每一段在干什么、有没有隐患，因为你得为它负责。

举个最简单的例子。我要给一个 CSV 文件做清洗，以前我会打开编辑器，回忆 pandas 的用法，写个循环，跑一下报错再调。现在我会直接告诉 AI："我有 10 万行销售数据，列有日期、金额、区域，帮我去重、把日期标准化、金额列里有'元'字要去掉并转成浮点数。"它几秒钟给我一版，我检查的反而只有三件事：逻辑对不对、有没有处理缺失值、性能能不能跑完 10 万行。

1.2 第二个转变：从背 API 到描述意图

以前写 Python 要记住strftime的格式码、groupby的用法、正则表达式的各种转义。现在这些细节我从脑子里"卸载"了，换成了更接近自然语言的描述能力。我能用一句"把字符串里所有形如 2024-01-01 的日期统一成 2024年1月1日 这种格式"来替代一长串正则。

这个转变最容易被误解的地方在于：不懂语法的人确实能写出能跑的代码，但写不出好的代码。AI 可以替你记住语法，但它不会替你做架构决策，更不会替你理解业务。如果你本身没有"这段代码会在什么场景下崩掉"的直觉，AI 给你的代码你连怎么验收都不知道。所以我的结论是：vibe coding 降低了编程的门槛，但没有降低编程的认知要求。

1.3 第三个转变：把报错当成对话的一部分

以前看到报错，我的第一反应是紧张，然后是漫长的 Stack Overflow 搜索。现在我看到报错，心态平和得多——因为报错本身就是一次新的输入。我会把报错信息原样丢回给 AI，跟一句"哪里出了问题？怎么改？"，然后看着它自我修正。

这个转变带来的副产品是，我处理问题的耐心变好了。以前一个 bug 卡三个小时我会烦躁，现在我知道只要把上下文喂够、把报错贴全，大部分问题都能在两三轮对话内解决。真正麻烦的从来不是报错本身，而是上下文缺失——AI 看不见你整个项目的状态，你也没告诉它你改了哪里，它当然只能瞎猜。

2. 一套我反复打磨的 vibe coding 工作流

光有心态不够，工具和流程才是让 vibe coding 稳定输出的关键。我前后试过很多方案，最后沉淀下来的工作流可以概括成六个字：小仓库、大上下文、分步走。

2.1 工具选型：我用过的几个 AI 编程工具横向对比

市面上能用来 vibe coding 的工具分三类：IDE 插件型、独立代理型、命令行型。我把实际用过的几款放在一起做了个对比，括号里是我个人的真实感受：

我的建议是别贪多，固定用一到两个。我现在的主力是命令行代理型工具搭配 IDE 插件：前者帮我写整块逻辑、做多文件改动，后者在我手动微调时提供补全。两者分工明确，基本不会互相打架。

2.2 项目结构：为什么"小仓库"反而更高效

很多人让 AI 写项目，喜欢从一开始就把目录搭得特别宏大——models、services、utils、config 一应俱全。结果 AI 在生成代码的时候，会把大量上下文浪费在"猜这些目录是什么关系"上。我的做法是：一个 ≤5000 行的独立脚本或一个小工具，就单独占一个仓库，不要塞进大项目里。

小仓库意味着你可以把整个仓库的代码都丢给 AI 当上下文。我一般会在项目根目录放一个README.md，里面写清楚这个工具是干什么的、输入输出是什么、运行命令是什么。这个 README 就是 AI 的第一份上下文，比它自己去翻代码高效得多。

2.3 提示词框架：我每次必写的四项结构

提示词不是越长越好，而是结构化越好。我写的绝大多数任务提示词都包含四块：

1. 角色与背景：告诉 AI 它在什么项目里、用什么技术栈。
2. 任务目标：一句话说清楚要做什么，输入是什么、输出是什么。
3. 硬性约束：明确"不许做什么"，比如不要引入额外依赖、不要改数据库结构、兼容旧版本。
4. 验收示例：给一个输入和期望输出的例子，比十句描述都管用。

举个例子，我让 AI 写一个批量重命名文件的脚本：

你是一个熟悉 Python 的自动化脚本工程师。 任务：写一个命令行脚本，把当前目录下所有形如 IMG_20240101_123456.jpg 的图片， 重命名为 2024-01-01_123456.jpg，日期格式替换成 YYYY-MM-DD。 约束：只允许用标准库 os、re、datetime，不要引入任何第三方依赖。 验收：输入 IMG_20240101_123456.jpg，输出应成为 2024-01-01_123456.jpg。

加上验收示例之后，AI 的理解准确率肉眼可见地提升。很多人抱怨 AI 写代码跑不通，八成原因是提示词里只有任务描述，没有验收标准。

2.4 上下文管理：喂给它"最新版本"，而不是"全部历史"

AI 对话窗口有上下文上限，用得多了它就会"忘记"前面的要求，开始答非所问。我踩过这个坑之后总结出来的经验是：每一轮对话，尽量把当前最新的文件内容重新贴一遍，而不是依赖它"记得"。

具体操作很简单：AI 改完一个文件，我立刻把改完的版本粘回去，跟一句"基于这个最新版本继续做下一步"。这个动作看起来笨，但能省掉后面大量的"你怎么忘了"的纠错对话。还有一个常用技巧，就是把长文件拆成小文件，比如把配置、主逻辑、工具函数分开。每个文件都被完整喂进上下文，AI 的推理质量会高很多。

3. 实战回放：两个让我彻底上头的项目

说再多方法论，都不如看两个真实项目是怎么从一句话长成一个完整工具的。下面这两个项目我都跑出了可用的成果，第一个偏工具，第二个偏带界面的小应用。

3.1 实战一：把十年散乱的 Markdown 笔记整理成知识库

我的笔记库有几千个文件，有些带 frontmatter，有些不带，有些标题写的是"未命名"，内文却全是干货。这个整理需求我拖了很久，就是因为手动做太烦，写脚本又懒得搜一堆解析库的用法。有了 vibe coding 之后，我把它当成了第一个练手项目。

第一轮对话，我只提了一个概述："写一个 Python 脚本，扫描 notes 目录下所有 .md 文件，补充 YAML frontmatter，包含 title、tags、date，date 从文件系统修改时间读取，tags 根据文件内容里的关键词自动打标。"

AI 第一版很快就出了，跑起来也确实能跑，但有两处不符合我的需求：一是它对"关键词自动打标"的实现非常粗暴，只是硬编码了几个词的映射；二是有一些已经带 frontmatter 的文件被重复处理了。我把这两个问题直接回给 AI："跳过已有 frontmatter 的文件；打标逻辑改成从文件名和正文前 300 字里提取关键词，并去重。"它改完之后，整个脚本稳定跑完，几百个文件全部规整。

这个项目的启发是：第一版永远只是半成品，但你只需要会指出"哪里不对"，就能把它推向你想要的方向。这在以前是不可想象的——以前每一步都得自己来。

3.2 实战二：给家里的水电燃气做了个小账本

第二个项目稍复杂：我想要一个本地网页小工具，能录入每月水电燃气读数，自动算环比，并生成简单的消费趋势图。放在以前，这个需求涉及前端页面、数据存储、图表渲染，我一个人得折腾好几天。

流程是这样的：我先让它定技术方案。我跟 AI 说："做一个本地运行的单页应用，不需要后端，数据存 localStorage，用 ECharts 画趋势图，尽量少的依赖。"它选用了原生 HTML + JavaScript + ECharts 的方案，文件就三个，非常轻。

然后我按模块推进：先让它把数据录入和存储部分写出来，我在浏览器里手动录入几组数据测试；再让它画趋势图；最后让它加环比计算和颜色标注（上涨红色、下跌绿色）。每一步我都是按第 2 节里的四项结构给提示词，每一步的产出都是可验收的。从头到尾，我只手写了不到二十行代码，剩下的全是评审和微调。

现在这个账本我用了两个月，真实数据跑得挺稳。它让我彻底相信了一件事：vibe coding 特别适合"为自己解决问题"的中小型项目，因为这种项目不需要多大并发、不需要多强安全，只要逻辑正确、符合使用习惯就行。

4. 翻车实录：AI 代码的崩溃现场与排查链路

vibe coding 不是不会翻车，而是翻车的方式和以前不太一样。以前翻车多半是我的逻辑漏洞，现在翻车往往集中在 AI 的"自信幻觉"上。下面三个事故我印象最深，每一个都让我心疼地浪费过时间。

4.1 事故一：AI 给我编了一个不存在的 API

有一次我让 AI 用某个第三方库处理 PDF，它给我写了一版代码，里头用的函数名长得完全合理，比如extract_pages()、rotate_page()。一运行，直接报AttributeError。我一开始以为是版本问题，来回折腾了好几个版本，最后去查官方文档才发现：那个 API 从来没有存在过，是 AI 根据函数命名习惯"脑补"出来的。

这次事故让我彻底养成了一个习惯：AI 引用第三方库时，必须让它先给我库的官方文档链接，或者我主动把文档片段贴给它。别指望 AI 对每个库的每个版本都了如指掌，它的训练数据有截止时间，而且它经常会"用逻辑补全事实"。

4.2 事故二：上下文一长，前面的约束全忘了

第二个事故发生在一个稍大的项目里。项目跑到第十几轮对话，我明显感觉 AI 的行为开始漂移：我前面说过"不要改数据库字段名"，它改着改着就给我加了新字段；我说"所有输入都要校验空值"，它后来生成的代码里完全没有校验。最典型的一次，是它忘了我最初定的"零第三方依赖"约束，在某个小工具里悄悄引了一个厚重框架。

我用了一个相对笨但有效的排查办法：重新整理一份当前项目的全貌文档，把之前散落在对话里的所有关键决策汇总成清单，然后把它作为新一轮对话的"开场导入"。这相当于给 AI 做了次"记忆清理"，之后它的行为立刻回到正轨。自那以后，我的每个项目都有了一个DECISIONS.md文件，专门记录所有已经拍板的约束和原因。

4.3 事故三：改 UI 改出了"僵尸循环"

还有一个事故特别有意思。我让 AI 调整一个网页的按钮样式，它为了确保所有状态都覆盖，在 JavaScript 里加了一个持续监听 DOM 变化的循环。结果页面加载后，无限触发重绘，浏览器直接卡死。这个 bug 特别难发现，因为报错没有明确指向，页面就是肉眼可见地"变慢"。

排查链路是这样的：先开开发者工具看性能面板，发现主线程占用率接近 100%；再看调用栈，发现反复执行同一个函数；接着看代码，发现MutationObserver回调里无限修改自身触发的属性。整个定位过程大概花了半小时，最后我让 AI 删掉那个观察器，换成一个只在按钮点击时执行一次的简单函数。

这次事故教会我一件事：AI 生成的前端交互代码，你得特别警惕"自动触发"和"监听"类的逻辑，它们一旦形成循环，表现往往不是报错，而是极难察觉的性能问题。

5. 让它别乱写：约束 AI 的三板斧

翻车多了，我总结出一套"约束 AI"的方法，核心就一句话：别让它自由发挥，给它一套可验收的笼子。这套方法我称之为三板斧：规格先行、增量交付、测试兜底。

5.1 规格先行：先写 README，再让 AI 写代码

传统的开发是先有代码后有文档，vibe coding 恰恰相反。我现在的习惯是：在动手写代码之前，先把这个项目的 README 写好。README 里包含三部分：这个工具解决什么问题、输入输出格式、运行和验收方式。

写完之后，我把 README 和"照着实现"四个字一起丢给 AI。它能基于这份规格生成相当靠谱的第一版。原理很简单：README 就是一份无歧义的需求说明书，AI 的推理空间被收窄，幻觉自然少很多。如果你连 README 都懒得写，那你至少要有"我到底要什么"的自信，不然 AI 会替你定义需求，后果通常不太妙。

5.2 增量交付：每轮只做一件可验证的小事

我最开始让 AI 干活，喜欢一口气说"帮我做一个博客系统，要文章管理、标签、搜索、评论"，结果它生成了一大堆文件，每个文件都不完整，Chat 一多上下文就爆炸。后来我改成一次只推进一个模块，比如"先做文章列表页，数据从硬编码数组读取，暂不接接口"，跑通了再接下一步。

这样做有三个看得见的好处：一是每一轮对话都能验证，有了错误立刻定位；二是上下文始终保持精简，AI 不容易"精分";三是我的工作量从"审查一大堆"变成"审查一小块"，质量明显提升。增量交付的本质，是把大项目拆成一系列小型的 vibe coding 任务，每轮对话都是一次独立的"需求-产出-验收"闭环。

5.3 测试兜底：让 AI 自己写测试并跑给你看

很多人觉得测试是完事之后才补的东西，但 vibe coding 里测试反而是约束 AI 的最佳工具。我的做法是：让 AI 写实现的同时，立刻写一个最小测试脚本，把关键路径跑一遍。测试脚本不需要多专业，能覆盖核心逻辑就行。

举一个例子，我让它写一个函数，把日期字符串从"YYYY/MM/DD"转成"YYYY-MM-DD"。它就同时给我生成了一组用例，包括正常输入、空值、格式不合法三种情况，然后跑给我看。这个"跑给你看"的动作特别关键——它逼着 AI 自己检查一遍逻辑，而不是交一版"看着对但其实没跑过"的代码。

注意：别完全信任 AI 自测的结果。它写的测试往往只覆盖它自己认为对的路径，你仍要把业务里最担心的边界场景单独提出来，让它补测。有一次我让它处理一个文件名为空的极端情况，它一开始完全没考虑，我补了之后它才加了判断。

6. 什么项目适合 vibe coding，什么项目千万别碰

说句实在话，vibe coding 不是万能药，它的边界比很多人想象中更清晰。用对了它是放大器，用错了它就是个会生成花哨 bug 的加速器。我给自己定了一张"该不该用"的判断表，供你参考。

我自己的经验法则可以浓缩成一句大白话："错了也能改、丢了也不怕"的东西，尽管 vibe coding；"错了要出大事、要长期养"的东西，回到传统开发模式。那些介于两者之间的，就用混合模式——关键模块手写、外围胶水代码交给 AI，然后再把 AI 生成的代码整体重写一遍重要的部分。

最后再分享一个我最近悟到的小技巧：vibe coding 的真正分水岭，不是"会不会让 AI 写代码"，而是"有没有能力告诉 AI 什么不能写"。越早学会给 AI 画边界，你的项目就越少翻车。我现在每启动一个新项目，第一句对话永远是让 AI 复述我的约束条件，确认它懂了再开工——这一步省下的时间，远超你想象。