# Rpi Workflow

> Research-Plan-Implementation workflow for complex projects. Use when the user mentions RPI, research-plan-implementation, 研究-计划-实现, complex multi-stage development, requirements analysis, technical planning, implementation plans, or explicitly asks to use the RPI process.

- Skill: `aioneas/rpi-workflow` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add aioneas/rpi-workflow`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aioneas/rpi-workflow/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: Aioneas (https://skillmd.com/u/aioneas)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/aioneas/rpi-workflow

---


# RPI Workflow - Research-Plan-Implementation

基于 RPI 理论的复杂项目开发工作流，通过三阶段分离实现上下文专注与零决策执行。

## 触发条件

当用户提到以下关键词时触发：
- "RPI"、"rpi workflow"、"研究-计划-实现"
- "复杂项目"、"大型开发任务"、"多阶段开发"
- "需求分析"、"技术方案"、"实现计划"
- 或明确要求使用 RPI 流程

## 核心理念

**上下文专注**：每阶段清空上下文，让 AI 的有效上下文（~80K tokens）专注于单一任务。

**约束驱动**：Research 阶段生成约束集（constraints），而非信息堆砌。约束用于缩小解决方案空间。

**零决策执行**：Plan 阶段消除所有决策点，Implementation 阶段纯机械执行，无需临场判断。

**多模型协作**：利用不同模型的优势（GPT-4 逻辑、Claude 代码、Gemini 创意）生成原型，最终由主模型重构为生产代码。

## 工作流程

### 阶段 0：初始化（Init）

**目标**：为项目创建 RPI 工作目录，初始化文档结构。

**执行**：
1. 检测当前项目是否已有 `.rpi/` 目录
2. 若无，创建以下结构：
   ```
   .rpi/
   ├── proposals/          # 需求提案
   ├── constraints/        # 约束集
   ├── plans/             # 执行计划
   ├── implementations/   # 实现记录
   └── config.json        # 配置文件
   ```
3. 记录项目基本信息（语言、框架、代码库路径）
4. 检测可用的多模型资源（通过 `minis-model-use list`）

**输出**：初始化报告，包含可用模型列表和工作目录路径。

---

### 阶段 1：研究（Research）

**目标**：将用户需求转化为约束集 + 可验证的成功判据。

**核心原则**：
- 约束集告诉后续阶段"不要考虑这个方向"
- 按上下文边界（而非角色）划分探索任务
- 使用 `find` + `grep` 进行代码库探索
- 所有模糊点必须通过用户交互消除

**执行步骤**：

1. **初步评估**
   - 结合用户需求快速扫描代码库（`find` + `grep` 关键文件）
   - 判断项目规模：单目录 vs 多模块结构
   - 决定是否需要并行探索

2. **定义探索边界**（按上下文，非角色）
   - 示例划分：
     * 边界 1：用户域代码（user models, services, UI）
     * 边界 2：认证授权代码（auth middleware, session, tokens）
     * 边界 3：配置与基础设施（configs, deployments, build scripts）
   - 每个边界应自包含，无需跨边界通信

3. **并行探索**（可选，复杂项目）
   - 为每个边界生成探索提示词
   - 使用 `minis-model-use` 调用多个模型并行分析
   - 统一输出格式（JSON）：
     ```json
     {
       "module_name": "探索的上下文边界",
       "existing_structures": ["发现的关键结构/模式"],
       "existing_conventions": ["使用中的约定/标准"],
       "constraints_discovered": ["限制解决方案空间的硬约束"],
       "open_questions": ["需要用户输入的模糊点"],
       "dependencies": ["对其他模块/系统的依赖"],
       "risks": ["潜在风险或阻塞点"],
       "success_criteria_hints": ["指示成功的可观察行为"]
     }
     ```

4. **聚合与综合**
   - 合并所有探索报告
   - 提取统一约束集：
     * 硬约束：技术限制、不可违反的现有模式
     * 软约束：约定、偏好、风格指南
     * 依赖关系：影响实现顺序的跨模块关系
     * 风险：需要缓解的潜在阻塞点
   - 识别所有需要用户澄清的开放问题

5. **用户交互消除模糊性**
   - 编译优先级排序的问题列表
   - 系统性地向用户提问：
     * 分组相关问题
     * 为每个问题提供上下文
     * 在适用时建议默认答案
   - 将用户响应转化为额外约束

6. **生成提案文档**
   - 创建 `.rpi/proposals/YYYYMMDD-HHMMSS-<title>.md`
   - 内容结构：
     ```markdown
     # 提案：<标题>
     
     ## 用户需求（原始）
     <用户的完整需求描述，不得缩写>
     
     ## 约束集
     ### 硬约束
     - <技术限制>
     
     ### 软约束
     - <约定/偏好>
     
     ### 依赖关系
     - <跨模块依赖>
     
     ## 开放问题（已解决）
     - Q: <问题>
       A: <用户答案>
     
     ## 风险与缓解
     - 风险：<描述>
       缓解：<策略>
     
     ## 成功判据
     - <可验证的成功标准>
     ```

**输出**：提案文档路径，提示用户"Research 阶段完成，建议清空上下文后进入 Plan 阶段"。

---

### 阶段 2：计划（Plan）

**目标**：将提案细化为零决策可执行任务流 + PBT 属性。

**核心原则**：
- 消除所有决策点，Implementation 应为纯机械执行
- 多模型协作发现盲点和冲突假设
- 为每个需求定义 Property-Based Testing 属性（关注不变量）
- 无法完全指定约束时，升级回用户而非假设

**执行步骤**：

1. **加载提案**
   - 列出 `.rpi/proposals/` 中的所有提案
   - 让用户选择要细化的提案 ID

2. **多模型模糊性检测**
   - 使用 `minis-model-use` 调用多个模型分析提案：
     * 模型 A（如 GPT-4）："检测提案中未指定的决策点，列出每个：[模糊性] <描述> → [需要的约束] <必须决定什么>"
     * 模型 B（如 Claude）："识别提案中的隐含假设，对每个假设指定：[假设] <描述> → [需要的显式约束] <具体规范>"
   
3. **反模式检测与目标模式**
   - **拒绝的反模式**：
     * 信息收集无决策边界（如"JWT vs OAuth2 vs session—都可行"）
     * 技术对比无选择标准
     * 推迟决策标记为"实现时确定"
   - **要求的目标模式**：
     * 显式技术选择 + 参数（如"JWT，accessToken TTL=15min，refreshToken TTL=7天"）
     * 具体算法选择 + 配置（如"bcrypt，cost factor=12"）
     * 精确行为规则（如"5 次登录失败后锁定账户 30 分钟"）

4. **用户交互解决模糊性**
   - 对任何模糊性使用用户提问，绝不假设或猜测
   - 迭代直到所有模糊性解析为显式约束

5. **提取 PBT 属性**（针对后端逻辑修改）
   - 使用 `minis-model-use` 调用模型提取可测试不变量：
     * "从提案中提取基于属性的测试属性。对每个需求，识别：[不变量] <必须始终成立的数学属性> → [证伪策略] <如何生成试图打破它的测试用例>"
   - **PBT 属性类别**：
     * 交换律/结合律：顺序无关的操作
     * 幂等性：重复操作产生相同结果
     * 往返：编码→解码返回原始值
     * 不变量保持：跨操作维护状态约束
     * 单调性：排序保证（如时间戳总是增加）
     * 边界：值范围、大小限制、速率约束

6. **生成执行计划**
   - 创建 `.rpi/plans/YYYYMMDD-HHMMSS-<proposal-id>.md`
   - 内容结构：
     ```markdown
     # 执行计划：<提案标题>
     
     ## 关联提案
     <提案文件路径>
     
     ## 技术决策（零模糊性）
     ### 技术栈
     - <具体技术 + 版本 + 配置>
     
     ### 算法选择
     - <算法 + 参数>
     
     ### 行为规则
     - <精确规则>
     
     ## 任务流（顺序执行，无决策点）
     1. [任务 1] <描述>
        - 输入：<明确输入>
        - 输出：<明确输出>
        - 验证：<如何验证完成>
     
     2. [任务 2] <描述>
        ...
     
     ## PBT 属性
     ### 属性 1：<名称>
     - 定义：<形式化描述>
     - 不变量：<必须成立的条件>
     - 边界条件：<边缘情况>
     - 证伪策略：<生成反例的方法>
     
     ## 退出标准
     - [ ] 所有多模型分析完成并综合
     - [ ] 零模糊性（经步骤 3 审计验证）
     - [ ] 所有 PBT 属性已记录证伪策略
     - [ ] 用户已明确批准所有约束决策
     ```

**输出**：计划文档路径，提示用户"Plan 阶段完成，建议清空上下文后进入 Implementation 阶段"。

---

### 阶段 3：实现（Implementation）

**目标**：通过多模型协作执行已批准的计划。

**核心原则**：
- 绝不直接应用外部模型原型—所有输出仅作参考，必须重写为生产级代码
- 变更严格限定于请求的结果；应用前审查副作用
- 最小化文档—避免不必要的注释；优先自解释代码

**执行步骤**：

1. **加载计划**
   - 列出 `.rpi/plans/` 中的所有计划
   - 让用户确认要实现的计划 ID

2. **任务迭代执行**
   - 按计划中的任务流顺序执行
   - 对每个任务：
     a. 识别任务类型（前端/UI vs 后端/逻辑）
     b. 选择合适的模型生成原型：
        - **路线 A（前端/UI）**：使用 Gemini/GPT-4（CSS、React、Vue、HTML、组件设计）
        - **路线 B（后端/逻辑）**：使用 Claude/GPT-4（API、数据处理、业务逻辑、调试）
     c. 调用 `minis-model-use` 生成原型（要求返回 unified diff patch 格式）
     d. **绝不直接应用**原型，重写为生产代码：
        - 移除冗余
        - 确保清晰命名和简单结构
        - 对齐项目风格
        - 消除不必要的注释
     e. 应用代码变更
     f. 验证任务完成（根据计划中的验证标准）

3. **多模型代码审查**
   - 每完成一个任务，使用 `minis-model-use` 调用多个模型进行审查：
     * 模型 A："审查以下代码变更，检查：逻辑正确性、边界条件、性能问题、安全漏洞"
     * 模型 B："审查以下代码变更，检查：可读性、可维护性、风格一致性、潜在副作用"
   - 迭代审查直到获得双模型 **LGTM 批准**

4. **上下文监控**
   - 每完成一个任务后，提示用户当前上下文使用情况
   - 若接近 80K，建议用户清空上下文并从步骤 1 继续

5. **记录实现过程**
   - 创建 `.rpi/implementations/YYYYMMDD-HHMMSS-<plan-id>.md`
   - 记录：
     * 已完成的任务
     * 使用的模型
     * 代码变更摘要
     * 审查结果
     * 遇到的问题及解决方案

**输出**：实现记录文档路径，已修改文件列表，提示用户"Implementation 阶段完成，建议进行集成测试"。

---

## 使用示例

### 示例 1：从零生成可视化天气页面

**阶段 0：初始化**
```
用户：使用 RPI 流程帮我开发一个天气页面
AI：[触发 RPI Init]
    - 创建 .rpi/ 目录结构
    - 检测可用模型：gpt-4, claude-3.5-sonnet, gemini-1.5-pro
    - 初始化完成，请描述你的需求
