# 一、先讲结论

你需要的不是 openspec init。
你需要的是：
```
1. 固定流程
2. 固定模板
3. 固定约束提示
4. 固定目录结构
```
只要这四个存在，
AI 一样可以 100% 可控。

----

# 二、核心思路：把“流程”变成一个 Skill

在 Claude Code / Cursor 里，你可以创建一个 Skill：
例如：

```
/spec-proposal
/spec-apply
/spec-archive
```
本质上只是预设 Prompt 模板。

----

# 三、实现第一步：Proposal Skill

创建一个 Skill，内容如下：

----

### 📌 Skill 名称：spec-proposal
```
我们现在进入规范驱动开发流程。

规则：
1. 不允许写代码
2. 只生成结构化 Proposal
3. 如果有不明确的地方必须提问
4. 不允许自行假设

请输出：
- 背景
- 功能目标
- 影响模块
- 边界条件
- 数据影响
- 风险点
- 验收标准
```

----
当你需要新增功能时：
```
/spec-proposal 自定义专注时长
```
效果 ≈ OpenSpec proposal 阶段。
不需要 CLI。

----

# 四、实现第二步：Spec 固化

在项目里建立一个目录：
```
/specs
    active/
    archive/
```
每个功能一个文件：
```
/specs/active/add-custom-focus-duration.md
```
内容由 AI 生成。
这一步相当于 OpenSpec 的 changes 文件夹。

----

# 五、实现第三步：Task 拆解 Skill

再创建一个 Skill：

### 📌 Skill 名称：spec-tasks

```
根据当前 Spec 文档，
拆分为最小可执行任务。

要求：
- 每个任务可独立验证
- 每个任务引用 Spec 条款编号
- 不允许一次性生成所有代码
```
然后执行：

```
/spec-tasks
```

----

# 六、实现第四步：受控执行 Skill
创建：

### 📌 Skill 名称：spec-apply
```
根据当前 Spec 和指定 Task 执行。

规则：
1. 只能修改与该 Task 相关的文件
2. 禁止结构性重构
3. 若发现 Spec 不完整必须暂停
4. 输出变更摘要
```
执行：
```
/spec-apply Task-01
```
----

# 七、归档机制（不需要命令行）
完成功能后：
1. 将文件从 active 移动到 archive
2. 在 archive 中记录：
	- 变更文件
	- 决策说明
	- 验证结果
	- 回滚方式

这一步你可以让 AI 自动生成归档摘要。

----

# 八、为什么 Skills 比 CLI 更轻？

OpenSpec CLI 的优势：

- 自动生成目录
- 自动验证
- 自动归档
- 命令式控制

但劣势：

- 需要 Node 环境
- 团队需要统一安装
- 引入新工具链

Skills 方式：

- 0 安装成本
- 直接嵌入现有 AI 工作流
- 更灵活
- 更适合中小团队

----

# 九、两种方式本质对比
|维度|OpenSpecCLI|Skills方案|
|:-:|:-:|:-:|
|自动化程度|高|中|
|灵活性|中|高|
|上手成本|较高|极低|
|团队推广|需培训|几乎无门槛|
|可控性|强|同样可强（取决于纪律）|

关键在于：

>纪律，而不是工具。

----

# 十、什么时候必须用 CLI？

建议用 CLI 的场景：

- 50+ 人团队
- 需要自动验证机制
- 有严格审计流程
- 需要 CI 集成
- 有专门的 DevOps

否则，Skills 足够。

----

# 十一、真正的核心认知
很多人误以为：
>OpenSpec = 规范驱动开发

其实：

>规范驱动开发 ≠ 某个工具

工具只是执行器。
真正重要的是：
```
冻结需求 → 固化规范 → 拆任务 → 受控执行 → 归档
```
你用纸笔都能做。

----

# 十二、我的建议（现实一点）
如果你是：

- 个人开发者
- 2–5 人小团队
- 已经在用 Claude Code / Cursor


我建议：
👉 先用 Skills 实现轻量版规范驱动
👉 跑 2–3 个功能
👉 再考虑是否需要 CLI 自动化
别一上来就堆工具。
# 总体设计原则
整个体系分为 7 个 Skills：
```
/spec-start        # 启动规范流程
/spec-proposal     # 生成 Proposal
/spec-design       # 输出技术设计
/spec-tasks        # 拆分任务
/spec-apply        # 执行单个任务
/spec-review       # 代码与规范一致性审查
/spec-archive      # 归档总结
```
配套目录结构：

