Product Requirements Document

加密货币自动化分析交易系统
产品说明文档 v1.0

版本 v1.0 状态 进行中 负责人 郭小威 更新 2026-05-27
项目简介

本系统可根据用户配置，持续跟踪多个加密货币交易对的行情，自动判断趋势方向、识别关键支撑阻力区间。当价格触及关键位出现入场信号且满足条件时，自动生成并执行完整交易计划，追踪持仓状态，平仓后归档交易记录，持续复盘优化决策。

核心功能

一个完整的交易系统包含以下几步，每步按顺序判断与执行。

#功能说明
01自动监控行情按用户配置的交易对、趋势周期和交易周期，在每根 K 线收盘后自动调用交易所接口拉取最新 OHLCV 数据，更新缓存，持续为后续分析提供最新行情。
02判断趋势方向运行配置的趋势分析算法（裸K / 均线（EMA组/Vegas隧道）/ 趋势线 / 形态），基于趋势周期的 K 线窗口数据，判断当前处于涨势、跌势还是震荡，为后续信号筛选确立方向基准。
03识别关键位扫描趋势和交易两个周期的 K 线，运行配置的关键位识别算法（水平 / 形态 / 特定价格），找出 K 线窗口数据内价格多次有反应的支撑/阻力区间，标注触碰次数。
04发现入场信号每根交易周期 K 线收盘后，检测价格是否进入关键区间，根据配置的做单方向（顺势/逆势）、信号识别算法（金K/形态/均线）、趋势方向，找出符合条件的入场信号。
05制定交易计划根据信号确定入场价，按策略寻找止盈目标和止损位，计算盈亏比需达到最小阈值才继续生成，不达标则丢弃。仓位也根据配置在这里计算，最终输出完整交易计划。
06执行交易计划程序根据交易计划内容去开仓，开仓后持续追踪持仓状态，记录实际入场/出场价格和盈亏结果。
07归档复盘优化交易结束后，对比计划与实际执行的差异，归档交易记录，积累历史数据用于统计胜率和优化策略。
系统设计需求

核心功能描述了单套交易系统的运行逻辑。在架构上，我们希望系统松耦合、易维护、易扩展、不做重复工作——各套系统独立运行互不干扰，新增算法或系统只加代码不动已有逻辑，相同的计算只做一次。以下三条需求是对这一目标的具体表达：

一个账户可同时运行多套交易系统

实际交易中，单靠一套交易系统难以应对所有市况。你可能需要同时跑两套配置：一套在 BTC 4H 上用 EMA 趋势捕捉大周期方向，另一套在 ETH 1H 上用裸K做短周期结构，两套交易系统监控不同交易对，共用同一个账户的资金。如果系统只能运行一套，就只能手动切换配置，另一套的信号随之错过；要是同时开两个独立程序，账户余额、持仓状态、风控限制就各管各的，一套系统不知道另一套的仓位，资金管理和风控约束就完全失效了。

每个实例对应一个「交易系统配置 × 交易对」的组合，拥有独立的分析结果和持仓记录，启停互不影响。所有实例运行在同一个框架里，共享同一份账户资金和同一套风控约束。同一份配置可以复用于多个交易对——新增一套交易系统只需新建配置文件，想停掉某套直接下线它，框架代码一行不动，其他实例继续运行。

交易系统各模块可选择不同分析算法

BTC 趋势清晰，主流币大周期用 EMA 均线判断方向很有效；但山寨币流动性差、K 线噪音大，均线容易严重滞后，换成裸K摆动结构判断反而更准。同样是"判断趋势方向"这件事，不同交易对、不同市场条件下，适合的方法并不相同。如果系统只内置一套固定算法，换方法就得改代码，不同交易对无法分别配置，每次想尝试新方法，都要承担动主逻辑的风险。

趋势判断、关键位识别、信号识别三个步骤在系统里各自独立，每一步都有多种算法可选。配置时为每一步指定一个算法，三者组合即构成一套完整的交易系统；某一步换用不同算法，就变成另一套系统，两者完全独立运行。增加新算法只需实现接口后登记到注册表，不需要动任何已有代码，已运行的实例不受影响。

交易系统间可共享相同数据计算结果

