企业官网建设流程全解析

"Vibe Coding"这个词我第一次刷到的时候，心里第一反应是"这不就是甩手掌柜式写代码吗"。后来真的拿它做了一个内部小工具，从零到能跑起来大概两周，我改口了——它压根不是偷懒，而是把开发者的注意力从一个地方整体搬到了另一个地方。简单说，Vibe Coding是一种以自然语言为主要输入方式、由大模型负责产出代码、开发者以"验收结果"而非"逐行审阅"为主的开发模式。它的关键词是"氛围"和"感觉"：你说清楚想要什么、大概长什么样、边界在哪，剩下的交给模型去填。它解决的核心问题不是"写得更快"，而是"把想法变成可运行东西的门槛被压得极低"。适合谁？适合已经有一个明确小目标、能自己跑起来验证结果、并且愿意为最终质量兜底的人；不适合完全没有工程常识、指望一句话变出生产级系统的人。这篇就把我这两周的真实操作、踩的坑、以及那套被反复提到的"全局 md 文档"到底怎么写，一次讲透。

1. 先把话说清楚：Vibe Coding 到底是什么，又不是什么

1.1 一句话定义与三个可观察的特征

如果非要压成一句话：Vibe Coding 是一种"描述意图—生成实现—观察结果—继续描述"的闭环，开发者主要工作在闭环的两端（描述和验收），而不是中间那段敲键盘的过程。它有三个特别明显的可观察特征，你可以拿它对照自己是不是在这么干。

第一个特征是不看 diff 也能推进。传统开发里，你 review 每一行改动是默认动作；Vibe Coding 里，你更多是跑一遍、看报错、看输出、看界面，用结果说话。第二个特征是提示词会不断迭代，你可能会为同一个功能改五六遍描述，直到模型给出的东西接近你要的形态。第三个特征是回滚是常态，你不太在乎某一次尝试失败，因为重来的成本很低。

这三个特征合在一起，就带来一个很关键的推论：Vibe Coding 的成本结构被重新分配了。写代码的时间大幅下降，但"定义清楚自己要什么"和"验证结果对不对"的时间大幅上升。很多人第一次尝试觉得不好用，就是因为只看到了前半句，没准备好承担后半句。

我自己的体感是，一个中等复杂度的小功能，过去我可能花两小时写、二十分钟测；现在我可能花四十分钟反复描述和调整、一小时验证和修边角。总时间差不多，但过程的心理负担小很多——因为不需要一直保持那种"每一行都得想清楚"的高度专注状态。

1.2 它和"用 AI 补全代码"根本不是一回事

这一点特别容易被混为一谈。代码补全（包括各种编辑器里的行级、块级建议）本质是加速你原有的工作流：你还在主导结构，模型帮你省键盘。而 Vibe Coding 是替换了主导权：结构由模型提，你负责判断和纠偏。

差别体现在几个具体的地方。补全模式下，你会下意识保持代码风格一致，因为它只是接你的下文；Vibe Coding 模式下，模型会按它自己的偏好组织代码，如果你不提前约束，一个文件里可能同时出现三种命名风格。补全模式下，你对每一处改动有天然的"这是我写的"的责任感；Vibe Coding 下，代码是"它写的"，责任感的建立需要额外机制，比如测试、比如强制自己过一遍关键路径。

还有一个隐蔽的差别在错误处理方式上。补全时，如果模型给的建议不对，你按一下 Esc 就完事了，成本接近零；Vibe Coding 时，如果它生成的方向错了，你可能要花十几分钟才意识到方向错在哪。所以 Vibe Coding 特别吃"前期把话说清楚"这个能力，这一点的权重被放大了好几倍。

我见过不少人抱怨"AI 写的代码一塌糊涂"，追根究底，问题往往不在模型，而在于他们把 Vibe Coding 当成了代码补全来用——只给一句模糊的需求，然后期待一个完整可用的结果。这个期待本身就是错配的。

1.3 三个最容易掉进去的认知误区

误区一：以为不用懂代码了。恰恰相反，Vibe Coding 对"能不能一眼看出这份代码有病"的要求更高。你不需要逐行写，但你需要能在几秒钟内判断：这个函数是不是在做三件事、这个循环是不是可能死、这个接口是不是没做校验。看不懂就验收不了，验收不了就只能在坑里越陷越深。

