从6700%到「死刑」

2025年2月，Karpathy 在 X 上抛出一个词——Vibe Coding。

「完全沉浸开发氛围，拥抱 AI 效率，几乎忘悼代码本身。用自然语言描述需求，AI 生成代码，直接 Accept All，报错丢给 AI 修，只求能跑通。」

五个月后，这个词搜索量暴涨 6700%，被《柯林斯词典》评为 2025 年度词汇。Cursor、Claude Code 几乎所有 AI 编辑器都把 Vibe Coding 做成核心体验。

一年后的 2026 年 2 月 5 日，Karpathy 再次发声：

「Vibe Coding is dead. The future is Agentic Engineering.」

说这句话的人，正是当初创造它的人。

最近这段时间，我一直在琢磨一件事，就是怎么让AI写代码这件事，变得不那么玄学。

你肯定经历过那种循环，跟AI说帮我写个登录功能，它啪啪啪给你生成一大坨代码，你一看，方向偏了，推倒重来。再描述一遍需求，再生成，再偏，再来。来回折腾几轮，你自己都烦了，AI也懵了，最后还是自己上手写。

问题不在AI，问题在于，你把需求全装在脑子里，每次对话都在重新解释上下文。AI没有记忆，你也没有结构化的需求文档，两边都在凭感觉走。

然后GitHub开源了一个东西，叫Spec Kit。

106k Stars。。。

我研究了一下，觉得这玩意确实解决了一个很核心的问题，就是，把需求从你脑子里搬出来，写死成结构化的规格文件，然后让AI按规格生成代码。规格是第一等公民，代码只是规格的产出物。

说实话，写这种工具推荐的文章，我一直是有心理负担的。因为我自己也还在摸索，也还在踩坑，也不是说用了这玩意就从此走上人生巅峰了。但用了这段时间下来，确实感觉，跟以前那种「聊天写码」的模式比，效率和质量都稳了不少。

所以还是想聊聊。

不成熟的经验，但毫无保留了。

先说这玩意怎么装。

一行命令就行，前提是你有Python 3.11以上的环境，还有Git和uv（或者pipx）。

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

装完你就有了一个specify命令行工具。跑一下specify self check，确认装好了就行。

然后初始化项目，也是一行命令。

specify init my-project --integration copilot

那个–integration后面跟的是你用的AI编程工具。Spec Kit支持30多种，Copilot、Claude Code、Gemini、Codex、Kilo Code、Zed、Forge、Kiro都有。不在列表里也没事，有个generic兜底。

这条命令跑完，你的项目目录下会多出来一套脚手架。最关键的是两个东西，一个是.specify/memory/constitution.md，这是项目的「宪法」，后面所有规格、方案、任务都得遵守它。另一个是specs/目录，每个功能一个子目录，里面放spec.md、plan.md、tasks.md这些产物。

宪法这个概念，我觉得是Spec Kit最精妙的设计之一。

你想想看，以前你跟AI说帮我写个功能，它怎么知道你的项目要不要写测试？要不要用TDD？架构上有什么约束？它不知道，它就按自己的理解来了，写出来你再改。

宪法就是把这些约束提前写死。

在AI编程工具里跑/speckit.constitution这个斜杠命令，它会生成一份constitution.md，内容大概长这样。

# My Project Constitution

## Core Principles

### I. Library-First
Every feature starts as a standalone library.

### II. CLI Interface
Text in/out protocol: stdin/args → stdout, errors → stderr

### III. Test-First (NON-NEGOTIABLE)
Red-Green-Refactor cycle strictly enforced

### IV. Integration Testing
Contracts and communication paths tested end-to-end

### V. Simplicity
Start simple, YAGNI principles

## Governance
This constitution supersedes all other practices.

你看那个Test-First后面标了NON-NEGOTIABLE，这就是在告诉AI，不许跳过测试直接写实现，没得商量。

宪法里的原则会自动注入后续所有步骤。你写进去的约束越硬，AI的产出就越可控。

这个思路，其实跟软件工程里那个很经典的概念是通的，叫契约式设计（Design by Contract）。Bertrand Meyer在1980年代就提出来了，核心想法就是，组件之间的交互由前置条件、后置条件和不变式来约束，而不是靠运行时的善意。Spec Kit的宪法，就是把这种约束从运行时提到了开发流程的最前端。

宪法立好了，接下来就是写规格。

跑/speckit.specify，生成specs/001-feature-name/spec.md。

模板结构是固定的，我拿一个用户认证的例子给你看。

# Feature Specification

**Feature Branch**: 001-user-auth
**Created**: 2026-07-02
**Status**: Draft
**Input**: 用户需要邮箱密码登录

## User Scenarios & Testing *(mandatory)*

### Scenario 1: 正常登录
**Given** 用户已注册且密码正确
**When** 提交邮箱和密码
**Then** 返回认证token，跳转到首页

### Edge Cases
- 密码错误连续5次 → 锁定账号30分钟
- 邮箱未验证 → 提示验证