```

**阶段 1：研究**
```
用户：我需要生成一个美观的实时天气展示页面。要求：
     1. 实时天气信息必须为真实信息，包含温度、湿度等
     2. 用户可以选择北京、上海、深圳三个城市
     3. 四种不同的基础天气（大风、降雨、晴天、下雪），有不同的页面展示
     4. UI 设计极具美感，参考苹果公司的顶级前端设计

AI：[触发 RPI Research]
    - 扫描代码库（若有）
    - 识别约束：
      * 硬约束：需要天气 API（OpenWeatherMap/和风天气）
      * 软约束：苹果风格 UI（简洁、毛玻璃、动画流畅）
    - 开放问题：
      Q1: 使用哪个天气 API？（建议：和风天气，国内稳定）
      Q2: 是否需要响应式设计？（建议：是，支持移动端）
      Q3: 是否需要天气动画效果？（建议：是，增强视觉体验）
    - 生成提案：.rpi/proposals/20260419-100000-weather-page.md
    - 建议：清空上下文后进入 Plan 阶段
```

**阶段 2：计划**
```
用户：继续 Plan 阶段
AI：[触发 RPI Plan]
    - 加载提案：20260419-100000-weather-page.md
    - 多模型分析：
      * GPT-4 检测到模糊性：天气图标来源未指定
      * Claude 检测到假设：假设用户有和风天气 API key
    - 用户交互：
      Q: 天气图标使用自定义 SVG 还是图标库？
      A: 使用 Iconify 图标库
      Q: 是否已有和风天气 API key？
      A: 是，已配置环境变量 QWEATHER_API_KEY
    - 技术决策：
      * 前端：React + TailwindCSS + Framer Motion
      * API：和风天气 API v7
      * 图标：Iconify (mdi:weather-*)
      * 动画：Framer Motion，过渡时长 300ms
    - 任务流：
      1. 创建 React 项目结构
      2. 实现天气 API 调用模块
      3. 实现城市选择组件
      4. 实现天气展示组件（四种天气状态）
      5. 实现苹果风格 UI（毛玻璃、圆角、阴影）
      6. 添加动画效果
      7. 响应式适配
    - PBT 属性：
      * 属性 1：API 调用幂等性（相同城市相同时间返回相同数据）
      * 属性 2：温度单位转换往返（摄氏→华氏→摄氏 = 原值）
    - 生成计划：.rpi/plans/20260419-101000-weather-page.md
    - 建议：清空上下文后进入 Implementation 阶段
