企业官网建设流程全解析

• 教程

导读：本文以开源仓库 ru-test-assignments 中 Oracul Analytics 量化研究员（Quant Researcher）测试任务 quant-challenge.md 为骨架，完整梳理该任务的背景、提交流程与五步技术路线——从 Bybit Testnet 的 Level 2 订单簿数据采集、Delta 指标计算，到信号与策略构建、模拟回测与最终报告。读完本文，你将掌握一个典型的"订单簿微观结构 → 信号策略 → 回测验证"研究闭环，并清楚了解 Python 与 Rust 两种实现路径下的工程化拆解方式。

一、任务背景：为什么要研究订单簿 Delta 突发

该任务来自量化数据与分析公司 Oracul Analytics（对应其 README 索引条目 中的 "Тестовое задание Quant Researcher"）。原文档给出的任务目标只有一句话：

研究在订单簿（Order Book）Delta 突发的（всплески，即 spike / surge）基础上构建策略的可能性。

这句话包含两个关键技术概念：

• 订单簿（Order Book，L2）：交易所按价格档位（Price Level）聚合的挂单队列，Level 2 数据通常包含多个深度档位的实时买卖挂单量与价格。
• Delta（买卖盘差值）：业内通行的定义为"买方累计挂单量 − 卖方累计挂单量"，反映在某一价格区间上主动买卖压力的净差。当大量买单或卖单瞬间涌入某一档位时，Delta 会出现"突发"（spike），这种微观结构信号常被用来捕捉短期方向性机会。

从任务设计看，公司希望候选人独立验证一个可交易假设：Delta 突发能否构成可用的交易信号。这要求候选人具备数据工程、信号建模与回测三方面的综合能力，而不仅仅是写一个指标。

二、任务总体流程：从 Star 到提交

原文档"Процесс"（流程）一节规定了完整参与方式，这是提交前的必经步骤：

1. 给源仓库Star；
2. Fork仓库；
3. 完成测试任务后，在申请回复（отклик）中发送自己 Fork 的链接，连同其他要求的材料（"вместе с бордами"）一并提交。

需要说明的是，quant-challenge.md 是该任务的本地副本（文档首行注明 "Локальная копия"），当前仓库内并未包含源仓库的实现代码，python/与rust/目录需要候选人自行创建并完成全部实现。

三、五步技术路线详解

原文档将任务拆解为五个步骤，这是整个测试任务的核心骨架，下面逐一展开并补充工程实现层面的细节。

第一步：采集 Bybit Testnet 的 Level 2 订单簿数据

原文要求："Собрать данные по ордербуку (Level 2) с Bybit Testnet."（从 Bybit Testnet 收集 Level 2 订单簿数据。）

为什么用 Testnet：Bybit 测试网（Testnet）与主网共享同一套 API 协议，但使用虚拟资产交易，无资金风险，非常适合用于数据采集与策略研究的第一阶段；同时文档要求数据采集来自 Testnet，意味着候选人不应直接使用他人预处理好的数据集，而必须自己动手摄取原始数据（即交付清单中的 "датаингест" 数据摄取模块）。

采集方案（业界通用做法，供实现参考）：

• WebSocket 增量推送：订阅订单簿增量通道（通常以depth/orderbook为名的 WebSocket 频道，按档位深度请求，如 50 档），交易所会在每次盘口变化时推送增量更新（新增、修改、删除档位）；
• REST 快照兜底：首次连接或连接重连后，先通过 REST 接口拉取一次全量快照（snapshot），再以增量流持续叠加，这是订单簿重建（Order Book Rebuild）的标准范式；
• 持久化：将每条快照/增量记录按时间戳、档位（价格、数量、方向）结构化存储，建议使用 Parquet、CSV 或嵌入式数据库等便于后续 pandas / Polars 读取的格式。

采集期设计要点：数据覆盖的时段应足够长、尽量连续（例如数天），因为后续的 Delta 突发信号与回测都需要足够多的样本；同时记录每一条事件的时间戳精度（通常为毫秒级），这是回测复盘的基石。

第二步：计算 Delta 指标

原文要求："Вычислить метрику дельты."（计算 Delta 指标。）

基础定义：对某一时刻 t，取订单簿前 N 档（例如 5 / 10 / 50 档）：

delta(t) = Σ(买盘第 i 档数量) − Σ(卖盘第 i 档数量)

面向"突发"信号的指标扩展（在基础定义之上的常见研究方向）：

• Delta 变化率 / 突发检测：定义 Δdelta = delta(t) − delta(t−k)，当 |Δdelta| 超过设定阈值或滚动窗口内的统计分位（如 z-score）时，判定为一次"突发"；
• 加权 Delta：对近档挂单赋予更高权重（按价格距离加权），以更贴近"有效压力"；
• 累计 Delta：将时间序列上的 delta 累加，用于观察买卖压力在时段内的持续累积方向。

原文档强调"простая метрика"（简单指标），因此第一步应实现一个清晰、可解释、参数少的 Delta 版本（如固定档数 N 的原始 Delta + 突发检测阈值），再在此基础上做有限的可控变体研究。

第三步：构建基于该指标的简单策略

