跳到主要内容

为什么选择 LeanSpec？

LeanSpec 是一个轻量级的 Spec 驱动开发 (Spec-Driven Development, SDD) 框架，通过人机对齐优化开发速度。

核心优势：

  • 轻量级 - 最小化设置，无重度依赖
  • 简单性 - 从一个文件开始，按需增长
  • 敏捷性 - 直接编辑，无多步骤工作流
  • 适应性 - 适用于任何编辑器、AI 工具、团队规模或组织文化
  • 全面工具 - CLI、MCP 服务器、验证

**为什么这能提升开发速度：**我们的第一原则（上下文经济 (Context Economy)、信噪比 (Signal-to-Noise)、意图优于实现 (Intent Over Implementation)）带来高度人机对齐、低上下文腐化和低认知负荷。结果：更好的质量 → 更少返工 → 更高速度。

快速对比​

功能LeanSpecSpec KitOpenSpecKiroPM 工具Vibe Coding
类型SDD 框架SDD 框架SDD 框架AI IDE + SDD项目管理无结构
Spec结构✅ 灵活⚠️ 刚性格式⚠️ 刚性模板✅ 内置❌ 基于任务❌ 无
AI 优化✅ 控制长度⚠️ 较长上下文⚠️ 长系统提示✅ 原生❌ 富文本✅ 聊天
工作流灵活5 步流程提案→归档自主代理工单/冲刺提示
访问延迟✅ 即时（本地）✅ 即时（本地）✅ 即时（本地）✅ IDE 原生❌ API/MCP 配置✅ 聊天
编号✅ 是✅ 是❌ 否⚠️ IDE 管理✅ 工单 ID❌ 无
CLI 工具✅ 功能完整✅ 斜杠命令✅ 斜杠命令✅ 内置❌ Web UI❌ 无
MCP 服务器✅ 是❌ 否❌ 否⚠️ 不同⚠️ 需要配置❌ 否
可视化模式（UI）✅ 是❌ 仅 CLI❌ 仅 CLI✅ 内置✅ Web UI❌ 无
编辑器任意任意任意锁定（Kiro）Web/任意任意
认知负荷✅ 低⚠️ 较高⚠️ 较高⚠️ 需学习新 IDE⚠️ 不同✅ 非常低
适应性✅ 高⚠️ 规定性⚠️ 规定性⚠️ IDE 锁定⚠️ 组织特定✅ 非常高
最适合1-50+ 团队企业 SDD正式提案单人/小团队大型组织单人原型

何时选择 LeanSpec​

✅ 选择 LeanSpec 当您重视：

  • 轻量级设置，无重度依赖
  • 简单灵活的结构，从一个文件开始
  • 直接编辑，无多步骤工作流
  • 适用于任何编辑器或 AI 工具
  • 本地版本控制Spec的低延迟
  • 通过低认知负荷实现高速度

🔄 选择替代方案当您需要：

  • 企业治理：Spec Kit 用于规定性 5 步流程
  • 正式变更提案：OpenSpec 用于提案 → 审查 → 归档
  • 集成 AI IDE：Kiro 用于一体化 SDD + 自主代理
  • 项目管理：Jira/Linear 用于任务跟踪（与 LeanSpec 一起使用）
  • 最大速度：Vibe coding 用于单人原型（无结构）

详细对比​

对比 Spec Kit​

Spec Kit（由 GitHub 开发）提供了一个结构化的多步骤工作流：constitution → specify → plan → tasks → implement。

Spec Kit 优势：

  • ✅ 具有章程和原则的结构化治理
  • ✅ 为企业团队提供清晰的多步骤工作流
  • ✅ 与 VS Code 原生集成，Copilot Chat 中有快速操作按钮
  • ✅ 丰富的斜杠命令集成
  • ✅ 强烈关注质量和测试标准

权衡：

  • 刚性Spec格式为人类审查者创造认知负担
  • 较长上下文（constitution + spec + plan + tasks）可能降低 AI 性能
  • 流程开销，编码前需要 5 个必需步骤
  • 每个功能多个文件增加导航复杂性
  • 规定性结构较难适应不同的团队文化

最适合：需要结构化治理和正式规划阶段的企业团队。

LeanSpec 的优势：轻量级且适应性强。灵活结构（单文件或按需子 Spec），2,000 Token 以下以获得最佳 AI/人类性能。渐进式披露 (Progressive Disclosure)而非规定性流程。无必需工作流——适应您的团队文化。

对比 OpenSpec​

OpenSpec 将Spec视为演化的提案，具有变更跟踪、提案文件夹和基于差异的工作流。