同时运行三套策略都在监控 BTC，每根 K 线收盘后，三套系统各自去拉一次 K 线，各自跑一次趋势分析。其中两套用了完全相同的 EMA 参数，输入相同、逻辑相同、结果也必然相同，却被重复计算了两遍。随着并行策略数量增加，重复的接口请求消耗交易所调用配额，重复的计算占用系统资源，而这些额外开销全部来自做了同样的事情。

系统对每类数据分别判断能否复用：K 线以「交易对＋周期」为单位合并拉取，无论多少套策略订阅同一个 BTC 4H，只向交易所发一次请求；趋势结果以「交易对＋周期＋算法＋参数」为 key 缓存，参数完全相同的计算只跑一次，结果由所有订阅方共用；关键位结果同理。只有信号识别和交易计划，因为每套交易系统的判断逻辑不同，才各自独立运算，不做共享。

框架、交易系统与实例

上述三条需求共同确立了一个核心设计模型：

框架 这套程序本身 基础设施（所有实例共享）：行情数据中枢 · 趋势缓存 · 关键位缓存 · 风控管理器 交易系统 一份配置文件，为每个功能模块选择算法并设定参数，与交易对无关 趋势分析 · 关键位识别 · 信号识别 · 交易计划 各模块算法可按需选择，参数可独立配置 × 指定交易对（启动时决定） 实例 交易系统配置 运行在 指定交易对 上的运行状态 持仓 · 分析结果 · 交易计划 各自独立，与其他实例互不干扰 示例：「EMA系统 × BTC/USDT」和「EMA系统 × ETH/USDT」是两个独立实例，共用同一份配置 框架边界

三层的定义：

概念是什么举例
框架 这套程序本身。提供一套可插拔的功能模块结构（趋势分析、关键位识别、信号识别、交易计划），以及共享行情数据和统一风控的基础设施 你安装并启动的那个程序，里面有各个功能模块等待被配置
交易系统 一套配置，定义「每个功能模块用哪种算法、参数是什么」。交易系统和具体的交易对无关，是一套可复用的策略定义。同一套交易系统可以在不同的交易对上运行，不需要重写配置 「EMA趋势 · 金K信号 · 顺势 · 盈亏比2:1 · 风险1%」——这套方法可以用在 BTC，也可以用在 ETH
实例 一套交易系统跑在一个具体交易对上的运行状态。交易对在启动实例时指定，不属于交易系统配置本身。每个实例有自己的分析结果和持仓记录，与其他实例互不干扰 「EMA均线系统 × BTC/USDT」是一个实例；「EMA均线系统 × ETH/USDT」是另一个实例，共用同一套配置

交易系统、模块与算法的关系：框架的每个功能模块都是一个「可替换的槽位」。交易系统配置就是在为每个槽位选择具体的算法——选了哪种趋势算法、哪种信号算法，就决定了这套交易系统的行为方式。实例化时，框架把这些算法组合运行在指定的交易对上，分析该交易对的行情、识别信号、生成订单。

同时运行两个实例，共用同一套交易系统配置：

实例 A实例 B
交易系统（共享同一份配置）EMA趋势 · 金K信号 · TREND_FOLLOW · 盈亏比 2:1 · 风险 1%
交易对（启动时各自指定）BTC/USDTETH/USDT
行情数据 / 分析结果BTC 各自独立ETH 各自独立
持仓 / 交易计划独立独立
框架（共享）同一个程序，共用账户资金和风控规则

想在 SOL 上跑同一套策略？再启动一个实例，指定交易对 SOL/USDT，不需要另写配置文件。

框架架构设计

基于上述核心功能目标与设计需求，框架分为七层，各层职责单一、边界清晰，如下所示。

模块分层与清单
层级 层间流转 模块 职责 扩展方式
L0
宿主运行层
 ↓ L0 调度所有系统实例并行运行，分发K线收盘事件至各系统 多系统运行器MultiSystemRunner 协调所有已注册交易系统并行运行；分发行情事件、执行统一风控、管理资金分配 否
风控管理器RiskController 账户级熔断：单交易对每日亏损上限 + 全账户每日亏损上限；触达后冻结开新仓 否
L1
共享数据层
 ↓ K线和计算结果按「交易对+周期+方法+参数」去重，相同计算只发生一次 行情数据中枢MarketDataHub 合并去重后统一拉取K线；每个交易对每个周期只拉一份，多套系统订阅同一份数据 否
