spce-kit使用详解github上爆火项目，实用的ai开范式，一周16k start项目Spec-Kit详解。简介、

文档概述

本文档详细说明如何验证Spec-Kit命令执行效果，快速发现意外情况，以及各命令的功能、影响和与Git的关系。

1. Spec-Kit 命令功能与影响分析

1.1 命令总览表

命令	功能描述	生成文件	影响范围	Git操作	验证方法	执行角色
`/constitution`	建立项目宪法和开发原则	`memory/constitution.md`	全局影响，指导所有后续开发	创建新文件，建议立即提交	检查文件内容完整性	Spec-Kit自动
`/specify`	定义功能规格和需求	`specs/[###-feature]/spec.md`	单个功能模块	创建新分支和文件	检查规格完整性和清晰度	Spec-Kit自动
`/plan`	制定技术实现方案	`specs/[###-feature]/plan.md` `research.md` `data-model.md` `contracts/`	技术架构和实现细节	在功能分支中创建文件	检查技术方案可行性	Spec-Kit自动
`/tasks`	生成可执行任务清单	`specs/[###-feature]/tasks.md`	具体实现步骤	在功能分支中创建文件	检查任务完整性和依赖关系	Spec-Kit自动
`/implement`	执行任务并生成代码	实际代码文件测试文件配置文件	整个项目代码库	在功能分支中创建/修改文件	检查代码质量和功能完整性	Spec-Kit自动

1.1.1 角色分工说明

角色	职责范围	具体任务	自动化程度
Spec-Kit系统	核心命令执行	执行 `/constitution`、`/specify`、`/plan`、`/tasks`、`/implement` 命令	100% 自动
AI助手	辅助验证和优化	代码审查、测试生成、文档优化、问题诊断	80% 自动 + 20% 人工确认
开发人员	人工验证和决策	需求确认、架构审批、质量把关、业务决策	100% 人工
测试人员	质量保证	功能测试、性能测试、用户验收测试	70% 自动 + 30% 人工
项目经理	项目管理	进度跟踪、风险评估、资源协调	60% 自动 + 40% 人工

1.2 详细命令分析

1.2.1 `/constitution` 命令

功能作用：

建立项目的核心开发原则和约束
为所有后续开发提供指导方针
定义代码质量、测试标准、性能要求等

生成文件：

memory/
├── constitution.md                    # 项目宪法文档
└── constitution_update_checklist.md   # 宪法更新检查清单

角色分工：

Spec-Kit自动完成：生成宪法文档内容、创建文件结构
AI助手可协助：优化宪法内容、检查逻辑一致性、补充遗漏原则
开发人员必须：确认宪法内容符合项目需求、审批最终版本
项目经理参与：确保宪法符合组织标准、协调团队共识

Git操作：

# 创建新文件
git add memory/constitution.md
git add memory/constitution_update_checklist.md
git commit -m "feat: 建立项目宪法和开发原则"

验证检查清单：

意外情况检测：

# 检查文件是否存在
ls -la memory/constitution.md

# 检查文件内容
cat memory/constitution.md

# 检查文件大小（不应为空）
wc -l memory/constitution.md

1.2.2 `/specify` 命令

功能作用：

将用户需求转换为结构化的功能规格
生成用户故事和验收标准
为技术规划提供基础

生成文件：

