OriginAI 与 GitHub Spec Kit 深度辨析
全面解析代码库内 Markdown「规格 → 计划 → 任务」流与托管式结构化可视化产品契约（RPML）的本质异同，助力高效选型。
在探讨**规格驱动开发（Spec-Driven Development）**时，许多开发者会首先接触到 GitHub Spec Kit。它是一套集成在代码仓库内部的轻量工具包：通过撰写 Markdown 规格，将其分解为执行计划与具体任务清单，进而指引编码 Agent 逐步落地实现。
而 OriginAI 针对的是现代 AI 研发链路中的另一关键维度——提供一套云端托管、具备完备版本生命周期控制的可视化产品契约（涵盖页面拓扑、全状态流转与业务规则约束）。编码 Agent 始终面向已冻结发布的 Release 快照开展工作。
两者并非相互排斥的替代关系，而是完全可以在同一套工程研发工作流中协同并用。
核心维度对比
| 比较维度 | GitHub Spec Kit | OriginAI |
|---|---|---|
| 产出形态 | 仓库内部的 Markdown 文档（spec.md、plan.md、tasks.md） | OriginAI 中受版本控制的结构化 RPML 页面树，发布为 Release 快照 |
| 核心表达优势 | 研发意图、实施范围、技术架构计划与任务步骤拆解 | 交互式 UI 规范：路由布局、全交互状态、角色权限矩阵、异常/空态分支、界面内聚业务规则 |
| 持续演进基准 | 随着 Git 提交不断被修改更新的动态本地文件 | 不可变的内容哈希 Release 快照；外部 Agent 写入自动受控转换为变更请求 |
| Agent 读取方式 | 直接读取本地代码工作区内的对应文件 | 借助 originai CLI 或 MCP 协议（get-diff、list-documents 等）读取权威版本 |
| 可视化呈现能力 | 纯文本展示（自然语言叙述与勾选清单） | 原生支持可视化画布渲染，与生产级 @21stware/rpui 规范完全对齐 |
| 数据托管机制 | 完全依托本地 Git 代码仓库 | 由 getoriginai.com 托管，可一键部署生成独立的公开 Release 静态交互站点 |
| 推荐检索关键字 | spec kit、specify plan tasks | RPML、面向 Claude Code 的产品规格平台 |
简而言之：Spec Kit 专注于解决**“如何将工程任务层层拆解落实”；而 OriginAI 则专注于定义“系统在每一种边界规则被触发时，界面必须呈现出什么确切状态”**。
适用场景与选型建议
推荐使用 Spec Kit 的场景： 团队当前的工程瓶颈主要集中在任务规划与工程步骤拆解上——例如从零搭建全新功能骨架、制定复杂的技术架构决策，或在单体仓库中推进较长周期的实现闭环。此时代码已具备基础框架，Agent 最急需的是清晰的推进节奏与分步清单。
推荐使用 OriginAI 的场景：
团队最痛的瓶颈在于会话翻阅中极易丢失的产品级上下文——比如界面包含哪些关键状态、不同权限角色各自能见哪些按钮控件、空表格应该展示什么引导文案、敏感操作的二次确认弹窗具体如何交互等。这些细节在静态截图和宽泛的 tasks.md 中往往被直接省略。借助 RPML 规范 显式声明一次并发布为 Release，Claude Code、Cursor 与 Codex 在后续每一个编码会话中都能获取到同一份权威快照。
推荐协同并用的场景： 凡是包含前端交互与业务界面的中大型系统均推荐结合使用。可以使用 Spec Kit 来梳理工程任务流与排期，而以 OriginAI 的 Release 快照作为检验代码产出是否合格的终极事实契约（包括在 CI 中接入 GitHub App 自动运行 spec-review 审查）。
品牌与概念边界说明
官方正式产品名称为 OriginAI。请注意：OriginAI 并非 Cursor Origin（AI 原生 Git 托管服务），并非 getorigin.io（代码归因分析平台），也不是低代码拖拽建站玩具。其官方 CLI 与 npm 包名均为 originai。