3 篇文章带有标签 “sdd”

HTML 版本

1. OpenSpec 是什么

OpenSpec 是一套规约驱动开发（Spec-Driven Development）的工作流工具。它要解决的问题是：在 AI 智能体参与编码的场景下，如何让"想清楚 → 写计划 → 写代码"这三个动作不互相污染，并且让代码之外还有一份可追溯的事实来源。

1.1 两种产物

产物	位置	回答的问题	生命周期
specs（规格）	openspec/specs/<capability>/spec.md	系统现在是什么行为（已交付、已归档的能力）	长期存在，随每次归档增量演进
changes（变更）	openspec/changes/<change-name>/	这一次要改什么（尚未实现的计划）	完成后整体移入 changes/archive/

一句话：specs/ 是唯一事实来源，changes/ 是待实现的增量，archive/ 是它是如何达成的历史。

关键差别在于 specs/ 是能力（capability）维度、changes/ 是变更维度。同一个能力会被多次变更反复修改，每次修改只写"增量"（delta），不重写整份规格。

1.2 五步循环

每个变更都走同一条闭环，本项目严格落在这条闭环上：

flowchart LR
    E["1 · Explore<br/>和智能体一起想清楚"] --> P["2 · Propose<br/>Agent 起草方案（不写代码）"]
    P --> R["3 · Review<br/>你修正方案"]
    R --> A["4 · Apply<br/>Agent 逐项构建"]
    A --> AR["5 · Archive<br/>增量写入 specs 并归档"]
    AR -. "下一次变更" .-> E

若渲染环境不支持 Mermaid，可读作线性流程：Explore → Propose → Rev

原文：Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl 作者：Birgitta Böckeler（Thoughtworks 杰出工程师、AI 辅助交付专家，拥有 20 多年软件开发、架构与技术领导经验） 本文是"Exploring Gen AI"系列的一部分。该系列记录了 Thoughtworks 技术专家对使用生成式 AI 技术进行软件开发的探索。

我一直在尝试理解 AI 编程领域最新的流行语之一：规约驱动开发（Spec-driven development，SDD）。我研究了三个自称 SDD 工具的产品，并试图厘清截至目前它到底意味着什么。

定义

与这个快节奏领域中许多新兴术语一样，"规约驱动开发"（SDD）的定义仍在变化之中。以下是我从目前见到的用法中归纳出的理解：规约驱动开发意味着在用 AI 编写代码之前先编写一份"规约"（"文档先行"）。这份规约成为人与 AI 共同的真理来源（source of truth）。

GitHub："在这个新世界中，维护软件意味着演进规约。［……］开发的通用语言上移到了更高层次，而代码只是最后一公里的实现手段。"

Tessl："一种开发方法，其中规约——而非代码——是

以下是 IBM 文章 《什么是规范驱动开发？》（What is Spec-Driven Development?） 的中文翻译：

作者： Anna Gutowska（IBM AI 工程师、开发者倡导者）

发布日期： 2026年5月19日

规范驱动开发的定义

规范驱动开发（Spec-Driven Development, SDD） 是一种软件开发方法论。在正式编码之前，团队需先编写并达成一份关于实现细节的详细规范（Specification）。换句话说，这份规范将作为“构建什么”以及“如何构建”的唯一真实来源（Single source of truth）。

随着 Microsoft GitHub Copilot、Anthropic Claude Code 或 IBM Bob 等 AI 工具与编程助手的普及，生成代码的门槛已大幅降低。基于先进 AI 模型的 LLM 驱动型 AI Agent，只需用户输入一条自然语言提示词（Prompt），即可随时实时运行一系列迭代任务。

对于软件开发而言，这意味着我们可以优化并自动化构建原型、新功能、单元测试等的开发工作流。生成代码从未如此简单。然而，“氛围程序员”（Vibe Coders）需要警惕一个潜在风险：AI 的表现上限完全取决于它所接收到的指令质量。

技术债务的抬头：一个典型场景

你可能在现实世界中见过技术债务，甚至自己都没意识到。