企业官网建设流程全解析

Vibe Coding 这个词火了之后，我身边最多的问题不是"怎么让 AI 写代码"，而是"让 AI 写出来的东西怎么用"。标题里这个排序——说清楚再验收——不是随口一说，而是我在几个内部小工具和一个外包协作项目里踩出来的顺序。AI 写代码的速度快得离谱，十分钟给你几百行代码，可如果你一开始没定义清楚"什么叫做好"，这几百行就会变成一条看不见尽头的返工隧道。

这篇文章我想把 Vibe Coding 从"动嘴让 AI 干活"的玄学还原成一个实在的工作流：先写验收标准，再生成代码，最后按标准逐条验收。无论你是刚听说这个词的非程序员，还是写了几年代码但想用 AI 提效的老手，这套流程都能直接抄。顺便说一句，搜"vibe coding 验收"时有时会看到一些硬件设备的验收词条，这其实是名称撞车，但背后那个道理是通用的：任何有交付物的活，都得先说清验收标准。

1. Vibe Coding 不是玄学，但也别把它当许愿机

1.1 它到底是什么：从"手写代码"到"口述验收"

Vibe Coding 最早是 Andrej Karpathy 提出的说法，大意是你不再一行行手写代码，而是用自然语言描述意图，让 AI 模型完整体现你的想法，最后你自己只需要看结果、做取舍。这个过程的重点不是"聊得开心"，而是"意图密度"——你一句话里包含的细节越多越准，AI 落在代码里的行为就越接近你要的东西。

我比较喜欢的类比是：你现在带了一个阅读理解能力极强、但完全不会读心术的超级实习生。你布置任务时说得越含糊，他能发挥的脑洞越大，最后你验收时越崩溃。你说"把客厅收拾干净"，他可能把所有东西都塞进柜子里，功能上确实"干净"了，但你要找钥匙时会在抽屉里翻半小时。需求里的每个关键词都可能被他极端地执行，甚至过度执行。

所以 Vibe Coding 本质上不是"随便聊聊就出软件"，而是"用自然语言做需求文档，用代码生成代替手工实现，用验收清单代替测试用例"的协作模式。它和传统开发的差别不在写码方式上，而在你的角色变化：从每行代码都自己敲，变成了定标准、看结果、控边界。工具选型反而是最不重要的事，真正决定成败的是你有没有把需求想清楚。

1.2 为什么"验收标准"才是 Vibe Coding 的真正瓶颈

这个判断不是拍脑袋。传统编码时代，人的打字速度、语法熟练度是瓶颈，一个功能写一天很正常；Vibe Coding 时代，生成环节几乎免费，瓶颈彻底转移到"判断和校验"上。AI 十秒生成的功能，如果需求本身是错的，那返工不是十秒，而是你花一小时把代码看懂、再花一小时描述清楚哪里不对、再等它产出 v2——一个简单功能可以这样耗掉一个周末。

而"验收"恰恰是大家最容易偷懒的环节。很多教程都在教你怎么写 prompt、怎么调模型参数，却很少有人告诉你：代码生成之前，你就该把"什么算完成了"写下来。这其实是敏捷开发里 acceptance criteria 的老概念，在 AI 写码时代重新变得关键。原因很简单：AI 不会问"你说得不够清楚，我能不能跟你确认一下"，它只会顺着你字面上的话往下做，等于给你返回一个包装精美的错误方向。延迟定义标准，等于把风险滚雪球，越到后期修复成本越贵。

我知道很多人第一次听到 Vibe Coding 时，第一反应是"终于可以不用学代码了"。现实是：代码可以少写，但需求建模和验收能力反而变得更重要了。这也是我把"说清楚再验收"放在最前面的原因——这是整套方法的承重墙，没有这面墙，后面所有花里胡哨的 prompt 技巧都撑不住。

2. 说清楚：把一句含糊需求拆成 AI 能执行的验收清单

2.1 验收标准的三个层次：功能、质量、呈现

写验收清单之前，先搞明白要覆盖哪几类。我一般分成三层：

功能层解决"有没有"，质量层解决"好不好"，呈现层解决"像不像给人用的"。很多 AI 项目翻车都是因为只写了功能层："帮我做个批量重命名工具"，结果 AI 交了个能跑但一遇到重名文件就静默覆盖的作品——你根本没给它定义过撞名时该怎么办。质量层的缺失是这类事故的根源。

