# CursorPro 3.0 - MITM 代理方案计划

> 状态: **规划中** (暂不启动)
> 优先级: 低
> 前置条件: 2.0 稳定运行后再考虑

---

## 一、目标

实现**真正的无感换号** - 请求级别自动切换账号，用户无需重启Cursor

---

## 二、当前方案 (2.0) vs 目标方案 (3.0)

| 特性 | 2.0 (当前) | 3.0 (MITM) |
|-----|-----------|------------|
| 换号方式 | 写Token到本地 | 请求转发 |
| 需要重启 | 是 | 否 |
| 切换粒度 | 会话级别 | 请求级别 |
| 技术难度 | 低 | 高 |
| 用户感知 | 有感 | 无感 |
| 检测风险 | 低 | 中高 |

---

## 三、技术方案

### 方案A: 本地代理 + Hosts劫持

```
┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│  [Cursor] ──→ api2.cursor.sh (被hosts指向127.0.0.1)             │
│      │                                                          │
│      ▼                                                          │
│  [本地代理服务] (127.0.0.1:443)                                  │
│      │                                                          │
│      ├─── 检查当前账号额度                                       │
│      ├─── 选择最优账号                                           │
│      ├─── 替换请求中的Token                                      │
│      │                                                          │
│      ▼                                                          │
│  [真实 api2.cursor.sh]                                          │
│      │                                                          │
│      ▼                                                          │
│  返回结果给 Cursor                                               │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

实现步骤:
1. 开发本地代理服务 (Node.js/Go)
2. 生成自签名CA证书
3. 修改系统hosts文件
4. 用户安装CA证书到系统信任

优点:
- 完全透明，Cursor无需修改
- 请求级别换号

缺点:
- 需要用户安装CA证书 (用户可能不信任)
- 需要管理员权限修改hosts
- HTTPS证书处理复杂
```

### 方案B: Cursor配置修改

```
┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│  修改 Cursor 的 API 端点配置                                     │
│                                                                 │
│  可能的配置位置:                                                 │
│  1. Cursor 安装目录下的配置文件                                  │
│  2. Electron app.asar 中的硬编码                                │
│  3. 环境变量                                                    │
│                                                                 │
│  修改后:                                                        │
│  原: https://api2.cursor.sh                                     │
│  改: https://proxy.ourserver.com                                │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

需要研究:
1. Cursor 是否有配置文件指定 API 地址
2. 是否可以通过环境变量覆盖
3. 修改 app.asar 的可行性

优点:
- 不需要CA证书
- 不需要修改hosts

缺点:
- Cursor 更新后可能失效
- 需要深入研究 Cursor 内部实现
```

### 方案C: 云端代理集群

```
┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│  [用户Cursor] ──→ [我们的云端代理] ──→ [Cursor官方API]           │
│                        │                                        │
│                        ├── 负载均衡                              │
│                        ├── 动态IP池                              │
│                        ├── 账号池管理                            │
│                        └── 请求级换号                            │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

需要:
1. 多台服务器做代理集群
2. 动态住宅IP代理服务
3. 高并发处理能力

优点:
- 集中管理，用户端改动最小
- 可以做更多优化

缺点:
- 服务器成本高
- 延迟增加
- 需要用户配置代理或修改Cursor
```

---

## 四、Cursor API 端点分析 (待研究)

需要劫持的主要端点:

```
# 认证相关
POST https://api2.cursor.sh/auth/...

# AI 对话
POST https://api2.cursor.sh/aiserver.v1.AiService/StreamChat
POST https://api2.cursor.sh/aiserver.v1.AiService/...

# 使用量查询
GET https://api2.cursor.sh/usage/...

# 其他
...
```

研究任务:
1. 抓包分析 Cursor 的所有 API 请求
2. 确定需要劫持的端点列表
3. 分析请求/响应格式
4. 确定 Token 在请求中的位置

---

## 五、风控规避

### Cursor 可能的检测手段

| 检测方式 | 规避方法 |
|---------|---------|
| IP异常 | 使用住宅代理IP池 |
| 设备指纹 | 同步machineId |
| 请求频率 | 限流 + 分散 |
| Token异常 | 模拟正常使用模式 |
| TLS指纹 | 使用标准TLS库 |

### 建议策略

1. **账号隔离**: 一个账号同时只服务一个用户
2. **请求限流**: 单账号请求频率限制
3. **IP绑定**: 账号绑定固定IP段
4. **行为模拟**: 模拟正常用户使用模式

---

## 六、实施阶段

### Phase 1: 研究 (预计2周)
- [ ] 抓包分析 Cursor API
- [ ] 研究 Cursor 配置文件
- [ ] 评估各方案可行性
- [ ] 选定最终方案

### Phase 2: 原型开发 (预计3周)
- [ ] 开发代理服务核心
- [ ] Token 替换逻辑
- [ ] 账号池调度算法
- [ ] 本地测试

### Phase 3: 集成测试 (预计2周)
- [ ] 与现有后端集成
- [ ] 多账号切换测试
- [ ] 性能测试
- [ ] 稳定性测试

### Phase 4: 灰度发布 (预计2周)
- [ ] 小范围用户测试
- [ ] 收集反馈
- [ ] 修复问题
- [ ] 正式发布

---

## 七、成本预估

| 项目 | 预估成本 |
|-----|---------|
| 开发人力 | 2人月 |
| 服务器 (代理集群) | $200-500/月 |
| 动态IP代理 | $100-300/月 |
| 域名+SSL | $50/年 |

---

## 八、风险评估

| 风险 | 等级 | 应对措施 |
|-----|-----|---------|
| Cursor更新导致失效 | 高 | 预留回滚方案 |
| 被Cursor封禁 | 中 | IP池 + 行为模拟 |
| 用户不愿装证书 | 中 | 提供详细教程 |
| 技术难度超预期 | 中 | 阶段性评估 |

---

## 九、决策点

在启动3.0之前需要回答:

1. **是否真的需要?**
   - 2.0 的"重启换号"用户接受度如何？
   - 用户对"无感"的需求有多强烈？

2. **投入产出比?**
   - 开发成本 vs 带来的价值
   - 维护成本 vs 收益

3. **风险是否可控?**
   - Cursor 的封禁风险
   - 法律合规风险

---

## 十、参考资料

待收集:
- Cursor 官方 API 文档 (如有)
- 类似项目实现参考
- MITM 代理开发资料
- 动态IP代理服务商对比

---

> 本文档仅作为技术方案规划，启动前需要团队评审确认。