```
/specs
    /active
    /archive
```
----

# ① /spec-start —— 启动规范流程

📌 用途：强制 AI 进入“规范模式”
```
我们现在进入【规范驱动开发模式】。

从现在开始：
1. 不允许直接写代码
2. 不允许自行假设未明确的需求
3. 如果有不确定必须提问
4. 所有内容必须结构化输出

请确认进入 Spec 模式。
```
使用方式：
```
/spec-start
```
作用：
防止 AI 一上来就写代码。

----

# ② /spec-proposal —— 生成需求提案

📌 用途：冻结需求

```
请根据以下功能描述，生成结构化 Proposal。

输出格式必须包含：

# Proposal

## 1. 背景
为什么需要这个功能？

## 2. 功能目标
要解决什么问题？

## 3. 影响范围
涉及哪些模块？

## 4. 行为规则
具体业务规则。

## 5. 边界条件
异常、极端情况。

## 6. 数据影响
是否新增字段？修改结构？

## 7. 权限与安全影响

## 8. 性能影响

## 9. 风险点

## 10. 验收标准（可测试条件）

如果有任何不明确，必须提问。
禁止写代码。
```
使用方式：

```
/spec-proposal 增加自定义专注时长功能
```
输出后保存到：

```
/specs/active/feature-name.md
```

----

# ③ /spec-design —— 技术设计输出

📌 用途：从“业务需求”升级为“工程设计”

```
基于当前 Proposal，
生成技术设计文档。

必须包含：

# Technical Design

## 1. 架构影响分析
## 2. 数据模型变更
## 3. 接口变更
## 4. 依赖关系
## 5. 回滚方案
## 6. 向后兼容策略
## 7. 潜在技术风险

不允许写实现代码。
```
作用：避免 AI 直接“边写边想”。

----

# ④ /spec-tasks —— 拆分最小执行单元
📌 用途：禁止一次性生成

```
根据当前 Spec 文档，
拆分为最小可执行任务。

要求：

1. 每个任务必须可独立验证
2. 每个任务必须引用 Spec 条款编号
3. 每个任务必须明确修改文件范围
4. 禁止合并多个逻辑改动

输出格式：

# Task Breakdown

- Task-01 (Spec 4.2)
  - 描述：
  - 修改文件：
  - 验证方式：

- Task-02 ...
```


----

# ⑤ /spec-apply —— 受控执行任务

📌 用途：限制 AI 行为

```
根据当前 Spec 和指定 Task 执行实现。

规则：

1. 只能修改该 Task 相关文件
2. 禁止结构性重构
3. 禁止顺便优化
4. 若发现 Spec 不完整必须暂停
5. 输出变更摘要

执行任务：{Task-ID}
```
使用：

```
/spec-apply Task-01
```
这是整个体系最关键的一步。


----

# ⑥ /spec-review —— 规范一致性检查

📌 用途：防止 AI 偏离规范
```
请对当前代码变更进行一致性审查。

检查：

1. 是否完全符合 Spec
2. 是否存在未授权结构改动
3. 是否遗漏验收标准
4. 是否引入潜在副作用

输出：
- 一致性评分（0-100）
- 风险点
- 建议修改
```
这一步相当于轻量级“架构审计”。


----

# ⑦ /spec-archive —— 归档与沉淀
📌 用途：可追溯历史
```
请生成本次功能变更的归档文档。

包含：

# Change Summary

## 1. 功能名称
## 2. 修改文件列表
## 3. 核心决策说明
## 4. 风险评估
## 5. 回滚方式
## 6. 测试验证情况

生成后可移动到 /specs/archive
```

----

# 📁 推荐项目目录结构
```
project-root/
│
├── src/
├── specs/
│   ├── active/
│   └── archive/
```
规则：
- active 中只保留当前开发
- 完成后移动到 archive
- 每个功能一个独立 md 文件

----

# 🧩 高级增强版（可选）


你可以增加一个“全局约束 Skill”：

### /spec-guard


```
在整个开发过程中：

1. 所有实现必须引用 Spec
2. 禁止自行扩展功能
3. 禁止更改架构结构
4. 若与 Spec 冲突必须停止
```
这可以长期开启。


----

# 🏁 使用完整流程示例


```
/spec-start
/spec-proposal 新增批量导出功能
/spec-design
/spec-tasks
/spec-apply Task-01
/spec-review
/spec-apply Task-02
/spec-review
/spec-archive
```
这就是轻量版 OpenSpec。
不需要 Node。
不需要 CLI。
不需要额外工具。