趋势结果缓存TrendResultCache 缓存趋势分析结果；以 交易对+周期+方法+参数 为 key，每种方法+周期只算一次 否
关键位缓存KeyLevelCache 缓存关键位识别结果；key 含收盘时间，新K线收盘时旧条目失效，保留 1 根供回放 否
交易对路由注册表SymbolStrategyRegistry 以交易对为路由入口，记录哪个交易对激活哪些交易系统；可随时启停某交易对的某套交易系统，无需改代码 否
L2
系统配置层
 ↓ 配置声明每套系统使用的算法，框架据此决定共享层哪些结果可复用 系统实例配置SystemConfig 定义一套交易系统的算法与参数：趋势分析方法、关键位识别方法、信号识别方法、止盈算法、趋势周期、最小盈亏比、风险敞口比例、自动下单开关等。不含交易对——交易对在启动实例时指定，同一份配置可复用于不同交易对 否
L3
分析计算层
 ↓ 趋势和关键位并行计算后写入 L1 缓存；趋势为震荡时后续流水线短路 趋势分析模块TrendModule 判断当前趋势方向（涨势/跌势/震荡）、阶段、极值价格、回调深度；震荡时触发短路，后续模块不再运行 整体替换
关键位识别模块KeyLevelModule 识别支撑/阻力区间，输出关键位列表及触碰次数；列表为空时触发短路 整体替换
L4
信号决策层
 ↓ 读共享层缓存进行信号判断；无信号或盈亏比不足时短路，否则输出交易计划给 L5 信号识别模块SignalModule 检测价格是否进入关键区且出现合格形态；消费趋势结果和关键位列表；无合格信号时短路 整体替换
交易计划模块PlanModule 计算入场价/止损位/止盈目标/盈亏比/仓位；盈亏比不达最小阈值时短路，不传入执行层 止盈算法可选
L5
执行监控层
 ↓ 执行完成后触发 L6 归档与通知，不阻塞主链路 下单执行模块OrderManager 按交易计划开仓；自动下单关闭时只记录计划并推送通知，不发送真实订单；成交后移交持仓监控 否
持仓监控模块PositionMonitor WebSocket 价格推送驱动；实时检查止盈/止损/移损触发；浮亏不加仓硬规则强制拦截 否
L6
输出层
 — 复盘归档模块ReviewLogger 平仓后归档交易计划与实际执行结果；提供胜率/盈亏统计；不影响主链路 否
通知推送Notifier 在三个时机推送 Discord 通知：① 发现合格信号时（含交易对、方向、入场价、止损价、止盈价、盈亏比）；② 订单成交确认（含实际入场价、仓位大小）；③ 持仓平仓后（含实际盈亏金额、盈亏比、持仓时长）；不参与主链路决策 否
设计需求在架构中的落地

上文确定了系统应满足三条设计需求，以下说明每条需求由哪些层和模块负责实现。

设计需求 负责的层 / 模块 实现方式
多套交易系统并行，各实例独立 L0 · 多系统运行器
L2 · 交易系统配置		 每套交易系统对应一个配置文件，声明交易对、算法和参数；多系统运行器扫描配置目录，为每份配置建立独立实例并行运行，实例间互不感知。增删一套交易系统只需增删配置文件。
各模块算法可按需选择 L2 · 交易系统配置
L3 · 趋势分析模块
L3 · 关键位识别模块
L4 · 信号识别模块		 配置文件里填算法名称；框架为每个模块维护注册表（算法名 → 实现类），启动时查注册表加载对应实现。新增算法只需实现接口 + 登记注册表，已运行实例不受影响。
相同计算只做一次 L1 · 行情数据缓存
L1 · 趋势结果缓存
L1 · 关键位结果缓存		 K 线以「交易对＋周期」为 key 合并拉取；趋势和关键位结果以「方法＋参数＋周期」为 key 缓存，相同计算只跑一次，所有实例共用同一份结果。
需求一展开
多套交易系统并行，各实例独立

框架启动时按以下步骤将配置文件转化为并行运行的实例：

框架启动流程

① 扫描配置目录，发现所有交易系统配置文件

