Vibe Coding
Vibe Coding 不是“把代码交给 AI 自动完成”，而是把开发变成以目标、上下文、约束和验证为中心的人机协作流程。
1. 什么是 Vibe Coding
Vibe Coding 可以理解为一种目标驱动的人机协作开发方式。
它强调：
- 人负责定义目标、约束、验收标准和优先级
- AI 负责生成草案、补全实现、执行重复劳动、给出备选方案
- 人继续审查、修正、验证和决策
所以它更像“高带宽协作开发”，而不是“完全自动编程”。
2. 为什么重要
在 AI 辅助开发里，真正稀缺的往往不是敲代码速度，而是：
- 问题定义能力
- 约束表达能力
- 上下文组织能力
- 方案判断能力
- 验证结果能力
Vibe Coding 把工程师的重心从“逐行实现”前移到“定义问题和控制结果”。
3. 适合与不适合的场景
适合：
- 原型验证
- 小功能迭代
- 重复性样板代码
- 文档、测试、脚手架生成
- 已有代码库里的定向修改
不适合直接无护栏使用：
- 高风险核心交易逻辑
- 安全敏感模块
- 缺少测试和验收标准的复杂系统
- 完全陌生、上下文极不足的老项目
4. 核心心智模型
不要把 AI 当“全自动程序员”，更合理的理解是：它是一个速度很快、上下文依赖很强、需要验收护栏的协作者。
AI 擅长：
- 快速起草
- 模式归纳
- 代码补全
- 文档整理
- 多方案发散
AI 不擅长：
- 自动理解隐藏约束
- 稳定处理模糊需求
- 对长期架构后果负责
- 默认保证正确性
5. 基本流程
目标描述
-> 补充上下文与约束
-> 让 AI 生成方案 / 代码
-> 人审查结果
-> 用测试、运行结果或规格验证
-> 继续修正 prompt / 规格 / 实现核心不是“一次生成”，而是“快速迭代 + 持续验证”。
6. 高质量上下文
高质量输入通常包括：
- 当前任务目标
- 所在项目技术栈
- 相关文件或模块
- 约束条件
- 验收标准
- 输出格式要求
差输入：
帮我写个评论功能好输入：
在 React + TypeScript 项目中新增评论组件。
要求支持已登录用户发表评论，长度 1-500 字；
未登录时显示登录提示；
提交成功后刷新列表；
网络失败时保留输入内容并显示错误提示。
请给出组件实现和状态处理逻辑。7. 提示词工程在 Vibe Coding 里的位置
提示词工程不是“写魔法咒语”，而是系统地设计输入，让模型更稳定地产生可用输出。
它关心：
- 任务有没有讲清楚
- 约束有没有讲清楚
- 上下文有没有给够
- 输出格式是否可验证
一个最小通用模板：
背景：
目标：
约束：
输入材料：
输出要求：工程任务更推荐：
Context:
Objective:
Constraints:
Input:
Output:
Validation:字段含义：
Context：项目背景、技术栈、相关模块、已有规则Objective：这次到底要完成什么Constraints：不能做什么，必须满足什么Input：任务材料、代码片段、数据、文档Output：结果格式Validation：怎么判断结果是对的
8. 常见有效技巧
8.1 结构化优于散文化
建议显式分块：
- 背景
- 目标
- 约束
- 输入材料
- 输出格式
- 验收标准
8.2 可验证优于“看起来不错”
好的提示词会要求：
- 固定输出格式
- 列出假设
- 标明不确定点
- 给出验证方式
8.3 显式写出边界条件
例如：
- 空输入怎么处理
- 失败时返回什么
- 不要改哪些文件
- 不要引入哪些依赖
8.4 先拆问题，再求结果
对复杂任务，常见写法是：
先列出假设，再给方案；
先分析根因，再给修复；
先给计划，再开始实现。这能减少模型直接冲向错误答案。
9. 适合不同任务的提示框架
小任务
背景：
目标：
约束：
输出格式：编码助手任务
Context:
- React 18 + TypeScript
- 已存在 CommentList 和 api client
Objective:
- 新增评论输入组件，并接入提交逻辑
Constraints:
- 保持现有代码风格
- 不引入新依赖
- 失败时保留用户输入
Output:
- 给出需要修改的文件
- 提供关键实现代码
- 补充测试建议
Validation:
- 已登录用户可提交
- 未登录用户看到提示
- 提交失败时显示错误信息分析类任务
背景：
任务：
分析维度：
证据来源：
输出结构：
不确定项处理：Agent 任务
任务目标：
可用工具：
禁止操作：
完成条件：
失败处理：
输出要求：Agent 任务里，工具边界和终止条件非常关键。
10. 什么时候提示词不够用
如果总是出现这些问题：
- 模型老是缺上下文
- 输出不稳定
- 事实不可靠
- 任务需要访问外部系统
那问题往往已经不只是 prompt，而是需要进入：
也就是说，提示词工程只是 AI Engineering 的一部分。
11. 常见误区
11.1 AI 会自动理解真实意图
不会。它只能根据你给出的信息推断。
11.2 生成出来能跑就算完成
不够。还需要确认：
- 是否符合需求
- 是否符合代码库风格
- 是否覆盖异常分支
- 是否可维护
11.3 存在一条万能最佳提示词
不存在。提示词高度依赖：
- 模型
- 任务
- 上下文
- 评测标准
11.4 AI 能替代工程判断
不能。AI 可以加速实现，但不能替你承担架构责任和业务责任。
12. 实践建议
从小任务开始
例如：
- 补一个 API
- 写一个组件
- 加一个测试
- 重构一个小函数
每次只解决一个主问题
不要在一个 prompt 里同时要求：
- 改架构
- 修 bug
- 写测试
- 优化 UI
- 补文档
始终要求可验证结果
例如：
- 给出变更文件
- 给出测试方式
- 给出边界处理
- 给出失败场景
13. 与 SDD 的关系
Vibe Coding 偏协作方式，SDD 偏需求和规格治理。
可以理解为：
- Vibe Coding 解决“人和 AI 如何协作”
- SDD 解决“任务如何先被定义清楚”
- Harness Engineering 解决“AI 如何在稳定环境里工作”
复杂任务不要只靠一条长 prompt，应该先写规格，再让 AI 基于规格实现和验证。
14. 一句话总结
Vibe Coding 的本质不是“把代码交给 AI”，而是“把开发协作升级为以目标、上下文、约束和验证为中心的工作流”。