功能规范：多平台 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 生成注意事项

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

用户场景与测试（必填）

核心用户故事

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

验收场景

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

审核与验收清单

无实现层面的语言/框架/接口细节
关注用户价值与业务诉求
面向非技术干系人
必填章节完整

需求完备性

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

执行状态

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

spec.md 7.3 KB Historie Surový