Spec Kit：别让 AI 写散需求

AI 写代码越快，需求越容易被写散。

一句“帮我做个管理页面”，模型很快能给出页面、接口和一堆组件。问题也在这里：需求没讲清，边界没定住，验收标准没写出来，后面就会反复补 prompt、补测试、补异常状态。看起来省了第一步，实际把返工挪到了后面。

Spec Kit 解决的不是“让 AI 再快一点”，而是让 AI 编程少一点散打。它把开发前的需求、规格、技术计划、任务拆分和实现串起来，让模型先围着规格工作，再进入代码。项目现在约 11 万 star，来自 GitHub，许可证是 MIT，官方描述也很直白：把注意力放回产品场景和可预期结果，而不是每一块都从 vibe coding 开始。

很多人用 AI 写代码，卡住的地方其实不在“模型不会写”。模型会写，甚至写得很勤快。麻烦是它不知道什么最重要，不知道哪些需求不能动，不知道哪些边界必须保留，也不知道这次生成到底算不算完成。

Spec Kit 的做法，是先把“人脑里的模糊想法”变成可以反复引用的材料。先用 /speckit.constitution 建项目原则，再用 /speckit.specify 写清要做什么和为什么做；到 /speckit.plan 才说技术栈和架构选择；随后用 /speckit.tasks 拆出任务，最后 /speckit.implement 执行。中间还有 /speckit.clarify、/speckit.analyze、/speckit.checklist 这类命令，用来补清需求、检查一致性和生成质量清单。

这套流程听起来像把开发变慢了，但它针对的不是临时脚本，而是那些“一旦写偏就很麻烦”的功能。

比如一个相册整理工具，随口说“支持拖拽、分组、预览”并不够。相册能不能嵌套？照片是不是上传？元数据放哪里？用户怎么重排？异常和权限怎么处理？这些问题如果不提前落下来，AI 会凭经验补。它补得越完整，后面越难分清哪些是你要的，哪些是模型替你编的。

Spec Kit 要求在 specify 阶段只讲 what 和 why，不急着讲技术栈。这个限制挺有用。很多 AI 编程返工不是因为技术栈选错，而是需求没被问清楚，就直接进入实现。先把用户故事、功能需求、非功能需求、验收标准写出来，再让计划去服务这些规格，后面的代码才不容易跑偏。

它也不是只能配 GitHub Copilot。官方文档里写到支持 30+ AI coding agent，CLI 初始化时可以选 Copilot、Gemini、Codex 等集成；如果走支持 skills 的模式，也能安装成对应 agent 的技能。环境上需要 Linux、macOS 或 Windows，推荐用 uv，也可以用 pipx，并要求 Python 3.11+ 和 Git。

更适合长期项目的一点，是它允许扩展和预设。extensions 用来加新能力，比如接外部工具、补新的开发阶段；presets 用来改规格、计划、任务的格式，比如加入合规要求、领域术语、安全审查或测试优先规则。项目本地也能覆盖模板。换句话说，它不是强迫所有团队用同一种规格，而是给 AI 编程加一层可沉淀的项目约束。

第一次试，不建议直接把一个大项目全丢进去。

更稳的方式是拿一个中等小功能练手：先写清“用户要完成什么”和“为什么需要它”，让 Spec Kit 生成规格；再补技术栈和约束，生成计划；最后拆任务，让 agent 按任务实现。中间发现规格不清，就回到 clarify 或 checklist，而不是继续用聊天补洞。

它的边界也很明显。

如果只是写一次性脚本、验证一个小想法，Spec Kit 可能太重。临时实验最需要的是速度和可丢弃，规格流程会增加前期成本。它更适合中等复杂度以上的功能、长期维护的产品代码库，或者多人协作里需要把需求、计划、任务和验收串起来的场景。

AI coding 这几年最容易让人上头的地方，是输入一句话就能看到代码跑出来。但工程里真正消耗人的，往往不是第一版代码，而是需求散了、边界漏了、返工多了、没人知道为什么这么改。Spec Kit 把这部分成本提前摊开，逼着人先把话说清楚。

这不一定浪漫，也不一定轻。可如果 AI 真的要参与更严肃的软件开发，它迟早要从“会写代码”走向“按规格交付”。Spec Kit 值得看的地方，就在这一步。