github--spec-kit/README.md

Note

本文档由 WeHub 基于上游 README 翻译整理，属于社区翻译，非官方中文文档。
English · 原始项目 · 上游 README
原作者、版权与许可证归属以原始项目及本仓库 LICENSE 文件为准。

🌱 Spec Kit

更快地构建高质量软件。

一套开源工具包，让你专注于产品场景和可预测的成果，而无需从零开始逐段凭感觉编码。

---

目录

• 🤔 什么是规范驱动开发？
• ⚡ 快速开始
• 📽️ 视频概览
• 🌍 社区
• 🤖 支持的 AI 编程代理集成
• 🔧 Specify CLI 参考
• 🧩 定制 Spec Kit：扩展与预设
• 📦 捆绑包：基于角色的配置
• 📚 核心理念
• 🌟 开发阶段
• 🎯 实验性目标
• 🔧 前置条件
• 📖 了解更多
• 📋 详细流程
• 💬 支持
• 🙏 致谢
• 📄 许可证

🤔 什么是规范驱动开发？

规范驱动开发颠覆了传统软件开发的方式。几十年来，代码一直是王者——规范只不过是我们搭建好然后在"真正的编码工作"开始后就丢弃的脚手架。规范驱动开发改变了这一点：规范变得可执行，它直接生成可工作的实现，而不仅仅是指导实现。

⚡ 快速开始

1. 安装 Specify CLI

需要 uv（安装 uv）。将 vX.Y.Z 替换为 发布页面: 中的最新标签。

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z

查看安装指南了解其他安装方法、验证、升级和故障排查。

2. 初始化项目

specify init my-project --integration copilot
cd my-project

如需检查更新或升级已安装的 CLI，请使用自管理命令。查看升级指南了解详细场景和自定义选项。

# Check whether a newer release is available (read-only — does not modify anything)
specify self check

# Preview what would run, without actually upgrading
specify self upgrade --dry-run

# Upgrade in place to the latest stable release (auto-detects uv tool vs pipx install)
specify self upgrade

# Or pin a specific release tag (replace vX.Y.Z[suffix] with your desired release tag)
specify self upgrade --tag vX.Y.Z[suffix]

裸机 specify self upgrade 会立即执行，与 pip install -U 和 npm update 等命令的无提示行为一致。对于 uv tool 安装，它在底层运行 uv tool install specify-cli --force --from <git ref>，因此固定发布标签可以正常工作，包括 dev、alpha/beta/rc 或构建元数据后缀。uvx（临时）运行时，源检出会被检测到并生成针对路径的指引，而不是运行安装程序。设置 SPECIFY_UPGRADE_TIMEOUT_SECS 来限制安装器子进程的运行时长（默认：无超时——如需可随时用 Ctrl+C 中断）。

3. 确立项目原则

在项目目录中启动你的编程代理。大多数代理将 spec-kit 暴露为 /speckit.* 斜杠命令；Codex CLI 在技能模式下改用 $speckit-*；GitHub Copilot CLI 使用 /agents 来选择代理或直接在提示中引用。

使用 /speckit.constitution 命令创建项目的治理原则和开发指南，这些将指导后续的所有开发工作。

/speckit.constitution Create principles focused on code quality, testing standards, user experience consistency, and performance requirements

4. 创建规范

使用 /speckit.specify 命令描述你想要构建的内容。聚焦于做什么和为什么做，而不是技术栈。

/speckit.specify Build an application that can help me organize my photos in separate photo albums. Albums are grouped by date and can be re-organized by dragging and dropping on the main page. Albums are never in other nested albums. Within each album, photos are previewed in a tile-like interface.

5. 创建技术实现方案

使用 /speckit.plan 命令提供你的技术栈和架构选择。

/speckit.plan The application uses Vite with minimal number of libraries. Use vanilla HTML, CSS, and JavaScript as much as possible. Images are not uploaded anywhere and metadata is stored in a local SQLite database.

6. 拆解为任务

使用 /speckit.tasks 根据你的实现方案创建可执行的任务列表。

/speckit.tasks

7. 执行实现

使用 /speckit.implement 执行所有任务，按照计划构建你的功能。

/speckit.implement

有关详细的分步说明，请参见我们的综合指南。

📽️ 视频概览

想看看 Spec Kit 的实际效果？观看我们的视频概览!。

🌍 社区

在 Spec Kit 文档站点: 浏览社区贡献的资源。