## Requirements *(mandatory)*

- FR-001: 系统MUST支持邮箱+密码认证
- FR-002: 系统MUST在密码错误5次后锁定账号
- FR-003: 系统MUST使用bcrypt哈希存储密码

## Success Criteria *(mandatory)*

- SC-001: 登录响应时间 < 200ms（P95）
- SC-002: 密码哈希验证通过率 100%

## Assumptions
- 用户已有邮箱
- 不支持第三方OAuth（V1）

几个硬约束你得注意。

User Scenarios是必填的，而且必须用Given/When/Then格式写，这就是你的验收标准，没得商量。

Requirements用FR-XXX编号，后面追溯全靠这个。

Success Criteria必须可量化。「体验好」不算，「< 200ms」算。

还有个细节我觉得挺用心的，就是不确定的地方用[NEEDS CLARIFICATION]标记。模板会阻止你在规格里写技术实现细节，写了就会被挡回来，逼你把「要什么」和「怎么做」分开。

规格写完之后，我强烈建议你跑一下/speckit.clarify。

这一步是可选的，但真的别跳过。

规格里标了[NEEDS CLARIFICATION]的地方，AI会主动追问你。这一步把模糊需求消解掉，而不是带着ambiguity往下走。模糊需求是bug的温床，多花5分钟澄清，能省5小时返工，这话我说了不下八百遍了。

还可以用/speckit.analyze做跨产物一致性检查，看看spec和plan之间有没有矛盾。

规格定好了，需求澄清了，接下来就是出技术方案。

跑/speckit.plan，生成plan.md。

# Implementation Plan

**Branch**: 001-user-auth
**Spec**: specs/001-user-auth/spec.md

## Summary
邮箱密码认证，bcrypt哈希，JWT token签发

## Technical Context
- Language: Python 3.11
- Primary Dependencies: FastAPI, SQLAlchemy, bcrypt
- Storage: PostgreSQL
- Testing: pytest
- Performance Goals: P95 < 200ms

## Constitution Check
GATE: Must pass before Phase 0 research

## Project Structure
src/
├── auth/
│   ├── library.py
│   └── cli.py
tests/
└── test_auth.py

## Complexity Tracking
| Violation | Why Needed | Simpler Alternative Rejected Because |
|-----------|-----------|-------------------------------------|

你看那个Constitution Check，这是个门控。如果方案违反了宪法，比如没写测试，这一步就过不去。它不是软提醒，是硬拦截。

plan还会顺带产出research.md（技术调研）、data-model.md（数据模型）、contracts/（API契约）这些文件。每一步的产出都是下一步的输入，结构化文档在流转，不是口头描述在衰减。

方案过了宪法检查，接下来拆任务。

任务

跑/speckit.tasks，生成tasks.md。

# Task List

## Phase 1: Setup
- [ ] T001 初始化项目结构和依赖
- [ ] T002 配置数据库迁移

## Phase 2: Foundational
- [ ] T003 实现密码哈希库（Library-First）
- [ ] T004 实现JWT token签发库

## Phase 3: User Story 1 — 正常登录
- [ ] T005 [P] 实现 POST /auth/login 端点
- [ ] T006 [P] 编写登录集成测试

## Phase 4: User Story 2 — 错误锁定
- [ ] T007 实现密码错误计数
- [ ] T008 实现账号锁定逻辑

## Polish & Cross-Cutting Concerns
- [ ] T009 错误处理统一
- [ ] T010 日志和监控接入

这里有几个规则你得知道。

[P]标记表示这个任务可以并行执行，前提是不同文件、无依赖。AI会真的并行跑这些任务，不是装饰。

Foundational Phase不完成，User Story不能开工。这是强制顺序约束。

两种策略可以选，MVP First，只做User Story 1就验证方向，或者Parallel Team，Foundational完成后多个Story并行推。我自己比较倾向MVP First，先验证方向对了再铺开，Parallel Team看着快，但方向错了就是并行返工。

任务拆好了，最后就是实现。

实现

跑/speckit.implement，AI按tasks.md逐条执行，遵守宪法里的TDD约束，先写测试，再写实现，最后重构。

实现完之后，记得跑一下/speckit.converge。这个命令检查代码库是否和规格一致。规格是源，代码是派生物，converge确认两者没漂移。代码和规格的漂移是渐进的，每次实现完都跑一次，别攒到最后。

好，整个流程走完了。Spec → Plan → Tasks → Implement，五步从想法到代码。

但我得坦诚说一下，一开始用这套流程，你可能会觉得，这也太慢了吧。。。

以前我直接跟AI说一句话就开始写代码了，现在要先立宪法、写规格、澄清需求、出方案、拆任务，光这些前置步骤就花了不少时间。花的时间可能比直接上手写还长。

但坚持几周之后，你会发现，返工的次数断崖式下降。因为方向在规格阶段就定准了，不是在代码阶段反复试错。而且规格文件就在那，下次改需求，改规格重新生成就行，不用从头解释。

