Vibe Coding：把想法聊成产品的方法论

01

概念起源：一条推文引爆的编程方式

2025 年 2 月 2 日，Andrej Karpathy（OpenAI 联合创始人、前 Tesla AI 总监）在 X 上发了一条推文：「有一种新的编程方式，我称之为 vibe coding——完全交给感觉，拥抱指数增长，忘记代码的存在。」原话里有半开玩笑的成分（他自嘲连 try-except 都懒得看、把报错直接截图丢回给模型），但这个词准确命中了正在发生的事：当模型强到能独立写出能跑的程序时，你贡献的不再是语法，而是意图与判断。

几个月内这个词从梗变成了行业通用词：媒体用、工具厂商用、Wikipedia 收了词条。它的内涵也分化出两个层次——狭义的 vibe coding 是 Karpathy 原始版本：不看代码、只看结果，快乐至上；广义的工作流 则是今天大多数人的用法：用自然语言驱动 Agent 干活，但保留 review、测试和版本控制。本页教的是后者——前者只适合玩具，后者才拿得出手。

它也一直伴随批评：批评者说这个词在鼓励「不读代码就上线」。两种理解都对了一半——vibe coding 的风险不在「用 AI 写代码」，而在跳过验证。这一页的整个方法论，本质上就是把 Karpathy 的快乐原教旨主义，改造成能对结果负责的工程实践。

提出者

Andrej Karpathy

提出时间

2025-02-02（X 平台推文）

原话关键词

give in to the vibes / forget the code

本质

自然语言驱动，意图即接口

最适用

原型 / 个人工具 / 一次性脚本

不适用

生产核心系统裸上（无 review）

前置条件

一个编码 Agent + Git 仓库

本页立场

交出键盘，不交出判断

02

搭工作台：能跑、能测、能回滚，一个都不能少

vibe coding 对环境只有三个硬要求：改动可回滚（Git）、结果可验证（能跑起来 / 有测试）、有个听得懂人话的 Agent。前两条没有，后面全部方法作废；第三条三选一装一个就够——本站都有对应教程，命令如下。

# 官方脚本：下载独立二进制，不依赖 Node
curl -fsSL https://claude.ai/install.sh | bash

# 或 npm（需要 Node ≥ 18）
npm install -g @anthropic-ai/claude-code

claude --version

# npm（包内是预编译 Rust 二进制）
npm install -g @openai/codex

# 或官方脚本
curl -fsSL https://chatgpt.com/codex/install.sh | sh

codex --version

# 官方脚本（macOS / Linux）
curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash

# 或 Homebrew
brew install kimi-code

kimi --version

# 1. 每个新项目都从 Git 开始——这是你的后悔药
mkdir ~/my-idea && cd ~/my-idea
git init && git commit --allow-empty -m "baseline"

# 2. 先想好「怎么跑起来」：网页就留个 index.html，
#    脚本就留个入口文件，Node 项目就 npm init -y
node --version  # 或 python3 --version，跑什么都行

三个硬要求之外，还有一个软性的选型口径：在真仓库里干活选终端 Agent（改的是你已有的代码，需要读写文件、跑测试的完整能力）；局部修补、边写边补选 AI IDE；从零起一个界面原型选网页生成器。选错的代价不是做不出来，而是来回搬运上下文——工具跟场景匹配，迭代才不累。

03

第一次 vibe：从一个想法到能跑的东西

以「做一个统计 Markdown 字数的小工具」为例，第一次完整走一遍循环：说清楚 → 让它做 → 跑起来 → 反馈 → 验收。工具就用 s2 装好的任意一个，下面以终端 Agent 通用流程演示。

cd ~/my-idea
git status          # 干净的基线，随时能回滚

# 启动你的 Agent（claude / codex / kimi 任一）

> 用 Node 写一个 CLI 工具 wc-md.js：
  1. 传入 markdown 文件路径，输出词数和预计阅读时长（按 200 词/分钟）
  2. 用 node:test 写两个测试：中文、中英混排
  3. 跑通测试后把输出贴给我

# 它写完代码、跑完测试、报告结果后：
node --test
node wc-md.js README.md

# 验收通过，立刻落袋为安
git add -A && git commit -m "feat: wc-md 统计工具第一版"

# 差：愿望式，输出全凭运气
> 做个字数统计工具

# 中：给了实现路径，但没给验收
> 用 Node 写个脚本统计 markdown 字数

# 好：路径 + 验收 + 边界，一次对齐
> 用 Node 写 wc-md.js：传文件路径，输出词数和阅读时长。
  代码块不计入；空文件不报错；用 node:test 覆盖这两条；
  零依赖；跑通测试后贴输出给我。

