企业官网建设流程全解析

2025 年 2 月，Karpathy 造了「vibe coding」这个词——别想太多，感觉对了就让 AI 写，边跑边看。这条推转发超过 10 万，因为说出了很多人的心声：原来写代码可以这么爽。

一年后，风向变了。「烧了 2000 美金，我发现 Vibe Coding 已死」这类标题开始刷屏。2026 年 2 月，Karpathy 本人也改口：vibe coding 的时代正在结束，我们进入的是 agentic engineering。

但他没说 vibe coding 错了。他说的是，光靠 vibe 不够了。

一个被问错的问题

过去一年，社区一直在吵「vibe coding 和 spec coding 谁对」。这个问题本身就有问题。

两种方式的差别不在「用不用 AI」，在判断发生在什么时候：vibe 把判断推迟，先让代码跑起来再说；spec 把判断前置，先锁住契约再生成。

一个更贴切的说法是：vibe coding 回答「AI 能不能写」，spec coding 回答「AI 写的东西能不能信」。从「能写」到「能信」，就是这场范式迁移的全部意义。

为什么现在才撕起来

这场争论是 AI 能力逼出来的。

在 AI 只能补全几行代码的年代，不存在 vibe coding——生成量太小，你怎么写都是人在主导。但当 agent 一次 session 能改几十个文件、产出几千行代码，一个新问题就冒出来了：生成越来越便宜，方向对不对成了瓶颈。

于是分成了两派。一派说「生成这么快，就别写文档了，直接跑」，这是 vibe 的底气。另一派说「生成越快，越需要一个东西把方向钉住，否则跑得快但跑偏」，这是 spec 的底气。

数据开始替后者说话。McKinsey 的报告里，65% 的企业说 AI 生成的代码「在原型阶段表现不错，但无法满足生产环境的可维护性要求」。Rand Group 的调研更刺眼：90-95% 的企业 AI 项目没能从试点进入生产。这不是 AI 写不好代码，是没人告诉 AI 为什么要写这段代码。

一张表看清优劣

vibe coding 的优势

快，而且快得真实。

探索原型、UI 试错、一次性脚本、快速验证 API——这些场景 vibe coding 没有对手。你还没想清楚要造什么，先让 AI 跑一版出来看看感觉，比任何前置仪式都强。

反馈紧。写代码最诚实的反馈就是「跑起来」。一个 API 到底是不是你以为的那样，vibe 几分钟就能回答，spec 只会把这个循环拖慢。

认知负担低。不需要维护额外文档，想改就改，想重来就重来。Tiugo 的 CTO Wiktor Walc 说得很准：vibe coding 配合强大的 agentic 系统，在缺陷爆炸半径小的场景——内部工具、第一个 POC——能带来惊人的速度。

vibe coding 的劣势

意图会蒸发。这是最根本的一条。「我们当时为什么这么决定」只活在聊天记录里，session 结束上下文就没了。下一个 session 的 AI、新来的同事，只能从代码反推意图，而反推经常是错的。Levelop 团队把它叫「没有可恢复意图的代码」——出了 bug 没有 spec 可对照，调试变成考古。

架构漂移。没有显式的「不做清单」，AI 会实现一切看起来合理的东西。session 三埋进数据模型的那层缓存，到 session 十就成了删不掉的债。

约束会被遗忘。「只有认证用户能触发这个」这句话，在 vibe 里被提过一次，session 四的新端点就没了。安全假设、校验边界、密钥处理——这些恰好是 AI 在追求「能跑的代码」时最会漏掉的。

可预测地崩在多文件。大约超过五个文件，上下文窗口就开始丢不变量。有人经历过更具体的版本：AI 在长对话里「忘掉」前面定好的字段命名，自信地用了另一套；改一处逻辑，另一处莫名挂掉；让它做个简单数据导出，它给你整了个异步队列加断点续传。

另一边，spec coding 的优势

意图可持久化。spec 是「要什么、为什么、不做哪些」的显式记录，不随 session 消失，能进版本控制、给下一个人读、给下一个 agent 读。这是 spec 最被低估的价值：代码会重构，意图记录不会。

质量可验证。验收标准能变成测试，代码对不对不再靠「我感觉」，看测试过没过。

协作安全。共享的、版本化的契约让并行编辑冲突更少。评审 spec 比评审代码便宜——评审一份 150 行的 design 只要十分钟，评审一个 3000 行的幻觉 PR 要一下午。