误区二：以为生成的代码可以直接上生产。我做的第一个功能就是踩了这个坑。当时生成的东西跑起来完全正常，我就直接合了。结果三天后一个边界输入把它打穿了。事后复盘，问题特别典型：模型写的是"快乐路径"，异常分支要么没有，要么只写了throw new Error("unexpected")这种等于没写的兜底。

误区三：以为上下文越多越好。这也是我一开始的想法，把所有相关文件一股脑丢进去。结果是模型被大量无关信息干扰，反而抓不住重点。后来我才想明白，上下文的关键不是"多"，而是"准"和"分层"——这也是下一节要重点讲的全局文档存在的意义。

2. 我为什么在真实项目里开始用这套玩法

2.1 从"逐行审查"切换到"审意图"的心理转变

说实话，最开始那几天我是抗拒的。作为一个写了十年代码的人，看着屏幕上哗啦啦冒出一大段自己没写过的逻辑，那种失控感非常真实。我试过逐行读，读了两百行就放弃了——不是因为读不懂，而是因为读得越细，越想去改，一改就变成了传统开发，Vibe Coding 的效率优势荡然无存。

真正的转折点是我给自己定了一条规矩：只审三件事——输入输出的契约、错误处理的完整性、以及是否有明显的资源泄漏或死循环风险。剩下的实现细节，交给测试去兜。

这条规矩一立，节奏立刻顺了。我不再纠结"为什么它用了 map 而不是 for"，因为这不影响正确性；我把注意力全放在"这个函数收到空数组会怎样""这个请求超时了会怎样""这个循环的终止条件是什么"。这三个问题问下来，八成的问题都能提前拦住。

有一点要提醒：这个转变不是让你放弃把关，而是让你把把关的精度放在最值钱的地方。代码风格可以后面统一格式化，命名可以全局替换，但逻辑漏洞和边界缺失，是后面极难补救的。

2.2 哪些项目类型天然适合放手让它写

经过这段时间的实践，我总结出一张"适配度"清单，判断标准主要看两点：错了会怎样，以及验证成本高不高。

我自己现在的习惯是：原型、脚本、内部工具，直接放手；核心链路，让它先写一版，然后我自己重写关键部分。

2.3 有几个场景我是明确禁止开启这个模式的

第一个是涉及权限判断的地方。模型的"直觉"在权限逻辑上特别容易出问题，比如把校验写在了数据返回之后，或者漏掉某个角色的边界。这类代码我坚持自己写，或者至少自己逐行过一遍。

第二个是数据库迁移与数据删除。任何会改写存量数据、删除记录的操作，我不接受"看起来对"这个标准。这类操作必须有明确的回滚预案，而且我会把生成的语句人工审一遍再执行。

第三个是加密与凭据处理。这不是不信任模型，而是这类代码的正确性很难通过"跑一遍"来验证，需要专门的测试向量和静态分析，普通验证手段根本覆盖不到。

第四个是性能敏感的循环。模型生成的实现往往可读性优先，可能藏着一个嵌套遍历或者每次都重新建连接的写法。这类代码我会单独用 profiling 工具过一遍，而不是靠肉眼。

3. 全局 md 文档：让 AI 不再每次从零猜你的项目

3.1 为什么单次对话的上下文撑不住一个真实项目

这是很多人卡住的地方。你开一个新会话，模型对项目一无所知，你花五分钟把项目背景、技术栈、目录结构讲一遍，然后开始干活。中途聊到第十轮，早期说的那些约定已经被挤出上下文窗口了，模型开始按照自己的默认习惯写代码——于是你发现它突然换了命名风格、突然用了另一个 HTTP 客户端、突然把配置文件放到了别的地方。

全局 md 文档解决的正是这个问题。它的本质是把那些每次都要重复交代的稳定信息，落成一个物理文件，让工具每次自动读取。这样你省下了开场白，模型也有了持久的约束，双方都在同一个前提下工作。