这个感觉，就像以前你是口头点菜，每次服务员都得重新确认你要不要辣、要不要葱。现在你写了个固定菜单，照着做就行，不会出错。

开发模式

说到这，再聊聊Spec Kit的几种开发模式。

不是只有从零开始这一种玩法。

0-to-1模式，全新项目，从宪法开始完整走完五步，适合新项目启动。

Creative Exploration模式，技术选型阶段，同一份规格生成多个技术方案并行比较。比如你不确定用FastAPI还是Django，两份plan同时出，看完再选。

Iterative Enhancement模式，已有项目加功能。保持工具更新和功能开发分成两条线，别混在一起提交。

已有项目用这个模式的时候，有个建议，把工具链的更新和功能产物的演进分开。我之前就踩过坑，升级Spec Kit版本和开发新功能混在一个PR里，结果出了问题都不知道是哪个导致的。

顺着上面的再聊聊扩展体系。

Spec Kit有三层定制，优先级从高到低。

最上面是你项目本地的模板覆盖，放在.specify/templates/overrides/里，优先级最高。然后是Presets，用来修改模板，比如改成合规格式。再然后是Extensions，新增命令，比如Jira集成、代码审查。最底层是Core Templates，内置模板。

# 搜索和安装扩展
specify extension search jira
specify extension add jira

# 搜索和安装预设
specify preset search compliance
specify preset add compliance

# 安装角色套装
specify bundle install product-manager

社区已经有105个扩展，60多个作者贡献的，还有22个预设。企业可以部署私有扩展和预设目录。

有两个治理扩展我觉得挺实用的。

CI Guard，放在CI流水线里当门控，规格没过不让合并。Architecture Guard，检查架构约束，防止实现偏离方案。有合规要求的团队，这两个扩展把「人工review规格是否被遵守」变成了自动化检查，不是花架子。

回到最核心的那个点，换AI工具这件事。

今天用Copilot，明天想换Claude Code，怎么办？？？

一行命令。

specify init my-project --integration claude-code

规格、方案、任务都是纯Markdown，跟AI工具无关。换工具只换执行层，产物层完全复用。

这个设计真的挺好的。相当于你的需求资产是独立的，不绑定任何一家AI工具。今天用这个，明天换那个，零成本切换。你敢信？？？

我自己觉得，这可能是Spec Kit最被低估的一个特性。因为现在AI编程工具迭代太快了，三个月前的工具可能现在已经被替代了。如果你的需求、方案、任务都跟某个工具深度绑定，换工具就是全部重来。但如果都存在Markdown文件里，那就是你的资产，工具只是执行者。

总结

好，最后总结几条我自己用下来的实战建议。

1，宪法写狠一点。Test-First标成NON-NEGOTIABLE，AI就不会偷懒跳测试。原则越硬，产出越可控。你写得软绵绵的，AI就会钻空子。

2，规格里别写实现细节。spec.md是「要什么」，不是「怎么做」。技术方案留给plan.md。模板本身会阻止你越界，但你也要有这个意识，别硬往规格里塞技术选型。

3，clarify不要跳过。我知道你急着想看代码，但模糊需求是bug的温床。多花5分钟澄清，省5小时返工。这话我又说了一遍。

4，MVP First策略优先。先做User Story 1，验证方向对了再铺开。Parallel Team看着快，但方向错了就是并行返工，那才叫真的浪费时间。

5，converge要常跑。代码和规格漂移是渐进的，你今天偏一点，明天偏一点，攒到最后就是两个东西了。每次实现完都跑一次/speckit.converge，把漂移扼杀在摇篮里。

6，用[P]标记并行任务。tasks.md里的[P]不是装饰，AI会真的并行执行无依赖任务，显著缩短实现时间。但前提是你得标对，有依赖的别标[P]，不然并行执行会出问题。

回到最开始那个循环。

描述需求，AI生成代码，方向不对，推倒重来。

这个循环的根本问题，不是AI不够聪明，是你没有把需求结构化。需求在你脑子里是模糊的，到AI那里就更模糊了，模糊的需求不可能产生精确的代码。

Spec Kit做的事情，就是把模糊变精确，把口头变书面，把一次性变可复用。

规格是起点，代码是终点。

不是反过来。

这个思路，其实不新鲜。建筑行业几百年前就这么干了，先出蓝图再施工，没人会边想边盖楼。软件工程自己也有几十年的需求规格传统，SRS、SDD这些文档规范早就有了。但以前写这些文档太重了，没人愿意写，最后都变成了「敏捷」名义下的口头沟通。

Spec Kit的聪明之处在于，它让规格变成了AI可执行的东西。你不是在写没人看的文档，你是在写AI会严格按照它来生成代码的规格。写规格的投入，直接转化为代码产出的质量。这才是规格驱动开发真正能跑起来的原因。

不是因为你更有纪律了，是因为AI让规格有了执行力。

这才是这件事真正有意思的地方。

谢谢你看我的文章，我们，下次再见。