实战!基于SPEC的AI开发
实战!基于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 | [mcp_servers.spec-workflow-mcp] |
通用安装
1 | { |
在项目文件夹下新建一个 .spec-workflow 文件夹,文件夹下新建一个 config.toml ,写入下面内容 。多个项目的话记得改面板端口
1 |
|
使用
官方给了一页的示例: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文件,这个文档会定义这个项目到底干嘛的,有什么用

无论你是给出了审阅意见还是快速批准了,回到你的CLI或者IDE,输入继续或者continue什么的,如果审阅没通过他就会继续改,快速批准就会开始编写tech.md
tech.md会定义项目的技术栈,外部资源什么的,还是一样不爽改,看着合适了就通过,通过之后就是structure.md,这玩意就具体了,会定义代码架构,文件夹结构,需要遵循的原则….


生成SPEC文档
接下来开始为一个任务创建一个具体的SPEC文档。
注意,我这是因为项目太简单了所以没有说明,不然你得告诉它你要干啥,比如”请使用spec-workflow-mcp帮我生成一个SPEC文档,我想要….”
1 | 请使用spec-workflow-mcp帮我生成一个SPEC文档 |
首先会生成需求文档,接下来是Design设计文档,最后是Task.md,哪里不对改哪里,和上面一样的流程我就不多赘述了

不过注意一下Task.md,这玩意有时候不按照模板生成,导致审核通过了后续无法推进,这时候要让它参考.spec-workflow/templates/tasks-template.md的格式重新生成
执行任务
来到任务视图,逐个任务点击复制提示就完了
旁边的视图有List和看板,当任务多了用看板会方便很多
直到写到这里我才发现我TM新建了Test文件夹拿来演示结果没用上在一个正在干的项目整了

总结
总的来说,我得承认,这种基于SPEC规范开发有一种“看起来很美”的感觉,看起来非常符合标准化开发的实践。
但是实际上因为AI能力的问题,对于大型问题它会拆分出三四十个任务,然后中间一个出问题就完犊子了,对于小型问题我说白了不用它也能整得出来……同时,每一步审批,每一步修改,背后都是TOKEN在燃烧啊…烧的都是钱啊
PS.这个测试任务最后也只实现了IP查询所以我就不放了,AI最后也没找到Whois的免费API,不过页面和响应式做得还行


.webp)