OpenSpec、Superpowers 和 Spec Kit:SDD 实践模式
对比 OpenSpec、Superpowers 与 GitHub Spec Kit,总结 SDD 中可复用的规格、计划、任务、测试、评审和证据模式。
基础概念相关文章集合,解释 Spec-First 开发、验收标准、技术规格和团队落地流程。
对比 OpenSpec、Superpowers 与 GitHub Spec Kit,总结 SDD 中可复用的规格、计划、任务、测试、评审和证据模式。
同一个订单退款功能,分别用 vibe coding 和 spec coding 两种方式实现。前者 10 分钟出活却花两周修 bug,后者 90 分钟写 spec 后零线上事故。完整对比。
网上大多数验收标准示例都太浅,没法直接用到实际项目中。本文给你 20 个生产级的真实示例,覆盖认证、电商、API、数据处理和通知五大领域——全部采用 Given/When/Then 格式,可以直接复制到你的规格文档里。
技术规格(spec)是软件工程中最被低估的工具。这篇文章带你逐一拆解 spec 的每个部分,展示一份完整的真实案例,并给你一个可以直接复制使用的模板——还有一个免费的在线生成器。
写测试和搭建测试 Harness 是两种截然不同的工程工作。测试验证行为,而 Harness 是让这些测试在成百上千次运行、数十位工程师协作中保持确定性、快速且可维护的基础设施。
Superpowers 是一个开源框架,为 AI 编码智能体强制执行 Spec-First 纪律。了解其强制流水线——头脑风暴、规格、计划、TDD、验证——如何在 AI 辅助工程时代验证规格驱动开发的价值。
你在周五下午发布了 API 的新版本。到周一早上,三个下游团队已经提交了故障工单,因为他们的集成全部崩溃了。他们依赖的字段被重命名了,一个枚举新增了一个值但他们的 switch 语句没有 default 分支,一个之前返回 null 的
迁移文件是永久性的。一旦它在生产环境中运行,你无法撤销它,只能再写一个迁移来修正。然而大多数团队写迁移的方式和写应用代码一样:打开编辑器,开始敲列定义,约束条件边写边想。
为什么 AI 编程工具会加上你根本没要求的校验逻辑,把下游还有消费者的字段随手重命名,还生成一堆超出任务范围的辅助函数?因为你丢给它的是一个"要解决的问题",而不是一份"要遵守的 spec"。
用 spec-driven prompts 治理 AI 辅助编程:提示词必须包含什么、AI 必须遵守哪些边界,以及让“这是 AI 写的”变成可核验声明的审计链。
围绕「为 Agentic 客户端设计 API 规格」展开,说明契约字段、兼容边界、失败路径和评审检查点,帮助团队在上线前减少集成风险,可直接用于规格评审、实现前对齐和测试计划补充。
大多数 AI 编码工具都在为一个目标做优化:让东西在未来十分钟内跑起来。Spec Skills 优化的是另一件事——确保生成出来的代码,就是你当初真正要的那个东西。
围绕「AI 辅助开发下的规格质量门禁」展开,说明如何用规格约束 AI 编码、保留人工评审点,并用证据判断实现是否达标,可直接用于规格评审、实现前对齐和测试计划补充。
项目能否按时交付,最大的预测指标不是目标清单——而是非目标清单。写了明确非目标的团队,大致能按计划完成。没写的团队,往往在三周后还在争论某件事到底算不算在范围内。我见过的每一个延期的项目,非目标章节要么缺失,要么就只有孤零零一行字。
在团队里推 Spec-First,本质上是个组织问题,不是技术问题。模板是最容易做的事,难的是养成习惯。如果你是那个想说服团队开始写规格的人,你大部分精力都会花在证明"它能省时间"上,而不是教大家怎么写。
"可测试"的规格并不是用某种特殊语言写成的规格。它是一份每一条声明都能由未参与撰写的人来核验的规格。这个门槛听起来不高,其实不然。我审阅过的大多数规格在第一轮就过不了这关——包括我自己写的。
把 PRD 和技术规格混为一谈的团队,最后写出来的文档两头不讨好。PRD 是一份给人看的产品文档,用来判断一件事 值不值得做 。技术规格是一份给人看的工程文档,用来决定 怎么做 以及 到底做成什么样 。
一个团队如果交付很快但不断返工,并不是在跑得更快——而是在烧跑道。问题几乎总是一样的:没人在编码之前写清楚"完成"是什么意思。Spec-First 开发解决这个问题——在实现之前定义验收标准,而不是之后。