企业官网建设流程全解析

前言：

在规范驱动编程：当 AI 编程从“单兵作战”走向“团队协作”我们了解了规范驱动编程的核心理念。但在实际落地时，面对市面上众多的工具，我们该如何选择？是选择 GitHub 官方的“正规军” Spec Kit，还是社区推崇的轻量级 OpenSpec，亦或是 AWS 的云端方案？

本节将为你详细介绍这 3 个主流的规范驱动编程工具，并提供一份详尽的选型建议，帮助你找到最适合团队的那把“利器”。

1. 工具选型概述：如何挑选合适的武器？

在选择规范驱动编程工具之前，我们需要明确几个核心评估维度：

1. 成熟度与社区支持：工具是否经过大量项目验证？社区是否活跃？遇到问题时能否获得足够的支持？
2. 与现有工作流的兼容性：工具是否与当前使用的 AI 编程编辑器（如 TRAE）良好集成？是否需要显著改变现有的开发流程？
3. 学习曲线与采用成本：团队需要投入多少时间来学习工具的使用方法和规范写作方法，才能达到有效的使用状态？
4. 灵活性与约束力：工具是提供一个轻量级的框架让我们自行填充，还是提供严格的流程让我们必须遵循？

表 1：规范驱动编程工具对比

特别说明：Amazon Bedrock Agent 与前两个工具有本质区别。它不是一个独立的规范文档管理工具，而是一个将规范嵌入 AWS 云服务架构的企业级 AI 编排框架。不为其设立独立小节。

2. Spec Kit：企业级严格规范管理的“重型武器”

Spec Kit 是 GitHub 推出的规范驱动开发框架，定位为企业级严格规范管理。它的核心特点是将规范过程分解为5 个递进阶段，每个阶段有明确的产出物和门控检查。

2.1 5 层规范链路

Spec Kit 的设计体现了从顶层工程宪章到底层代码实现的严格分层架构思维。即使目前无需使用如此重量级的框架，理解其分层思想也有助于读者更好地组织规范文档。

图 1：Spec Kit 的 5 层规范链路

2.2 核心层级详解

（1）工程宪章 (Constitution)

这是整个框架的顶层约束，定义团队在使用 AI 编程工具时必须遵守的硬性规则。示例如下：

# Constitution (工程宪章) ## AI 使用原则 ### 必须 - 所有 AI 生成代码必须经过代码审查才能合并。 - 安全相关功能（认证、支付、数据加密）必须由人类工程师实现核心逻辑。 - 规范文档必须与代码同步更新。 ### 禁止 - 禁止使用 AI 生成涉及用户隐私数据的处理逻辑。 - 禁止使用 AI 修改数据库迁移文件。 - 禁止在未创建规范文档的情况下直接让 AI 修改核心业务逻辑。 ## 代码质量标准 ### AI 生成代码的最低要求 - 所有函数必须包含中文 docstring。 - 所有公共 API 必须有单元测试覆盖。 - 代码必须通过团队统一的 lint 检查。 ## 规范优先级 - Constitution > Specification > Plan > Tasks。 - 下层规范不得与上层规范冲突。

（2）系统级规范 (Specification)

系统级规范定义系统的功能需求和数据模型。与工程宪章不同，系统级规范关注的是“系统做什么”，而非“团队如何工作”。示例如下：

# Specification (系统级规范) ## 功能范围 ### 核心功能 - 用户注册与登录（邮箱 + 密码） - 用户资料管理 - 订单创建与查询 ### 排除功能（本章不涉及） - 支付网关集成 - 物流跟踪 - 促销和优惠券 ## 数据模型 核心数据模型包括用户和订单两个实体，字段定义如下。 **User 实体字段定义** | 字段 | 类型 | 约束 | 说明 | |------|------|------|------| | id | UUID | 主键 | 用户唯一标识 | | email | VARCHAR(255) | 唯一，非空 | 邮箱地址 | | hashed_password | VARCHAR(255) | 非空 | bcrypt 哈希密码 | | created_at | TIMESTAMP | 非空，默认 NOW | 注册时间 | **Order 实体字段定义** | 字段 | 类型 | 约束 | 说明 | |------|------|------|------| | id | UUID | 主键 | 订单唯一标识 | | user_id | UUID | 外键，非空 | 下单用户 | | total_amount | DECIMAL(10,2) | 非空 | 订单总金额 | | status | ENUM | 默认 PENDING | 订单状态 | | created_at | TIMESTAMP | 非空，默认 NOW | 创建时间 |

