熔岩AI热榜与多窗热度对账：为什么 /hot/stocks 上榜但 /heat/windows 对不上

摘要

熔岩（Lava）全市场热度里，GET /hot/stocks（MCP 工具 get_market_hot_stocks）给出的是一张按窗口排序的个股热榜；GET /heat/windows（get_stock_heat_windows）给出的是同一只股票在 1h / 4h / 18h / 24h / 3d / 7d 六个窗口上的快照。两套接口都是只读的结构化数字，但「上了热榜」并不等于「单股窗口里的计数能对上」。本文把对不上的常见原因写成可执行的对账清单：先对齐 window、market、min_score，再比较名次与单股窗口，而不是把两列数字直接相减。

两个接口各自回答什么

接口	MCP 工具	观察对象	时间参数	市场范围
/hot/stocks	get_market_hot_stocks	全市场截面，按提及热度从高到低排	查询参数 window，默认 24h，枚举为 1h / 4h / 18h / 24h / 3d / 7d	参数 market：ashare（默认，只看 A 股，按代码合并）或 all（含港美股等，按简称合并）
/heat/windows	get_stock_heat_windows	单只股票的多窗快照	无 window 参数，一次返回上述六档，并附最近 24 小时逐小时走势	无 market 参数；用 ts_code 或 stock_name 二选一指定标的

热榜回答的是「这个窗口里，全市场谁更靠前」；多窗接口回答的是「这一只在六个镜头距离下分别是多少」。名次是相对量，窗口计数是该标的自己的快照，两者不是同一列指标。个股与概念消息面里的意见摘要，也解决不了这两列数字的口径差异，对账要回到参数本身。

对账前必须对齐的三组参数

1. 窗口要对同一档。
用 /hot/stocks?window=24h 得到的名次，只能去多窗返回里找 24h 那一档对照。短窗 1h、4h 灵敏，长窗 3d、7d 更平滑：一只股票完全可以出现在 1h 热榜前列，同时在 7d 窗口里看起来很普通；反过来，7d 窗口计数不低，也不保证它此刻还留在 1h 榜上。

2. market 只存在于热榜。
ashare 与 all 不仅改变谁能上榜，还改变合并键：A 股按代码合并，all 按简称合并。多窗接口没有 market 参数，对账时必须先记下热榜当时用的是哪一种范围，否则会把两套样本当成同一总体。

3. min_score 的含义并不对称。
热榜的 min_score 表示「只统计机构/大V 分达到该值的提及」；不传则不按分数过滤。分数大约分布在 450～1500，1000 左右算中等，1050 约前 10%。多窗接口的 min_score 默认是 1050，文档把它定义为「高分机构/大V」的分数线，并同时给出提及数、机构/大V 数、高分机构/大V 数和加权热度。用一张「未设门槛的热榜」去对一张「高分线默认 1050 的单股快照」，计数对不上是预期现象，不是接口故障。

另外，热榜 limit 默认 50、最大 200，没有分页偏移参数，不要自行假设还能翻页。返回列表里找不到某只股票，可能只是它排在 limit 之外，不能写成「多窗热度为零」。热榜约 1 分钟更新，两次调用的 meta.server_time 若不一致，短窗数字也可能已经滑动。

示例：名次对得上、计数对不上

下面用一组标注为「示例」的虚构数字，只演示口径，不对应真实标的或行情。

假设调用 get_market_hot_stocks，参数为 window=24h、market=ashare、不传 min_score、limit=50，某只示例股票排在第 12 名，行内提及数为 80。随即调用 get_stock_heat_windows，只传该股 ts_code，其余用默认（min_score=1050）。若在返回的六档里读取 24h 窗口，提及数是 80、高分机构/大V 数明显小于热榜行里的机构数，这仍然可以对得上：热榜这一行统计的是未按分数过滤的提及，多窗里的高分计数走的是 1050 默认线。若再误拿 1h 窗口的提及数去减 80，就会得到「对不上」的假差异。

