OpenSpec、Superpowers 和 Spec Kit：SDD 实践模式
对比 OpenSpec、Superpowers 与 GitHub Spec Kit，总结 SDD 中可复用的规格、计划、任务、测试、评审和证据模式。
标签：流程实践
流程实践相关文章集合，覆盖规格评审、上线回滚、质量门禁、治理机制和团队协作习惯。
AI 编码前的规格包：先给边界，再让它写代码
围绕「AI 编码前的规格包：先给边界，再让它写代码」展开，说明可测试输入、预期结果、边界条件和评审标准，帮助 QA 与开发提前对齐，可直接用于规格评审、实现前对齐和测试计划补充。
AI 编码治理：用规格驱动的 Prompt 设立边界
用 spec-driven prompts 治理 AI 辅助编程：提示词必须包含什么、AI 必须遵守哪些边界，以及让“这是 AI 写的”变成可核验声明的审计链。
AI 编码 PR 评审：用验收标准衡量通过与否
围绕「AI 编码 PR 评审：用验收标准衡量通过与否」展开，说明可测试输入、预期结果、边界条件和评审标准，帮助 QA 与开发提前对齐，可直接用于规格评审、实现前对齐和测试计划补充。
AI 编码合并前风险登记：merge 之前要追踪的条目
围绕「AI 编码合并前风险登记：merge 之前要追踪的条目」展开，说明如何用规格约束 AI 编码、保留人工评审点，并用证据判断实现是否达标，可直接用于规格评审、实现前对齐和测试计划补充。
AI 编码的测试证据门禁：为什么通过用例还不够
AI 写出的代码读起来都像能跑。有时候它甚至能通过自己写的那套测试。我现在的规矩是：不信代码，不信测试，只信"这些测试真的能抓住真实 bug"的证据。下面讲的，就是我在合并前如何把这份证据落成具体文件。
AI 生成客户端下的 API 变更治理
上个季度打到我 API 上的集成，有一半是那种从来没读过我文档的人写出来的。开发者在 Cursor 里敲一句含糊的提示词，Claude 或 Copilot 给什么就接什么，接完就上线。
API Schema Diff 上线前评审实战
上线前如何做 API schema diff 评审：自动化 diff 工具能抓到什么、漏掉什么，以及 OpenAPI 和 GraphQL 仍然需要人工检查的那些点。
Spec Skills 与 Spec-First 交付：实际如何结合
大多数 AI 编码工具都在为一个目标做优化：让东西在未来十分钟内跑起来。Spec Skills 优化的是另一件事——确保生成出来的代码，就是你当初真正要的那个东西。
AI 辅助开发下的规格质量门禁
围绕「AI 辅助开发下的规格质量门禁」展开，说明如何用规格约束 AI 编码、保留人工评审点，并用证据判断实现是否达标，可直接用于规格评审、实现前对齐和测试计划补充。
契约测试计划：从 OpenAPI 到 CI
围绕「契约测试计划：从 OpenAPI 到 CI」展开，说明契约字段、兼容边界、失败路径和评审检查点，帮助团队在上线前减少集成风险，可直接用于规格评审、实现前对齐和测试计划补充。
事件驱动系统的规格模式：契约与消费语义
事件驱动系统的规格范式：事件 schema 版本化、command 与 fact 事件的区分、choreography 与 orchestration 的取舍、幂等处理器，以及最终一致性边界的明确表达。
高风险发布的上线与回滚设计
一个团队的工程成熟度，最能看出来的时刻不是 code review，而是他们怎么描述凌晨三点出事之后的应对流程。大多数上线计划死在"我们会密切监控"这句话上——这话从来没救过谁。
编写 QA 可以实际测试的边界条件
"合理处理边界情况。"我几乎每周都能在 spec 里看到这句话。它什么都没说。QA 没法测试"合理"——他们需要具体的输入、具体的触发条件、具体的预期结果。下面是我写边界情况的方式，让 QA 不用追问一句就能把它们变成测试用例。
软件规格中的 10 个常见错误
我评审过的每一个失败项目都有 spec。问题是 spec 里没写真正重要的那些事。下面这十个错误在我评审过的 spec 里反复出现——我自己写的也不例外。它们都不难修，但在截止日期的压力下，每一个都容易被漏掉。
如何在团队中推行 Spec-First（30 天计划）
在团队里推 Spec-First，本质上是个组织问题，不是技术问题。模板是最容易做的事，难的是养成习惯。如果你是那个想说服团队开始写规格的人，你大部分精力都会花在证明"它能省时间"上，而不是教大家怎么写。
PRD 与技术规格的区别
把 PRD 和技术规格混为一谈的团队，最后写出来的文档两头不讨好。PRD 是一份给人看的产品文档，用来判断一件事 值不值得做 。技术规格是一份给人看的工程文档，用来决定 怎么做 以及 到底做成什么样 。
编码前的规格评审清单
大多数规格评审只是走过场。三个人扫一眼文档，有人写一句"LGTM"，然后所有人带着同样的模糊地带继续往前走。真正的规格评审，会抓住那些一周之后会让你付出代价的东西。下面这份清单，是我在放任何规格通过评审之前都会过一遍的。
什么是 Spec-First 开发？（完整指南）
一个团队如果交付很快但不断返工，并不是在跑得更快——而是在烧跑道。问题几乎总是一样的：没人在编码之前写清楚"完成"是什么意思。Spec-First 开发解决这个问题——在实现之前定义验收标准，而不是之后。