文章总结： 本文介绍GitHub开源的Spec-Kit工具，通过规范驱动开发理念在ClaudeCode中建立标准化工作流。文章详细阐述了工具安装、初始化步骤及Constitution到Implement的完整流程，并提供了针对新项目和Bug修复的实践建议。此外，还分享了Kiro规约法与EARS语法作为补充方案，帮助开发者利用规范作为唯一可信源头驱动AI生成高质量代码。 综合评分： 88 文章分类： 产品介绍,解决方案
在claude code中无痛嵌入Spec 工作流
原创
hhh
黑极客hijackY
2026年1月11日 08:00 四川
近期，GitHub 官方发布了 Spec-Kit——一套基于规范驱动开发（Spec-Driven Development, SDD）理念的开源工具，并迅速引发关注。亲自体验了一番，确实能显著提升开发流程的规范性。项目地址：https://github.com/github/spec-kit，里面也有详细的案例可以参考，这里简单介绍下
什么是 Spec Kit？
Spec Kit 是 GitHub 开源的一套工具包，核心思想是 规范驱动开发。它倡导从“代码先行”转向“规范先行”，将规范作为项目开发的唯一可信源头，并以此驱动 AI 编程助手自动生成高质量、符合预期的代码。
简单来说，它是一套预置的 Claude Command，通过约束开发原则，实现以下标准化工作流：
constitution（项目原则） → specify（功能规范） → plan（实现计划） → tasks（任务分解） → implement（代码实现）
Spec Kit 的实现机制
Spec Kit 本质上是一套开发框架与工具集，并不绑定特定 AI 模型，而是作为中间层工作。它支持 Claude Code、Gemini CLI、GitHub Copilot 等多种 AI 代理，并提供标准化的命令与模板系统。
项目初始化后的典型结构如下：
项目根目录/
├── memory/
│ ├── constitution.md # 项目核心原则
│ └── constitution_update_checklist.md
├── specs/
│ └── 001-feature-name/
│ ├── spec.md # 功能规范
│ ├── plan.md # 实施计划
│ ├── tasks.md # 任务清单
│ ├── data-model.md # 数据模型
│ └── research.md # 技术调研
├── scripts/ # 自动化脚本
├── templates/ # 模板文件
└── CLAUDE.md # AI 会话记录
安装与初始化
1. 安装
首先安装 uv，然后通过它安装 specify-cli：
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
2. 初始化项目
在项目目录下执行：
specify init .
按提示输入 y，并选择你使用的 AI 助手（例如 Claude Code）。
接着选择脚本类型（Unix 类系统选 sh，Windows 选 ps）。
若遇到 GitHub API 频率限制（如返回 403 错误），可通过添加 GitHub Token 解决：
export GITHUB_TOKEN=your_token_here
# 或
specify init . --github-token your_token_here
初始化完成后，启动 Claude Code 即可看到新增的 speckit. 系列命令。
官方也提供一键创建项目的命令：
# 在已有项目中初始化，并指定为 claude code
specify init . --ai claude
# 检查工具安装
specify check
使用流程详解
1. 制定项目原则
使用 /speckit.constitution定义项目的核心原则与开发指南，它将指导后续所有工作。
/speckit.constitution 制定以代码质量、测试标准、用户体验一致性以及性能要求为核心的原则。
2. 描述功能需求
使用 /speckit.specify 描述你想要构建什么，重点应该放在“要构建什么”以及“为什么需要构建它”上，而不是所使用的技术栈。
/speckit.specify：构建一个能够帮助我将照片整理到不同相册的应用程序。相册按日期分类，支持在主页拖放排序，且不嵌套。照片在相册内以瓷砖网格形式展示。
完成这一步后，你应该会看到一个新的分支被创建出来（例如，001-create-taskify），同时specs/001-create-taskify目录中也会出现一个新的规格文件。
3. 澄清需求细节（可选但推荐）
通过 /speckit.clarifySpec-Kit 开始针对需求不明确的点，向我们提问。（也可无需额外输入直接执行）
/speckit.clarify 进行需求澄清，有无不足或未考虑到的地方（也可无需额外输入直接执行）
4. 制定技术实施计划
使用 /speckit.plan 说明技术栈与架构方案。（也可无需额外输入直接执行）
/speckit.plan：该应用程序使用 Vite 框架，最小化第三方依赖，尽量使用原生 HTML/CSS/JS。图片不上传至外部服务器，元数据存储于本地 SQLite 数据库。
5. 任务分解
通过 /speckit.tasks 将计划拆解为可执行的任务清单。（也可无需额外输入直接执行）
/speckit.tasks
6. 全面审核（可选，但推荐）
使用 /analyze 检测 spec.md、plan.md 和 tasks.md 各文档之间的一致性、完整性，并生成问题报告协助修复。
/analyze
7. 执行实现
最后通过 /speckit.implement 开始自动化编码。
/speckit.implement
实践建议
新项目完整流程
- 1. /speckit.constitution | 定义项目宪章与核心原则
- 2. /speckit.specify | 编写功能规格文档
- 3. /speckit.checklist | 验证规格是否达到可交付标准
- 4. /speckit.clarify | 澄清需求细节
- 5. /speckit.plan | 制定技术计划
- 6. speckit.tasks | 任务分解
- 7. /speckit.implement | 生成代码
二次使用或小型任务
对于已建立规范的项目或小需求、小bug，可直接从 /speckit.specify开始，或采用“快速路径”, 这里都不会重新生成 spec.md ：
场景一：处理复杂Bug（涉及多模块，需分析影响）可按以下流程
1. **需求澄清** | `/speckit.clarify`
2. **制定计划** | `/speckit.plan`
3. **分解任务** | `/speckit.tasks`
4. **生成代码** | `/speckit.implement`
场景二：修复简单Bug（逻辑、UI或配置问题，范围明确）可按以下流程
1. **制定计划** | `/speckit.plan`
2. **分解任务** | `/speckit.tasks`
3. **生成代码** | `/speckit.implement`
场景三：执行简单变更（如更新配置、调整脚本）可按以下流程
1. **分解任务** | `/speckit.tasks`
2. **生成代码** | `/speckit.implement`
这种“跳过 specify，直接进入 plan → tasks → implement”的模式被称为 Fast Path Workflow，可将修复周期缩短 40–60%，同时保持原有规范的完整性。
其他 Spec 设计方法
除了speckit流程，也可借鉴 Kiro 规约法，利用 EARS 语法 自定义规约结构。例如下面找到一个可用于 Claude Skill 的 Spec 工作流模板，当然也可以参考这个改成rules，让其每一步都遵循这个步骤：
---
name: spec-workflow
description: Standard software engineering workflow for requirement analysis, technical design, and task planning. Use this skill when developing new features, complex architecture designs, multi-module integrations, or projects involving database/UI design.
alwaysApply: false
---
## When to use this skill
Use this skill for **structured development workflow** when you need to:
- Develop new features from scratch
- Design complex architecture
- Integrate multiple modules
- Work on projects involving database design
- Work on projects involving UI design
- Ensure high-quality requirement analysis and acceptance criteria
**Do NOT use for:**
- Simple bug fixes
- Documentation updates
- Configuration changes
- Code refactoring (unless explicitly requested)
---
## How to use this skill (for a coding agent)
1. **Follow the workflow strictly**
- Each phase must be completed and confirmed by user before proceeding to next phase
- Never skip phases or proceed without user confirmation
- Use `interactiveDialog` tool when clarification is needed
2. **Apply EARS requirement syntax**
- Use EARS (Easy Approach to Requirements Syntax) for requirement descriptions
- Format: `While <optional precondition>, when <optional trigger>, the <system name> shall <system response>`
3. **Reference UI design rules when needed**
- If requirements involve frontend pages, must strictly reference `rules/ui-design.mdc`
- Determine design style and color palette in requirements phase
- Confirm design details with user before finalizing requirements
4. **Update task status**
- Keep task status updated in `tasks.md` file
- Mark tasks as completed when finished
- Work independently and efficiently while maintaining quality
---
# Spec Workflow
**Important: You must follow these rules. Each phase must be confirmed by the user before proceeding to the next phase.**
## Workflow Overview
1. If you determine that the user's input is a new requirement, you can work independently following standard software engineering practices. Confirm with user when necessary, and can use `interactiveDialog` tool to collect information.
2. Whenever the user inputs a new requirement, to standardize requirement quality and acceptance criteria, you must first understand the problem and requirements clearly. You must confirm with the user before proceeding to the next phase.
## Phase 1: Requirements Document and Acceptance Criteria Design
First complete the requirements design using EARS (Easy Approach to Requirements Syntax) method. If you determine the requirements involve frontend pages, **you must strictly reference `rules/ui-design.mdc` rule file**. Determine design style and color palette in the requirements phase. You must confirm requirement details with the user. After final confirmation, the requirements are finalized, then proceed to the next phase.
Save to `specs/spec_name/requirements.md`. After confirming with the user, proceed to the next phase.
**Reference format:**
'''
# Requirements Document
## Introduction
Requirement description
## Requirements
### Requirement 1 - Requirement Name
**User Story:** User story content
#### Acceptance Criteria
1. Use EARS syntax: While <optional precondition>, when <optional trigger>, the <system name> shall <system response>. For example: When "Mute" is selected, the laptop shall suppress all audio output.
2. ...
...
'''
## Phase 2: Technical Solution Design
After completing the requirements design, based on the current technical architecture and the confirmed requirements above, design the technical solution. It should be concise but accurately describe the technical architecture (e.g., architecture, tech stack, technology selection, database/interface design, test strategy, security). Use mermaid diagrams when necessary.
Save to `specs/spec_name/design.md`. You must confirm with the user clearly, then proceed to the next phase.
## Phase 3: Task Breakdown
After completing the technical solution design, based on the requirements document and technical solution, break down specific tasks. You must confirm with the user clearly, then save to `specs/spec_name/tasks.md`. After confirming with the user, proceed to the next phase and begin formal task execution. You need to update task status in a timely manner. When executing, work as independently and autonomously as possible to ensure efficiency and quality.
**Task reference format:**
'''
# Implementation Plan
- [ ] 1. Task Information
- Specific things to do
- ...
- _Requirement: Related requirement point number
'''
## Phase 4: Task Execution
- Begin formal task execution
- Update task status in `tasks.md` file in real-time
- Work independently and autonomously
- Ensure efficiency and quality
- Mark tasks as completed when finished
## Key Principles
1. **User Confirmation Required**: Each phase must be confirmed by the user before proceeding
2. **EARS Syntax**: Use EARS method for requirement descriptions
3. **UI Design Integration**: When requirements involve frontend pages, must reference UI design rules and determine design style in requirements phase
4. **Technical Accuracy**: Technical solutions should be concise but accurate
5. **Task Tracking**: Keep task status updated throughout execution
6. **Independent Execution**: Work autonomously while maintaining quality
下面这里是个简化版：
---
name: spec-workflow
description: 标准软件工程工作流，适用于新功能开发、复杂架构设计、多模块集成、数据库/UI 设计等项目。
alwaysApply: false
---
## 使用场景
适用于以下结构化开发场景：
- 从零开发新功能
- 设计复杂架构
- 多模块集成
- 涉及数据库/UI 设计的项目
不适用于：
- 简单 Bug 修复
- 文档更新
- 配置变更
- 代码重构（除非明确要求）
---
## 工作流阶段
1. **需求分析与验收标准设计**
使用 EARS 语法编写需求文档，涉及前端时需参考 UI 设计规范，确定样式与配色。保存为 `specs/<spec_name>/requirements.md`。
2. **技术方案设计**
基于需求设计技术架构、选型、数据接口、测试策略等。保存为 `specs/<spec_name>/design.md`。
3. **任务拆解**
将方案拆解为可执行任务，保存为 `specs/<spec_name>/tasks.md`。
4. **任务执行**
按任务清单开发，实时更新状态，确保高效交付。
该模板强调每阶段必须经用户确认后方可进入下一阶段，适合对质量与流程要求较高的项目。
参考资料
- • https://github.com/github/spec-kit
- • https://github.com/Fission-AI/OpenSpec
- • https://aws.amazon.com/cn/blogs/china/use-kiro-specification-driven-development-to-accelerate-data-quality-construction/
- • https://alistairmavin.com/ears/
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：黑极客hijackY hhh《在claude code中无痛嵌入Spec 工作流》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论