【暴论】不要盲目的使用spec规范驱动开发或者mcp多ai协同开发

开发调优
, ,
1

最近把市面上流行的那些 Cursor Rules、多 Agent 协作（MCP）、还有什么 Spec 规范驱动开发都试了一遍，说实话，感觉全在瞎折腾。反而浪费时间，上下文污染，幻觉积累，过度设计，全是跑MVP的阻碍 :distorted_face:

我现在越来越觉得，现阶段 AI 编程这事儿，产出真的只跟你投入的纯时间成正比，跟你用的那些奇技淫巧没半毛钱关系。

之前我总想着让 AI 像个正经团队一样，弄个架构师 Agent 指挥，再弄个程序员 Agent 写，搞个多ai讨论。结果呢？架构画得那是真漂亮，层级分明，文档洋洋洒洒1000行。但一到具体的细节，api这里少一个头，那里少个参数，全是灾难。代码极其臃肿，明明几行能搞定的逻辑，因为它要遵循那个宏大的“架构”，非得给我绕一大圈。

最要命的是耗钱啊，昨天耗了20美元生成一堆废物文档，而且迭代速度慢得令人发指，一般一个对话几分钟就能出来测试到底行不行，搞了一堆openspec和多ai协作一轮对话都要半个小时去了。 :face_with_symbols_on_mouth:

后来我发现，最有效的“Prompt”其实是能够成功运行你心中所想的这个信息，或者是运行的报错信息。规划出来的全是空的，能跑出来才是最落到实处的。直接写个大概逻辑，让它跑，炸了就把 报错甩脸上。那个信息，含金量比几十页的 Spec 文档高多了。是对 AI 幻觉最直接的惩罚和修正。而且就算前期规划的有问题，ai最不怕的就是重构或者推翻重写，干就完了 :face_with_steam_from_nose:

Spec 驱动看起来信息量大，其实全是干扰和废话，多ai，Agent A 猜 Agent B 的意图，Agent B 猜代码的逻辑。这中间全是概率，每一次猜测都在增加熵（不确定性）。虽然它们输出了几千字，但可能全是“废话”（因为没验证过）；报错驱动看起来像是在硬试，但每次修正都是实打实的熵减。

所以现在的感觉就是：在规划阶段差不多就行，执行阶段拆成一个个最小可验证的单元，做一个跑一个，简单粗暴地堆时间、看报错、删了重写。还有就是尝试自己去维护一个伪代码的核心逻辑，确定之后非必要不更改，然后每次上下文都把这个引用，会好一些

大家觉得呢？啥时候应该增加上下文，啥时候应该精简上下文呢？或者还有没有什么提高vibe coding效率的方法？

34 个赞
2

感觉在开始编码的时候，要求ai分析自行制定计划，就可以开始写代码了，后面就是一个个细节的微调。

2 个赞
3

是的，我昨天就是在做计划上搞了一天，结果出来2000行的文档跑都跑不通的一坨 :distorted_face:

1 个赞
4

完全不用人介入怎么可能，再怎么强大还是个辅助工具，不是许愿机，写大模型的人都不敢这么说，用的人比较勇，以为配置配置就能全套完美跑通，如果真的可行的话，在座的各位早都被优化了，还轮得到你配置给你自己提效吗

3 个赞
5

不是这个问题，文档也是我看着看着一步步写的啊，我反对的是过度spec驱动或者多ai驱动这种疯狂加上下文的操作，实际上就是看着没问题，然后各种小细节给你挖坑，又因为迭代速度慢，没法即使运行代码找这些坑，效率反而更低

2 个赞
6

最近想利用 AI 搞得 CLI，我目前的想法是核心協調器-階段-任務，對照的工作抽象-中間-實際
以及計畫大綱只能創建與新增，小節能夠更新 刪除 創建 新增
以及我的 Cortex 協議強制 AI 跟隨對話輪次以及說明內容來源等方式

不知道這樣是否能解決 SPEC 和 Agents 的問題

7

spec是tdd，一般方法是敏捷开发，这下区别就很好懂了

8

所以说啊，spec更适合维护，在MVP阶段就别轻易用

9

就着请教下各位大佬,如果拿到一份比较泛的需求,或者说是 一份需求会议的文字纪要,从 0开始开发,应该怎么高效完成开发呢

10

定个大向，让 web 哈基米（web 的记忆总结使得 ctx 能很大）作为记忆主控，每次计划&提交都在基米这里反馈，在 Coder 端就按照流向敏捷开发，这样子，感觉节奏挺舒服的，但是的确也，时间投入多（相对 SPEC 的理想状态）

拆分模块但是不细致化定义（除了核心部分），不同语境不同 ctx 下，各个 llm 的（甚至有时候同一个）决策也会不同，定了细致互相混淆干扰（鄙见）

2 个赞
11

我觉得大的任务要先和AI讨论如何分解成小的任务， 把接口和功能定义清楚。 这一步做好了， 其他小任务对于AI都是比较容易做对，哪怕有点问题， 人工介入一下就可以啦。复杂任务，人工介入都不一定让AI立即明白

1 个赞
12

看来自然语言的不准确性是个问题

但其实真实的程序员接手别人代码的时候也这样，各种猜各种试，然后到某个阶段突然看懂

13

开发啥啊，会议文字纪要软件吗，如果是纯文字纪要直接让ai总结就好了啊

14

MVP的时候恰恰就需要规范驱动，除非你的MVP只是来展示产品原型的，除此之外，MVP都是产品开发的最早期版本，后期都会基于MVP来添砖加瓦去丰满整个产品。
如果MVP没有确定好规范，比如Schema，比如组件，比如架构，等等，那后期就会越来越歪（这点在AI接手的情况下非常明显）。
所以我认为宁可多花点时间去审Spec，也不要放任AI自流。
Spec确实有的时候是屎，但是根本原因其实还是没有逐条去审，说到底还是看人类自己的架构能力。

2 个赞
15

人工才是最强的MCP

1 个赞
16

真别说，我最近越来越觉得程序员就是老板/领导的mcp，奶奶的

领导提要求，然后实现

不符合要求然后慢慢改或者重新写

4 个赞
17

plan模式性能下降很明显，就不说spec了

1 个赞
18

个人感受 纯vibe 自己都不了解项目结构的话 会有很多问题 。自己了解项目结构 知道怎么改 直接跟ai说基本上一次就成功。

1 个赞
21

对的！所以我在文中提到你得自己去维护一个伪代码流程图做到心中有数。但是这样又有一个问题就是大部分情况ai的架构能力是会高于一般程序员的，很多时候我们也不知道这个地方这样处理到底是过度设计还是必要的

22

恭喜佬友，你发现了这个世界的本质（bushi

2 个赞