specs/
└── [###-feature-name]/              # 功能分支目录
    └── spec.md                      # 功能规格文档

角色分工：

Spec-Kit自动完成：解析需求描述、生成规格文档、创建分支结构
AI助手可协助：优化用户故事描述、完善验收标准、检查需求完整性
产品经理必须：确认需求理解正确、审批功能规格、协调利益相关者
开发人员参与：评估技术可行性、提出实现建议、确认需求可测试性
测试人员参与：审查验收标准、补充测试场景、确认需求可验证性

Git操作：

# 创建功能分支
git checkout -b 001-core-drawing

# 创建规格文件
git add specs/001-core-drawing/spec.md
git commit -m "feat: 定义核心绘图功能规格"

验证检查清单：

意外情况检测：

# 检查分支是否创建
git branch | grep 001-core-drawing

# 检查文件内容
cat specs/001-core-drawing/spec.md

# 检查规格完整性
grep -c "User Story" specs/001-core-drawing/spec.md
grep -c "Acceptance" specs/001-core-drawing/spec.md
grep -c "Requirements" specs/001-core-drawing/spec.md

1.2.3 `/plan` 命令

功能作用：

将功能规格转换为技术实现方案
生成详细的技术文档
为任务分解提供基础

生成文件：

specs/[###-feature-name]/
├── plan.md              # 实现计划
├── research.md          # 技术研究
├── data-model.md        # 数据模型
├── quickstart.md        # 快速开始指南
├── contracts/           # API合约
│   ├── api-spec.json    # API规格
│   └── [feature]-spec.md # 功能接口规格
└── [AGENT].md           # AI助手配置文件

角色分工：

Spec-Kit自动完成：生成技术方案、创建技术文档、设计数据模型
AI助手可协助：优化技术选型、完善API设计、补充技术研究、代码生成
架构师必须：审批技术架构、确认技术选型、评估技术风险
开发人员参与：评估实现复杂度、确认技术可行性、提供实现建议
测试人员参与：确认测试策略、评估测试复杂度、设计测试方案
DevOps工程师参与：评估部署复杂度、确认基础设施需求

Git操作：

# 在功能分支中添加文件
git add specs/001-core-drawing/plan.md
git add specs/001-core-drawing/research.md
git add specs/001-core-drawing/data-model.md
git add specs/001-core-drawing/contracts/
git commit -m "feat: 制定核心绘图功能技术实现方案"

验证检查清单：

意外情况检测：

# 检查所有文件是否生成
ls -la specs/001-core-drawing/

# 检查文件内容完整性
head -20 specs/001-core-drawing/plan.md
head -20 specs/001-core-drawing/research.md
head -20 specs/001-core-drawing/data-model.md

# 检查API合约
ls -la specs/001-core-drawing/contracts/
cat specs/001-core-drawing/contracts/api-spec.json

1.2.4 `/tasks` 命令

功能作用：

将技术计划分解为可执行的任务
定义任务依赖关系
标记可并行执行的任务

生成文件：

specs/[###-feature-name]/
└── tasks.md             # 任务清单

角色分工：

Spec-Kit自动完成：分解技术计划、生成任务清单、定义依赖关系
AI助手可协助：优化任务描述、调整任务顺序、补充遗漏任务、估算工作量
项目经理必须：审批任务计划、分配资源、确认时间安排、协调团队
开发人员参与：确认任务可执行性、评估技术复杂度、提供实现建议
测试人员参与：确认测试任务完整性、评估测试工作量、设计测试策略

Git操作：

# 在功能分支中添加任务文件
git add specs/001-core-drawing/tasks.md
git commit -m "feat: 生成核心绘图功能实现任务清单"

验证检查清单：

意外情况检测：

# 检查任务文件
cat specs/001-core-drawing/tasks.md

# 检查任务数量
grep -c "T[0-9]" specs/001-core-drawing/tasks.md

# 检查并行任务标记
grep -c "\[P\]" specs/001-core-drawing/tasks.md

# 检查任务依赖
grep -A5 -B5 "Dependencies" specs/001-core-drawing/tasks.md

1.2.5 `/implement` 命令

功能作用：

执行任务并生成实际代码
运行测试验证功能
更新项目文档

生成文件：

app/
├── src/main/kotlin/     # Kotlin源码
├── src/main/cpp/        # C++源码
├── src/test/            # 测试文件
├── build.gradle         # 构建配置
└── 其他项目文件

角色分工：

Spec-Kit自动完成：执行任务清单、生成代码文件、运行基础测试
AI助手可协助：代码优化、测试用例生成、文档编写、代码审查、bug修复
开发人员必须：代码审查、架构决策、复杂逻辑实现、性能优化
测试人员必须：功能测试、集成测试、性能测试、用户验收测试
DevOps工程师参与：部署配置、环境设置、CI/CD流程、监控配置
产品经理参与：功能验收、用户体验验证、需求变更确认

Git操作：

# 在功能分支中添加代码文件
git add .
git commit -m "feat: 实现核心绘图功能"

# 合并到主分支
git checkout main
git merge 001-core-drawing
git push origin main

验证检查清单：

意外情况检测：

# 检查代码编译
./gradlew build

# 检查测试
./gradlew test

# 检查代码质量
./gradlew lint

# 检查文件结构
find app/src -name "*.kt" | head -10
find app/src -name "*.cpp" | head -10

2. 自动化验证脚本

2.1 命令执行验证脚本

#!/bin/bash
# verify_spec_kit.sh - Spec-Kit命令验证脚本

echo "=== Spec-Kit 命令验证脚本 ==="

# 检查constitution命令
verify_constitution() {
    echo "检查 /constitution 命令执行结果..."
    
    if [ ! -f "memory/constitution.md" ]; then
        echo "❌ 错误: constitution.md 文件不存在"
        return 1
    fi
    
    if [ ! -s "memory/constitution.md" ]; then
        echo "❌ 错误: constitution.md 文件为空"
        return 1
    fi
    
    # 检查关键内容
    if ! grep -q "代码质量" memory/constitution.md; then
        echo "❌ 错误: 缺少代码质量原则"
        return 1
    fi
    
    if ! grep -q "测试标准" memory/constitution.md; then
        echo "❌ 错误: 缺少测试标准"
        return 1
    fi
    
    echo "✅ constitution 命令执行正常"
    return 0
}

# 检查specify命令
verify_specify() {
    local feature_name=$1
    echo "检查 /specify 命令执行结果..."
    
    if [ ! -d "specs/$feature_name" ]; then
        echo "❌ 错误: 功能目录不存在: specs/$feature_name"
        return 1
    fi
    
    if [ ! -f "specs/$feature_name/spec.md" ]; then
        echo "❌ 错误: spec.md 文件不存在"
        return 1
    fi
    
    # 检查关键内容
    if ! grep -q "User Story" specs/$feature_name/spec.md; then
        echo "❌ 错误: 缺少用户故事"
        return 1
    fi
    
    if ! grep -q "Requirements" specs/$feature_name/spec.md; then
        echo "❌ 错误: 缺少功能需求"
        return 1
    fi
    
    echo "✅ specify 命令执行正常"
    return 0
}

# 检查plan命令
verify_plan() {
    local feature_name=$1
    echo "检查 /plan 命令执行结果..."
    
    local required_files=("plan.md" "research.md" "data-model.md" "contracts")
    
    for file in "${required_files[@]}"; do
        if [ ! -e "specs/$feature_name/$file" ]; then
            echo "❌ 错误: 缺少文件: $file"
            return 1
        fi
    done
    
    echo "✅ plan 命令执行正常"
    return 0
}

# 检查tasks命令
verify_tasks() {
    local feature_name=$1
    echo "检查 /tasks 命令执行结果..."
    
    if [ ! -f "specs/$feature_name/tasks.md" ]; then
        echo "❌ 错误: tasks.md 文件不存在"
        return 1
    fi
    
    # 检查任务数量
    local task_count=$(grep -c "T[0-9]" specs/$feature_name/tasks.md)
    if [ $task_count -lt 5 ]; then
        echo "❌ 错误: 任务数量不足: $task_count"
        return 1
    fi
    
    echo "✅ tasks 命令执行正常"
    return 0
}

# 检查implement命令
verify_implement() {
    echo "检查 /implement 命令执行结果..."
    
    # 检查代码编译
    if ! ./gradlew build > /dev/null 2>&1; then
        echo "❌ 错误: 代码编译失败"
        return 1
    fi
    
    # 检查测试
    if ! ./gradlew test > /dev/null 2>&1; then
        echo "❌ 错误: 测试失败"
        return 1
    fi
    
    echo "✅ implement 命令执行正常"
    return 0
}

# 主函数
main() {
    local command=$1
    local feature_name=$2
    
    case $command in
        "constitution")
            verify_constitution
            ;;
        "specify")
            verify_specify $feature_name
            ;;
        "plan")
            verify_plan $feature_name
            ;;
        "tasks")
            verify_tasks $feature_name
            ;;
        "implement")
            verify_implement
            ;;
        "all")
            verify_constitution
            verify_specify $feature_name
            verify_plan $feature_name
            verify_tasks $feature_name
            verify_implement
            ;;
        *)
            echo "用法: $0 <command> [feature_name]"
            echo "命令: constitution, specify, plan, tasks, implement, all"
            exit 1
            ;;
    esac
}

