Vibe Coding：写着看，看着写

共计 6207 个字符，预计需要花费 16 分钟才能阅读完成。

有个朋友，他吐槽现在很多人写代码像在“打碟”：想到一个功能，先把提示词丢给 AI，几分钟后页面已经能点、能看、能演示了。至于目录结构规不规范、命名是不是优雅、状态管理该不该抽层，这些问题往后放。
我听完第一反应不是反感，反而觉得这个描述挺准确：这几年不少项目，的确就是这么开始的。

这类写法后来被很多人统称为 Vibe Coding。它不算什么新技术，也不是严肃的软件工程方法，更像是一种开发状态：先顺着感觉把东西做出来，再看它值不值得被认真维护。

它的迷人之处在于速度，它的问题也恰恰出在速度。你能很快把一个想法推到用户面前，也很容易在几天之后发现，自己面对的是一团“能跑，但不太想再碰”的代码。

图 1：一个常见的 Vibe Coding 流程：先描述想法，快速生成原型，边跑边改，最后再决定要不要工程化。

它到底是什么

如果一定要给 Vibe Coding 下一个定义，我更愿意这么说：

它不是“随便写代码”，而是把“先启动”这件事放到了比“先设计完整”更高的位置。

过去做一个小项目，很多人会先想技术栈、目录结构、数据库表、接口规范。现在的顺序变了：先把页面跑起来，先让按钮能点，先让数据能流动，先看这个想法到底有没有意思。

这背后不是开发者忽然不讲究了，而是工具变了。AI 把“从一个念头到一个可演示页面”的距离，压缩到了前所未有的程度。很多以前要花半天才能起步的事情，现在几十分钟就能看见雏形。

为什么它这两年特别有存在感

一个很现实的原因是：大多数项目不是死在实现阶段，而是死在根本没开始。

你原本想做一个小工具，结果一想到要搭环境、选框架、配路由、想数据结构，热情先掉了一半。Vibe Coding 吸引人的地方，就是它把“开始”的阻力降得很低。你不需要先证明自己有完整方案，只需要先把那个朦胧的念头拎出来。

还有一个原因是，它很符合今天独立开发和小团队试错的节奏。很多时候你并不需要一个完美系统，你需要的只是一个足够真实的版本，拿去看用户反应、看老板态度、看自己还有没有继续做下去的欲望。

图表一：Vibe Coding 和传统开发有什么不同

维度	传统开发起手式	Vibe Coding 起手式
第一件事	先定结构和边界	先把东西跑起来
目标	可维护、可协作、可扩展	快速验证想法是否成立
节奏	前期慢，后期更稳	前期快，后期容易返工
适合场景	正式业务、多人协作、长期项目	原型、MVP、活动页、小工具
最大风险	起步重，容易还没做就放弃	越写越乱，后期不好收拾

这张表里最关键的一点，不是哪个更先进，而是 它们解决的根本不是同一个问题。

传统开发解决的是“项目怎么活得久”；Vibe Coding 解决的是“项目到底值不值得出生”。

图 2：这不是一张统计图，而是一张示意图。它想表达的是两种开发方式在启动成本、反馈速度、维护压力和工程规范上的重心差异。

它为什么让人上头

因为反馈太快了。

你说“给我一个极简的待办页面”，几秒钟后就有结构；你说“这个按钮不够轻，换成更有产品感的样子”，它马上变；你说“再像一点真实产品，不要像作业”，它又会给你一版新的结果。这个过程很像和一个反应极快的搭档一起做东西，脑子里的想法几乎没有损耗地出现在屏幕上。

这种快感会让人误以为自己已经完成了开发，实际上你只是完成了“表达”和“试验”这一步。真正麻烦的，往往是后面那些不那么有成就感的工作：命名、拆分、测试、异常处理、权限、性能、兼容性。

所以我一直觉得，Vibe Coding 最大的优点不是“帮你少写代码”，而是 帮你尽快知道这东西值不值得继续认真写。

一个更具体的例子：做一个灵感待办板

我们不谈大而空的概念，直接看一个小例子。需求很简单：

做一个“灵感待办板”，支持新增、完成、删除，并把数据保存在本地。

用 Vibe Coding 的方式，最自然的起手不是上来就建一套复杂工程，而是先写一个能跑的版本。下面这份代码就是这种思路的典型样子：结构简单、反馈直接、足够完成验证。

