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

YC Vibe Coding 实战手册：别让 AI 写嗨了

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

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

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

原始材料来自 X：@Charly Wargnier（YC 相关内容整理），此处做了结构重排 + 实操补全（不加新结论，只补落地做法）。

先把误区踢走：Vibe ≠ 乱写

不是“想到哪写到哪”。
不是“让模型一次性生成一个系统”。
不是“靠工具自带的撤销/回滚保命”。

Vibe Coding 的门槛在于：

拆需求的能力要更强（不然 AI 一口吃成胖子直接噎死）
版本控制要更干净（不然错误会像雪球一样滚）
测试要更上层（不然修一个点，另外两个点悄悄炸）

0）一张总览：把 AI 的“熵”关进笼子

把开发过程拆成 3 个回路：

计划回路：写清楚要做什么、怎么做、先后顺序
执行回路：AI 只负责在“小范围”内产出代码
校验回路：用 Git + 测试把偏航拦下来

这三个回路不跑顺，工具再贵都救不了。

1）规划：先写文档，再写代码（真的）

最常见的翻车姿势：一上来就让 AI 生成代码，然后在错误上继续迭代，最后得到一坨“看起来能跑、实际没人敢动”的东西。

更稳的做法是：先让 AI 写计划，但计划必须由人来“砍”。

1.1 用 Markdown 做一份可勾选的实现计划

建议格式（关键是可追踪、可切片）：

# Feature: xxx

## Goal
- ...

## Non-goals (Won't do)
- ...

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

## Acceptance
- ...

## Notes
- ...

Goal：一句话定义这次要达成什么（别写愿景）
Won’t do：主动砍掉“看着很香但会拖死进度”的功能
Acceptance：用用户行为描述验收（为后面的 E2E 测试埋点）

1.2 精简与修剪：复杂的功能先标红

AI 生成能力强，但“系统性风险控制”弱。

一旦 feature 牵扯：权限、资金、并发、跨服务一致性……先别硬上。

做法很简单：

直接写进 Won't do
或者拆成“先能用”的最小版本（不换结论，只换路径）

1.3 小步快跑：按章节推进，不要一次性要整套

让 AI 写一个模块可以；让 AI 写一个系统，基本等于买彩票。

实践建议：

一次只做一个 checklist item
每次只让 AI touch 少量文件
走到新岔路口，就回到文档改计划

1.4 进度追踪：每完成一步，就打勾 + 立刻提交

这一步看起来“啰嗦”，但它就是稳定性的来源。

完成一个功能点 → 文档勾选 → Git commit
commit 信息写清楚：做了什么、影响什么

AI 产出越快，越需要你用“颗粒度”去控风险。

2）版本控制：Git 才是救命绳，不是工具的撤销按钮

有些人对 Git 没洁癖，但一用 AI 就必须有。

因为 AI 的错误不是“写错一行”，而是“写错一片”，还会带着你继续错。

2.1 分支要干净：每个新功能从干净状态开始

建议习惯：

每个 feature 一个分支
分支起点必须是可运行、可测试的状态

别把希望寄托在 IDE 的 revert。

2.2 及时止损：模型开始“神游”，直接回滚

当 AI 出现这些征兆：

开始编接口/编参数
改了 A 却顺手把 B 重写了
反复解释但越修越偏

不要争论，直接：

git reset --hard HEAD

硬一点，省时间。

2.3 拒绝在烂代码上打补丁

修一次失败就继续补丁，最后就是“补丁叠补丁叠补丁”，全靠运气维持。

正确姿势：

修复失败 → 回滚到上一个确定正确的点
换提示词/换方案/换模型
重新来一遍

这不是浪费，是在买稳定。

3）测试与修 Bug：别被“单元测试”困住

Vibe Coding 场景下，最大的问题不是“某个函数错了”，而是“改动的外溢效应”。

所以要优先抓住用户路径。

3.1 优先做高层级测试：E2E/集成比单测更值

单测能保局部，但 AI 最喜欢在你没注意的地方“顺手优化”。

因此更推荐：

先把核心用户流程写成 E2E
让测试模拟真实点击/输入/跳转

这类测试的价值是：只要用户链路没断，内部怎么重构都不慌。

3.2 用自动化当守门员：防止回归

LLM 很常见的操作是：

修 A 的同时，把 B 改坏
或者为了让测试过，动了你没要求它动的逻辑

解决办法不玄学：