我记得第一次意识到这件事重要，是在一个周五晚上。当时我在调一个接口，模型给出的代码用了axios，但我项目里一直是fetch封装。我改完之后顺手问了句"你为什么会用 axios"，它说"因为你没有告诉我用什么"。那一刻我明白了，它不是不会，是不知道。

3.2 一份能用的全局 md 文档最小结构

下面这份是我现在在用的模板，去掉注释大概七八十行。核心思路是：只写模型猜不到的东西。什么叫猜不到？比如"用 TypeScript"它能猜到，但"错误统一用 Result 类型而不是抛异常"它就猜不到。

# 项目全局约定 ## 1. 项目一句话 一个面向内部同事的设备借用登记小工具，单页应用 + 轻量服务端。 ## 2. 技术栈（不要替换） - 运行时：Node.js 20 LTS - 语言：TypeScript，strict 模式必须开启 - 前端：原生 DOM + 少量模板字符串，不引入框架 - 服务端：Fastify - 数据层：SQLite，通过 better-sqlite3 同步访问 - 包管理：pnpm ## 3. 目录职责 - src/api/ 仅放路由定义与参数解析，不写业务 - src/domain/ 业务规则，纯函数优先，不依赖框架 - src/infra/ 数据库、日志、外部调用 - src/web/ 前端页面与交互 - scripts/ 一次性脚本 ## 4. 编码约定 - 变量与函数用 camelCase，类型与接口用 PascalCase，文件名用 kebab-case - 不抛异常，统一返回 { ok: true, data } 或 { ok: false, code, message } - 所有对外输入必须在 api 层完成校验，domain 层默认输入可信 - 日志只用一个 logger，禁止 console.log - 时间统一用 UTC 毫秒时间戳，展示层再转本地时区 ## 5. 明确禁止 - 未经说明不得新增第三方依赖 - 不得修改 src/infra/db.ts 的导出签名 - 不得留下 TODO 占位实现或空函数 - 不得在 domain 层直接访问数据库 ## 6. 常用命令 - 安装：pnpm install - 开发：pnpm dev - 类型检查：pnpm typecheck - 测试：pnpm test - 构建：pnpm build ## 7. 交付标准 每次改动结束前，必须保证 pnpm typecheck 与 pnpm test 全绿。

这份文档有几个设计上的小心思。第一，"不要替换"和"明确禁止"这两节是整份文档里最有价值的，因为它们直接堵住了模型最容易自作主张的地方。第二，目录职责那一节直接降低了耦合，模型知道该把代码放哪，不会把所有逻辑堆在一个文件里。第三，"交付标准"那一节把验收条件写成了命令，这样模型自己就能跑一遍再交给你。

3.3 分层文档：全局、目录级、任务级三层配合

一份全局文档管不了所有细节。真到具体模块，你还需要更细的约束。我的做法是三层：

第一层，根目录的全局文档。放技术栈、目录职责、编码约定、禁止项、命令。这部分变动很少，大概一两周才改一次。

第二层，目录级文档。在src/domain/下再放一个 md，写这个目录特有的规则，比如"这里的函数必须是纯函数，不允许读写外部状态""所有金额以分为单位存储"。这类规则放在全局文档里会显得很杂，放在目录里就恰到好处。

第三层，任务级提示。这是每次对话临时给的，只针对当前这一件事，比如"这次只改 api 层，不要动 domain"。

这个分层的好处是，上下文的注入量和你实际需要的精度是匹配的。做一个小改动，不需要把所有目录的规则都塞进去；做跨模块重构，再把相关的几份都带上。我踩过的坑是，一开始把所有规则都堆在全局文档里，结果它膨胀到四百多行，模型反而抓不住重点，还浪费了宝贵的上下文空间。

3.4 文档写完之后，怎么验证它真的生效了

写完不代表生效。我有个特别简单的验证方法：开一个全新的会话，什么都不说，直接让它做一个小改动，比如"给用户列表加一个按注册时间排序的选项"。然后看它输出的代码：

• 有没有用你指定的技术栈？
• 文件放对目录了吗？
• 返回值格式是{ ok, data }还是裸数据？
• 有没有引入新依赖？

如果这四点都对，说明文档生效了。如果有一两条不对，通常是那部分描述太含糊。比如我一开始写"错误处理要统一"，模型理解成了"统一打日志"，后来改成明确的返回结构示例，立刻就对了。