main "$@"

2.2 使用示例

# 验证constitution命令
./verify_spec_kit.sh constitution

# 验证specify命令
./verify_spec_kit.sh specify 001-core-drawing

# 验证所有命令
./verify_spec_kit.sh all 001-core-drawing

3. 人工验证检查清单

3.1 Constitution 命令验证

## Constitution 命令验证清单

### 文件检查
- [ ] `memory/constitution.md` 文件存在
- [ ] 文件大小 > 0 字节
- [ ] 文件格式正确（Markdown）

### 内容检查
- [ ] 包含代码质量原则
- [ ] 包含测试标准要求
- [ ] 包含性能指标定义
- [ ] 包含架构原则说明
- [ ] 包含安全要求定义
- [ ] 内容完整，无缺失部分

### 质量检查
- [ ] 原则描述清晰明确
- [ ] 原则之间无冲突
- [ ] 原则可执行可验证
- [ ] 符合项目需求

3.2 Specify 命令验证

## Specify 命令验证清单

### 文件检查
- [ ] 功能分支已创建
- [ ] `specs/[feature]/spec.md` 文件存在
- [ ] 文件大小 > 0 字节

### 内容检查
- [ ] 包含用户故事描述
- [ ] 包含验收标准
- [ ] 包含功能需求列表
- [ ] 包含非功能需求
- [ ] 需求描述清晰无歧义

