01
Vibe Coding 是什么
Vibe Coding 是什么
Vibe Coding 不是“按一下按钮，AI 自动把 product 做完”。更准确地说，它是一种新的开发协作方式：你用自然语言描述目标、约束和 acceptance criteria，让 AI 帮你生成、修改、解释和迭代代码。
很多人第一次接触它，会觉得像 magic。做过几个真实 project 后就会发现，它更像一套新的 engineering workflow。
Vibe Coding 到底在替代什么
它主要替代的是这些机械动作：
- setup 脚手架
- 写重复代码
- 在 document 和 IDE 之间来回切换
- 把一个明确的小需求手动翻译成代码
- 根据 error log 去搜一堆零散帖子
它没有替代的，是这些更值钱的动作：
- 定义目标
- 判断 priority
- 做 architecture 取舍
- validate 结果
- 对 production 风险负责
所以 Vibe Coding 的核心不是“少写代码”，而是把人从低密度劳动里抽出来，去做更像 engineer 的判断。
一眼看懂：它适合什么，不适合什么
| Scenario | 适不适合 | 原因 |
|---|---|---|
| 页面样式调整、组件补全 | 很适合 | feedback 快，容易 validate |
| CRUD、form、type 定义 | 很适合 | 规则明确，重复度高 |
| 报错排查、定位问题 | 适合 | AI 能快速做第一轮 analysis |
| 新 project prototype | 适合 | 能快速拉出第一版 |
| 支付、鉴权、权限系统 | 谨慎 | 一旦写错，后果高 |
| 核心 architecture 升级 | 谨慎 | 需要你先定方案 |
| compliance、security 敏感逻辑 | 不建议全权交给 AI | 必须人工主导 review |
一次完整的 Vibe Coding 循环
1. 先讲清楚 task
一个有效 prompt，通常至少包含四件事：
- 目标：你要做什么
- 背景：在哪个 project、哪个 file、什么业务 context
- 约束：tech stack、style、不能动的 boundary
- 验收：完成后怎么判断是对的
2. 让 AI 先出 plan，再动手
直接让 AI 上来改代码，常见结果是“改了，但方向偏了”。
先让它输出 plan，你更容易及时纠偏。
3. 小步执行，小步 validate
不要一次让 AI 改十几个 file 再一起看。
更稳的方式是：
- 改一个点
- run 一下
- 记住问题
- 带着 error 和结果继续问
4. 把好用的 prompt 沉淀下来
真正拉开效率差距的，不是谁会说“帮我写一下”，而是谁能把常用 instruction template、acceptance checklist、debug 套路沉淀成自己的 workflow。
一个新手最容易踩的坑
| 坑 | 表现 | 修正方法 |
|---|---|---|
| 需求太空 | AI 产出一堆看似合理但不对题的代码 | 写清 input、output、boundary |
| 一次改太多 | 很难定位是谁引入的问题 | 拆成 1-2 个小 task |
| 不贴错误信息 | AI 只能猜问题 | 直接贴 log、截图、调用链 |
| 只看代码不运行 | 代码“看着像对”，实际跑不通 | 每轮都 validate |
| 把 AI 当最终责任人 | 结果出错没人兜底 | 人必须保留 sign-off 权 |
给新手的第一套上手动作
如果你今天第一次试，按这个顺序最稳：
- 在一个小 project 里挑一个可验证 task
- 让 AI 先输出 implementation plan
- 再让它生成代码
- run 项目或 test
- 把 error 继续贴回去修
- 最后让它总结“下次怎么更快”
这个流程的关键，不是一次成功，而是你开始建立“提问 -> 生成 -> validate -> 迭代”的节奏感。
一个可以直接复制的 Prompt 模板
你现在在一个 [tech stack] project 里帮我完成任务。
任务目标：
[要实现的功能]
项目背景：
[相关 file、已有逻辑、dependency 限制]
约束：
- 不要改动无关 file
- 保持现有 code style
- 如果有不确定点，先给 plan 再修改
acceptance criteria：
- [功能 A]
- [功能 B]
- [test 或 run 方式]
练习
挑一个最小 task 开始：
- 写一个带参数校验的
hello函数 - 给现有 button 补 loading 状态
- 把一段重复 logic 提取成公共 function
要求自己做三件事：
- 先写清楚 acceptance criteria
- 每次只让 AI 改一个小点
- 每轮都 run and validate
外部工具建议
Cursor：更适合在 IDE 里做 multi-file 修改和 context 协作Claude Code：更适合 task 拆解、terminal workflow 和 codebase 级别修改GitHub Copilot：更适合补全、解释和 IDE 内即时辅助
别急着同时学三四个 tool。先把一个 tool 用顺手，再扩展。
小结
Vibe Coding 最有价值的地方，不是让你少思考，而是让思考更快变成可验证的 result。
你真正要练的，不是“怎么把 prompt 说得像咒语”，而是怎么把需求说清楚、把结果验明白。