跳到正文
WC.

一天内 vibe coding 出一个网站

•1 分钟阅读•工作流•
•
#vibe-coding#cursor#agents#productivity

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

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

带有 MDX、Zod、Next.js 和 Cloudflare 卡片的 agent 编码编辑器,表现一天建站流程。

没人说的那层转变

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 没有跳过那部分,只是让你终于能用上它。

继续阅读

先推敲想法,再开始 vibe coding

我不会在 Cursor 里开启一个新项目。我会先去 ChatGPT。 在 repo 出现之前,先有一个想法。在实现计划出现之前,通常只有一个半成形的直觉,在我脑子里听起来比它实际更聪明。我已经学会不相信那个第一版。所以现在我会把这个想法讲给一个…

•1 分钟阅读•工作流
vibe-codingcursorskills
Spec-Kit 教训:先打草稿再写 spec,先定范围再写代码

第一次用 spec-kit 时,我塞进去一段含糊的需求就点了运行。出来的 spec 技术上成立——但 practically 没用:太宽、太野心、和编码代理一次会话里能执行的东西脱节。 问题不在工具,在我的输入。 在多个项目里跑了几十次 spec-kit…

•2 分钟阅读•工作流
spec-kitagentscursor
技能中的渐进式披露

技能里塞得越多就越有用——直到不再有用。一个 SKILL.md 想把每种内容类型、每种 schema、每种语气规则都写进去,可以轻松上百行。Agent 会一次性全加载。Token 预算被烧掉,真正和当前任务相关的部分淹没在噪音里。 我设计技能时,让主文件当路由器,不当垃圾桶。它告诉 agent…

•1 分钟阅读•开发者工具
skillsagentscursor
教代理用你的口吻写作

你正在读的这篇博客是 AI 代理写的。但听起来像是我写的。 这不是巧合。我写了一个 skill——一套可复用的指令——教代理如何用我的口吻写、按我的内容 schema 来、按我会用的结构组织文章。这篇文章既是说明,也是证明。 真正的问题不是能力…

•1 分钟阅读•开发者工具
skillsagentscursor