通过规范驱动开发 (SDD) 解决 AI 漂移

在当前的 AI 辅助编程领域，开发者经常发现自己需要同时应对多种工具——Claude Code、Cursor、GitHub Copilot 和 Windsurf——来构建单个功能。虽然这些工具在技术上令人印象深刻，但一个反复出现的问题出现了：AI 漂移。你可能会要求 Claude 构建一个功能，结果在要求 Cursor 修复 Bug 时，它却违背了之前的实现，而 Copilot 在清理代码时又发明了第三种解释。

其根本原因是缺乏一个共享的真相来源。如果没有一个集中的规范，每个 AI Agent 都会用自己的假设来填补你指令中的空白。为了解决这个问题，一个新的 Claude 技能——规范驱动开发 (SDD) 已发布，旨在强制 AI Agent 在编写任何一行代码之前，先在了一组管理文档上达成一致。

核心框架：三个真相来源

SDD 的运作原理是规范必须先于实现。该技能引导 Claude 进行访谈并生成三个主要文件，作为项目的“宪法”：

  • requirements.md：定义系统必须做什么。它使用正式的“shall”语言和唯一的 ID（例如 REQ-001）来确保每个功能都是可追溯的。
  • design.md：定义系统将如何构建，涵盖架构和数据模型。
  • tasks.md：一个原子的、有序的实现计划，其中每个任务都链接回特定的需求。

通过首先建立这些文件，开发者创建了一个硬性关卡。AI 工具被指示在触碰代码之前必须完整阅读这些文件，从而有效地阻止了由 Agent 假设分歧引起的漂移。

跨 AI 同步

SDD 技能最强大的方面之一是其能够生成特定于工具的配置文件，而这些文件都指向同一个通用指令。

工具 配置文件
Claude Code CLAUDE.md
Cursor .cursorrules
Windsurf .windsurfrules
GitHub Copilot .github/copilot-instructions.md
Aider .aider.conf.yml

这些文件中的每一个都包含一个通用指令块。该指令块强制要求 AI 在执行任何操作之前必须阅读需求、设计和任务文件，并建立了一个“分歧协议”：如果实现必须偏离设计，AI 必须立即停止，描述冲突，并等待用户批准更新设计文件后方可继续。

处理现有代码库

SDD 不仅仅适用于新项目。对于现有代码库，该技能执行“改造”。它通过逆向工程当前代码的状态来生成需求和设计文件的 v0-retrofit 版本。至关重要的是，设计文件会在推断出的字段上标记 [TO VERIFY]，强制开发者在添加新功能之前验证 AI 对现有架构的理解。

严格的验证与测试

与许多 AI Prompt 或“技能”不同，该框架由一套全面的测试套件支持。该项目包含跨三个阶段的 130 个断言：

  1. 静态断言 (Phase 2A)：64 项检查以确保生成文件的结构完整性。
  2. 行为测试 (Phase 2B)：13 项实时会话测试以验证 AI 对 SDD 流程的遵循程度。
  3. 生成质量 (Phase 2C)：针对已提交的固定测试用例进行 53 项检查，以确保输出的一致性。

这种测试优先的方法确保了技能本身不会引入它试图解决的不稳定性。

批判性视角与局限性

虽然该框架提供了一个稳健的结构，但社区已就可扩展性提出了重要的考量。一位评论者指出，随着 requirements.md 和 tasks.md 的规模增长，它们可能会消耗大量的上下文窗口空间，从而可能导致“上下文腐烂”并增加在大型代码库中产生幻觉的可能性。

此外，该项目目前处于公开测试阶段，正在寻求各种类型的测试者——从完全的初学者到使用多种 AI 工具的团队负责人——来完善该技能如何处理自然语言触发器和复杂的现实世界工作流。

防止的错误模式总结

通过强制执行规范优先的工作流，SDD 主动防止了以下几种常见的 AI 编程陷阱：

  • “直接开始写代码”陷阱：当用户试图跳过规划阶段时，该技能会予以回绝。
  • 模糊性捏造：AI 不被允许猜测模糊的需求，而是被强制要求请求澄清。
  • 范围蔓延：未列在 requirements.md 中的功能会被标记为超出范围，防止 AI 添加不必要的复杂性。

Sources