企业官网建设流程全解析

OpenSpec是 2025~2026 年 AI 辅助编程领域最具影响力的**规范驱动开发（Spec-Driven Development, SDD）**框架之一。本文将从底层原理、定制封装实战到进阶生态方案，做一次系统性梳理。

一、OpenSpec 是什么

OpenSpec是由 Fission-AI 开源的、专为 AI 编程助手设计的轻量级规范驱动开发框架。它通过在代码编写之前建立一套结构化的规范层，让开发者和 AI 在"要构建什么"上达成共识，从而大幅减少模糊提示带来的不可预测结果。

1.1 四条设计哲学

OpenSpec 的全部设计都围绕这四条哲学展开：

1.2 与同类工具的定位差异

OpenSpec 在生态中的位置非常清晰：

二、核心原理：三层架构与 Artifact 工作流

2.1 第一层：规范注入系统（Spec Injection System）

OpenSpec 在 AI 助手启动时，自动把specs/和changes/的内容注入上下文，让助手始终基于最新规范工作。

不同工具的注入路径：

设计意图：关注点分离——开发者专注于"变更提案"，AI 专注于"按规范实现"。

2.2 第二层：CLI 引擎核心

OpenSpec CLI 引擎是整个框架的"大脑"，由以下核心模块组成：

2.2.1 ArtifactGraph（依赖图引擎）

每个变更提案（Change）包含多个Artifact（工件），如proposal.md、specs/、design.md、tasks.md。这些工件之间存在依赖关系，引擎通过拓扑排序（O(V+E)）确定生成顺序。

proposal ──→ specs ──→ design ──→ tasks ──→ implement ▲ ▲ ▲ │ └───────────┴──────────┴────────────────────┘ （可随时回改任何节点）

2.2.2 Mustache 模板引擎

所有 Artifact 的生成基于Mustache模板。引擎将规范数据注入模板，生成结构化的 Markdown 文件。

2.2.3 Delta Spec 合并器

这是 OpenSpec 适配存量代码库的核心。Delta Spec 描述"相对当前规范改了什么"，而非重写整份规格。

为什么用 Delta 而非全量？

• Clarity：直接显示改了什么
• 冲突规避：不同 change 改不同 requirement 可并行
• Review 效率：reviewer 只看变更
• Brownfield 契合：让"修改"成为一等公民

2.2.4 ToolCommand 适配器

跨工具兼容通过适配器模式实现：

interfaceToolCommandAdapter{getFilePath(id):stringformatFile(content):string}

新增 AI 工具支持只需添加新的适配器，无需改动核心引擎。

2.3 第三层：规范驱动工作流

OpenSpec 的命令体系分为两套 Profile：

Core Profile（默认）：

Expanded Profile（进阶）：

同一份 intent，多种落地形态：Claude Code 用/opsx:propose，Cursor 用/opsx-propose，Kimi 用/skill:openspec-propose。

三、完整工作流演示

3.1 典型开发周期

# 1. 初始化项目npminstall-g@fission-ai/openspec@latestcdyour-project openspec init# 2. 创建变更提案/opsx:propose"为 iOS 番茄专注 APP 新增自定义时长功能"# AI 自动生成：# openspec/changes/custom-timer/# ├── proposal.md # 变更原因、影响范围# ├── specs/ # 需求规范（Delta Spec）# ├── design.md # 技术方案（SwiftUI + Node.js）# └── tasks.md # 实现任务清单# 3. 按规范实现/opsx:apply# AI 逐项完成 tasks.md 中的任务# ✓ 1.1 修改 SwiftUI 界面，添加时长输入框# ✓ 1.2 实现 POST /api/timer/custom 接口# ✓ 1.3 验证时长范围 1-60 分钟# 4. 归档并更新主规范/opsx:archive# 移动到 openspec/changes/archive/2025-01-23-custom-timer/# Delta Spec 合并到 openspec/specs/

3.2 Token 效率优化

在大型项目中，直接投喂全部代码会瞬间耗尽 Token。OpenSpec 通过结构化文件实现按需加载：