在动手让 AI 写代码前，把这三层各列两三条，就已经比大多数人的起点高一大截了。注意一点：验收标准要写"该怎样"，不要写"该怎么实现"。比如"加载时间小于 1 秒"是标准，"用 CDN 或者用 HTTP/2"是实现方案；AI 最擅长的就是把你的方案做得很好看，但标准换了味道，就不是你要的东西。

2.2 把"感觉"翻译成条件：坏例子与好例子

这个环节最难，因为我们的日常表达充满了感觉词。下面是几个我看过太多遍的对话，以及它们应该被翻译成什么样子：

把每个验收项写成"当...时，系统应该...，并且..."的句式，几乎立刻就能暴露需求的空洞。比如"当上传的文件是空文件时，系统应该提示用户并终止处理，并且不生成任何输出文件"。这句话同时定义了触发条件、行为、和副作用边界。当一个条件能用"是/否"判断时，它才算真正进入了验收清单。

还有个小技巧：验收清单必须包含"不做什么"。告诉 AI"这个版本不做多用户登录，不做图片识别"，比告诉它"你要厉害一点"有用得多。范围是标准的一部分，越早写死越安全，否则 AI 会在你不管的地方自行发挥，给后面埋雷。

2.3 交付物不同，验收粒度完全不同

同样的"说清楚"，在不同类型的交付物身上，关注点完全不一样。我按场景分开说：

• Web 页面：除了主流程，还要验状态覆盖——加载中、空数据、报错、断网各自长什么样；以及响应式断点、浏览器兼容性。我会写明"360px 宽不出现横向滚动条""Chrome 和 Safari 都要正常"这类句子。
• 脚本与命令行工具：验输入边界、退出码、幂等性。比如"重复运行不覆盖旧文件""目录不存在时报错并提示正确用法"。
• API 服务：验接口超时、错误码、鉴权、数据一致性。"请求 100 次，错误率低于 0.1%""无权限返回 403 而不是 500"。
• 嵌入式程序：验资源约束、实时性、外设协议。内存占用上限、任务周期是否满足、引脚和字节序是否符合硬件手册。

拿嵌入式 vibe coding 来说，这块的验收标准是最严格的，因为硬件上没法随时热修复，代码错了轻则重启，重则可能影响整个系统。所以我不建议在嵌入式场景里让 AI"自由发挥"，每条验收标准都得能上板实测，编译通过、单元测试通过只能算基本盘，最后必须拿真硬件跑一遍清单。

3. 验收闭环：让 AI 先自证，再人工兜底

3.1 把验收标准变成自动化测试

"验收标准"和"测试用例"在 AI 生成的场景下几乎是同义词。最有效的方法不是让 AI 生成完代码，再由你手动一条条验，而是把验收标准直接投喂给它，让它先把标准翻译成测试代码。测试先行的逻辑在这里特别顺：非程序员做不到"读懂代码"，但完全可以读懂"这个测试在验什么"；而 AI 写的代码自己也未必每行都有把握，测试就是它自证清白的方式。

举个真实例子。我要一个"从会议纪要里提取关键词"的小函数，验收标准里有一条"输入纯文本，输出出现频率最高的前 5 个词，并忽略停用词"。我会把这条直接写进 prompt，并要求它先写 pytest 用例再实现，比如：

def extract_keywords(text: str, top_n: int = 5) -> list[str]: """从文本中提取 top_n 个高频关键词，忽略停用词。""" def test_extract_keywords_ignores_stopwords(): text = "项目 项目 项目 的 的 的 验收 验收 标准 标准 标准 标准" assert extract_keywords(text, top_n=3) == ["标准", "项目", "验收"]

AI 写完测试和实现后，直接在本机跑一遍；红了就让它改，绿了才进入人工环节。这套循环能把功能层的大部分问题消化掉，你真正需要动脑子的，只剩下测试覆盖不到的地方。我实测下来，凡是让我先写测试的 prompt，最终交付质量明显高于"直接给我实现"的请求，前者返工次数平均会少一半以上。

3.2 人工验收不能只看"能跑"

