云计算百科
云计算领域专业知识百科平台

Spec-Driven-Development 规范驱动开发指南

软件工程行业正经历自高级编程语言诞生以来最重大的转折点。像Claude Code、Codex、PI、Open Code等工具现在已经能够以极限速度编写、测试,甚至重构代码。但是能保证准确度的推理不是一种资产,而是一种负担。

大多数使用 AI 编程 Agent 的团队都在摸着石头过河。向 Agent 发出提示(prompt)、接收输出、修补错误、然后重复。这个循环会随着代码库复杂度的增长而不断降低质量。根本原因不在于 AI,而在于缺乏一个向 Agent 传达明确意图的纪律性框架。

规范驱动开发(Spec-Driven Development,SDD)就是那个框架。它是一门工程学科,将Structure Spec(结构化规范)视为软件交付的主要产出物。

Why Spec ?

Vibe Coding 通过对话式描述期望结果并通过非正式提示迭代 AI 输出的实践。对于独立任务、快速原型设计和单会话实验确实有效。但是代码上规模了之后,往往会灾难性地崩溃,而精确理解它为何崩溃是构建更好方案的第一步。

每个 AI 编程会话都在一个上下文窗口(Context Window)内运行,即 Agent 在任何时刻能够推理的有限信息集合。在 vibe coding 会话中,项目的"状态"存在于提示历史中。随着对话的增长,早期的架构决策、安全约束和库选择会掉出窗口。然后 Agent 会进行听起来合理的替代,通常不会标记这种变化。有些人给这个现象起了个专业名词:上下文衰减(Context Decay)。

上下文衰减会产生一种特定的病理现象,称为实现漂移(Implementation Drift)。就是说 Agent 对正在构建内容的理解与业务最初需求实际已经出现了偏离,而 Agent 不自知。

Spec 原则

规范驱动开发建立在一个单一的架构原则之上:规范是主要产出物;实现代码是衍生输出。这不仅仅是工作流的改变,而且是对传统软件工程  Way of Woking 的根本性反转,在传统模型中代码是主要的,文档是次要的。

在 SDD 中,规范是机器可读的、版本控制的、活的、可执行的。它充当人类意图与 Agent 执行之间的契约。Agent 不进行解释或推断;它在约定契约的边界内实现。当约定契约是精确且准确的,那输出就是可预测的。当契约是模糊的,就会产生偏差。

核心原则:如果你没有精确定义想要构建什么,你就无法控制 Agent 构建的内容。Spec 中的精度是控制实现质量的核心。

Spec 六要素

Spec 最终是要给机器或者Agent 设计的,因此这些 Spec规范必须超越自然语言的歧义性。以下是六个基础要素,防止 Agent 做出不需要的假设:

  • 结果(Outcomes):具体的、可衡量的结果。"用户收到验证邮件并无错误地登录"优于"用户可以登录"。

  • 范围边界(Scope Boundaries):既包括范围内的事项,也关键地包括明确排除在范围外的事项。

  • 约束和假设(Constraints and Assumptions):技术栈决策、API 版本、安全要求。

  • 先前的决策(Prior Decisions):AI 必须尊重的已选择的数据库模式、库或架构模式。

  • 任务分解(Task Breakdown):可以独立执行和验证的离散的、有序的子任务。

  • 验证标准(Verification Criteria):实现必须满足的验收标准和边界情况。

  • SDD 工作流

    SDD 工作流被组织为四个顺序阶段,每个阶段都有定义明确的人类干预点(Human Intervention Point,HIP)。这些 HIP 是逐层递进的,每一个干预点都是为了防止下游链路出现错误。

    阶段 1:指定(Spec)

    开发者提供高层次的意图描述。Agent(或开发者单独)将其扩展为结构化的功能规范,涵盖用户旅程、业务成果、验收标准和明确的作用域边界。

    在这个阶段,开发者扮演的角色是架构审查:在任何实现计划开始之前,检查规范中的幻觉(hallucinations)、遗漏和误解。

    关键原则:如果阶段 1 存在歧义,永远不要进入阶段 2。一个模糊的规范不会产生模糊的实现——它会产生一个自信但错误的实现。

    阶段 2:计划(Plan)

    有了经过审查后的 Spec,Agent 将创建技术实现计划:架构决策、数据模型、API 协议和技术选型。该计划编码了组织约束,例如"使用 PostgreSQL 进行持久化"和"所有 API 端点需要 JWT 认证"。

    在此阶段的开发者需要审查 Agent 提供的 Planner 是否有问题。并能在数千行架构错误代码生成的代码之前就进行及时捕获并修正。

    阶段 3:任务分解(Task Breakdown)

    经过验证的 Plan 被分解为原子级的、可独立测试的任务列表。任务粒度是 SDD 中最被低估的变量。每个任务都应该能够在单个 Agent 执行周期内实现和验证。如果一个任务要求 Agent 同时在脑海中保持三个以上的独立关注点,那么它就太大了。

    阶段 4:实现与验证(Implement and Verify)

    有了清晰、经过验证的任务列表,Agent 逐个任务地实现代码。输出是聚焦的、可审计的,并且可追溯回特定的规范要求。

    此阶段需要配有一个验证器(Verifier)模式:一个 Agent 生成代码,第二个 Agent(或自动化测试套件)根据规范的验收标准验证输出。

    总结

    规范驱动开发不是临时趋势,也不是对现有工作流的渐进式改进。它是对工程工作本质的根本性重新调整。AI 编程 Agent 的时代明确地揭示了一件事:软件交付中的瓶颈不再是语法构建的速度。它是意图定义的精度。

    规范是产品。代码是实现它的东西。在 Agent 软件构建的时代,Spec 会慢慢变成工程师最重要的可交付成果。

    如果你喜欢更多文章,请扫描二维码关注
    在这里插入图片描述

    赞(0)
    未经允许不得转载:网硕互联帮助中心 » Spec-Driven-Development 规范驱动开发指南
    分享到: 更多 (0)

    评论 抢沙发

    评论前必须登录!