2.3 适用场景与局限性

• 适用场景：大型团队协作；金融、医疗等对合规性要求高的行业；需要严格架构约束的复杂系统；已有成熟工程实践的团队。
• 局限性：学习曲线较陡，团队需要投入较多时间学习 5 层规范链路；规范文档数量多，维护成本较高；对于快速迭代的中小型项目，可能显得过于笨重。

3. OpenSpec：轻量级敏捷开发的“瑞士军刀”

OpenSpec 是 Fission-AI 推出的轻量级规范驱动框架，定位为快速迭代的灵活规范管理。相比 Spec Kit 的严格多阶段流程，OpenSpec 更强调简洁和快速上手。它是本书推荐的首选入门工具。

3.1 4 步工作流

OpenSpec 的核心是简洁直观的 4 步工作流，如图 2 所示。

图 2：OpenSpec 的 4 步工作流

1. 探索 (Explore)：全面调研梳理代码库整体现状，拆解项目现有技术能力、功能架构与业务逻辑，排查各类开发约束、潜在问题与技术边界，为后续开发工作筑牢前置基础。
2. 提案 (Propose)：当有新功能需求时，在openspec/changes/目录下创建新的规范文档草案。这个阶段是快速且非正式的——用简洁的语言描述要做什么，不需要追求完美。
3. 实施 (Implement)：确认规范后，AI 基于规范生成代码。每次代码变更时都要与规范进行对比验证，确保一致性。这个阶段强调“规范即真理”——代码必须符合规范，任何偏差都需要被记录和修正。
4. 归档 (Archive)：在功能完成并通过验收后，将规范文档和相关知识归档到openspec/archive/目录。归档不是丢弃，而是将知识整理成可检索的形式，供日后参考。

3.2 项目结构与配置

OpenSpec 的项目结构非常简洁，如下所示：

your-project/ ├── openspec/ │ ├── changes/ # 活跃变更目录（正在进行的工作） │ │ ├── user-auth/ # 用户认证功能规范 │ │ │ └── spec.md # 规范文档 │ │ └── todo-list/ # 待办列表功能规范 │ │ ├── spec.md # 规范文档 │ │ ├── plan.md # 技术方案（可选） │ │ └── tasks.md # 任务清单（可选） │ ├── archive/ # 归档知识库（已完成的工作） │ │ └── v1.0-features/ │ │ └── spec.md # 历史规范 │ └── config.yaml # 项目配置（可选） └── AGENTS.md # AI 上下文配置

config.yaml是项目配置文件，其context字段的内容会被自动注入每一次 AI 规划请求中，确保 AI 始终了解项目的技术背景。下面是一个典型的配置示例：

schema: spec-driven context: | Tech stack: Python 3.12, FastAPI, SQLite, SQLAlchemy Testing: pytest Architecture: Three-layer (routers -> services -> repositories) We use conventional commits rules: proposal: - Always include "## Why" and "## What Changes" sections specs: - Use Given/When/Then format for scenarios tasks: - Break tasks into max 2-hour chunks

3.3 规范文档格式

OpenSpec 对规范文档格式有严格要求，了解这些格式是正确编写规范的前提。每个变更目录下的proposal.md必须包含## Why和## What Changes两个段落，否则openspec validate会报错。

能力规范文件specs/[capability]/spec.md必须使用“变更类型+Requirement+Scenario”格式，示例如下：

