图片资源未同步：未命名图片

Vibe Coding 真相：不是写爽，是控熵

“Vibe Coding（氛围编程）”这词听起来像摆烂：打开 Cursor/Windsurf/Claude，手一挥，代码自己长出来。

但 YC 这套指南讲得很直白：

核心不是写代码，而是控制 AI 的发散
真正的生产力来自流程：计划、边界、版本、测试、复盘

把 AI 当成一个“输出爆炸、但方向感不稳定”的外包队友就好—— 你负责控熵（边界 + 校验 + 回滚），AI 负责出分力（实现 +改动 +解释）。

YC 那套「Vibe Coding」被很多人误解成“开个 Cursor/Claude，然后一路自动驾驶”。

实际刚好相反：真正的核心不是敲代码，而是把 AI 当成一个高产但容易跑偏的队友，用流程把它的“发散/幻觉/自嗨”压住。

一句话翻译：你负责控熵，AI 负责出苦力。

材料来源：YC guide to vibe coding（整理自 X / @Charly Wargnier 等）

别求“自动驾驶”，求“可回滚的推进”

Vibe Coding 的目标不是一次生成一个系统。目标是：

每 30~90 分钟推进一个小步
每一步都有“边界”和“证据”（测试/日志/可运行状态）
任何时候都能一键回到上一个稳定点

这套东西看似保守，其实是给 AI 这种“高产但不靠谱”量身定制的工程学。

1）规划：先写计划，再让 AI 开工（否则就是把自己卖给随机性）

1.1 先产出一份“可执行计划”

第一步不是敲代码，而是让 AI 写一份实现计划放进 Markdown 文件里。

建议结构（关键：可切片、可追踪）：

# Feature: xxx

## Goal
- ...

## Scope
- In scope: ...
- Out of scope: ...

## Won't do (for now)
- ...

## Parking lot (ideas later)
- ...

## Plan (checklist)
- [ ] Step 1 ...
- [ ] Step 2 ...
- [ ] Step 3 ...

## Acceptance (user behaviors)
- ...

额外强调了两个点：

Maintain scope control：给“以后再做”的想法单独开一个 Parking lot，避免写着写着就加戏。
Implement incrementally：按小节推进，别试图“先把整个系统生成出来再说”。

1.2 Review & refine：计划必须被“砍”

AI 擅长把事情写大；人类要负责把事情写小。

不必要的项直接删
太复杂的功能直接标记 Won't do
边界不清的，先补充“验收动作”，再写实现

一句话：计划不是许愿清单，是约束合同。

1.3 Track progress：每完成一小节，就打勾

明确建议：实现完成后，让 AI 把对应 checklist 打勾。

这个动作的意义不在“记录”，而在让推进有节奏：

做完一个点就停一下
回头检查边界有没有被破坏
再进下一步

2）版本控制：Git 是保险箱，IDE 的 Revert 只是纸巾

2.1 Use Git religiously：每个新功能从干净状态开始

一个 feature 一条分支
分支起点必须是“可运行/可测试”的状态

别依赖工具自带撤销。AI 写错不是“一行错”，往往是“一片错”。

2.2 Reset when stuck：AI 开始“神游”，直接回滚

用词很形象：vision quest（开始走神游剧情）。

典型征兆：

开始编接口/编参数
改 A 顺手重写 B
一直解释但修复越来越偏

处理方式别温柔：

git reset --hard HEAD

该砍就砍。继续补丁只会把错误堆叠成地层。

2.3 Avoid cumulative problems：失败多次就“重来一次干净实现”

还补了一句：当终于找到正确方案时，最好 reset 然后 clean implementation。

原因很现实：

经过几轮失败修复，代码里会残留大量“为了过某个点而临时加的东西”
这些残留后面会变成隐形地雷

所以：找到正确路径后，从干净状态把它“重新走一遍”，反而更快。

3）测试：别陷在“单测崇拜”，先把用户路径锁死

