OpenSpec 星数突破 70.3k、周榜第 14 连榜AI 编程的规格化浪潮彻底点燃【免费下载链接】OpenSpecSpec-driven development (SDD) for AI coding assistants.项目地址: https://gitcode.com/GitHub_Trending/op/OpenSpec如果你关注过 GitHub 周榜过去几周大概率会在榜单前部反复看到同一个名字OpenSpec。一个面向 AI 编程助手的规范驱动开发Spec-driven Development, SDD框架正以一周 1538 星的增速把星数推向 70.3k连续多周停留在周榜第 14 位。星数的爆发只是表象真正值得注意的是它背后那场正在发生的范式转移——AI 编程的主流叙事正在从让模型直接生成代码转向先立规、后写码。本文不打算复述官方 README而是结合社区情报与仓库源码拆解这条增长曲线为什么发生、OpenSpec 到底在技术上解决了什么问题以及接下来值得盯住的变量。从 5.8 万到 70.3k一条可以上溯的增长曲线先看数据事实。标题中的 70.3k 星与单周 1538 星的数字来自当下的 GitHub 榜单而把它放回时间轴能拼出一条相当清晰的爆发曲线2026 年 7 月中旬社区文章中 OpenSpec 的星数还在 5.8 万左右同期对比对象是 24 万星的 Superpowers更近一段时间多篇媒体稿件开始以6.8 万星68k 星开源规格框架为题报道标题中开始出现每两秒创建一新规范这样的传播性表述现在70.3k 星、周榜第 14 位、单周净增 1538 星。两个月内从 5.8 万到 7 万属于典型的长尾项目被某个结构性事件点燃的形态——不是线性爬坡而是过了某个临界点后的加速。触发这个临界点的正是 AI 编程工具链集体转向可控性这一主题。值得注意的一个细节是OpenSpec 的月下载量徽章npmDownloads/mo挂在 README.md 顶部与星数并列说明它不只在被围观也在被真实安装使用。一个规范框架的星数增速超过绝大多数代码生成类工具这件事本身就在投票开发者缺的不是更多 AI 代码而是让 AI 代码做对的事。为什么是现在从生成代码到先立规后写码星数的暴涨需要一个技术叙事来解释而这个叙事在社区情报里反复出现AI 编码助手已经能完整写出功能但提效不提质——需求还原失真、上下文丢失、模型幻觉导致的反复返工正在成为所有重度使用者的共同痛点。得物技术、洞窝技术等一线团队的文章标题几乎一致从模型博弈转向工程化从生成转向规格驱动。OpenSpec 对这个痛点的回答浓缩在 docs/overview.md 开篇的一句话里agree first, then build confidently先达成一致再放心构建。它的核心机制值得从源码层面拆开看第一双目录模型。openspec/specs/是当前系统行为的唯一真相源openspec/changes/存放每次变更的全部产物。两者之间靠归档archive闭环变更完成时delta 规范合并进主规范变更文件夹带日期移入changes/archive/。这个结构在 docs/getting-started.md 中有完整的目录树示意。第二delta 而非全量。这是 OpenSpec 最被低估的设计。它不要求你把 8 万行老代码全部写成规范——你只为即将改动的那一小片写 delta。ADDED/MODIFIED/REMOVED/RENAMED 四类语义标记让 AI 以差异而非目的地的方式描述变更这正是棕地brownfield项目能够低门槛接入的根本原因。官方在 docs/existing-projects.md 里说得非常直白你的 app 有 8 万行不代表你要先为它写 8 万行规范规范是跟着真实变更自然生长出来的而不是一次性批量转换出来的。第三把工作流本身做成可编程的制品图。OpenSpec 在 1.0 版本OPSX Release重构了整套架构废弃了旧的相位锁定命令/openspec:proposal等改为基于制品artifact依赖图的动作系统。每个变更文件夹里的产物proposal → specs → design → tasks不是硬编码在 TypeScript 里的字符串而是定义在 schemas/spec-driven/schema.yaml 这样的外部 YAML 文件中name: spec-driven version: 1 description: Default OpenSpec workflow - proposal → specs → design → tasks artifacts: - id: proposal generates: proposal.md requires: [] - id: specs generates: specs/**/*.md requires: [proposal] - id: design generates: design.md requires: [proposal] - id: tasks generates: tasks.md requires: [specs, design] apply: requires: [tasks] tracks: tasks.md对应的图引擎在 src/core/artifact-graph/graph.ts 中实现用 Kahn 算法做拓扑排序getNextArtifacts()依据依赖完成度计算下一个可以创建的制品getBlocked()报告未满足的依赖。关键哲学是文档里反复强调的enablers, not gates依赖是使能项不是闸门——proposal → specs → design → tasks只表示接下来什么变得可能而非你被强制进入下一阶段。实现到一半发现设计错了直接改design.md继续没有任何相位锁。这套架构带来的直接效果是每个 AI 助手Claude Code、Cursor、Codex……在执行apply前都能通过openspec status --change name --json查询实时状态再通过openspec instructions artifact拿到上下文 规则 模板三层动态指令而不是收到一份与项目状态无关的静态提示词。这也解释了为什么它能被 40 余款工具共享同一套工作流——接入成本是生成几个 SKILL.md 文件而不是为每款工具写死一套集成。教程井喷与大厂落地生态的双轮驱动星数增长从来不是靠项目自己吆喝出来的而是靠生态。社区情报里的证据可以分为明显两层第一层是教程的井喷。从 CSDN 到掘金围绕 OpenSpec 的中文教程在过去几个月呈指数级增长《OpenSpec 详解》单篇浏览量超过 1.1 万、收藏 37 次《OpenSpec 完整使用流程笔记SDD》在掘金拿到近 4 万阅读AI 编程三剑客Spec-Kit、OpenSpec、Superpowers 深度对比达到 3.6 万阅读、216 赞。教程内容的分布也很有信息量有结合 Claude Code DeepSeek 的自动化代码生成教程有 VSCode ClaudeCode 插件的国产大模型接入指南有 Trae-CN、InsCode 等国内平台的一线实战甚至出现了OpenSpec 与 Superpowers 融合成单一工作流并开源的社区项目——生态开始自发地做杂交创新这是框架类项目成熟的典型信号。另外值得注意CSDN 上甚至出现了openspec/config.yaml 不生效怎么排查这类排障向内容说明它已经越过尝鲜阶段进入被日常使用、被认真踩坑的深度采用期。第二层是企业级落地。社区里最能说明问题的是这几篇署名一线团队的技术文章得物技术Dewu发表的《Claude Code OpenSpec 正在加速 AICoding 落地》明确提出代理化执行与规格驱动开发模式用于解决编码幻觉与流程失控洞窝技术服务家居零售 B 端中台的团队的文章则描述了OpenSpec CodeGraph双引擎直指需求还原失真、代码复用率低、Token 成本高这三个量化痛点网易智企提出了Spec Driven 马具工程的完整解法。QCon 北京也出现了相关演讲议题。企业不再是试用者而是开始把 SDD 写入自己的研发流程——这层证据比教程更能支撑浪潮的判断因为它意味着付费意愿和组织级预算正在入场。OpenSpec 本身也在为这种双轮驱动做结构性准备。它用openspec init的--tools参数把支持面铺到了惊人的广度。在 src/core/config.ts 的AI_TOOLS数组里除了 Claude Code、Cursor、Codex、Gemini CLI、GitHub Copilot 这些主流工具还能看到 Amp、AtomCode、GigaCode、DeepSeek Harness、Grok Build、Warp、Veai、ZCode、Oh My Pi 等大量新面孔——许多是在过去几个版本里逐个合入的CHANGELOG.md 里 1.14.0 一个版本就新增了 Code Studio、DeepSeek Harness、GigaCode、AtomCode、GSD、Amp、Veai、Grok Build、Warp 等目标。docs/supported-tools.md 给出了每种工具的调用形态矩阵Claude Code 用/opsx:proposeCursor 用/opsx-proposeAmazon Q 用opsx-proposeCodex 用$openspec-proposeKimi Code 用/skill:openspec-propose——同一套工作流四十多种方言。生态的第三块拼图是第三方衍生项目记录在 docs/community.md有监督 OpenSpec 变更执行的可视化工坊OpenSpec Workbench、做规范访谈并导出 OpenSpec 兼容产物的云服务MySpec以及把 OpenSpec 场景映射到 Vitest/Jest 测试覆盖率的 CLI 与 GitHub Actionopenspec-guard。规范与测试覆盖率的打通尤其值得关注——它意味着 OpenSpec 的场景即测试用例设计每个#### Scenario:都对应一个可验证的 given/when/then正在被工具链兑现。上面的面板是openspec view的仪表盘预览。它不是花架子在 CHANGELOG.md 的 1.14.x 系列里view陆续加入了按 schema 展示每个制品的 done/ready/blocked/skipped 状态、进度条对齐修复以及不再统计已归档变更的改动——这些细节反映出一个项目在爆发期仍然保持着对真实使用体验的打磨。下一步看什么天花板、竞争与生态变现星数到 70k 之后最值得追问的不是还能涨多少而是三个更实质的问题。其一企业采用能否从文章变成流程。OpenSpec 已经具备了企业落地的基础设施openspec init --tools支持 CI 场景的非交互初始化社区已有专门的 CI 集成教程--profile控制系统安装哪些工作流还有openspec doctor、openspec validate --strict等可嵌入 pre-commit 和 CI 的校验面。更关键的是 1.5.0 开始引入的Storesbeta——允许规划独立存在于一个单独的 git 仓库跨仓库、跨团队共享同一套 specs。这直接命中了一个特性横跨三个仓库、需求归一个团队所有、由另一个团队消费的典型企业场景。Stores 从 beta 走向稳定的节奏是判断企业市场能否真正放量的首要观测点。其二规格化赛道自身的竞争烈度。OpenSpec 并不是唯一在做这件事的GitHub 的 Spec Kit 走的是重流程路线Python 环境、刚性阶段门AWS 的 Kiro 绑定自家 IDE 与 Claude 模型Superpowers 用 24 万星证明了AI 编码纪律框架的需求上限GSD 则是另一种流派。README.md 里 OpenSpec 给自己定的差异化是更轻、更流畅、不锁定工具而社区里三剑客对比GSD vs OpenSpec vs Superpowers这类内容的高流量恰恰说明这个赛道已经拥挤到需要选型文章来引流了。在拥挤赛道里70k 星是门票而非护城河——真正的护城河是AI_TOOLS里那 40 多个适配器带来的网络效应以及第三方 schema/衍生工具如 openspec-guard构成的生态厚度。其三商业化的可能路径。目前 OpenSpec 是 MIT 许可的纯开源项目仓库里没有明显的商业化动作社区衍生品MySpec反而先一步探索了云服务 收费的模式。对这类开发者工具 工作流定义的项目合理的变现想象空间在于企业版的工作流模板市场、托管式 stores/团队协作服务、以及围绕规范资产的数据与服务——但至少在现阶段项目更优先的动作依然是扩支持面、修边界问题CHANGELOG 里 1.13.x 一整版几乎全是安全加固与 Windows/跨平台修复和沉淀文档。判断它会不会变现可以盯住openspec/config.yaml里是否出现组织级功能开关、以及 Stores 是否转正这两件事。最后说一点客观的保留意见。OpenSpec 的文档自己也很诚实对一个真正一行代码的琐碎修复这套规范 提案 设计 任务的仪式感未必划算。它的价值密度集中在需要和 AI 达成一致的场景——而这恰恰是 AI 编程普及后占比越来越高的场景。当每个开发者都拥有一个会自信地把你模糊的需求写成错误代码的助手时先立规、后写码就不再是一种方法论偏好而是一种生存需要。这或许才是那 1538 颗新星真正投出的票。【免费下载链接】OpenSpecSpec-driven development (SDD) for AI coding assistants.项目地址: https://gitcode.com/GitHub_Trending/op/OpenSpec创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考