Codebuddy使用CloudBase MCP辅助AI编码基于Spec工作流开发的坦克大战小游戏

引言

在上一篇文章《浅谈AI辅助编码从氛围编程Vibe Coding到基于spec规范驱动开发》中小马已经介绍了AI辅助编码的各种阶段，也介绍了基于spec规范驱动开发的概念和优缺点。为了避免理论空谈，我们今天来体验一下整个流程。

一、什么是基于Spec的工作流

基于上一篇文章，这个属于老生常谈了。

基于命令驱动的Spec工作流 又叫做 “基于命令驱动的规范文档流程”，是一种以规范文档驱动AI进行软件开发的方法论。它强调在编写代码前，先通过结构化文档明确需求、设计和技术方案，引导AI生成更精准、高质量、可维护的代码，确保开发过程可控、可协作、可复盘。

其核心是通过一系列规范文档（如 requirements.md, design.md, tasks.md）来明确“做什么”、“怎么做”以及“如何一步步实现”，将人类的决策、评审和AI的高效执行相结合。

一个 Spec 可以说是一个规格/规范，如果用过BDD (行为驱动开发) 可能就会比较熟悉这个名词。

Spec 是用来解决如何把模糊的想法转化为详细的实施计划、跟踪和验收标准的问题。

每个 Spec 都是一个文件夹，下有 3 个核心文件：
requirements.md —— 需求文档（用 EARS 语法写用户故事和验收标准）
design.md —— 技术方案（架构、流程、注意事项）
tasks.md —— 任务清单（todolist，便于跟踪）

基于Spec的工作流是一种以结构化文档为核心的软件开发方法，它将开发过程系统地划分为需求分析、技术设计和任务拆分三个阶段，旨在提升AI辅助编程的工程化水平、可追溯性和协作效率。

该工作流的核心理念是通过生成标准化文档来消除需求歧义、确保设计完整性，并驱动精细化执行。具体而言，它强制在编码前创建requirements.md（需求文档）、design.md（设计文档）和tasks.md（任务清单），这些文档保存在项目的.kiro或.spec目录下，形成可迭代的开发链条。 例如，需求分析阶段采用EARS（Easy Approach to Requirements Syntax）语法规范用户故事和验收标准，技术设计阶段生成系统架构图和接口定义，任务拆分阶段则将设计转化为离散的可执行步骤。

在AI编程场景中，Spec工作流通过自动化文档生成和多代理协作实现高效开发。AI代理（如spec-analyst、spec-architect、spec-developer）分别负责不同阶段，例如从用户描述自动生成requirements.md，再基于此生成design.md，并最终分解为tasks.md。 开发者可通过斜杠命令（如/spec、/no_spec）控制流程，AI会根据任务复杂度智能判断是否启用完整工作流。 这种模式显著减少了上下文遗忘和需求偏差，例如在Claude Code或Kiro等工具中，文档更新会触发级联同步，确保各阶段一致性。

Spec工作流的优势体现在多个方面：首先，它通过文档化实现全流程可追溯，便于团队协作和后期维护；其次，AI承担需求梳理和设计草案生成，人类开发者可专注于决策与评审，提升整体效率；最后，结构化约束减少了错误率，尤其适用于新功能开发、复杂架构设计等场景。 该方法起源于AWS Kiro AI IDE，现已成为前端工程化和AI编程的最佳实践之一。

通俗理解起来可以这么理解，传统vibe coding就是输入需求等AI输出结果，而Spec工作流首先接收需求然后会输出类似requirements.md文档，该文档包含了AI对本次需求的理解和描述，此时人需要去评审AI所理解的需求并更正，OK后进行下一步；AI会继续输出类似design.md的设计思路文档，人评审修改确认后点击下一步；最后AI输出tasks.md文档，描述了具体任务实现的逻辑方式比如包含技术栈等，人评审修改确认后点击下一步开始执行生成代码。

我们发现两者的最大不同在于，Spec工作流在每一步会进行人工的确认，通常这一个步骤被称为“需求澄清”。Spec工作流是一个概念，具体实现各有不同（流程命令也可以自己根据需要更改），但凡没有具备“需求澄清”这个环节的都不能称为真正的Spec工作流。

二、基于Spec的工作流实现方式

小马认为Spec其实是一个概念，如何实现这个工作流开发流程实则有很多种方法，各不相同。

1、专为规范驱动设计的IDE

有些IDE自带了支持该模式的功能，比如Cursor、Kiro、
Codebuddy（若是IDE安装的Codebuddy插件则插件自带“Plan”模式可支持，若是直接下载的Codebuddy IDE则支持直接编辑spec命令，然后通过命令唤起流程，即基于命令驱动的Spec工作流）。

2、集成规范驱动功能的工具或插件

比如GitHub上的Spec-Kit、OpenSpec、CloudBase AI ToolKit等，可以通过CLI或集成到IDE中。

比如下文将介绍的CloudBase AI ToolKit框架的CloudBase MCP方式就是其中的一种。

三、实践开发坦克大战小游戏

我们以CloudBase MCP方式来尝试开发一款经典的坦克大战小游戏。我们来沉浸式体验一下基于spec的开发过程。

1、IDE Codebuddy插件安装CloudBase MCP

我们使用phpstorm IDE 先安装Codebuddy插件，可以自行点击链接进入本文不再赘述。

安装完插件后我们根据CloudBase官方git安装CloudBase MCP，这种方式比较方便。

{"mcpServers":{"cloudbase":{"command":"npx","args":["@cloudbase/cloudbase-mcp@latest"]}}}

配置完之后我们看到绿色状态正常即可，这种方式非常方便。

还有一种安装方式是CloudBase AI CLI，本文不赘述。

npminstall@cloudbase/cli@latest -g

2、需求澄清

我们在Codebuddy对话框内输入需求，你也可以称为“模糊需求”。

开发一款坦克大战小游戏。请调用MCP来进行spec工作流，要求每一步都需要我澄清确认在执行。

它开始工作了。

我们可以看到左侧已经输出了spec的需求描述文档。

由于是演示案例，我们假装看都不看，默认需求可以，让它继续。当然，在任一个环节中如果对生成的文档内容需要修改则可以按需修改即可，这也是spec工作流的核心优势。

它还不放心了，于是人工进行了一番勾选确认之后让它继续。

3、技术方案设计

我们可以看到此时左边输出了技术设计方案文档md。

4、任务分解

我们看到左侧生成了task.md文档。

5、技术实现

我们可以看到，确认任务分解之后它就开始执行技术代码实现了。

我们可以看到它吭哧吭哧已经把项目写完了，大概5分钟之内的时间。

我们使用浏览器打开项目，如下方向控制OK，发射子弹也OK。一个简单的坦克大战demo已经完成。

总结

至此AI编码基于Spec工作流开发的坦克大战小游戏就完成了，我们体验了整个流程的开发。基于Spec的AI编码辅助，确实可以解决AI抽盲盒的困境，将软件开发周期流程拆解，人工与AI交互并干预到每一步的确认，确保生成的代码可控。

小马抛砖引玉，感谢评阅，欢迎交流。