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）：

     {
       "module_name": "探索的上下文边界",
       "existing_structures": ["发现的关键结构/模式"],
       "existing_conventions": ["使用中的约定/标准"],
       "constraints_discovered": ["限制解决方案空间的硬约束"],
       "open_questions": ["需要用户输入的模糊点"],
       "dependencies": ["对其他模块/系统的依赖"],
       "risks": ["潜在风险或阻塞点"],
       "success_criteria_hints": ["指示成功的可观察行为"]
     }
     

4. 聚合与综合

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

5. 用户交互消除模糊性

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

6. 生成提案文档

   • 创建 .rpi/proposals/YYYYMMDD-HHMMSS-<title>.md
   • 内容结构：

     # 提案：<标题>
     
     ## 用户需求（原始）
     <用户的完整需求描述，不得缩写>
     
     ## 约束集
     ### 硬约束
     - <技术限制>
     
     ### 软约束
     - <约定/偏好>
     
     ### 依赖关系
     - <跨模块依赖>
     
     ## 开放问题（已解决）
     - 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
   • 内容结构：

     # 执行计划：<提案标题>
     
     ## 关联提案
     <提案文件路径>
     
     ## 技术决策（零模糊性）
     ### 技术栈
     - <具体技术 + 版本 + 配置>
     
     ### 算法选择
     - <算法 + 参数>
     
     ### 行为规则
     - <精确规则>
     
     ## 任务流（顺序执行，无决策点）
     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：

{
  "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/