自动化测试解决了确定性判断，但"能跑"不是验收的全部。我用 Vibe Coding 完成过几个工具后的体会是：AI 很喜欢吞错误。你会发现程序在大路线上表现得体，但异常分支里全是静默失败——比如文件没权限时它直接退出而不告诉你；网络请求超时它重试三次后没任何日志；你查半天发现它把错误掩盖在了空的 except 块里。

所以人工验收阶段，我基本只做三件事：看入口和退出逻辑、看数据层的读写方向、看依赖和配置。具体说，入口文件要看参数校验有没有兜底；数据处理要看会不会把不该删的删了、会不会把内容写成别的编码；配置和依赖要看版本来路是否干净、有没有明显不该出现的权限要求。其余业务代码可以信任测试，但这三类不能跳过，因为它们对应的是数据安全、资源消耗、部署稳定性这些直接影响用户的东西。

另一条经验：验收时把日志也当作交付物来验。一个工具如果运行失败时只抛出"Error"，那它还不算完成；验收标准里可以加一条"所有错误必须有可读信息，并建议下一步动作"。这类标准 AI 很容易满足，但对日常使用体验的提升是巨大的。

注意：自动化测试全绿，不等于业务正确。AI 可能把测试和实现写得"互相配合"，绕过标准里真正难的部分。所以哪怕测试过了，我也至少要肉眼看一遍关键逻辑，尤其是"删、写、改权限"这类不可逆操作。

3.3 小步迭代：每次验收通过都留一个版本

AI 写代码有一个让人哭笑不得的特点：修一个 bug 可能顺带重写半个文件。所以"改错地方"和"改对但破坏了别的功能"是 Vibe Coding 项目最大的两个回归风险。我的对策很简单：把大需求拆成小模块，每个模块完成一轮"定义标准 → 生成 → 自动测试 → 人工抽查"，验收通过立刻 commit，甚至打一个 tag。

比如我常用的版本注释方式是 git tag v0.1-accepted 这样。之后每次迭代，如果 AI 越改越乱，直接 checkout 回上一个 accepted 版本，换一种表述重新开始，成本也就是十分钟。很多 AI 对话走偏之后，硬着头皮继续聊是最亏的，上下文污染会让它越改越偏；回到验收过的版本，带着更清晰的差异化需求重新开对话，反而快得多。

4. 实操走查：一个小项目从需求到验收的完整记录

4.1 写验收清单：先花半小时把标准定死

为了演示，我挑了一个很多人都会用到的场景：把一场会议录音的转写文本，变成一份带关键词的会议纪要。现场的输入是纯文本转写稿，目标输出是 Markdown 文件。我先花大概三十分钟把验收清单写下来，而不是直接让 AI 开工。

清单大约长这样：

• 功能层：读取 .txt 输入；输出 .md 文件；摘要部分按"决议/待办/风险"三类组织；关键词取高频词并忽略停用词；不接入任何在线服务，数据处理全程本地。
• 质量层：20 页文本 10 秒内出结果；空文件提示并退出码 2；超长文本（10 万字以上）不崩溃；重复运行时不会覆盖旧文件，而是生成带时间戳的新文件。
• 呈现层：Markdown 有标题层级；关键词用逗号分隔；文件尾部附生成时间与输入文件名。

注意这里我把"不做什么"也写进去了："不接入在线服务"，是为了避免它顺手调一个 LLM API，把纯本地工具变成有隐私顾虑的东西。范围写死，边界才能立住。

4.2 带着清单去写代码：Prompt 里必须带验收标准

我用的工具是终端里的 Claude Code，不过这套写法换到 Cursor、Cline 上一样适用。初始化时我在项目目录放了一个 CLAUDE.md，里面就是那份验收清单，并且加了这么一句规则："每次修改后必须运行项目里的测试命令，并报告哪个验收项通过、哪个未通过。"

然后发出的初始 prompt 长这样：

项目：会议纪要关键词提取工具。 输入：一行一个文件路径。 输出：同名 .md 文件。 验收标准见 CLAUDE.md，请严格按照标准实现。 第一步先写 pytest 测试，第二步实现，第三步运行测试。 测试全部通过之后再交付，不要在交付说明里解释代码设计。

这段 prompt 本身平平无奇，但有三点很关键：验收标准放进了长期记忆文件而不是对话里；要求先测试后实现；禁止解释型输出。第二条可以避免 AI 给你一大段"设计思路"然后交一个跑不起来的代码；第三条能让你把精力放在结果而不是氛围上。