• 扩展 — 命令、钩子和能力
• 预设 — 模板和术语覆盖
• 捆绑包 — 由现有组件组合而成的角色和团队技术栈
• 演练 — 端到端的 SDD 场景
• 生态伙伴 — 扩展或构建于 Spec Kit 之上的项目

Note

社区贡献由各自作者独立创建和维护。安装前请审查源代码，并自行决定使用风险。

想要贡献？请参阅扩展发布指南、预设发布指南或社区捆绑包指南。

🤖 支持的 AI 编程代理集成

Spec Kit 可与 30 多种 AI 编程代理配合使用——包括 CLI 工具和基于 IDE 的助手。在支持的 AI 编程代理集成 指南中查看完整列表及说明和用法详情。

运行 specify integration list 查看已安装版本中所有可用的集成。

可用斜杠命令

运行 specify init 后，你的 AI 编程代理将可以使用以下斜杠命令进行结构化开发。对于支持技能模式的集成，传递 --integration <agent> --integration-options="--skills" 将安装代理技能而非斜杠命令提示文件。

核心命令

规范驱动开发工作流程中的基本命令： USD 预算：$0/$3；剩余 $3；约 4 天后重置。

命令	Agent 技能	描述
/speckit.constitution	speckit-constitution	创建或更新项目治理原则和开发指南
/speckit.specify	speckit-specify	定义你想要构建的内容（需求与用户故事）
/speckit.plan	speckit-plan	基于所选技术栈创建技术实施方案
/speckit.tasks	speckit-tasks	为实现生成可执行的任务列表
/speckit.taskstoissues	speckit-taskstoissues	将生成的任务列表转换为 GitHub Issues，便于跟踪和执行
/speckit.implement	speckit-implement	执行所有任务，按计划构建功能
/speckit.converge	speckit-converge	对照规格/计划/任务评估代码库，并将剩余工作追加为新任务

可选命令

用于增强质量和验证的额外命令：

命令	Agent 技能	描述
/speckit.clarify	speckit-clarify	澄清规格中不够明确的区域（建议在 /speckit.plan 之前运行；原名为 /quizme）
/speckit.analyze	speckit-analyze	跨产物一致性与覆盖率分析（在 /speckit.tasks 之后、/speckit.implement 之前运行）
/speckit.checklist	speckit-checklist	生成自定义质量检查清单，用于验证需求的完整性、清晰度和一致性（类似"英语的单元测试"）

🔧 Spec Kit CLI 参考

完整的命令详情、选项和示例，请参阅 CLI 参考.

🧩 定制你的 Spec Kit：扩展与预设

Spec Kit 可通过两个互补系统——扩展（extensions） 和预设（presets）——以及项目本地覆盖来进行调整，以满足你的需求：

优先级	组件类型	位置
⬆ 1	项目本地覆盖	.specify/templates/overrides/
2	预设 — 自定义核心和扩展	.specify/presets/templates/
3	扩展 — 添加新能力	.specify/extensions/templates/
⬇ 4	Spec Kit 核心 — 内置 SDD 命令和模板	.specify/templates/

• 模板在运行时解析——Spec Kit 自上而下遍历栈，使用第一个匹配项。
• 项目本地覆盖（.specify/templates/overrides/）让你无需创建完整预设即可为单个项目进行一次性调整。
• 扩展/预设命令在安装时应用——当你运行 specify extension add 或 specify preset add 时，命令文件会被写入 Agent 目录（例如 .claude/commands/）。
• 如果多个预设或扩展提供了相同的命令，优先级最高的版本将胜出。移除时，次高优先级的版本会自动恢复。
• 如果没有覆盖或自定义，Spec Kit 将使用其核心默认值。

扩展 — 添加新能力

当你需要的功能超出 Spec Kit 核心范围时，使用扩展。扩展引入了新的命令和模板——例如，添加内置 SDD 命令未覆盖的领域特定工作流、与外部工具集成，或添加全新的开发阶段。它们扩展了 Spec Kit 能做什么。

# Search available extensions
specify extension search

# Install an extension
specify extension add <extension-name>

例如，扩展可以添加 Jira 集成、实现后代码审查、V-Model 测试可追溯性或项目健康诊断。

完整的命令指南请参阅扩展参考。浏览社区扩展了解现有可用内容。

预设 — 自定义现有工作流

