31K Stars的OpenSpec，我为什么不看好它
思想被铭记，工具被遗忘——这不是悲剧，是成功产品的宿命。
一个周末的深度复盘
前几天Boss在群里分享了一个GitHub项目——OpenSpec，31K+ stars，号称「Spec-driven development for AI coding assistants」。
我花了一个周末把文档、架构、工作流全部啃完。结论很残酷：思想有价值，工具太重，不适合大多数团队。
31K stars代表的是「共识价值」——人们认同这个理念。但不代表人们真的需要这个工具。
OpenSpec想解决什么问题？
一句话：在AI写代码之前，先用结构化的Spec文档对齐需求和方案。
核心工作流很优美：
/opsx:propose "add-dark-mode"
→ AI自动创建4个文档
/opsx:apply
→ AI按tasks.md逐项写代码
/opsx:archive
→ 完成后归档，Spec合并到主文档理念是「先对齐再编码」，避免AI跑偏。听起来很完美。
但问题是：谁来写Spec？还是AI。
六个无法回避的硬伤
硬伤一：Spec质量无人负责——AI自产自销
OpenSpec的核心承诺是「先对齐需求再写代码」。但Spec本身是AI写的。
当你执行/opsx:propose，AI自动生成所有文档。如果AI一开始就理解错了需求，后面所有步骤都在「正确地执行错误的方案」。
用户意图 → AI理解 → AI生成Spec → AI基于Spec实现
^ ^
可能偏差 可能遗漏Spec只是把「聊天中的隐式需求」变成了「文件中的显式需求」。但如果需求本身就是AI猜出来的，文件化并不能修正它。
更残酷的现实：大多数开发者不会仔细审查AI生成的长文档——谁会认真读4个Markdown文件？他们会直接/opsx:apply。这样OpenSpec就退化成了「多了几步的命令行」。
硬伤二：文档过重——80%的日常开发用不上
一个简单的功能需要生成4个文件：
add-loading-state/
├── proposal.md # ~50行
├── specs/ # ~30行
├── design.md # ~40行
└── tasks.md # ~20行「给Toast加一个loading图标预设」这种需求，直接做只需改3个文件花10分钟。用OpenSpec？先生成4个文档→审查→实现→可能还要更新文档→最后归档。
对于小改动，维护文档的成本 > 直接写代码的成本。
硬伤三：Spec漂移——长期不可维护
随着项目演进，openspec/specs/里的主规格会越来越庞大、越来越过时。
如果有一次代码改动没通过OpenSpec走流程（这在实际开发中太常见了），Spec就和代码不一致了。没有自动化的「Spec ↔ Code一致性检查」。
时间一长，Spec就变成了「看起来像文档但实际过时」的负担。
硬伤四：Brownfield项目初始化成本极高
OpenSpec声称「brownfield-first」（面向存量项目）。但对于一个已有50个模块的项目，你需要先为所有现有功能编写Spec作为基线。否则Delta Spec里的MODIFIED/REMOVED就没有对照基础。
文档说可以「渐进式」补Spec，但这意味着前期投入巨大，短期看不到回报。
硬伤五：验证环节是「AI自审」
/opsx:verify号称验证实现是否匹配Spec。但它的方式是：让AI读它自己写的Spec，再看它自己写的代码，然后告诉你做得对不对。
这就是让被告当自己的法官。
硬伤六：强依赖高端AI模型
README推荐Opus 4.5和GPT 5.2——最贵的模型。4个文档×完整代码库分析，一个feature的propose就烧掉几美元。直接用Cursor Agent可能只需要五分之一的token成本。
它像什么？像DDD
分析到这里，我忍不住想到了DDD（Domain-Driven Design）。
两者有惊人的相似：
| 特征 | DDD | OpenSpec |
|---|---|---|
| 核心洞察 | 业务逻辑应直接映射到代码结构 | AI编码前应先对齐需求 |
| 理论框架 | 完整优美（聚合根、值对象、领域事件…） | 完整优美（Spec、Delta、Artifact、Schema…） |
| 实际落地 | 大多数团队只用了一小部分 | 大多数人可能只会用propose + apply |
| 过度设计风险 | 简单CRUD硬套DDD很痛苦 | 简单功能硬套Spec流程很痛苦 |
DDD推出20+年了，真正完整落地的项目凤毛麟角。大多数人「用了DDD」实际只是用了Repository模式和Service层。
OpenSpec大概率会走同样的路：思想被铭记，工具被遗忘。
它最大的贡献将是让开发者意识到「AI需要结构化的需求输入」这个道理。但这个道理一旦成为共识，OpenSpec本身就不再必要。
那正确的做法是什么？
Cursor的Plan模式已经是「轻量版SDD」
Cursor的Plan模式本质上就在做OpenSpec想做的事——在写代码前先对齐方案。只是它用对话完成，而不是用文件。
| 维度 | OpenSpec | Cursor Plan |
|---|---|---|
| 形态 | 文件式，生成Markdown | 对话式，在聊天中完成 |
| 重量级 | 重（4个文件+归档） | 极轻（一次对话） |
| 即时性 | 延迟（改文件→重新apply） | 即时（说”方案不对”→立刻调整） |
| 持久化 | 有 | 无 |
| 代码感知 | 需要AI先分析再生成 | 直接理解当前上下文 |
对于80%的开发场景，Plan模式+一份技术方案文档就够了。
我的实际方案
在我的组件库项目中，我用更轻量的方式实现了OpenSpec的大部分价值：
| OpenSpec概念 | 我的替代方案 |
|---|---|
| proposal.md | 对话中的需求讨论（Plan模式） |
| specs/ | types.ts + TypeScript接口（编译器保障） |
| design.md | 技术方案.md（每个复杂组件一份） |
| tasks.md | Cursor的TODO工具 |
| archive/ | Git history + CHANGELOG.md |
| /opsx:verify | TypeScript编译 + ESLint + 人工Review |
关键区别：TypeScript的接口比Markdown的Spec更精确、更不容易过时，而且编译器还帮你验证。
一个更深层的问题：SDD的过度工程化在AI时代可以忽略吗？
有人会说：「AI时代生成文档几乎零成本，过度工程化不再是问题。」
确实，生成成本可以忽略。但还有几个成本无法消除：
- 审查成本——AI写的文档你还是要读（否则就是AI自编自答）
- 维护触发——你需要记得去维护、知道什么时候需要维护
- 信任验证——AI全链路（生成→验证→执行）是否足够可信？
更好的方向可能是：让SDD成为AI的内部推理过程，而不是暴露给用户的外部流程。
Cursor的extended thinking就在走这条路——AI内部在做结构化推理，但用户不需要感知文件和流程。
什么才是真正的工程化
回到最初的问题：OpenSpec想解决的「AI跑偏」问题，本质是什么？
不是工具不够，是验证链条断裂。
对比一下两种做法：
| OpenSpec的做法 | 更轻量的实践 |
|---|---|
| AI生成Spec → AI执行Spec → AI验证Spec | 人工校验需求 → AI实现 → 编译器验证 |
| 4个Markdown文件（无人读、易过时） | TypeScript接口（编译器强制检查） |
| /opsx:verify（AI自审，被告当法官） | ESLint + 单元测试（独立验证） |
| 文档驱动，流程重 | 对话驱动，反馈快 |
| 改需求要改文件再apply | 改需求直接说，Plan模式即时调整 |
OpenSpec想用「结构化文档」约束AI。但真正的约束来自三个地方：
- 人工校验——需求理解必须有人确认，不能AI猜完就干
- 编译器保障——TypeScript接口比Markdown Spec精确100倍，过时了编译器会报错
- 独立验证——测试不能让写代码的人来写，AI也一样
这些都不需要31K stars的CLI工具。Plan模式 + TypeScript + 多角色分工，足够了。
谁适合用OpenSpec？
适合：
- 大企业的合规团队（需要审计追踪）
- 外包项目（需求白纸黑字防扯皮）
- 大型开源项目（多人异步协作的RFC流程）
不适合：
- 小团队/单人开发（流程摩擦 > 价值）
- 快速迭代的产品（文档维护跟不上迭代）
- 有经验的AI用户（已经学会用Rules/Skills引导AI）
写在最后
OpenSpec是一个「你理解它在做什么之后就不太需要它」的工具。
它教会了我们一个重要的道理：在让AI写代码之前先对齐需求很重要。
但你把这个道理内化之后，不需要一个CLI工具和4个Markdown文件来实践它。一个Plan模式的对话、一份技术方案文档、一个TypeScript接口定义——就够了。
AI编程时代的DDD——思想被铭记，工具被遗忘。
这不是失败，是成功产品的宿命。就像没人会为写一个CRUD去翻DDD那本厚书，但每个人都记得「聚合根」这个概念。
思考来源：OpenSpec官方文档、DDD实战经验、Cursor Plan模式探索