限制、权衡与现实
我们应该问的问题
Robert Matsuoka 的批判性分析认为，规范驱动开发（SDD）具有双重目的：解决实际问题，但也提供"证明企业采购合理性并使估值脱节的治理叙事"。
公平的问题。让我们诚实地解决它。
批评是有效的
1. TDD 并行警告
关注点： 测试驱动开发尽管已被证明有益，但在 20 年后的采用率仍 <20%。由于时间压力、cargo cult 实践和采用障碍而失败。
SDD 的类似风险： 该方法论要求在实现之前有完整的规范——这正是软件已经挣扎了 50 年的事情。
我们的回应： LeanSpec 明确拒绝"预先完整规范"。我们的上下文经济原则（少于 300 行）和意图优于实现方法专注于捕获为什么/什么，而不是详尽的如何。我们不是要求瀑布需求——我们是要求足够的意图来协调人类和 AI。
2. 70% 自动化神话
关注点： 真实世界的 METR 研究发现，开发人员使用 AI 实际上花费了 19% 更长时间，尽管他们相信自己快了 20%。"70% 自动化"的声明被夸大了——它只是总开发工作的 27%（39% 编码时间 × 70% 自动化）。
我们的回应： 我们不承诺自动化百分比。 LeanSpec 是关于对齐和意图文档，而不是自动化声明。现实结果：通过更好的人机协作实现 10-30% 的生产力提高，而不是消除人类工作。
3. AI 代理仍然会犯错
关注点： Martin Fowler 的实验表明，尽管有详细的规范，AI 代理仍然会生成未请求的功能，中途改变假设，并在构建失败时声称成功。
Fowler 的引用： "由于这项技术的非确定性本质，它做我们不想要的事情的概率总是会非常高。"
我们的回应： 我们同意。 规范不能消除 AI 的不可预测性——它们减少了它。目标不是自主编码；而是人类审查的更明智的 AI 建议。规范提供的上下文使 AI 输出更符合意图。
4. SDD 可能是过渡性的
关注点： "如果模型变得足够确定和上下文感知，规范就成为不必要的开销。"
我们的回应： 可能是真的。 如果 AI 变得足够好，您可能需要更少的结构。但即使那样：
- 人与人之间的对齐仍然需要文档
- 捕获意图（而不仅仅是实现）的规范更持久
- 渐进式披露意味着随着 AI 的改进，您可以使用更少的结构，而不是放弃方法论
我们今天有用是因为 AI 不可预测。如果 AI 显著改进，相应地调整。
规范是表演的地方
让我们具体说明规范何时成为治理表演而不是生产力工具：
❌ 表演：规范作为复选框练习
- 症状： 编写规范以证明预算合理，但不衡量结果
- 示例： 企业要求规范用于采购，但批准后没有人阅读它们
- 结果： 浪费精力，没有对齐好处
❌ 表演：完整的预先需求
- 症状： 在任何编码之前要求详尽的规范（瀑布陷阱）
- 示例： 试图在发现之前指定每个边缘情况的 2,000 行 PRD
- 结果： 上下文溢出，陈旧的文档，AI 无法帮助
❌ 表演：AI 无论如何都会忽略的规范
- 症状： 编写 AI 不读或无法适应上下文窗口的规范
- 示例： 超过令牌限制的冗长文档
- 结果： 人力浪费，AI 在没有规范上下文的情况下生成代码
❌ 表演：僵化的流程胜过实用主义
- 症状： 无论变更大小如何都需要多步骤工作流程
- 示例： 错误修复需要规范 → 计划 → 任务 → 批准 → 实现
- 结果： 流程开销扼杀速度
规范增加价值的地方
当规范真正改善结果时，而不仅仅是勾选合规框：
✅ 价值：复杂功能的团队对齐
- 场景： 多个开发人员需要协调理解
- 好处： 共享的真实来源防止不同的实现
- 结果： 更少的返工，更快的进展
✅ 价值：意图保留
- 场景： 决策需要文档以供将来参考
- 好处： 捕获"为什么"，而不仅仅是"如何"
- 结果： 未来的更改尊重原始约束和权衡
✅ 价值：AI 上下文不会溢出
- 场景： 功能对于纯 vibe 编码来说太复杂
- 好处： 少于 300 行的规范适合 AI 上下文窗口
- 结果： AI 实际读取并将规范纳入建议
✅ 价值：渐进式完善
- 场景： 需求通过实现出现（规范驱动开发风格）
- 好处： 规范随着学习而演变，保持对齐
- 结果： 保持相关的活文档
理论基础：Rice 定理
人类参与必要的更深层原因来自计算机科学基础。
Rice 定理（1951）证明所有程序的非平凡语义属性都是不可判定的——没有算法可以确定任意程序是否具有任何有趣的行为特征。
这对 SDD 意味着什么
不可判定的问题： "这个程序做用户想要的事情吗？"（需要理解未定义的意图）
可处理的问题： "这个程序满足这些明确的规范吗？"（检查定义的需求）
关键见解： 规范不能"解决"不可判定性——它们提供使验证可处理的语义基础。人类定义"正确"的含义；AI 在这些约束内生成实现和测试。
为什么 AI 不能取代人类规范
Rice 定理解释了原因：
- 语义属性不可判定 - AI 无法算法地确定您想要什么
- 规范提供基础 - 人类将意图转换为可检查的断言
- AI 放大，不取代 - AI 从人类提供的规范生成代码/测试
- 测试是采样，而不是证明 - 即使有规范，我们也通过启发式测试建立信心，而不是数学确定性
来自 Rice 定理文章：
"理解完全测试自动化在数学上是不可能的并不会让我们无助——它指导我们走向更有效的策略。关键见解是，我们可以通过将正式规范与 AI 驱动的测试生成相结合，显著提高测试有效性。"
这正是 LeanSpec 的哲学： 人类提供意图（规范），AI 放大规模（实现），两者都在理论约束内工作。
LeanSpec 与批评的不同之处
Hyperdev 文章批评像 Tessl（1.25 亿美元，只交付了测试版注册表）和僵化方法论这样的 SDD 框架。以下是 LeanSpec 的不同定位：
我们不是：
- ❌ 承诺 70% 自动化或自主编码
- ❌ 出售 1.25 亿美元的平台或 100 亿美元的 IDE
- ❌ 在任何代码之前要求僵化的 5 步工作流程
- ❌ 声称规范消除 AI 不可预测性
- ❌ 要求完整的预先规范
我们是：
- ✅ 免费、开源工具（没有风险投资，没有估值炒作）
- ✅ 对规范何时有帮助与何时有害持务实态度（明确的"何时不使用规范"指导）
- ✅ 工具不可知（适用于任何编辑器、任何 AI 助手）
- ✅ 解决真正的痛点：团队对齐、上下文腐烂、决策文档
- ✅ 从最小开始，仅在感到痛苦时添加结构（渐进式披露）
定位差异
来自文章： "SDD 充当质量控制表演...但该方法论还提供证明企业采购合理性并使估值脱节的治理叙事——它既是解决方案又是症状。"
LeanSpec 的立场： 我们是"解决方案"部分，没有"症状"部分：
- 规范增强判断力，它们不取代对代码库的理解
- 随团队成长的结构（单人 → 企业）
- 没有革新软件创建的承诺——只是务实的文档
在修正中幸存
Hyperdev 文章预测 AI 泡沫将在 18-24 个月内修正。以下是 LeanSpec 定位不同的原因：
幸存者共享这些特征
根据文章，幸存者将是"增强而不是取代核心能力"的工具。
那就是我们：
- 规范不取代编码判断——它们增强人机对齐
- 没有自主编码声明——只是更明智的建议
- 免费工具，没有需要证明的估值
- 在理论约束（Rice 定理）内工作，而不是违背它们
在修正中杀死公司的是什么
- 在"技术潜力"而不是付费客户上烧钱
- 承诺超出理论可能的自动化
- 不适应现实的僵化流程
- 与实际效用脱节的估值
LeanSpec 避免这些：
- 开源，没有资本燃烧
- 对限制诚实（没有 70% 自动化承诺）
- 渐进式披露（适应团队需求）
- 免费使用，价值以生产力而非估值衡量
诚实的评估
规范可以是表演。 当它们：
- 采购需要但没有人阅读它们
- 超出上下文限制的详尽预先需求
- 应用于琐碎变更的僵化流程
- 代码演变时保持静态的文档
规范增加价值时：
- 团队需要在复杂功能上对齐
- 意图必须持续超越对话
- 决策需要文档以供未来参考
- 规范适合 AI 上下文窗口并实际告知实现
- 结构逐步适应团队需求
LeanSpec 的哲学：
- 对限制诚实（Rice 定理证明完全自动化是不可能的）
- 从简单开始，仅在感到痛苦时添加复杂性（渐进式披露）
- 保持规范足够短以实际使用（<300 行，上下文经济）
- 专注于持久的意图（意图优于实现）
- 利用 AI 的优势，承认其弱点
您应该问的问题
不是："我应该使用 SDD 吗？"
而是："将意图形式化为规范是否为这项特定工作增加价值？"
当满足以下条件时回答是：
- 功能足够复杂，vibe 编码导致错位
- 团队需要共同理解
- AI 需要结构化上下文才能有效帮助
- 决策应该为未来的维护者记录
当满足以下条件时回答否：
- 变更琐碎且明显
- 您仍在探索和发现需求
- 开销超过好处
- 不会维护的原型
LeanSpec 为您提供在重要时有效说是的工具。
进一步阅读
- AI 泡沫文章 - 引发此评估的批评
- Rice 定理解释 - 为什么人类参与在数学上是必要的
- LeanSpec 第一原则 - 从约束中衍生的哲学
- 何时不使用规范 - 关于跳过规范的诚实指导
底线： 我们不是在卖革命。我们为一个真正的问题提供务实的工具——通过轻量级、可维护的规范保持人类和 AI 对齐。如果这是表演，那是真正改善表演的那种。