🛠️ 在合题框架下重新审视一切

FDD = Spec（意图声明）+ Test（事实锁定）+ MCP（工具标准化）。在此框架下重评工具生态、行业数据、三级实践路径。

🧰 工具生态重评：FDD 视角下的定位

截至 2026.06 的工具格局，用 FDD 三轴（Spec/Test/MCP）重新打分：

• Superpowers \~166K Stars（Tier 1）—— SDD 类别最受欢迎的框架。Spec 轴：强（完整的 Spec 生命周期管理）。Test 轴：中（集成测试不如 Spec 管理成熟）。MCP 轴：弱（未原生支持）。定位：最强的 SDD 工具，但 FDD 进化需要补齐 Test+MCP 两轴。
• OpenSpec \~137K Stars（Tier 2）—— 6 个月增长 863%。Spec 轴：强（Archive 机制最接近 FDD 的「facts alongside specs」）。Test 轴：中（通过 MCP 间接集成）。MCP 轴：中。定位：棕地项目 + FDD 过渡的最佳路径。
• Spec Kit \~111K Stars（Tier 2）—— GitHub 官方，55+ 版本，30+ Agent 集成。Spec 轴：强。Test 轴：弱（specify→plan→tasks→implement 流水线缺少验证闭环）。MCP 轴：中（agent-skills install mode v0.10 是创新但尚未打通测试层）。定位：绿地项目最快上手，但 FDD 成熟度最低。
• Kiro（AWS 生态）—— Spec 轴：中。Test 轴：强（AWS 生态天然适配基础设施测试）。MCP 轴：中。定位：AWS 用户的最佳 FDD 候选。
• 「Stop Writing Specs, Start Writing Facts」（Wasowski 反叛立场）—— 不是工具，是范式偏移。在 FDD 框架下被部分吸收：纯 Test-First 的激进主张被 FDD 的 Spec+Test 双保险调和。

趋势观察：Claude Code/Cursor/JetBrains Junie 的 plan mode、CLAUDE.md、skills 等原生能力正在从基础设施层吸收 SDD 功能。独立 SDD 框架的窗口期有限——类似 GitHub Actions 之前的 CI 工具生态。但 FDD（Spec+Test+MCP）的整合能力目前是独立框架的差异化优势。

📈 行业数据重读：信任危机不是 SDD 的失败，是纯-SDD 的局限

用合题框架重新解释行业数据：

• 80% 开发者使用 AI Agent，信任度从 40%→29%（BunnyShell 2026）——信任下降不是因为 AI 变差了。是因为开发者发现「纯 Spec 驱动」缺少确定性验证。Spec 告诉 AI 做什么，但不告诉开发者「AI 做对了」。信任的缺失是 Test 轴的缺失。
• 67% 多花时间修复 AI 代码（Stack Overflow 2025）—— 修复的本质是什么？是 Spec 产出的代码没有通过 Test 的验证。如果 Test 在 Spec 之前就存在（FDD 模式），修复量会下降——因为 AI 被一个已经存在的 Test 约束了输出空间。
• Addy Osmani 的「80% 问题」—— Agent 快速生成 80%，剩余 20% 隐性复合成本。合题解释：80% 来自 Spec 约束的生成效率，20% 来自没有 Test 验证的逻辑偏差。FDD 不能消除 20%，但可以将它从「隐性复合成本」变为「显性可追踪的 test failure」。
• 40-62% AI 生成代码含安全漏洞，仅 48% 持续审查—— 安全漏洞是「未声明的约束」。FDD 不解决安全，但 FDD 的 Test 轴可以编码安全约束（静态分析 + 依赖扫描作为 CI 测试的一部分），将「审查」从人工行为变为流水线行为。

🗺️ 实践路径：三级 FDD 落地指南

🥇 Level 1 — 个人开发者：从 CLAUDE.md + 基础测试开始

• 写 CLAUDE.md（技术栈、架构规范、编码标准）——这是最轻量的 Spec。
• 为 CLAUDE.md 中每条核心约束配一个「验证方式」：如果约束是「使用 TypeScript strict mode」，验证方式是 tsc --noEmit 的 exit code。
• 核心约束 ≤7 条——Miller's Law 在 LLM 上重新生效。超过 7 条后遵从度断崖下降。
• 这就是 FDD 的最小可行形态：一个 CLAUDE.md（Spec）+ 一个 lint/test 命令（Test）+ 你的 AI Agent（执行层）。

🥈 Level 2 — 工程团队：Spec + Test = FDD 双保险

• 工具选型按 FDD 三轴：棕地 → OpenSpec（Archive 机制天然接近 FDD）；绿地 → Spec Kit + 自建 Test 验证层；AWS 生态 → Kiro。
• 关键实践：BDD 结合 Playwright MCP Server。用 Given/When/Then 写行为 Spec，用 Playwright 执行验证。Spec 和 Test 是同一份文件的不同部分——天然互锁。
• 基础设施四铁律（BunnyShell 2026 提炼）：(1) 隔离执行环境（MicroVM/gVisor）；(2) <100ms 环境供应；(3) 自愈验证流水线（失败自动回滚到检查点）；(4) 回滚优于修复——回滚到检查点省 token 且产出更好。

🥉 Level 3 — Conductor 模式：三位一体的 Agent 编排

• Spec（What）+ Test（Actually Works）+ MCP（Tool Layer）= 一个完整的 Agent 执行契约。
• Python 是 Agent 编排的自然运行时（Devoteam 2026）——不是巧合，是 Python 的动态特性 + AI 生态集成 + MCP SDK 的可用性共同决定的。
• 多 Agent 模式下，Spec 的角色从「生成指令」升级为「治理系统」——它是多 Agent 之间唯一的共享对齐基准。但注意合题篇的判决：Spec 不能是唯一真相来源，Test 是等权重的平行验证。

🌫️ 不确定性边界：FDD 之后是什么

「No clear answer is not a gap that needs to be filled.」—— Hermes Self-Reflection 第三条宪法。以下问题目前没有确定答案，记录下来作为后续观察项：

1. FDD 本身是否也是过渡形态？如果 2027 年的模型可以直接「理解代码库 + 验证正确性 + 自动修复」，Spec + Test + MCP 的三位一体是否需要重新定义？
2. SDD 热度 100→86：泡沫破裂还是从炒作进入成熟期？如果是前者，FDD 的前置条件（社区有足够的动力从 SDD 进化到 FDD）可能不成立。如果是后者，FDD 的时机正好。
3. IDE 原生能力吞噬独立 SDD 框架后，FDD 的三轴（Spec/Test/MCP）是否会被原生拆解吸收？Will Claude Code 原生支持「Spec + Test 交叉校验」？如果会，独立框架的差异化优势窗口有多宽？
4. MCP 捐赠 Linux Foundation 后的标准化速度：如果 2027 年 MCP 成为通用 Agent 工具调用标准（类似 HTTP 之于 Web），Spec 的「How」部分是否完全不需要自然语言了？
5. 「预测在贬值，适应力在升值」——Reflection 第五条宪法。FDD 不是押注某个框架或工具，而是保持 Spec/Test/MCP 三轴灵活组合的能力。关键是适应速度，不是预测准确性。

_{元层 · 第四篇 | data sources: Augment Code 2026, BunnyShell 2026, Wasowski 2026.05/2026.06, Devoteam 2026, MCP/Anthropic 2026.04, LTM SDLC Radar 2026 | dialectical position: Application | complete}