OpenSpec 优势：

  • ✅ 明确的变更提案供团队审查
  • ✅ 当前状态和拟议变更之间的清晰分离
  • ✅ 适合棕地项目和跨Spec更新
  • ✅ 结构化差异格式（ADDED/MODIFIED/REMOVED）

权衡：

  • 无编号系统 - 难以在长期项目管理中引用Spec
  • 刚性工作流 - 需要提案 → 应用 → 归档步骤
  • 刚性模板 - 结构化差异格式可能不适合所有用例
  • 长系统提示 - AGENTS.md >400 行可能随时间导致上下文腐化
  • 斜杠命令依赖 - 需要特定提示文件（openspec-xxx.prompt.md）

最适合：希望在合并到Spec真实源之前使用审查工作流进行正式变更提案的团队。

LeanSpec 的优势：简单性和敏捷性。编号Spec便于引用。使用 git 版本控制直接编辑。无提案，无变更文件夹，无归档步骤。灵活模板。简洁的 AGENTS.md（2,000 Token 以下）。像编辑代码一样编辑Spec——提交、推送、完成。

对比 AI IDE（Kiro）​

Kiro 是一个完整的 AI IDE，内置Spec驱动开发和自主代理。

Kiro 优势：

  • ✅ 集成的Spec驱动开发
  • ✅ 自主代理和自动驾驶模式
  • ✅ 内置上下文管理
  • ✅ 编辑器内无缝 AI 交互

权衡：

  • IDE 锁定 - 必须从当前编辑器切换
  • 订阅成本 - 每月 $20-40
  • 学习曲线 - 新编辑器和工作流
  • 较少控制 - 固执己见的自动驾驶行为

LeanSpec 的优势：适应性和灵活性。编辑器无关——适用于任何 AI 工具（Copilot、Claude、Cursor、Windsurf）和任何编辑器（VS Code、JetBrains、Vim、Emacs）。保持现有工作流和肌肉记忆。

对比文档集合（RFC/ADR）​

记录技术决策的传统方法。

局限性：

  • 无工具：手动文件管理
  • 结构不一致
  • 无 AI 优化（通常 1000+ 行）

LeanSpec 的优势：RFC/ADR 哲学 + 现代工具。CLI/MCP 工具、一致结构、AI 优化（<2,000 Token）、搜索和验证。

对比项目管理工具（Jira、Linear）​

PM 工具擅长任务跟踪和团队协调。

技术Spec的权衡：

  • 更高延迟（需要 API/MCP 配置）
  • 富文本编辑器无法适应 AI 上下文窗口
  • 不与代码一起版本控制
  • 错误抽象（工单 vs. 技术Spec）

LeanSpec 的优势：Spec存在于您的仓库中——零 API 开销。与代码一起版本控制。使用 Jira 进行任务跟踪，使用 LeanSpec 进行技术Spec。

对比 Vibe Coding​

最快的方式开始——只需与 AI 聊天，无Spec。

权衡：

  • 无团队对齐或文档
  • 决策在聊天历史中丢失
  • 没有书面Spec，AI 可能会产生幻觉

LeanSpec 的优势：最小结构实现最大敏捷性。足够的Spec以对齐团队并指导 AI 而无重度流程。

哲学：第一原则优于流程​

LeanSpec 建立在 5 个第一原则之上（按优先顺序）：

  1. 上下文经济 - Spec必须适应工作记忆 (Working Memory)（人类 + AI）

    • 目标：控制长度（通常每个Spec 2,000 Token 以下）
    • 原因：注意力是稀缺资源，而非存储

  2. 信噪比最大化 - 每个字必须提供决策信息

    • 测试："这句话提供了什么决策信息？"
    • 删减：显而易见、可推断或"可能未来"的内容

  3. 意图优于实现 - 捕获为什么，而非仅仅如何

    • 必须有：问题、意图、成功标准
    • 原因：意图是稳定的，实现会变化

  4. 架起桥梁 - 人类和 AI 都必须理解

    • 对人类：概述、上下文、理由
    • 对 AI：明确的需求、清晰的结构

  5. 渐进式披露 - 当感受到痛点时添加复杂性

    • 单人开发：仅状态 + 创建日期
    • 感到痛点？添加标签、优先级、自定义字段
    • 永远不要添加"以防万一"的功能

**这些原则指导每个决策。**其他工具预先添加功能和流程。LeanSpec 从最小化开始，仅在您感到痛点时增长。

迁移与现实期望​

从其他工具迁移​

已在使用 OpenSpec、spec-kit 或 ADR？

lean-spec migrate ./path/to/specs          # 从任何 SDD 工具迁移
lean-spec migrate ./path/to/specs --with copilot  # AI 辅助迁移
lean-spec backfill                         # 从 git 回填元数据

详见迁移指南。

对限制的现实态度​