② 为每份配置各自建立独立实例，互不感知

③ 向多系统运行器注册，统一调度并行运行

示例：在 BTC/USDT 4H 上同时运行两套不同系统，框架代码一行未改

配置项系统 A系统 B
执行交易对BTC/USDTBTC/USDT
趋势周期4 小时1 小时
趋势分析方法均线组（EMA 21/55/144）裸K
关键位识别方法水平关键位水平关键位
入场信号方法金K形态信号
最小盈亏比2.02.5
需求二展开
各模块算法可按需选择
支持三种粒度的算法替换
粒度替换什么操作方式需要改动什么
模块级趋势分析 / 关键位识别 / 信号识别模块整体替换为完全不同的实现类实现新类继承抽象基类，注册后在配置里填新名称写新实现类 + 登记注册表 + 改配置一行
方法级同一模块内换用不同算法（如趋势分析从 EMA → 裸K）配置文件改一行 trend_method只改配置一行
参数级同一算法，调整数值参数（如 EMA 周期 20→9）配置文件改 trend_params 字典只改配置里的数值
可用算法目录

趋势分析模块 · TrendModule

注册名中文名算法原理适用场景
naked_candle裸K通过裸K摆动结构（高低点序列）判断趋势方向和阶段，不依赖任何均线指标均线失效的山寨币、低流动性行情
ema_group均线组（EMA）快慢 EMA 组合定方向，均线相对位置和间距判断趋势阶段趋势清晰的主流币；BTC/ETH 大周期
vegas_tunnelVegas 隧道特定 EMA 组合（144/169 与 576/676）形成"隧道"区间中长周期趋势跟踪
trendline趋势线连接摆动高点或低点绘制斜线，价格击穿为反转信号有明显斜向结构的行情
pattern_trend形态趋势通过头肩、双顶底、旗形等宏观K线形态判断趋势方向大时间周期结构判断

关键位识别模块 · KeyLevelModule

注册名中文名算法原理适用场景
horizontal_swing水平关键位聚类历史摆动高低点为水平区间，按触碰次数和量能打分排序结构清晰、有明显水平支撑阻力的行情
pattern_level形态关键位识别头肩颈线、双顶双底颈线、旗形边界等形成的关键位宏观形态驱动行情
specific_price特定价格将重要均线当前值和整数关口视为关键位，动态更新大资金关注的心理价位

信号识别模块 · SignalModule

注册名中文名算法原理适用场景
golden_candle金K在关键位区间内识别大实体阳线（多）或大实体阴线（空）作为入场触发关键位强势确认；趋势延续行情
pattern_signal形态信号识别针形、吞没、晨星暮星等K线形态，在关键位附近触发入场关键位反转确认
ema_signal均线信号价格回踩关键均线并反弹确认，或短期均线穿越长期均线趋势延续入场
算法注册表原理

算法名称与实现类的绑定通过注册表完成，框架启动时按名称自动加载：

加载流程

① 实现算法：按模块接口约定编写算法类，继承对应模块的抽象基类

② 登记注册表：将算法名称（如 "ema_group"）与实现类绑定，框架通过名称查找实现

③ 配置中引用：在实例配置文件里填入算法名称

④ 框架启动时：查注册表找到对应实现类并加载，框架核心代码和已有算法零改动

示例：基于需求一中系统 A（BTC/USDT 4H），三种粒度的改法——每次只改一处，其余不变

参数级 · 同一算法，只改参数值

配置项改前（系统 A）改后
执行交易对BTC/USDTBTC/USDT
趋势周期4 小时4 小时
趋势分析方法均线组（EMA 21/55/144）均线组（EMA 10/30/60）
关键位识别方法水平关键位水平关键位
入场信号方法金K金K
最小盈亏比2.02.0

方法级 · 同一模块，换用不同算法

配置项改前（系统 A）改后
执行交易对BTC/USDTBTC/USDT
趋势周期4 小时4 小时
趋势分析方法均线组（EMA 21/55/144）Vegas 通道
关键位识别方法水平关键位水平关键位
入场信号方法金K金K
最小盈亏比2.02.0

模块级 · 整套判断体系替换（即需求一中的系统 B）

