从 v0.1 到 v1.0.0Spec Kit 一年演进史GitHub 官方把「规范驱动」从口号做成了产品【免费下载链接】spec-kit Toolkit to help you get started with SDD or any other process!项目地址: https://gitcode.com/GitHub_Trending/sp/spec-kit2025 年 8 月 21 日GitHub 官方仓库github/spec-kit落下首个提交整整一年后的同一天项目以 v1.0.0 完成周年庆。这一年里Spec Kit 从一套只讲「Specify → Plan → Tasks → Implement」的 SDD 工具包长成了覆盖 38 个编码 Agent 集成、157 个社区扩展、33 个预设、270 贡献者的可扩展框架。更值得玩味的是v1.0.0 发布时维护者自己给出的注脚是——1.0.0 is now just a number。这不是一句凡尔赛。它背后是一条清晰的演进主线当 AI 编码 Agent 让改代码变得廉价价值就转移到改流程上而 Spec Kit 用一年时间把一套流程做成了可以被安装、被替换、被社区持续扩充的产物体系。本文结合仓库源码与社区情报拆解这条从工具包到框架的演进路径。奠基期为什么 GitHub 官方要做 SDD 工具包Spec Kit 的出发点直指 AI 辅助编程的最大痛点——prompt 是一次性的对话上下文是一次性的产出的代码散落在会话里无法沉淀为资产。传统开发里规格文档只是脚手架写完代码就丢弃的惯性在 AI 时代被放大成了失控没有what和why的约束模型每生成一段代码都是对怎么做的一次盲猜。Spec Kit 给出的解法是把开发流程反转规格不再是从属品而是可执行的第一等公民。docs/concepts/sdd.md 把这套哲学概括为四点意图驱动先定义 what 再谈 how、富规格创建用护栏与组织原则约束生成、多步精炼拒绝一次性 prompt 生成代码、重度依赖 AI 模型对规格的解读能力。奠基期的产品形态是三张入场券0-to-1 绿地开发、创意探索并行实现多套技术方案、迭代增强棕地演进。三者共享同一条核心流水线Specify → Plan → Tasks → Implement配套的模板体系从第一天就强调agent 无关——同一个流程可以落在 Claude Code、GitHub Copilot、Gemini CLI 等不同 Agent 上脚手架按各 Agent 的目录约定分别生成。团队换 Agent 不换方法论这正是后来可扩展框架的种子。转型期从工具包走向编码 Agent 可扩展框架奠基期定下工具包的形态转型期则把它重构成框架。这段演进的独特之处在于它不是维护团队自上而下规划出来的而是被社区推着走的。docs/history.md 记录了两次治理交接2025 年 8 月 Den Delimarsky 与 John Lam 创立项目2026 年 1 月 22 日 Manfred Riem 接任主维护者2 月 23 日CODEOWNERS变更公开。社区化治理直接改变了项目节奏——模块化扩展系统本身就是社区贡献者 Michal Bachorik 提交的随后每个原语都是社区先用起来、再被官方收编。到 2026 年 4 月可组合模型定型为五大原语Integrations把 Spec Kit 接入编码 Agent注册表架构见 design/integration.mdExtensions增加命令、模板、脚本、钩子等能力Presets用优先级堆栈替换/组合模板与命令见 presets/README.mdWorkflowsYAML 定义的多步骤可恢复自动化管线Workflow steps可复用的步骤行为单元其中 workflow 引擎是最能体现框架化的一环。workflows/README.md 展示了一个典型定义命令步骤、gate 人工审批、shell 步骤、if/switch/while 分支、fan-out/fan-in 并发全部用 YAML 声明每次运行的状态持久化到.specify/workflows/runs/run_id/中断后可specify workflow resume恢复。内置的speckit工作流workflows/speckit/workflow.yml把 specify → plan → tasks → implement 编排成带两道 review gate 的端到端管线steps: - id: specify command: speckit.specify integration: {{ inputs.integration }} input: args: {{ inputs.spec }} - id: review-spec type: gate message: Review the generated spec before planning. options: [approve, reject] on_reject: abort这个阶段的另一标志是一等流程从一个变成三个。0.9.52026-06-05引入随包分发的可选bug扩展assess → fix → test三阶段把缺陷诊断、修复与验证彻底分离0.13.02026-07-17引入assess扩展intake → research → define → shape → decide五阶段在想法进入 SDD 之前先做证据驱动的 go / needs-clarification / kill 决策。两个扩展的清单文件extensions/bug/extension.yml、extensions/assess/extension.yml展现了同一套声明式结构requires声明最低 CLI 版本provides逐条登记命令。与此同时发布管道加入 PyPI脚本类型从 Bash/PowerShell 扩展到 Python核心资产内嵌进 Python 包——离线与气隙环境的初始化由此变得可靠。到 v1.0.0 时生态规模已经不能用工具包衡量38 个 Agent 集成、157 个社区扩展、33 个预设、270 贡献者以及由目录catalog驱动的发现与安装机制。社区目录明确标注列入目录不等于代码审计或背书见 docs/community/overview.md把信任边界交给用户自己判断。v1.0.0 之后值得跟踪的能力清单v1.0.0 没有冻结任何东西——发布后的提交记录显示项目正沿着几个方向继续加码这些是当前最值得跟踪的MCP 服务器落地。src/specify_cli/mcp_server/server.py 实现了实验性 stdio MCP 适配器把稳定的 CLI JSON 命令暴露为specify_list_commands、specify_describe_command、specify_run_command等 MCP 工具1.1.1 又加入 version-only stdio server1.1.2 新增一等artifact list与version工具。这让 Spec Kit 从Agent 的斜杠命令进一步变成可被任意 MCP 客户端调用的协议服务。版本化目录与精确选择。1.0.13 到 1.1.2 之间bundles、presets、extensions、workflows、steps 全部支持精确选择目录中的指定版本exact catalog release selection社区提交的 bundle 还能被自动优先级化——生态组件的版本治理正在变得工程化。认证与集成的边界扩张。0.12 加入 Bitbucket 认证提供方随后补上 GHE.com release 资产下载支持集成侧新增 MiniMax Codemcode等条目并修正了多个 Agent 的 dispatch 参数。对使用企业内部 GitHub 与多云环境的团队这条线直接决定可落地性。workflow 表达式系统持续增强。1.1.1 为{{ }}表达式加入upper/lower/split/length/to_json过滤器并对错误用法做类型校验而非静默强转1.1.2 修复了括号表达式求值与负索引解析。workflow 正在从脚本编排走向具备完整表达式语义的自动化语言。自举dogfooding。docs/guides/agentic-sdlc.md 记录了 Spec Kit 如何用自己开发自己feature-assess agentic workflow 在 issue 上直接运行assess扩展产出证据与 verdict历史提交中还能找到specify bundle命令的宪法与规格快照。用规范驱动开发 Spec Kit 本身这可能是对产品理念最苛刻也最有效的验收。截至 2026 年 10 月初仓库已迭代到 1.1.2。回看这一年Spec Kit 真正交付的东西或许不是某个版本号而是一个可以被团队改写、替换、扩展的开发方法论基础设施——正如维护者在周年庆里反复强调的当 Agent 让适应变化变得廉价产品的价值锚点就从稳定转移到了可适应。规范驱动不是 GitHub 喊出的口号而是它用一年时间、38 个集成和 270 贡献者持续验证的工程路线。【免费下载链接】spec-kit Toolkit to help you get started with SDD or any other process!项目地址: https://gitcode.com/GitHub_Trending/sp/spec-kit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考