提示：验证文档生效时，一定要用新会话。在旧会话里测是不准的，因为历史消息里可能有你没意识到的暗示。

4. 从零跑通一个 Vibe Coding 循环的完整步骤

4.1 环境准备里最容易忽略的两件事

工具本身其实没什么好挑的，能读文件、能改文件、能跑命令的编程助手基本都能用。真正容易被忽略的是两件事。

第一件是版本控制的状态要干净。开始之前，务必确认工作区没有未提交的改动，或者至少先把当前状态提交一次。原因很实在：Vibe Coding 的尝试次数很多，你需要一个随时能退回去的锚点。如果工作区本来就有一堆零散改动，一旦生成的东西把某处改坏了，你连"退回到哪"都说不清。

第二件是让命令能一条跑通。类型检查、测试、构建，这三个命令必须是开箱可用的。如果项目本身跑测试都要配半天环境，那模型每次想自检都卡在环境上，整个循环就断了。我现在的习惯是，项目初始化第一件事就是把这三条命令配好，再开始写业务。

还有个小细节：如果有格式化工具，先跑一遍把存量代码格式化统一。不然模型生成的代码和你原有的风格混在一起，后面 diff 会非常难读。

4.2 第一条指令应该怎么给

第一条指令决定后面几轮的质量。我的经验是遵循一个结构：目标 + 边界 + 验收方式 + 参考。

举个例子。不要这样说：

帮我做一个设备借用功能。

这样说：

目标：在 src/domain 下新增设备借用的业务规则函数，实现"借用"和"归还"两个操作。 边界：只写 domain 层的纯函数，不碰数据库，不碰路由；入参和返回值都用已有的类型定义。 规则：同一台设备同时只能被一个人借用；归还时必须校验借用人一致；每次操作需要记录时间戳。 验收：写完在 src/domain/borrow.test.ts 里补上覆盖上述三种情况的测试，然后跑 pnpm test。

第二种说法好在哪？它把"做什么"和"不做什么"都说清楚了，把验收标准也给了。模型不需要猜你的意图，也不需要为了保险多做一堆你没要的东西——比如顺手把路由也写了，那才是真的添乱。

我自己的体感是，第一条指令里"不做什么"往往比"做什么"更重要。因为模型天然的倾向是"多做一点显得更完整"，而这个倾向在有明确边界的项目里就是灾难。

4.3 迭代节奏：小步、可回滚、随时验收

一个健康的循环大概是这样：

1. 描述一个小目标（控制在一次能改完的范围内）
2. 让模型改，改完自己先跑一遍类型检查和测试
3. 我这边跑一遍实际功能，看输出对不对
4. 对了就提交，不对就继续描述哪里不对

关键是第 2 步，一定要让模型自己先跑检验命令。这条我坚持了很久，收益特别明显。它自己跑一遍，能拦住大概七成的低级错误——拼错的方法名、漏掉的导入、类型不匹配。这些错误如果留到我这，我可能得看半天才知道问题在哪。

第 4 步的提交频率也要高。我的习惯是每完成一个小功能就提交一次，哪怕这个功能只有二十行。提交信息写清楚这次干了什么。这样做的好处是，一旦发现三次尝试之前那个方向是错的，往回退的时候不会一波带走太多正确的改动。

至于"小步"到底多小？我的标准是：出错的时候，能一眼看出是哪一步引入的。如果一次改动涉及了五个文件、改了两百行，那就不算小步，应该拆。

4.4 什么时候必须停手，自己动手写

这个判断力比什么技巧都重要。我总结了几条红线，碰到就自己写：

第一，同一个问题描述了三遍还没解决。说明要么是模型理解不了这个领域，要么是这个问题本身需要更细的拆解。继续描述下去大概率是浪费双方的时间。

第二，出现了"改了这里坏了那里"的循环。这说明底层结构有问题，让模型在错误的结构上继续打补丁只会越来越乱。

第三，涉及核心算法或性能瓶颈。这种地方"能跑"和"跑得好"差距巨大，靠描述很难传达清楚。

