Blankly / 与技能路线对比
写策略工程，还是直接问一个研究问题
这两条路线其实在回答不同的问题。Blankly 是一个策略工程框架：你写代码、定义事件、管理状态，换来跨交易所的统一接口与一份可长期演进的代码资产。EasyClaw 的本机技能面向研究任务：你描述问题，技能完成取数、指标计算、筛选或出图，换来的是立刻可用的结论。这一页按任务逐项对照，并把两者的边界说清楚——尤其是它们之间没有已证实集成这件事。
一分钟速判：你该走哪条路线？
只回答一个问题：你最终要不要下单？
不确定时的默认做法：先用技能路线把问题问清楚，再把值得投入的部分写进框架工程。两者配合使用的时间成本，通常低于一开始就搭工程。
两条路线的区别是什么？一个产出代码资产，一个产出研究结论
先把这个区别想清楚，后面的对照表才有意义。两者的差异不在功能多少，而在「你最终想留下什么」。
Blankly 留下的是可演进的代码
你得到的是一个项目目录：策略入口、配置文件、密钥管理、依赖清单。它的价值随时间累积——同一套回调既能跑回测也能接实盘，交易所可以替换。代价是你必须自己承担环境维护，包括那条当前需要钉住版本上限的依赖链。
技能路线留下的是结论与产物
你得到的是数据表、指标数值、筛选结果或图表。这类任务不需要你维护一个 Python 工程，也不需要处理依赖版本问题。代价是它不产出「可以长期迭代的策略代码」——每次研究是独立的一次问答。
它们不是替代关系
一个完整的量化工作流往往两者都需要：用技能路线快速验证想法、取数据、出图；确认值得投入后，再写进一个可维护的策略工程。把两者当成互斥选项反而会限制自己。
但在「只想拿结论」的场景下，成本差异很大
如果你的任务就是回答一个问题（某标的的波动率是多少、哪几只票满足条件），那么搭环境、装依赖、写策略、跑回测这一整套流程是纯开销。这是本站把技能路线作为一条正式替代路线列出的原因。
按任务看：这件事该走哪条路线？
下表把常见量化研究任务拆开，逐条说明两条路线各自能做到什么程度。技能名称来自本机技能目录中各技能的自述文档，只代表技能存在并可被调用，不代表已安装或已验证。
| 任务 | Blankly（框架路线） | EasyClaw 技能路线 | 建议 |
|---|---|---|---|
| 回测一个自定义策略 | ✓ 事件驱动回测，内置订单过滤器与绩效函数 | ◐ 有面向回测方法论与策略设计的技能，但不产出可长期维护的策略代码 | 要长期迭代选框架；只想验证想法两边都可以 |
| 取某只标的的历史行情 | ✓ 从所连交易所拉取并缓存 | ✓ 多个数据类技能覆盖股票、基金、期货、外汇、债券、指数、加密货币 | 只取数用技能更快 |
| 计算区间指标（波动率、回撤等） | ✓ blankly.metrics 的 11 个函数 | ✓ 数据类技能可直接给出区间指标结果 | 单次计算用技能；批量纳入策略用框架 |
| 技术指标计算（RSI/MACD 等） | ✓ blankly.indicators 的 28 个函数 | ✓ 有面向 K 线技术分析的技能 | 两边都能做；框架适合嵌入策略循环 |
| 按条件筛选一批股票 | ◐ 有 Screener 基类，但无内置选股数据源 | ✓ 有面向条件选股与板块查询的技能 | 选股类任务优先技能路线 |
| 把结果画成图表 | ◐ 内置绘图依赖，需自行组织输出 | ✓ 有专门出图的技能，支持多种图表类型 | 要出版级图表优先技能路线 |
| 接交易所下单 | ✓ 有多个交易所接口实现（状态见交易所可用性页） | ✗ 本机技能目录中无交易机器人类技能；部分模拟交易类技能只做模拟组合 | 真实下单只有框架路线 |
| A 股相关工作 | ✗ 无 A 股交易所实现 | ✓ 多个技能覆盖 A 股行情、财务、筛选与研究报告 | A 股任务优先技能路线 |
| 多策略并行运行 | ◐ 有多进程相关示例与基类 | ✗ 不涉及进程级编排 | 工程化需求只有框架路线 |
| 部署到托管环境 | ✗ CLI 的部署命令已被注释 | ✗ 不在技能范围内 | 两边都需要自建运行环境 |
成本对照：两条路线各自要你先准备好什么
选型时最容易被低估的就是这一栏。下表的差异比功能清单更能说明问题。
| 前置条件 | Blankly 框架路线 | EasyClaw 技能路线 | 说明 |
|---|---|---|---|
| Python 环境 | 必需，且需注意版本与依赖上限 | 不需要自己搭 | 框架侧当前在 3.11 上需要钉 numpy 上限才能导入 |
| 依赖维护 | 需自行承担；关键依赖已停更 | 由平台侧承担 | 这是两条路线差别最大的一项 |
| 交易所密钥 | 接实盘必需；离线回测不需要 | 数据类技能通常不需要 | 框架侧密钥为明文存放，需自行控制访问 |
| 策略代码 | 必需 | 不需要（用自然语言描述任务） | 这是两者最本质的分界 |
| 数据准备 | 可用交易所数据或自备文件 | 由技能侧提供 | 框架离线模式对文件格式有六列硬要求 |
| 运行环境（长期） | 需自建进程守护、日志与恢复机制 | 不需要 | 框架侧官方 CLI 部署入口当前不可用 |
| 上手时间 | 取决于对 Python 项目的熟悉程度 | 接近零 | 但复杂任务仍需你判断口径是否合理 |
技能路线在同类任务上怎么交互？三类实际形态
下面三张是本机 EasyClaw 的实际对话截图（2026-09-21）。请特别注意每张图注里写明的边界：这些数据源与标的都与 Blankly 无关，且 Blankly 与 EasyClaw 无已证实集成。
哪四种情况最容易「选错路线」？
下面这些组合看起来很自然，但实际会让你多花很多时间。逐条对照自己的情况。
| 你的情况 | 常见选择 | 为什么会踩坑 | 更合适的做法 |
|---|---|---|---|
| 只想查一只票的指标 | 装 Blankly 写脚本 | 装环境与依赖的时间远大于计算本身 | 直接用数据类技能提问 |
| 已有成型策略要接实盘 | 用技能路线 | 技能路线不产出可长期运行的策略进程 | 走框架路线，并按实盘前检查清单逐项验证 |
| 目标市场是 A 股 | 找 Blankly 的 A 股接口 | 框架内没有 A 股交易所实现 | 用覆盖 A 股的技能；若要写策略，自行补数据与规则层 |
| 需要批量把结果出成图表交付 | 在框架里自己拼绘图 | 框架的绘图是为回测输出服务的，不是为交付设计的 | 用专门的出图技能产出交付物 |
| 想要一份能复现的回测报告 | 只截一张收益曲线 | 曲线不能重跑，也不说明口径 | 按回测引擎审计页的记录清单补齐字段 |
市场覆盖与数据来源有什么差别？
这一栏往往决定路线选择。特别注意「能取到数据」和「能交易」是两件不同的事。
| 市场 / 资产 | Blankly 能取数 | Blankly 能交易 | 技能路线（本机目录） |
|---|---|---|---|
| 加密货币现货 | ✓ 通过交易所接口 | ✓（接口代码存在，需实测） | ◐ 可获取行情数据，不执行交易 |
| 加密货币合约 | ◐ 期货接口存在，官方标注 beta | ◐ 资金费率处理未完成 | ◐ 可获取行情数据 |
| 美股 | ✓ 通过美股券商接口 | ✓（依赖已弃用的客户端库） | ✓ 有美股行情类技能 |
| 外汇 | ◐ 有对应接口，但不支持 WebSocket | ◐ | ◐ 数据类技能覆盖外汇行情 |
| A 股 / 港股 | ✗ 无交易所实现 | ✗ | ✓ 多个技能覆盖行情、财务、筛选 |
| 基金 / 债券 / 指数 | ✗ 框架未覆盖 | ✗ | ✓ 数据类技能覆盖 |
| 期货（商品） | ◐ 有期货接口（加密合约为主） | ◐ | ◐ 数据类技能覆盖期货行情 |
关于两条路线选择的高频问题
技能侧信息来自本机技能目录中各技能的自述文档；框架侧信息来自源码与实测。两边都不构成投资建议。
Blankly 里的技能是不是已经集成好了？
没有。本站必须明确这一点：Blankly 与 EasyClaw 之间没有任何已证实的集成关系，本机技能目录里也没有任何与 Blankly 相关的技能。本页的对比是「同一类任务在两条不同路线上的做法差异」，不是「Blankly 可以在 EasyClaw 里安装」的说明。
技能路线能替代回测吗？
不能完整替代。回测的核心产出是「一份可以反复重跑、口径可追溯的策略验证过程」，这需要代码资产。技能路线可以帮你快速算指标、取数据、出图，也能在方法论层面提供思路，但它不产出一个可版本管理、可接实盘执行的策略工程。两者配合使用才是完整工作流。
我该先学哪一个？
取决于你下一步要交付什么。如果近期目标是「搞清楚几个标的的情况」，从技能路线开始更高效。如果近期目标是「把一个策略想法做成可运行的工程」，那就直接面对框架路线，但请先读完安装页——因为不处理依赖上限，你会在第一步就卡住。
技能列表里的技能我都能直接用吗？
本站只能说明这些技能的目录与自述文档存在于本机，也就是「目录可见」这一状态。目录可见不等于已安装成功、不等于已获得数据源授权、也不等于运行验证通过。具体某个技能能否完成你的任务，需要实际调用一次才能确认。
为什么技能路线在 A 股上覆盖更好？
因为本机技能目录里存在多个面向 A 股与国内金融数据的技能，覆盖行情、财务指标、条件选股、研报检索等场景；而 Blankly 的交易所实现面向的是它的历史目标市场（美股、加密货币、外汇），没有 A 股或港股实现。这是两边设计目标不同造成的结果，不是优劣问题。
能不能两条路线一起用？
可以，而且这通常是效率更高的做法：用技能路线做探索与数据准备，确认想法值得投入后，再把逻辑写进框架工程做严格回测。要注意的是两边的时间基准、复权口径与费率假设必须统一，否则同一个想法会得出两套结论。建议把口径记录写在一起。