适用于 Cursor 的 RIPER-5 高级代理约束模式
RIPER-5 是一个社区创建的约束框架，已被证明可以大幅减少 AI 幻觉和未经授权的代码修改。它最初为 Claude 3.7 设计，但在 Cursor 的 Agent 模式下表现异常出色。本指南解释了五个阶段及其实现方法。
什么是 RIPER-5？
RIPER-5 代表：
| 阶段 | 名称 | 目的 |
|---|---|---|
| R | 研究 (Research) | 在不进行更改的情况下收集信息 |
| I | 识别 (Identify) | 精确定位确切的问题或需求 |
| P | 计划 (Plan) | 创建详细、已获批准的计划 |
| E | 执行 (Execute) | 仅实施已批准的计划 |
| R | 审查 (Review) | 验证并测试实施结果 |
五个阶段详解
阶段 1：研究 (R)
规则：只读。不允许修改文件。
操作：
- 读取相关文件
- 使用 Grep 搜索代码库
- 分析现有模式
- 理解依赖关系
输出：带有研究发现的研究摘要
## 研究阶段完成
### 分析的文件
- `src/auth/login.ts` - 当前认证流程
- `src/middleware/auth.ts` - JWT 验证
- `tests/auth.test.ts` - 现有测试
### 主要发现
1. 认证使用 JWT，15 分钟过期
2. 不存在刷新令牌机制
3. 密码重置未实现
4. 测试覆盖登录但不覆盖边缘情况
### 依赖项
- jsonwebtoken: ^9.0.0
- bcrypt: ^5.1.0
阶段 2：识别 (I)
规则：定义确切的问题陈述。
操作：
- 清晰陈述问题
- 定义验收标准
- 识别约束条件
- 注明潜在风险
输出：问题定义文档
## 问题识别
### 问题陈述
用户在 15 分钟后被登出，必须重新认证。
这为长时间会话创造了糟糕的用户体验。
### 根本原因
JWT 令牌在 15 分钟后过期，没有刷新机制。
### 验收标准
- [ ] 用户保持登录状态 7 天
- [ ] 每次使用刷新令牌时轮换
- [ ] 旧的刷新令牌被使无效
- [ ] 用户可以撤销所有会话
### 约束条件
- 必须保持向后兼容
- 不对现有 API 进行破坏性更改
- 必须与现有 JWT 中间件一起工作
### 风险
- 如果刷新令牌被泄露，可能导致令牌被盗
- 需要数据库存储来跟踪令牌
阶段 3：计划 (P)
规则：创建详细的分步计划。
操作：
- 列出所有要修改的文件
- 指定每个文件的确切更改
- 定义测试策略
- 计划回滚程序
输出：详细的实施计划
## 实施计划
### 要修改的文件
#### 1. `src/models/refresh-token.ts` (新建)
```typescript
// 刷新令牌的模式
// 字段：id, userId, token, createdAt, expiresAt, revoked
2. src/services/auth.ts (修改)
- 添加
createRefreshToken()函数 - 添加
rotateRefreshToken()函数 - 添加
revokeAllUserTokens()函数
3. src/routes/auth.ts (修改)
- 添加 POST
/refresh端点 - 添加 POST
/revoke端点
4. src/middleware/auth.ts (修改)
- 更新 JWT 验证以支持更长的会话
测试计划
- 令牌轮换的单元测试
- 刷新流程的集成测试
- 令牌撤销的安全测试
回滚计划
- 移除刷新令牌模型
- 恢复认证服务更改
- 移除新端点
### 阶段 4：执行 (E)
**规则**：仅实施计划中的内容。
**操作**：
- 进行计划好的更改
- 严格遵循计划
- 每个文件完成后报告进度
- 如果计划需要修订则停止
**输出**：带有进度跟踪的实施结果
```markdown
## 执行阶段
### 进度
- [x] 创建了 `src/models/refresh-token.ts`
- [x] 修改了 `src/services/auth.ts`
- [ ] 修改 `src/routes/auth.ts` (进行中)
- [ ] 更新 `src/middleware/auth.ts`
### 已做的更改
1. 添加了带有字段的 RefreshToken 模型
2. 实现了令牌轮换逻辑
3. 添加了撤销支持
### 下一步
- 添加刷新端点
- 更新中间件
阶段 5：审查 (R)
规则：验证一切是否按计划工作。
操作：
- 运行所有测试
- 检查回归问题
- 验证验收标准
- 记录任何偏差
输出：审查报告
## 审查阶段
### 测试
- [x] 单元测试通过 (15/15)
- [x] 集成测试通过 (8/8)
- [x] 安全测试通过 (5/5)
### 验收标准
- [x] 用户保持登录状态 7 天
- [x] 每次使用刷新令牌时轮换
- [x] 旧的刷新令牌被使无效
- [x] 用户可以撤销所有会话
### 回归
- 未检测到
### 与计划的偏差
- 添加了令牌清理定时任务 (不在原始计划中)
- 原因：防止过期令牌导致数据库膨胀
在 Cursor 中设置 RIPER-5
步骤 1：创建规则文件
创建 .cursor/rules/riper5-mode.mdc：
---
description: 'RIPER-5 高级约束模式'
globs: ['**/*']
alwaysApply: true
---
# RIPER-5 模式
您必须对所有任务遵循 RIPER-5 工作流。
## 阶段顺序
1. **研究** - 仅读取和分析
2. **识别** - 定义问题
3. **计划** - 创建详细计划
4. **执行** - 仅实施计划
5. **审查** - 验证和测 试
## 阶段规则
### 研究阶段
- 仅使用 Read、Grep、Search 工具
- 不修改文件
- 不生成代码
- 以结构化格式呈现发现
### 识别阶段
- 清晰陈述问题
- 定义验收标准
- 列出约束条件
- 识别风险
### 计划阶段
- 列出所有要修改的文件
- 显示每个文件的确切更改
- 包括测试策略
- 包括回滚计划
- 等待用户批准
### 执行阶段
- 仅实施计划好的更改
- 每个文件完成后报告
- 如果卡住则请求澄清
- 不进行计划外的修改
### 审查阶段
- 运行所有测试
- 验证验收标准
- 检查回归问题
- 记录偏差
## 关键
- 绝不跳过阶段
- 绝不在研究阶段修改文件
- 绝不在执行阶段添加计划外的更改
- 在执行阶段之前始终获得批准
步骤 2：添加到系统提示词
在 Cursor 设置中：
## RIPER-5 工作流
对于每个任务，您必须遵循以下 5 个阶段：
1. **研究**：读取和分析，不做更改
2. **识别**：定义确切的问题
3. **计划**：创建详细的实施计划
4. **执行**：仅实施已批准的计划
5. **审查**：验证一切是否正常工作
您不能在未完成当前阶段的情况下进入下一阶段。
您不能在研究或识别阶段修改文件。
您不能在执行阶段添加计划外的更改。
步骤 3：用简单任务练习
从一个小任务开始熟悉：
[任务] 添加一个用于格式化日期的实用函数。
遵循 RIPER-5：
1. 研究现有的日期处理
2. 识别需要什么
3. 计划实施
4. 在我批准后执行
5. 审查结果
高级：带检查点的 RIPER-5
Git 集成
# 开始前（研究阶段）
git checkout -b feature/riper5-task
git commit -m "checkpoint: before RIPER-5 implementation"
# 研究阶段后
git add research-notes.md
git commit -m "riper5: research complete"
# 计划阶段后（批准前）
git add plan.md
git commit -m "riper5: plan created, awaiting approval"
# 执行阶段后
git add -A
git commit -m "riper5: implementation complete"
# 审查阶段后
git commit -m "riper5: review passed, tests green"
衡量有效性
跟踪这些指标：
| 指标 | 使用 RIPER-5 前 | 使用 RIPER-5 后 |
|---|---|---|
| 未经授权的更改 | 高 | 接近零 |
| 计划批准率 | 不适用 | >90% |
| 更改后的测试通过率 | 60% | 95% |
| 回滚频率 | 高 | 低 |
| 用户满意度 | 混合 | 高 |
常见挑战
| 挑战 | 解决方案 |
|---|---|
| 代理跳过阶段 | 用严格规则强制执行 |
| 计划过于宽泛 | 要求文件级别的特异性 |
| 审查流于表面 | 强制要求执行测试 |
| 减慢简单任务 | 允许对琐碎更改使用快捷方式 |
快速参考
[RIPER-5 开始]
阶段 1/5：研究
[代理读取和分析]
阶段 2/5：识别
[代理定义问题]
阶段 3/5：计划
[代理创建计划]
[用户：批准或修改]
阶段 4/5：执行
[代理实施]
阶段 5/5：审查
[代理验证]
[RIPER-5 完成]