跳到主要内容

限制、权衡与现实预期

我们应该问的问题​

Robert Matsuoka 的批判性分析 认为，Spec 驱动开发（SDD）具有双重目的：解决实际问题，但也提供"治理叙事，为企业采购和脱离实际的估值提供正当理由"。

公平的问题。让我们诚实地解决它。

批评是有效的​

1. TDD 平行警告​

关注点： 测试驱动开发在 20 年后的采用率不到 20%，尽管有经过验证的好处。由于时间压力、货物崇拜实践和采用障碍而失败。

SDD 的类似风险： 该方法论要求在实施前有完整的Spec——这正是软件 50 年来一直在努力解决的问题。

我们的回应： LeanSpec 明确拒绝"预先完整Spec"。我们的 上下文经济 (Context Economy) 原则（少于 2,000 Token）和 意图优于实现 (Intent Over Implementation) 方法专注于捕获为什么/什么，而不是详尽的如何。我们不要求瀑布式需求——我们要求有足够的意图来对齐人类和 AI。

2. 70% 自动化神话​

关注点： 现实世界的 METR 研究发现，尽管开发人员认为他们快了 20%，但使用 AI 实际上花费了 19% 更长 的时间。"70% 自动化"的说法被夸大了——它只占总开发工作的 27%（39% 编码时间 × 70% 自动化）。

我们的回应： 我们不承诺自动化百分比。 LeanSpec 是关于对齐和意图文档，而不是自动化声明。现实结果：通过更好的人机协作实现 10-30% 的生产力改进，而不是消除人类工作。

3. AI 代理仍然会犯错​

关注点： Martin Fowler 的实验表明，尽管有详细的Spec，AI 代理仍然会生成未请求的功能，在中途更改假设，并在构建失败时声称成功。

Fowler 的引用： "由于这项技术的非确定性性质，它做我们不想要的事情的概率将始终保持非常不可忽略。"

我们的回应： 我们同意。 Spec不能消除 AI 的不可预测性——它们减少了它。目标不是自主编码；而是人类审查的更明智的 AI 建议。Spec提供的上下文使 AI 输出更符合意图。

4. SDD 可能是过渡性的​

关注点： "如果模型变得足够确定性和上下文感知，Spec就成为不必要的开销。"

我们的回应： 可能是真的。 如果 AI 变得足够好，你可能需要更少的结构。但即使如此：

  • 人与人之间的对齐仍然需要文档
  • 捕获意图（而非仅实现）的Spec会更持久
  • 渐进式披露 (Progressive Disclosure) 意味着随着 AI 的改进，你可以使用更少的结构，而不是放弃方法论

我们今天有用，因为 AI 是不可预测的。如果 AI 显著改进，请相应调整。

Spec何时成为作秀​

让我们具体说明Spec何时成为治理作秀而非生产力工具：

❌ 作秀：Spec作为勾选练习​

  • 症状： 编写Spec以证明预算的合理性，但不衡量结果
  • 示例： 企业需要Spec用于采购，但批准后没人阅读
  • 结果： 浪费精力，没有对齐好处

❌ 作秀：预先完整需求​

  • 症状： 在任何编码之前要求详尽的Spec（瀑布陷阱）
  • 示例： 2,000 行 PRD 试图在发现之前指定每个边缘情况
  • 结果： 上下文溢出，陈旧文档，AI 无法帮助

❌ 作秀：AI 无论如何都会忽略的Spec​

  • 症状： 编写 AI 不读或无法适应上下文窗口的Spec
  • 示例： 超过 token 限制的冗长文档
  • 结果： 人类努力浪费，AI 在没有Spec上下文的情况下生成代码

❌ 作秀：僵化流程优于实用主义​

  • 症状： 无论大小如何，所有更改都需要多步骤工作流
  • 示例： 错误修复需要Spec → 计划 → 任务 → 批准 → 实施
  • 结果： 流程开销扼杀速度

Spec何时增加价值​

当Spec真正改善结果，而不仅仅是勾选合规框时：

✅ 价值：复杂功能的团队对齐​

  • 场景： 多个开发人员需要协调理解
  • 好处： 共享的真相来源防止分歧的实现
  • 结果： 更少的返工，更快的进展

✅ 价值：意图保留​

  • 场景： 决策需要文档以供将来参考
  • 好处： 捕获"为什么"，而不仅仅是"如何"
  • 结果： 未来的更改尊重原始约束和权衡

✅ 价值：AI 上下文而不溢出​

  • 场景： 功能太复杂，无法进行纯粹的氛围编码
  • 好处： 少于 2,000 Token 的Spec适合 AI 上下文窗口
  • 结果： AI 实际上阅读并将Spec纳入建议

✅ 价值：渐进式细化​

  • 场景： 需求通过实施出现（Spec 驱动开发风格）
  • 好处： Spec随着你学习而演变，保持对齐
  • 结果： 保持相关性的活文档

理论基础：赖斯定理​

需要人类参与的更深层次原因来自计算机科学基础。

赖斯定理（1951）证明程序的所有非平凡语义属性都是 不可判定的——没有算法可以确定任意程序是否具有任何有趣的行为特征。

这对 SDD 意味着什么​

