AI 编程规范化:SpecKit 编程实战!是否能实现可控 AI 编程?

新闻

作者：微信文章
微软 spec-kit 已经发布已经过去两个多月了。 大多数人都已经被 AI 变成的各个工作流搞得眼花缭乱了， 看到新的技术无论吹得多么牛逼，都没有心力去尝试。

本文用一个实际工作的开发流程，带你走进 「规范驱动开发」的世界。
无论是 spec 模式也好，spec-kit 工具也好， 对于经常接触 AI 编程的人来说，肯定能明白现阶段 AI 既不会出现无所不能的神器， 也不会流行一些一无是处的工具。所以大家摆正好心态，去看待每一个新事物。第一次接触 SPEC 模式

最早接触 Spec 驱动的开发，还是今年七月份的时候使用亚马逊推出的 AI 变成工具 Kiro 。 当时觉得 spec 模式真的是为 AI 变成打开了一扇大门。

还写了两篇文章介绍这个新工作流的体验，虽然觉得牛逼，但是并没有体系化的理解，当时也没有什么资料。

• 《Kiro Spec 模式介绍》

关于 Spec Kit

Spec Kit 是微软9月初左右发布的产品。
提示词产品？如果你仔细看了这个项目的内容，就是一些提示词模板，以及对不同编程工具的适配。 没错，AI 时代的产品可能就是这么简单，会说话，写出来提示词，这就是一个产品， 设置能风靡全球。
SpecKit Github 站点[1] 上有很详细的安装和使用以及更详细的介绍说明，我就不重复了。
安装和初始化项目

按照官网的命令直接安装 specify-cli 工具。
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
我不是从零开始，使用 --here 参数，在当前目录下初始化一个 spec 项目。
specify init --here
如果当前目录有文件，他会要求你确认是否在当前目录下初始化项目。


确认创建项目
选择使用的工具，比如 claude，这里列出了长江的 AI 编程工具，


选择使用的工具
然后提示选择脚本，默认即可，如果是 Windows 选择第二个。


选择脚本
接下来，他会自动初始化项目，包括检查工具、下载模板等：


自动初始化项目
过几秒就好，初始化完成。


初始化成功使用 Specify 进行规范驱动开发

specify 主要有五个命令：

• /speckit.constitution： 制定或更新项目管理原则和开发指南• /speckit.specify： 明确你想构建什么（需求和用户故事）• /speckit.plan： 使用您选择的技术栈创建技术实施计划。• /speckit.tasks： 生成可执行的任务清单以供实施• /speckit.implement： 按照计划执行所有任务以构建该功能。

第一个命令对我来说是可选的，他会根据当前项目情况或者你的需求生成开发指南，我这里 CLAUDE.md 都基本已经制定好了。 我们跳过。

输入 /speckit.specify 以及你要实现的功能描述，AI 会帮你实现需求内容。比如我这里让他实现一个知识库模块。


specify
AI 在 Specify 阶段会执行下面一系列操作。
检查并创建 Git 分支

检查并创建 Git 分支
从模板创建并编写规范文件 spec.md


创建并编写规范文件
编写需求文件 requirements.md


编写需求文件
最后和用户澄清一些问题，


和用户澄清问题
用户中它会给出一些建议选项：


给出建议选项
你回答之后，AI 会继续更新 spec.md 文件，


更新 spec.md 文件
最后 AI 已经觉得创建完成了，并给出下一步的实施计划。


创建完成
我们先看一下 spec.md 文件结构：


spec.md 文件结构
AI 给出了四个用户故事，看起来都很合理。但是这里隐藏了一个大家经常遇到的 AI 陷阱。

这个陷阱就是 「合理和好的用户故事，并不一定是你必须的」。

同时，我们又以为 AI 有能力根据用户故事，完美的完成需求，同样的在后续的迭代中，用户故事也会不断的变化和增加， 导致项目范围越来越大，AI 的补丁也越打越多，最终项目的失败。

我这里给的建议是，如果这是一个正式项目：严格保证AI给出的用户故事和设计，都是在你原来产品构思范围之内的。 如果超出，必须调整或者直接删除。

如果是一个发散型的项目，至多保留一个超出你原设计的用户故事，其他所有AI 给出的好点子放在下一个迭代里面去实现。

除了规范文件，AI 还会根据用户故事，生成对应的需求文件 requirements.md。 这里是给我生成了一个中英文混杂的需求文件。


需求文件
如果你对任何地方不满意，可以使用 specify 命令，重新进行修改，比如我们让他使用中文来编写需求文件。


修改为中文Plan

计划阶段，直接输入 /speckit.plan 命令，AI 会根据你之前的需求文件，生成技术实施计划。


计划阶段
分析完成之后，会给你生成对应的文档：


计划文档
原则：对于AI生成的文档，一定要逐个阅读，然后修改再修改，直到你完全满意为止。

AI生成的文档都很棒，而且很规范。但是，多多少少都会不符合你的要求， 而这些模棱两可的地方，一定是未来让你项目变得面目全非的源头。
到底谁是工具，谁是主人？目前的现状是，如果你要用 AI 来实现复杂项目的编写， 大部分人都是在给 AI 打下手，你没听错。无论你承认不承认， 我们多数人使用 AI 的过程，就是在给 AI 进行测试、报告问题、修复 Bug、改文档、接收黛玛诗山等等。 而如果你面前坐的不是AI而是你的同事，相信我，你肯定早就掀桌子了!Tasks

/speckit.tasks 命令来让工作流来拆解和生成任务。

我这里为了快速验证，让他用 Mock 接口来实现，先不用连接后端。


生成任务
最终给我生成了，惊人的 96 个任务。


任务结果
给大家看看任务大概长啥样：


任务截图
任务多少到时没关系，对 AI 来说，一个也是做多个也是做。 但是任务的合理性往往需要人工检查和处理。
Implementation

输入 /speckit.implement 来开始执行任务。


开始
AI 编码还有一个问题，他会创建远比你想象中要多个文件和代码。

过了十几分钟，任务完成了一个阶段，


任务完成
给我增加了十几个文件，也没法验证，只能硬着头皮继续。
Spec 模式的缺点

使用 Spec Kit 或者说使用 Spec 模式的好处大家讲了很多。 我稍微说一下他带来的问题。

首先是人的工作量变大了，即使（假设）生成的应用质量高， 前期也需要设计、需求、任务等诸多需要人重度参与的内容。 这其实也增加了人很大的工作量，或者说极大降低了AI效率。 （如果让 AI 直接写可能几个页面10分钟就写完了，但是如果用 Spec 模式，可能需要半天或者一天。）

对于大模型来说，原生就对多文件处理起来比较困难。 正确率也比较低。Spec 模式任由 AI 去设计，也会面临这个问题。
运行结果

Task 总共分了 6 个阶段，我在第一二阶段运行完之后，检查了下程序错误，然后让 AI 修复。

然后就过去半个小时了，这些 Bug 还没有修复完。


启动测试中
下班了。明天再给大家更新后续。
引用链接

[1] SpecKit Github 站点: https://github.com/github/spec-kit