OpenSpec

从采用判断看，OpenSpec 的“热度证明”很强：官方 GitHub 仓库星标与分叉都很高，X 与知乎也有持续讨论，说明它已成为 AI Coding Workflow 里的高关注项目。但“好用证明”相对有限，现有更能支撑能力判断的证据主要是官方仓库说明、入门教程、三阶段实操文和少量对比分析；保守看，它更像一套正在被积极试用的流程框架，而不是已经被大规模验证的通用工程标准。

它的实际作用不是替你独立生成完整应用，也不是通用 IDE、代码补全器或另一个大模型。更准确的类比，是“给 Claude Code、Cursor 等 AI 编程助手使用的 spec-first 开发流程脚手架”。证据反复提到 propose、spec、design、tasks、archive 等阶段，核心产出是结构化变更提案、验收场景、技术设计、任务拆分与变更归档，用来减少需求漂移和返工，而不是直接替代实现能力本身。

门槛主要在流程纪律，不在购买成本。现有证据只能确认它是开源项目；没有看到官方定价、托管服务费用或稳定的 API 成本信息，因此不能把它写成付费 SaaS，也不能把社区演示里的效率或成本说法当作官方承诺。前期先写 proposal/spec/design 再实现，会增加文档、评审与协作成本；对小修小补、一次性脚本或强探索型原型，摩擦可能偏大。它更适合希望控制变更范围、降低返工、让多人或多 agent 对齐的软件团队与严肃个人项目。

社媒共识大致是：OpenSpec 代表了 AI 编程从“直接生成”转向“先规格后实现”的趋势，但也有批评认为当前 SDD 类工具可能把流程做重。讨论质量上，evidenceSources 里既有高热度转发和观点帖，也有教程、实操和对比内容；其中 GitHub 官方仓库、实操文章与教程更能支持能力和门槛判断，榜单式讨论与转发更能说明受关注。整体属于“教程和观点多于大规模实测”，参考价值存在，但样本仍有限，适合先小范围试用再决定是否纳入正式团队流程。