当你想要改变 Spec Kit 的工作方式而不添加新能力时，使用预设。预设会覆盖核心以及已安装扩展中的模板和命令——例如，强制采用面向合规的规格格式、使用领域特定术语，或将组织标准应用于计划和任务。它们自定义的是 Spec Kit 及其扩展产出的产物和指令。

# Search available presets
specify preset search

# Install a preset
specify preset add <preset-name>

例如，预设可以重构规格模板以要求法规可追溯性，调整工作流以适应你使用的方法论（如敏捷、看板、瀑布、Jobs-to-Be-Done 或领域驱动设计），在计划中添加强制安全审查关卡，强制执行测试优先的任务排序，或将整个工作流本地化为另一种语言。海盗话演示展示了自定义的深度。多个预设可按优先级顺序叠加。

完整的命令指南（包括解析顺序和优先级叠加）请参阅预设参考。

📦 捆绑包：基于角色的设置

扩展和预设是独立的构建块。捆绑包（bundle） 将一组精心策划的扩展、预设、步骤和工作流打包为一个单一的、带版本的、面向角色的设置，这样整个团队角色（产品经理、业务分析师、安全研究员、开发者等）只需一条命令即可完成配置。

捆绑包通过手写的 bundle.yml 清单文件来描述。它将每个组件锁定到特定版本，并可选择性地指定目标集成方式；不包含 integration 的捆绑包是**无关（agnostic）**的，将继承项目已使用的任何集成。

# Discover bundles in the active catalog stack
specify bundle search [<query>]

# Inspect the exact component set a bundle will add (equals what install does)
specify bundle info <bundle-id>

# Install a bundle's full component set in one operation
specify bundle install <bundle-id>

# See what's installed, then update or remove non-destructively
specify bundle list
specify bundle update <bundle-id>     # or --all
specify bundle remove <bundle-id>     # removes only this bundle's components

捆绑包从按优先级排序的目录栈（项目 > 用户 > 内置）中解析。每个源都带有一个安装策略：install-allowed 源可从中安装，而 discovery-only 源在 search/info 中可见，但拒绝安装。使用 specify bundle catalog list|add|remove 管理栈。

作者在本地验证和打包捆绑包。分发方式是托管构建产物并添加目录源；社区捆绑包提交使用捆绑包提交 Issue 模板，以便审查所需的组件目录和安装证据：

specify bundle validate --path ./my-bundle      # structural + reference checks
specify bundle build --path ./my-bundle         # produce a versioned .zip artifact

四个可直接阅读的示例清单位于 examples/bundles/ 目录下（分别面向产品经理、业务分析师、 安全研究员和开发者）。

关键保证：info 可精确显示 install 新增了哪些内容（透明性）； 安装是幂等的且限定在项目根目录；remove 绝不会触碰其他已安装包仍需要的 组件；所有使用/编写命令均可离线工作，基于本地或固定的源。

何时使用哪种

目标	使用
添加全新的命令或工作流	扩展包
自定义规格、计划或任务的格式	预设
集成外部工具或服务	扩展包
执行组织或监管标准	预设
交付可复用的领域特定模板	两者皆可——模板覆写用预设，与全新命令绑定的模板用扩展包
一条命令完成完整的基于角色的环境配置	包

📚 核心理念

规格驱动开发是一种结构化流程，强调：

• 意图驱动的开发：规格先定义"做什么"，再考虑"怎么做"
• 丰富的规格创建：利用护栏和组织原则进行规格编写
• 多步精炼：而非从提示词一次性生成代码
• 高度依赖先进 AI 模型的能力来解释规格

🌟 开发阶段

阶段	聚焦点	关键活动
从零到一开发（"绿场开发"）	从零生成	从高层需求开始 生成规格 规划实现步骤 构建生产级应用
创造性探索	并行实现	探索多种解决方案 支持多种技术栈与架构 实验用户体验模式
迭代增强（"棕场开发"）	棕场现代化	迭代式添加功能 现代化遗留系统 适配流程

对于现有项目，请将 Spec Kit 工具更新与特性工件的演进分离：升级时刷新受管理的项目文件，并在预期行为发生变化时更新 specs/ 工件。演进中的规格指南描述了 推荐的棕场循环。

🎯 实验目标

我们的研究和实验聚焦于：

技术无关性

• 使用多种技术栈创建应用
• 验证"规格驱动开发是一种不受特定技术、编程语言或框架约束的流程"这一假设