第四，你自己读不懂生成的那段代码。这是最硬的一条。读不懂就意味着无法维护，无论它现在跑得多好，都是定时炸弹。宁可花时间重写一遍，也比留一段黑盒强。

5. Vibe Coding 失控时的典型症状与排查链路

5.1 症状一：改一处坏一处，越改越慌

这个症状我遇到的次数最多。表现是：你让模型改 A 功能，它顺手动了 B；你再让它修 B，A 又坏了。来回几次之后，你自己都说不清当前代码是什么状态。

这种局面的根因通常不是模型不行，而是它没有完整的视野。它每次只看到你给的那几个文件，不知道其他模块怎么依赖这些接口。所以它的修改在局部看是合理的，在全局看就破坏了契约。

对应的做法是，一旦进入这个循环，立刻停下。然后按这个顺序处理：

1. 用git diff --stat看这一轮到底动了多少文件，通常会发现问题比你想象的大
2. 把当前改动全部退回上一次提交
3. 重新描述需求时，明确列出所有相关的文件，并且加上一句"不要修改这个列表之外的文件"

最后这句约束特别管用。它把模型的行动范围框死了，破坏其他模块的概率大幅下降。我现在的习惯是，任何涉及公共接口的改动，都要在指令里显式列出影响面。

5.2 症状二：能跑，但里面全是硬编码

这是我踩过的最隐蔽的坑。功能测试全过，界面也正常，但打开代码一看：设备类型是写死的数组、超时时间是写死的数字、路径拼接里混着绝对路径。它在"把事办成"这个目标上完成得很好，在"这个代码能不能改"上完全不及格。

为什么会出现这种情况？因为你的验收标准里没有包含"可配置性"这一项。模型是按你的验收标准干活的，你只测了功能，它就把功能做到位；你没提可配置，它就用最简单的方式实现。

所以从第二次迭代开始，我在全局文档里加了一条：

所有会随环境变化的量（地址、超时、开关、类型枚举）必须来自配置文件或环境变量，不得硬编码。

加了这一条之后，这类问题基本消失了。如果已经出现了，处理办法是让模型专门做一次"去硬编码"的重构，并且在指令里明确列出要抽出来的量有哪些——不要指望它自己找全，它找不全。

5.3 症状三：文档和代码开始脱节

全局 md 文档写得越认真，这个问题越容易出现。因为你在文档里规定了目录职责，但某一轮对话里模型为了方便，把代码放在了别处。三周之后，文档说的和代码做的是两回事，文档就成了一纸空文。

我的处理方式是，把文档校验变成循环的一部分。具体做法是，每隔一段时间（我大概是一周一次），开一个新会话问它：

请对照项目全局约定文档，检查 src 下所有文件的目录归属是否合规，列出不符合的地方和原因。

让它自己做一次审计。这个操作花不了几分钟，但能及时发现漂移。发现之后不要直接让它改，先自己看一眼，因为有时候是文档本身需要更新，而不是代码需要挪。

5.4 一条可以照着走的排查顺序

出问题的时候，最怕的就是乱试。我固定用这个顺序排查，效率最高：

第 4 步特别值得说。问它"你实现这个功能时，假设了什么前提"，往往能直接暴露问题。我遇到过一次，它假设"输入一定非空"，所以没做空值判断，而实际上游可能传空数组。这个假设它自己说得清清楚楚，比我翻十遍代码都快。

6. 长期项目里必须立住的几条硬规矩

6.1 版本控制是唯一的保险绳

这句话我写在文档最前面。Vibe Coding 的所有便利都建立在一个前提上：你随时能退回去。一旦这个前提不成立，整个模式的风险就会放大好几倍。

具体要做到几点：每次生成之前工作区是干净的；每个功能完成就提交；提交信息写清楚改了什么、为什么改。分支策略上，我建议每个稍大的功能开一个分支，因为 Vibe Coding 的尝试过程会产生很多零碎提交，混在主分支里很难看。

还有一个容易忘的：不要在有未提交改动的状态下接受大范围重构。这时候如果出了问题，你连"哪些是它的改动、哪些是我的改动"都分不清，回滚就变成了猜谜。

6.2 类型检查和测试，给"感觉"装上刹车