配置项改前（系统 A）改后（系统 B）
执行交易对BTC/USDTBTC/USDT
趋势周期4 小时4 小时
趋势分析方法均线组（EMA 21/55/144）裸K
关键位识别方法水平关键位水平关键位
入场信号方法金K形态信号
最小盈亏比2.02.5
需求三展开
相同计算只做一次

多套系统并行运行时，同一交易对的行情拉取、趋势计算、关键位识别都由共享数据层统一完成、缓存复用，各实例只读不写。以下四层按调用顺序排列：

第一层 · MarketDataHub
行情数据中枢

启动时收集所有系统声明的订阅，合并去重后统一拉取 K 线。每个交易对每个周期只拉一份，多系统共用同一份数据。写入缓存时加写锁，确保信号探测不读到半更新状态。

第二层 · TrendResultCache
趋势结果缓存

缓存 key：(symbol, timeframe, method, params_hash)。同方法+同参数只算一次，多系统共享同一份结果。新 K 线收盘时该交易对的所有缓存条目失效，触发重新计算。支持多读单写。

第三层 · KeyLevelCache
关键位缓存

缓存 key 含 source_close_time 保证时效性，新 K 线收盘时旧条目自动失效，保留 1 根供信号探测回放。多系统共享同一份关键位列表，各自按自己的盈亏比门槛筛选使用。

第四层 · SymbolStrategyRegistry
交易对路由注册表

以交易对为路由入口，记录每个交易对激活了哪些系统实例。K 线数据就绪后，注册表决定将数据推给哪些系统处理。支持热更新，运营时可随时启停某交易对下的某套交易系统，无需重启。

并发安全约定：市场扫描写缓存加写锁；信号探测读缓存加读锁（多读单写）。读取前校验 trend.source_close_time == key_level.source_close_time，不一致则跳过本次。

示例：需求一中系统 A 与系统 B 都运行在 BTC/USDT 4H 上，哪些数据共享、哪些独立

数据共享 / 独立说明
BTC/USDT 4H K线共享两套系统订阅同一个 BTC 4H，只向交易所拉一份，复用同一份缓存
BTC 4H 水平关键位结果共享两套系统都用水平关键位，相同参数时只算一次；参数不同时各自计算一次
BTC 4H 均线组趋势结果系统 A 独享只有系统 A 使用均线组，算一次；若再加一套也用相同均线参数，则共用
BTC 4H 裸K趋势结果系统 B 独享只有系统 B 使用裸K，算一次；若再加一套也用裸K，则共用
信号探测 / 交易计划各自独立每套系统按自己的信号算法和盈亏比门槛独立判断，结果不共享
持仓状态各自独立系统 A 的持仓不影响系统 B，任一崩溃互不干扰
运转链路概览
每根 K 线收盘 · 触发 更新行情缓存 趋势方向判断 关键位识别 趋势震荡？ 有入场信号？ 制定交易计划 盈亏比达标？ 执行交易计划 推送通知 归档复盘 本次结束 ↩ 本次结束 ↩ 本次结束 ↩ 否 是 是 否 达标 不足 ↩ 循环
模块间运行流程

三条轨道各自由不同事件触发，相互独立、互不阻塞。

轨道一 · 数据更新 · K线收盘定时触发

① 行情数据缓存：拉取最新K线，写入缓存

② 趋势结果缓存：运行趋势分析，写入结果

③ 关键位结果缓存：运行关键位识别，写入结果

轨道二 · 信号探测 · K线收盘事件驱动

① 读取共享缓存（趋势结果 + 关键位结果）— 震荡则短路

② 信号识别模块：检测价格是否进入关键区 — 无信号则短路

③ 交易计划模块：计算入场/止盈/止损/盈亏比 — 盈亏比不足则短路

④ 下单执行模块：提交订单，推送通知

轨道三 · 持仓追踪 · WebSocket 价格推送驱动

① 持仓监控模块：实时比对止盈/止损线，触发后平仓

② 下单执行模块：记录实际出场价和盈亏

③ 复盘归档模块：归档交易记录，推送复盘通知

风控层统一约束 点击展开

风控由多系统运行器统一执行，所有系统实例无法绕过。当前版本架构已明确，暂缓实现。

多级亏损熔断

单交易对每日亏损上限：触发后该交易对当日冻结新开仓，已有持仓不受影响。