3.1 Prioritize high-level tests：E2E/集成测试优先

明确：优先 end-to-end integration tests，而不是 unit tests。

原因很朴素：

AI 最爱在“你没盯着的地方”做不必要的改动
单测保局部，E2E 保用户路径

3.2 Simulate user behavior：测试要像用户一样点

把核心流程写成“有人真的在点击/输入/跳转”。

这类测试的价值是：

内部怎么重构都行
只要用户路径没断，就不会把产品写成“代码很漂亮但没人能用”

3.3 Use tests as guardrails：必要时先写测试再写实现

提到：有些 founder 建议从 test cases 开始，用测试提供清晰边界。

这不是教条，而是控熵：

先把边界写成可运行的断言
再让 AI 在这个轨道里产出代码

4）Bug 修复：最有效的提示词，往往就是“把报错粘过去”

把 bug fixing 单独拎出来，说明它在 AI 开发里是高频场景。

4.1 Leverage error messages：报错信息就是最强上下文

很多时候不需要长篇解释：

直接把 error message + stack trace + 触发步骤贴给 AI
再加一句“不要猜，给出最可能原因 + 验证步骤”

4.2 Analyze before coding：先列原因，再动手

让 AI 先输出：

可能原因列表（按概率排序）
每个原因对应的验证方法（加日志/断点/最小复现）

把“瞎改代码”改成“像工程师一样排查”。

4.3 Implement logging：战略性加日志

提到 implement logging，这点很关键：

AI 很会“修到看似没错”
但没有日志，就不知道是不是修到了真正根因

日志不是为了漂亮，是为了让系统对排查友好。

4.4 Switch models：一个模型卡住就换脑子

当某个模型持续在一个坑里打转，直接换（Claude ↔ GPT-4 等）。

很多时候不是表达问题，是推理路径卡死。

5）AI 工具优化：把规则写进文件，让 AI 每次上岗都先读员工手册

完整的一组“AI tool optimization”。

5.1 Create instruction files：.cursorrules / windsurf.rules / claude.md

把项目规范固化在文件里：

目录结构
命名约定
不允许的改动（例如：不要动无关文件）
测试策略（改行为必须补 E2E）

示例：

# AI Working Rules
- Only touch files mentioned in the plan.
- Do not refactor unrelated code.
- If unsure, ask before guessing.
- Any behavior change requires E2E update.
- Prefer small, reviewable diffs.

这不是写给人看的，是写给每次都会失忆的 AI 看。

5.2 Local documentation：把 API 文档下载进项目

把关键文档放进 docs/，让 AI 读本地文件。

好处：

避免联网搜索到过期信息
避免凭“训练记忆”编参数

5.3 Use multiple tools：多工具并行

有人会同时开 Cursor + Windsurf。

重点不是品牌崇拜，而是岗位分工：

一个负责快写快改（偏实现）
一个负责长思考/总结/复盘（偏审查）

5.4 Tool specialization：承认工具有偏科

写得很直白：

Cursor 前端更快
Windsurf 更“想得久”

不要指望一个工具全能，把它们当不同角色用更稳。

5.5 Compare outputs：多产几份方案再挑最好的

让 AI 同时给 2~3 个实现方案（或同方案不同取舍），再由人做选择。

这一步的意义：

减少“第一版就上头”
避免被模型的叙述能力绑架

6）复杂功能开发：先在“干净沙盒”做原型，再搬回主干

提到了 complex feature development 的几个关键动作。

6.1 Create standalone prototypes：先在干净代码库里做

复杂功能容易把主仓库弄脏。

更稳的策略：

新开一个干净 repo/目录做 prototype
跑通最小链路
再把可行实现搬回主项目

这样 AI 的探索不会污染生产代码。

6.2 Use reference implementations：给 AI 一份“能跑的例子”

让 AI 跟着“可工作的参考实现”走，成功率会高很多。

指向一个已验证的 demo
或者仓库里已有模块作为模板

