先说一个直觉：如果你还在用「描述需求 → AI 写代码 → 反复修改」这条链路写代码，那 spec-kit 出来之后，你大概率会觉得自己在做体力活。
这个项目上周悄悄跨过了 10 万星的门槛，本周又涨了 6700+。974 个 commit，148 个 tag，7 个活跃分支——这不是一个热了两天就凉的概念验证项目，而是一个在真实迭代中长大的工具链。
什么是 Spec-Driven Development
一句话解释：先写规格文档，再让 AI 按规格生成代码。
不是 prompt engineering，不是一段 300 字的描述丢给 Claude 让它猜你想做什么。spec-kit 要求的规格是有结构的：需求说明、架构设计、任务分解、测试标准——每一个环节都有明确的模板和产出物。
项目里有 9 个核心扩展，覆盖了从产品需求文档到架构设计、从任务分配到代码生成的完整链路。最近一次更新（昨天）是 Architecture Workflow 扩展升到了 v1.1.0，说明这个框架还在快速吸收社区反馈。
283 个 open issues、141 个 open PRs——活跃度不低，但也意味着生态还在早期磨合阶段。
跟 Cursor / Claude Code 的区别
很多人第一反应是：这跟 Cursor 或者 Claude Code 有什么区别？
区别在于控制权的位置。
Cursor 和 Claude Code 的核心逻辑是：你描述意图，AI 理解并执行。中间的理解偏差靠对话来修正——改一行、跑一次、再改。
spec-kit 的逻辑是：你先花 20 分钟把规格写清楚，然后 AI 按图施工。偏差发生在规格层面，而不是代码层面。改规格比改代码便宜得多。
社区扩展生态
spec-kit 的 integrations 目录最近新增了 lingma 支持（上周合并的 PR #2348），说明国内工具链也在接入这个生态。
社区已经贡献了不少扩展——文档站刚从 README 里独立出来（PR #2560，3 天前），说明项目已经大到 README 装不下了。
实际能用吗
我扫了一遍 extensions 目录的结构，扩展的设计思路是清晰的：每个扩展定义了自己的输入输出格式、模板和验证规则。这意味着你可以自己写扩展来适配团队的工作流。
但要说「今天就能用于生产项目」——我觉得还得观察。141 个 open PRs 说明框架本身还在快速变化中，API 稳定性是个问题。
101k 星不全是噪音。这个项目的增长速度说明，开发社区正在寻找一种比 prompt engineering 更可靠的方式让 AI 写代码。spec-kit 给出的答案不是更好的 prompt，而是更好的流程。