原文要求："Построить простую стратегию на основе этой метрики."（基于该指标构建简单策略。）

信号生成：以 Delta 突发的方向与强度为信号。例如：

• Delta 向上突发（买压骤增）→ 看多信号（买入 / 平空）；
• Delta 向下突发（卖压骤增）→ 看空信号（卖出 / 平多）；
• 可用突发阈值、信号有效期（signal decay / cooldown）约束频繁开仓。

"简单"的工程含义：策略规则应尽量少参数、规则透明，便于在回测中归因——到底是 Delta 信号本身有效，还是参数过拟合带来的虚假收益。建议固定交易方向、固定每笔头寸（或固定比例仓位），暂不引入复杂的止盈止损组合，先回答"信号是否具有预测力"这一核心问题。

第四步：模拟 / 回测策略

原文要求："Провести симуляцию / бэктест стратегии."（进行策略模拟 / 回测。）

标准回测流水线（供实现参考）：

1. Tick 级数据重放：按时间顺序回放采集到的订单簿事件，逐笔生成信号与模拟成交；
2. 撮合与成本建模：模拟限价/市价单成交，计入手续费（fee）与滑点（slippage），否则回测结果会系统性高估收益；
3. 指标评估：统计收益率、交易次数、胜率、最大回撤（Max Drawdown）、夏普比率（Sharpe Ratio）等，并对比"无信号基准"（如买入并持有）；
4. 稳健性检查：对阈值、档位数、信号有效期等关键参数做敏感性分析，判断结论是否对参数敏感。

注意：原文档此处使用的是"симуляция / бэктест"的并列表述，二者在本次任务中可视为同一环节——在历史数据上模拟策略执行，验证假设。

第五步：准备报告

原文要求："Подготовить отчёт."（准备报告。）

报告是评审理解你研究过程的窗口，建议包含：

• 数据说明：采集的时间范围、档位深度、数据量、数据质量（缺失/断连处理）；
• Delta 指标定义：公式、参数（档位数 N、突发检测阈值）与可视化（Delta 时序图、突发分布直方图）；
• 策略规则：信号如何转化为开平仓动作、持仓与成本假设；
• 回测结果：上述核心指标、与基准的对比、参数敏感性结果；
• 结论与局限：Delta 突发信号是否具有统计意义上的预测力、在哪些市场状态下有效、以及该测试网络数据与实际主网环境（延迟、撮合深度）的差异。

四、实现语言与目录结构

原文档明确给出两种实现语言，且要求二选一：

• python/— реализация на Python（Python 实现）
• rust/— реализация на Rust（Rust 实现）

选择其中一个目录，并在其中完成全部实现。

推荐的模块划分（对应原文档"Что сдавать"交付清单中的四类代码）：

选型建议：Python 生态在数据分析与回测上更快捷（pandas、numpy、matplotlib 一条龙）；Rust 则在低延迟数据摄取与吞吐上有优势。任务本身对"研究结论"的权重高于对"极致性能"的权重，选自己更熟练的语言即可，关键是四个模块职责清晰、可复现。

五、交付物清单

原文档"Что сдавать"（提交什么）一节列出的交付物为：

• Исходный код（源代码）：即上述**数据摄取（датаингест）、信号（сигнал）、策略（стратегия）、模拟（симуляция）**四个模块的完整实现；
• 在回复中附上Fork 仓库链接（见第二节流程）；
• 一并提交的"борды"（看板/看板材料）。

简言之，候选人交付的是一套端到端可运行的量化研究代码库：从订单簿原始数据出发，最终产出信号有效性结论与回测证据。

六、评审视角自检清单

虽然原文档未给出显式评分标准，但从任务目标（"研究……构建策略的可能性"）可以合理推断评审关注点：

1. 数据工程是否扎实：快照+增量重建是否正确、时间戳与档位是否对齐、数据是否有缺失记录与断连处理；
2. 指标是否可解释：Delta 定义是否清晰、参数是否公开、突发检测规则是否有统计学依据；
3. 回测是否可信：是否计入手续费/滑点、是否有基准对比、是否做参数敏感性分析而非单一最优参数；
4. 结论是否诚实：报告是否如实呈现"信号有效/无效/有条件有效"的结论，而非为了好看而选择性呈现结果。

以上第 3、4 点尤其重要——该任务本质是一次假设验证研究，研究过程严谨性与结论的可复现性，往往比"跑出高收益"更能体现候选人的真实水平。

七、在当前仓库中的位置与延伸阅读

• 任务原文：analytics/oracul-analytics/quant-challenge.md（本地副本，含完整流程与交付要求）；
• 仓库索引：README.md 的 "Oracul Analytics → Тестовое задание Quant Researcher" 条目（README.md#L137-L138）将读者引导至该任务；
• 仓库中其余分析类任务（如 analytics/vtb-analitik-dannykh 的test.ipynb与 SQLite 数据库、analytics/tinkoff-analitik-python 的 Notebook）可作为对比参考，理解不同公司对分析类测试任务的侧重差异。

最后提醒：当前仓库为只读镜像，本文仅用于理解与准备任务；完成测试请按原文档流程在自己的 Fork 中进行开发与提交。

• 教程