6.3 Clear boundaries：外部 API 稳定，内部随便折腾

这句非常 YC：

外部接口保持一致
内部实现可以不断重构

这也是控熵的边界：对外稳定、对内可迭代。

6.4 Modular architecture：有边界的模块化更适合 AI

提到：service-based architecture with clear boundaries 往往比 monorepos 更好。

翻译成人话：

边界清楚，模型不容易越界改一大片
模块小，模型更容易“看全上下文”

7）技术栈选择：老框架更香，小文件更保命

7.1 Established frameworks excel：老牌框架对 AI 更友好

点名 Ruby on Rails：因为 20 年一致的 conventions，训练数据覆盖足。

延伸一下：

不是说新技术不能用
但“冷门 + 新潮 + 资料少”的组合，会把 AI 的可靠性拉到地板

7.2 Training data matters：新语言可能更吃亏

像 Rust、Elixir 这类语言，在某些领域很强，但对 AI 来说可能训练语料更少。

所以选型时要加一个维度：AI 对这套栈的熟悉程度。

7.3 Modularity is key / Avoid large files：拆小文件

强调：不要有几千行的大文件。

原因很简单：

人类 review 痛苦
模型上下文有限，更容易漏掉关键细节

模块越小，越可控。

8）Beyond coding：AI 不只写代码，它还能把杂活扫干净

额外给了“Beyond coding”的清单，这部分很适合创业/小团队。

DevOps automation：配服务器、DNS、hosting
Design assistance：生成 favicon、UI 小素材
Content creation：写文档、写营销材料
Educational tool：让 AI 逐行解释实现（用于 onboarding / code review）
Use screenshots：UI bug 直接截图丢给 AI
Voice input：像 Aqua 这类工具，语音输入速度能到 140 wpm

一句话：把 AI 当“跨职能实习生”，能省掉一堆低价值切换。

9）Continuous improvement：把 AI 开发当成一个长期系统

最后一块是持续改进，核心不是“今天写爽了”，而是“下周还能迭代”。

Regular refactoring：测试在位后，频繁重构
Identify opportunities：让 AI 找重构候选点（但由人拍板）
Stay current：新模型发布就试（别闭门造车）
Recognize strengths：承认不同模型擅长不同任务

这套思路非常现实：工具在变，流程要能承受变化。

10）一些想法与“真实体感”（不煽情，只讲工程学）

这套指南最值钱的不是某条技巧，而是它默认了一个事实：

LLM 的产出像洪水：来得快、量很大、但方向不稳定
工程体系的作用是堤坝：计划、边界、版本、测试、日志

当把“写代码”切换成“控熵”，很多情绪会消失：

不再被“它怎么又改坏了”气到上火，因为回滚是默认动作
不再被“它是不是更聪明”焦虑，因为工具只是岗位，不是信仰
不再把“写得快”当胜利，因为可回滚、可验证的推进才算赢

换句话说：Vibe Coding 并不是放弃工程纪律，而是把工程纪律提升到了更高优先级。

11）一页可复制工作流（建议直接贴进 claude.md）

# Vibe Coding Workflow

## 0. Plan first
- Write docs/plan.md with Goal, Scope, Won't do, Parking lot, Checklist, Acceptance.
- Only implement one checklist item per iteration.

## 1. Git discipline
- Work on a clean feature branch.
- Commit after each completed item.
- If stuck or AI goes off-track: git reset --hard HEAD.

## 2. Tests as guardrails
- Prefer E2E/integration tests for core user paths.
- Update tests whenever behavior changes.

## 3. Debugging
- Paste exact error messages.
- Analyze possible causes before coding.
- Add logging for observability.
- Switch models if stuck.

## 4. Boundaries
- Keep external APIs stable; refactor internals freely.
- Keep files small and modules clear.

#VibeCoding #AI编程 #Cursor #Windsurf #Claude #Git #E2E测试 #工程化