binance-api/specs/001-specManager-perp/plan.md

实施计划：多平台 Delta 中性控制平面

分支：001-specManager-perp | 日期：2025-09-27 | 规范：spec.md
输入：/specs/001-specManager-perp/spec.md

执行流程（/plan 命令作用范围）

1. 从 Input 路径加载功能规范
2. 填写技术背景（扫描 NEEDS CLARIFICATION）
3. 根据宪章完成 Constitution Check（原则 I–V、运营约束、流程质量门槛、治理）
4. 评估 Constitution Check，若违例则记录与解释
5. 执行 Phase 0 → research.md（记录行情数据源、敞口目标、风险约束）
6. 执行 Phase 1 → contracts、data-model.md、quickstart.md、agent 文件
7. 再次评估 Constitution Check 并更新进度
8. 规划 Phase 2（说明任务生成策略，不实际创建 tasks.md）
9. 停止，准备执行 /tasks

重要提示：/plan 在步骤 7 停止；Phase 2 之后由 /tasks 以及实施阶段完成。

总结

• 构建一个可扩展的多交易所多账户控盘层，自动保持整体 Delta 中性，并让单账户资金利用率维持 50%-80%。
  
• 所有高频行情使用 WebSocket 实时刷新，主源失效 10 秒内必须切换备用；所有带权限的交互经代理执行。
  
• 框架需支持限价优先、对冲、资金费率套利、做市等策略模块，配套结构化观测与自动化测试保障。

技术背景

语言/版本：TypeScript 5.1 / Node.js 18.12
主要依赖：ws、axios、dotenv、winston、jest、tsx、https-proxy-agent、redis、sequelize 等
存储：当前以内存状态与外部交易所为主，无持久化数据库约束
测试框架：jest（含 ts-jest）、集成测试脚本
目标平台：Linux/容器化运行环境，需支持代理网络
项目类型：单一后端项目（多模块架构）
性能目标：行情刷新 <2s、控制循环 ≤8s、主源失效 ≤10s 完成回退
约束条件：所有敏感调用走代理；资金利用率 50%-80%；Delta 容忍 ±0.0005 BTC；止损路径 ≤30s；日志保留 ≥90 天
规模/范围：同时管理 ≥3 个交易所账户，支持新增策略模块与交易所扩展

宪章核对（Constitution Check）

• 原则 I：Delta-Neutral First —— 计划中所有策略均以内外账户 Delta 为核心监控，设定再平衡与对冲流程，状态 PASS。
  
• 原则 II：Deterministic Market Data Intake —— 行情层采用 WebSocket+HTTP 回退，明确 2s 新鲜度与 10s failover SLA，状态 PASS。
  
• 原则 III：Capital Protection & Risk Controls —— 监控资金利用率、止损、利用率越界触发回滚；30s 内完成紧急对冲，状态 PASS。
  
• 原则 IV：Transparent Observability & Audit —— 设计阶段将补充统一日志、指标、健康检查与事件追踪，状态 PASS。
  
• 原则 V：Tested Execution Paths —— 在计划中安排 Dry-run、双账户集成测试、回退场景测试，状态 PASS。
  
• 运营约束：≤8s 循环、代理网络、密钥轮换、日志保留要求已纳入研究与实施任务。
  
• 流程质量门槛：plan/research/data-model/quickstart 均需映射宪章要点；PR 需附带日志或测试佐证。
  
• 治理要求：遵循 SemVer 及每月合规复核；本计划中为后续 /tasks 与 PR 审查提供依据。
  → 评估结果：PASS

项目结构

文档（本功能）

specs/001-specManager-perp/
├── plan.md
├── research.md
├── data-model.md
├── quickstart.md
├── contracts/
└── tasks.md   # 将由 /tasks 生成

源码目录（仓库根目录）

src/
├── exchanges/
│   ├── pacifica/
│   ├── aster/
│   └── binance/
├── modules/
│   ├── trading/
│   ├── hedging/
│   ├── orderbook/
│   ├── account/
│   ├── risk/
│   └── dashboard/
├── core/
│   └── hedging/
├── utils/
└── main-modular.ts

tests/
├── integration/
├── unit/
└── fixtures/

结构决策：维持单体后端结构，围绕 src/modules 提供新的控制器、风险监控、策略插件，并扩展 tests/ 下的集成测试套件。

Phase 0：概述与调研

1. 调研需求：
   • 多交易所行情 failover 设计（WebSocket → HTTP → 合成价格）
   • 资金利用率 50%-80% 的算法与阈值配置
     
   • 跨账户风险指标、Delta 阈值与自动对冲策略
     
   • 代理路由、凭证隔离与网络延迟监控
     
   • 可插拔策略模块的接口约定与沙箱验证方式
     
2. 调研任务输出：详见 research.md，记录决策、理由与备选方案。

产出：research.md

Phase 1：设计与契约

1. 从规范提取实体 → data-model.md（账户、策略模块、行情源、风险包络、订单意图等）。
   
2. 依据功能需求设计 API/事件契约 → contracts/（账户状态同步、对冲指令、行情事件、告警）。
   
3. 为每个契约生成失败态测试用例 → /tests/contract/（列于计划，实际实现待 Phase 3）。
   
4. 从用户故事与边界情况提炼 quickstart 场景 → quickstart.md，覆盖利用率越界、行情 failover、Delta 再平衡。
   
5. 更新 CLAUDE.md 等 agent 文件，确保新增技术与步骤被记录。

产出：data-model.md、contracts/、quickstart.md

Phase 2：任务规划方法

• /tasks 将以 Phase 1 文档为输入，生成测试先行的任务列表。
  
• 分类：环境与代理配置、Dry-run 仿真、对冲引擎、行情服务、风险/观测、回退测试等。
  
• 排序：按 TDD 顺序、依赖链（行情 → 风险 → 执行 → 策略模块）。
  
• 标记 [P] 以指示可并行的互不影响任务。
  
• 目标输出：25-30 个编号任务，覆盖执行、观测、合规。

Phase 3+：后续实施

• Phase 3：执行 /tasks，生成 tasks.md 并指派。
  
• Phase 4：按任务实现，保持 Delta/风险合规。
  
• Phase 5：运行测试、quickstart、性能与回退验证。

复杂度追踪

违例	原因	被否决的简单方案
（无）

进度追踪

阶段状态：

• Phase 0：调研完成 (/plan)
• Phase 1：设计完成 (/plan)
• Phase 2：任务规划完成 (/plan，仅描述方法)
• Phase 3：任务已生成 (/tasks)
• Phase 4：实现完成
• Phase 5：验证通过

关卡状态：

• 初次宪章核对：通过
• 设计后宪章核对：通过
• 所有 NEEDS CLARIFICATION 已解决
• 复杂度偏差已记录

---

基于宪章 v1.0.0 - 详见 /memory/constitution.md