```

**阶段 3：实现**
```
用户：继续 Implementation 阶段
AI：[触发 RPI Implementation]
    - 加载计划：20260419-101000-weather-page.md
    - 执行任务 1：创建 React 项目结构
      * 使用 Gemini 生成项目模板原型
      * 重写为简洁结构（移除冗余配置）
      * 应用变更
      * GPT-4 审查：LGTM
      * Claude 审查：LGTM
    - 执行任务 2：实现天气 API 调用模块
      * 使用 Claude 生成 API 模块原型
      * 重写为生产代码（添加错误处理、重试逻辑）
      * 应用变更
      * GPT-4 审查：建议添加请求缓存
      * 修改后再审查：LGTM
    - [继续执行剩余任务...]
    - 上下文监控：当前 65K，可继续
    - 所有任务完成
    - 生成实现记录：.rpi/implementations/20260419-103000-weather-page.md
    - 建议：进行集成测试
```

---

## 配置文件格式

`.rpi/config.json`：
```json
{
  "project_name": "项目名称",
  "project_type": "web|mobile|backend|cli",
  "languages": ["javascript", "python"],
  "frameworks": ["react", "fastapi"],
  "codebase_paths": ["./src", "./lib"],
  "available_models": [
    {"id": "gpt-4", "provider": "openai", "use_for": ["logic", "review"]},
    {"id": "claude-3.5-sonnet", "provider": "anthropic", "use_for": ["code", "review"]},
    {"id": "gemini-1.5-pro", "provider": "google", "use_for": ["ui", "creative"]}
  ],
  "context_limit": 80000,
  "created_at": "2026-04-19T10:00:00Z"
}
```

---

## 最佳实践

1. **严格遵循阶段分离**：每阶段完成后清空上下文，避免上下文污染
2. **约束优先于信息**：Research 阶段关注"不能做什么"，而非"可以做什么"
3. **消除所有决策点**：Plan 阶段必须解决所有模糊性，Implementation 不做临场判断
4. **多模型交叉验证**：利用不同模型的视角发现盲点
5. **原型仅供参考**：外部模型生成的代码必须重写，确保质量和风格一致
6. **上下文监控**：定期检查上下文使用量，及时清空避免超限
7. **文档驱动**：所有决策和变更记录在 `.rpi/` 目录，便于追溯和协作

---

## 注意事项

- 本技能适用于**复杂、长期的开发任务**，简单任务无需使用 RPI 流程
- 多模型调用需要配置相应的 API keys（通过 `minis-model-use` 管理）
- `.rpi/` 目录应加入版本控制（Git），便于团队协作
- 上下文清空由用户手动执行（Minis 无 `/clear` 命令），AI 仅提示
- PBT 属性定义后需要手动编写测试代码（本技能不自动生成测试）

---

## 故障排除

**问题 1：`minis-model-use` 调用失败**
- 检查模型配置：`minis-model-use list`
- 确认 API keys 已设置（环境变量或 Minis 配置）

**问题 2：代码库探索耗时过长**
- 使用 `find` 限制搜索深度：`find . -maxdepth 3 -name "*.js"`
- 针对性搜索关键文件，避免全盘扫描

**问题 3：多模型审查意见冲突**
- 优先采纳更保守的建议（安全性、可维护性）
- 必要时向用户说明冲突，由用户决策

**问题 4：上下文超限**
- 立即停止当前任务
- 保存当前进度到实现记录
- 提示用户清空上下文后继续

---

## 参考资源

- 原始项目：https://github.com/GuDaStudio/commands
- RPI 理论：Research-Plan-Implementation 编码理论
- OpenSpec：https://github.com/fission-ai/openspec（本技能未使用，仅作参考）
- Property-Based Testing：https://hypothesis.works/articles/what-is-property-based-testing/