### 质量检查
- [ ] 没有技术实现细节
- [ ] 需求可测试可验证
- [ ] 需求完整覆盖功能
- [ ] 需求之间无冲突

3.3 Plan 命令验证

## Plan 命令验证清单

### 文件检查
- [ ] `plan.md` 文件存在
- [ ] `research.md` 文件存在
- [ ] `data-model.md` 文件存在
- [ ] `contracts/` 目录存在
- [ ] API规格文件存在

### 内容检查
- [ ] 包含技术架构设计
- [ ] 包含数据模型定义
- [ ] 包含API接口设计
- [ ] 技术方案符合宪法要求
- [ ] 技术选型合理可行

### 质量检查
- [ ] 架构设计清晰合理
- [ ] 技术选型有充分理由
- [ ] 实现方案可执行
- [ ] 符合项目约束

3.4 Tasks 命令验证

## Tasks 命令验证清单

### 文件检查
- [ ] `tasks.md` 文件存在
- [ ] 文件大小 > 0 字节

### 内容检查
- [ ] 包含任务编号和描述
- [ ] 包含任务依赖关系
- [ ] 标记并行任务 [P]
- [ ] 任务描述具体可执行
- [ ] 包含测试任务

### 质量检查
- [ ] 任务顺序合理
- [ ] 任务覆盖完整
- [ ] 依赖关系正确
- [ ] 任务可并行执行

3.5 Implement 命令验证

## Implement 命令验证清单

### 代码检查
- [ ] 代码文件已生成
- [ ] 代码编译通过
- [ ] 无语法错误
- [ ] 无运行时错误

### 测试检查
- [ ] 测试用例通过
- [ ] 测试覆盖率达标
- [ ] 单元测试完整
- [ ] 集成测试通过

### 质量检查
- [ ] 代码质量检查通过
- [ ] 功能验证通过
- [ ] 文档更新完成
- [ ] 性能指标达标

4. 意外情况检测与处理

4.1 常见意外情况

意外情况	检测方法	处理方案	预防措施
文件未生成	检查文件是否存在	重新执行命令	分阶段验证
文件内容为空	检查文件大小	重新执行命令	内容验证
代码编译失败	运行编译命令	修复语法错误	语法检查
测试失败	运行测试命令	修复测试用例	测试驱动
功能不完整	功能验证测试	补充实现	需求验证

4.2 自动检测脚本

#!/bin/bash
# detect_issues.sh - 意外情况检测脚本

