Back to Details

rpi

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

RPI

RPI

概览

Overview

  • 使用四阶段流程：
    调研 -> 计划 -> 实施 -> 迭代
    。
  • 严格保持阶段边界：调研/计划阶段不改代码，实现阶段必须验证。
  • 每阶段产出结构化结果，确保下一阶段可以直接复用。
  • Uses a four-phase process: 
    Research -> Plan -> Implement -> Iterate
    .
  • Strictly maintain phase boundaries: No code modification during Research/Plan phases, verification is mandatory during the Implementation phase.
  • Produce structured results at each stage to ensure direct reuse in the next phase.

使用方式

Usage

在同一会话中按阶段推进：
  1. 进入 
    调研
    ，只收集事实和约束。
  2. 进入 
    计划
    ，输出可审核执行计划。
  3. 计划确认后进入 
    实施
    ，执行改动并验证。
  4. 完成实施后进入 
    迭代
    ，复盘并给出改进优先级。
Advance phase by phase in the same session:
  1. Enter the 
    Research
    phase, only collect facts and constraints.
  2. Enter the 
    Plan
    phase, output a reviewable execution plan.
  3. After the plan is confirmed, enter the 
    Implement
    phase, execute changes and verify.
  4. After implementation is completed, enter the 
    Iterate
    phase, conduct a retrospective and define improvement priorities.

工作流决策

Workflow Decision-Making

  1. 需求不清晰或上下文不足时，先做 
    调研
    。
  2. 关键事实明确后，做 
    计划
    并等待确认。
  3. 计划确认后，执行 
    实施
    。
  4. 实施完成后，执行 
    迭代
    。
  5. 出现关键前提变化时，回退到 
    调研
    或 
    计划
    。
  1. When requirements are unclear or context is insufficient, start with 
    Research
    .
  2. After key facts are clarified, create a 
    Plan
    and wait for confirmation.
  3. After the plan is confirmed, execute 
    Implementation
    .
  4. After implementation is completed, execute 
    Iteration
    .
  5. When key prerequisites change, roll back to the 
    Research
    or 
    Plan
    phase.

阶段规范

Phase Specifications

1) 调研

1) Research

目标：建立可信上下文，不改代码。
动作：
  • 明确问题定义、成功标准、约束边界。
  • 识别相关代码、依赖、配置与现有模式。
  • 区分事实、假设、未知项。
  • 提炼进入计划阶段的决策信息。
输出结构：
  1. 概要
  2. 关键发现
  3. 上下文
  4. 待确认问题
  5. 建议
Objective: Establish credible context, no code modification.
Actions:
  • Clarify problem definition, success criteria, and constraint boundaries.
  • Identify relevant code, dependencies, configurations, and existing patterns.
  • Distinguish between facts, assumptions, and unknowns.
  • Extract decision-making information for entering the Plan phase.
Output Structure:
  1. Summary
  2. Key Findings
  3. Context
  4. Pending Confirmations
  5. Recommendations

2) 计划

2) Plan

目标：形成可执行、可验证、可审阅的计划，不改代码。
动作：
  • 基于已确认事实拆解步骤。
  • 标注受影响文件、风险、回滚思路。
  • 定义验证方案与完成标准。
  • 等待确认后再进入实施阶段。
输出结构：
  1. 目标
  2. 前提假设
  3. 范围与涉及文件
  4. 执行步骤
  5. 风险与缓解
  6. 验证方案
Objective: Form an executable, verifiable, reviewable plan, no code modification.
Actions:
  • Break down steps based on confirmed facts.
  • Mark affected files, risks, and rollback ideas.
  • Define verification schemes and completion criteria.
  • Wait for confirmation before entering the Implementation phase.
Output Structure:
  1. Objectives
  2. Prerequisites & Assumptions
  3. Scope & Involved Files
  4. Execution Steps
  5. Risks & Mitigation
  6. Verification Scheme

3) 实施

3) Implement

目标：按计划实施改动并持续验证。
动作：
  • 按步骤实施，控制改动范围。
  • 每批改动后立即验证（测试、lint、type-check、功能检查）。
  • 偏离计划时先说明原因并更新计划。
  • 记录进度与剩余工作。
输出结构：
  1. 已完成改动
  2. 验证结果
  3. 偏离说明
  4. 剩余工作
Objective: Execute changes according to the plan and conduct continuous verification.
Actions:
  • Implement step by step, control the scope of changes.
  • Verify immediately after each batch of changes (testing, lint, type-check, function check).
  • When deviating from the plan, first explain the reason and update the plan.
  • Record progress and remaining work.
Output Structure:
  1. Completed Changes
  2. Verification Results
  3. Deviation Explanation
  4. Remaining Work

4) 迭代

4) Iterate

目标：系统复盘并定义下一轮优化。
动作：
  • 评估正确性、健壮性、可维护性与可观测性。
  • 检查边界条件、失败路径、性能与安全风险。
  • 识别测试缺口和技术债。
  • 输出按优先级排序的改进项。
输出结构：
  1. 优点
  2. 问题
  3. 边界情况与缺口
  4. 优先级改进项
Objective: Conduct a systematic retrospective and define the next round of optimizations.
Actions:
  • Evaluate correctness, robustness, maintainability, and observability.
  • Check boundary conditions, failure paths, performance, and security risks.
  • Identify test gaps and technical debt.
  • Output prioritized improvement items.
Output Structure:
  1. Strengths
  2. Issues
  3. Boundary Cases & Gaps
  4. Prioritized Improvement Items

质量门禁

Quality Gates

  • 在 
    调研
    与 
    计划
    阶段禁止直接改代码。
  • 在 
    实施
    阶段禁止跳过验证直接宣告完成。
  • 在 
    迭代
    阶段禁止只给结论，必须给可执行改进项。
  • 每阶段结束必须输出结构化结果。
  • Direct code modification is prohibited during the 
    Research
    and 
    Plan
    phases.
  • Skipping verification and directly declaring completion is prohibited during the 
    Implement
    phase.
  • Only giving conclusions without executable improvement items is prohibited during the 
    Iterate
    phase.
  • A structured result must be output at the end of each phase.

参考

References

  • 读取 
    references/rpi-playbook.md
    获取详细检查清单与提示词模板。
  • Read 
    references/rpi-playbook.md
    for detailed checklists and prompt templates.