首页 ⚙ 实用教程 在团队里如何使用AI编程?Spec coding实践

在团队里如何使用AI编程?Spec coding实践

1、一个人用AI来编程,想怎么搞怎么搞。Agent 全自动模式,最大化放权,用什么技术栈,AI自主决定,新创建的文件放到哪里,怎么命名,AI自主决定,只要最终能运行就行了。

2、Claude喜欢每完成一个任务,就生成一个总结文档,无所吊谓,反正不影响程序运行。删起来还花时间。

3、一个人这么干,大不了就是一坨屎山代码,但对于团队协作,如果每个人都这样来一坨,就很容易堆成巨型屎山。

直到某一天CTO受不了了,痛定思痛:这个项目我们删掉重构吧。

4、Claude Code、Cursor等很多工具都有plan mode,但实际上很少人用,因为没这个习惯,都喜欢让AI少废话,多干活。

5、实际上从软件工程的角度,完成一个项目本身就会产生大量文档:需求文档(如需求规格说明书)、设计文档(如架构设计、数据库设计)、测试文档(如测试计划、测试用例、测试报告)和项目管理文档(如项目计划、进度报告)。此外,还有用户文档(如用户手册)、维护文档(如维护手册)和部署文档(如部署手册)等。

而编码过程产生的代码文件,只是其中的一个小环节。

6、前期工作准备得越充分,AI写代码就越能够一次性到位。

氛围编程(Vibe Coding)适合个人,规范驱动编程(Spec Coding)适合团队。

最近我用Spec Coding,体感上确实有让我直呼“卧槽”。

7、最重视Spec coding概念的AI编程工具是Kiro AI, 它引入 Specs(需求 / 设计 / 任务)+ Hooks + Steering,提出了「用规范约束 AI 编码」的基本范式。

8、当然,不用局限于这种非常小众的IDE 工具,最近几个月就出现了好几个开源的Spec coding项目。

9、Spec Kit, Github官方推出的开源项目: http://github.com/github/spec-kit

这是一个工具包,旨在通过“规范驱动开发”(Spec-Driven Development)加速高质量软件的构建,这种方法将规范转变为可执行代码。用户首先使用 Specify CLI 安装工具并初始化项目,然后通过一系列 AI 助手驱动的斜杠命令(如 /speckit.constitution、/speckit.specify、/speckit.plan 和 /speckit.tasks)来定义原则、创建规范、制定技术计划并生成可执行任务。该流程支持多种 AI 代理,并提供结构化的七个步骤,确保开发过程从意图驱动到最终实现都得到精确指导和验证。

10、OpenSpec, https://github.com/Fission-AI/OpenSpec

OpenSpec 也是一种规范驱动的开发方法,旨在让人类和 AI 编码助手就构建内容达成一致,从而使 AI 生成的代码更具确定性和可审查性。它通过在编写代码前锁定意图(通过“提议”、“审查”、“实施”和“归档”的流程)来解决 AI 助手在需求分散于聊天历史时的不可预测性问题。OpenSpec 适用于您已使用的各种 AI 工具,通过结构化的变更文件夹来明确和审计范围,并能很好地处理现有代码库的修改(1→n)。

11、总结:Spec Kit适合从0到1, OpenSpec适合从1到n。

实际上,大多数时候我们没有那么多从0到1的项目,即使做一个项目,到可能是从一个老项目的框架拿过来直接改。

从这个角度,我倾向于OpenSpec。

12、简单实测教学:

首先,打开终端,执行:npm install -g @fission-ai/openspec@latest
就能安装好openspec工具包。

然后,在你的项目文件夹里的终端,执行:openspec init
用上下方向键选择一个你正在用的AI编程工具。

它就会在你的项目里新建一个openspec文件夹。

然后它就提示你,把以下提示词发送给你的AI:

通过你发给AI的这一串提示词,AI就能秒懂OpenSpec这个文件夹的意思,按照OpenSpec的规范来生成文档。

提示词中的“Your Feature Here” 可以替换成一两句话简单的目标。我们不指望一次性能表达清楚。后续可以进一步深聊需求,AI会反复更改proposal文档,从而实现对需求分析的严格把控。

13、熟悉了这一套模式后,如果我要对项目增加新功能,不再是想到一出是一出,而是让AI生成一个OpenSpec proposal,比如我这里有许多proposal,都是我期待的未来新功能想法,因为我怕我忘记,但不着急实现,就让AI先做成一个个proposal了。后续实现一个,就归档一个。


后续你还可以用openspec list命令行看有哪些未完成的proposal,用openspec view 命令行来看当前dashboard情况。
当然,像我们用可视化IDE编辑器的人来说,没必要记这些命令,让AI来执行生成proposal、修改proposal、最后归档proposal这些任务。

14、实测感想:

OpenSpec适合项目的从1——>n,尤其配合最新的Claude Opus 4.5,基本上一改一个准。

需求聊个三五轮,代码一次到位。

这又是AI编程中的“卧槽”时刻。

15、OpenSpec 虽然是神兵利器,但它对团队纪律要求极高。

很多小任务,员工可能会觉得,“明明我用AI一次对话,分分钟就能完成,但你非要我写文档,却要三五轮对话才能完成”,“写代码还要先写一堆文档,太繁琐了”,最后导致 Spec 文档和实际代码脱节,变成新的形式主义。

Spec Coding 的本质不是工具,而是流程变革。 它需要配合Git 工作流的改造、Code Review 标准的升级才能真正落地。

工具免费,但“让工具在团队里跑通”的经验,才是最昂贵的。

关于作者: 苏江

热门文章

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注