古法编程

RPI 工作流是一个将功能开发严格拆解为研究 (Research)、计划 (Plan)、实现 (Implement) 三个阶段的系统化流程，每个阶段都由专用的 AI 子代理 (Subagents) 协作完成，并设置验证门 (Validation Gate) 以控制质量。该流程旨在将 Claude Code 从随意的对话工具转变为结构化的工程实践，帮助开发者系统性地规划和执行复杂功能。

RPI 工作流：Research-Plan-Implement 系统化开发流程（7 个 Agent 协作）

对于使用 Claude Code 进行复杂功能开发的团队，随意的提示词往往会导致需求遗漏、设计缺陷或代码质量不稳定。RPI 工作流（Research-Plan-Implement）提供了一个系统化框架，通过分阶段、多代理协作和明确的验证节点，确保从想法到上线的每一步都扎实可靠。

工作流核心：四步流程与 7 个协作 Agent

RPI 工作流并非从编码开始，而是始于清晰的需求描述。它遵循一个四步循环：Describe → Research → Plan → Implement。其中，Research 和 Implement 阶段是自动化协作的核心，分别调用了 6 个和 3 个专用子代理 (Subagents)。

1. Describe（描述）

这是手动步骤。开发者需要将模糊的功能想法转化为一份结构化的请求文档。系统会生成一个功能文件夹 rpi/{feature-slug}/，并将需求描述存入其中的 REQUEST.md 文件。这份文件是后续所有自动化步骤的输入。

2. Research（研究）

这是整个流程的关键决策点，也是一个 GO/NO-GO 门控。执行 /rpi:research 命令会启动一个由 6 个专用子代理 组成的协作分析流水线：

阶段 代理名称 核心任务
阶段 1 requirement-parser 解析 REQUEST.md，提取结构化需求、目标、复杂度估算。
阶段 2 product-manager 从用户价值、市场契合度、产品战略角度评估可行性。
阶段 2.5 Explore （关键） 深入探索现有代码库，分析集成点、现有模式和技术约束，确保后续评估基于代码现实而非假设。
阶段 3 senior-software-engineer 基于技术探索结果，评估实现方案、技术复杂度、依赖和风险。
阶段 4 technical-cto-advisor 综合产品与技术分析，做出战略性的 GO/NO-GO/DEFER 决策。
阶段 5 documentation-analyst-writer 汇总所有分析结果，生成最终的《研究报告》并保存至 research/RESEARCH.md。

只有获得 GO 或 CONDITIONAL GO 建议的功能，才能进入下一阶段。这个研究阶段有效防止了团队在不可行或低价值的功能上浪费精力。

3. Plan（计划）

执行 /rpi:plan 命令，基于通过研究的分析报告，系统将生成一套完整的规划文档。此阶段由 senior-software-engineer、product-manager、ux-designer 和 documentation-analyst-writer 等代理协作，最终产出四个核心文件，全部存放在功能文件夹的 plan/ 目录下：

  • PLAN.md：实现路线图，包含分阶段的任务列表和依赖关系。
  • pm.md：产品需求文档，定义用户故事和验收标准。
  • ux.md：用户体验设计，描述交互流程。
  • eng.md：技术规格文档，阐述架构、API 和数据库设计。

4. Implement（实现）

这是将计划转化为代码的最后一步，也是质量管控最严格的一环。执行 /rpi:implement 命令会启动一个带有 验证门 (Validation Gate) 的循环流程。

Implement 阶段为每个计划中的任务阶段（Phase）执行以下标准化循环：

  1. 代码探索：使用 Explore 代理深入了解现有代码。
  2. 编码实现：senior-software-engineer 代理负责编写代码。
  3. 自我验证：代理运行 lint 和测试进行自检。
  4. 代码审查：code-reviewer 代理审查代码质量、安全性和可维护性。
  5. 用户验证门：系统会暂停，向开发者展示阶段成果、文件变更和审查结果，等待开发者做出 PASS、CONDITIONAL PASS 或 FAIL 的决策。这是人工介入控制质量的关键节点。
  6. 文档更新：根据验证结果更新 PLAN.md 和 IMPLEMENT.md 中的阶段状态。

这个循环确保每一阶段的代码都经过了 AI 自检、AI 评审和人工确认三重关卡，大幅降低了集成风险。

Feature Folder：统一的项目结构

RPI 工作流的一个核心实践是为每个功能创建一个专属的、结构化的文件夹。所有与功能相关的输入、分析、规划和输出都集中管理，便于追踪和审计。

标准的 Feature Folder 结构模板如下：

rpi/{feature-slug}/
├── REQUEST.md              # 步骤1：初始功能描述（输入）
├── research/
│   └── RESEARCH.md         # 步骤2：研究分析与GO/NO-GO决策（输出）
├── plan/
│   ├── PLAN.md             # 步骤3：分阶段实现路线图（输出）
│   ├── pm.md               # 产品需求文档
│   ├── ux.md               # 用户体验设计
│   └── eng.md              # 技术规格文档
└── implement/
    └── IMPLEMENT.md        # 步骤4：实现记录与验证日志（输出）

如何开始使用

  1. 安装：将包含 agents/ 和 commands/rpi/ 的 .claude 文件夹复制到你的代码仓库根目录。
  2. 创建需求：手动创建 rpi/{feature-slug}/REQUEST.md 文件并写入功能描述（Describe 步骤）。
  3. 启动研究：运行 /rpi:research rpi/{feature-slug}/REQUEST.md。
  4. 制定计划：研究通过后，运行 /rpi:plan {feature-slug}。
  5. 开始实现：计划完成后，运行 /rpi:implement {feature-slug}，并按照验证门的提示进行阶段性确认。

这个工作流非常适合用于开发新功能模块、进行重大重构或集成第三方服务等复杂任务。它通过 编排工作流 的模式，将多个独立的代理技能 (Skills) 串联成一个自动化的流水线。

FAQ

Q: RPI 工作流和直接让 Claude Code 写代码有什么区别？ A: 主要区别在于过程控制和决策质量。直接写代码是端到端的，容易在需求理解或技术方案上出错。RPI 流程将大任务拆解，并在每个关键节点（特别是 Research 和 Implement 的验证门）强制进行分析和人工确认，确保方向正确、质量可控。

Q: Research 阶段的“Explore”代理具体做什么？ A: 它负责深入阅读和理解现有的代码库。在评估一个功能是否可行之前，它会分析当前架构、相关模块的代码、依赖关系和编码规范。这保证了后续的技术可行性评估是基于你项目的实际情况，而不是泛泛的通用知识。

Q: 如果 Implement 阶段的某个 Phase 被用户判定为 FAIL 怎么办？ A: 流程会自动回退。senior-software-engineer 代理需要根据用户指出的问题修复代码，然后重新进行自我验证和代码审查，直到再次通过用户验证门。系统严格禁止带着未解决的问题跳入下一个阶段。