📚 喵喵的笔记库

03-SDD与Spec驱动

9分钟阅读

SDD 与 Spec 驱动

Spec-Driven Development 是 Harness Engineering 在团队层面的落地方法——先写规格说明书再写代码，把人的思考前置，让 AI 执行。 前置 → 02-核心架构 | 企业案例 → 05-企业实战案例

🧠 我的心智模型

SDD 是什么：

(例：SDD 就是给 AI 写一份详细的"施工图纸"再让它干活，而不是口头说"帮我盖个房子") ✍️ 你的理解：

[来源：RedHat] RedHat 提出了两阶段工作流来落地 SDD：第一阶段生成 Repository Impact Map（仓库影响地图）——分析需求会影响哪些文件、哪些模块、哪些依赖；第二阶段基于影响地图生成 Structured Task Template（结构化任务模板）——每个任务都有明确的文件范围、预期变更描述和验收标准。这比直接"给 spec 就开干"更稳健，因为先分析影响范围能大幅减少 Agent "改了 A 坏了 B"的问题。

Spec 的本质：

(例：Spec 是人和 AI 之间的"合同"——明确交付物、约束和质量标准) ✍️ 你的理解：

[来源：Anthropic] Anthropic 的 Sprint Contract 机制给 Spec 增加了一个维度：可测试性。Spec 只定义高层意图是不够的，必须填补到"能写测试来验证"的粒度。每个 sprint contract 是一个原子交付单元，包含：要做什么、怎么做、怎么验证。这个思路和 RedHat 的 Structured Task Template 异曲同工。

渐进式复杂度：

(例：简单需求不需要复杂流程，改个字段不用先写 spec 再拆 tasks) ✍️ 你的理解：

[来源：12-Factor Agents] 12-Factor Agents 项目提出了 Agent 应用的 12 个最佳实践因子，而 12-Factor AgentOps 则补充了运维层面的 12 个因子。两者共同指向一个核心原则：Structure in, structure out——你给 Agent 的输入结构化程度越高，Agent 的输出就越可靠。这和 SDD 的渐进式复杂度完美吻合：简单需求用 Rules 就够（最低结构化），复杂需求用 Spec + Tasks（高结构化），关键是按需升级，不要一刀切。

🎯 核心问题

  1. SDD-RIPER 方法论的核心思想是什么？和传统开发流程有什么区别？
  2. Spec Coding 的"渐进式复杂度"框架怎么设计？什么情况下用 Rules 就够了？
  3. No Spec No Code 原则在实践中会不会太严格？怎么平衡灵活性和规范性？
  4. 搜狗输入法的跨端 Spec Coding 工程化，对多平台项目有什么启发？

📝 我的理解

SDD 理论

✍️

[来源：综合] "Structure in, structure out" 是贯穿所有 SDD 方法的底层原则。不管是 RedHat 的两阶段工作流、Anthropic 的 Sprint Contract、还是阿里云的渐进式 Spec，本质上都是在做同一件事：在 Agent 开始执行之前，先注入足够的结构化信息。这些结构化信息不是约束 Agent 的创造力，而是减少 Agent 在不确定性上浪费的 token——把认知负荷从"猜需求"转移到"执行明确任务"。

渐进式 Spec

✍️

⚡ 我的实战

✍️ 我自己做过什么、踩过什么坑。

🔒 关书自测

  1. SDD 的核心流程是什么（Specify→Plan→Implement→Validate）？每个阶段的关键输出？
  2. 渐进式 Spec 的三层（Rules → Spec → Tasks）分别解决什么问题？
  3. Propose → Apply → Review → Archive 工作流的设计逻辑是什么？
  4. knowledge/ 目录和 rules/ 目录的区别是什么？为什么知识比规则更重要？

🎤 费曼输出

1 句话版本:✍️ 3 分钟版本:✍️ 信心:_/10 最可能翻车的地方:✍️

参考资料

SDD-RIPER 三部曲（阿里云开发者）

  1. 觉醒篇：从传统编程转向大模型编程 — 为什么必须转
  2. 内功篇：AI 原生研发范式：从"代码中心"到"文档驱动"的演进 — 完整理论体系
  3. 落地篇：SDD-RIPER 团队落地指南 — 可执行的团队落地方案
  4. 实战篇：2026 年 AI 编码的"渐进式 Spec"实战指南 ⭐⭐⭐ — 渐进式复杂度框架（Rules → Spec → Tasks 按需加载）、编排层+执行层两层 Agent 架构、Propose→Apply→Fix→Review→Archive 完整工作流、code_copilot 框架完整目录结构
  5. 评测篇：搭建 AI First 评测平台 — AI 自动生成评测集→自主运行→提交报告→自动优化→循环迭代，三轮过夜优化 90.7→97.4→99.1
  6. 实战篇2：从玩具到生产力：用真实项目讲透 AI Agent 的 Harness Engineering ⭐⭐⭐ — Aegis 项目实战复盘。架构四象限矩阵、伪 Harness 识别、8 阶段 SOP、三层目标控盘、sdd-riper-one-light 工具骨架
  7. 实战篇3：Harness Engineering：耗时一周，将 AI Coding 率提升至 90% ⭐⭐⭐ — 存量 Java 应用 Harness 落地。AI Coding 率从 24.86%→90.54%
  8. 实战篇4：告别"氛围编程"：基于 Harness 治理和 SDD 的团队级 AI 研发范式演进 ⭐⭐⭐ — 高德团队。出码率从 53%→80-90% 但提效不明显——研发是全链路问题

Spec Coding 核心原则

来源：多篇实战文章综合

  1. No Spec, No Code — 没有文档，不准写代码
  2. Spec is Truth — 文档和代码冲突时，错的一定是代码
  3. Reverse Sync — 执行中发现 spec 与实际不符，先修 spec 再修代码
  4. 渐进式复杂度 — 简单需求不承担复杂流程的成本，改个字段不需要先写 spec 再拆 tasks
  5. 知识比规则更重要 — 一个没有 knowledge/ 的 Spec 框架，就像让刚入职的应届生对着编码规范写代码——规范都能遵守，但业务逻辑全靠猜

Propose → Apply → Review → Archive 工作流

Propose: 生成完整 spec.md + tasks.md + log.md（确认门控 HARD-GATE）
Apply:   逐步执行 tasks，每个 task 都是原子可提交的
Review:  spec-reviewer + code-quality-reviewer 双阶段审查
Archive: 完成后归档，知识沉淀到 knowledge/

跨端 Spec Coding 实践

  • 搜狗输入法 Kuikly：Spec coding 的探索与落地 ⭐⭐⭐ — 跨端项目（Android/iOS/鸿蒙/H5）的 Spec Coding 工程化。GAN 思路构建 AI 上下文文档生成器（生成器vs评估器多轮对抗），AI 编码准确率提升 114%

团队落地方法

关系图谱

反向链接