前面说过，Vibe Coding 靠感觉推进。但感觉必须有东西兜底。类型检查和自动化测试就是那个兜底。

我的配置标准是这样的：类型系统开严格模式，宁可多写几个类型定义，也不要any满地跑，因为any会绕过整套检查。测试上，我不追求覆盖率数字，而是盯住三件事——核心业务规则、边界输入、错误分支。这三块有测试，心里就有底。

顺带说一句，让模型自己写测试有个副作用，就是它写的测试往往会迎合它的实现，而不是验证需求。我遇到过测试全绿但功能就是不对的情况，原因是测试用例本身写错了。所以我现在的习惯是，关键功能的测试用例我自己列，让模型去实现；而不是让它自己列自己实现。

6.3 全局文档的更新节奏

文档不是写完就完事。我的更新规则有三条：

第一，每次新增一条约束就立刻加进去。比如这次发现它爱硬编码，就加一条禁止硬编码。不要攒着，攒着就忘了。

第二，定期删掉已经内化的内容。有些规则写了一段时间后发现，模型基本不会犯这个错了，就可以删掉，给文档减负。上下文空间是有限的，留给出错概率高的约束。

第三，每次大重构之后，把文档通读一遍。因为重构常常会改变目录结构，文档里的目录职责描述可能已经过时了。

我现在的文档大概每两周动一次，每次动只是加一两行或者删一两行。这个维护成本很低，但收益很明显。

6.4 团队里怎么共享这套规则

如果只有你一个人用，文档放根目录提交到仓库就够了。如果是团队，就需要多考虑两点。

一是不要各写各的。每个人项目里有自己的一份全局文档，结果就是提交来提交去互相覆盖。我们后来的做法是，把这份文档当作项目资产，改动走正常的评审流程。

二是区分强制项和建议项。文档里有些是硬约束（比如技术栈、返回值格式），有些是偏好（比如命名风格）。硬约束要写得斩钉截铁，偏好可以写得宽松些。全都写得一样强硬，模型会束手束脚，反而影响效率。

还有一点体会：团队里最好有一个人负责这份文档的最终拍板。否则讨论"到底用不用某个库"会没完没了，文档也就没法稳定。

7. 几个更细的技巧和我自己的体会

7.1 用反向提问榨出更多信息

这是我用得最多的一招。当模型给出一个方案后，不要急着接受，先问它：

这个实现有哪些已知的局限？在什么情况下会出问题？

它的回答经常能帮你省掉一次返工。因为模型对自己的产出其实是有认知的，它知道哪里是权宜之计、哪里用了简化假设，只是除非你问，它不会主动说。我问过几次之后发现，它自己列出的风险点，往往比我事后发现的还要准。

7.2 让它先写文档，再写代码

这个习惯是从写全局文档那件事延伸出来的。对于稍微复杂一点的功能，我会先让它写一份简短的设计说明：接口长什么样、数据怎么流、有几个分支。我确认之后，再让它照着写代码。

好处有两个。一是纠正成本低，改一段文字比改一百行代码容易得多。二是前后一致性有保障，因为它手里有自己写的说明，实现时不太会跑偏。这个流程多加了一步，但整体上反而更快。

7.3 我这几周攒下来的一份踩坑清单

• 不要在同一个会话里滚太久。聊到二三十轮之后，早期的约定基本失效了，模型开始飘。宁可分新会话重新开场。
• 不要给它"顺便优化一下"。这个指令会引发大范围改动，风险极高。要优化就单独立一个任务。
• 不要接受没跑过的代码。哪怕它说"应该没问题"，也要实际跑一遍。我因为这个吃过一次亏，浪费了一个下午。
• 不要让它在没有测试的模块上大改。先补测试，再动逻辑。
• 不要相信"我改好了"。要它给出证据：跑了什么命令、输出了什么。这一条能省掉大量来回。

最后分享一个我最近才意识到的事：Vibe Coding 真正的门槛不在提示词写得多漂亮，而在于你能不能把一个模糊的想法，切成一连串边界清晰的小问题。这件事以前是隐性的，因为写代码的过程本身就逼着你做拆解；现在拆解这一步被显式地摆到了台面上，做不好，后面全乱。我自己在这上面吃过不少亏，也还在练。