GitHub 趋势 · 第 45 期

13 万 star 的 Spec Kit 发了 1.0，官方说这个数字不代表稳定

#规范驱动开发#AI编程#GitHub官方

一个版本号，被官方主动降级

README 顶部那条 NOTE 写得很清楚，原文是 it is now just a number，并解释为什么：当 agent 让「适应变化」的成本大幅下降之后，价值就从稳定性转移到了适应性（the value moves from stability to adaptability）。

仓库里的 docs/history.md 也是同一个口径：「Version 1.0.0 did not create or freeze that model; it gave the project’s evolving state a round number.」翻成中文就是——1.0.0 没有冻结任何东西，只是给一个仍在演进的形态取了个整数。

官方月报把话说得更硬：1.0.0 明确「not a feature release and not a stability promise」，理由是过去的 major 版本号是用来对冲破坏性变更成本的保险，而 agent 已经把这份成本压低了。所以这个 1.0 标记的是五个原语之间的关系已经自洽，而不是接口不再变。

Spec Kit 是什么

一句话版本：它是 GitHub 官方维护的一套规范驱动开发（Spec-Driven Development，SDD）工具包，README 的定位句是「Define what to build before building it — with any AI coding agent.」关键词是 any——它不绑定某一家 agent。

它要颠覆的东西写在仓库那份 spec-driven.md 里，标题直接叫 The Power Inversion（权力倒置）。原文的两句：「Specifications don’t serve code—code serves specifications」与「Code was truth」。这套方法论的落点是：规范成为主产物，代码只是它在某个语言与框架里的表达形式，所以维护软件这件事被重新定义成维护规范。

规模上：README 正文说它支持 30+ AI 编程 agent，1.0.0 的文档给出的集成数是 38 个。仓库根目录还自带一份简体中文 README（README.zh-CN.md，20,439 字节），对中文读者算是省了一步。

五个原语，一套优先级栈

1.0.0 真正落下来的是五个可组合的原语。它们的关系是官方历史页自己梳理的：

这五层之上是一套统一的优先级栈，五个原语共用同一套发现与安装策略。模板是运行时解析的，从上往下取第一个命中的：

要注意的是扩展与预设的解析时机不一样：模板在运行时解析，而扩展/预设的命令是在安装时写进 agent 目录的（比如 .claude/commands/）。多个预设或扩展提供同一条命令时，优先级高的赢；卸载之后，下一顺位的版本会自动恢复。

官方自己还带了两个可选扩展，同样是装完就能用的流水线：

• ▪bug 扩展：assess → fix → test，把「先确认诊断、再改、最后验证原始症状」拆成三步
• ▪assess 扩展：intake → research → define → shape → decide，把一个想法在进入开发流程之前先评估成 go / needs-clarification / kill 三种结论

上手：三条命令加六步流程

安装命令取自 README 的 SDD Quickstart 原文，注意 tag 要保留前导的 v：

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z
specify init my-project --integration copilot
cd my-project

然后在项目目录里启动你的编程 agent，按这六步走：

/speckit.constitution    每个项目只做一次，写清项目原则
/speckit.specify         要说清做什么，而不是怎么做
/speckit.plan            选技术栈、定架构
/speckit.tasks           把方案拆成可执行任务
/speckit.implement       执行
/speckit.converge        对照 spec / plan / tasks 检查是否真的做完
                         未收敛就回到 implement 再来一轮

README 特别提示：第四步和第五步要反复跑，直到 converge 报告 Converged 为止。CLI 自身的升级走这套命令：

specify self check                  # 只读检查有没有新版本
specify self upgrade --dry-run      # 预演升级，不实际执行
specify self upgrade                 # 立即原地升级到最新稳定版
specify self upgrade --tag vX.Y.Z    # 锁定到指定 tag

生态里的扩展、预设、bundle 都是同一套发现命令，其中 bundle 是「一个角色要用的整套东西打成一个包」：

specify extension search         # 找社区扩展
specify preset search            # 找预设
specify bundle info   # 装之前先看会装进什么
specify bundle install 

前置条件与环境要求（README 原文口径）：

• ▪Linux / macOS / Windows
• ▪uv（推荐）或 pipx 用于安装，Python 3.11+，Git
• ▪CI 或无法交互的 agent 环境要加 --non-interactive，否则 init 可能卡在选择器上
• ▪初始化到非空目录时加 --force

它把批评也一起放进了仓库

这是这期最值得说的一点。仓库根目录有个 newsletters 目录，里面躺着 2026 年 2 月到 8 月共 7 份月报，最新那份 28.9KB。月报不只是报喜，它成段收录了外部最尖锐的质疑和实测数字：

• ▪一位韩国开发者的实战记录：13 个功能之后 specs/ 长到 12,931 行，相当于 src/（17,590 行）的 73%，结论是「做完的规范文档没什么可决定的，只能批准」，最终迁到自建的轻量流程
• ▪一位日本开发者的量化实测：加一个需求的成本约 31 美元、34 分钟，并指出这套流程覆盖了「规范到代码」，但需求获取仍在其范围之外
• ▪被反复引用的那句批评：每个 spec 要配 8 个以上的 markdown 文件
• ▪官方自己的收束句：文档膨胀与认知负担，是 8 月所有评论里被提到最多的问题

官方在 Roadmap 里也认了一件事：1.0.0 之后最值钱的未完成工作是信任边界。社区目录（community catalog）是 discovery-only 设计——维护者校验的是条目格式是否合规，不是代码是否安全。README 里对应的一句提示是：社区内容由各自作者独立维护，安装前请自行审阅源码（Review source code before installation and use at your own discretion）。

我的判断：适合谁，不适合谁

几个实际会踩到的坑，都来自官方文档原文：

• ▪同一批命令在 README 里有两种写法：/speckit.specify（点号，slash 命令）与 /speckit-specify（连字符，skills 模式下的技能名）。Codex CLI 与 Command Code 在 skills 模式下用的是 $speckit-*，写法不能混
• ▪扩展和预设的命令文件是在安装时写进 agent 目录的，所以换 agent、换集成之后要重新确认命令是否都在
• ▪裸跑 specify self upgrade 会立即升级、不给确认提示，行为对齐 npm update 那一类命令；想先看会做什么就加 --dry-run
• ▪升级示例里的 tag 必须带前导 v（写 v0.12.11，不是 0.12.11）
• ▪bundle 的来源分 install-allowed 与 discovery-only 两类，后者能在搜索和查看里看到，但会拒绝安装
• ▪发版非常密：一页 tag 从 v0.12.15 一路排到 v1.0.6，最新 v1.0.6 发布于 2026-09-10，也就是说前一天还在发版
• ▪README 把目标明确写在 Experimental Goals 下，遇到行为变化别当成 bug

你所在的团队现在是「先写规范再让 agent 动手」，还是「直接让 agent 动手、出问题再补」？评论区说说你们踩过哪种坑。

下一期预告：Lakr233/vphone-cli（11,560 star，本月 +3,892，Swift），备选 modular/modular（29,677 star，本月 +3,080，Mojo/MAX）。

#规范驱动开发#AI编程#GitHub官方