不可判定的问题： "这个程序做用户想要的吗？"（需要理解未定义的意图）

可处理的问题： "这个程序满足这些明确的Spec吗？"（检查定义的需求）

关键见解： Spec不能"解决"不可判定性——它们提供使验证可处理的语义基础。人类定义什么是"正确"；AI 在这些约束内生成实现和测试。

为什么 AI 无法取代人类Spec​

赖斯定理解释了为什么：

  1. 语义属性是不可判定的 - AI 无法通过算法确定你想要什么
  2. Spec提供基础 - 人类将意图转化为可检查的断言
  3. AI 放大，而不是取代 - AI 从人类提供的Spec生成代码/测试
  4. 测试是采样，而不是证明 - 即使有Spec，我们通过启发式测试建立信心，而不是数学确定性

来自赖斯定理文章的引用：

"理解完全测试自动化在数学上是不可能的并不会让我们束手无策——它引导我们采用更有效的策略。关键见解是我们可以通过将形式Spec与 AI 驱动的测试生成相结合来显著提高测试有效性。"

这正是 LeanSpec 的哲学： 人类提供意图（Spec），AI 放大规模（实施），两者都在理论约束内工作。

LeanSpec 与批评的不同之处​

Hyperdev 文章批评了 SDD 框架，如 Tessl（$125M，仅交付 beta 注册表）和僵化的方法论。以下是 LeanSpec 的不同定位：

我们不是：​

  • ❌ 承诺 70% 自动化或自主编码
  • ❌ 销售 $125M 平台或 $10B IDE
  • ❌ 在任何代码之前要求僵化的 5 步工作流
  • ❌ 声称Spec消除 AI 不可预测性
  • ❌ 要求预先完整Spec

我们是：​

  • ✅ 免费、开源工具（无风险投资，无估值炒作）
  • ✅ 关于Spec何时帮助与伤害的实用主义（明确的"何时不使用Spec"指导）
  • ✅ 工具无关（适用于任何编辑器、任何 AI 助手）
  • ✅ 解决真正的痛点：团队对齐、上下文腐烂、决策文档
  • ✅ 从最小开始，仅在感到痛苦时添加结构（渐进式披露）

定位差异​

来自文章： "SDD 作为质量控制作秀发挥作用...但该方法论还提供治理叙事，为企业采购和脱离实际的估值提供正当理由——它既是解决方案又是症状。"

LeanSpec 的立场： 我们是"解决方案"部分，没有"症状"部分：

  • Spec增强判断，它们不取代对代码库的理解
  • 随着团队成长的结构（独奏 → 企业）
  • 不承诺革新软件创建——只是实用的文档

在修正中幸存​

Hyperdev 文章预测 18-24 个月内 AI 泡沫修正。以下是 LeanSpec 定位不同的原因：

幸存者共享这些特征​

根据文章，幸存者将是"增强而非取代核心能力"的工具。

那就是我们：

  • Spec不取代编码判断——它们增强人机对齐
  • 没有自主编码声明——只是更明智的建议
  • 免费工具，没有需要证明的估值
  • 在理论约束内工作（赖斯定理），而不是对抗它们

修正中扼杀公司的因素​

  • 在"技术潜力"而非付费客户上烧钱
  • 承诺超出理论可能的自动化
  • 不适应现实的僵化流程
  • 脱离实际效用的估值

LeanSpec 避免这些：

  • 开源，无资本消耗
  • 诚实对待限制（无 70% 自动化承诺）
  • 渐进式披露（适应团队需求）
  • 免费使用，价值以生产力而非估值衡量

诚实的评估​

Spec可能是作秀。 当它们是：

  • 采购所需但没人阅读
  • 超出上下文限制的详尽预先需求
  • 应用于琐碎更改的僵化流程
  • 代码演变时保持静态的文档

Spec何时增加价值：

  • 团队需要复杂功能的对齐
  • 意图必须在对话之外持续
  • 决策需要文档以供将来参考
  • Spec适合 AI 上下文窗口并实际告知实施
  • 结构逐步适应团队需求

LeanSpec 的哲学：

  • 诚实对待限制（赖斯定理证明完全自动化是不可能的）
  • 从简单开始，仅在感到痛苦时添加复杂性（渐进式披露）
  • 保持Spec足够短以实际使用（<2,000 Token，上下文经济）
  • 专注于经得起时间考验的意图（意图优于实现）
  • 利用 AI 的优势，承认其弱点

你应该问的问题​

不是："我应该使用 SDD 吗？"

而是："将意图形式化为Spec是否为这项特定工作增加价值？"

何时回答是：

  • 功能足够复杂，氛围编码导致错位
  • 团队需要共同理解
  • AI 需要结构化上下文才能有效帮助
  • 决策应为未来维护者记录

何时回答否：

  • 更改微不足道且显而易见
  • 你仍在探索和发现需求
  • 开销超过好处
  • 不会维护的原型

LeanSpec 为你提供工具，在重要时有效地说是。

进一步阅读​

底线： 我们不卖革命。我们为一个真实的问题提供实用工具——通过轻量级、可维护的Spec保持人类和 AI 对齐。如果这是作秀，那是真正改善演出的那种。