实战两天，一个基本功能都没跑通。最大的问题是，其实30分钟就已经跑通了基本功能，但是在后面迭代中，因为A功能里面的一个bug修改，AI会把整个系统都改一遍，A的bug改好了，BCDE功能模块里面出现了n个bug，然后在改B的一个BUG时，AI顺手又把A改出bug来了，这是产生屎山的底层逻辑。所以开发管理规范对于vibecoding至关重要。

给agent做分工、定规范，不仅仅不会产生屎山，而且可以节省95%的token，因为屎山就是烧token堆起来的。虽然说组件化开发对于代码复用的价值不大了，但是对于vibecoding开发却极其重要，并且要附加版本管理规范。vibecoding可以让产品经理一人就是一支完整的开发团队，并且大幅度降低了原来开发模式的沟通时间成本，但是用国内agent小米+步枪，显然架构师职能还不能下放给AI。

一、什么是 vibecoding？为什么它必然产出屎山

2025年初，Andrej Karpathy 提出了一个词——vibecoding：你不需要理解代码，只需要用自然语言告诉AI你要什么，AI帮你写，你只管凭感觉接受。

听起来很美好对吧？但现实是这样的：

vibecoding 的本质是：没有架构、没有规范、没有测试，只有感觉。

AI 写的每一行代码你都看不懂，每一次修改都在前一次的基础上打补丁，补丁上面叠补丁，直到有一天你发现——改一个地方，另外三个地方崩了。

这就是屎山代码的经典形成路径。而当屎山出现在生产环境，你不是在开发，你是在救火。

二、一次真实的 vibecoding 灾难复盘

我最近做了一个语音对话助手项目，让 AI 和你实时语音聊天。技术栈不复杂：浏览器录音 → 语音转文字（STT）→ 大模型对话（LLM）→ 文字转语音（TTS）→ 浏览器播放。

我让 AI 全权负责开发，自己只负责点一下试试。结果：

Day 1：前端 WebSocket 用了 ws:// 而不是 wss://，浏览器直接拦截连接，整个应用AI思考中卡死。AI 花了半天排查，一度怀疑是后端问题。

Day 1 晚：AI 用 cat > file << EOF 命令修改服务器上的前端文件，Windows Git Bash 路径解析 bug，把文件清空成了 0 字节。前端彻底白屏。

Day 2：AI 用 sed -i 替换 URL，结果多写了一个点号，wss:// 变成了 .wss://，JS 语法错误，又是白屏。

Day 2 下午：前端消息类型和后端不匹配——前端期待 content_start，后端发的却是 llm_chunk。两边各写各的，谁也不知道对方在发什么。

结局：两天过去了，一个基本的语音对话功能都没跑通。

三、屎山的三大病根

复盘下来，问题不是出在 AI 的能力上，而是出在开发方法上：

病根一：没有协议先行的规范

前端和后端各自vibe出消息类型，接口不通，再怎么调都是对牛弹琴。

病根二：没有安全操作的约束

cat > file 清空文件、sed -i 写坏语法、忘了加 wss://——这些低级错误一次就够了，但没有规范约束，AI 每次都从零vibe，同样的坑反复踩。

病根三：没有自动化验证闭环

AI 写完代码说应该没问题了，然后让用户手动去浏览器试。浏览器有缓存，用户不确定看到的是新代码还是旧代码，测试结果完全不可靠。没有自动化测试，就是没有真相。

核心洞察：vibecoding 的根本问题不是 AI 不行，而是没有给 AI 一个团队协作的框架。

四、解决方案：架构智能体开发团队

既然问题的根源是没有团队协作框架，那解决方案就是：给 AI 搭一个团队。

不是让一个 AI 万能地包揽一切，而是让多个专职智能体各司其职，每个智能体只做自己最擅长的事，通过共享规范和任务列表协同工作。

核心思路：把一个人凭感觉写代码变成一个团队按规范交付

具体来说，我设计了4个专职智能体：

架构师 Architect：项目的大脑，先想清楚再动手

后端开发者 Backend Dev：服务器端的实现者

前端开发者 Frontend Dev：浏览器端的实现者

部署测试员 Deploy & Test：质量的守门人

五、协作流程：不是并行乱写，而是有序交付

Step 1: 架构师定义协议→Step 2: 前后端并行开发→Step 3: 部署测试验证→Step 4: 失败→回退修复→循环直到通过

六、共享规范：嵌入提示词的团队公约

这是整个体系最关键的设计：开发规范不是写在文档里等人去看，而是直接嵌入每个智能体的提示词（prompt）里。

为什么嵌入提示词而不是写文档？因为AI 不会主动去翻文档。如果你想让 AI 遵守规则，就把规则写进它的DNA（提示词）里，而不是写在一本它不会翻的规章制度（文档）里。

七、效果对比：vibecoding vs 智能体团队

八、写在最后

Vibecoding 的问题不在于 AI 的能力，而在于人类放弃了架构师的角色。

当你对 AI 说帮我做个语音聊天，然后等着它全部搞定——你不是在用 AI，你是在碰运气。运气好的时候，demo 能跑；运气不好的时候，就是两天的屎山。

正确的姿势是：你来当 CTO，让 AI 当工程师。

不是告诉 AI 做什么，而是定义怎么做——协议先定、规范先行、测试闭环、迭代修复。这正是软件工程几十年积累的最佳实践，只不过执行者从人变成了 AI 智能体。

一句话总结：Vibecoding 是一个人凭感觉写代码；智能体团队是一群人按规范交付产品。区别不在于谁写代码，而在于有没有规范。

如果你也在用 AI 写代码，试试这个方法：别急着让 AI 动手，先花半小时把协议和规范定好，把规则写进提示词里。磨刀不误砍柴工——这是我两天屎山换来的最贵的教训。

本文首发于微信公众号「哲学猪」，转载请注明出处。