• 01

  需求说成「可验收」的话

  「做个字数统计」是愿望；「传入文件路径，输出词数和阅读时长，测试覆盖中文和混排」才是任务。把输出格式、边界情况写进提示词，返工次数直接减半。

• 02

  让它跑，别只让它写

  明确要求「跑通后贴运行结果」。Agent 自己跑过一遍，你拿到的就不是「应该能跑」的代码，而是验证过的结果。

• 03

  反馈要具体，一次一个问题

  报错就贴报错，不对就描述期望与实际的差距。「不行，重写」是最差反馈——AI 只能再掷一次骰子。

• 04

  每个验收点提交一次

  跑通了就 git commit，别攒。提交信息说清楚这一步干了什么，下轮回滚、下下轮回看 diff 都靠它。

04

核心方法：小步、验收、先计划、后审查

小步提交：把大赌注拆成一串小赌注

一次性描述 10 个需求，等于把 10 个赌注押在一个提示词上——错一个，后面的全建立在错误地基上。正确姿势是把任务切成每步都能验证的小块：先让 CLI 能跑，再加参数解析，再补测试，再管错误处理。每步一个提交，每步都有 git 兜底。步子小到什么程度？小到你 30 秒能判断这步对不对。

git log --oneline
a1b2c3d feat: wc-md 支持 --top 参数统计高频词
e4f5a6b test: 补中文混排边界用例
7c8d9e0 fix: 剥离围栏代码块再统计
1f2e3d4 feat: wc-md 第一版，测试覆盖中文与空文件
0a1b2c3 baseline: empty repo

每个提交对应一次「AI 干活 → 你验收」。哪一步引入了问题，git log 一眼定位，git revert 精准撤销——这就是把赌注拆开之后的止损粒度。

验收标准先行：把「好」写成可检查的句子

完成定义（全部满足才算完）：
1. node wc-md.js <文件> 输出词数与分钟数
2. 围栏代码块内容不计入字数
3. 空文件输出 0，不报错
4. node --test 全绿
5. 不引入任何第三方依赖

验收标准的本质是把判断权留在你手里：AI 负责实现，你负责判定。没有验收标准，「完成」就变成它的自由发挥；有了验收标准，完成与否一句话就能机器判定——这也是后面让测试兜底的前提。

让 AI 先出计划：Plan 是最便宜的迭代

超过三步的任务，先要求「先给计划，我确认后再动手」。现在的终端 Agent 基本都有 Plan 模式（Claude Code、Codex、Kimi Code 都有，通常 Shift-Tab 切换）：它只读代码、列步骤、标出要动哪些文件，一个字不写。计划错了改一句话就行，代码错了就得整个回滚——在计划层迭代的成本是代码层的几十分之一。计划批准后，再把大计划拆成小步提交执行。

> 任务：给 wc-md 加一个 --top N 参数，输出高频词。
不要写代码，先给我实现计划：
1. 要动哪几个文件、各改什么
2. 有没有更简单的替代方案，为什么选这个
3. 拆成几个可独立验收的小步骤
我确认后你再动手。

跑测试、读 diff：质量控制的两道闸

「有测试就跑测试，没测试就让它补测试」——测试是你和 AI 之间最可靠的沟通协议：验收标准写进测试用例，模型每次改动自己就能回归。第二道闸是读 diff：git diff 之后肉眼过一遍改动，重点看三样——有没有改它不该改的文件、有没有为绕过问题留下的怪代码、有没有硬编码的魔法值。diff 是 AI 全部工作的诚实记录，读它比读全量代码快得多。

05

速查表：贴在手边的四张卡片

下面这块表格能搜。搜 提交、模板、密钥 之类的词试试。

06

实战：完整 vibe 一个「Markdown 字数统计」CLI

把 s3 的例子走完整。目标是拿到一个有测试、有提交历史、随时可回滚的小工具——重点不在工具本身，而在每一步的方法论动作。全程约 30 分钟。

第 1 步：立基线，写需求卡

mkdir ~/md-stats && cd ~/md-stats
git init
git commit --allow-empty -m "baseline: empty repo"

> 用 Node 写 CLI 工具 wc-md.js。先复述需求、列歧义点，确认后再写码。

目标：node wc-md.js <文件.md> 输出「词数 + 预计阅读分钟数（200 词/分钟）」

验收标准：
1. 围栏代码块（```…```）内容不计入
2. 中文按字计，英文按空格分词
3. 空文件输出 0 词，不报错
4. 用 node:test 写测试，覆盖以上三条，先跑给我看
5. 零第三方依赖，单文件实现

注意三件事：要求复述需求（对齐先于实现）、验收标准可机器判定、圈定了边界（零依赖、单文件）。