数据也站在这一边，但要打折看。Hoko 说 SDD 能减少 40-60% 的 bug、降低 50% 的重构时间；Accenture 一项 450 名开发者的随机对照试验显示，结构化工作流让合并请求 +8.69%、合并率 +15%、成功构建 +84%。数字好看，但大多来自 SDD 工具厂商或合作方，对照组也不清晰。保守结论：中等规模以上项目，有 spec 比没有好，方向是对的。

但它也不是免费的

前期慢。写一份能用的 spec 是真功夫，比张口让 AI 生成费时得多。对探索期和一次性工作，这份开销纯属浪费。

容易过度设计。把 spec 写成五十页需求文档、对着小功能磨两天需求、迟迟看不到代码——这是 spec coding 最常犯的错。有工程师拿一套 spec 流水线去跑一个小 CLI 工具，结论是「激进的想法，还是被重新发明的瀑布流」：花了大量时间打磨需求，迟迟看不到代码。HN 上有人把这种叫「Waterfall Strikes Back」，讽刺的不是 spec 本身，是长期前置规划。

spec 会漂移。如果没人强制代码去对齐 spec，spec 就会变成文档，而文档会漂移。一份不再匹配代码的 spec 比没有更糟，因为人和 agent 都还在信它。

有门槛。写清「输入、输出、不变量、边界」需要工程判断力。不会写 spec 的人，spec coding 帮不了他。

同一个功能，两种写法

Levelop 团队的 streak-freeze 功能能说明一切。

vibe 版的开头：「加一个 streak freeze，每周左右给他们一个。」这句话在 happy path 能跑，但「每周左右」不可检查，时区处理没说，上限是拍脑袋。

spec 版的开头是验收标准：连续七天活跃得一个 freeze，最多存两个；错过一天在用户本地时区的午夜扣掉，不是 UTC；扣掉的动作五秒内出现在活动日志里。agent 从这份 spec 推导出 schema 变更、事件消费者、时区边界矩阵。两个月后，一个新 contributor 改上限，只改了一行 spec。

差距不在「有没有写文档」，在「能不能被测试验证」。

怎么落地，其实门槛不高

spec 不是凭空写出来的，它前面还差一步很多人跳过的 brainstorm。

别一上来就让 AI 写代码，甚至别急着写 spec。先发散、对齐问题定义。这一步 AI 的角色不是动手，是提问——让它先列出五到八个「答案会改变设计」的澄清问题，尤其是范围边界和验收标准上的歧义。你逐个回答。这一步挡掉的返工，往往比后面所有优化加起来都多。

对齐之后，再让 AI 把结论完善成 spec。一个可行的做法是：把问题用大白话描述给 AI，让它先问清楚那几个关键问题，你回答完，让它用一小段话（两百字上下）总结成一份 spec 初稿。然后你逐条定稿——AI 负责起草和完善，你负责把关，因为它填的「合理默认值」未必符合你的具体场景。

最小的版本，今天就能做：花 10-15 分钟写一个 spec.md，三件事就够——这次要做什么、有哪些约束（技术栈、不能动的地方、边界）、怎么判断做完了做对了。把这个文件给 AI 先读，再动手。

很多时候，光是写这个文档的过程，你就会发现需求本身没想清楚。这是好事，把问题暴露在写代码之前，而不是之后。

更完整一点的，是把 spec 写成三段：需求要什么、架构怎么取舍、任务怎么拆。但别在这上面加戏——改个按钮颜色也要走一遍完整流程，那是在给自己制造仪式感，下一回真正需要 spec 的复杂需求，反而没人愿意写了。

还有一条容易被忽略：spec 要短。一份能在一屏内读完的 spec 才有人维护，五十页的需求文档从出生那一刻就开始漂移。把任务切到「一个 session + 一个能 review 完的 diff」的量级，先按第一个任务实现，别等整份 spec 写完；现实和设计对不上的时候，回头改 spec，而不是硬撑。

业务约束怎么变成测试和验证

spec 最实的价值，是它能把业务约束直接转成测试，而测试就是验证 AI 代码对不对的机器可读标尺。这一环，恰恰是 vibe coding 完全没有的。

关键是约束要写成「可测试」的形式。「系统要快、要安全」这种话，AI 没法照着写，也没法照着验。换成结构化的写法就不一样了：登录响应 p95 在 200 毫秒内；密码用 bcrypt cost 12 哈希；连续失败 5 次锁号 15 分钟。每一条都能直接变成测试，错了就 fail。