全账户每日亏损上限：触发后所有系统当日冻结新开仓，直到次日重置。

风控介入时机：交易计划生成后、实际下单前。

复仇协调器

同一信号事件判定条件：同交易对 + 同方向 + 关键位重叠 ±0.4% + 时间差 ≤ 4 小时。满足条件的多套系统共享复仇配额，先到先得，防止多套系统在同一位置重复放大亏损。

硬规则（不可配置）

浮亏不加仓：持仓处于亏损状态时，任何系统均不得在同一方向追加仓位。

当日强平：配置的结束时间到达后，按比例强制平仓当日持仓。

为什么风控不放在各系统内：各系统独立风控容易被绕过或漏实现；多系统并行时各系统的配额加总可能超过账户实际承受能力。账户级风控必须是唯一入口，任何系统都无法绕过。

运行模式 点击展开

运行模式是框架级配置，决定整套系统使用哪种行情来源和订单处理方式。交易系统流水线本身一行代码不变，区别只在两个可插拔接口：行情来源（DataFeed）和订单处理（Broker）的不同组合。

模式一 · Backtest
历史回测

行情来源：本地历史 K 线文件，按时间顺序逐根回放。

订单处理：内存模拟撮合，按配置的滑点和手续费计算成交价。

用途：验证某套算法组合在历史行情上的表现；参数搜索；策略可行性初判。

回测结束输出：总交易次数、胜率、平均盈亏比、平均盈亏比（盈利交易/亏损交易分别统计）、最大连续亏损次数、最大回撤（百分比）、净盈亏。

资金风险：无。

模式二 · Forward Test
实时模拟盘

行情来源：接入真实交易所行情（WebSocket），实时 K 线。

订单处理：内存模拟撮合，账户余额和持仓在内存维护，不发真实订单。

用途：上实盘前的最后验证；建议连跑 1-2 周。

资金风险：无。

历史回测无法验证系统稳定性。WebSocket 断连与重连、API 限频、K 线对齐错误等问题只有接入真实行情后才会触发。上实盘前不跑足够时间的 Forward Test，相当于用真实资金做压测。

模式三 · Live
实盘交易

行情来源：真实交易所行情（WebSocket）。

订单处理：通过 CCXT 向交易所发送真实订单，受 auto_trade 开关控制。

资金风险：真实资金。建议用滚动窗口（Walk-Forward）分段验证，分别在牛市、熊市、震荡市段落单独评估。

附录 A · 模块技术规格索引

每个模块的详细内容（技术选型 · 输入/输出字段 · 关键设计点）记录在独立的技术规格文档中。完整技术规格文档：module_tech_spec.html

模块 ID模块名称层次核心职责技术规格
L0MultiSystemRunner
多系统运行器		宿主层协调多套交易系统实例并行运行，统一启停、心跳检测、故障隔离查看规格 ↗
L0RiskController
风控管理器		宿主层单交易对/全账户每日亏损上限，多级熔断，当前版本架构明确待实现查看规格 ↗
L0RevengeController
复仇协调器		宿主层跨系统共享复仇配额，防止多套系统在同一关键位重复放大亏损，架构明确待实现查看规格 ↗
L1MarketDataHub
行情数据中枢		共享层合并去重拉取K线，每交易对每周期只拉一份，供所有系统共享查看规格 ↗
L1TrendResultCache
趋势结果缓存		共享层缓存趋势计算结果，key=(symbol,timeframe,method,params_hash)，多系统共用一份查看规格 ↗
L1KeyLevelCache
关键位缓存		共享层缓存关键位识别结果，key含source_close_time，新K线时旧条目自动失效查看规格 ↗
L1SymbolStrategyRegistry
交易对路由注册表		共享层以交易对为视角决定激活哪些系统，支持热更新，双向索引查看规格 ↗
L2SystemConfig
系统实例配置		系统配置层固化每套系统的全部配置（exchange/symbols/timeframes/方法选择/交易参数），只读消费查看规格 ↗
M1TrendModule
趋势分析模块		分析计算层输出 direction/stage/extreme_price/pullback_depth，震荡时触发短路查看规格 ↗
M2KeyLevelModule
关键位识别模块		分析计算层输出 zone_low/zone_high 区间列表，无关键位时短路查看规格 ↗
M3SignalModule
信号识别模块		信号决策层信号必须绑定关键位，输出 signal_type/direction/confidence，无信号时短路查看规格 ↗
M4PlanModule
交易计划模块		信号决策层计算 entry/stop/tp/qty，盈亏比不足时短路，止盈算法可选查看规格 ↗
M5AOrderManager
下单执行模块		执行监控层幂等下单，WS+REST 双通道追踪状态，FILLED→持仓 / EXPIRED→结束查看规格 ↗
M5BPositionMonitor
持仓监控模块		执行监控层WebSocket 价格驱动，本地+交易所双重止损保护，移损原子操作查看规格 ↗
M5CReviewLogger
复盘归档模块		输出层JSON 归档 + ndjson 索引 + MFE/MAE 追踪 + Discord 推送，失败不阻塞主流程查看规格 ↗
新增章节
产品范围与非范围

