Spec Kit 快速上手从 specify init 到 /speckit.converge 的完整 SDD 工作流【免费下载链接】spec-kit Toolkit to help you get started with Spec-Driven Development项目地址: https://gitcode.com/GitHub_Trending/sp/spec-kitSpec KitSpecify CLI是一套面向 Spec-Driven Development规格驱动开发的工具包它通过specify init在项目中铺设模板、脚本与集成命令再由一系列/speckit.*斜杠命令驱动“规格 → 澄清 → 计划 → 任务 → 实现 → 收敛”的完整闭环。本文以官方快速上手指南为主线全程用一个示例项目Taskify一个小型团队生产力平台演示每一步的真实输入并结合specify init的源码实现与脚本层代码解释各步骤背后的工程细节帮助你从零跑通第一条特性。准备工作安装 Specify 并初始化项目自动化脚本提供 Bash.sh、PowerShell.ps1和 Python.py三种变体。交互式specify init会提示你选择其中一种非交互运行无 TTY或显式传入--non-interactive会按操作系统默认选择一种 shell 变体Windows 为ps其他平台为sh。你也可以用--script sh|ps|py显式指定。命令在下文中以/speckit.*形式书写但实际调用形式取决于你所用的 Agent。部分基于 skills 的 Agent 使用$speckit-*如 Codex、ZCode或/skill:speckit-*如 Kimi。使用你的 Agent 暴露的形式即可——步骤本身完全一致。安装 CLI 并初始化项目在终端中先从 PyPI 安装 CLI需要 uv然后初始化项目uv tool install specify-cli specify init taskify # 或specify init . 使用当前目录init会让你交互式地选择编码 Agent也可以用--integration显式传入例如--integration copilot。对于 CI 和 AI Agent 编排场景加上--non-interactive使未指定的选项使用文档化的默认值而不是卡在方向键选择器上。其他安装方式pipx、一次性uvx运行、固定版本、离线/内网环境见 安装指南。如果要把 Spec Kit 加入一个已有代码的仓库请先阅读 在既有项目中采用 Spec Kit再开始下面的工作流。specify init背后做了什么源码视角阅读 init 命令实现 可以确认文档中的行为细节集成选择传入--integration时会在注册表中校验init.py 中未知集成名会报错并列出全部可用集成非交互会话无 TTY 或--non-interactive默认落到内置的默认集成如 Copilot并打印提示。Agent 编排器即使分配了 PTYisatty()为真也无法发送方向键输入因此_prompts_allowed()init.py专门处理了这种伪交互场景避免挂起。脚本类型未显式传--script时默认为psWindows或sh其他平台交互模式下用方向键选择器init.py。初始化步骤命令会依次安装集成、共享基础设施模板与脚本、内置speckit工作流、初始化 constitution 文件并把feature_numbering: sequential、集成、脚本类型等写入 init 选项init.py。项目脚手架来自 CLI 包内捆绑的资源因此初始化本身不需要网络且模板版本与已安装 CLI 严格一致。失败清理如果初始化中途失败且项目目录是本次命令新建的源码会清理该目录init.py避免留下半成品。初始化完成后脚本会安装到与所选脚本类型对应的子目录.specify/scripts/bash/—.sh脚本Linux/macOS 默认.specify/scripts/powershell/—.ps1脚本Windows 默认.specify/scripts/python/—.py脚本--script py选择同时安装平台 shell 回退上下文感知当前特性是怎么被定位的Spec Kit 通过记录在.specify/feature.json中的特性目录来跟踪当前活动特性可用环境变量SPECIFY_FEATURE_DIRECTORY覆盖。各命令从该状态解析特性而不是从当前签出的 Git 分支解析——也就是说整个流程不强制要求 Git。可选的git 扩展会添加带编号的特性分支如001-feature-name用于在版本控制中组织工作但当前活动特性始终是状态文件指向的那个目录单独执行git checkout不会改变它。要把命令指向另一个特性更新.specify/feature.json或设置SPECIFY_FEATURE_DIRECTORY即可。这个解析逻辑在三套脚本实现中完全一致。以 Bash 公共库为例get_feature_paths()的解析优先级为见 common.sh环境变量SPECIFY_FEATURE_DIRECTORY显式覆盖相对路径会被归一化到仓库根目录下.specify/feature.json中的feature_directory键由 specify 命令持久化两者都没有则报错退出。Python 变体在 common.py 中实现了相同逻辑并且读取feature.json时按jq → python3 → grep/sed的顺序降级解析common.sh保证在缺少jq的机器上也能工作。解析成功后脚本会输出FEATURE_DIR、FEATURE_SPEC、IMPL_PLAN、TASKS等路径变量供各/speckit.*命令定位spec.md、plan.md、tasks.md等产物。推荐流程短路径与完整路径安装 Spec Kit 后下面每条命令都是流程中的一步。常见的有两条路径短路径—— 适用于较小的特性/speckit.specify/speckit.plan/speckit.tasks/speckit.implement/speckit.converge完整路径—— 适用于生产级特性额外加入/speckit.clarify、/speckit.checklist、/speckit.analyze作为质量门禁/speckit.constitution/speckit.specify/speckit.clarify/speckit.plan/speckit.checklist/speckit.tasks/speckit.analyze/speckit.implement/speckit.convergeStep 1/speckit.constitution— 确立项目原则建立项目的指导原则后续每一步都会对照它进行评估。开头运行一次即可把原则作为参数传入/speckit.constitution Taskify is a Security-First application. All user inputs must be validated. We use a microservices architecture. Code must be fully documented.Step 2/speckit.specify— 描述要构建什么从自然语言描述创建特性规格。聚焦what和why而不是技术栈/speckit.specify Develop Taskify, a team productivity platform where predefined users create projects, assign tasks, comment, and move tasks across Kanban columns (To Do, In Progress, In Review, Done). Five users (one product manager, four engineers), three sample projects, no login for this first phase.Step 3/speckit.clarify— 消除歧义针对规格中任何欠明确之处提出有针对性的问题并把你的回答折叠回规格避免在歧义之上做计划。在计划之前运行可以附带一个聚焦领域/speckit.clarify Focus on task card behavior — status changes, comment permissions, and user assignment.Step 4/speckit.plan— 选择技术栈从规格生成设计产物。实现细节应该出现在这里——提供技术栈与架构/speckit.plan Use .NET Aspire with Postgres. The frontend is Blazor Server with drag-and-drop boards and real-time updates. Expose REST APIs for projects, tasks, and notifications.Step 5/speckit.checklist— 验证规格生成自定义质量清单——相当于针对需求的单元测试——确认规格在拆解工作之前是完整、清晰、一致的。这些自定义清单是评审者持有reviewer-owned的需求质量评审产物只有当评审者认定某条需求质量准则被满足时才把条目标记为[x]。已勾选的自定义条目不代表实现工作已完成/speckit.checklistStep 6/speckit.tasks— 拆解工作从设计产物生成可执行、按依赖排序的tasks.md/speckit.tasks从 tasks 命令模板 对应的参考文档看任务按阶段组织Setup、Foundational阻塞性前置然后每个用户故事一个阶段按优先级排序最后是跨切面关注的Polish阶段任务在可行处会被标记为可并行执行。Step 7/speckit.analyze— 检查一致性在spec.md、plan.md、tasks.md之间报告冲突、缺口与歧义。它是只读的——如果它标记出问题请在源头修复后重跑再去实现/speckit.analyzeStep 8/speckit.implement— 构建按依赖顺序执行tasks.md中的任务。实现前它会读取清单checklist的复选框状态作为门禁如果有任何清单项未勾选会先询问你是否继续它不会修改任何清单文件或其标记。内置的checklists/requirements.md清单由/speckit.specify和/speckit.clarify维护而自定义清单保持评审者持有。可以一次运行构建全部内容也可以在大型特性中按阶段逐次限定范围/speckit.implement模板层面可以验证这个门禁implement 命令模板 明确要求扫描checklists/目录下所有清单文件——全部勾选为PASS存在未勾选项则为FAIL并停下来询问Do you want to proceed with implementation anyway? (yes/no)且明确说明自定义清单的[x]只表示需求质量准则已被评审满足不表示实现工作完成。Step 9/speckit.converge— 验证完整性对照规格、计划与任务检查代码库。如果发现缺口它会向tasks.md追加新任务再运行/speckit.implement并重复 converge直到它报告已收敛。否则就大功告成——进入评审或提交 PR/speckit.convergeconverge 命令模板 的 frontmatter 显示它会先调用check-prerequisites脚本check-prerequisites.sh 及其.ps1/.py变体并传入--require-spec --require-tasks --include-tasks即强制要求规格与任务文件存在再把当前任务状态交给收敛逻辑。implement模板类似只要求--require-tasks --include-tasks。可选把整个流程编排为工作流Spec Kit 在初始化时会安装内置的speckit工作流Full SDD Cycle见 workflow.yml。它以声明式 YAML 把specify → plan → tasks → implement串起来并在 specify 之后、plan 之后各插入一个gate步骤approve/reject拒绝即中止对应短路径流程的人工评审点。工作流要求speckit_version 0.8.5integration输入默认auto使用项目初始化时的集成scope可取full/backend-only/frontend-only。关键原则显式表达你要构建什么、为什么在规格阶段不要聚焦技术栈技术栈属于/speckit.plan在实现之前迭代打磨规格在开始编码前验证需求与计划让编码 Agent 处理实现细节深入阅读Agentic SDD 参考每个/speckit.*命令的完整参考——参数、产物、分阶段实现方式以及它们如何交互完整方法论对 Spec-Driven Development 的深入指导对比 核心模板 与 社区实战走查看规格驱动开发在真实项目中的用法安装细节uv 安装、pipx 安装、PyPI 安装、一次性 uvx 运行【免费下载链接】spec-kit Toolkit to help you get started with Spec-Driven Development项目地址: https://gitcode.com/GitHub_Trending/sp/spec-kit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考