四、如何封装自己的定制版

OpenSpec 提供了完整的扩展机制，让你可以根据团队或项目需求封装定制版。

4.1 自定义 Schema（工作流定义）

Schema 定义了 Artifact 的序列和依赖关系。你可以从零创建，或 Fork 内置 Schema。

# 方式一：从零创建openspec schema init api-first\--description"API-first design workflow"\--artifacts"api-spec,proposal,design,tasks"\--default

生成的目录结构：

openspec/schemas/api-first/ ├── schema.yaml # 工作流定义 └── templates/ ├── api-spec.md # 每个 artifact 的模板 ├── proposal.md ├── design.md └── tasks.md

schema.yaml 示例：

name:api-firstartifacts:-id:api-specgenerates:api-spec.mdrequires:[]# 无依赖，最先生成-id:proposalgenerates:proposal.mdrequires:[api-spec]# 依赖 api-spec-id:designgenerates:design.mdrequires:[proposal]-id:tasksgenerates:tasks.mdrequires:[design]

模板示例（templates/api-spec.md）：

#APISpecification:{{change.name}}##Endpoints{{#endpoints}}###{{method}}{{path}}-**Auth**:{{auth}}-**Request**:{{requestSchema}}-**Response**:{{responseSchema}}{{/endpoints}}##RateLimits{{#rateLimits}}-{{tier}}:{{limit}}req/min{{/rateLimits}}

4.2 方式二：Fork 内置 Schema

# Fork 内置的 spec-driven schemaopenspec schema fork spec-driven my-workflow# 或从社区 Schema 仓库获取# 复制到 openspec/schemas/ 目录即可

Schema 解析优先级：

1. Project-level：openspec/schemas/<name>/schema.yaml（本地，版本控制）
2. User-level：~/.local/share/openspec/schemas/<name>/（全局共享）
3. Built-in：OpenSpec 包内置（如spec-driven）

4.3 项目配置（config.yaml）

# openspec/config.yamlschema:api-first# 默认使用的 schemacontext:|Project: My SaaS Platform Tech Stack: React + Node.js + PostgreSQL Architecture: Microservices with API Gateway Coding Standards: ESLint Airbnb, Conventional Commitsrules:-id:require-testsdescription:"All changes must include unit tests"applies:[tasks]-id:api-versioningdescription:"API changes must follow semver"applies:[api-spec,design]

4.4 工具适配器扩展

如果需要支持新的 AI 工具，实现ToolCommandAdapter接口：

// src/core/command-generation/adapters/my-tool.tsexportclassMyToolAdapterimplementsToolCommandAdapter{getFilePath(id:string):string{return`.my-tool/commands/${id}.md`;}formatFile(content:string):string{// 转换为目标工具的命令格式return`---\nname:${id}\ndescription: OpenSpec command\n---\n${content}`;}}

4.5 验证自定义 Schema

# 查看可用 schemasopenspec schemas# 验证 schema 格式openspec schema validate my-workflow--verbose# 查看 schema 解析路径openspec schemawhichmy-workflow# 设置项目默认 schemaopenspec configsetschema my-workflow

4.6 实战：封装团队级定制版

假设你的团队是互联网支付团队，需要强制包含安全评审和合规检查：

# 1. 创建团队 Schemaopenspec schema init fintech-payment\--artifacts"proposal,security-review,compliance-check,design,tasks"\--default# 2. 编辑 templates/security-review.md# 加入 CWE 漏洞检查清单、OWASP Top 10 映射# 3. 编辑 templates/compliance-check.md# 加入 PCI-DSS 合规项、数据脱敏要求# 4. 提交到团队内部 npm 仓库# 其他项目通过 openspec schema init 直接使用

五、进阶方案：从 OpenSpec 到企业级规范驱动

OpenSpec 是入门和中小团队的绝佳选择，但随着规模扩大，你可能需要更进阶的方案。

5.1 方案一：spec-kit（GitHub 官方）

定位：重量级规范驱动套件，适合大型开源项目。