企业约束

• 演示关键任务应用的开发
• 融入组织约束（云提供商、技术栈、工程实践）
• 支持企业设计系统与合规要求

以用户为中心的开发

• 为不同的用户群体和偏好构建应用
• 支持多种开发方式（从氛围编码到 AI 原生开发）

创造性与迭代流程

• 验证并行实现探索的概念
• 提供健壮的迭代式特性开发工作流
• 扩展流程以处理升级和现代化任务

🔧 前置条件

• Linux/macOS/Windows
• 支持的 AI 编码代理。
• uv) 用于包管理（推荐）或 pipx) 用于持久安装
• Python 3.11+)
• Git)

如果遇到代理相关的问题，请提交 issue 以便我们改进集成。

📖 了解更多

• 完整的规格驱动开发方法论——深入理解完整流程
• 详细操作指南——分步实现指南

---

📋 详细流程

点击展开详细的分步操作指南

您可以使用 Specify CLI 来引导您的项目，它会将所需的工件带入您的环境中。运行：

specify init <project_name>

或在当前目录中初始化：

specify init .
# or use the --here flag
specify init --here
# Skip confirmation when the directory already has files
specify init . --force
# or
specify init --here --force

在交互式终端中，系统会提示您选择所使用的编码代理集成。在非交互式会话（如 CI 或管道运行）中，除非您传递 --integration，否则 specify init 默认为 GitHub Copilot。您也可以直接在终端中主动指定集成：

specify init <project_name> --integration copilot
specify init <project_name> --integration gemini
specify init <project_name> --integration codex

# Or in current directory:
specify init . --integration copilot
specify init . --integration codex --integration-options="--skills"

# or use --here flag
specify init --here --integration copilot
specify init --here --integration codex --integration-options="--skills"

# Force merge into a non-empty current directory
specify init . --force --integration copilot

# or
specify init --here --force --integration copilot

当所选集成具有 requires_cli: True 时，CLI 会检查该集成所需的 CLI 工具是否已安装在您的机器上。如果您没有安装所需的工具，或者希望在无需检查工具的情况下获取模板，请在命令中使用 --ignore-agent-tools：

specify init <project_name> --integration copilot --ignore-agent-tools

第 1 步： 确立项目原则

进入项目文件夹并运行您的编码代理。在我们的示例中，我们使用的是 claude。

如果您看到 /speckit.constitution、/speckit.specify、/speckit.plan、/speckit.tasks 和 /speckit.implement 命令可用，则说明配置正确。

第一步应使用 /speckit.constitution 命令来确立项目的治理原则。这有助于确保在后续所有开发阶段中保持一致决策：

/speckit.constitution Create principles focused on code quality, testing standards, user experience consistency, and performance requirements. Include governance for how these principles should guide technical decisions and implementation choices.

此步骤会创建或更新 .specify/memory/constitution.md 文件，其中包含项目的基础指导原则，编码代理将在规格、计划和实现阶段引用该文件。

第 2 步： 创建项目规格

项目原则确立后，您可以创建功能规格。使用 /speckit.specify 命令，然后提供您想要开发的项目的具体需求。

Important

请尽可能明确地描述您要构建的内容及原因。此时不要关注技术栈。

示例提示词：

Develop Taskify, a team productivity platform. It should allow users to create projects, add team members,
assign tasks, comment and move tasks between boards in Kanban style. In this initial phase for this feature,
let's call it "Create Taskify," let's have multiple users but the users will be declared ahead of time, predefined.
I want five users in two different categories, one product manager and four engineers. Let's create three
different sample projects. Let's have the standard Kanban columns for the status of each task, such as "To Do,"
"In Progress," "In Review," and "Done." There will be no login for this application as this is just the very
first testing thing to ensure that our basic features are set up. For each task in the UI for a task card,
you should be able to change the current status of the task between the different columns in the Kanban work board.
You should be able to leave an unlimited number of comments for a particular card. You should be able to, from that task
card, assign one of the valid users. When you first launch Taskify, it's going to give you a list of the five users to pick
from. There will be no password required. When you click on a user, you go into the main view, which displays the list of
projects. When you click on a project, you open the Kanban board for that project. You're going to see the columns.
You'll be able to drag and drop cards back and forth between different columns. You will see any cards that are
assigned to you, the currently logged in user, in a different color from all the other ones, so you can quickly
see yours. You can edit any comments that you make, but you can't edit comments that other people made. You can
delete any comments that you made, but you can't delete comments anybody else made.

