实战!基于SPEC的AI开发

规范驱动开发颠覆了传统软件开发的模式 。几十年来,代码一直是王道——规范只是我们搭建的脚手架,一旦“真正的”编码工作开始,就被丢弃。规范驱动开发改变了这一点: 规范变得可执行 ,直接生成可执行的实现,而不仅仅是指导它们。

上面这段话来自spec-kit的仓库,简单介绍了基于Spec开发的意义。在传统依赖AI写代码时,我们往往直接发出指令,AI则遵循指令对代码进行修改,这样至少我发现的就有两个问题:

一是对于大型任务的指令遵循效果差,必须人为细化任务,但是人为细化往往还有所遗漏;二是由于个人提示词撰写水平能力的不同,AI写出的代码也良莠不齐。

而基于Spec编程,可能给了我们一个全新选择。

啥是基于Spec编程?

简单来说,在开始编程之前,花大量的时间和AI讨论你想要的产品的需求,实现,技术等,明确你想整出个什么玩意,然后根据这个需求再进行设计和任务拆分,最后严格按照任务顺序进行开发

这一篇先介绍我比较习惯的一个MCP工具,项目地址:https://github.com/Pimzino/spec-workflow-mcp

我是不会告诉你原本打算一次性写两个工具然后犯懒的

安装

Claude Code

一行命令安装

1
claude mcp add spec-workflow npx @pimzino/spec-workflow-mcp@latest

CODEX

编辑~/.codex/config.toml,

1
2
3
[mcp_servers.spec-workflow-mcp]
command = "npx"
args = ["-y", "@pimzino/spec-workflow-mcp@latest"]

通用安装

1
2
3
4
5
6
7
8
{
"mcpServers": {
"spec-workflow": {
"command": "npx",
"args": ["-y", "@pimzino/spec-workflow-mcp@latest", "/path/to/your/project"]
}
}
}

在项目文件夹下新建一个 .spec-workflow 文件夹,文件夹下新建一个 config.toml ,写入下面内容 。多个项目的话记得改面板端口

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# Dashboard port (1024-65535)
port = 3456

# Auto-start dashboard with MCP server
autoStartDashboard = true

# Run dashboard-only mode
dashboardOnly = false

# Interface language
# Options: en, ja, zh, es, pt, de, fr, ru, it, ko, ar
lang = "zh"

# Sound notifications (VSCode extension only)
[notifications]
enabled = true
volume = 0.5

# Advanced settings
[advanced]
# WebSocket reconnection attempts
maxReconnectAttempts = 10

# File watcher settings
[watcher]
enabled = true
debounceMs = 3000

使用

官方给了一页的示例:https://github.com/Pimzino/spec-workflow-mcp/blob/main/docs/PROMPTING-GUIDE.md

从个人使用上来说,一般还是得强调一下,请使用spec-workflow-mcp工具

生成指导文档

指导文档(steering documents)是用来规定整个项目的文档

比如

1
请使用spec-workflow-mcp工具帮我生成一个steering documents,我希望写一个程序,使用纯HTML单文件,实现IP信息查询和Whois查询功能,使用免费的API

然后在AI一顿操作后,会首先生成一个product.md文件,这个文档会定义这个项目到底干嘛的,有什么用

然后让我们打开http://IP:端口/#/approvals,会出现一个类似下面这种审批申请,点击审阅和注释查看是否满足你的要求,满足就快速审批,想修改就直接滑动修改的地方给出意见,Preview是查看(只有这个页面能用沉浸式翻译...),Annotate是审阅,Changes在多次审批之间可以查看和上次的区别

image

无论你是给出了审阅意见还是快速批准了,回到你的CLI或者IDE,输入继续或者continue什么的,如果审阅没通过他就会继续改,快速批准就会开始编写tech.md

tech.md会定义项目的技术栈,外部资源什么的,还是一样不爽改,看着合适了就通过,通过之后就是structure.md,这玩意就具体了,会定义代码架构,文件夹结构,需要遵循的原则….

image

image

生成SPEC文档

接下来开始为一个任务创建一个具体的SPEC文档。

注意,我这是因为项目太简单了所以没有说明,不然你得告诉它你要干啥,比如”请使用spec-workflow-mcp帮我生成一个SPEC文档,我想要….”

1
请使用spec-workflow-mcp帮我生成一个SPEC文档

首先会生成需求文档,接下来是Design设计文档,最后是Task.md,哪里不对改哪里,和上面一样的流程我就不多赘述了

image

不过注意一下Task.md,这玩意有时候不按照模板生成,导致审核通过了后续无法推进,这时候要让它参考.spec-workflow/templates/tasks-template.md的格式重新生成

执行任务

来到任务视图,逐个任务点击复制提示就完了

旁边的视图有List和看板,当任务多了用看板会方便很多

直到写到这里我才发现我TM新建了Test文件夹拿来演示结果没用上在一个正在干的项目整了

image

总结

总的来说,我得承认,这种基于SPEC规范开发有一种“看起来很美”的感觉,看起来非常符合标准化开发的实践。

但是实际上因为AI能力的问题,对于大型问题它会拆分出三四十个任务,然后中间一个出问题就完犊子了,对于小型问题我说白了不用它也能整得出来……同时,每一步审批,每一步修改,背后都是TOKEN在燃烧啊…烧的都是钱啊

PS.这个测试任务最后也只实现了IP查询所以我就不放了,AI最后也没找到Whois的免费API,不过页面和响应式做得还行

image

image