初版生成大概花了二十多分钟，包括它自己跑测试、修了两轮小问题。第一轮测试通过后，我进入人工验收环节，发现了个测试没覆盖的问题：输出目录不存在时，程序直接崩溃，而验收标准里没写这条。我当场补了一条验收标准进清单，再让它修。这个动作就是"说清楚再验收"的现场版——验收过程中发现的新边界，第一时间回流到标准本身。

4.3 验收、记录、返工：一次真实的迭代

人工验收阶段我按清单逐条过，验收记录长这样：

两处返工的修法相差不大：把失败信息喂回给它，附上"最小化修改，不要碰无关代码"的约束。第二次返工只花了几分钟。整套流程下来，从定义到验收完成不到三小时，其中真正需要我动脑的时间大概占了三分之一，剩下的都是 AI 自己在写、在测、在改。这就是有验收标准和没验收标准的差距：后者可能一个周末搭进去，前者三小时收工。

4.4 换个场景：这个流程对非程序员同样适用

我不建议只有程序员用这套方法。我身边有同事完全不写代码，但也用 Vibe Coding 做成了不少事：批量整理网盘文件、把几十个 Excel 合并成交报表、给团队做意见收集表单的后端逻辑。他们的共同特点不是会代码，而是会列完成条件。

比如整理网盘这个需求，普通人会说"帮我整理一下文件"，但这位同事写下来的完成条件是：按年月建文件夹、重复文件跳过并写日志、程序结束打印"移动了 N 个文件，跳过了 M 个重复文件"。就这五句话，AI 就能交出可用脚本。非程序员可能看不懂一行代码，但完全可以验收每一个条件——这也正是"说清楚再验收"对所有人都有意义的原因。

5. 常见问题与排查技巧实录

5.1 AI 说"做不到"？先学会拆

我很常遇到这样的对话："帮我把 PDF 里表格提取成 Excel"，AI 回复"需要第三方库，可能比较麻烦"。别急着换工具，先把它说的"比较麻烦"拆开。麻烦通常来自三个地方：PDF 扫描件需要 OCR、表格结构复杂、表格不在同一页。对应地拆成三步走：先让它完成"文本型 PDF 提取"，再单独做"扫描件 OCR 模块"，最后才合并成"一键脚本"。每一步都有自己的验收标准，代码量小、验证路径清晰，AI 的完成率会高得多。

如果拆完还不行，那就是任务本身超过模型能力，或者模型上下文容纳不下整个方案。这时候我会换一个更强的模型，或者换一种思路实现，比如绕开表格识别，直接让用户把 PDF 另存为 Excel 再合并。

5.2 越改越乱的死循环怎么破

AI 越改越乱，几乎是每个 Vibe Coding 用户必经的坎。通常的表现是：改 A 功能时把 B 功能搞坏了，你再让它修 B，它又把 C 弄坏。这时候别继续对话，对话历史越长，AI 越分不清哪些是新要求、哪些是旧约束。

我的做法是开一个新对话，把项目背景压到最短：一段话需求、验收清单、刚才改坏的现象描述。然后明确告诉它"基于最近的 git 版本继续，只修这一个问题，不要重构其他代码"。很多新手舍不得丢掉对话历史，觉得重开麻烦，但实测下来重开反而更快。上下文是成本，不是资产。

提示：把验收清单和测试命令放在独立文件里（如 CLAUDE.md、AGENTS.md），这样换模型、开新对话时，AI 都能在第一步读到约束，不用反复口头叮嘱。

5.3 AI 很礼貌但没解决问题：要求先写测试

有时你会遇到一种"配合型表演"：AI 回复"好的，我已经完成了"，然后你跑一下发现压根没变化，或者代码里有大量注释但核心逻辑粗细不精。这时候我会把 prompt 改成"请先创建测试文件并跑一遍给我看，再写实现"，让它的交付物从"解释"变成"证据"。

我还会加一句"改动列表里必须写清楚你改了哪几个文件、每个文件动了哪一行级别的内容"。这个约束能在不增加多少成本的情况下，逼着它老老实实做最小改动。如果你连这个都不想要，可以直接要求"用 diff 形式输出所有改动，禁止大段复制粘贴"。