Robert Matsuoka 的批判性评估指出 AI 编码估值（25-70倍 ARR vs 互联网泡沫峰值 18倍）并警告 18-24 个月内可能出现修正。

LeanSpec 的定位：

  • ✅ 免费、开源——不销售平台或 IDE
  • ✅ 对Spec何时有帮助或有害持务实态度
  • ✅ 诚实面对限制（Rice 定理证明完全自动化是不可能的）
  • ✅ 增强而非取代核心能力

**理论基础：**Rice 定理（1951）证明 AI 无法通过算法确定“您想要什么”。Spec提供语义基础——人类定义意图，AI 在这些约束内放大规模。

**Spec会成为表演吗？**是的，当详尽、未读或静态时。LeanSpec 通过明确的“何时不使用Spec”指导、2,000 Token目标以及关注意图而非实现来避免这种情况。

📖 深入探讨：限制、权衡与现实 →

在 AI 泡沫修正中生存​

Robert Matsuoka 的批判性评估认为 SDD 具有双重目的：解决实际问题，但也支持"证明企业采购和脱节估值的治理叙事"。

泡沫指标是真实的：

  • AI 编码公司的估值达到 25-70 倍 ARR（对比互联网泡沫峰值 18 倍）
  • Tessl 筹集了 1.25 亿美元，10 个月后仅交付了测试版注册表
  • Cursor 在不到一年内估值达到 99 亿美元
  • "70% 自动化"声称在审查下崩溃（现实世界：10-30% 生产力提升）

**预测：**18-24 个月内修正。那些在"技术潜力"上烧钱而非展示产品市场契合度的公司将面临清算。

为什么 LeanSpec 处于不同位置​

我们不是：

  • ❌ 承诺 70% 自动化或自主编码
  • ❌ 销售 1.25 亿美元平台或 100 亿美元 IDE
  • ❌ 要求刚性 5 步工作流
  • ❌ 声称 AI 将消除高级开发者
  • ❌ 以虚高估值筹集风险投资

我们是：

  • ✅ 免费、开源工具
  • ✅ 对Spec何时有帮助或有害持务实态度
  • ✅ 工具无关（适用于任何编辑器/AI）
  • ✅ 解决真实痛点：团队对齐、上下文腐化、决策文档
  • ✅ 诚实面对限制（Rice 定理证明完全自动化在数学上是不可能的）

幸存者（根据 Matsuoka）：增强而非取代核心能力的工具。

**这就是我们的定位：**Spec增强判断，它们不取代对代码库的理解。无自主编码承诺——只是更明智的人机协作。

理论基础​

为什么人类参与是必要的：Rice 定理（1951）证明所有程序的非平凡语义属性都是不可判定的——没有算法可以确定任意程序是否具有有趣的行为特征。

这意味着什么：

  • AI 无法通过算法确定"您想要什么"（不可判定）
  • Spec提供使验证可行的语义基础
  • 人类定义意图，AI 放大规模（实现/测试）
  • 测试是采样，而非证明——我们在理论约束内建立信心

**LeanSpec 的哲学与 Rice 定理一致：**人类提供意图（Spec），AI 在这些约束内生成实现。我们与基本限制合作，而非对抗它们。

Spec会成为表演吗？​

是的，当：

  • 采购需要但没人阅读
  • 详尽的前期需求超出上下文限制
  • 对琐碎变更应用刚性流程
  • 文档保持静态而代码在演化

LeanSpec 通过以下方式避免这种情况：

  • 明确的"何时不使用Spec"指导
  • 2,000 Token目标防止上下文溢出
  • 渐进式披露（从简单开始，仅在需要时添加结构）
  • 关注随时间老化良好的意图，而非详尽实现

📖 深入探讨：限制、权衡与现实 →

总结​

LeanSpec 适合想要以下特性的团队：

  • 高速度通过低认知负荷和高 AI 对齐
  • 适应性适应任何团队文化、组织结构或工具
  • 简单性而不牺牲全面性
  • 低延迟使用本地版本控制的Spec
  • 渐进式披露 - 随团队增长的结构
  • 诚实定位 - 无炒作，无不可能的承诺，只有务实的工具

其他工具优化：

  • 结构化工作流（Spec Kit） - 企业治理的规定性多步骤流程
  • 变更治理（OpenSpec） - 正式提案 → 审查 → 归档工作流
  • 集成体验（Kiro） - 内置 SDD 和自主代理的完整 AI IDE
  • 项目管理（Jira、Linear） - 任务跟踪和团队协调（补充 LeanSpec）
  • 最大速度（vibe coding） - 无结构，无文档，只有聊天

选择适合您团队工作流和需求的工具。对理论约束内可能实现的目标保持现实态度。