【AI 】OpenSpec 实战指南:在 Cursor 中落地 AI 原生开发工作流

【AI 】OpenSpec 实战指南:在 Cursor 中落地 AI 原生开发工作流

OpenSpec 实战指南:在 Cursor 中落地 AI 原生开发工作流

前言:OpenSpec 是“规范驱动开发 (Spec-Driven Development, SDD)”在 Cursor IDE 中的最佳实践落地。它将 AI 从一个“容易遗忘的编码助手”升级为“严谨的工程合作伙伴”。

0. 安装和初始化

安装要求:Node.js >= 20.19.0
npm install -g @fission-ai/openspec@latest
openspec --version 装好后可以查看版本,输出版本号,说明安装成功,我的版本号是1.1.1,注意1.0.0之后的版本命令都更新了,我讲的都是新的命令。

选择你的工程目录,打开cmd输入,openspec init 初始化目录,

在这里插入图片描述


我这里用的是cursor,所以选择cursor。

在这里插入图片描述


确认后,显示如下:

在这里插入图片描述


这样整个工程就创建好了~~~~

1. 核心架构解密:CLI 与 Agent 的关系

在 OpenSpec 中,我们经常看到两类命令:openspec .../opsx:...。理解它们的底层关系,是你掌握这套系统的关键。

1.1 角色定义

  • CLI (openspec ...) —— “机械臂” (The Engine)
    • 本质:它是底层的命令行工具(类似于 Git 或 NPM)。
    • 能力:它只懂文件操作。它负责创建文件夹、移动文件、验证 JSON 格式、合并文档。它没有智能,不理解业务,只听死命令。
    • 运行位置:Terminal (终端)。
  • Agent (/opsx:...) —— “大脑” (The Brain)
    • 本质:它是 Cursor 的 AI 代理脚本(Prompt Chain)。
    • 能力:它拥有智能。它负责思考架构、编写文档、生成代码。
    • 运行位置:Chat (对话框)。

1.2 底层调用关系

Agent 是 CLI 的“驾驶员”。

当你输入 /opsx:new "login" 时,实际上发生了一连串的连锁反应:

  1. Agent 思考:AI 先分析你的意图,决定需要创建一个名为 login 的变更。
  2. Agent 调用 CLI:AI 在后台默默执行了终端命令 openspec new change "login"
  3. CLI 执行:CLI 在硬盘上创建了目录结构。
  4. Agent 接管:AI 看到目录创建好了,开始引导你:“好了,文件夹建好了,我们来写 Proposal 吧…”。
结论:你(用户)指挥 Agent,Agent 指挥 CLI。Agent 封装了繁琐的 CLI 操作,让你专注于业务逻辑。

2. 双重规格系统:Delta Specs vs. Main Specs

这是 OpenSpec 最精妙的设计之一。你会发现有两个地方存放 spec.md,它们看似相同,实则作用完全不同。

2.1 位置对比

  • 位置 A (Delta Specs): openspec/changes/<change-name>/specs/...
  • 位置 B (Main Specs): openspec/specs/...

2.2 深度解析

特性Delta Specs (位置 A)Main Specs (位置 B)
中文名变更规格 (拟议)主规格 (真理之源)
状态Draft (草稿/拟议中)Live (生效中/已发布)
含义“我希望系统变成什么样”“系统现在是什么样”
生命周期随变更创建,归档即消失 (合并)永久存在,随项目演进
Git 类比Feature Branch (功能分支)Main Branch (主分支)
作用指导 AI 完成本次开发任务指导 AI 理解现有系统能力,帮助新成员上手

2.3 数据流向

  1. 开发时:你在 changes/ 下编写 Delta Specs。此时,它可能与 Main Specs 冲突(因为你要修改现有功能)。
  2. 归档时 (/opsx:archive):CLI 会自动将 Delta Specs 合并 (Merge) 到 Main Specs 中。
  3. 完成后changes/ 文件夹被移走,specs/ 文件夹更新为最新状态。

