从Vibe到Spec：我的AI编程集训翻车实录，以及如何用Spec模式爬出来
同样是AI写代码，隔壁组3天交付，我们组加班一周还没搞定？真相扎心了：不是AI不行，是你在“凭感觉编程”
本文基于真实集训经历，约2400字，阅读时间6分钟。如果觉得有用，欢迎点赞、在看、转发给那个还在“凭感觉编程”的同事。
上周，公司组织了一周的AICoding集训，要求各组在限定时间内完成一个完整的企业级项目交付。
我信心满满——平时Claude Code用得贼溜，摸鱼技术文章都写了好几篇了。这次我主动请缨担任技术负责人，心想：AI辅助开发，这不是我的主场吗？
然而一周后，我的Git记录显示：AI初版代码——已删除。
这不是AI的错，是我的错。我踩进了Vibe Coding的坑。
💀 我被“感觉对的代码”坑惨了
事情是这样的：
集训目标：一周内搭建一个完整的企业级应用，技术栈确定为统一基座 + Vue 3 + Spring Boot。
我当时的内心OS：这不就是CRUD吗？AI分分钟搞定。
Day 1-2：我开启了“Vibe Coding”模式——想到什么就让AI写什么。“帮我生成用户管理模块”“加个权限控制”“写个报表页面”……AI很给力，代码刷刷地出来。我沾沾自喜，觉得自己带队水平又上了一个台阶。
Day 3：前后端联调，灾难开始了。
前端调用的接口返回格式不统一：有的用result.data，有的用result.content，还有个模块直接返回了字符串。登录状态判断也是五花八门——一个地方用code === '0'，另一个地方用res.success === true，还有直接判断res.data存不存在的。
后端各模块的数据库表更是“百花齐放”：用户表用user_id，订单表用orderId，日志表用log_Id。看着这些代码，我感觉自己不是在维护一个项目，而是在考古——每个模块都是一个独立的文明。
Day 4：产品经理提了一个跨模块的需求：“在报表页面加个用户信息展示”。
我让AI改A模块，B模块的样式崩了。修B模块，C模块的数据不显示了。修完C，A模块的逻辑和B模块又对不上了。这像极了过年串门——去了这家，那家嫌你没到。
Day 5：代码膨胀到5000行，相同的数据校验逻辑出现了5次（且写法都不完全一样），依赖包版本冲突到令人头大。
Day 6：集训即将结束，我做出了一个艰难的决定——推翻重来。
我花了一天时间，重新梳理架构、制定规范、写好Spec文档，再让AI按Spec生成代码。最终在Deadline前压哨交付。
虽然集训成果按时交付了，但我深刻反思了“凭感觉编程”的代价。
🧠 Vibe Coding vs Spec Coding：一张表看懂差距
先上定义：
| 对比维度 | Vibe Coding（氛围编程） | Spec Coding（规约编程） |
|---|---|---|
| 一句话概括 | “我要做个xxx，AI你看着办” | “这是Spec文档，AI你按这个来” |
| 核心特征 | 凭感觉+自然语言驱动 | 基于规范和契约驱动 |
| 目标用户 | 个人开发者、Demo验证 | 企业团队、生产级项目 |
| 适用场景 | MVP原型、个人小工具 | 复杂业务系统、团队协作 |
| 代码质量 | 不确定性高，依赖AI“发挥” | 可控、可预期、可审计 |
| 维护成本 | 高，修改一处可能多处崩 | 低，架构统一、逻辑清晰 |
| 团队协作 | 灾难，各自为政 | 顺畅，统一规约 |
🎯 Vibe Coding的“三宗罪”——我踩过的坑
第一宗：架构随缘，代码无根
Vibe Coding生成的代码，像是一个没有蓝图就开工的房子——能住，但二楼卫生间可能刚好开在主卧床头。
它会自己“发挥”选择架构：这个模块用类，那个模块用函数式；这个接口用RESTful，那个用GraphQL风格。你永远不知道AI下一段代码会用什么“风格”。
在我们的集训项目中，最惨痛的教训是API接口规范不统一：
| 问题类型 | 错误示例 | 正确规范 |
|---|---|---|
| 返回格式 | result.data / result.content / 纯字符串 |
统一用 Result 封装 |
| 状态判断 | res.success / res.data 存在性 / 自定义code |
统一用 code='0' 判断成功 |
| 异常处理 | 各模块自行catch，有的吞异常有的抛 | 统一全局异常拦截器 |
第二宗：隐藏的技术债——比人工写的更难还
人工写的烂代码至少还能看懂逻辑，AI写的“精致烂代码”更难对付——它语法正确、命名规范，但架构层面可能完全错误。
比如AI生成的pom.xml，依赖版本可能冲突；生成的建表脚本，字段命名风格不一致；生成的构建脚本，可能在特定环境下跑不通。
在这次集训中，我的AI辅助参与度达55%以上——AI帮我生成了pom.xml配置、建表脚本、build构建脚本等。但我当时没做统一规范审查，导致各模块的脚本风格各异，集成时问题百出。
最扎心的真相：AI不会告诉你“这段代码不符合团队规范”，它只会自信地把“看起来对”的代码交给你。
第三宗：知识不沉淀，团队无法复用
Vibe Coding生成代码后，没有任何设计文档、架构决策记录。一周后你想改，发现已经看不懂自己当时让AI写的代码了。
更坑的是团队协作——集训中我们有多个成员并行开发，如果大家都用Vibe模式各自生成，就会得到N个不同“风格”的模块：
- 前端组件库：有的用wg-ui，有的直接原生，有的引了别的库
- API调用：有的用axios封装，有的直接用fetch
- 状态管理：有的用Pinia，有的用Vuex，有的用组件内状态
🔧 Spec Coding：让AI从“艺术家”变成“施工队”
踩坑之后，我用Spec模式重新梳理了项目架构。Spec Coding的核心是：在写代码之前，先跟AI签一份“合同”，这份合同就是Spec（规约文档）。
我的Spec四层架构（集训复盘版）
| 层级 | 内容 | 我的集训案例 |
|---|---|---|
| 技术栈规范 | 核心框架、版本、依赖 | Athena + Vue 3 + Spring Boot，xteam-server + xteam-ui 双模块 |
| 接口契约 | API格式、返回结构、状态码 | Result统一返回 + code='0' 判断成功 |
| 数据规范 | 命名规则、字段类型、建表规范 | 统一小写下划线命名，每张表必有id/create_time/update_time |
| 工程规范 | 组件库、构建工具、CI/CD | wg-ui + Element Plus，Maven + Vite流水线 |
真实案例：集训复盘后的Spec化改造
第1步：先定技术栈规范（30分钟）
## 技术栈规范
### 后端
- 框架：Spring Boot
- 构建：Maven（统一parent pom）
- 数据库：统一小写下划线命名，每张表包含id/create_time/update_time
### 前端
- 框架：Vue 3 + TypeScript
- 组件库：Element Plus
- 构建：Vite
第2步：再定接口契约（20分钟）
## API接口规范
### 统一返回格式
{
"code": "0", // '0'=成功，其他=失败
"msg": "success", // 提示信息
"data": {} // 业务数据
}
### 状态判断
前端统一用 res.code === '0' 判断成功
第3步：制定数据规范（20分钟）
## 数据库规范
- 表名：小写下划线，如 `user_order`
- 字段：小写下划线，如 `user_id`
- 必备字段：id (bigint)、create_time (datetime)、update_time (datetime)
- 索引命名：`idx_字段名`
第4步：将Spec喂给AI
把这些规范作为Claude Code的系统提示，然后再让它生成代码。生成的代码严格遵循了所有规范——接口格式统一、命名风格一致、数据库规范完整。
结果：同样是5000行代码，有了Spec约束后，代码风格统一率从37%提升到96%，联调时间从2天缩短到半天。
✅ 什么时候用Vibe，什么时候用Spec？
这不是“二选一”，而是工具选型问题。我总结了一个决策树：
| 场景 | 推荐模式 | 原因 |
|---|---|---|
| 个人周末项目、MVP验证 | Vibe Coding | 快！别纠结架构，先跑起来再说 |
| 写一次性脚本 | Vibe Coding | 用完即弃，不值得写Spec |
| 企业生产系统 | Spec Coding | 代码要维护3-5年，必须有规约 |
| 金融/医疗等高合规场景 | Spec Coding | Spec+RAG是标配 |
| 遗留系统改造 | Spec Coding | 必须先定义好迁移规范 |
| 团队协作开发 | Spec Coding | 统一规约是团队协作的基础 |
| 技术调研、POC验证 | Vibe Coding | 快速试错，验证可行性 |
💡 集训的三大核心收获
这次为期一周的AI Coding集训，让我深刻认识到：
1. AI辅助不是“甩手掌柜”
AI参与度55%以上听起来很美，但没有规范约束的AI辅助，等于在加速制造技术债。AI帮你写了pom.xml、建表脚本、构建脚本，但如果各模块规范不一致，集成时就是灾难。
2. 技术负责人的核心职责是“定规矩”
技术架构设计与落地不是写代码，而是定规范：技术栈选型、API接口规范、数据库命名规则、CI/CD流程。这些规矩定好了，AI才能当合格的“施工队”。
3. Spec Coding是团队协作的基石
一周集训、多人并行开发，如果没有统一的Spec，就是各写各的、最后谁也看不懂谁的。有了Spec，AI生成的代码风格统一，团队协作才能顺畅。
💡 一句话总结
Vibe Coding = 凭感觉编程，适合个人快速验证
Spec Coding = 凭契约编程，适合企业级交付
两者的区别，就像“随便炒个蛋炒饭”和“按米其林食谱做惠灵顿牛排”——后者前期准备复杂，但出品稳定、可复制、可审计。
我现在的工作流是：
- 技术调研/POC：Vibe模式快速验证可行性
- 确认要做：花30-60分钟写Spec（技术栈+接口+数据+工程四层规范）
- 核心模块：Spec + AI生成 + 自动化验证，确保质量
真正的AI编程提效，不是“AI写得多快”，而是“AI写得对不对”。快但不规范，等于加速制造技术债；慢但有规约，每一行代码都是资产。
评论区聊聊：你在团队协作中有被Vibe Coding坑过的经历吗？或者你们已经在用Spec模式了？
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
8
0- 0
已为社区贡献17条内容
所有评论(0)