这里有个容易被忽略的坑：测试不能让「写代码的那个 agent」自己来写。让 AI 给自己的代码写测试，它会写出一堆同义反复的测试——测的是「代码做了代码做的事」，永远能过。这就好比让承包商既写施工、又写验收报告。有数据说话：AI 自己生成的测试里，同义反复率能从 35% 降到 5-10%，前提是测试从 spec 派生，而不是让 agent 临场发明。

更进一步的玩法是属性测试。不写「输入 X 期望 Y」这种单个例子，而是定义一条性质：对任何有效输入，结果必须满足某个不变量。系统自动生成几百个随机输入去撞这条性质，撞不破就说明实现是对的。对 AI 生成的代码尤其有用——你没法穷举它的边界，但性质测试能替你把边界试一遍。AWS 拿这个做大型机迁移，把几十年的 COBOL 业务规则写成性质，验证重写后的服务在成千上万个随机输入下行为不变。

当一条性质测试失败时，它会自动缩小到一个最小的反例，直接指回对应的那条业务约束。这时候你能立刻判断：是实现错了，还是当初 spec 写错了。这种「失败一定找得到源头」的确定性，是 vibe coding 给不了的。

该用哪个，看三件事

别先问「哪种更先进」，先问三件事。

第一，不确定性在哪。不确定「用户要什么界面」，vibe 最合适；不确定「业务规则到底是什么」，先写 spec 别写代码。

第二，做错的破坏半径多大。改个文案，vibe 就好；改订单状态流转，哪怕你很熟业务，也该有可对照的规则。

第三，要不要留下能复用的资产。Demo 可以不留，一次探索性重构留个 commit 就行。但如果是后续还要迭代的业务，聊天记录会消失、模型会话会满、人会换——这时候 spec、测试、简短说明才是可维护的部分。

再简化成一句一刀切的话，叫「两句话规则」：如果你给人类同事写 ticket 会超过两句话，就给 AI 写 spec；如果你周五乐意把结果整个删掉，那就 vibe。

一条硬线单独拎出来：一旦碰到钱、认证、或数据写入，别犹豫，直接上 spec，而且测试先行——每条验收标准先变成一个会 fail 的测试，再让 AI 写代码。

各自的失败信号

判断自己是不是用错了，看几个信号。

vibe 用过头的信号：开始对着自己上周写的代码问「这当时是为什么这么写的」；改 bug 要先考古聊天记录；同一个 bug 修了两遍；交接时说不清哪些是刻意的设计、哪些是 AI 随手写的。

spec 用过头的信号：一个本可以半小时跑完的小功能，磨了两天需求还没写一行代码；spec 里写满了没人会真去验证的章节；代码早就改了，spec 还原封不动躺着没人管。

两条信号线指向两种最对称的错误：拿 vibe 去扛长期维护，拿 spec 去压一次性脚本。

一线工程负责人的分歧，比社区站队更有参考价值。Tiugo 的 CTO 站在「分场景」一边，认为一旦碰到大型生产环境、分布式状态、事务完整性，就需要 spec 驱动的服务间契约，原因是「还没有任何 agentic 工作流能提供生产级基础设施要求的那种确定性正确性保证」。Pegasystems 的 CTO 则提醒，两种方式都默认了一个前提——业务和 IT 已经对齐了需求，而真实企业里对齐需求本身就是最难的一步。Dataiku 的 Hannes Hapke 给出最平衡的量化视角：vibe 压缩了「到第一个 demo 的时间」，但债务、安全、可审计性是大问题；spec 保住纪律但加了开销，所以他建议 CIO 用四个指标来衡量而不是只看速度——发布时间、bug 率、重构频率、开发者满意度。

判断力才是那个词

AI 生成很便宜，人的 review 很贵。AI 单位时间生成的代码越多，确保每次生成方向正确就越重要。spec 就是给便宜生成配的方向盘。

没 spec，你开得快但没地图，AI 会把你带到某个地方，只是未必是你要去的地方。有 spec，你开得快还有地图，AI 的速度在帮你，而不是放大你的混乱。

所以问题从来不是「我该 vibe 还是该写 spec」。问题是：此刻我在探索，还是在交付。探索用 vibe，交付用 spec。知道自己每一刻在干哪件事，这就是判断力。