核心特性：

• 严格的阶段门控（Phase Gates）
• 完整的 PRD（Product Requirements Document）模板
• Python 工具链和 CLI
• 与 GitHub Issues、Projects 深度集成

与 OpenSpec 的关系：OpenSpec 更轻更自由，spec-kit 更完整更严格。两者可以共存——用 OpenSpec 做日常迭代，用 spec-kit 做重大版本规划。

5.2 方案二：cc-sdd（CCSD / Kiro 风格）

定位：一行命令部署的 Kiro 风格轻量工作流。

# 一行部署npx cc-sdd@latest--claude--langja# 命令族/kiro-spec-init → /kiro-spec-requirements → /kiro-spec-design → /kiro-spec-tasks → /kiro-impl

核心特性：

• 极简部署，无需维护 schema 文件
• 内置 TDD 循环（RED → GREEN → Refactor）
• 独立评审和自动调试
• 适合快速启动和个人开发者

选择建议：如果你嫌 OpenSpec 的 schema 管理太麻烦，cc-sdd 是更轻量的替代。

5.3 方案三：Red Queen（AI 工作流编排引擎）

定位：AI 编码的"Jenkins"，多阶段流水线编排。

工作流：

spec-writing → plan-review ↻ spec-feedback (≤3 retries) → spec-review → coding → code-review ↻ coding (≤3 retries) → testing → human-review → merged

核心特性：

• 动态阶段：通过redqueen.yaml定义，可增删门控
• 人机协作：每个关键节点都设有人类审批门
• 多 Agent 协作：不同 AI worker 负责不同阶段
• 与 OpenSpec 互补：Red Queen 不管理规范，只编排执行

适用场景：企业级 CI/CD、需要严格审批流程的团队。

5.4 方案四：Constitutional SDD（宪法约束规范驱动）

定位：带安全约束和审计追踪的规范驱动开发。

核心特性：

• 权威等级系统（Authority Level）：
  • authority=system：核心业务逻辑和安全要求（最高优先级）
  • authority=platform：基础设施和技术架构决策
  • authority=feature：用户界面和体验要求（最低优先级）
• CWE 漏洞映射：每个安全需求关联具体 CWE 编号
• 审计追踪：完整的规范变更历史，满足合规要求
• 对抗性评估器（Adversarial Evaluator）：独立 Agent 评审实现质量

适用场景：金融、医疗、政务等对安全和合规有严格要求的行业。

5.5 方案五：AI Development Patterns（模式库）

Paul Duvall 维护的 ai-development-patterns 是目前最完整的 AI 开发模式库，将 SDD 扩展为完整的工程体系。

关键模式：

核心理念：

“Keep Quality Left” —— 在早期运行廉价、快速的控制（linter、基础评审），将昂贵的控制（变异测试、深度 AI 评审）留到后期。

“Steer, don’t automate” —— 当 Agent 重复犯错时，改进 harness（指南和传感器），而非仅仅修改提示词。

六、选择决策树

你是个人开发者或小团队？ ├── 是 → 追求极简？ │ ├── 是 → cc-sdd（一行命令，即刻开始） │ └── 否 → OpenSpec（轻量规范，30+ 工具适配） │ └── 否 → 企业级需求？ ├── 需要严格审批流程 → Red Queen（多阶段流水线） ├── 需要合规审计 → Constitutional SDD（宪法约束） ├── 大型开源项目 → spec-kit（GitHub 官方套件） └── 已有 OpenSpec → 渐进升级：加入 Adversarial Evaluator + Model Routing

七、总结

一句话总结：OpenSpec 让 AI 编程从" vibe coding"走向"规范驱动"，而真正让 AI 编程结果可预测的，不是更强的提示词，而是"人和 AI 动手前先对齐、动手后可沉淀"的这层轻量规格层。

参考资源

• OpenSpec GitHub 仓库
• OpenSpec NPM 包
• OpenSpec 官方文档
• AI Development Patterns
• Red Queen
• Constitutional SDD 论文