detect_file_issues() {
    echo "检测文件生成问题..."
    
    # 检查constitution文件
    if [ ! -f "memory/constitution.md" ] || [ ! -s "memory/constitution.md" ]; then
        echo "❌ 问题: constitution文件缺失或为空"
        return 1
    fi
    
    # 检查spec文件
    for spec_dir in specs/*/; do
        if [ -d "$spec_dir" ]; then
            if [ ! -f "$spec_dir/spec.md" ] || [ ! -s "$spec_dir/spec.md" ]; then
                echo "❌ 问题: $spec_dir/spec.md 缺失或为空"
                return 1
            fi
        fi
    done
    
    echo "✅ 文件生成正常"
    return 0
}

detect_code_issues() {
    echo "检测代码问题..."
    
    # 检查编译
    if ! ./gradlew build > /dev/null 2>&1; then
        echo "❌ 问题: 代码编译失败"
        echo "运行 './gradlew build' 查看详细错误"
        return 1
    fi
    
    # 检查测试
    if ! ./gradlew test > /dev/null 2>&1; then
        echo "❌ 问题: 测试失败"
        echo "运行 './gradlew test' 查看详细错误"
        return 1
    fi
    
    echo "✅ 代码质量正常"
    return 0
}

detect_content_issues() {
    echo "检测内容质量问题..."
    
    # 检查constitution内容
    if ! grep -q "代码质量" memory/constitution.md; then
        echo "❌ 问题: constitution缺少代码质量原则"
        return 1
    fi
    
    # 检查spec内容
    for spec_file in specs/*/spec.md; do
        if [ -f "$spec_file" ]; then
            if ! grep -q "User Story" "$spec_file"; then
                echo "❌ 问题: $spec_file 缺少用户故事"
                return 1
            fi
        fi
    done
    
    echo "✅ 内容质量正常"
    return 0
}

# 主函数
main() {
    local all_good=true
    
    if ! detect_file_issues; then
        all_good=false
    fi
    
    if ! detect_code_issues; then
        all_good=false
    fi
    
    if ! detect_content_issues; then
        all_good=false
    fi
    
    if [ "$all_good" = true ]; then
        echo "🎉 所有检查通过，项目状态正常"
    else
        echo "⚠️  发现问题，请检查上述错误"
        exit 1
    fi
}

main "$@"

5. Git 集成与最佳实践

5.1 Git 工作流

# 1. Constitution 阶段
git checkout -b setup/constitution
/constitution 建立项目宪法
git add memory/constitution.md
git commit -m "feat: 建立项目宪法和开发原则"
git push origin setup/constitution

# 2. Specify 阶段
git checkout -b 001-core-drawing
/specify 开发核心绘图功能
git add specs/001-core-drawing/spec.md
git commit -m "feat: 定义核心绘图功能规格"
git push origin 001-core-drawing

# 3. Plan 阶段
/plan 制定技术实现方案
git add specs/001-core-drawing/plan.md specs/001-core-drawing/research.md
git commit -m "feat: 制定核心绘图功能技术实现方案"
git push origin 001-core-drawing

# 4. Tasks 阶段
/tasks
git add specs/001-core-drawing/tasks.md
git commit -m "feat: 生成核心绘图功能实现任务清单"
git push origin 001-core-drawing

# 5. Implement 阶段
/implement
git add .
git commit -m "feat: 实现核心绘图功能"
git push origin 001-core-drawing

# 6. 合并到主分支
git checkout main
git merge 001-core-drawing
git push origin main

5.2 Git 钩子验证

#!/bin/bash
# .git/hooks/pre-commit - 提交前验证

echo "运行 Spec-Kit 验证..."

# 检查constitution文件
if [ -f "memory/constitution.md" ]; then
    if ! grep -q "代码质量" memory/constitution.md; then
        echo "❌ 错误: constitution文件不完整"
        exit 1
    fi
fi