----

# ⚖ 本质理解

这整套体系的核心不是 Prompt。
而是：
```
冻结需求 → 固化设计 → 拆任务 → 受控执行 → 审查 → 归档
```
只要流程在，

工具是什么不重要。
----

# 🔥 极简万能 Spec Prompt（完整版）
直接复制使用：
----
```
从现在开始，我们使用“规范驱动开发模式”。

规则：

1. 禁止直接写代码。
2. 禁止自行假设未明确需求。
3. 如果有不清晰的地方，必须先提问。
4. 所有输出必须结构化。
5. 每次实现必须可追溯到明确条款。

现在针对以下功能进行完整规范流程：

【功能描述：在此填写】

按以下阶段依次执行，不得跳过阶段。

————————————
阶段 1：Proposal
输出：
- 背景
- 功能目标
- 影响模块
- 行为规则
- 边界条件
- 数据影响
- 权限/安全影响
- 性能影响
- 风险点
- 验收标准
若有不明确必须提问。

————————————
阶段 2：Technical Design
输出：
- 架构影响分析
- 数据结构变更
- 接口变更
- 依赖关系
- 回滚方案
- 向后兼容策略

禁止写实现代码。

————————————
阶段 3：Task Breakdown
将功能拆分为最小可执行任务：
- 每个任务可独立验证
- 每个任务标注关联条款
- 明确修改文件范围

————————————
阶段 4：等待我指定 Task 才允许实现。
实现时：
- 仅修改指定范围
- 禁止结构性重构
- 若发现规范缺失必须暂停

————————————
阶段 5：实现完成后输出：
- 变更摘要
- 风险评估
- 一致性自检结果
```


----

# 🧠 使用方式示例


你只需这样发：

```
从现在开始，我们使用“规范驱动开发模式”。

【功能描述：给用户模块增加批量导出 Excel 功能】
```
然后 AI 会自动进入规范流程。

当它拆分完任务后，你说：

```
实现 Task-01
```
就进入受控执行阶段。


----

# 🎯 为什么这一条就够？


因为它同时完成了：


- 冻结需求

- 技术设计

- 任务拆解

- 受控执行

- 自检机制


本质上它是：

```
OpenSpec 流程的 Prompt 级压缩版
```


----

# 🧩 如果你想再压缩到“超短版”


给你 10 行终极极简版：

```
我们进入规范驱动开发模式：
1. 禁止直接写代码
2. 不清晰必须提问
3. 所有输出结构化
4. 先生成 Proposal
5. 再生成 Technical Design
6. 再拆分最小任务
7. 未指定任务不得实现
8. 实现时禁止重构
9. 每次实现必须自检一致性
10. 所有变更必须可追溯
```
这条可以长期固定放在对话顶部。


----

# ⚠ 真正关键的一句话


如果只能保留一句核心控制语：

```
如果规范不完整，必须停止实现并提问。
```
这句话是防失控的核心。

在 Claude Code / Cursor 里，你可以创建一个 Skill：例如：

不安装 OpenSpec，用 Skills 实现规范驱动开发（企业可落地轻量方案）

OpenSpec，用 Skills 实现规范驱动开发

数据库

规范驱动开发无需复杂工具，通过固定流程、模板和约束提示即可实现AI代码100%可控。核心方法：将开发流程拆分为Proposal、设计、任务拆解、受控执行等阶段，每个阶段创建对应Skill，确保AI按规范输出结构化内容。相比CLI工具，Skills方案更轻量、零安装成本，适合中小团队快速实施规范开发。关键在于严格执行冻结需求→固化规范→拆任务→受控执行→归档的流程，而非依赖特定工具。

数据结构

DevOps

2026新春采购季

coding

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

规范驱动开发无需复杂工具，通过固定流程、模板和约束提示即可实现AI代码100%可控。核心方法：将开发流程拆分为Proposal、设计、任务拆解、受控执行等阶段，每个阶段创建对应Skill，确保AI按规范输出结构化内容。相比CLI工具，Skills方案更轻量、零安装成本，适合中小团队快速实施规范开发。关键在于严格执行冻结...

不安装 OpenSpec，用 Skills 实现规范驱动开发（企业可落地轻量方案）-腾讯云开发者社区-腾讯云

不安装 OpenSpec，用 Skills 实现规范驱动开发（企业可落地轻量方案）

不安装 OpenSpec，用 Skills 实现规范驱动开发（企业可落地轻量方案）

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