## ADDED Requirements ### Requirement: 随机数生成 系统 SHALL 在每局游戏开始时生成 1~100 范围内的随机整数。 **Priority**: P0 (Critical) **Rationale**: 随机数是猜数字游戏的核心。 #### Scenario: 游戏开始时生成目标数字 Given 玩家点击“开始游戏” When 系统初始化新一局游戏 Then 系统生成一个 1~100 范围内的随机整数作为目标数字 And 玩家不可见该数字

这里用到了Gherkin格式。Gherkin 是一种结构化自然语言格式，用于编写可被 AI 解析、可直接转化为测试用例的场景描述，核心是通过“Given（给定）、When（当）、Then（那么）”三段式清晰定义前置条件、触发动作和预期结果。

表 2：格式要点

3.4 适用场景与局限性

• 适用场景：存量项目引入规范驱动编程（学习成本低，可渐进式采用）；初创公司或小团队（灵活、快速，不需要严格的阶段门控）；个人开发者建立规范写作习惯；快速迭代的敏捷项目。
• 局限性：规范的质量很大程度上取决于团队成员对“好规范”的理解；没有强制性的阶段检查，可能出现“规范写了但没认真执行”的情况；对于需要严格合规管理的行业，可能不够正式。

4. 实战演练：在 TRAE 中安装与配置 OpenSpec

TRAE 是字节跳动推出的 AI 代码编辑器，原生支持中文界面，与 OpenSpec 的集成非常顺畅。本小节将介绍在 TRAE 中安装与配置 OpenSpec 的完整过程。

4.1 前置要求

使用 OpenSpec 之前，需要确认本地已安装 Node.js 20.19.0 或更高版本。读者可以在终端中执行以下命令检查版本：

node --version

如果没有安装，可以从 Node.js 官网下载并进行安装。若安装好后无法在 Git Bash 中使用，则一般是环境变量问题，解决方法是在~/.bashrc文件中添加命令路径，如下所示：

export PATH="$PATH:/c/Program Files/nodejs/"

添加完后，需要重新启动 Git Bash 以生效。

4.2 安装 OpenSpec

OpenSpec 以 npm 全局包的形式发布，执行以下命令即可完成安装：

npm install -g @fission-ai/openspec@latest

安装完成后，执行以下命令验证安装是否成功：

openspec --version

若终端输出版本号（如 1.3.1），则安装成功。如果安装完 OpenSpec 后无法使用，大概率是环境变量问题，可以在~/.bashrc文件中添加如下命令路径（需要将路径替换为读者的真实路径），再重新启动 Git Bash：

export PATH="$PATH:/c/Users/linziyu/AppData/Roaming/npm"

4.3 初始化项目

进入项目根目录，执行以下初始化命令：

openspec init

openspec init会以默认的交互模式运行，会询问需要集成哪些 AI 工具

使用空格键选择工具，按回车键确认。若需要在脚本或 CI 环境中以非交互模式运行，可使用--tools参数，如下所示：

# 仅为 TRAE 配置 openspec init --tools trae

选择 TRAE 后，系统会生成图 4 所示的目录结构。

图 4：OpenSpec 项目目录结构

4.4 理解核心目录结构

初始化完成后，openspec/目录成为项目规范的统一管理中心。表 3 给出了各文件和目录的用途及说明。

表 3：OpenSpec 各文件和目录的用途及说明

4.5 常用命令

表 4 给出了 OpenSpec 的常用命令说明。一般情况下，我们不需要直接使用这些命令，TRAE 会自动调用这些命令完成工作。但是，了解这些命令有助于故障诊断和理解 OpenSpec 的原理。

表 4：OpenSpec 常用命令说明

在 TRAE 中，推荐使用斜杠命令驱动工作流，这比直接调用 CLI 更加便捷，如图 5 所示。

图 5：TRAE 中的 OpenSpec 斜杠命令

5. 工具选型建议

基于前面的分析，表 5 给出了针对不同情况的规范驱动编程工具选型建议。

表 5：规范驱动编程工具选型建议