在此提示输入后，你会看到 Claude Code 开始规划并起草规范文档。Claude Code 也会触发一些内置脚本，用于初始化仓库。

这一步完成后，你会看到一个新的分支被创建（例如 001-create-taskify），以及在 specs/001-create-taskify 目录下的新规范文件。

生成的规范应包含一组用户故事和功能需求，按照模板定义来组织。

在此阶段，你的项目文件夹结构应大致如下：

```text
.
├── .specify
│   ├── memory
│   │   └── constitution.md
│   ├── scripts
│   │   └── bash
│   │       ├── check-prerequisites.sh
│   │       ├── common.sh
│   │       ├── create-new-feature.sh
│   │       ├── setup-plan.sh
│   │       └── setup-tasks.sh
│   └── templates
│       ├── plan-template.md
│       ├── spec-template.md
│       └── tasks-template.md
└── specs
    └── 001-create-taskify
        └── spec.md

### **步骤 3：** 功能规范澄清（规划前必做）

在基线规范创建完成后，你可以进一步澄清初次起草中未能妥善捕获的需求。

建议在制定技术方案之前，先运行结构化澄清工作流，以减少后续返工。

推荐顺序：

1. 使用 ``/speckit.clarify``（结构化）—— 基于覆盖率的顺序提问，答案记录在"澄清说明"章节中。
2. 如果仍有模糊之处，可选择性进行自由形式细化。

如果你有意跳过澄清步骤（例如是技术调研或探索性原型），请明确说明，以便 agent 不会因缺失澄清而阻塞。

自由形式细化示例提示（如仍需，可在 ``/speckit.clarify`` 之后使用）：

For each sample project or project that you create there should be a variable number of tasks between 5 and 15
tasks for each one randomly distributed into different states of completion. Make sure that there's at least
one task in each stage of completion.

你还应请 Claude Code 验证**评审与验收清单**，标记已通过/符合需求的项，保留未通过项为未勾选状态。可使用以下提示：

Read the review and acceptance checklist, and check off each item in the checklist if the feature spec meets the criteria. Leave it empty if it does not.

务必将与 Claude Code 的交互作为澄清和提问规范的机会——**不要将其第一次输出视为最终版本**。

### **步骤 4：** 生成方案

现在你可以指定技术栈和其他技术要求。可以使用项目模板内置的 ``/speckit.plan`` 命令，配合如下提示：

We are going to generate this using .NET Aspire, using Postgres as the database. The frontend should use
Blazor server with drag-and-drop task boards, real-time updates. There should be a REST API created with a projects API,
tasks API, and a notifications API.

此步骤的输出将包含一系列实现细节文档，目录结构大致如下：

.
├── CLAUDE.md
├── .specify
│   ├── memory
│   │   └── constitution.md
│   ├── scripts
│   │   └── bash
│   │       ├── check-prerequisites.sh
│   │       ├── common.sh
│   │       ├── create-new-feature.sh
│   │       ├── setup-plan.sh
│   │       └── setup-tasks.sh
│   └── templates
│       ├── CLAUDE-template.md
│       ├── plan-template.md
│       ├── spec-template.md
│       └── tasks-template.md
└── specs
    └── 001-create-taskify
        ├── contracts
        │   ├── api-spec.json
        │   └── signalr-spec.md
        ├── data-model.md
        ├── plan.md
        ├── quickstart.md
        ├── research.md
        └── spec.md

检查 ``research.md`` 文档，确保根据你的指示使用了正确的技术栈。如果某些组件有问题，你可以要求 Claude Code 进行调整，甚至让它检查你本地安装的平台/框架版本（如 .NET）。

此外，如果你选择的技术栈变化较快（如 .NET Aspire、JS 框架），你可以考虑让 Claude Code 调研相关细节，使用如下提示：

I want you to go through the implementation plan and implementation details, looking for areas that could
benefit from additional research as .NET Aspire is a rapidly changing library. For those areas that you identify that
require further research, I want you to update the research document with additional details about the specific
versions that we are going to be using in this Taskify application and spawn parallel research tasks to clarify
any details using research from the web.

在此过程中，如果发现 Claude Code 在调研方向上偏离了目标，你可以使用如下提示纠正：

I think we need to break this down into a series of steps. First, identify a list of tasks
that you would need to do during implementation that you're not sure of or would benefit
from further research. Write down a list of those tasks. And then for each one of these tasks,
I want you to spin up a separate research task so that the net results is we are researching
all of those very specific tasks in parallel. What I saw you doing was it looks like you were
researching .NET Aspire in general and I don't think that's gonna do much for us in this case.
That's way too untargeted research. The research needs to help you solve a specific targeted question.

> [!NOTE]
> Claude Code 可能过于积极，添加了你未要求的组件。请要求它说明变更理由和来源。

### **步骤 5：** 让 Claude Code 验证方案

方案确定后，应让 Claude Code 逐项检查，确保没有遗漏。可使用如下提示：

Now I want you to go and audit the implementation plan and the implementation detail files.
Read through it with an eye on determining whether or not there is a sequence of tasks that you need
to be doing that are obvious from reading this. Because I don't know if there's enough here. For example,
when I look at the core implementation, it would be useful to reference the appropriate places in the implementation
details where it can find the information as it walks through each step in the core implementation or in the refinement.

这有助于细化实现方案，避免 Claude Code 在规划周期中遗漏的潜在盲区。完成初步细化后，请 Claude Code 再次逐项检查清单，然后进入实现阶段。

如果你已安装 [GitHub CLI](https://docs.github.com/en/github-cli/github-cli))，还可以让 Claude Code 从当前分支创建一个指向 ``main`` 的 Pull Request，并附带详细描述，确保工作进度被妥善追踪。

> [!NOTE]
> 在让 agent 开始实现之前，也值得请 Claude Code 交叉检查细节，看是否存在过度设计的部分（记住——它可能过于积极）。如果存在过度设计的组件或决策，可请 Claude Code 进行优化。确保 Claude Code 在制定方案时，遵循 ``.specify/memory/constitution.md`` 中的原则作为基本准则。

### **步骤 6：** 使用 /speckit.tasks 生成任务分解

在实现方案验证通过后，你可以将方案拆解为具体、可操作的任务，并按正确顺序执行。使用 ``/speckit.tasks`` 命令，从实现方案自动生成详细的任务分解。

```text
/speckit.tasks

