▸ 查看实时数据面板

指标构造

两条轴各自二值化，交叉出四个象限。流量轴取 BTC + ETH 现货 ETF 的 20 日滚动净流入； 费率轴取 BTC 永续资金费率的 7 日均线，与静息点比较（下一节详述为什么是静息点而不是某个分位）。

象限	条件	含义
A 健康吸筹	净流入 + 费率低位	现货主导，杠杆未拥挤，上涨最扎实
B 杠杆追高	净流入 + 费率高位	多头拥挤，回撤易触发连环清算
C 磨底无人问津	净流出 + 费率低位	抛压已难压价，同时缺乏做空燃料
D 危险背离	净流出 + 费率高位	现货不接盘而杠杆仍做多

这个指标衡量的不是涨跌方向，是上涨的脆弱程度。 A 和 B 可能对应同样的价格走势，但风险结构完全不同。

费率阈值校准

币安永续的资金费率由两部分构成：溢价指数分量，加一个默认利率分量。默认分量固定为每 8 小时 0.01%， 一天三档，年化即 0.01% × 3 × 365 = 10.95%。 当永续与现货基本平价、溢价接近零时，费率就精确停在这个数上。

由此确定的两件事

其一，阈值必须在静息点之上。 「杠杆在出价」的经济含义是多头真金白银付钱给空头，那只有突破静息点才成立。 本项目最初把阈值设在 10.0——低于静息点——结果「费率静息」被判成「杠杆追高」，象限系统性偏移一格。 这个错误不报错、不崩溃、图照画，只是结论全错，是整个模块最隐蔽的坑。

其二，费率轴不能用百分位。 实测 p75 与 p90 都等于 10.95——中间是一个巨大的并列平台。 任何落在 75–90 分位的阈值都会砸在平台上，判定完全不稳定。

百分位还有个更根本的问题：它按构造必然让固定比例的日子被判为「高」， 无论真实费率是 30% 还是贴地 1%。而当前市场最重要的事实恰恰是「杠杆被清算后长期贴地」—— 这个状态在百分位口径下完全看不见。一个具体例证：面板上线时费率精确停在 10.95， 是最平淡无奇的读数，百分位却给出满分 100。

一个实测发现：十七个月无溢价

校准过程中出现一个我没有预期的结果。以 2025 年 10 月的大规模爆仓为界，对比前后：

区间	观测数	均值	高于静息点占比	低于 5% 占比
2025-04 → 10-10	576	5.44%	0.0%	45.0%
2025-10-10 → 2026-08	965	2.88%	0.0%	62.9%

2025 年 4 月至今十七个月，BTC 资金费率一次都没有突破过静息点。 全历史 7% 的多头溢价时段，全部发生在 2025 年 4 月之前。

而且爆仓并不是这件事的起点——它只是让贴水更深（低于 5% 的时段占比从 45% 升到 63%）。 趋势在爆仓之前就已经开始了。

RDI：三次迭代与搁置

最初的设计还有第三条轴：把「加密」与「AI 股票」两个资金桶做比较，得出一个资金分流指数（RDI）， 衡量边际风险资金站在哪一边。这条轴目前未启用，但推导过程本身值得记录。

第一版：双边 z-score 差

RDI = z(crypto_20d) − z(ai_20d)。看起来自然，实际上错得很彻底。 z-score 衡量的是「相对自身近期是否异常」，会把水平信息完全消掉。 但「BTC 净流出而 AI 净流入」是一个水平事实，且这类 regime 常持续 6–12 个月， 120 日的 z 基准会在半年内把它吸收干净——正好抹掉要测的东西。

第二版：规模归一化份额

先各自除以自身量纲基准，解决两桶绝对规模差几个数量级的问题，再取份额。 合成数据测试全部通过，象限判定正确，RDI 方向正确。

但把序列打印出来才发现问题：抽血期 RDI 被死死钉在 −1.00 长达 175 天。 份额公式在两侧符号相反时恒等于 ±1，与量级完全无关—— 「BTC −$1B / AI +$46B」和「BTC −$0.1B / AI +$2B」算出来是同一个数。 而分流的核心信息恰恰是量级差。一条钉在 −1 的直线，研究价值为零。

第三版：tanh

