# 需求写成工序：规格驱动四件横评 ## 概述 本期是本栏 Skills 生态定期观察的赛道横评轮，镜头对准「规格驱动开发」（Spec-Driven Development）这条赛道。一句话需求丢给 Agent 就开工的写法，今年在真实项目里撞了墙：需求漂移、返工无据、验收全靠感觉。于是货架分化出四个方案，赌的是同一件事——需求必须先变成 Agent 可读、可验收的中间产物；分歧在于中间产物长什么样：GitHub 官方的 spec-kit 把需求写成**工序**，claude-task-master 把需求写成**任务台账**，BMAD-METHOD 把需求写成**角色剧本**，OpenSpec 把需求写成**变更对账单**。本期对四件做纸面横评：不实测、不读源码，机制描述以各家仓库公开自述为准，评分为编辑判断，能核实的数字注明出处，核实不了的明说。 ## 评测对比表 权重沿用本栏固定口径：功能 25%、设计 25%、实战 20%、上手 15%（越高越省事）、社区 15%。 | 选手 | 功能完整度 | 设计质量 | 实战效果 | 上手友好 | 社区活跃 | 加权 | |---|---|---|---|---|---|---| | github/spec-kit | ★★★★★ | ★★★★ | ★★★★ | ★★★ | ★★★★★ | **4.25** | | claude-task-master | ★★★★ | ★★★★ | ★★★★ | ★★★★ | ★★★★ | **4.00** | | Fission-AI/OpenSpec | ★★★ | ★★★★★ | ★★★ | ★★★★★ | ★★★ | **3.80** | | BMAD-METHOD | ★★★★★ | ★★★★ | ★★★ | ★★ | ★★★★ | **3.75** | ## 一、这条赛道在争什么 Vibe coding 的甜头和苦头是同一枚硬币：demo 十分钟，真项目两周后没人说得清「当初到底要做什么」。需求只存在于对话记录里，Agent 每次开工都在重新猜一遍，改一处崩三处，验收时甲方和 Agent 各执一词。 规格驱动的药方只有一张：**开工之前，需求先落盘成结构化文档，Agent 按文档施工，文档就是验收标准**。但「需求落盘」有四种落法，四个选手各押一种： - 押**工序**的，认为需求要经过宪法、澄清、规划、拆解一整条流水线才可信； - 押**任务**的，认为规格最终都要翻译成一张可勾销的清单，清单就是真相源； - 押**角色**的，认为一个人扮演不全 PM、架构师、测试，文档应该从角色会商里长出来； - 押**变更**的，认为规格不是一次写完的圣旨，而是随每次改动持续对账的活账本。 ## 二、四位选手速写 ### 1. github/spec-kit：官方下场修流水线 **定位**：GitHub 官方出品的规格驱动工具包，把「从需求到代码」切成七道slash 命令工序：`/speckit.constitution` 立项目宪法（不可妥协的技术与产品原则），`/speckit.specify` 写规格，`/speckit.clarify` 强制澄清，`/speckit.plan` 出技术方案，`/speckit.tasks` 拆任务，`/speckit.analyze` 做交叉一致性校验，最后 `/speckit.implement` 施工。本站变现栏 5 月底曾记录其星值约 10 万量级（2026-05-08 快照，见参考来源）。 **亮点**有两处值得单说。一是 **clarify 是显式工序**：大部分工具默认需求写完就能开工，spec-kit 把「向人提问补齐歧义」做成独立关卡，问题不问完不许进规划——这是把需求工程里最贵的返工源头直接焊死在流程上。二是 **analyze 的交叉对账**：规格、方案、任务三份产物互相校验，发现「任务里做了规格没要求的事」就标红，等于给 Agent 的自作主张加了一道审计闸。它对宿主的适配也是四家最广，Claude Code、Copilot、Gemini CLI、Cursor 等十余种 Agent 都有对应模板。 **短板**是仪式感偏重。七道命令、多份模板产物，单人小项目跑完全套，流程开销可能超过代码本身；命令词法（constitution、specify）也有学习成本，团队里得先有人把这套词法教会所有人。 **安装**（以仓库 README 为准）： ```bash uvx --from git+https://github.com/github/spec-kit.git specify init 项目名 --ai claude ``` 初始化后，项目里会出现 `.claude/commands/` 下一整套 speckit 斜杠命令，Claude Code 里直接调用。 ### 2. claude-task-master：任务台账是一等公民 **定位**：老牌热门件（社区常称 Task Master），路线是「PRD 进、任务出」。把产品需求文档喂给 `parse-prd`，生成一份结构化的 `tasks.json` 台账；之后 `analyze-complexity` 给每条任务标复杂度，太粗的用 `expand` 拆细，`next` 按依赖关系挑出当前该干的那条。 **亮点**在于它把任务做成了**可查询、可更新的数据结构**，而不是散落在对话里的自然语言。Agent 每次开工先查台账、干完即勾销，断点续传和多人分工都有了锚点；它还能以 MCP server 形态常驻，让任务台账成为 Agent 的工作记忆数据库。模型可插拔，主力模型和研究模型分开配置的思路也务实。 **短板**：规格层薄。PRD 之外的「为什么这么定」没有栖身之处，需求变更时缺一道正式的修订仪式——台账会更新，但理由不留档；另外需要自备各家模型的 API key，配置门槛比纯模板件高一截。 **安装**： ```bash npm install -g task-master-ai cd 你的项目 && task-master init ``` ### 3. BMAD-METHOD：一整套敏捷剧团 **定位**：名字展开是 Breakthrough Method for Agile AI-Driven Development，本质是把敏捷团队的编制搬进 Agent：分析师、PM、架构师、开发、QA 各自是一个带人设和产出物模板的角色，绿地/棕地项目各有工作流，文档按角色会商分片产出，支持 IDE 与网页两种运行形态。 **亮点**是**覆盖面最全**：从市场调研、用户故事、架构决策到开发与 QA 交接，每个环节都有对应的角色和产物模板，等于自带一套研发管理制度。对多人协作的真团队，这套剧本比单人工具更接近「AI 参与的正规交付」。 **短板**同样直白：概念和配置量四家之最，上手分只给两星；小项目会被角色流程压垮——写个爬虫也要先过分析师和 PM 两道会；角色轮换意味着反复装载不同的人设与模板，上下文开销在四家里最高。 **安装**（以仓库 README 为准）： ```bash npx bmad-method install ``` ### 4. Fission-AI/OpenSpec：变更提案当对账单 **定位**：轻量派。项目里维持两个柜子：`specs/` 存「当前为真的规格」，`changes/` 存「正在发生的变更」。每次新需求先写一份提案（改哪些能力、加哪些验收场景），批准后 apply 落盘，做完 archive 归档——变更从提案到归档三步走完。 **亮点**是把规格从「一次性圣旨」改成了**持续对账的活文档**。审查单位从整个项目缩小到一次变更，diff 清晰可读，AI 改了什么、依据哪份提案，翻 changes 柜就对得清。三件套 slash 命令（proposal、apply、archive）心智负担极低，不押特定 Agent 宿主。设计分给到五星：四家里概念最干净的一个。 **短板**：年轻。模板、案例、周边生态都比前三家薄，流程之外没有护栏，纪律靠用户自律；深度流程（跨仓规格、多团队合并）尚需时间验证。本期纸面评估，其实战表现留待回访。 **安装**（以仓库 README 为准）： ```bash npx openspec init ``` ## 三、一张图看四条产线 ```mermaid flowchart TD R["一句需求"] --> S R --> T R --> B R --> O S["spec-kit
七道工序"] T["task-master
任务台账"] B["BMAD
角色剧团"] O["OpenSpec
变更对账"] S --> S1["宪法先行"] S1 --> S2["规格与澄清"] S2 --> S3["方案与任务"] S3 --> S4["交叉审计后施工"] T --> T1["PRD落盘"] T1 --> T2["tasks.json台账"] T2 --> T3["复杂度分析拆细"] T3 --> T4["按依赖逐条勾销"] B --> B1["分析师与PM会商"] B1 --> B2["架构师出方案"] B2 --> B3["开发与QA轮换"] O --> O1["写变更提案"] O1 --> O2["批准后落盘"] O2 --> O3["归档进规格柜"] ``` ## 四、推荐排行榜 - **总榜**：spec-kit（4.25）＞ task-master（4.00）＞ OpenSpec（3.80）＞ BMAD-METHOD（3.75） - **流程完备榜**：spec-kit ＞ BMAD ＞ task-master ＞ OpenSpec —— 要闸门最多、最防自作主张，选 spec-kit - **轻装上阵榜**：OpenSpec ＞ task-master ＞ spec-kit ＞ BMAD —— 个人项目、增量迭代，从 OpenSpec 进 - **任务颗粒度榜**：task-master ＞ spec-kit ＞ BMAD ＞ OpenSpec —— 长周期项目要断点续传，台账形态最稳 - **团队剧本榜**：BMAD ＞ spec-kit ＞ OpenSpec ＞ task-master —— 真团队要研发制度，只有 BMAD 交付了编制 - **上下文经济榜**：OpenSpec ＞ task-master ＞ spec-kit ＞ BMAD —— 在意 token 账单，仪式越少越省 一句话选型：**新项目要全流程保险，spec-kit；老项目管任务，task-master；老项目对账变更，OpenSpec；小团队要制度，BMAD。** 四件并非互斥，实务里常见 task-master 管执行、OpenSpec 管规格修订的组合——工序可以拼装，前提是需求先落盘。 ## 参考来源 1. [github/spec-kit](https://github.com/github/spec-kit) — GitHub 官方规格驱动工具包，七道工序命令与多 Agent 适配的口径出处 2. [Meet GitHub Spec-Kit: An Open Source Toolkit for Spec-Driven Development](https://www.marktechpost.com/2026/05/08/meet-github-spec-kit-an-open-source-toolkit-for-spec-driven-development-with-ai-coding-agents/) — MarkTechPpost 对 spec-kit 的独立介绍（2026-05-08） 3. [本刊存档：GitHub 可变现仓库评估（2026-05-30）](output/2026-05-30/github-monetizable-r3-2354.md) — spec-kit 星值约 10 万量级、更新时间的存档记录 4. [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec) — 轻量规格驱动工具，specs 与 changes 双柜结构的口径出处 5. [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master) 与 [bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD) — 任务台账件与敏捷剧团件仓库入口；四件安装参数均以各自仓库 README 为最终口径，本期未实测 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。