3. 标准工作流 (The Workflow)

第一阶段:思考 (Thinking)

  • 指令/opsx:explore
  • 作用:自由探索,分析代码,不产生文件。

第二阶段:定义 (Defining)

  • 指令
    • /opsx:new "任务名" (新手向,一步步引导)
    • /opsx:ff "任务名" (老手向,Fast-Forward,一次性生成)
  • 产出工件
    1. Proposal: Why & What (意图)。
    2. Specs (Delta): 具体的、可测试的需求 (WHEN…THEN…)。
    3. Design: 技术选型、架构决策。
    4. Tasks: 执行清单。

第三阶段:执行 (Executing)

  • 指令/opsx:apply "任务名"
  • 作用:AI 读取 tasks.md,自动写代码。
  • 技巧:中断后使用 /opsx:continue "任务名" 恢复。

第四阶段:完成 (Finishing)

  • 指令/opsx:archive "任务名"
  • 作用
    1. 验证任务完成度。
    2. 将 Delta Specs 合并进 Main Specs
    3. 将变更文件夹移入 archive/ 目录作为历史记录。

4. 最佳实践与 FAQ

4.1 并行开发与“暂停”

  • 场景:正在做 feature-A,突然要修 bug-B
  • 操作流
    1. git stash (保护 feature-A 的半成品代码)。
    2. /opsx:ff "bug-B" (创建修复任务)。
    3. /opsx:apply -> /opsx:archive (修复并归档)。
    4. git stash pop (恢复现场)。
    5. /opsx:continue "feature-A" (继续之前的任务)。

4.2 为什么不用 Cursor (CLI)命令行?

  • Cursor (CLI):适合“盲写”和自动化执行,但缺乏全局视图。
  • Cursor (IDE):OpenSpec 产生大量文档,IDE 的文件树分屏对比Diff 视图能让你更好地进行决策审查 (Review)
  • 建议:在 IDE 里做规划和 Review,享受掌控感。

4.3 什么时候该用什么命令?

  • 90% 的时间:用 /opsx:... (Agent 命令)。让 AI 帮你干活。
  • 10% 的时间:用 openspec ... (CLI 命令)。通常用于查看状态 (openspec status) 或手动强制归档。

5. 总结

OpenSpec 的本质是将**“隐性的思维过程”转化为“显性的文档资产”**。

  • 它让 AI 不再是“黑盒”,而是可控的“白盒”。
  • 它让你的项目不再只有代码,还有完整的决策历史 (archive/)功能说明书 (specs/)

Read more

LazyLLM 多 Agent 应用全流程实践:从源码部署到可视化 Web 调试的低代码方案

LazyLLM 多 Agent 应用全流程实践:从源码部署到可视化 Web 调试的低代码方案