单调、有界、不饱和，强度梯度全程保留。除以 2 是量纲校准：|c_n| 与 |a_n| 典型量级约 1，差值约 2，tanh(1) ≈ 0.76，动态范围舒适。

为什么搁置

公式定了，数据没有。AI 主题 ETP 的日频资金流需要从流通份额变化估算，四条路径全部实测失败：

数据源	实测结果
发行商日频 CSV（iShares）	端点已不提供 CSV，三种请求头变体返回完全相同的产品页 HTML
yfinance get_shares_full()	对 ETF 返回空，包括作为对照组的 IBIT
ETF 数据聚合站	表格由 JS 渲染，静态 HTML 中不存在
SEC N-PORT	权威且免费，但披露滞后约 60 天，20 日滚动流量无法使用

可以用价格类代理凑出一个数（比如半导体 ETF 相对大盘的强弱），但那就不再是资金流指标了。 沿用同一个名字会破坏方法论本身的可信度，因此选择留空而不是凑数。

数据工程：四个陷阱

结论的可信度取决于取数环节，这部分通常不被记录。以下四个都是本项目实测踩到的。

一、HTTP 200 不等于拿到了要的东西

上游数据源在 Cloudflare 之后。用普通 HTTP 客户端请求时，返回的不是 403，而是一个 200 的诱饵页—— 38KB，结构完整，但没有数据表。如果抓取逻辑只判断「有没有抛异常」，会把这条判为成功并缓存下来， 从此再不尝试真正可用的方式。

修正方式是在抓取层加内容校验：用真正的解析器验一遍能否定位到目标表格，验不过就当这条策略失败、继续降级。 同类问题在本项目出现了两次，第二次是另一个数据源返回 2.2MB 的产品页 HTML—— 三种请求头变体返回完全相同的字节数，这才是判定「不是请求头问题」的决定性证据。

二、同一来源的两个页面可以有完全不同的结构

BTC 流量表首格是 Date，单行表头；ETH 流量表首格是空的， 双行表头（第一行发行商名，第二行 ticker），中间还夹着两行伪数据行。 按字符串匹配 "Date" 定位表头的写法，在 ETH 页上整张表都认不出来。

改成结构无关的判据后解决：选表看哪张表含有最多「首格能解析成日期」的行； 选表头看数据区之前哪一行的 ticker 形态单元格最多。 发行商行（Blackrock / Grayscale）得 0 分，ticker 行（ETHA / ETHB）得满分，自动选中后者。

三、非交易日记 0 会污染滚动统计

节假日在来源表中整行无数据。如果按「缺失即 0」处理，这些 0 会进入 20 日滚动和，把真实流量稀释掉。 正确做法是跳过而非记 0——没有交易就没有流量，不是流量为零。

同类问题还有 stale 判定的阈值口径。最初沿用了服务心跳的 30 小时，但 ETF 流量数据本身有约一个交易日的 发布延迟，叠加周末后，周五的数据到周一早上已经 72 小时——按小时判必然天天误报。改为数交易日后正常。

四、给自己留一个可验证的锚

来源表格的每一行都附有一个 Total 汇总列。解析时逐行核对 per-ticker 求和是否等于公布的 Total， 容差 0.15M，对不上就丢弃该行。全量 1,180 个交易日、11,995 条明细，失配数为 0。

这是解析正确性最硬的证据——比「代码跑通了」「图看起来正常」都可靠。 整表层面另设两道闸门：解析行数低于下限、或失配率超过 2%，直接拒绝写库，不覆盖已有的好数据。

局限

• 费率轴当前区分度不足。在十七个月无溢价的 regime 下，B / D 象限几乎不会触发，四象限实际退化成两象限。面板另设四档费率带（空头付费 / 永续贴水 / 静息区 / 多头溢价）承载细节。
• 费率取样为每日最后一档（8 小时一档，取当日最后一条），非日内均值。趋势判断不受影响，但不宜用于日内分析。
• ETF 流量按美股交易日对齐，而永续费率是 7×24 连续的。周末费率被自然丢弃，因此 7 日均线实为「7 个交易日」而非 7 个自然日。
• 只覆盖美国现货 ETF 与币安永续。其他地区 ETP、其他交易所的永续、以及场外交易均不在口径内。
• 不含价格预测。本指标不回答「会不会涨」，只回答「正在涨的这一段由谁驱动」。