明确本期做什么、不做什么，以及永久不在范围内的设计边界。

✅ 本期包含（v1.0）
类别具体内容
核心闭环7步闭环完整运行：监控行情 → 判断趋势 → 识别关键位 → 发现信号 → 制定计划 → 执行 → 复盘
多实例并行同一框架下同时运行 ≥3 个交易系统实例，各实例独立运行、互不干扰
算法可插拔TrendModule / KeyLevelModule / SignalModule 支持配置切换算法，无需修改框架代码
共享缓存同一交易对的行情数据和 K 线在实例间共享，避免重复拉取
通知输出关键事件（开仓、止损触发、异常）通过 Notifier 推送至 Discord
复盘记录ReviewLogger 记录每笔交易完整决策链，可导出 JSON
模拟交易支持 paper trading 模式（不真实下单，仅记录和通知）
手动干预支持通过 CLI 命令停止/暂停/重启指定实例
❌ 本期不包含（后续版本考虑）
类别说明
Web UI / 可视化界面v1.0 只有 CLI + 通知，不做 Dashboard
自动参数优化不内置参数回测自动调参，需手动配置
多交易所聚合v1.0 只支持单一交易所，不做跨所套利
账户资产管理不做资产再平衡、复利计算等账户管理功能
社交信号源不接入 Twitter/新闻情绪等非行情信号
🚫 永久不在范围内（设计边界）
限制原因
不承诺盈利或保本系统执行算法规则，市场风险由用户承担
不做无限加仓（马丁格尔）风控硬约束，单笔最大仓位和总风险敞口有上限
不做高频刷单（<1分钟K线）不支持 tick 级或秒级交易，最小周期为 1m K 线
不托管用户资金通过用户自己的 API Key 操作，不接触资金归属
不做法币出入金只操作现货/合约仓位，不涉及充提操作
新增章节
用户场景与运行方式

描述典型使用路径，说明"一个账户多系统"在实际操作中如何展开。

Scenario 1：新建一套交易系统

用户：有一定加密货币交易经验的个人用户，想针对 BTC/USDT 运行一套 EMA 趋势自动策略。

步骤：

  • 复制 systems/template.yaml，命名为 btc_ema_v1.yaml
  • 填写配置：交易对 BTC/USDT，趋势算法 ema_triple，信号算法 breakout_v1，仓位上限 10%，止损比例 2%
  • 运行 tradecat start --system btc_ema_v1
  • 框架完成配置校验 → 创建实例 → 拉取历史 K 线缓存 → 进入监控循环
  • Discord 收到通知："实例 btc_ema_v1@BTC/USDT 已启动，当前趋势：上升，暂无信号"
Scenario 2：多系统并行运行

用户：进阶用户，同时跑 BTC 趋势策略、ETH 震荡策略、SOL 突破策略，互不干扰。

步骤：

  • 准备 3 个配置文件：btc_trend.yaml、eth_range.yaml、sol_break.yaml
  • 运行 tradecat start --system btc_trend eth_range sol_break
  • 框架初始化 3 个实例；BTC/USDT 的 K 线只拉取一次，三实例共享
  • BTC 出现信号时只触发 btc_trend 实例下单，不影响其他实例
  • Discord 各实例独立通知，可通过 --system 参数区分来源
