Featured image of post 在OpenCode中尝试OpenSpec：规约驱动开发实践分享
AI

在OpenCode中尝试OpenSpec：规约驱动开发实践分享

OpenCode环境下使用OpenSpec的体验分享。探讨规约驱动开发如何架起AI编程助手与结构化开发工作流之间的桥梁，以及我为什么选择OpenSpec而不是Spec Kit。

引言：在OpenCode中使用OpenSpec

编程工作空间

最近我在OpenCode环境中尝试使用 OpenSpec，想分享一下这段体验。不熟悉OpenSpec的朋友，简单介绍一下：它是一个规约驱动开发（SDD）框架，为AI辅助编程工作流提供结构化支持。它现在支持与OpenCode集成，正好契合我的开发环境。

这篇文章里，我会聊聊我对规约驱动开发的理解、它如何与vibe coding结合，以及为什么我最终选择了OpenSpec而非Spec Kit。

https://openspec.dev/

什么是规约驱动开发？

规划与文档

规约驱动开发（SDD） 是一种在写代码之前先定义清晰规约的方法。不是直接跳到实现阶段，而是先明确你要做什么、为什么做、以及它应该如何工作。就像盖房子前先画好详细的设计图。

核心工作流

OpenSpec遵循一个简洁的三阶段流程：

  1. Propose（提议） — 描述你的想法，AI生成提案、规约、设计文档和任务分解
  2. Apply（应用） — AI按照任务清单一步步实现变更
  3. Archive（归档） — 完成的变更被移动到归档目录，保留清晰的记录

主要优势

  • 实现前对齐：在写代码前，你和AI就方案达成一致
  • 持续上下文：规约文件存放在代码库的openspec/目录下，不会在会话间丢失
  • 可追踪进度：任务以清单形式组织，方便监控和审查
  • 审计轨迹：每次变更都有文档记录，便于理解历史决策

与Vibe Coding的结合

如果你喜欢 vibe coding（那种凭直觉快速迭代的流动状态开发方式），可能会担心SDD会不会太死板。从我的经验来看，它们其实相辅相成。Vibe coding适合探索和快速原型，SDD则在实现复杂功能或维护长期项目时发光发热。先用vibe coding探索想法，准备构建可持续的成品时再切换到SDD。

更换oh-my-opencode的模型

kimi-k2.5

岔开话题一下：如果你看过我之前的发文，应该知道我在优化oh-my-opencode的模型配置。最近我又做了一个调整 —— 把主模型换成了 Kimi K2.5。

有趣的是，这正好和最近的一则行业新闻呼应：Cursor最近承认他们的新Composer 2模型是基于Kimi K2.5作为训练基座构建的。虽然Cursor在此基础上做了继续预训练和强化学习，但底座是Kimi K2.5。这印证了我的选择 —— 如果Cursor都押注Kimi做他们的编程助手，那我的配置里也该考虑它。

OpenSpec与Spec Kit的对比

在选定OpenSpec之前，我也评估了GitHub的Spec Kit。对比结果如下：

维度 OpenSpec Spec Kit
方式 迭代式，提议优先 全面但重量级
最适合 存量项目、已有代码库 全新项目、新功能
工作流 灵活阶段（提议→应用→归档） 严格的阶段关卡
配置 轻量（npm install） 需要Python环境
文档 Markdown格式，简洁 大量Markdown模板
变更追踪 内置（ADDED/MODIFIED/REMOVED） 需手动协调
工具支持 20+ 智能体/IDE 8+ 支持的智能体

关键差异

Spec Kit非常适合大型新功能开发，前期规划的投入能通过减少返工获得回报。它提供全面的模板和严格的阶段关卡确保完整性。但这种刚性在小任务或维护现有代码库时可能显得过重。

OpenSpec则是为存量项目设计的。它使用变更标记（ADDED/MODIFIED/REMOVED）追踪相对于现有功能的改动，非常适合迭代改进。工作流更灵活，可以随时更新任何文档，没有严格的阶段关卡。

我为什么选择OpenSpec

试用两者后，我因为几个原因选择了OpenSpec：

1. 维护存量项目

我的工作大多是维护现有项目，而非从零构建。OpenSpec的变更追踪方式（标记为ADDED、MODIFIED或REMOVED）非常契合这种工作流。

2. 团队协作考量

在团队环境中，不是所有人都会用OpenSpec。OpenSpec的灵活性意味着即使团队成员不用这个工具，也能理解和审查变更 —— 规约就是仓库里的Markdown文件而已。

3. 简洁性

OpenSpec更轻量、更易上手。不需要配置Python环境，也不需要研究复杂的模板。简单的npm install -g @fission-ai/openspec就搞定。

4. 个人开发工作流

对个人项目和小任务，OpenSpec恰到好处。既提供了足够的结构保持条理，又不会显得官僚。

OpenSpec使用方法和小技巧

开始使用 

1
2
3
4
5
6

# 全局安装OpenSpec
npm install -g @fission-ai/openspec@latest

# 在项目目录初始化
cd your-project
openspec init

这会创建一个openspec/目录，包含：

  • AGENTS.md — 给AI智能体的指示
  • project.md — 全局项目上下文
  • specs/ — 当前系统规约
  • changes/ — 活跃的变更提案

基本工作流

proposal.md、design.md、tasks.md

  1. 创建提案：

    1

    /opsx:propose add-user-authentication

    AI会生成：proposal.md、design.md、tasks.md和变更规约

  2. 审查和优化：检查生成的文件，按需调整

  3. 应用变更：

    1

    /opsx:apply

    AI按任务清单逐项实现

  4. 完成后归档：

    1

    /opsx:archive

    完成的变更移到openspec/changes/archive/

使用小贴士

  • 从小做起：不要试图一次性规约整个项目，先从一个功能或bug修复开始
  • 应用前审查：提案阶段是抓住误解的最后机会，趁代码还没写
  • 版本控制规约文件：提交openspec/目录，让整个团队受益
  • 存量项目用/opsx:onboard：这个命令扫描代码库生成初始规约

总结

在OpenCode中使用OpenSpec几周后，我确信规约驱动开发在现代AI辅助工作流中有一席之地。它不会取代vibe coding那种创造性、探索性的本质，但会在需要时增加一层有价值的结构。

OpenSpec的轻量方式和OpenCode的智能体架构天然契合。无论你是维护存量代码、团队协作，还是只是想更刻意地进行开发流程，我都建议试试。

如果你已经在用oh-my-opencode，集成是无缝的 —— 在项目中初始化OpenSpec，然后就开始使用斜杠命令。对我的模型配置历程感兴趣的朋友，可以看看我之前关于oh-my-opencode模型选择的文章。

你有没有试过用OpenSpec或Spec Kit做规约驱动开发？欢迎在评论区分享你的体验。