# Rivo：面向AI编程代理的规范驱动开发工作流 > 探索一种纯Markdown、主机无关的AI辅助开发工作流，通过结构化规范文档解决上下文漂移和决策不透明问题 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-05-11T05:44:18.000Z - 最近活动: 2026-05-11T05:54:28.115Z - 热度: 150.8 - 关键词: Rivo, 规范驱动开发, AI编程助手, Claude Code, Codex, 工作流, Markdown, 代码审查 - 页面链接: https://www.zingnex.cn/forum/thread/rivo-ai - Canonical: https://www.zingnex.cn/forum/thread/rivo-ai - Markdown 来源: ingested_event --- # Rivo：面向AI编程代理的规范驱动开发工作流\n\n## AI辅助开发的痛点：上下文漂移与决策黑洞\n\n如果你曾经使用Claude Code、Codex CLI或其他AI编程助手完成过持续数天的复杂项目，你一定遇到过这两种令人沮丧的失败模式：\n\n**上下文漂移（Context Drift）**：AI在对话的第三轮就忘记了第一轮达成的共识。你明明告诉过它某个关键的设计决策，但几轮交互后，它又开始按照完全不同的思路实现功能。\n\n**决策不透明（Decision Opacity）**：AI在某个时刻做出了一个关键判断，但这个判断过程完全是一个黑盒。你无法审查它为什么这样决定，也无法在后续需要时回溯或修正这个决策。\n\n这些问题的根源在于：传统的AI辅助开发缺乏结构化的工作流和可追溯的决策记录。Rivo项目正是为解决这些问题而生。\n\n## Rivo的核心理念：规范驱动的开发工作流\n\nRivo是一个面向AI编程代理的规范驱动开发（Spec-Driven Development, SDD）插件。它将AI辅助开发的完整生命周期——从需求提出到代码实现——框架化为一系列Markdown命令文档。\n\n### 设计哲学：少即是多\n\nRivo的设计刻意追求极简：\n- **12个命令**：覆盖从需求到实现的完整流程\n- **零代码**：没有编排逻辑、没有验证脚本、没有模式检查\n- **纯Markdown**：所有规范都以人类可读的Markdown文档形式存在\n- **主机无关**：相同的命令文档在Claude Code和Codex CLI上运行一致\n\n这种极简主义不是功能缺失，而是刻意为之。Rivo相信，AI本身已经足够智能，我们不需要用复杂的框架来约束它，而是应该提供清晰的指导，让AI发挥其能力。\n\n## 工作流全景：从问题到代码的完整链路\n\nRivo将开发流程划分为三个层次：需求层、工程层和闭环层。\n\n### 需求层（Requirement Tier）：理解要做什么\n\n需求层的核心目标是确保团队真正理解需要解决的问题，而不是急于跳入解决方案。\n\n**`/rivo:roadmap`** - 项目路线图管理\n初始化或管理`.rivo/project.yaml`，这是项目的单一事实来源（Single Source of Truth），记录所有史诗（Epics）和条目（Entries）。\n\n**`/rivo:charter`** - 产品宪章\n创建或编辑`CHARTER.md`，定义项目的核心原则：定位、用户、硬性约束、非目标、价值排序。这份文档是后续所有决策的锚点。\n\n**`/rivo:issue`** - 智能提案\n提出新需求时，系统会进行重复检测和AI字段评估，确保提案的质量和独特性。\n\n**`/rivo:clarify`** - 协作澄清\n这是Rivo最具特色的命令之一。它通过协作式根因分析，深入挖掘需求背后的真实问题。输出是一份`contract.md`，明确记录问题定义和验收标准；如果需求被判定为无效，则会被归档。\n\n**`/rivo:claim`** - 锁定任务\n纯粹的状态切换，标记一个条目已被认领并开始开发。这是一个刻意设计的"接缝"——在决定做和开始做之间留出空间，让人的判断始终保持在循环中。\n\n### 工程层（Engineering Tier）：决定怎么做\n\n工程层将已澄清的需求转化为可执行的实现方案。\n\n**`/rivo:architect`** - 架构对齐（可选）\n对于非机械性任务，通过一问一答的方式逐步对齐架构决策：数据流向、模块边界、故障模式。输出`architect.md`。\n\n**`/rivo:spec`** - 规范物化\n将架构设计和需求合同转化为具体的实现规范。自动触发`/rivo:review-spec`进行审查。输出`spec.md`。\n\n**`/rivo:plan`** - 执行计划\n从规范推导出详细的执行计划。自动触发`/rivo:review-plan`进行工程和产品双维度审查。输出`plan.md`。\n\n**`/rivo:code`** - 代码实现\n按照计划逐任务执行，采用TDD（测试驱动开发）方法，每个任务产生一个原子提交。自动触发`/rivo:review-code`进行代码审查。\n\n### 审查机制：多视角的质量把关\n\n每个工程层命令都内置了审查步骤：\n\n**`/rivo:review-spec`** - 规范审查\n检查规范是否完整、清晰地表达了需求，是否考虑了边界情况。\n\n**`/rivo:review-plan`** - 计划审查\n从工程可行性和产品价值两个维度评估执行计划。\n\n**`/rivo:review-code`** - 代码审查\n从安全性、质量、正确性三个维度审查实现代码。\n\n审查采用循环修复机制：审查者发现问题后，修复在原地进行，直到审查通过（PASS）才提交代码。如果需要人工介入（ESCALATE），则创建一个检查点并保留工作现场供人工检查。\n\n### 闭环层（Closing Tier）：从经验中学习\n\n闭环层是Rivo的M7里程碑目标，包括：\n\n**`/rivo:retro`** - 复盘\n将项目经验沉淀为`learnings/.md`，供未来项目参考。\n\n**`/rivo:archive`** - 归档\n将完成的条目归档，保持项目看板的整洁。\n\n## 项目布局：规范即代码\n\nRivo强制采用特定的项目目录结构，每个文件都有明确的职责：\n\n```\nyour-repo/\n├── CHARTER.md # 产品级根原则（可加载的上下文）\n├── CLAUDE.md # 工程规范（代码风格、语言选择、仓库规则）\n├── .rivo/\n│ ├── project.yaml # 史诗+条目（单一事实来源）\n│ └── items// # 每个条目的专属目录\n│ ├── contract.md # clarify的输出\n│ ├── architect.md # architect的输出\n│ ├── spec.md # spec的输出\n│ ├── plan.md # plan的输出\n│ └── checkpoints/ # ESCALATE的追踪记录\n└── ... (你的代码)\n```\n\n这种布局的设计意图非常明确：\n- **CHARTER.md**回答"项目是为了什么"\n- **CLAUDE.md**回答"如何在这个项目中写代码"\n- **.rivo/**目录下的所有文档构成完整的审计日志\n\n## 状态管理：显式优于隐式\n\n每个`.rivo/project.yaml`条目都有一个状态字段，跨越10个值的枚举：\n\n```\ndraft → clarified → claimed → in-architect → in-spec → in-plan → in-code → in-review → done → archived\n```\n\n合法的转换规则、硬性约束、过渡期豁免都记录在`.rivo/project.yaml`的头部——这是单一事实来源。每个命令文档以`## Status transitions`章节开头，指向这个源头（DRY原则——通过构造避免漂移）。\n\n重要的是：没有状态机代码。审查者和用户通过手工识别违规，而不是依赖自动化验证。这种设计保持了Rivo的"零代码"承诺。\n\n## 双向对称性：主机无关的硬约束\n\nRivo的一个核心设计原则是**双向对称性**：同一个命令文档必须在任何支持插件协议的主机上运行一致。Claude Code和Codex CLI的命令体必须是源代码完全相同的。\n\n这意味着：\n- 拒绝任何主机特定的机制（钩子、原生二进制文件、CLI调度）\n- 如果需要在Claude Code前端和Codex审查之间切换，通过主机级桥接插件实现\n- Rivo本身保持主机中立\n\n这种约束看似严格，但它确保了Rivo的可移植性和长期价值。\n\n## 技术渊源：站在巨人肩膀上\n\nRivo的设计融合了三个前序项目的精华：\n\n**superpowers**（Jesse Vincent, MIT）\n提供了多主机插件形态（`.claude-plugin/` + `.codex-plugin/` + `shared commands/` + `skills/`）和头脑风暴三问测试。TDD/验证/子代理驱动开发技能作为第三方内容适配；其他模式（澄清式探询、任务后审查）则被内联表达为Rivo的命令文档。\n\n**gstack**\n贡献了顺序多视角审查（autoplan风格）以及安全性/质量/正确性检查清单——这些模式作为指导文字存在于`commands/review-code.md`中。\n\n**GSD**\n作为反面教材，其12-23个命令的表面、STATE.md、复盘/波浪调度机制被刻意省略，认为它们对于单人设置而言是过度设计。\n\n## 使用场景：谁应该使用Rivo\n\nRivo特别适合以下场景：\n\n**持续数天的复杂项目**\n当项目需要多轮迭代、涉及多个模块、需要保持长期上下文一致性时，Rivo的结构化工作流能够显著降低认知负担。\n\n**多人协作的AI辅助开发**\n当多个开发者使用AI Agent协作时，Rivo提供的标准化流程和审计日志能够协调团队工作。\n\n**需要严格质量把关的项目**\n当代码质量至关重要、需要多维度审查时，Rivo的审查机制提供了系统化的质量保障。\n\n**追求可解释性的场景**\n当需要理解AI为什么做出某个决策、需要回溯决策过程时，Rivo的文档化工作流提供了完整的审计追踪。\n\n## 局限与权衡\n\nRivo明确告知用户它不是什么：\n\n**不是重型框架**\n如果你需要状态机、验证器、自动化检查，Rivo不是正确的工具。它提供的是轻量级的指导，而不是强制性的约束。\n\n**不适合简单任务**\n对于一次性的简单修改，Rivo的流程可能显得过于繁琐。它更适合需要持续投入的中大型任务。\n\n**依赖主机能力**\nRivo假设主机AI能够生成子代理、读写文件、执行git操作。如果主机不具备这些能力，Rivo无法工作。\n\n## 结语：规范驱动开发的未来\n\nRivo代表了一种新的AI辅助开发范式：不是让AI完全自主地工作，也不是让人完全控制每一步，而是通过结构化的规范和清晰的决策点，实现人与AI的高效协作。\n\n在这个范式中，AI负责执行和生成，人负责判断和把关，而规范文档成为两者之间的契约。这种设计既发挥了AI的能力，又保留了人的控制，同时通过文档化确保了可审计性和可复现性。\n\n随着AI编程助手的普及，像Rivo这样的工作流工具将变得越来越重要。它们不是限制AI的枷锁，而是释放AI潜力的脚手架——让AI能够承担更复杂、更长期的任务，同时保持质量和可控性。\n\n如果你正在使用Claude Code或Codex CLI进行严肃的开发工作，Rivo值得你认真考虑。它可能正是你一直在寻找的、让AI辅助开发从"玩具"走向"生产工具"的那块拼图。