LazyLLM 多 Agent 应用全流程实践:从源码部署到可视化 Web 调试的低代码方案 前言:为什么选择 LazyLLM 构建多 Agent 大模型应用? LazyLLM 作为低代码构建多 Agent 大模型应用的开发工具,可大幅降低大模型应用的开发与部署门槛。本文聚焦其在豆包模型的落地实践,将从源码部署豆包文本模型的完整配置步骤入手,延伸至官方 WebModule 启动可视化 Web 界面的实操流程,并配套精准性、简洁度等多维度的部署测试说明,为开发者提供可直接对照的实操指南,助力高效完成豆包模型在 LazyLLM 框架下的部署与验证。 LazyLLM 整体架构解析:三层联动的多 Agent 运行体系 LazyLLM 的架构分为三层级递进结构,各层级分工明确且联动协同,实现从应用开发到落地执行的全流程覆盖:上层(LazyPlatform AI 大模型应用开发平台):核心含应用编排平台以可视化编排、发布、回流、调优的闭环完成应用构建迭代与平台管理模块通过租户、权限管理支撑多用户运维,是开发者的高效开发管理入口中层(

PyBullet实战:用AABB碰撞检测让R2D2机器人避开障碍物(附完整代码)

从碰撞检测到智能避障:用PyBullet为R2D2机器人注入“触觉” 如果你曾经尝试过在虚拟世界里让一个机器人动起来,大概率会遇到一个令人头疼的问题:它要么像个醉汉一样横冲直撞,要么对眼前的障碍物视而不见,一头撞上去。几年前,我第一次用PyBullet做机器人仿真时,就遇到了这个尴尬。我让一个R2D2模型在场景里跑,结果它径直冲向一个立方体,然后……穿过去了。那一刻我意识到,让机器人“动起来”只是第一步,让它“感知”并“避开”环境中的物体,才是仿真从玩具走向实用的关键。 PyBullet作为一款强大的物理仿真引擎,其真正的价值不仅在于能模拟重力、关节运动这些基础物理现象,更在于它提供了丰富的环境交互能力,其中碰撞检测就是实现智能避障的基石。而AABB(轴对齐包围盒) 作为一种高效、实用的碰撞检测方法,是我们在仿真中为机器人赋予“触觉”的首选工具。这篇文章,我将带你深入PyBullet的碰撞检测世界,手把手教你如何为经典的R2D2机器人实现一套实时、可靠的动态避障系统。我们不止步于让轮子转起来,更要让机器人学会“看路”。 1. 理解PyBullet中的碰撞检测:不止于AABB

【选型】地瓜机器人RDK系列选型指南:X3 vs X5 vs S100 vs S100P(含资源对比图)

【选型】地瓜机器人RDK系列选型指南:X3 vs X5 vs S100 vs S100P(含资源对比图)

在机器人开发领域,地瓜机器人(D-Robotics)凭借其“RDK(Robot Developer Kit)”系列开发套件,已成为众多开发者和创业团队的首选平台。从轻量级边缘计算到高性能具身智能,地瓜机器人已构建了覆盖多场景的完整产品线,致力于为开发者提供高性价比、高集成度、高扩展性的解决方案。其核心芯片“旭日®”系列持续迭代,推动AI与机器人深度融合,助力实现从感知到控制的全链路自主化。 本文将深入对比当前主流的四款RDK开发套件:RDK X3、RDK X5、RDK S100、RDK S100P,并提供详细的资源对比图与应用场景分析,帮助你快速完成技术选型,降低开发门槛,提升项目落地效率。 一、产品定位概览 在深入参数前,先明确每款产品的核心定位,以便根据项目阶段、预算和性能需求做出合理选择。 ● RDK X3:轻量级边缘AI计算模组,适合入门级机器人、智能摄像头、无人机等低功耗、小体积场景。是初学者和教育项目的理想起点,具备基础AI推理能力,可快速搭建视觉识别系统。 ● RDK

飞书 × OpenClaw 接入指南:不用服务器,用长连接把机器人跑起来

你想在飞书里用上一个能稳定对话、能发图/收文件、还能按规则在群里工作的 AI 机器人,最怕两件事:步骤多、出错后不知道查哪里。这个项目存在的意义,就是把“飞书接 OpenClaw”这件事,整理成一套对非技术也友好的配置入口,并把官方文档没覆盖到的坑集中写成排查清单。 先说清楚它的角色:OpenClaw 现在已经内置官方飞书插件 @openclaw/feishu,功能更完整、维护也更及时。这是好事,说明飞书 + AI 的接入已经走通。这个仓库并不是要替代官方插件,而是继续为大家提供: * 新用户:从零开始的新手教程(15–20 分钟) * 老用户:从旧版(独立桥接或旧 npm 插件)迁移到官方插件的保姆级路线 * 常见问题答疑 & 排查清单(最常见的坑优先) * 进阶场景:独立桥接模式依然可用(需要隔离/定制时再用) 另外,仓库也推荐了一个新项目