对账时应同时记下：热榜 window / market / min_score / limit，多窗的 min_score，以及两次响应的 meta.server_time。需要看高分主体时，应把热榜也加上同一条 min_score 再取数，而不是改多窗结果去迁就榜单。

# reconcile_hot_vs_windows.py —— 示例
import os, requests

BASE = os.environ["LAVA_BASE"]  # 指向订阅根路径 /subscribe/v1
H = {"Authorization": "Bearer " + os.environ["LAVA_API_KEY"]}
CODE = "000000.SZ"  # 示例代码，请换成实际 ts_code

hot = requests.get(
    BASE + "/hot/stocks",
    params={"window": "24h", "market": "ashare", "limit": 200},
    headers=H, timeout=60,
).json()
assert hot["ok"], hot["code"]
rows = hot["data"] if isinstance(hot["data"], list) else hot["data"].get("items", [])
# 行内代码、名称、提及数字段名以 OpenAPI 为准
hit = next((r for r in rows if r.get("ts_code") == CODE), None)

win = requests.get(
    BASE + "/heat/windows",
    params={"ts_code": CODE, "min_score": 1050},
    headers=H, timeout=60,
).json()
assert win["ok"], win["code"]
# 六档窗口的列表字段名以 OpenAPI 为准；对账时只取与热榜相同的 24h
print(hot["meta"]["server_time"], "in_list=", hit is not None)
print(win["meta"]["server_time"])

匿名机构/大V 的分数线在这里只用来对齐口径。账户侧的计费规则是：开通赠 100 元代金券，成功调用每次 0.005 元，非 2xx 与查余额不计费；对账脚本不要为了「再看一眼」而高于更新节奏地重复拉取。

推荐的对账步骤

1. 固定热榜参数：window、market、是否传 min_score、limit，并把这四项和 server_time 落盘。
2. 在返回列表里定位目标股票；若不在列表中，先把 limit 提到 200，仍不在只能记「该参数下未进入榜单」，不能推断多窗为零。
3. 用同一 ts_code 调 /heat/windows；若热榜用了 min_score，多窗使用同一数值，避免默认 1050 偷偷改线。
4. 只抽取与热榜 window 相同的那一档计数来对照；其他五档用来解释「为什么上了这张榜、另一档却不起眼」，不要混进同一条差值。
5. 名次只在同一张榜、同一参数下比较。多窗接口不产生全市场名次，缺了名次不是对账失败。

FAQ

Q：为什么热榜第 1 名，多窗里的 1h 计数却很低？
A：先看热榜用的是哪一档 window。若榜单是 24h 或 7d，第 1 名只说明在该长窗里相对靠前；1h 窗口完全可以已经回落。这是镜头距离不同，不是两套数据互相否定。

Q：market=all 的热榜，能直接和多窗快照对提及数吗？
A：可以在「同一只已指定的股票」上对照同一档窗口，但要记住 all 按简称合并，和 ashare 按代码合并不是同一总体。多窗没有 market 参数，不要把范围差异解释成窗口误差。

Q：要把 min_score 调成 0 才能对上吗？
A：不一定。热榜不传 min_score 表示不加分数过滤；多窗把 min_score 设为 0 是否改变提及总数，以返回字段和 OpenAPI 为准。更稳妥的做法是：需要高分口径时两边都显式传同一门槛（常用 1050），需要全量提及时不要拿默认高分线去减热榜行。

Q：对不上是否说明接口坏了？
A：先核对窗口、市场范围、分数线、limit 和两次 server_time。这五项对齐后仍只应比较「同一标的、同一窗口档」的计数，而不是比较名次与快照。

结论

熔岩的全市场热榜和单股多窗热度是互补的只读观测，不是同一张表的两个视图。上榜只说明在指定 window、market、min_score 和 limit 下相对靠前；/heat/windows 给出的是该标的六档窗口快照。对账的核心是参数对齐，而不是让两列数字相等。把名次当成单股窗口，或拿错窗口档、拿错分数线，都会产生假的「对不上」。

数据来自熔岩消息面热度监测，仅供研究参考，不构成投资建议。

只读监测与字段说明见：https://lava.ai-dolphin.com/tools/stock-heat-compare