为什么 Vibe Coding 的天花板这么低先说清楚问题再说解决方案。vibe coding 这个词是 Andrej Karpathy 提出的原意是「顺着感觉写代码让 AI 处理细节」。在原型验证阶段这个方式非常有效——你描述个大概AI 给你一个能跑起来的架子5 分钟内看到效果。但进入真正的功能开发之后这个模式会遇到一个内在矛盾AI Agent 不是搜索引擎它是「字面意思执行者」。你说「加一个排序功能」它就加排序功能。它不知道你的数据量有多大不知道你的分页逻辑在哪一层不知道「注册时间」和「创建时间」在你的 schema 里是不是同一个字段。它把所有这些模糊的空间用它认为「合理」的猜测填满了。这就是 GitHub 官方文章里说的那句话“it looks right, but doesn’t quite work”——看起来对但跑起来不对。更深的问题是需求漂移context drift。你在一个长对话里反复修改需求AI 的「记忆」会逐渐偏离最初的意图。第 10 轮修改的代码和第 1 轮的需求之间可能已经没有直接的对应关系了。这不是 AI 的智力问题是信息结构的问题。vibe coding 本质上是把「需求」藏在了对话历史里分散在十几条消息的来回里。AI 每次生成代码都需要从这些碎片里重建上下文每次重建都可能丢失细节。Spec Kit 的解法是把需求从对话里拿出来放到一个结构化的文件里。这个文件就是 spec.md它是整个开发流程的单一真相源。AI 每次做任何决策都从这里取信息而不是从对话历史里猜。vibe coding 与规范驱动开发的对比需求漂移 vs 单一真相源图左边是 vibe coding 的信息结构——需求散落在对话里AI 每次都在猜右边是 SDD 的信息结构——spec.md 是唯一真相源AI 从这里取信息Spec Kit 的核心设计七步工作流Spec Kit 的安装很简单核心是一套七步工作流每一步生成一个文件这些文件共同构成一个功能的「完整规范体系」。在看具体命令之前先理解这个设计哲学规范先于实现文件先于代码。传统开发是先写代码遇到问题再补文档。Spec Kit 是先写规范让规范驱动代码生成。这个顺序的改变意义远大于工具本身的功能。七步工作流全景步骤 命令 生成文件 核心作用1 /speckit.constitution .specify/memory/constitution.md 项目治理原则所有后续决策的底线2 /speckit.specify specs/[FEATURE]/spec.md 用户故事和功能需求only「what」和「why」3 /speckit.plan specs/[FEATURE]/plan.md 技术架构和技术栈选型4 /speckit.clarify — 解决歧义提前暴露假设5 /speckit.tasks specs/[FEATURE]/tasks.md 带依赖关系的任务清单6 /speckit.analyze — 跨文件一致性验证7 /speckit.implement 实际代码 系统性执行所有任务这七步里最容易被跳过的是第 4 步clarify和第 6 步analyze。跳过这两步的代价往往在第 7 步才暴露出来——任务跑到一半发现两个模块的接口不兼容或者某个边界情况根本没考虑进去。有实践者在完整走完一个 Azure 微服务项目后报告在 analyze 阶段自动发现了 9 个潜在问题包括「缺失 FluentValidation 验证器」和「DI 注册顺序错误」——这两个如果等到 implement 阶段才发现代价是完全不同的。最终生成的目录结构是这样的specs/[FEATURE]/├── spec.md # 用户故事和功能需求├── plan.md # 技术架构和决策├── tasks.md # 带依赖关系的工作分解├──>项目治理原则技术栈约定后端Java 17 Spring Boot 3.x数据库MySQL 8.0禁止使用 JSON 字段做核心业务查询ORMMyBatis-Plus禁止写原生 SQL 到 Service 层性能要求列表接口 P99 ≤ 200ms数据量 100 万时分页必须在数据库层面完成禁止前端分页禁止行为禁止在 Controller 层写业务逻辑禁止 Transactional 注解用在 private 方法上这个文件写得越详细后续每个 spec 的质量就越高——因为 AI 在生成 plan 和 tasks 时会把这些约束自动带进去。第四步写第一个 spec假设你要实现「用户列表按注册时间排序」这个功能在 Claude Code 里执行/speckit.specifyAI 会引导你描述需求最终生成 specs/001-user-list-sort/spec.md。一个规范的 spec.md 长这样用户列表排序功能背景运营团队需要能够按注册时间对用户列表进行排序以便优先联系最新注册的用户。用户故事作为运营人员我希望能够在用户列表页按注册时间升序/降序排序以便我能快速定位需要跟进的新用户。功能需求支持按registered_at字段排序非created_at默认按注册时间降序排序必须在数据库层面完成支持分页场景下的正确性前端控件列表头部的可点击排序箭头不在范围内多字段组合排序排序偏好的持久化不记忆用户上次的排序选择