此步骤会在特性规范目录中创建一个 tasks.md 文件，其中包含：

• 按用户故事划分的任务分解 — 每个用户故事成为一个独立的实现阶段，附带各自的任务集合
• 依赖管理 — 任务按依赖关系排序，确保组件之间的依赖得到尊重（如模型先于服务，服务先于端点）
• 并行执行标记 — 可并行运行的任务使用 [P] 标记，以优化开发工作流
• 文件路径规范 — 每个任务包含实现所需的确切文件路径
• 测试驱动开发结构 — 如果请求了测试，测试任务会被包含并按顺序安排在实现之前编写
• 检查点验证 — 每个用户故事阶段包含检查点，用于验证独立功能是否正常

生成的 tasks.md 为 /speckit.implement 命令提供了清晰的路线图，确保系统化实现，维护代码质量，并支持用户故事的增量交付。

步骤 7： 实现

准备就绪后，使用 /speckit.implement 命令执行实现计划：

/speckit.implement

/speckit.implement 命令将：

• 验证所有前置条件是否已就绪（规范、规格文档、计划及任务）
• 解析 tasks.md 中的任务分解
• 按正确顺序执行任务，尊重依赖关系和并行执行标记
• 遵循任务计划中定义的 TDD 方法
• 提供进度更新并妥善处理错误

Important

编码代理将执行本地 CLI 命令（如 dotnet、npm 等）— 请确保你的机器上已安装所需工具。

实现完成后，测试应用程序并解决 CLI 日志中可能不可见的运行时错误（如浏览器控制台错误）。你可以将这些错误复制粘贴回编码代理进行解决。

---

💬 支持

如需支持，请开启一个 GitHub Issue.)。欢迎提交 Bug 报告、功能请求以及关于使用规范驱动开发的问题。

🙏 致谢

本项目深受 John Lam.) 的工作和研究成果影响，并以其为基础。

📄 许可证

本项目采用 MIT 开源许可证条款。完整条款请参阅 LICENSE 文件。 USD 预算：$0/$3；剩余 $3。

---

English | 简体中文 | 日本語 | Español | Français | Deutsch | Português | Italiano | Русский | 한국어 | العربية | हिन्दी