修订总览（Revision Summary）
本次修订目标
为实现最快MVP上线目标，对整套中文PRD文档进行系统性架构重构。核心目标是明确两域拆分（账本与交易处理域 vs 风控与安全域）、强化对赌而非撮合的设计纯粹性、优化双账户隔离策略、加强风险对冲作为Phase 2关键交付件的地位，并新增落地执行相关的制度性文档（开发计划、上线手册、验收清单）。
核心架构变更
| 维度 |
修订前 |
修订后 |
影响范围 |
| 域拆分 |
未明确 |
账本交易域 + 风控安全域 |
所有模块 |
| 对冲引擎阶段 |
Phase 3 |
Phase 2（关键交付） |
L6、Phase计划、新增07a |
| 术语系统 |
混用”撮合”与”对赌” |
“撮合”全部移除，统一”对赌” |
01/02/04/06/07a等 |
| HL账户模型 |
单账户（交易+对冲混合） |
双账户：Trading + Hedge |
L4、L5、07a、基础设施 |
| 新增文档 |
无 |
07a(对冲架构)、13(域架构)、14(成本收益)、15(开发计划)、16(上线手册)、17(验收) |
总文档数从12→17 |
按模块修订清单
| 文件 |
修订类型 |
关键变更点 |
| 01-overview.md |
补充 |
Phase表更新（L6移入Phase 2）；撮合引擎排除声明加强；MVP边界明确化 |
| 02-routing.md |
补充 |
MVP路由限制说明（灰度期仅HL_MODE/NORMAL_MODE）；三模式路由细化；域归属标记 |
| 03-account-assets.md |
补充 |
域归属标记（账本交易域）；账户结构与HL映射关系 |
| 04-internal-execution.md |
补充 |
域归属（账本交易域）；术语修正（撮合→对赌）；与风控域接口契约及失败处理流程 |
| 05-hl-execution.md |
补充 |
大额拆单策略明确为Phase 4（MVP不交付）；双账户适配说明（Trading vs Hedge）；填单优化 |
| 06-margin-liquidation.md |
补充 |
清算编排由风控域触发，账本域执行；跨域接口契约定义；保证金模型细化 |
| 07-risk-management.md |
重写 |
Phase改为2（不再是3）；域归属为风控安全域；L3与L6职责边界清晰化；自然对冲概念；对冲分期策略 |
| 07a-hedge-architecture.md |
新增 |
双账户隔离设计；杠杆阶梯策略；预对冲评估机制；6个边缘场景处理 |
| 08-market-data.md |
无变更 |
保持原样 |
| 09-settlement.md |
补充 |
域归属（账本交易域）；对账引擎与风控域的接口 |
| 10-withdrawal-liquidity.md |
无变更 |
保持原样 |
| 11-admin.md |
补充 |
路由模式三按钮（HL_MODE/NORMAL_MODE/BETTING_MODE）；对冲账户监控面板；权限与风控关系 |
| 12-infrastructure.md |
补充 |
双账户相关表结构；域间消息队列设计；事件溯源架构 |
| 13-domain-architecture.md |
新增 |
两域拆分定义（概念、职责、边界）；六大接口契约；一致性策略；调用规则 |
| 14-cost-revenue.md |
新增 |
成本最小化策略（HL费用优化、对冲策略选择）；收益最大化机制（利差、风险准备金分配） |
| 15-dev-plan.md |
新增 |
多团队并行计划（小时制细度）；Phase 1/2/3关键路径；上线前完成度检查 |
| 16-launch-rollback.md |
新增 |
灰度方案（百分比递增、限额递增）；回滚触发条件与流程；应急手册 |
| 17-acceptance.md |
新增 |
验收清单（功能、性能、风险三维）；Phase分层验收标准；上线签字 |
| scenarios/05-risk-hedge.md |
新增 |
风控与对冲场景（8个：净敞口变化、跨阈值、多币种、杠杆变化等） |
| scenarios/06-edge-cases.md |
新增 |
边缘与异常场景（12个：清算失败、对冲延迟、价格跳跃、网络分区等） |
MVP / Post-MVP 边界总览
| 范畴 |
MVP必须做 |
Phase 3交付 |
Phase 4/Post-MVP |
| 账户体系 |
✓ 用户账户、资产、多链流入 |
✓ 保证金隔离/全仓模型 |
分级与信用额度 |
| 订单处理 |
✓ 路由决策 |
✓ 对赌执行 |
大额拆单 |
| 执行通道 |
✓ HL API中继 |
✓ 对赌内部匹配 |
跨阈值路由优化 |
| 市场数据 |
✓ HL WebSocket中继 |
✓ 标记价格本地计算 |
行情衍生指标 |
| 风险控制 |
✓ 净敞口监控、基础对冲 |
✓ 统一清算、偏差兜底 |
预对冲、策略优化 |
| 清算系统 |
✓ HL订单触发 |
✓ 两域联动、保证金结算 |
智能清算 |
| 风险准备金 |
✓ 基础累积与监控 |
风险评估与分配 |
动态调整 |
| 后台管理 |
✓ 基础账户查询、权限 |
✓ 路由/对冲/风险可视化 |
高级策略配置 |
文档使用指南
优先级阅读顺序
- 本文（00）— 修订总览，快速掌握全局变化
- 01-architecture-baseline.md（新增）— 统一架构基线，理解两域与接口
- 01-overview.md — 平台设计与Phase总览
- 02-routing.md → 03-account-assets.md → 04-internal-execution.md — 下单链路
- 05-hl-execution.md → 06-margin-liquidation.md — 大单与清算
- 07-risk-management.md → 07a-hedge-architecture.md — 对冲与风控（Phase 2核心）
- 08-market-data.md → 09-settlement.md → 10-withdrawal-liquidity.md — 支撑系统
- 11-admin.md → 12-infrastructure.md — 后台与技术基础
- 13-domain-architecture.md — 深度域设计（开发必读）
- 14-cost-revenue.md — 商业目标
- 15-dev-plan.md → 16-launch-rollback.md → 17-acceptance.md — 执行路线图
不同角色使用地图
| 角色 |
必读文档 |
参考文档 |
| 产品经理 |
00, 01, 01(arch), 02, 04, 07, 14 |
03, 05, 06, 11 |
| 后端开发 |
01(arch), 13, 04, 05, 06, 07a, 12, 15 |
02, 03, 08, 09, 11 |
| 风控工程师 |
07, 07a, 06, 11, 13 |
01, 02, 12 |
| 测试/QA |
17, 16, scenarios/*, 15 |
01, 04, 05, 06 |
| 运维/DevOps |
12, 16, 15 |
01, 11 |
关键决策回顾
为什么是”方案二”而非”方案三”？
- 方案二（内部对赌 + 阈值对冲）：平台是所有小单的唯一对手方，大单转发HL
- MVP可闭环：不需要撮合引擎，代码量最小，上线最快
- 风险单一：平台直接承担对手方风险，通过对冲和准备金控制
- 盈利清晰：利差 + 风险准备金 = 收入
- 方案三（用户间撮合）：用户订单相互匹配，平台仅做市
- 需要完整撮合引擎：开发周期长，复杂度高
- 风险分散：平台风险较低，但流动性风险高
- 此版本 明确不包含
为什么对冲要从Phase 3提前到Phase 2？
净敞口是风险最大化的时刻。如果等到Phase 3再对冲，Phase 2上线后可能发生灾难性亏损。对冲引擎必须与路由引擎同步上线。
为什么是两域而非单域？
单域架构下，账本修改和风控检查容易形成循环依赖，且测试困难。两域通过事件总线异步通信，解耦清晰，每域可独立升级。
版本信息
| 项 |
值 |
| 修订日期 |
2026-04-09 |
| 修订版本 |
v1.1-MVPFocus |
| 适用范围 |
Platform Perpetual Futures Trading Engine MVP |
| 审核状态 |
待产品/技术联合审核 |
| 下一步 |
启动15-dev-plan并行工作流 |