一天内 vibe coding 出一个网站

这整个站我一天就做完了。不是落地页，不是换色的模板，而是静态导出的 Next.js 站：MDX 内容管道、Zod 校验 schema、Cloudflare Pages 部署。

我不是在批量生产样板。我是* vibe coding *出来的。这段经历改变了我对「当开发者意味着什么」的看法。

没人说的那层转变

Andrej Karpathy 用「vibe coding」形容用自然语言描述你想要什么来写软件。定义没错，但不完整：它把 vibe coding 说成一种技巧——写代码更快的方式。更有意思的是它暴露了开发者时间实际花在哪。

传统流程是：想清楚要什么 → 把想法翻成代码 → 修翻译错误 → 重构 → 重复。我这么干了多年，从没想过这个循环里有多大一块是翻译——把已经做好的决定机械地转成机器能接受的语法。

Vibe coding 把这道翻译层压到几乎为零。剩下的是思考：架构、数据流、边界情况、取舍——决定你做出来的东西好不好的是这些。

一开始会有点晕。你习惯花四小时实现一个功能，没意识到其中三小时是样板、API 调用和接线。当代理把这些活接过去，一小时搞定，你会觉得像作弊。没有。你只是不再做本来就不该你亲手做的那部分。

规格成了新瓶颈

一天建站最大的教训：输出质量的上限是规格的质量，不是模型的质量。

给代理模糊指令——「给我做个好看的 writing 页」——结果就很平庸：通用布局、占位套路、没个性。给它结构化 spec、验收标准、内容 schema、组件契约，结果才是我会直接上的那种。

这颠倒了传统的能力排序。在 pre-AI 流程里，打字最快、API 记得最多的人占优。在 vibe coding 流程里，想得最清楚的人占优。瓶颈上移了——从执行到表达。

对把身份建立在「实现速度」上的人会不舒服。但也是解放：如果你的优势是品味、判断和架构思维，vibe coding 会放大这些；如果你的优势是背 React hooks，护城河就没了。

信任问题

Vibe coding 需要一种多数开发者没被训练过的信任：信任你没逐行写出来的输出。

建站时我发现自己有个怪习惯：让代理写组件，看输出，然后在脑子里重写一遍，以确认我本来也能写出来——好像只有「我能独立写出」的代码才算有效。

这本能是错的，但值得理解。开发者几十年养成的习惯是「认识代码库的每一行」。Vibe coding 要你从作者变成负责人：你不写代码，你负责塑造它的决定；你审查、修正、批准——像不砌砖但对每面墙负责的建筑师。

实际含义：如果你说不清为什么某段生成代码是对的，就等于没审。光读代码不够，你得理解它编码的是哪条决定。

速度真正换来什么

「一天建站」听起来像炫技。重点不在这。

重点是速度腾出了什么。因为不用花几小时在脚手架和接线上，我把时间花在平时会砍掉的东西上：有层次的内容结构、动效打磨、在 build 时而不是生产时发现问题的 schema 校验、真正能用的联系表单而不是 mailto。

速度没有拉低结果，反而提高了——因为省下的时间进了质量，不只是提前收工。

很多人说 vibe coding 是「让 AI 写你代码」时就漏了这点。替代方案不是我亲手写出更好的代码，而是周末泡在样板里、周日晚上发一个半成品。代理没有降低标准，是给了我时间把标准抬高。

能力仍然关键的地方

没有品味，vibe coding 玩不转。代理可以生成你描述的任意架构——包括烂的。它会很乐意造过度工程化的组件层级、加没必要抽象、设计让以后查询痛苦的数据库 schema。它按你说的做，不按你的意思做。

在这个流程里开发者的工作不是打字，是做决定：静态导出还是服务端渲染？MDX 还是 headless CMS？Edge 函数还是传统 API？这些决定决定项目能不能撑住，没有代理替你做。

Vibe coding 的讽刺在于：它要求更多架构判断，不是更少。实现变便宜了，你可以多试几种方案——但也要多评估几种。约束从「我能不能做出来」变成「该不该做、这样做对不对」。

站是一天建的。但让这个站值得建的那些决定，是多年才形成的。Vibe coding 没有跳过那部分，只是让你终于能用上它。