5.4 验收标准不是越细越好

前面一直在强调标准要具体，但具体不等于多。我见过有人把验收清单写到八十多条，连按钮圆角半径、图标颜色都定死，结果 AI 每改一个地方都要重新适配十几个条件，进展非常缓慢。标准的关键路径可以写死，但外观和实现方式应该给 AI 留自由度。

我的取舍原则是：功能层和质量层的风险大，写死；呈现层只写"状态齐全、无横向滚动条、可读性达标"这类底线，其余让 AI 自由发挥。如果 AI 的产出太丑再单独提一轮视觉修改。约束的颗粒度应该和你对风险的容忍度成正比，而不是和你对控制欲的满足感成正比。

5.5 安全红线：哪些东西不能交给 AI

这个必须单独说。AI 生成的代码，尤其是让它从零写起的项目，有两类风险：一是你直接把生产环境的密钥、数据库信息、内网地址贴进对话，等于把敏感信息外包出去；二是它生成的代码里可能带进来源不明的依赖，或者默认开放了不该开放的权限。

我给自己定的规矩是：生产相关的东西不进 AI 对话；AI 生成的依赖清单必须人工过一遍，确认版本和来源；涉及支付、权限、用户数据的代码，无论测试多绿都强制人工 review。Vibe Coding 适合原型、内部工具、非关键链路，核心业务还是要有真人在关键位置把关。这和技能无关，是责任心的问题。

6. 我的工具清单与使用习惯

6.1 工具按场景分工，别指望一个工具打天下

市面上"vibe coding 工具"很多，我常被问哪个最好。实际上工具之间差距没那么大，差别主要在适用场景：

我的习惯是：小工具和脚本用 Claude Code，因为可以提前把 ACCEPTANCE.md 放在项目里让它自己读；页面类项目用 Cursor，因为它能直接预览效果，验收更快；想搞清楚 AI 行为时切到 Cline，看它一步步怎么操作。工具可以换，工作流不要换——定义清楚 → 生成 → 自动验证 → 人工验收 → 记录版本，这个闭环在哪套工具里都一样。

6.2 嵌入式 Vibe Coding 的额外纪律

本来想聊聊嵌入式，因为这块的搜索热度也不低。嵌入式场景里 AI 写 C/C++ 代码没问题，问题在于"PC 上能跑"和"板子上能跑"是两回事。我给这块定的纪律是四条：交叉编译必须通过；模拟器和单元测试只能证明逻辑，不能证明时序；硬件在环测试的验收项要写死 CPU 占用率、内存峰值、外设时序；烧录前必须人过一遍中断处理和资源释放的代码。

比如一个电机控制任务，验收标准会写"控制周期 1ms 内完成，CPU 占用低于 30%，异常断电时电机保持刹车状态"。这些条件 AI 无法自行验证，只能你列出来、它实现、你上板测。嵌入式 Vibe Coding 不是不能用，而是验收标准必须比 Web 场景更早定、更严格地定，因为硬件出错没有 Ctrl+C。

6.3 把验收清单变成团队流程而非仪式

最后说说团队协作。我带的人里，有经验的工程师容易把验收清单当成"给 AI 看的 prompt 模板"，生搬硬套；没经验的人容易把它当成"开工前要填的表格"，填完就忘。这两者都偏离了本质。验收清单是团队和 AI 之间的共同语言，它存在的意义是让"什么叫做好"这件事可争论、可确认、可传承。

所以在团队里，我会把每次项目的 ACCEPTANCE.md 留下来，攒成一个内部模板库。下次同类需求直接复制改，不用从零开始写"说清楚"的部分。这个准备工作会让后面每个项目的返工成本肉眼可见地下降，里面的条条框框不是流程仪式，而是真实踩坑的记录。

我个人在实际操作中的体会是：Vibe Coding 最自由的地方不是让 AI 放开发挥，而是让你的需求表达能力可以完全展开。代码里有 80% 的活可以让 AI 干，但那 20% 的"定义清楚"必须自己来。最后再分享一个实用小习惯：在项目目录里放一个 ACCEPTANCE.md，每完成一个迭代就更新一次，让 AI 自己读它、自己报告验收状态。试过之后你会发现，"说清楚再验收"这四个字，能帮你省下比想象中多得多的时间。