yinwm:
哈喽哈,我是大铭,一个智能体开发者。
我们来聊聊 AI 编程一个让人血压飙升的场景:项目稍微复杂点,AI 就开始“自由发挥”。今天生成的函数还挺好,明天让它写个相关的,数据结构就给你改了;前一个模块里的字段还在第一层,到另一个模块里它就给你塞到第二层去了。
这种 AI 代码的 “不一致性”和“失控感”,是目前所有 AI 编程工具最大的痛点。
最近大火的 Kiro Agent 尝试用一套 ‘Specs’ 流程来解决这个问题,思路非常棒,但实际体验下来也很 OK ,但是无尽的 Retry 和报错,太慢、太不稳定了。

不过,它的核心思想是金子!所以我把它抽了出来,做成了一个更轻、更快、并且能无缝融入你现有开发工具(比如 Cursor )的流程——我叫它 [ Vibe Specs ] 。
接下来,我想聊聊为什么这套 “Specs” 模式如此重要,以及我是如何让它变得更好用的。
为什么 Kiro 的 Specs 是 vibe coding 的重要一环
控制 AI 编程的核心在于确保其行为一致且不偏离预设轨道,而不是纠结于单一片段代码的多种“正确”写法。
而 Specs 的方式正是尝试解决这个问题。
核心理念:控制比“正确”更重要
在 AI 编程的时候,最重要的不是说需要让它写对,而是要控制它,别让他写错。
为什么这么说?因为对于编程这件事来讲,什么叫“对”?实现一个功能可以有很多种做法,你用不同的循环方式、判断方式,甚至是代码组织方式都可以。真正的风险在于不一致性。
AI 可能会乱写,比如:不能说你前面一个字段还在一个数据结构的第一层,到了后面,AI 在另一个模块里就把这个字段变到了数据结构的第二层。你单拿任何一个代码片段来看,它可能都是 OK 的,但是作为一个整体项目的不同模块放在一起,那它就是错的了,至少是数据不一致的。所以,我们需要去控制它。
Kiro 的 Specs 模式是如何控制的
一个三步走的策略
站在我们整个需求的角度,如何去有效控制 AI 的行为呢?其实就是我们明确地告诉它“什么是什么”。这套方法论可以分解为三个核心步骤:
- 明确目标 (Define the "What" and "Why")
我们作为主导者,必须首先提出我们需要的目标和本次需求的详细描述。这包括要解决的根本问题 (Why) 和要实现的功能是什么 (What)。这是整个流程的基石,为 AI 的所有后续行为设定了清晰的边界和方向。
这步的产出是需求文档 requirements.md
- 共同设计 (Design the "How")
在明确了目标之后,关键的下一步是和 AI 一起来去设计我们的实施路径。我们提供思路和约束,AI 负责填充细节和提供选项,双方共同确认技术方案、关键数据结构、模块划分和核心函数等。这一步确保了我们的意图能够被准确地转化为技术蓝图。
这步产出是设计文档 design.md
- 分步实施 (Execute the "Action")
最后,我们根据已经确定的设计方案,一步一步地去实施。我们将大的任务拆解成小的、可执行的步骤,引导 AI 逐个完成。每完成一步,我们都能进行快速验证,确保结果符合设计,然后再进行下一步。
这步产出是任务文档 tasks.md
为什么不用 Kiro
既然 Kiro 已经把这个解决的非常好了,为什么不直接用呢?
答案是,Kiro 太慢太不稳定了,无限的 Retry , 然开发流程根本无法持续进行
而我尝试把这个流程切换到 Cursor 里面,借助 Claude sonnet 4 ,1 个小时就完成了 Kiro 里面半天都在等待 Retry 的任务
是时候把 Specs 抽取出来了
感谢 https://github.com/ghuntley/amazon-kiro.kiro-agent-source-code-analysis 提供的 Kiro 提示词
我则经过测试,把这个流程结合 Kiro 提示词,做成了一个 MCP
额外的,我还增加了一个目标讨论的过程,让 AI 和我们更加精准的进行需求讨论
在 Claude 3.7 / Claude 4 / Gemini-2.5-pro 表现良好
如何安装和使用我的 [ Vibe Specs ] MCP
1. 安装 Vibe Specs MCP
请选择你的工具安装 MCP
{
"mcpServers": {
"vibedev-specs": {
"command": "npx",
"args": ["vibedev-specs-mcp@latest"]
}
}
}
▶︎ Claude Code
claude mcp add vibedev-specs -- npx vibedev-specs-mcp@latest
▶︎ Gemini
修改
~/.gemini/settings.json
安装成功后,你可以在 Cursor 等工具中看到这些命令

2. 开始一个需求流程
为了测试,我使用 gemini-cli 进行了测试
首先进入 gemini ,然后启动 vibe specs 开始进入需求讨论明确并实施的流程
例如输入:
我想要使用 vibe specs 来做一个需求, 使用 go 写一个命令行, 这个命令行调用 geimini cli 工具,来对接 chatlog 的接口,然后分析一个特定日期的聊天记录,拆成卡片,调用 aimemo API 写入
然后就会开启整个流程

2.1. 讨论需求
这个过程是一个和 AI 反复沟通的过程,这个过程你可以让 AI 去联网搜索,去不断的和你讨论目标
把以前一句话要描述清楚目标的过程,转化为和 AI 讨论目标的过程

在这个过程中 AI 会不断的和我们讨论需求,直到我们和 AI 讨论的非常清楚以后,再确认目标推进到下一步
目标确认后,MCP 会给本次的目标生成一个名字 feature_name
,然后我们就可以在项目的根目录找到我们本次工作的相关文件了

如本次的功能命名为 wechat-article-to-aimemo
,那我们就可以在项目的根目录寻找
.vibedev/specs/wechat-article-to-aimemo/

当然现在这些文件还等待生成



这也是一个交互的过程,交互的目的就是明确细节
这个过程,都是人类可以听明白的需求描述。
在这个过程中,我们可以看到 AI 会反复的和我们确认需求的细节,甚至很多都是我之前考虑不周全的。
这个过程会反复好几次,不要嫌烦,这都是必要的。想要 AI 更准确的写代码,这个过程是必须的。
最后我们确认需求后,就可以生成 requirements.md 文件了

2.3. 生成设计文档,从人类描述向机器描述转换



有时候生成的文档是英文的, 你可以让他翻译成中文

2.4. 生成任务列表,进入到开工前的最后阶段

MCP 会把我们上面的需求和设计,拆成 N 个任务,写入到 tasks.md
中


此时这些任务看起来是这样的

可以开始编码了
3. 根据任务文件开工干活

Vibe Specs MCP 会寻找任务文件中第一个未完成的任务,然后开工
然后一路,确认、继续,等着 AI 干活


此时 tasks.md
文档也做了对应的完成标记

3.1. 如果中间断掉了怎么办
因为这个任务是保存在 tasks.md
文件中,所以不怕
只要选中对应的 tasks.md
文件, 或者说明 feature_name
,在这里是 wechat-article-to-aimemo
, Vibe Spec MCP 会自己继续干活的


结语
我用 Specs 这个模式完成了三个相对完整的需求,虽然不能说是完美,但是在限制 AI 不出错的方面的确是还不错
在执行的时候,还有一部分是特意说明要一个任务一个任务执行,这样给我们留下足够的机会去按照任务测试,排查
但不好的地方是他就没办法静默的一直干活到完了。这个我稍后做一个升级,弄个开关,让他可以一直干到底。
AI 牛马又要进化了