spec-kit 四大命令

5

这四个命名本质上是一套 vibe coding / spec-driven development 的阶段化心智模型，不是随意起的名字，而是刻意把 “人类在做软件时的思考顺序”拆解给 AI。

可以把它理解为：

给 AI 一个不会跳步、不会抢跑的开发流水线

下面我按 「做什么 / 产出什么 / 解决什么问题」 来逐个讲清楚。

1️⃣ /speckit.specify

Define what you want to build

核心定位

需求澄清与边界收敛阶段

这是整个 spec-kit 里 最重要的一步，但不写任何代码。

这个阶段 AI 在做什么？

  • 把你的自然语言需求转成明确、可验证的规格

  • 识别隐含假设

  • 主动补齐模糊点

  • 明确 做什么 / 不做什么

典型产出

  • 功能描述

  • User Stories

  • Acceptance Criteria

  • Non-Goals

示例（抽象）：

## User Story
As an admin
I want to deactivate a user
So that the user can no longer access the system

## Acceptance Criteria
- User status is updated to inactive
- Inactive users cannot log in
- Existing sessions are invalidated

## Non-Goals
- 不处理用户数据删除
- 不涉及权限系统重构

解决的核心问题

✅ 防止 AI “理解错需求却写得很自信”
✅ 防止你和 AI 对“完成”的理解不一致
✅ 为后续所有阶段提供不可推翻的依据

一句话总结：

specify 是在锁定“正确的问题”

2️⃣ /speckit.plan

Create technical implementation plans

核心定位

技术设计阶段（How）

这一步 仍然不写最终代码，而是决定：

  • 用什么技术

  • 放在哪一层

  • 怎么拆模块

  • 哪些是关键点 / 风险点

这个阶段 AI 在做什么？

  • 把 specify 的需求映射到你既定的技术栈

  • 拆分架构与模块

  • 确定数据流、调用链路

  • 标注实现顺序

典型产出

## High-Level Design
- HTTP endpoint: POST /users/{id}/deactivate
- Handler validates request and permissions
- Service handles business rules
- Repository updates user status

## Data Changes
- users.status: active -> inactive

## Error Cases
- User not found
- User already inactive

解决的核心问题

✅ 防止 AI 跳过设计直接写代码
✅ 防止中途推翻技术选型
✅ 提前暴露复杂点，而不是写到一半才发现

一句话总结：

plan 是在锁定“正确的解法”

3️⃣ /speckit.tasks

Generate actionable task lists

核心定位

工程执行拆解阶段

这是从“设计”到“编码”的桥梁。

这个阶段 AI 在做什么？

  • 把 plan 拆成可独立完成的最小任务

  • 明确任务顺序

  • 明确每个任务的完成定义（DoD）

典型产出

1. Add user status field validation in model
2. Implement repository method to update status
3. Add service method with business checks
4. Implement HTTP handler
5. Add unit tests for service

每个 task 都应该：

  • 不依赖隐含上下文

  • 可以单独 review

  • 可以单独测试

解决的核心问题

✅ 防止 AI 一口气生成一坨代码
✅ 防止遗漏关键步骤（比如测试、迁移）
✅ 让人类可以中途介入、调整顺序

一句话总结：

tasks 是在锁定“正确的执行顺序”

4️⃣ /speckit.implement

Execute all tasks

核心定位

受约束的实现阶段

这是 唯一允许大量写代码的阶段。

这个阶段 AI 在做什么？

  • 严格按照 tasks 顺序执行

  • 不擅自增加功能

  • 不偏离 plan

  • 不修改 specify 中的边界

行为约束示例

  • 如果 task 没提到 DB migration → 不写

  • 如果 plan 没提到缓存 → 不加

  • 如果 specify 明确 non-goal → 不碰

解决的核心问题

✅ 防止 scope creep
✅ 防止 AI “顺手优化”
✅ 保证结果可预测、可 review

一句话总结：

implement 是在“被约束地执行”

五、四个命名连起来的真正价值

把它们放在一起看，其实就是：

specify   → 锁定问题
plan      → 锁定解法
tasks     → 锁定步骤
implement → 锁定行为

这是 把人类高级工程思维强行灌给 AI 的流程化方案。

六、为什么这套命名在 vibe coding 里特别重要？

因为 AI 最大的问题不是不会写代码，而是：

  • 跳步骤

  • 自作主张

  • 过度发挥

  • 不可预测

而 speckit 这四步，本质上是：

用“阶段”代替“长 prompt”来约束 AI

七、给你一个实战建议（很重要）

在 Cursor / GPT 里，不要一次性说：

“帮我实现一个 XXX 功能”

而是严格走：

/speckit.specify
/speckit.plan
/speckit.tasks
/speckit.implement

你会明显感觉到：

  • 代码更像人写的

  • 改动更可控

  • 心智负担更小

你只需要说一句：
👉「我想把 speckit 用在 XXX 项目上」。