核心链路必须有自动化
每次生成/改动后跑一轮
让测试决定“能不能合并”，而不是靠肉眼

3.3 换模型思路：卡住就换“脑子”

当一个模型进入死循环：

同样的错误反复出现
解释听起来合理，但代码一直不对

直接切换模型（例如 Claude ↔ GPT-4）。

很多时候不是你表达不清楚，是它的推理路径卡住了。

4）AI 工具优化：让规则长在项目里，而不是长在脑子里

你不可能每次都靠对话把规范说全。

所以把“团队共识”写进文件，让 AI 每次都能读到。

4.1 指令文件：把规范写死（.cursorrules / claude.md）

指令文件的作用：

限制 AI 的改动范围
统一代码风格
固化工程约束（目录结构、命名、提交策略）

示例（可按项目改）：

# Project Rules

- Do not change unrelated files.
- Keep functions small and pure.
- Prefer existing patterns in /src.
- Add/adjust E2E tests when behavior changes.
- If unsure, ask for clarification instead of guessing.

重点不在内容多，而在“每次都生效”。

4.2 本地化文档：把 API 文档放进仓库

很多错误来自：

在线搜索到过期文档
或者模型凭训练记忆瞎补

更稳：

把关键 API/SDK 文档下载进 docs/
让 AI 在本地文件里找答案

这会显著减少“编出来的参数”。

4.3 双持策略：工具各干各的活

有些人会同时开：

Cursor：偏“写得快、改得快”
Windsurf：偏“想得深、总结强”

核心不是信仰哪个工具，而是把它们当不同岗位：

一个当码农
一个当架构师/Reviewer

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

AI 的能力很吃“训练数据覆盖”。

5.1 老牌框架对 AI 更友好

像 Ruby on Rails 这种沉淀久、资料多的体系，对 AI 更友好：

常见坑在互联网上被踩过无数次
模型更容易给出靠谱的套路

选择新潮但冷门的东西，等于让 AI 在黑箱里摸索。

5.2 避开巨型文件：模块小，模型脑子才清醒

AI 的上下文是有限的。

文件越大：

它越容易漏细节
越容易“重写一段不该重写的逻辑”

实践建议：

拆小模块
每次改动控制影响面
让关键逻辑更可定位、更可测试

6）续写：把这套方法变成“每日可复用的工作流”

上面是原则，下面是能直接照着做的节奏。

6.1 开工前 10 分钟：先把边界钉死

开工前做三件事：

选一个最小任务（能在 30~90 分钟内完成）
写进计划文档（含 Won't do）
明确“验收动作”（用户会点什么、看到什么）

这三步做完，再开 AI。

6.2 一次对话只解决一件事：别开“全能许愿池”

给 AI 的任务建议写成这样的结构：

目标：只改某个行为
限制：只允许改哪些文件
输出：需要补哪些测试
失败策略：不确定就先问

示例提示词（按项目改写即可）：

Task: Implement <feature> following the plan in docs/plan.md.
Constraints:
- Only modify files under src/<module>.
- Do not refactor unrelated code.
- If the plan is unclear, ask before coding.
Tests:
- Add/adjust E2E tests for the acceptance criteria.

这类提示词的价值是“控熵”：限制范围，减少发散。

6.3 每个 checklist item 的标准闭环

每次完成一个小步，都走同一个闭环：

生成/修改代码
跑测试（至少跑关键链路）
文档打勾
Git commit

缺一项都容易出事。

6.4 处理翻车：三种“立即止血”的动作

回滚：先回到干净状态再说
缩小任务：把任务再拆一半
换模型：换一个推理路径

别让 AI 陪着在一个坑里挖 2 小时。

6.5 团队协作补丁：让每个人都在同一套规则里

多人协作时，建议把下面内容写进仓库：

claude.md / .cursorrules（统一约束）
docs/plan-template.md（统一计划模板）
docs/testing-guide.md（统一测试优先级：先 E2E 再单测）

这样新人上手不会靠口口相传，AI 也不会各写各的风格。

7）一页速查清单（复制就能用）

开始前

有一份 Markdown 计划（含 Won’t do）
任务被拆成 30~90 分钟的小步
验收动作写清楚（为 E2E 服务）

开发中

每次只做一个 checklist item
只改小范围文件
模型开始神游就回滚

收尾

跑过关键链路测试
文档打勾
Git commit（信息清晰）

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