量化平台真正的门槛：不是策略，是交付
EasyQuant 的产品定位：策略交付型量化平台
很多团队做量化，第一阶段都很顺：写策略、跑回测、出曲线、开会讨论。
真正让项目停滞的，往往不是“策略不够好”，而是进入第二阶段后，事情突然变成了另一种难题：
- 同一个策略，换个人、换机器、换一段时间，结果就不一样了
- 策略“没信号”“没下单”，大家只能猜：是逻辑问题？数据问题？风控问题？通道问题？
- 调参、复盘、评审越来越依赖“口述”和“经验”，团队协作成本不断上升
- 一旦要推进到更接近生产的环境，系统稳定性、排障效率、审计留痕都开始成为硬门槛
于是量化平台的竞争，从“谁的指标库更多、回测更快”，变成了更现实的命题：
你的策略，能不能被稳定地交付给团队使用？
EasyQuant 从一开始就把这个命题放在中心：
我们不只做“能跑策略”的工具，而是做一套能把策略从“个人脚本”变成“团队资产”的系统。
你以为的难点：策略
真正的难点：交付
为了讲清楚，我们先用三个团队最常见的场景来对照。
场景 1：没信号——到底是谁的问题？
策略没触发信号，你可能要排查：
- Universe 是否为空？是否被过滤？
- 数据是否缺失？K 线是否不新鲜？
- 指标计算是否异常？参数是否被覆盖？
- 调度是否在跑？是否被跳过？
在很多系统里，这会变成“翻日志 + 试出来”。
而真正需要的是：把原因结构化、可视化，让人一眼看到下一步该查什么。
场景 2：没下单——到底卡在风控还是通道？
策略有信号但没有成交，这中间可能被：
- 风控拒绝（仓位、额度、数据质量、流动性等）
- 通道拒绝（参数校验、价格异常、不可交易状态等）
- 或者执行链路本身异常
如果系统只能给一句“下单失败”，那问题就会在团队里反复出现。
真正的交付要求是：拒绝也要可解释，最好还能被统计、能被监控。
场景 3：结果不一致——到底变的是哪一个变量？
同策略不同结果，最常见来源不是“玄学”，而是：
- 输入漂移（数据来源不同、时间窗口不同）
- 版本漂移（策略版本/参数不一致）
- 成本漂移（手续费、滑点、撮合假设不同）
所以“可复现”不是一句口号，而是系统能力：
要能记录这次运行的关键输入与配置快照，让每条结果有出处。
EasyQuant 的四件套：把交付做成系统能力
EasyQuant 把策略交付拆成四个产品能力，并让它们在 UI 与数据层都能闭环。
1）可解释：把“猜原因”变成“看原因”
在 EasyQuant 里，“为什么没信号/没下单”不是散落在日志里的句子，而是结构化原因码与聚合统计。
当问题发生时，系统能告诉你属于哪一类：标的、数据、调度、风控、通道、引擎异常……并给出可读的中文解释。
这意味着排障不再依赖个人经验，而是可流程化、可协作。
2）可复现：每次运行都要有“身份证”
回测结果要能被评审、对比、复盘，靠“记得当时怎么配的”是不可靠的。
EasyQuant 用运行快照（provenance）的方式，把关键配置和输入摘要固化下来，让结果可追溯、可对比。
这件事看似“工程细节”，但对团队协作是质变：讨论基于事实，而不是口述。
3）可运维：从“能跑”到“可长期运行”
系统要进入团队日常使用，就必须可监控、可告警、可排障。
EasyQuant 通过 Prometheus/Grafana 的可接入性，让系统不仅能展示页面，也能进入运维体系：
服务存活、接口健康、关键行为统计（比如阻塞原因、拒单原因）都可以变成可监控对象。
4）可扩展：为未来的多数据源/实盘接入留边界
很多量化系统的问题是：早期写得快，后期改不动。
EasyQuant 在内核里明确了“边界”：数据获取、执行通道、风控规则等都应该可替换、可演进。
这不是为了“架构漂亮”，而是为了让系统能从研究走到准生产，而不是推倒重来。
EasyQuant 适合谁？不适合谁？
为了减少误解，我们把边界说清楚。
更适合
- 想把量化从“个人研究”推进到“团队交付”的团队
- 需要策略评审、复盘、协作、留痕、可追溯的组织
- 目标是“研究 + 纸面 + 准生产”逐步演进，而不是一次性豪赌实盘
暂不适合
- 只需要一个本地脚本回测器，不关心协作与交付
- 立即要上高频/高并发/复杂交易品种，并且要求全市场细节高度拟真（这需要更长周期工程化）
结语：策略会过时，交付能力会沉淀
策略的优势可能会被市场磨平，但一个团队的交付能力会长期沉淀：
可解释、可复现、可运维、可扩展——这些能力决定了团队能否持续迭代、持续产出。
EasyQuant 想做的，就是把这些能力做成“平台默认提供的基础设施”。
下一篇我们会用最短路径跑通一个完整闭环：从演示数据到组合回测，再到如何读懂结果与异常。