Scenario 3：停止某个实例并查看复盘

用户：运行中的用户，想临时停掉 ETH 策略（市场波动异常），但不影响其他实例。

步骤：

  • 运行 tradecat stop --system eth_range
  • 系统完成当前周期后停止（不强制中断），写入 review/eth_range_YYYYMMDD.json
  • 运行 tradecat review --system eth_range，终端输出交易摘要
  • Discord 推送："实例 eth_range@ETH/USDT 已停止。本次运行 2 笔交易，盈亏 +1.2%"
新增章节
风控、安全与异常处理
8.1 风控硬约束（PRD 级，配置可调范围）

以下约束由系统强制执行，配置值超出范围时框架拒绝启动。

约束项默认值可配置范围超出处理
单笔最大仓位（占账户总资产）5%1% ~ 20%超出上限拒绝下单
单个交易系统最大持仓数1 笔1 ~ 3 笔已达上限时不开新仓
所有实例合计风险敞口上限30%10% ~ 50%超出时所有实例暂停开新仓
单笔止损比例2%0.5% ~ 5%超出范围拒绝启动
单日最大亏损（账户净值回撤）5%2% ~ 10%触发后当日停止所有开仓
单实例连续亏损笔数熔断3 笔2 ~ 5 笔触发后该实例暂停 24h
最小下单金额10 USDT5 ~ 100 USDT低于下限拒绝下单
8.2 安全边界
8.3 异常处理规则
异常类型触发条件处理规则
行情拉取失败连续 3 次请求超时或 HTTP 错误暂停该交易对所有实例分析，30s 后重试；超过 10 分钟未恢复则推送告警
下单失败（网络）下单请求超时或返回网络错误等待 5s 重试 1 次；仍失败则取消本次信号，记录日志，推送通知
下单失败（余额不足）交易所返回余额不足错误立即取消下单，标记该实例为"余额不足"状态，暂停开仓直到用户确认
止损订单未成交止损价已触及但订单状态异常以市价强制平仓（fallback），推送紧急告警，记录异常日志
实例内部异常模块抛出未捕获异常隔离该实例（不影响其他实例），推送告警，进入安全模式（只平仓不开仓）
账户净值单日熔断当日亏损超过配置阈值停止所有实例开新仓，保持现有持仓，推送告警，等待用户手动确认恢复
交易所维护API 返回 503 或维护状态码暂停所有交易操作，每 60s 检查一次，恢复后自动继续
新增章节
验收标准与成功指标
9.1 功能验收标准

F1 实例启动与配置校验

  • 合法配置 → 10 秒内完成初始化进入监控循环，CLI 输出启动确认，Discord 收到通知
  • 非法配置（如仓位比例超出上限）→ 启动阶段报错，明确指出非法字段，不创建实例

F2 多实例并行隔离

  • 3 个实例同时运行，其中一个触发开仓 → 只有对应实例执行下单，其他两个不受影响
  • 实例 A 发生内部异常崩溃 → 实例 B/C 继续正常运行

F3 共享缓存

  • 两个实例订阅同一交易对同一周期 → 底层只发起一次 API 请求，可通过日志验证

F4 止损执行

  • 价格从开仓价下跌超过配置止损比例 → 系统在下一周期内触发平仓，实际平仓价偏差 ≤ 0.5%

F5 单日熔断

  • 当日账户净值回撤达到配置阈值 → 所有实例停止开新仓，Discord 推送熔断告警
9.2 成功指标（上线后衡量标准）
指标目标值衡量周期
系统稳定性单实例月连续运行 ≥ 720h（无人工干预重启）每月统计
止损执行准确率实际平仓价格偏差 ≤ 0.5% 的比例 ≥ 95%每月统计
信号响应延迟K 线收盘到完成判断并下单 ≤ 10 秒（1h K 线场景）持续监控
行情数据可用率行情缓存有效时长占比 ≥ 99.5%每月统计
异常自恢复率可自动恢复异常中，无需人工干预的比例 ≥ 90%每月统计
复盘记录完整性每笔交易复盘日志必填字段完整率 = 100%每月抽查
风控拦截有效性配置的风控规则被正确执行，0 次穿透持续监控
通知到达率开仓/止损/告警 Discord 通知到达率 ≥ 99%每月统计