第1章项目背景与需求分析

一、项目背景与需求分析：理解做市商业务，明确库存监控看板的核心需求与功能边界

大家好，我是你们的老朋友。今天咱们正式开始这个做市商库存监控看板的实战教程。

说实话，我最早接触做市商业务的时候，也是一头雾水。什么双边报价、库存风险、Gamma 对冲……听着就头大。但后来我慢慢发现，做市商的核心逻辑其实没那么玄乎。说白了，就是「低买高卖，赚取价差」。只不过这个「低买高卖」是在极短的时间内，靠高频交易和严格的风险管理来实现的。

嗯，咱们今天不聊那些复杂的数学模型，先把这个业务场景理清楚。你想想看，如果你是一个做市商，你手里有一堆股票、债券或者加密货币的库存。你的任务就是不断地向市场报出买入价和卖出价，吸引对手方来跟你交易。你的利润来源，就是买卖价差。

但这里有个大坑——库存风险。你手里的货，价格是实时波动的。万一市场突然暴跌，你手里的库存还没卖出去，那亏损可就大了。所以，做市商必须时刻盯着自己的库存，知道现在手里有多少货，成本是多少，浮盈浮亏是多少，风险敞口有多大。

这就是我们做这个库存监控看板的初衷。

我在项目中遇到过不少做市团队，他们最头疼的问题往往不是策略本身，而是「看不清自己的底牌」。具体来说，有这几个痛点：

数据分散：交易数据在交易所、券商、自营系统里各存一份，想汇总起来看，得手动导出再拼凑，费时费力。
实时性差：很多团队还在用 Excel 做库存管理，数据刷新频率是分钟级甚至小时级。对于高频做市来说，这跟闭着眼睛开车没区别。
风险暴露滞后：等发现库存风险已经很大了，往往已经错过了最佳对冲时机。我曾经见过一个团队，因为没及时看到某个币种的库存集中度超标，结果一个黑天鹅事件直接亏掉了半个月的利润。
决策缺乏依据：没有直观的看板，交易员只能凭感觉调整报价策略。说白了，就是拍脑袋。

核心结论：做市商库存监控看板，本质上是一个「风险仪表盘」。它要解决的核心问题，就是让交易员和管理层在 1 秒内看清当前库存的健康状况。

好，痛点明确了，咱们来梳理一下这个看板到底需要展示什么。我个人习惯把需求分成三个层次：

层次	需求描述	优先级
第一层：数据总览	总库存市值、总浮盈/浮亏、总风险敞口、各品种占比	P0（必须）
第二层：明细监控	每个品种的持仓数量、平均成本、当前价格、浮动盈亏、库存周转率	P0（必须）
第三层：风险预警	库存集中度、最大回撤、VaR（在险价值）、压力测试结果	P1（重要）

你可能会问，为什么要把风险预警放在第三层？因为在实际业务中，数据总览和明细监控是交易员每天都要看的，而风险预警更多是风控部门或管理层在特定场景下才需要深入分析。当然，如果条件允许，最好都做上。

做项目最怕的就是需求蔓延。我见过太多团队，一开始只想做个库存看板，结果做着做着变成了交易系统、风控系统、报表系统……最后项目烂尾。

所以，咱们得明确功能边界。这个看板的核心职责是「监控」和「展示」，而不是「交易」或「风控执行」。具体来说：

避坑指南：我曾经接手过一个项目，客户非要在看板里加一个「一键平仓」按钮。结果上线第一天，某个实习生误操作，把整个库存清空了……虽然最后追回了损失，但那个月的奖金全泡汤了。记住，看板就是看板，别越界。

为了让你更直观地理解整个项目的结构，我画了一张图。这张图展示了从数据源到最终看板的完整链路。

这张图其实已经把咱们整个项目的骨架画出来了。数据从交易所或者数据库来，经过清洗和计算，最后展示在 Web 看板上。中间的核心指标，就是咱们要重点监控的内容。

小提示：在实际开发中，我建议你先把「数据总览」和「明细监控」这两个 P0 需求做扎实。等上线稳定了，再逐步加上风险预警功能。这样既能快速交付，又能降低项目风险。

虽然咱们这一章主要讲需求，但技术选型也得提前想清楚。我个人比较推荐用 Python 做后端数据处理，前端用 Vue 或 React 配合 ECharts 做图表展示。数据库的话，PostgreSQL 或者 ClickHouse 都行，看你的数据量大小。

不过这些细节咱们后面会详细讲，今天先把业务逻辑吃透。你想想看，如果连需求都没搞清楚，代码写得再漂亮也是白搭。

好，这一章就到这里。咱们下一章开始动手搭建开发环境，到时候我会带着你一步步把代码写出来。