1）HTML：先把页面骨架立起来

<!DOCTYPE html>
<html lang="zh-CN">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>Vibe Todo</title>
  <link rel="stylesheet" href="style.css" />
</head>
<body>
  <div class="app">
    <h1>Vibe Todo</h1>
    <p class="desc"> 把一闪而过的想法，先接住。</p>

    <div class="input-group">
      <input id="todoInput" type="text" placeholder="输入你的灵感或任务..." />
      <button id="addBtn"> 添加 </button>
    </div>

    <ul id="todoList"></ul>
  </div>

  <script src="app.js"></script>
</body>
</html>

这段结构的重点只有一个：别想太多，先把页面放出来。
输入框、按钮、列表容器，已经足够承载这个原型最核心的交互。

2）CSS：不用复杂，但要有点“产品感”

* {box-sizing: border-box;}

body {
  margin: 0;
  font-family: "PingFang SC", "Microsoft YaHei", sans-serif;
  background: linear-gradient(135deg, #f5f7fa, #e4ecfb);
  min-height: 100vh;
  display: flex;
  align-items: center;
  justify-content: center;
  color: #333;
}

.app {
  width: 92%;
  max-width: 520px;
  background: rgba(255, 255, 255, 0.9);
  border-radius: 18px;
  padding: 28px;
  box-shadow: 0 12px 35px rgba(0, 0, 0, 0.08);
  backdrop-filter: blur(8px);
}

h1 {
  margin-top: 0;
  margin-bottom: 8px;
  font-size: 32px;
}

.desc {
  margin-top: 0;
  margin-bottom: 20px;
  color: #666;
}

.input-group {
  display: flex;
  gap: 10px;
  margin-bottom: 20px;
}

input {
  flex: 1;
  padding: 12px 14px;
  border: 1px solid #d8e0ef;
  border-radius: 12px;
  outline: none;
  font-size: 15px;
}

input:focus {
  border-color: #7aa2ff;
  box-shadow: 0 0 0 3px rgba(122, 162, 255, 0.15);
}

button {
  border: none;
  background: #4f7cff;
  color: white;
  padding: 0 18px;
  border-radius: 12px;
  cursor: pointer;
  transition: 0.2s ease;
}

button:hover {transform: translateY(-1px);
  opacity: 0.95;
}

ul {
  list-style: none;
  padding: 0;
  margin: 0;
}

li {
  background: #f8fbff;
  border: 1px solid #e6eefc;
  padding: 14px 16px;
  border-radius: 12px;
  margin-bottom: 12px;
  display: flex;
  align-items: center;
  justify-content: space-between;
}

li.done span {
  text-decoration: line-through;
  color: #999;
}

.actions {
  display: flex;
  gap: 8px;
}

.actions button {
  background: #eef3ff;
  color: #3d5fd6;
  padding: 8px 12px;
}

.actions button.delete {
  background: #fff1f1;
  color: #d9534f;
}

这里没有什么炫技，重点是让页面在第一眼看上去不像“刚从教程里复制出来的练习题”。毛玻璃、圆角、留白、聚焦态，这些细节都不复杂，但它们决定了一个原型有没有“像产品”的感觉。

3）JavaScript：先闭环，再谈优雅

const todoInput = document.getElementById("todoInput");
const addBtn = document.getElementById("addBtn");
const todoList = document.getElementById("todoList");

let todos = JSON.parse(localStorage.getItem("vibe_todos")) || [];

renderTodos();

addBtn.addEventListener("click", addTodo);

todoInput.addEventListener("keydown", function (e) {if (e.key === "Enter") {addTodo();
  }
});

function addTodo() {const text = todoInput.value.trim();

  if (!text) {alert("请输入任务内容");
    return;
  }

  const newTodo = {id: Date.now(),
    text,
    done: false
  };

  todos.unshift(newTodo);
  saveTodos();
  renderTodos();
  todoInput.value = "";
}

function renderTodos() {
  todoList.innerHTML = "";

  todos.forEach(function (todo) {const li = document.createElement("li");

    if (todo.done) {li.classList.add("done");
    }

    li.innerHTML = `
      <span>${todo.text}</span>
      <div class="actions">
        <button onclick="toggleTodo(${todo.id})"> 完成 </button>
        <button class="delete" onclick="deleteTodo(${todo.id})"> 删除 </button>
      </div>
    `;

    todoList.appendChild(li);
  });
}

function toggleTodo(id) {todos = todos.map(function (todo) {if (todo.id === id) {return { ...todo, done: !todo.done};
    }
    return todo;
  });

  saveTodos();
  renderTodos();}

function deleteTodo(id) {todos = todos.filter(function (todo) {return todo.id !== id;});

  saveTodos();
  renderTodos();}

function saveTodos() {localStorage.setItem("vibe_todos", JSON.stringify(todos));
}

这段代码有几个很典型的 Vibe Coding 特征：

不用框架，先把基本交互闭环跑通。
用 localStorage 顶掉数据库，先解决“能不能用”。
每次修改数据后直接重渲染，逻辑直白，原型阶段完全够用。

如果站在工程化角度看，它当然不算完美：事件绑定可以更规范，渲染可以更细，结构也还能继续拆。但对原型来说，它已经完成了最重要的任务：让一个想法在最短时间内变成了可操作的东西。

图表二：一个项目从“凭感觉”到“能维护”通常怎么走

阶段	关注点	典型动作	产出
想法阶段	先证明值不值得做	对 AI 描述需求，快速出界面	可演示原型
试用阶段	先看体验顺不顺	改交互、改文案、改视觉	第一版可用产品
确认阶段	决定要不要长期维护	拆结构、补状态管理、补异常处理	稳定版本
工程化阶段	让它能继续长大	测试、权限、性能、协作规范	正式项目

你会发现，Vibe Coding 真正舒服的地方主要集中在前两段；而真正麻烦、也真正体现水平的，往往是后两段。

图 3：越往后走，“感觉”占比越低，“结构”和“约束”占比越高。能把这两个阶段接上，才算真正会用 Vibe Coding。

它适合什么，不适合什么

我不太喜欢把一种开发方式说成“未来一定全面取代另一种方式”。Vibe Coding 不是银弹，它只是特别适合某些问题。

很适合

独立开发者做 MVP
活动页、工具页、展示页
产品想法验证
后台雏形、运营工具、内部小系统
需要快速拿结果的短周期项目

不太适合直接一路冲到底

支付、鉴权、隐私数据相关系统
权限复杂、流程复杂的后台
多人长期协作项目
对可维护性和可测试性要求很高的业务
一开始就要承受复杂约束的正式系统

说得更直白一点：它很适合帮你把门踹开，但不适合替你把整栋楼盖完。

真正容易出问题的，不是“用 AI 写代码”，而是误判阶段

很多人不是不会写，而是分不清自己现在到底处在什么阶段。

原型阶段，本来就应该快一点、粗一点、直接一点；但当项目已经确定要上线、要协作、要长期维护时，你还继续沿用原型思路，问题就来了。目录开始混乱，状态开始到处飞，组件越来越大，谁也不敢改，最后每加一个功能都像在拆炸弹。

所以 Vibe Coding 最该记住的一句话不是“先做再说”，而是：

先做出来，然后尽快决定：这是玩具、样品，还是产品。

这个判断一旦做错，后面所有成本都会翻倍。

如果你也想试，提示词可以这么写

与其给 AI 下很多空泛的命令，不如把需求说得具体一点。比如：

请帮我做一个极简风格的待办网页，使用 HTML + CSS + JavaScript 原生实现。实现需求：**************       
1. 可以添加任务
2. 可以标记完成
3. 可以删除任务
4. 数据保存到 localStorage
5. 页面风格简洁、现代，不要像练习作业
6. 代码拆分为 index.html、style.css、app.js
7. 给核心逻辑写清楚注释

这个提示词好用，不是因为它专业术语多，而是因为它把 功能、风格、边界和输出格式 都说清楚了。AI 其实不怕你说得多，它更怕你说得空。

最后

我现在越来越觉得，Vibe Coding 最有价值的地方，不是替代开发者，而是把开发者从“迟迟不开始”这件事里拽出来。它让你先看到东西，再决定要不要认真做下去；先得到反馈，再决定值不值得投入更多时间。这种能力，对今天的个人开发者、小团队、内容产品、甚至很多传统公司里的试验项目，都非常有用。

但它真正考验人的地方也在这里：当你已经确认这件事值得做，能不能及时从“凭感觉冲刺”切回“按工程落地”。会用 Vibe Coding 的人很多。知道什么时候该停下来收拾战场的人，其实没那么多。而后者，往往更重要。