AI 编程的问题在于有没有一个稳定、可复用的工作流程。通过 SPEC → PLAN → TASK 这套流程，可解决需求混乱、上下文漂移、输出不稳定等常见问题。

为什么需要 SPEC → PLAN → TASK

很多 AI 编程失败的原因并不是模型能力不足，而是：

• 需求和实现混在一起
• AI 一边猜需求，一边做设计
• 改一个点，整体逻辑失控

SPEC → PLAN → TASK 的核心价值在于：

固定思考顺序，让 AI 只做“执行层”的事

对应关系：

层级	关注点
SPEC	做什么 & 不做什么
PLAN	如何实现
TASK	具体执行

SPEC：冻结需求边界

SPEC 的目标只有一个：

明确系统“要做什么”，并且在短期内不再变化

SPEC 应包含的内容

• 目标（Goal）
• 用户 / 系统行为
• 功能范围
• 非目标（明确不做什么）

简化示例

# SPEC: User Registration

## Goal
允许用户通过邮箱和密码注册账号

## User Flow
- 用户填写邮箱和密码
- 校验失败显示错误
- 成功后跳转登录页

## Functional Requirements
- 邮箱格式校验
- 密码最小长度限制

## Non-Goals
- 不包含第三方登录
- 不包含邮箱验证

判断标准：

技术栈完全更换后，SPEC 是否仍然成立
成立，说明边界清晰

PLAN：把需求变成实现路径

PLAN 用于回答：

在不写代码的前提下，系统准备如何实现

PLAN 通常包含：

• 模块划分
• 职责边界
• 实现思路

例如：

- 用户模块
- 注册接口
- 前端注册页面

PLAN 是一份还是多份？

推荐做法是：

• 一份主 PLAN（覆盖整体）
• 若干增量 PLAN（对应新增需求）

关键原则：

每一份 PLAN 都应是一个可冻结、可追溯的状态

TASK：AI 的执行指令

TASK 是直接交给 AI 执行的最小单元。

一个好的 TASK 应满足

1. 目标单一
2. 可独立完成
3. 有明确完成标准

对比示例

❌ 不清晰的 TASK：

实现用户注册功能

✅ 清晰的 TASK：

创建注册页面基础表单结构
- 包含邮箱和密码输入框
- 不包含校验逻辑
- 不做样式优化

经验法则：

一个 TASK 的输出不应超过 1–2 个文件

在 AI 编辑器中的使用方式

大多数情况下，不需要多次对话。

更高效的方式是：

一次性声明流程，让 AI 分阶段输出

示例：

请按以下流程处理需求：
1. 生成 SPEC
2. 基于 SPEC 生成 PLAN
3. 将 PLAN 拆分为 TASK
4. 分步骤输出

只有在以下情况才需要再次提问：

• 需求发生变化
• 单个 TASK 的结果需要调整

这套流程的实际收益

采用该流程后，通常可以观察到：

• AI 输出更稳定
• 上下文漂移显著减少
• 需求与实现边界更清晰

更重要的是：

AI 从“临时帮手”变成了“可控执行器”

体系化的使用

可以尝试自建 Skill 来实践该工作流，尝试不同提示词，找到最适合自己的方案；

也可以通过 Github 的 Spec Kit, 或 Kiro 编辑器的 Spec 工作流来使用，比起自己研究提示词生成更成熟。

总结

SPEC 冻结目标，PLAN 规划路径，TASK 驱动执行，AI 只负责 TASK 这一步。尤其是在创建新项目的时候，或者开发一个大型需求的时候，尤为好用。

当然，简单的需求也许不需要这么复杂的步骤，使用编辑器本身提供的 PLAN 模式就够了。

根据场景使用不同的方案，在不断的探索中，找到最适合自己的 AI 编程使用方式。