# 检查spec文件
for spec_file in specs/*/spec.md; do
    if [ -f "$spec_file" ]; then
        if ! grep -q "User Story" "$spec_file"; then
            echo "❌ 错误: $spec_file 不完整"
            exit 1
        fi
    fi
done

# 检查代码编译
if [ -f "build.gradle" ]; then
    if ! ./gradlew build > /dev/null 2>&1; then
        echo "❌ 错误: 代码编译失败"
        exit 1
    fi
fi

echo "✅ 验证通过"
exit 0

5.3 分支管理策略

# 主分支保护
main                    # 主分支，只接受PR合并
develop                 # 开发分支，集成所有功能
feature/001-drawing     # 功能分支，每个功能一个分支
hotfix/bug-fix-001     # 热修复分支，紧急修复
release/v1.0.0         # 发布分支，准备发布版本

6. 角色分工详细说明

6.1 Spec-Kit 系统自动化能力

自动化类型	具体能力	完成度	备注
文档生成	生成宪法、规格、计划、任务清单	100%	完全自动化，无需人工干预
代码生成	生成基础代码框架、数据模型、API接口	85%	需要人工审查和优化
测试生成	生成单元测试、集成测试框架	80%	需要人工补充测试用例
Git操作	创建分支、提交代码、合并分支	90%	需要人工确认合并策略
验证检查	文件存在性、内容完整性检查	95%	需要人工质量把关

6.2 AI助手协助能力

协助类型	具体能力	完成度	适用场景
代码优化	代码重构、性能优化、最佳实践应用	70%	代码审查阶段
测试增强	补充测试用例、边界测试、压力测试	75%	测试完善阶段
文档完善	技术文档、用户手册、API文档	80%	文档编写阶段
问题诊断	Bug分析、性能问题定位、架构问题识别	65%	问题排查阶段
需求分析	需求澄清、用户故事优化、验收标准完善	60%	需求确认阶段

6.3 人工必须参与的任务

角色	必须参与的任务	参与程度	关键决策点
产品经理	需求确认、功能验收、用户体验验证	100%	需求变更、功能优先级
架构师	技术架构审批、技术选型确认、架构决策	100%	技术方向、架构变更
开发人员	代码审查、复杂逻辑实现、性能优化	100%	代码质量、技术实现
测试人员	功能测试、集成测试、用户验收测试	100%	质量保证、测试策略
项目经理	进度管理、资源协调、风险控制	100%	项目决策、资源分配

6.4 多角色协作场景

协作场景	参与角色	协作方式	自动化程度
需求确认	产品经理 + AI助手 + 开发人员	需求评审会议 + AI辅助分析	60%
技术评审	架构师 + 开发人员 + AI助手	技术评审会议 + AI辅助优化	70%
代码审查	开发人员 + AI助手 + 测试人员	代码审查工具 + AI辅助检查	80%
测试执行	测试人员 + AI助手 + 开发人员	自动化测试 + AI辅助分析	75%
部署发布	DevOps + 开发人员 + 测试人员	CI/CD流水线 + 人工确认	85%

6.5 角色责任矩阵

任务类型	Spec-Kit	AI助手	产品经理	架构师	开发人员	测试人员	DevOps	项目经理
需求分析	生成	协助	主导	参与	参与	参与	-	协调
技术设计	生成	协助	参与	主导	参与	参与	参与	协调
代码实现	生成	协助	-	参与	主导	参与	参与	协调
测试执行	基础	协助	参与	-	参与	主导	参与	协调
部署发布	-	协助	参与	参与	参与	参与	主导	协调
质量保证	检查	协助	参与	参与	主导	主导	参与	协调

7. 总结

通过本指南，你可以：

全面了解 Spec-Kit 各命令的功能和影响
快速检测 命令执行是否成功
及时发现 意外情况和问题
有效处理 各种异常情况
规范管理 Git 版本控制
明确分工 各角色的职责和协作方式

关键要点：

每个命令都有明确的验证标准
自动化脚本可以快速检测问题
Git 集成确保版本控制规范
人工检查确保质量可靠
角色分工明确，协作高效

建议使用流程：

执行 Spec-Kit 命令
运行验证脚本
进行人工检查
提交到 Git
继续下一步开发

角色协作建议：

Spec-Kit 负责自动化执行
AI助手 负责辅助优化
人工团队 负责决策和质量把关
多角色协作 确保项目成功

这样可以确保 Spec-Kit 开发过程的可控性和可靠性。

spce-kit使用详解

文档概述

1. Spec-Kit 命令功能与影响分析

1.1 命令总览表

1.1.1 角色分工说明

1.2 详细命令分析

1.2.1 /constitution 命令

1.2.2 /specify 命令

1.2.3 /plan 命令

1.2.4 /tasks 命令

1.2.5 /implement 命令

2. 自动化验证脚本

2.1 命令执行验证脚本

2.2 使用示例

3. 人工验证检查清单

3.1 Constitution 命令验证

3.2 Specify 命令验证

3.3 Plan 命令验证

3.4 Tasks 命令验证

3.5 Implement 命令验证

4. 意外情况检测与处理

4.1 常见意外情况

4.2 自动检测脚本

5. Git 集成与最佳实践

5.1 Git 工作流

5.2 Git 钩子验证

5.3 分支管理策略

6. 角色分工详细说明

6.1 Spec-Kit 系统自动化能力

6.2 AI助手协助能力

6.3 人工必须参与的任务

6.4 多角色协作场景

6.5 角色责任矩阵

7. 总结

1.2.1 `/constitution` 命令

1.2.2 `/specify` 命令

1.2.3 `/plan` 命令

1.2.4 `/tasks` 命令

1.2.5 `/implement` 命令