AI系列面试14：vibe coding和spec coding区别？
这是大多数程序员都会面临的问题。Vibe Coding 和 Spec Coding 是当前借助大语言模型（LLM）编程时两种截然不同的工作范式。它们的核心区别在于：你给 AI 的“输入”是模糊的感觉，还是精确的规约。
一、以做饭为例来简单描述下vibe coding和spec coding区别
- Vibe Coding = 你和朋友说“我想吃辣的”，朋友凭感觉炒了一盘菜，你尝一口说“再咸一点”，他又加盐。味道可能惊艳，但换个朋友炒出来完全不同。
- Spec Coding = 你写好菜谱：“郫县豆瓣 20g，牛肉片 150g，芹菜段 50g，大火爆炒 2 分钟，起锅前加糖 3g”。不同厨师按菜谱做，口味高度一致。
二、两者的定义
| 维度 | Vibe Coding | Spec Coding |
|---|---|---|
| 别名 | 感觉驱动编程、提示即兴 | 规格驱动编程、文档先行 |
| 输入形式 | “帮我做一个好看的登录页，要有科技感” | “登录页需包含邮箱/密码输入框、记住我复选框、提交按钮；前端使用 React + Tailwind；表单校验规则：邮箱格式、密码长度≥8；失败时显示红色提示……” |
| AI 使用方式 | 对话式、迭代式：给出大致方向 → 看输出 → 再微调 | 工程化：先写详细 PRD/技术规范 → AI 基于规范生成代码 |
| 人类参与度 | 低：依赖 AI 发挥创意，人只负责“感觉对不对” | 高：人先完成设计/架构，AI 主要做执行 |
| 典型场景 | 快速原型、个人小工具、UI 探索、创意写代码 | 生产级系统、团队协作、需要可维护/可测试的代码 |
三、两者工作流对比
Vibe Coding 流程
- 模糊想法：“我想写个爬虫，抓知乎热榜。”
- 写第一段 prompt：直接让 AI 生成代码。
- 运行 → 报错 → 把报错粘回去 → AI 修改。
- 感觉界面丑 → “把那个按钮变圆一点，背景改成渐变蓝” → AI 改。
- 功能缺 → “再加个保存到 CSV 的功能” → AI 加。
- 循环 3-5 直到“感觉差不多了”。
Spec Coding 流程
- 编写规格文档：明确输入/输出、数据结构、错误处理、性能要求、非功能性需求（如日志、限流）。
- 将规格拆分为任务：例如任务1：实现
fetch_hot_topics()函数，遵守 spec 中的 API 签名。 - 逐个任务让 AI 实现：prompt 中包含函数签名、注释、测试用例预期。
- 人工审查和验证：确保符合规约，运行单元测试。
- 集成与回归。
四、优缺点对比
| 特性 | Vibe Coding | Spec Coding |
|---|---|---|
| 上手速度 | 极快，几分钟出原型 | 慢，需要写文档、拆任务 |
| 代码质量 | 低（可能冗余、不一致、隐藏 bug） | 高（可读、可测、符合架构） |
| 可维护性 | 差，后来者看不懂“为什么这么写” | 好，规约即文档 |
| 对 LLM 依赖 | 极高，换模型可能输出彻底不同 | 中等，只要规约清晰，不同模型也能产出类似结构 |
| 调试难度 | 困难，不知道代码哪来的逻辑 | 容易，按 spec 逐条检查 |
| 适合团队协作 | 几乎不可能 | 可以（spec 作为沟通契约） |
| 产出确定性 | 低，每次对话结果可能漂移 | 高，相同 spec 产生稳定输出 |
五、现实中的使用建议
“在工作中，vibe coding和spec coding不会二选一，而是混合使用，在合适的场景使用合适的方案：
- 在探索阶段（不确定技术选型或 UI 样式时），用 Vibe Coding 快速验证不同方案，比如‘用 Tailwind 写一个卡片组件看看效果’。
- 一旦方案确定，就立即切换到 Spec Coding：把成功原型反向整理成清晰的规格（输入输出、边界条件、错误处理），然后让 AI 或人工严格按照 spec 重写生产级代码。
纯 Vibe 模式只适合一次性脚本或内部小工具；对于要长期维护、多人在用的系统，Spec Coding 是硬要求。”
评论
暂无已展示的评论。
发表评论（匿名）