🧭 SDD 解决了一个真问题

Non-deterministic 的 LLM 需要 Deterministic 的约束框架——这不是工具选择，是认知法则。

📊 SDD 解决了什么真问题：Vibe Coding 不是玩笑，是真代价

「Vibe Coding」——用自然语言 Prompt 让 AI 生成代码，不满意就重来——听起来像解放。数据说的是另一回事。

不是写得快就写得好。你今天让 AI 写的和昨天让它写的，可能不是同一个东西。66% 的开发者最困扰的是「差一点就对的 AI 方案」——不是完全错，是差一点。这种「差一点」最耗人，因为你不能扔掉，也不能直接用，只能修。

Google 2026.04：75% 的新代码是 AI 生成的。Spotify 最佳开发者自 2025.12 起未手写代码——不是因为不需要写，而是因为写的人变成了修的人，而「修」这个角色的痛苦远超「写」。

🔍 根因：Underspecification — AI 欠的不是算力，是规约

Vibe Coding 的代价不是「AI 不够聪明」。AI 很聪明——它只是不知道你要什么。当你用一句 Prompt 描述需求，AI 要填补 90% 的未声明决策：边界条件、错误处理、命名规范、架构分层、性能约束、兼容性要求。它每次填的都不一样——这就是 1.7x 波动性的根源。 Underspecification（欠规约命题）是根本病因。三重独立证据指向同一个结论：

• METR 2025：AI 辅助的真实效率是负的——因为修复欠规约产生的偏差消耗了生成节省的时间。
• CodeRabbit：同一需求的代码波动性 1.7x——不是 AI 不稳定，是你的 prompt 没有足够的约束让 AI 稳定。
• MIT CSAIL：仅 50% 符合预期——另一半不符合是因为你「没说出来」的约束被 AI 随意填充了。

结论：不约束 AI 的探索空间，它就帮你探索到不可维护的方向去。欠规约不是 AI 的问题——是你的问题。

💡 SDD 的核心洞察：约束创造自由

Spec-Driven Development 提出的核心见解不是「写文档」。它是一条认知法则：

这条法则的认知地基来自 Miller's Law——人类工作记忆容量 7±2。在 AI Agent 上也重新生效：超过 7 个并行约束后，Agent 遵从度断崖式下降。SDD 工程化的本质是：把无限可能的探索空间压缩到 Agent 能精准执行的有限空间内。不是「限制 AI 做更多」——是「让 AI 在受限空间内做到极致」。 这恰是 Hermes Self-Reflection skill 反复警告的：精确在错的层面分析（如黑铁匠追踪锤子设计创新而汽车已至）是比模糊分析更危险的失败模式。SDD 之所以正确，不是因为它提供了一套工具——而是因为它把分析从「工具层」（哪个 AI 写得好）提升到了「约束框架层」（什么条件下 AI 能写得对）。

🪜 SDD 三阶成熟度：从 CLAUDE.md 到 Spec-as-Source

Martin Fowler / arxiv 2602.00180（首篇 SDD 学术论文，提交 AIWare 2026）提出的三阶框架：

1. Level 1 — Spec-First：先写 Spec 再让 AI 执行。一个 CLAUDE.md 文件描述技术栈和编码规范即可入门。大部分团队从这里开始。
2. Level 2 — Spec-Anchored：Spec 和代码并行维护、共同演进、交叉校验。这是当前工程化的主流位置。Allegro 2026 最佳实践指南聚焦在此。
3. Level 3 — Spec-as-Source：只编辑 Spec，不碰代码。代码完全是 AI 从 Spec 生成的衍生品。对应 Devoteam 2026 描述的「Spec 成为活跃的操作合约」。但——这是本文的伏笔——Level 3 有一个未被充分讨论的前提：Spec 本身必须跨 LLM 版本稳定。它是吗？

🎭 角色演化：从执行者到架构师

SDD 带来的不是工具升级，是角色认知重构：

1. Manual Coder → 手写代码。AI 是配角。产出：代码。
2. Cleanup Engineer → 修 AI 代码。这是当前大多数开发者的真实状态——感知快 20%，实际慢 19%。产出：修复后的代码。
3. Spec Architect → 核心产出不再是代码，而是约束框架。你写 Spec，AI 生成代码，你验证。对应 SDD Level 2。
4. Conductor（指挥） → 同时管理 Spec（What）、Test（是否正确）、MCP（用什么执行）。这超越 SDD Level 3——因为你意识到 Spec 本身也只是意图声明，不是真理。

当前大部分团队卡在 Level 2 到 Level 3 之间。跃迁的关键不是学新工具——是完成认知转变：你的核心产出不是代码，是约束框架。

❓ 未回答的问题——通往反题篇的入口

SDD 的论证框架有一个隐含假设：Spec（用自然语言写的需求/架构/规范）是稳定的、跨 LLM 版本可复现的。但这是真的吗？ 如果一份 Spec 在 Claude Sonnet 3.7 下生成正确代码，在 Sonnet 4 下生成错误代码——那么 Spec-as-Source（Level 3）的整个成熟度模型就建立在沙子上。这正是第二篇文章要深挖的裂缝。

_{元层 · 第一篇 | sources: KB-009/012/074/093 | dialectical position: Thesis | next: Antithesis}