第 2 步：第一轮生成 + 验收

node --test                    # 测试是绿的？
node wc-md.js README.md        # 输出符合预期？
node wc-md.js empty.md         # 边界用例亲手试一个

# 全过 → 落袋为安
git add -A && git commit -m "feat: wc-md v1，测试覆盖中文与空文件"

第 3 步：典型报错的迭代

真实世界里第一版几乎总有边界问题。假设你贴了一篇带代码块的文章，字数虚高：

node wc-md.js post.md
# 输出 2100 词 —— 明显把代码块算进去了

> post.md 里的围栏代码块被计入了（2100 词，人读约 1700）。
  修法：解析前剥离围栏代码块。给「含代码块」补一个测试用例，
  先红后绿，跑通贴结果。

# 它改完：
node --test && node wc-md.js post.md   # 全绿，数字对上了
git diff                                # 肉眼确认：只动了 wc-md.js 和测试
git add -A && git commit -m "fix: 剥离围栏代码块再统计"

反馈包含三要素：现象（2100 vs 期望 1700）、假设的根因、验收方式（先红后绿）。不贴「数字不对你看看」这种让它猜的话。

第 4 步：读 diff，发现「偷懒式修复」

读 diff 时最该警惕的是它绕过问题而不是解决问题：删测试让套件变绿、放宽断言、加 try-except 吞掉报错。看到这类改动，直接打回：「这是掩盖不是修复，回到根因。」如果三轮修不好一个点，别硬磨——git reset --hard 回到上一个好提交，换一种方案重新谈，往往比第五轮追问更快。

第 5 步：把重复的部分沉淀下来

这个工具做完你会发现：需求卡的结构、先红后绿的要求、读 diff 的动作，每次都一样。把「怎么跟你协作」也沉淀下来——写在仓库的 AGENTS.md 里，或更进一步做成可复用的技能（本站 Skills（技能）教程 有完整做法）。第一次 vibe 交付的是工具，第二次起，交付的还有你和 AI 的协作协议。

git log --oneline | wc -l      # 5 个提交，一步一个验收点
node --test                    # 测试全绿，回归有保障
ls                             # wc-md.js + 测试文件，零依赖

07

避坑：四个最贵的错误

坑一：不看 diff 就合并

git status --short    # 改动文件清单：有没有不该动的？
git diff --stat       # 改动量：几十行的小事改出 800 行？追问
git diff              # 重点看：删掉的测试、放宽的断言、硬编码的值

坑二：一个提示词想一次到位

「帮我做一个带用户系统、支付、后台管理的电商网站」——这种提示词的产出注定是好看的外壳加松动的地基。模型上下文有限、注意力稀释，一次塞得越多，每部分质量越差。拆成「先跑通骨架 → 再加模块 A → 再加模块 B」，每步验收、每步提交，总耗时反而更短。

一个实用的自测：把你写好的提示词里的需求逐条编号，超过三条就拆开分轮发——第一轮只留「最小能跑」的那条，其余的作为后续轮次的任务清单。你要的不是一个巨大的回复，而是一串你都能看懂的、每步可回滚的小改动。

坑三：把密钥和敏感数据聊进提示词

• 永不进入提示词：API Key、数据库密码、.env 文件内容、生产数据、客户资料。
• 谨慎进入提示词：未公开的商业代码、内部文档、带真实用户信息的日志。
• 安全做法：密钥放环境变量或密钥管理器；示例数据先脱敏；让 AI 写「读取配置」的代码而不是替你保管配置。

坑四：报错了追着聊，越聊越歪

git status              # 看看现在被改成了什么样
git reset --hard HEAD   # 回到上一个好提交（确认没有要保留的改动）

> 刚才的方案修不动这个问题。换个思路：
  用 <另一种方案> 重新实现，先讲方案再动手。

同一问题修三轮没好转，继续追问大概率是在错误方向上加注——模型会顺着会话里的错误假设越走越深。回滚 + 换策略 + （必要时）开新会话，是把 vibe 拉回正轨的三个手动挡。

08

延伸方向与资源

• Karpathy 原始推文（2025-02-02）——概念源头，一分钟的原文胜过十篇二手解读。
• Wikipedia：Vibe coding——概念的传播史与主流定义演变。
• Claude Code 官方文档——本站配套 Claude Code 教程 之外的官方全览。
• OpenAI Codex 文档——沙箱与自动化思路的官方说明。
• OpenCode 文档——想不锁模型，从这里开始；本站配套 OpenCode 教程。
• v0——网页生成路线代表，起 UI 原型最快的一档。

09

收尾：照着勾一遍

0 / 5