--- title: "规格驱动开发爱好者，你一定会喜欢 sdd-flow" date: "2026-03-31" description: "一个 Claude Code 技能，通过子代理编排规格驱动开发流程：研究、对抗性审查、规格制定、实现、代码审查和批判性审查，全部由单一命令触发。用它在两天内构建了 Redakt。" language: zh url: "https://pablooliva.de/the-closing-window/zh/spec-driven-development-fans-youll-love-sdd-flow/" markdownUrl: "https://pablooliva.de/the-closing-window/zh/spec-driven-development-fans-youll-love-sdd-flow.md" translations: - language: ar url: "https://pablooliva.de/the-closing-window/ar/spec-driven-development-fans-youll-love-sdd-flow/" - language: de url: "https://pablooliva.de/the-closing-window/de/spec-driven-development-fans-youll-love-sdd-flow/" - language: es url: "https://pablooliva.de/the-closing-window/es/spec-driven-development-fans-youll-love-sdd-flow/" - language: en url: "https://pablooliva.de/the-closing-window/spec-driven-development-fans-youll-love-sdd-flow/" ---
## TL;DR 构建了一个 Claude Code 技能，强制执行研究、规格制定、实现、批判性审查和代码审查，用于一次性完成功能开发。用它在两天内构建了 Redakt（GDPR PII 匿名化工具），实现了六个功能。技能和插件均为开源。
上周我发布了 [Redakt](https://github.com/pablooliva/redakt)，一个开源的 GDPR 合规工具。它为 Web UI 和 REST API 提供了六个功能，帮助我们更好地处理 PII（个人身份信息，Personally Identifiable Information）。 几个月来，我一直通过自己构建的一个[插件](https://github.com/pablooliva/claude-plugins)使用规格驱动开发（SDD）流程。当我看到 Claude 将上下文窗口扩展到一百万个 token 时，我心想："为什么不试着突破我开发软件方式的极限？"我的意思是，SDD 流程最初是为了帮助管理上下文而创建的。它遵循传统且严格的软件开发周期，但相对于 AI 领域的发展速度来说太慢了。我决定尝试用一个[技能](https://github.com/pablooliva/claude-skills)来编排开发周期的各个阶段，一次性完成功能开发——结果出乎意料地顺利。 技能并不是唯一优化流程的因素。Anthropic 上周发布的 `--permission-mode auto` 是推动我摘掉"安全裤"的最后一把力。我兴奋地试用了它。这个模式目前仅限于 Teams 账户。起初不太稳定，但它让我尝到了禁果的滋味。我不想再回到每个请求都要手动确认的日子。在家里，我知道还有另一个选项，一个危险的选项，一个我一直回避的选项：`--dangerously-skip-permissions`。用了将近一年的 Claude，从没出过任何"完蛋了"的时刻，我决定移除所有护栏，绕过权限检查。那感觉就像你在战斗机飞行员的视频中看到的那样，脸被重力往后推，飞行速度达到好几个马赫……而且这种感觉会上瘾。 --- ## SDD，不是 STD 不是 STD——我的语音转文字模型经常把它打错。规格驱动开发（Specification-driven development）引导 AI 研究代码库和需求，编写规格说明，然后依据规格实现功能。规格成为你进行版本控制和审查的对象，而代码只是输出物。 我喜欢这个概念，也很享受它带来的成果。 --- ## `/sdd-flow` 做什么 `/sdd-flow` 是一个 [Claude Code](https://docs.anthropic.com/en/docs/claude-code) 技能，一个自定义斜杠命令，你用一个任务来调用它： ``` /sdd-flow Add GDPR-compliant audit logging for all anonymization requests ``` 然后一个子代理流水线接管工作。每个子代理是独立的 Claude 对话，拥有全新的上下文窗口，各自负责一个阶段。 **研究。** 第一个子代理调查代码库。对于 Redakt 的审计日志功能，它梳理了现有的日志设置，发现了一个我不知道的重复处理器 bug，并标记出代码中的 schema 与原始规格已产生偏差。它生成了一份包含文件路径、具体行号和集成点的研究文档。 **对研究的对抗性审查。** 第二个子代理对研究成果发起挑战。针对审计日志，它发现了真实问题：六个关键缺口、四个存疑的假设、四个被忽视的视角。 **规格制定。** 一个规划子代理读取经过审查的研究成果，编写完整的规格说明：功能需求、边界情况、失败场景、安全约束。 **对规格的对抗性审查。** 针对审计日志，这一步发现了一个问题：如果在审计层修复，将意味着对上游共享函数进行侵入性改动。 **实现、代码审查、批判性审查。** 依据规格编写代码和测试。一个代码审查子代理检查与规格的对齐情况，而一个批判性审查子代理进行最终的对抗性审查。所有发现，无论严重程度如何，都必须在提交前解决。 --- ## `/sdd-flow` 的样子 `/sdd-flow` 完成后，你会得到这样一个目录： ``` SDD/ ├── research/ │ └── RESEARCH-006-audit-logging.md ├── requirements/ │ └── SPEC-006-audit-logging.md ├── prompts/ │ ├── PROMPT-006-audit-logging-2026-03-29.md │ ├── implementation-complete/ │ │ └── IMPLEMENTATION-SUMMARY-006-...md │ └── context-management/ │ └── progress.md └── reviews/ ├── CRITICAL-SPEC-audit-logging-20260329.md └── CRITICAL-IMPL-audit-logging-20260329.md ``` --- ## 一个技能，两种模式 监督模式是默认模式，因为它迫使你做出通常不应该自动化的关键决策。这些决策包括：审查已完成的研究，以及在提交前审查代码。 自主模式适用于需求明确、你感到足够自信的功能。在前两个功能验证了流程之后，我在 Redakt 的部分后续功能中使用了它。但暂停审查是默认设置，原因很简单——自信往往是过度自信。 --- ## 试一试 技能和插件均为开源： - **技能**（编排器）：[claude-skills](https://github.com/pablooliva/claude-skills) - **插件**（阶段命令）：[claude-plugins](https://github.com/pablooliva/claude-plugins) - **Redakt**（用它构建的项目）：[redakt](https://github.com/pablooliva/redakt)，查看 `SDD/` 目录了解完整的工件记录 Redakt 的 `SDD/` 目录中的工件是我能做出的最好说明。读一读研究文档、规格说明，尤其是批判性审查。然后，就让 SDD 流动起来。