# 功能规范：多平台 Delta 中性控制平面

**功能分支**：`[###-delta-neutral-control-plane]`  
**创建日期**：2025-09-27  
**状态**：草稿  
**输入**：用户描述：“为了防止女巫，所有的账户内带权限的交互（下单/user data查询信息等交互都要通过 proxy，所有高频的信息都用 ws fresh，账户的资金利用率不得低于 50% 不得高于 80%（触发平仓开仓），保证 Delta 中性（敞口大小和开仓价格），保持 50% 左右资金的Delta 中性持仓 ，主要的持有仓位 带有对等方向的止盈止损，尽可能的使用 limit 单来保障有盈利机会，同时保证尽可能多的开仓和交易量，能对多个平台/多账户 自动分配方向达到整体的 Delta 中性，基础框架通用性好能方便切换更多的策略（ 比如 往后可能会有的做市型开单策略，资金费率套利型开单策略），可宽展性好，可以不断加入新的 exchanges，账户管理方便，可以根据不同规范加入更多的账户”

## 执行流程（main）
```
1. 解析 Input 中的用户描述
   → 若为空：报错 “No feature description provided”
2. 从描述中提取关键概念
   → 识别：参与角色、关键操作、数据、约束
3. 对每个不清晰点：
   → 使用 [NEEDS CLARIFICATION: 具体问题] 标记
4. 补全“用户场景与测试”章节
   → 若无法识别明确流程：报错 “Cannot determine user scenarios”
5. 生成功能需求
   → 每条需求必须可测试
   → 含糊需求需标记
6. 若涉及数据：识别关键实体
7. 执行“Review Checklist”
   → 若存在 [NEEDS CLARIFICATION]：警告 “Spec has uncertainties”
   → 若出现实现细节：报错 “Remove tech details”
8. 输出成功，说明规范可进入规划阶段
```

---

## ⚡ 编写指引
- ✅ 聚焦用户价值与业务目标  
- ❌ 避免实现细节（语言、框架、API）  
- 👥 面向业务干系人而非开发者  

### 章节要求
- **必填章节**：每个功能都必须完成  
- **可选章节**：仅在相关时保留  
- 若不适用，请删除整段，不留 “N/A”

### AI 生成注意事项
1. **标记所有疑问**：使用 [NEEDS CLARIFICATION: …]
2. **不要猜测**：缺少信息时必须标注  
3. **以测试视角思考**：每条需求要可验证  
4. 常见缺失信息：
   - 用户类型与权限
   - 数据保留与删除策略
   - 性能目标与规模
   - 错误处理模式
   - 外部集成要求
   - 安全 / 合规假设

---

## 用户场景与测试（必填）

### 核心用户故事
多平台对冲控制器在多个交易所、多个账户之间维护整体 Delta 接近零，并保证每个账户的资金利用率稳定在 50%-80% 之间；即便高频策略持续发出限价单以提升真实成交量，也能在手续费后保持盈利。

### 验收场景
1. **给定** pacifica-1/2 与 aster-1 账户利用率降到 50% 以下，**当** 控制器评估敞口时，**则** 会通过代理发起限价单，将利用率恢复到约 50%，同时保持整体 Delta 在 ±0.0005 BTC 等值内。  
2. **给定** binance 与 pacifica 的订单簿通过 WebSocket 正常刷新，**当** pacifica 数据陈旧超过 2 秒时，**则** 系统必须切换到 HTTP 深度、发出告警，并在数据恢复之前暂停新交易。  
3. **给定** 部分成交导致 Delta 失衡，**当** 控制平面执行再平衡时，**则** 会跨可用交易所/账户路由对冲订单，重新拉回 Delta 中性，并重新设置成对止损/止盈。  
4. **给定** 新策略模块（做市、资金费率套利）接入，**当** 它们申请账户配额时，**则** 框架会在利用率、代理路由、现有对冲承诺之间自动分配，保证不中断。  
5. **给定** 主行情源突然失效，**当** 备用行情在 10 秒内完成切换时，**则** 交易可恢复且继续维持 Delta 中性与风险控制。

### 边界与异常
- 行情数据过期或不可用时的处理策略。  
- 流动性不足、代理链路故障、部分成交的处理方式。  
- 交易所停机或账户冻结期间如何维持 Delta 中性。  
- 限价单长时间未成交的应对流程。  
- 主行情源在 10 秒内无法完成切换的应急策略。

## 功能需求（必填）

### 功能性需求
- **FR-001**：系统必须让整体 Delta 在各交易所之间保持接近 0，满足预设阈值。  
- **FR-002**：所有带权限的 API 调用（下单、余额/仓位查询等）必须经过授权代理；高速行情必须首选 WebSocket。  
- **FR-003**：系统必须执行对冲、再平衡与刷量策略，并在可能情况下优先使用限价单确保手续费后仍有正收益；若必要可自动降级至其他执行方式。  
- **FR-004**：系统必须将每个账户的资金利用率维持在 50%-80%；利用率定义为（账户总余额 − 可用余额）÷ 账户总余额，一旦越界必须立即触发再平衡。  
- **FR-005**：核心持仓必须配置成对止损/止盈，以保护资金同时维持成交量。  
- **FR-006**：系统必须输出结构化日志与指标，覆盖代理状态、订单生命周期、敞口状态、健康事件以及与利用率/Delta 相关的合规检查。  
- **FR-007**：系统必须支持可插拔策略模块，为账户分配、信号接入、执行守护提供统一接口。  
- **FR-008**：系统必须允许快速接入新交易所与新账户，支持按账户配置代理与合规规则。  
- **FR-009**：系统必须在启用新策略前提供自动化的 Dry-run 与集成测试，证明 Delta 中性、代理路由、手续费后盈利的可行性。  
- **FR-010**：上述行为必须由自动化测试覆盖，包括仿真、集成、回退场景。  
- **FR-011**：当主行情源失效时，系统必须在 10 秒内切换到经过验证的备用行情或可合成价格，再恢复交易。

### 关键实体
- **ExchangeAccount**：存储凭证、代理配置、利用率目标、敞口限制、止损/止盈模板。  
- **OrderIntent**：描述限价/市价意图、目标账户、对冲配对、预期手续费后收益以及回退规则。  
- **MarketDataFeed**：追踪 WebSocket/HTTP 数据源、新鲜度、回退状态、告警信息。  
- **StrategyModule**：抽象新交易/对冲策略，提供分配、执行、合规校验的钩子。  
- **RiskEnvelope**：定义账户级限制、Delta 容忍度、利用率边界以及补救时限。

---

## Clarifications

### Session 2025-09-27
- Q: 为了落实 50%-80% 的资金利用率约束，请确认“资金利用率”的具体计算方式 → A: (账户总余额 − 可用余额) ÷ 账户总余额
- Q: 为制定数据源失效时的恢复策略，请确认系统在主行情源失效后可以暂停交易的最长容忍时间 → A: 最长 10 秒内完成切换

## 审核与验收清单
- [x] 无实现层面的语言/框架/接口细节  
- [x] 关注用户价值与业务诉求  
- [x] 面向非技术干系人  
- [x] 必填章节完整

### 需求完备性
- [x] 不存在 [NEEDS CLARIFICATION] 标记  
- [x] 需求具备可测试性与可度量性  
- [x] 验收标准清晰可界定  
- [x] 范围界定明确  
- [x] 依赖与假设已识别

---

## 执行状态
- [x] 用户描述已解析  
- [x] 关键概念已提取  
- [x] 未残留模糊标记  
- [x] 用户场景已定义  
- [x] 功能需求已写就  
- [x] 关键实体已确定  
- [x] 审核清单全部通过