摘要：用AI复盘自选股，难点常常在于下一步查谁、查什么。面向有量化或技术基础的A股投资者及投研团队，本文通过TickDB MCP调用股票行情API，以2026年11月11日寒武纪、海光信息和中科曙光的真实数据，比较当日涨跌、近20个交易日表现与成交变化，整理一张带后续研究问题的观察表，并提供可复制提示词与重算代码。 11月11日收盘，寒武纪涨7.40%，海光信息涨3.34%，中科曙光涨0.84%。如果它们都在你的自选股里，今晚只够认真研究一家公司，你会先点开谁？ 先看谁，要看你今晚想弄清什么。这次使用的[TickDB]是一项面向量化研究和AI应用的市场数据服务。我们通过它的MCP入口，让AI取得三只股票的行情快照和历史K线，再把当天涨幅放回近期走势里比较。 结果很有意思：当天涨得最多的寒武纪，近20个交易日累计下跌3.12%；当天只涨0.84%的中科曙光，累计上涨14.82%。 研究当天的明显反弹，与复盘近一个月的累计表现，需要追问的问题不同。把研究目标告诉AI，观察表里的比较和问题，才能围绕这项任务展开。 一、先把当天涨幅放回近期背景 我们先选定寒武纪、海光信息和中科曙光，再查询数据。这是三只科技股组成的自选股观察样本。 把当天与近期表现放在一起，差异就清楚了： 图1：同一组股票，换一个比较窗口，看到的相对表现顺序随之改变。 数据说明：样本交易日为2026年11月11日，快照时间为北京时间15:00:00至15:00:02。近期涨跌按前复权收盘价计算，从10月14日收盘至11月11日收盘，共20个交易间隔，使用21个收盘价。 只看当天，寒武纪排第一；看这20个交易日，中科曙光排第一。 两种排序都有用途。当天涨幅帮助你定位这一天的变化，近期涨跌帮助你了解一段时间的累计表现。研究顺序要结合你准备验证的问题来安排。 二、同一只股票，为什么今天大涨，近20天却仍在下跌？ 先把寒武纪的几个价格摆出来。按这次取回的前复权日线，10月14日收盘价是929元，11月10日是838元，11月11日回到900元。 从838元涨到900元，当天涨幅约7.40%；拿900元与929元相比，仍低约3.12%。当天的涨幅很醒目，过去这段时间的回落也确实存在。两组数字各有自己的比较起点。 中科曙光则呈现另一种情况：10月14日至11月11日，前复权收盘价从69.03元升至79.26元，累计上涨14.82%；单看11月11日，它从前一天的78.60元涨到79.26元，涨幅只有0.84%。在这组三只股票中，它当天涨幅最小，20日累计涨幅却最高。 这里值得带走的，是给AI布置任务时要补充的一个条件：你准备比较哪段时间。 “帮我看看今天谁涨得多”，会把注意力带向当天变化；“比较这几只股票近20个交易日的表现”，会让你看到另一组差异。 研究窗口有了，下一步才容易具体：查哪段时间的公告，核对哪些经营变化，下一个交易日继续观察什么。 三、再加一层成交背景 价格之后，再看当天的交易活跃度。 这次用一个容易复算的比较：把当日成交量，除以这只股票此前20个交易日的平均成交量。平均值中不包含当日。 计算结果是： 寒武纪约1.09倍，比自身此前均量略高。 海光信息约0.80倍，低于自身此前均量。 中科曙光约0.60倍，也低于自身此前均量。 三只股票当天都上涨，但成交相对各自历史水平的变化不同。 对寒武纪，后续可以继续观察价格变化与成交能否配合；对中科曙光，可以把近期累计上涨与当天相对较低的成交放在一起，记录下一次复盘要关注的变化。 这里比较的是每只股票相对自己的历史。若直接把不同股票的绝对成交量摆在一起，股本规模等差异也会混进来。这种“先和自己比”的办法，更适合本篇要完成的自选股复盘。 表中的成交比值按上述20日均量计算，与行情软件中的盘中量比口径不同。 四、让观察表最后一列写下研究问题 到这一步，AI已经有了当天表现、近期背景和成交变化。接下来要把它们接到具体工作上。 如果你今晚想研究当天明显反弹的股票，可以先追查寒武纪这次上涨前后有哪些新披露，再记录之后的价格与成交表现。 如果你正在复盘近一个月的相对表现，中科曙光值得单独展开：这段时间披露了哪些经营信息，哪些公司事项需要继续核对？ 例如，中科曙光2026年三季报在解释业绩变化时，提到了高端计算机等IT设备销量增加、配套软件销售增加。这些信息可以帮助你继续查产品销售和业务结构。它们是具体的研究材料，不能仅凭发布时间就认定为某一天上涨的原因。 寒武纪、海光信息也各有自己的经营披露。三份三季报中的前三季度营业收入均同比增长，而这组三只股票的20日价格表现方向并不相同。研究需要继续落到各家公司，核对增长来自哪里、后续披露有没有改变原先的判断。 最终，观察表可以整理成这样： 股票 已观察到的情况 下一步查什么 寒武纪 当天涨幅最大，20日累计表现仍为负；成交略高于此前均量 上涨前后有哪些新披露？后续价格与成交怎样变化？ 海光信息 当天上涨，20日累计表现为负；成交低于此前均量 近期经营披露中，有哪些变化值得重新核对？ 中科曙光 20日累计涨幅居样本第一；当天成交低于此前均量 这段时间有哪些经营信息与公司事项？下一次复盘重点观察什么？ 这张表把已经看到的情况与后续工作连在一起。你可以按自己的研究目标调整先后，而不必停留在一段泛泛的行情点评里。 五、把这段任务交给AI，再换成自己的名单 在已连接上述MCP入口的AI客户端中，可以复制下面的任务，把股票名单换成自己持续跟踪的对象。 请帮我做一份A股自选股收盘复盘表。 观察名单： 688256.SH 寒武纪 688041.SH 海光信息 603019.SH 中科曙光 研究目标： 比较当天变化与近期累计表现，安排下一步查资料的顺序。 请按下面的方法处理： 1. 核对股票名称与代码，查询当前行情快照并注明数据时间。 2. 以最近一个完整交易日为复盘截止日，取得每只股票至少21根 完整交易日的前复权日线，并核对比较日期是否一致。 3. 用完整日线计算当日涨跌，以及最近20个交易间隔的涨跌； 用截止日成交量除以此前20个交易日的平均成交量，均值排除当日。 4. 输出股票、截止日、当日涨跌、20日涨跌、成交比值， 再为每只股票写一条具体的后续研究问题。 5. 写清比较起点与计算方法。数据不足或日期不齐时标明缺口。 盘中快照与完整日线分开使用，不把尚未收盘的数据当作全天结果。 6. 把已观察到的事实和仍要查的原因分开；若引用公告， 注明公告名称与日期，不补写没有来源的消息或目标价。 本次实际使用的核心工具是get_ticker和get_kline，日线参数为1d、forward。三只股票各取得25根日线，覆盖的日期与本次交易日历逐日一致；快照价格、昨收和成交量也与对应日线核对。 行情数据由工具取得，比较和表格整理由AI及计算程序完成。把研究目标、名单、时间范围和输出要求一次说清楚，后续追问就能沿着同一项任务继续。 六、用这段代码重算文中的数字 下面是从本次日线提取的最小计算输入，包含窗口起点收盘价、昨收、收盘价、当日成交量和此前20日平均成交量。 代码使用Python标准库，复制后即可运行，重算本篇示例；它不发起新的行情请求。换股票或换日期时，先取得同口径数据，再替换输入。 from decimal import Decimal as D # 名称、代码、20个交易间隔前收盘、昨收、收盘、当日量、此前20日均量 # 价格为本次取得的前复权日线口径；成交量沿用接口单位。 samples = [ ('寒武纪', '688256.SH', '929', '838', '900', '116347', '107017.75'), ('海光信息', '688041.SH', '201.46', '190', '196.35', '164721', '206017'), ('中科曙光', '603019.SH', '69.03', '78.60', '79.26', '169962', '284811.75'), ] print('股票,当日涨跌,20日涨跌,成交量/此前20日均量') for name, symbol, start, previous, close, volume, mean_volume in samples: start, previous, close, volume, mean_volume = map( D, (start, previous, close, volume, mean_volume) ) if min(start, previous, mean_volume) <= 0: raise ValueError(f'{symbol}: 计算基准必须大于0') day_change = (close / previous - 1) * 100 period_change = (close / start - 1) * 100 volume_ratio = volume / mean_volume print(f'{name},{day_change:+.2f}%,{period_change:+.2f}%,{volume_ratio:.2f}倍') 运行结果： 股票,当日涨跌,20日涨跌,成交量/此前20日均量 寒武纪,+7.40%,-3.12%,1.09倍 海光信息,+3.34%,-2.54%,0.80倍 中科曙光,+0.84%,+14.82%,0.60倍 其中，20个交易间隔的涨跌，需要用截止日与20个间隔前的收盘价比较，也就是至少21个收盘价。计算此前20日均量时，要把截止日排除。把这两个基准固定下来，换一份名单也能沿用同样的方法。 七、下次复盘，从一条明确的问题开始 下一次打开自选股，不妨先写下今晚要解决的问题：研究当天的明显变化，还是回顾近期累计表现？ 再让AI取回相应数据，把比较结果放在一起，并在观察表最后一列写下接下来要查的材料。 寒武纪当天涨7.40%，中科曙光近20个交易日涨14.82%，都值得被准确记录。它们会把研究引向不同的问题。问题明确了，你才知道有限的时间应该先花在哪里。 参考资料与数据来源： 中科寒武纪科技股份有限公司《2026年第三季度报告》，巨潮资讯网，存档日期2026年10月24日。 海光信息技术股份有限公司《2026年第三季度报告》，巨潮资讯网，存档日期2026年10月20日。 曙光信息产业股份有限公司《2026年第三季度报告》，巨潮资讯网，存档日期2026年10月28日。 行情快照、K线查询官方文档，核对日期2026年11月11日。 本文MCP实际返回与Python计算记录，样本交易日2026年11月11日。 文中股票用于展示数据研究方法，不构成投资建议。 **摘要：做行情看板、量化回测或盯盘工具时，最麻烦的往往不是业务逻辑，而是行情数据源。本文基于 DeepTick 的 REST 与 WebSocket 接口，完整演示港股、美股、A 股实时报价、历史 K 线与逐笔成交的接入方式，附 Python 可运行代码与字段说明。 一、背景 金融类应用开发中，行情数据通常需要覆盖三类能力： 快照报价：当前最新价、开高低、成交量额，用于看板、列表页； 历史 K 线：用于画图、技术指标计算与回测； 逐笔成交（Tick）：用于高频盯盘、成交明细展示。 传统做法是 HTTP 轮询，简单但延迟高、请求量大。更合理的组合是：REST 拉快照和历史数据 + WebSocket 推实时数据。本文以 DeepTick 为例，把这条链路完整走一遍。 二、接入准备 2.1 认证方式 DeepTick 的 REST 接口通过请求头 deeptoken 认证，WebSocket 在建立连接时通过 additional_headers 传入同一个 token。 python headers = { "deeptoken": "your_api_key" } 2.2 标的代码（symbol）规则 DeepTick 统一使用 代码.市场 格式，跨市场规则如下： 市场 后缀 示例 说明 港股 .HK 700.HK、9988.HK 5 位数字代码 美股 .US AAPL.US、TSLA.US 1–4 位字母 A 股沪市 .SH 601398.SH 60 开头 A 股深市 .SZ 300750.SZ、000001.SZ 00 / 30 开头 加密货币 .CR BTCUSDT.CR 加密对 注意：REST 实时报价一次只能查 1 个标的；K 线接口单次最多 20 个标的；WebSocket 可在同一订阅中混合多市场。 三、REST 接口实战 3.1 实时报价：GET /api/v1/quote 拉取单个标的的当前最新价与当日统计，不含买卖盘口，逐笔成交请走 WebSocket tick。 请求参数 参数 类型 必填 说明 symbols string 是 一个标的，如AAPL.US；传多个会返回错误码8005 Python 示例 python import requests url = "https://api.deeptick.cc/api/v1/quote" headers = {"deeptoken": "your_api_key"} params = {"symbols": "AAPL.US"} try: resp = requests.get(url, headers=headers, params=params) result = resp.json() if result["code"] == 0: q = result["data"][0] print(f"标的：{q['s']}") print(f"最新价：{q['ld']}") print(f"开盘：{q['o']} 最高：{q['h']} 最低：{q['l']}") print(f"成交量：{q['v']} 成交额：{q['tu']}") else: print("请求失败：", result["msg"]) except Exception as e: print("请求异常：", str(e)) 响应示例 json { "code": 0, "msg": "ok", "data": [ { "s": "AAPL.US", "ld": "225.215", "o": "226.27", "h": "226.92", "l": "224.44", "v": "16742235", "tu": "3774688301.452", "t": 1731689407000 } ] } 字段说明（data[] 元素） 字段 类型 说明 s string 标的代码 ld string/number 最新价 p string/number 前收 o/h/l string/number 开 / 高 / 低 v/tu string/number 成交量 / 成交额 ch/chp string/number 涨跌额 / 涨跌幅（上游无则不出现） ts int 交易状态：0正常、1停牌、2退市、3熔断，不是时间戳 t long 行情时间戳（毫秒） 这里有个容易踩的坑：ts 是交易状态而不是时间，真正的时间是 t。 3.2 历史 K 线：GET /api/v1/candles 用于补历史 K 线、绘图或回测，始终查上游、不走缓存，返回按时间升序排列。正在走的当前 K 线请订阅 WebSocket candle，不要轮询本接口。 请求参数 参数 类型 必填 说明 symbols string 是 逗号分隔，单次最多 20 个，超限返回8006 interval enum 否，默认5m 1m/5m/15m/30m/60m/4h/1d/1w/1M；1h视为60m limit int 否，默认 40 1~500，超限返回8007 et long 否 截止时间（Unix 毫秒），缺省取最新 Python 示例 python import requests import datetime url = "https://api.deeptick.cc/api/v1/candles" headers = {"deeptoken": "your_api_key"} params = { "symbols": "300750.SZ", # 宁德时代 "interval": "1d", "limit": 10 } try: resp = requests.get(url, headers=headers, params=params) result = resp.json() if result["code"] == 0: for item in result["data"]: print(f"标的：{item['s']} 周期：{item['i']}") for bar in item["d"]: dt = datetime.datetime.fromtimestamp(bar["t"] / 1000) print( f"{dt:%Y-%m-%d} 开:{bar['o']} 高:{bar['h']} " f"低:{bar['l']} 收:{bar['c']} 量:{bar['v']} 额:{bar['tu']}" ) else: print("请求失败：", result["msg"]) except Exception as e: print("请求异常：", str(e)) 响应示例 json { "code": 0, "msg": "ok", "data": [ { "s": "300750.SZ", "i": "1d", "d": [ { "t": 1723100000000, "o": "535.0", "h": "536.0", "l": "534.5", "c": "534.5", "v": "104799385", "tu": "56119888070.5" } ] } ] } 字段说明 字段 类型 说明 s string 标的代码 i enum 周期 d array K 线数组，时间升序 d[].t long 该周期时间戳（毫秒） d[].o/h/l/c string/number 开 / 高 / 低 / 收 d[].v/d[].tu string/number 成交量 / 成交额 四、WebSocket 实时推送 连接地址： text wss://api.deeptick.cc/ws/v1 一次 subscribe 必须是同一种 type（quote 或 tick），不能混写。topic 格式： 报价：quote.{market}.{symbol}，如 quote.US.AAPL、quote.HK.700 逐笔：tick.{market}.{symbol}，如 tick.US.AAPL Python 示例（需 pip install websockets） python import asyncio import json import websockets TOKEN = "your_api_key" async def main(): async with websockets.connect( "wss://api.deeptick.cc/ws/v1", additional\_headers={"deeptoken": TOKEN} ) as ws: print(await ws.recv()) # welcome await ws.send(json.dumps({ "type": "subscribe", "topics": [ "quote.US.AAPL", "tick.US.AAPL", "quote.HK.700", "tick.HK.700" ], "request\_id": "r1" })) while True: frame = json.loads(await ws.recv()) ftype = frame.get("type") data = frame.get("data", {}) if ftype == "quote": print(f"[QUOTE] {data.get('s')} 最新价:{data.get('ld')} " f"开:{data.get('o')} 高:{data.get('h')} 低:{data.get('l')} " f"量:{data.get('v')} 额:{data.get('tu')}") elif ftype == "tick": print(f"[TICK] {data.get('s')} 价格:{data.get('ld')} " f"数量:{data.get('v')} 时间:{data.get('t')}") if __name__ == "__main__": asyncio.run(main()) quote 数据帧 json { "type": "quote", "topic": "quote.US.AAPL", "ts": 1723100000000, "data": { "s": "AAPL.US", "ld": "225.215", "o": "226.27", "h": "226.92", "l": "224.44", "v": "16742235", "tu": "3774688301.452", "t": 1731689407000 } } tick 数据帧 json { "type": "tick", "topic": "tick.US.AAPL", "ts": 1723100000000, "data": { "s": "AAPL.US", "ld": "192.41", "v": "100", "t": 1723100000000 } } 外层字段 字段 类型 说明 type enum 帧类型：tick/quote/depth/candle/trade topic string 订阅 topic 原文 ts long 行情时间戳（毫秒） quote data 字段：s、ld、p、o/h/l、v/tu、ch/chp、ts（交易状态）、t（时间戳），含义同 3.1。 tick data 字段：s 标的、ld 成交价、v 成交数量、t 成交时间（毫秒）。 五、接入踩坑与注意事项 ts 不是时间：报价里的 ts 是交易状态（0 正常 / 1 停牌 / 2 退市 / 3 熔断），时间字段是 t。 数值类型不固定：字段可能是 string 也可能是 number，落库或计算前统一 float() 转换，展示保留 2 位小数。 订阅不能混 type：一次 subscribe 只能全是 quote 或全是 tick，混写会失败。 REST 单标的限制：/api/v1/quote 只接受 1 个 symbol，批量场景请用 WebSocket 订阅。 K 线上限：单次最多 20 个标的、limit 最大 500，超限分别返回 8006、8007。 频率控制：免费版建议每秒不超过 5 次请求，高频需求升级套餐。 错误处理：code != 0 时读 msg；网络超时做重试，无数据时用缓存降级。 市场差异：A 股人民币、港股港币、美股美元，交易时间也不同，展示层需针对性适配。 六、总结 整体接入思路可以归纳为一条链路： 快照类需求（看板、列表）→ REST /api/v1/quote 历史类需求（绘图、回测）→ REST /api/v1/candles 实时类需求（盯盘、成交明细）→ WebSocket quote.* / tick.* REST 负责「拉」，WebSocket 负责「推」，两者组合即可覆盖绝大多数行情场景。代码层面重点处理好三件事：字段类型统一、时间戳转换、错误码与重试。 免责声明：本文代码用于技术接入演示，不构成投资建议。行情数据的使用、展示、存储和再分发应遵守 DeepTick 服务条款及相关市场的数据授权要求。 GitHub：https://github.com/deeptick-cc/deeptick-realtime-market-data-api 平时在 SuperMind 上开发量化策略时，不知道大家有没有遇到过这样的情况： 明明已经有了比较清晰的选股思路或交易逻辑，但真正写成可运行的策略代码，还是需要花不少时间。尤其是涉及平台 API、数据获取、调仓逻辑和仓位管理时，经常需要反复修改和调试。 虽然现在 DeepSeek、ChatGPT 等通用 AI 工具也能辅助编程，但生成的代码有时会出现平台接口不匹配、函数调用错误等问题，实际运行前还需要不少调整。 最近在推广一款专门面向量化策略开发的 AI 工具——AI 量化代码助手，分享给有类似需求的朋友。 目前支持 SuperMind、QMT、PTrade、聚宽等国内主流量化平台，主要功能包括： AI 生成策略代码：直接用自然语言描述选股条件、交易信号和调仓规则，辅助生成适用于 SuperMind 的策略代码。 修改已有策略：可以在原有代码基础上调整买卖条件、选股逻辑、仓位管理和止损机制，不需要每次都从头编写。 辅助排查代码问题：帮助分析报错信息、检查代码逻辑，减少重复调试的时间。 多平台策略开发：可以针对不同量化平台的 API 和代码规范生成对应代码，方便使用多个平台的开发者。 例如，直接输入： “帮我编写一个适用于 SuperMind 的多因子选股策略，根据市盈率、ROE 和动量指标筛选股票，每周调仓一次，并设置单只股票最大持仓比例。” AI 就可以根据这些要求辅助生成对应的策略代码，后续也能继续通过自然语言修改交易逻辑。 相比通用 AI 编程工具，这类专门面向国内量化平台的助手，在平台 API 适配和策略代码开发方面可能更有针对性。 当然，AI 生成的策略仍然需要通过实际运行和历史回测验证，尤其要注意未来函数、交易成本以及策略过拟合等问题。工具主要是帮助提高开发效率，并不保证策略能够盈利。 工具地址：https://qmtai.cn/?le 也想借这个帖子和社区里的朋友交流一下： 大家平时使用 AI 编写 SuperMind 策略时，最常遇到的是 API 兼容问题，还是策略逻辑修改和代码调试方面的问题？ 欢迎交流使用经验，也希望能收集一些实际需求和建议，进一步完善工具对 SuperMind 的支持。 1.开源项目 XTick行情API提供了全面、准确、稳定的行情数据，帮助开发者和研究者构建创新的交易和分析工具，满足金融行业的需求，进行深入的市场分析和模型验证。 项目网址：http://www.xtick.top/ GitHub地址 https://github.com/xticktop/xtick API接口文档 API接口分为订阅数据、行情数据、财务数据三个部分。行情数据支持盘中实时更新。 除了订阅接口是Websocket API，其余接口为Http API接口且均支持GET和POST方法，下面以GET请求示例。 订阅数据接口 在GitHub上，已实现Java版本和Python版本的订阅代码，请先下载代码直接调用。 暂时无法在飞书文档外展示此内容 订阅数据按照证券交易所订阅推送，包括上交所、深交所、北交所、港交所（只支持部分股票）。 数据为实时推送，发数据非常快，客户端接受到数据后，最好做异步处理，将接受数据和数据处理分开，避免接受数据阻塞。 订阅方法： 订阅数据：订阅为Websocket API，请在Github上下载开源项目，参考XTickWebSocketClient.java中已实现的订阅功能。 入参1：authCodes 枚举取值如下： tick.SZ - 订阅深交所A股的tick数据。 tick.SH - 订阅上交所A股的tick数据。 tick.BJ - 订阅北交所A股的tick数据。 tick.HK - 订阅港交所港股的tick数据。 time.SZ - 订阅深交所A股的k线数据，包括time、1m。 time.SH - 订阅上交所A股的k线数据，包括time、1m。 time.BJ - 订阅北交所A股的k线数据，包括time、1m。 time.HK - 订阅港交所港股的k线数据，包括time、1m。 入参2：token 登录XTick网站，注册获取 取消订阅：http://api.xtick.top/doc/unsubscribe?token=043fbdcba7f3f3ab332ffff123456789 入参：token 登录XTick网站，注册获取 行情数据接口 请求方法： 请求地址：http://api.xtick.top/doc/market?type=1&code=000001&period=tick&fq=none&startDate=2025-03-25&endDate=2025-03-25&token=043fbdcba7f3f3ab332ffff123456789 备注：行情数据支持交易日内盘内实时更新。 入参1：type 股票类别 沪深京A股type=1，港股type=3; **入参2**：**code** 股票代码 比如平安银行为000001 **入参3**：**period** 用于表示要获取的周期，枚举取值如下： tick - 分笔数据 1m - 1分钟线 5m - 5分钟线 15m - 15分钟线 30m - 30分钟线 1h - 1小时线 1d - 日线 1w - 周线 1mon - 月线 1q - 季度线 1hy - 半年线 1y - 年线 参数4：fq 除权方式，用于K线数据复权计算，对tick等其他周期数据无效，枚举取值如下： none 不复权 front 前复权 back 后复权 front_ratio 等比前复权 back_ratio 等比后复权 参数5：时间范围，用于指定数据请求范围，表示的范围是[<b>startDate</b> ,<span> </span><b>endDate</b>]区间（包含前后边界）。 特别说明：period为tick类型，则单次请求时间跨度最大为一天，即startDate和endDate日期需设置为同一天。 period为分钟类型（包括1m、5m、15m、30m、1h），则单次请求时间跨度最大为一月，即**endDate - startDate不超过30天。** startDate - 起始时间，日期格式：2025-03-25 endDate- 结束时间，日期格式：2025-03-25 入参6：token 登录XTick网站，注册获取 财务数据接口 请求方法： 请求地址：http://api.xtick.top/doc/financial?type=1&code=000001&report=Pershareindex&startDate=2020-03-25&endDate=2025-03-25&token=043fbdcba7f3f3ab332ffff123456789 入参1：type 股票类别 沪深京A股type=1，港股type=3; **入参2**：**code** 股票代码 比如平安银行为000001 **入参3**：**report** 用于表示要获取的财务报表，枚举取值如下： Balance - 资产负债表 Income - 利润表 CashFlow - 现金流量表 Capital - 股本表 Holdernum - 股东数 Top10holder - 十大股东 Top10flowholder - 十大流通股东 Pershareindex - 每股指标 **参数4：**时间范围，用于指定数据请求范围，表示的范围是[<b>startDate</b> ,<span> </span><b>endDate</b>]区间（包含前后边界）。 startDate - 起始时间，日期格式：2025-03-25 endDate- 结束时间，日期格式：2025-03-25 入参5：token 登录XTick网站，注册获取 摘要：做黄金事件研究，怎样取得CPI公布前后的分钟行情，并判断最初涨跌是否延续？本文通过TickDB黄金历史行情API，对照6次公布后的5、15、30分钟变化，给出完整Python取数代码、逐次研究表和实际输出，帮助量化研究与数据开发人员复算结果，再按相同条件追加研究。 研究同事问“CPI公布后黄金怎么走”，你给出的结果，可能取决于观察了多长时间。 在这次核对的2026年9月11日行情里，XAUUSD前5分钟下跌约0.26%，半小时结束时却已比公布前上涨约1.09%。如果研究表只留一个“CPI后涨跌幅”，这段转向就很容易被漏掉。 要继续判断最初方向有没有延续，需要保留统一起点下的多个观察时点，再把不同公布日放到一起。本文用TickDB黄金历史K线取得六次事件的分钟数据，由Python生成逐次结果和统计摘要；读者可以直接运行代码，得到一张可以继续追加日期的研究表。 先看一次行情 研究问题才具体 9月11日这次公布后，相对公布前同一个价格起点：5分钟结束时约为−0.26%，15分钟时转为+0.30%，30分钟时约为+1.09%。 图1：2026年9月11日CPI公布前后，XAUUSD一分钟收盘报价相对公布前基准的变化。点位按分钟结束时刻排列。 如果你关注消息刚公布时的反应，就单独研究前5分钟；如果想知道最初方向是否延续，再观察15分钟和30分钟的位置。每个结果都应写明它回答的是哪段时间的问题。 另一种容易改变印象的做法，是看到金价反弹后改用低点作起点。这样得到的涨幅有它的用途，但应另列一项；与其他公布日比较时，仍沿用原先约定的基准。 把比较条件定好 再请求数据 这次研究使用以下条件： 项目 本例做法 数据对象 XAUUSD黄金报价序列 事件范围 2026年5月至10月的6次已公布月度CPI 公布时刻 每个事件当日美东08:30，按纽约时区转换 行情周期 一分钟K线 查询区间 公布前10分钟至公布后30分钟，共需40根完整分钟记录 比较起点 公布前最后一根完整分钟线的收盘报价 观察时点 公布后5、15、30分钟结束时 事件日期先按美国劳工统计局BLS归档确定，再查询行情，没有根据黄金涨跌挑选日期。 原始响应和运行结果于2026年11月10日保存。下面的采集代码已经实际完成六次请求，本文沿用这批历史数据；各次变化按未舍入报价计算。这里比较的是黄金报价序列，不能直接套成某只黄金ETF或期货合约的收益。 一分钟K线按开始时刻标记。假设公布时刻为08:30，基准取08:29那根线的收盘，前5分钟的末值取08:34那根线的收盘，也就是到08:35时结束的五根分钟线。 计算式很简单： 观察期变化 =（观察时点报价 ÷ 公布前基准报价 − 1）× 100% 按这个起点计算，才方便区分“最初反应”和“后续走势”。扩展到冬令时事件时，也让程序按事件当日纽约时区转换，避免把固定北京时间套到所有日期。 六次结果放在一起 有哪些值得继续查 CPI公布日期 公布后5分钟 公布后15分钟 公布后30分钟 2026-05-12 -0.0611% +0.1540% +0.2108% 2026-06-10 +0.5392% +0.4884% +0.1693% 2026-07-14 +1.6415% +1.5668% +1.1548% 2026-08-12 +0.0389% +0.1239% +0.3186% 2026-09-11 -0.2587% +0.2972% +1.0915% 2026-10-14 -0.9093% -1.4384% -1.3308% 5月12日和9月11日，前5分钟为负，后面转为正。6月10日最初上涨较多，半小时后回落，但仍高于公布前。10月14日三个观察时点都低于公布前。 这些差异能把后续研究的问题缩小：哪些事件的最初方向延续了，哪些发生了转向？时间拉长以后，保留了多少涨幅或跌幅？研究表留住过程，接下来才有具体日期可以回查。 平均变化和上涨次数要一起看。这六次前5分钟的平均变化约为+0.1651%，但上涨和下跌各3次。 原因可以从表里直接找到。7月14日上涨约1.64%，对均值的贡献远大于8月12日约0.04%的上涨；统计方向时，两者各记一次。均值回答幅度怎样汇总，次数记录方向出现过多少次。 再看中位数。六项从小到大排列，中间两项为−0.0611%和+0.0389%，取平均约为−0.0111%，接近零。于是，这组样本同时呈现出均值为正、中间位置接近零、涨跌次数各半的特点。 研究报告可以写得更具体：“这6次CPI公布后前5分钟，XAUUSD上涨、下跌各3次，平均变化约+0.1651%，其中一次较大上涨对均值有明显影响。”继续增加事件时，检查这些差异是否还存在。 用Python生成可以复算的研究表 程序按六个日期查询一分钟K线，保存原始响应、请求参数和取数时间，再输出event_windows.csv。全部事件计算成功后，才写出完整研究表。 代码使用Python 3.10及以上版本和requests。将自己的API Key通过安全配置放入TICKDB_API_KEY环境变量，并确认账号可查询XAUUSD及所需历史区间。环境缺少时区数据时，可安装tzdata。 先安装依赖： python3 -m pip install requests 将下面代码保存为gold_cpi_study.py： """Python 3.10+; install requests. API key: TICKDB_API_KEY.""" import argparse import csv import json import os from datetime import datetime, timezone from decimal import Decimal from pathlib import Path from statistics import median from uuid import uuid4 from zoneinfo import ZoneInfo import requests EVENTS = ["2026-05-12", "2026-06-10", "2026-07-14", "2026-08-12", "2026-09-11", "2026-10-14"] MINUTE = 60_000 def event_time(day): release = datetime.fromisoformat(day + "T08:30:00") return int(release.replace(tzinfo=ZoneInfo("America/New_York")).timestamp() * 1000) def fetch(day, out): t = event_time(day) params = dict(symbol="XAUUSD", type="forex", interval="1m", start_time=t - 10 * MINUTE, end_time=t + 30 * MINUTE - 1, limit=1000) key = os.environ["TICKDB_API_KEY"] response = requests.get("https://api.tickdb.ai/v1/market/kline", params=params, headers={"X-API-Key": key}, timeout=30) if key.encode() in response.content: raise ValueError("Unexpected credential echo") raw = out / (day + "_1m.json") raw.write_bytes(response.content) meta = dict(params=params, http_status=response.status_code, retrieved_utc=datetime.now(timezone.utc).isoformat()) raw.with_suffix(".request.json").write_text(json.dumps(meta, indent=2)) response.raise_for_status() return response.json() def calculate(day, body): data = body.get("data", {}) if body.get("code") != 0 or (data.get("symbol"), data.get("type"), data.get("interval")) != ("XAUUSD", "forex", "1m"): raise ValueError("Unexpected API result or product identity") rows = data["klines"] if any(type(row.get("time")) is not int for row in rows): raise ValueError("Expected integer millisecond timestamps") by_time = {row["time"]: row for row in rows} if len(by_time) != len(rows): raise ValueError("Duplicate minute") t = event_time(day) expected = set(range(t - 10 * MINUTE, t + 30 * MINUTE, MINUTE)) if not expected.issubset(by_time): raise ValueError("Missing expected minute; inspect the saved raw response") for time in expected: o, h, l, c = (Decimal(by_time[time][k]) for k in ("open", "high", "low", "close")) if not all(v.is_finite() and v > 0 for v in (o, h, l, c)): raise ValueError("Invalid price") if not l <= min(o, c) <= max(o, c) <= h: raise ValueError("Invalid OHLC") baseline = Decimal(by_time[t - MINUTE]["close"]) result = dict(date=day, baseline=str(baseline)) for minutes in (5, 15, 30): close = Decimal(by_time[t + (minutes - 1) * MINUTE]["close"]) result[f"change_{minutes}m_pct"] = str((close / baseline - 1) * 100) return result def main(): parser = argparse.ArgumentParser() parser.add_argument("--out", default="gold_cpi_study") args = parser.parse_args() out = Path(args.out) / uuid4().hex out.mkdir(parents=True) results = [calculate(day, fetch(day, out)) for day in EVENTS] with (out / "event_windows.csv").open("w", newline="") as file: writer = csv.DictWriter(file, fieldnames=list(results[0])) writer.writeheader() writer.writerows(results) for minutes in (5, 15, 30): values = [Decimal(row[f"change_{minutes}m_pct"]) for row in results] print(f"{minutes}m: n={len(values)}, mean={sum(values)/len(values):+.4f}%, " f"median={median(values):+.4f}%, " f"up={sum(v > 0 for v in values)}, down={sum(v < 0 for v in values)}") print("Saved:", out) if __name__ == "__main__": main() 运行： python3 gold_cpi_study.py 本次真实采集后的统计输出如下；使用留存的六份原始响应离线复算，结果一致： 5m: n=6, mean=+0.1651%, median=-0.0111%, up=3, down=3 15m: n=6, mean=+0.1986%, median=+0.2256%, up=5, down=1 30m: n=6, mean=+0.2690%, median=+0.2647%, up=5, down=1 每次运行会创建独立目录，避免覆盖上一轮留存： gold_cpi_study/ 本次运行ID/ 2026-05-12_1m.json 2026-05-12_1m.request.json 其他公布日的响应与请求记录 event_windows.csv 如果同事对某个结果有疑问，可以沿公布日期找到原始报价，再核对基准与末值。调用成功以后，还要检查所需分钟是否齐全、时间有无重复、价格是否有效；代码已经包含这些检查。缺少预定分钟或出现无效价格时，它会停止计算，保留已取得的响应供定位。 让这张表继续服务研究 先沿用相同起点和观察时长，在EVENTS中加入新的已公布日期。程序按同一规则查询和计算，方便逐次比较。若改为其他标的、周期或跨休市区间，则应同步调整预期分钟与完整性检查。 这里的30分钟变化仍相对公布前基准。如果想研究“第5分钟至第30分钟”，应另以第5分钟的报价作起点计算，避免把两个问题混在一起。 准备解释行情原因时，再补充CPI实际值与公布前一致预期，并对齐同期利率、美元等变量。世界黄金协会2022年9月22日的一篇研究就记录过：高通胀支持黄金的同时，利率上升和强美元也形成了压力。这个历史背景提示了继续查哪些条件；具体到本次六个事件，还要分别补齐相应数据。 本文的取数流程按标的、周期和时间区间查询黄金历史行情，研究程序负责比较与统计。需要把同样的方法用于自己的黄金或外汇区间时，可参考统一实时行情数据 API 的 GitHub 仓库（地址见文末资料），先核对所需数据，再扩展研究。 六次记录先帮助我们把问题展开。若要继续设计交易策略，再明确何时产生信号、用什么价格成交，并加入点差、滑点和费用。研究表中的上涨次数描述历史方向，策略结果还需要按这些交易条件重新计算。 下一次交给研究同事的，可以是一张逐次表、一段明确的计算方法和对应原始数据。读者既能看见走势，也能追着具体日期复查判断。 资料与数据来源 美国劳工统计局BLS，2026年5月12日、6月10日、7月14日、8月12日、9月11日、10月14日CPI新闻稿归档，用于核对公布日期与美东08:30的公布时刻。 TickDB历史K线接口，XAUUSD一分钟行情；本文所用六事件原始响应与采集程序运行结果于2026年11月10日保存。 世界黄金协会，2022年9月22日，Why has gold not performed better in 2022 despite high inflation?，用于多因素研究的历史背景。 统一实时行情数据 API 的 GitHub 仓库：https://github.com/TickDB/tickdb-unified-realtime-marketdata-api，供核对接口相关信息。 快速锁定市场主线的重要性 在股票交易中，能否快速准确地锁定当前的主线板块，是提升整体决策效率与交易胜率的关键所在。许多散户投资者面对海量盘面信息时，往往感到无从下手，容易错失市场主流行情。本文将基于同花顺行情软件，为大家分享一套简单、高效且易于落实的实操筛选方法，帮助大家在盘中快速定位市场核心关注点。 核心实操：定位主线板块的步骤 想要在同花顺软件中快速找准主线，只需按照以下步骤进行清晰的参数配置与页面跳转： 第一步：进入软件板块页面 路径：同花顺行情 -> 板块页面 -> 热点板块 具体操作流程如下： ●打开 同花顺行情 软件。 ●在主界面中点击进入 板块页面。 ●在板块页面中找到并定位到 热点板块 区域。 第二步：调整关键指标与时间周期 进入热点板块区域后，需要对右上角的参数进行两项关键设置： ●将右上角的默认指标 涨幅 修改为 涨停加速。 ●将右上角的时间周期（日期）修改为 10****日。 第三步：观察数据表头与连续涨停现象 完成上述设置后： ●仔细观察页面下方表头展现的数据列表，重点对齐“概念”列与“涨停加速”列的数据。 ●重点监测列表中是否有特定概念频繁、重复地出现，并同步观察其涨停加速的数据表现。 判定标准：如何确认真正的“主线板块” 经过上述筛选后，如何确信所看到的板块就是当前市场的核心主线？可以依据以下确凿的量化标准进行判定： 主线板块核心判定法则： 在数据列表中，如果反复出现某个概念，并且该概念的涨停加速连续超过十个（>10个），那么大概率这块区域就是当前的主线板块。 总结 为了方便大家记忆与日常盘中对照应用，现将本次实操要点梳理如下： ●工具选择：同花顺行情 -> 板块页面 -> 热点板块 ●关键设置：指标由“涨幅”改为“涨停加速”，日期改为“10日” ●核心法则：概念反复出现 + 涨停加速连续超10个 = 当前主线板块 为什么天天盯盘不如“会休息”的人赚钱？ 在A股市场摸爬滚打多年，老哥我总能看到两类截然不同的散户： 第一类人，每天从开盘盯到收盘，频繁买卖、来回折腾，恨不得把每一分钱都塞满股票。结果却深陷“买入就跌、卖出就涨”的怪圈，一年到头亏得惨不忍睹； 而另一类人，一年到头根本不频繁操作，把大把的时间用来钓鱼、旅游，账户收益率却比天天盯盘的人稳健得多。 他们既不靠内幕消息，也不靠虚无缥渺的运气，而是看清了一个被绝大多数散户忽略的交易真相： 在A股，三分靠技术，七分靠节奏。 说实话，这种躲坑保命的门道，平时很少有人愿意完整讲清楚。今天老哥就把这个真相摊在你面前：一年365天，真正能让你亏大钱的致命行情，大概率就集中在四个特定的时间窗口。剩下的300多天，就算你瞎折腾也亏不到哪去。 只要你能踩准节奏，在这四个危险节点忍住不动、果断减仓或空仓，一年下来就能轻松甩开绝大多数盲目折腾的股民，一年少亏一半钱！ 节点一：年末枯水期（12月中旬至春节前两周）—— 资金面三重“抽水” 每年的12月15****日至春节前两周，是全年最确定的下跌窗口，闭着眼睛都能预判。这绝非普通的短期调整，而是市场活水被持续抽干的“枯水期”。在此期间，市场会同时启动“三台抽水机”： 第一重抽水：银行年中**/**年底结算 每年12月，万亿级别的机构资金必须例行回流。券商、公募、私募账面上的资金都需要上交结算，市场里的活水一夜之间大幅减少。 第二重抽水：公募排名战收官 到了11月，公募基金的全年排名基本定局。进入12月后，基金经理的首要目标是保住净值、规避风险以锁定年终奖。他们不仅不会主动发起进攻，反而会为了防范风险而主动减仓出货。 第三重抽水：游资私募分红兑现 年末客户要拿钱过年，私募与游资面临集中赎回压力，机构只能被迫卖出股票换取现金。 市场现象与应对策略 在此阶段，市场最典型的特征就是成交量直接萎缩3成以上。盘面多陷阱，偶有冒出的阳线基本都是“一日游”行情，再大的利好也难以拉动指数。 就像用吸管抽水塘，越抽越干。 【操作指令】：12月15****日之后，必须将账户仓位压低至3成以下。除了跨年主线外，其余个股全相当做包袱处理。在此阶段不求赚大钱，以守住本金为第一要务。 节点二：财报审判期（4月下旬）—— 密集避雷与“丑媳妇”破灭 4****月下旬是上市公司年报与一季报集中披露的最后期限，也是题材股集体暴雷的高发期。 过往经验表明：凡是拖到最后五个交易日（4月25日之后）才发布年报的公司，一多半业绩都极其难看。 道理很简单，“丑媳妇总要见公婆”，业绩拿得出手的公司早早就提前披露了，拖到最后一天才交卷的，基本都是拿不出手的成绩单。更糟糕的是，年报难看的，一季报往往更为恶劣。在年报与一季报的双重打击下，一旦业绩出现断层，机构投资者会毫不犹豫地选择“一键清仓”，瞬间引发踩踏式抛盘。 🚨 核心警示：宁可杀错，绝不抱侥幸！ 股价涨起来需要三天，但业绩暴雷跌下去只需要一瞬间。4月25****日之后才披露财报的题材股，一律当做“地雷”看待。这个阶段的核心任务是排雷而非选股。账户内仅保留业绩已经落地且超预期的优质蓝筹股，其余股票哪怕处于小幅亏损状态，也要果断卖出离场！ 节点三：中报证伪期（8月下旬）—— 炒作泡沫破裂，现金为王 上半年的各种故事和概念炒作，到了8****月下旬的中报披露期就要面临最终兑现。 回想上半年，各种新概念铺天盖地，脱离基本面也能暴涨。但在7月之前市场炒的是预期，到了8月底，机构不再听动听的故事，只看真实的财报数据。 咱们来算一笔硬账： ●如果一只股票在上半年上涨了****50%，但最终公布的中报业绩增速却不足****20%，这就是典型的估值泡沫。 面对这种业绩无法匹配涨幅的标的，机构会毫不留情地一键清仓砸盘。 【操作指令】：在8月20****日之前，必须执行“去弱留强”策略。账户仅保留业绩超预期的行业龙头标的；对于那些纯粹蹭概念、缺乏业绩支撑的跟风杂毛股，必须坚决割掉、一股不留！此阶段务必保持现金为王。 节点四：杀伤力最强！年末获利了结期（10月下旬至11月初）—— 主力撤退陷阱 这是全年杀伤力最强、套人最多、亏损最冤的时间窗口，发生在10月25日至11****月初。这一阶段本质上是主力资金的战略大撤退窗口。 在“金九银十”行情刚热闹完之后，大盘指数看似平稳、没有大跌，但你手中的暴涨个股突然砸下一根大阴线。很多散户看到指数没事，往往会误以为这只是普通的“洗盘”，甚至盲目加仓抄底，结果一步就被套在山顶。 老哥明确告诉你：这根阴线绝非洗盘，而是主力机构全年业绩目标落地后的不计成本出货与锁定利润。基金经理的核心任务是稳住排名、保住年终奖，此时冲进去抄底，无异于给机构的年终奖买单！前期涨得越猛的股票，后续砸盘越凶狠。 🚨 核心警示：严禁抄底，切防杀伤！ 10月25****日之后，必须立刻切换为**“旁观者模式”（绝对空仓/****纯观望）**。坚决做到：不开新仓、不盲目抄底、不轻信任何利好消息，管好账户资金。 记住，10月底前后的市场吃人不吐骨头！ 四句保命口诀与避险图表 为了方便大家记忆与日后对照，老哥将全年的四个防守节点浓缩为四句保命口诀： 12****月防资金慌， 4****月小心业绩伤， 8****月中报要证伪， 10****月警惕要空仓。 记牢一句话：在A股，三分靠技术，七分靠节奏。就算你一个技术指标都不看，只要牢记这四个窗口，一年下来也能比大多数散户少踩一半大坑。 摘要：面向参与股票报价看板交付的产品与开发人员，本文把“接入实时行情”拆成页面功能、数据口径和验收条件，说明报价、K线、盘口与成交明细各自何时需要。结合一份TickDB美股实际返回，给出数据需求表、样本获取步骤、完整Python检查程序和运行结果，帮助团队在开发界面之前确认数据是否支持已承诺的功能。 做一个股票报价看板，最先接通的往往是价格：请求成功，页面也出现了数字。 继续开发时，问题会逐渐变具体：涨跌幅相对哪个价格？休市后保留什么状态？盘口和成交记录的时间为什么与主报价不同？历史K线、逐笔成交和扩展交易时段，是否都要放进首版？ 这些问题需要产品和技术共同确定。接口清单只告诉我们能请求什么；交付还要明确页面展示什么、采用什么口径，以及数据不足时怎样回应。 一个实用的顺序是：先定页面功能，再选数据，最后写验收条件。下面以美股自选报价看板为例，完成一份数据需求表，再用保存的真实返回做一次本地结构检查。 一、先给首版划定范围 本文的产品需求是构造案例：首版展示自选股票身份、所选交易时段的价格与涨跌，支持持续更新和数据过期提示；示例先选择常规交易时段，暂不提供盘口分析、成交明细、扩展时段切换和历史研究。 如果你的产品以历史走势或买卖价差为主要功能，相应数据就应进入首版。优先级取决于用户要完成的任务。 把“实时行情”拆成下面四项，开发任务会更明确： 需求 需要写清的内容 对象 目标市场、完整自选清单、代码和名称的对应关系 口径 价格属于哪个时段，涨跌相对哪个参考值 更新 目标时段内，什么条件下认定数据过期 异常 证券不存在、没有权限、字段缺失或连接中断时的页面行为 例如，“接上WebSocket”是一项实现任务；“目标时段内持续更新，更新停止后显示过期状态”是一项产品验收要求。两者需要通过应用逻辑连接起来。 图1：AI方法示意图。不同功能需要不同数据，历史、盘口或成交是否进入首版，由本次需求决定。 二、报价、K线、盘口与成交分别支持什么功能 1. 报价展示：身份、时间和参考值一起处理 首版报价列表至少需要建立证券身份、市场、币种与价格之间的明确关系。名称和币种可以来自目录或参考资料，报价响应则按自己的字段契约核对。 涨跌幅也需要有参考值。TickDB报价文档说明，除核心报价字段外，其他字段会根据产品、时段及可用性按条件返回。某条样本返回参考昨收和涨跌幅，不代表每只股票、每个时段都必然返回。 字段缺失时，界面应显示未提供或暂不可用。填成零涨跌会改变信息含义。如果自己计算涨跌幅，还要确认价格和参考值的时段与统计口径匹配。 时间至少保留两类：行情时间和接收时间。前者属于市场记录，后者属于程序获取过程。过期判断还需要交易时段规则：休市后保留最后一条目标时段报价，可以是正常状态；目标时段内停止更新，则需要明确提示。 2. 历史走势：先确定区间和周期 要展示历史曲线，就需要相应周期与范围的K线，并约定复权方式、缺失记录和未结束周期的处理。 当前报价功能不必因为接口提供多年历史而提前建设回测模块。即使曲线已经画出，是否适合回测仍涉及历史证券样本、数据版本和研究设计，需要另行判断。 3. 盘口：用于观察可见买卖报价 最新成交价描述已经发生的交易；盘口描述返回时可见的买卖报价及数量。观察价差需要对应买卖报价，观察价格层级时才进一步需要相应深度。 页面应按实际返回档数展示，处理单侧为空和档数不足。可见挂单可能变化，不能把静态盘口显示为保证可成交的价格和数量。 4. 成交明细：先约定记录范围 最近成交接口提供的是一个记录窗口。返回三条或一百条，不代表已经取得整天成交历史。 如果功能承诺连续记录，就需要进一步设计持续接收、断线处理、去重和缺口检查。反复刷新最近记录，不能直接作为完整归档的验收依据。 三、把功能选择写成数据需求表 下面是本文假设看板的填写示例。它用于需求与开发交接，尚不是已上线系统的验收报告。 功能与优先级 必要数据 可后加能力 验收方法 证券识别：首版 代码、名称、市场、币种及映射 跨市场搜索 逐项核对完整自选清单，检查代码与单位 价格展示：首版 目标时段价格和行情时间 扩展时段切换 价格、时间和时段标签采用同一对象 涨跌展示：首版 匹配口径的涨跌字段或计算基准 更多统计指标 核对参考值；缺失不填零 更新与异常状态：首版 更新记录、行情时间、接收时间和错误状态 增强恢复机制 测试目标时段更新及中断后的过期提示 历史走势：本示例后加 目标周期的K线 更多周期与研究工具 核对范围、复权、缺失及周期完成状态 盘口或成交：本示例后加 与选定功能匹配的买卖报价或成交记录 深度分析或连续归档 检查实际档数、记录范围、时间、数量单位与空态 这张表还应附上目标账户、预期负载和使用对象。内部研究、内部看板和客户展示的使用条件分别确认。目录里能找到证券，也不代表当前账户已经拥有所有相关数据权限。 后加功能如果进入首版，它的数据与异常处理也要一起进入验收范围。 四、先取真实样本，再开始写字段映射 本文使用TickDB提供的股票数据，通过已经连接的MCP取得一份美股样本。MCP适合这里的按需查询；本文没有用它验证持续推送，也没有在本例重新运行REST或WebSocket。 2026年11月10日，先从US股票目录核对Apple身份，再对AAPL.US分别查询报价、盘口与最近三条成交。目录中的代码为AAPL，报价工具使用AAPL.US；关联时同时核对市场与工具的代码规范。 实际返回摘要如下，未展示行情价格值： 模块 返回结构 数据时间，UTC 主报价 包含证券代码、价格、参考昨收、涨跌幅及时间字段 2026-11-09 21:00:01 盘口 买侧1档、卖侧1档 2026-11-10 04:01:56.484 最近成交 请求3条，返回3条，记录标签为overnight 2026-11-10 04:00:42至04:01:51 取数记录位于2026年11月10日UTC 04:01这一分钟。这是几次独立查询，不是同一时刻的原子快照，也不用于计算端到端延迟。 报价响应还包含扩展时段对象。页面若选择常规时段，就需要核对所选字段与时段要求是否一致；以后增加夜盘，必须同时处理夜盘价格、时间和标签。不能只选一个更晚的时间，配上另一个对象的价格。 在自己的MCP客户端取得输入文件 前提是客户端已经连接TickDB MCP，并配置了自己的有效凭证。密钥留在本地配置中，不放进下面的任务文本。 先调用get_available_symbols，在US股票目录中确认Apple。 可使用market="US"、type="stock"、limit=1000、offset=0； 如果目标不在这一页，按实际分页继续查找，不能视作不支持。 随后查询AAPL.US： 1. get_ticker：symbols="AAPL.US"，type="stock"； 2. get_order_book：symbol="AAPL.US"，type="stock"； 3. get_recent_trades：symbol="AAPL.US"，type="stock"，limit=3。 将工具返回的完整业务JSON（包含code、message、data），分别保存为 ticker_raw.json、depth_raw.json、trades_raw.json，并另记取数时间。 不要保存客户端界面截图或带text/content包装的展示文本来替代业务JSON。 失败时保留实际错误，不补造成功文件。 样本结构可用于检查字段映射。完整标的清单、持续更新、页面过期状态、账户等级和客户展示条件，本例没有验证，需要按需求表继续完成。 五、用完整Python程序检查保存的JSON 环境与文件布局 需要Python 3.10或以上版本，只使用标准库。程序不联网，不需要API Key，也不会输出行情价格。它读取三个保存文件，检查业务状态、证券一致性和必需报价字段，再整理各模块的结构与时间。 文件放在同一目录： quote-api-check/ ├── check_sample.py ├── ticker_raw.json ├── depth_raw.json └── trades_raw.json 将下面代码保存为check_sample.py： """Python 3.10+; inspect saved TickDB MCP payloads, without network calls.""" import csv import json from datetime import datetime, timezone from pathlib import Path def read_payload(filename): payload = json.loads(Path(filename).read_text(encoding="utf-8-sig")) if payload.get("code") != 0: raise ValueError(f"Unsuccessful API response: {filename}") return payload["data"] def utc(value): if type(value) is not int or value < 0: raise ValueError("Expected a nonnegative millisecond timestamp") return datetime.fromtimestamp(value / 1000, timezone.utc).isoformat() def main(): symbol = "AAPL.US" quotes = read_payload("ticker_raw.json") matching = [row for row in quotes if row.get("symbol") == symbol] if len(matching) != 1: raise ValueError("Expected exactly one matching quote") quote = matching[0] book = read_payload("depth_raw.json") tape = read_payload("trades_raw.json") if book.get("symbol") != symbol or tape.get("symbol") != symbol: raise ValueError("The payloads refer to different symbols") required = ("last_price", "timestamp") if any(quote.get(key) is None for key in required): raise ValueError("Missing a required quote field") bids, asks, trades = book["bids"], book["asks"], tape["trades"] times = [row["timestamp"] for row in trades] rows = [ ["quote", symbol, "required_fields_present", utc(quote["timestamp"])], ["depth", symbol, f"bids={len(bids)};asks={len(asks)}", utc(book["timestamp"])], ["trades", symbol, f"rows={len(trades)}", f"{utc(min(times))} to {utc(max(times))}" if times else "empty"], ] with Path("sample_check.csv").open("w", newline="", encoding="utf-8-sig") as file: writer = csv.writer(file) writer.writerow(["module", "symbol", "observed_structure", "data_time_utc"]) writer.writerows(rows) for row in rows: print(" | ".join(row)) print("Saved sample_check.csv; structure check only, not release approval") if __name__ == "__main__": try: main() except (OSError, ValueError, TypeError, KeyError) as error: raise SystemExit(f"STOP: {error}") 运行方式与实际输出 在上述目录运行： python3 check_sample.py 使用本文2026年11月10日保存的样本，本地运行输出为： quote | AAPL.US | required_fields_present | 2026-11-09T21:00:01+00:00 depth | AAPL.US | bids=1;asks=1 | 2026-11-10T04:01:56.484000+00:00 trades | AAPL.US | rows=3 | 2026-11-10T04:00:42+00:00 to 2026-11-10T04:01:51+00:00 Saved sample_check.csv; structure check only, not release approval sample_check.csv使用UTF-8 BOM编码保存，便于Excel或WPS打开。使用自己的新样本时，数量和时间应以实际返回为准，不要求复现上面的数值。 程序还有两个停止条件：业务响应失败时输出STOP: Unsuccessful API response...；盘口或成交指向另一只证券时输出STOP: The payloads refer to different symbols。这两个错误分支已用单独的负向测试输入检查，未修改原始行情文件。 怎样理解检查结果 required_fields_present表示程序要求的字段在样本中存在。它不判断市场数据是否正确，不校验参考昨收的业务口径，也不会自动认定数据属于页面要求的交易时段。 同样，盘口每侧1档、成交3条，仅是本次观察。程序没有检查连续运行、成交完整性或页面异常状态，不能把CSV生成成功当成上线验收完成。 图2：AI方法示意图。样本结构检查之后，还要按目标时段、正常与异常状态继续验收。 六、开始开发前，留下一个可共同核对的交付依据 完成这一步，应能交出三份材料：填好的功能与数据需求表、保留时间及条件的真实样本、可逐项执行的验收清单。 需求表解释为什么要这类数据；样本帮助开发者看到实际字段与返回范围；验收清单说明更新正常、停止或缺失时应发生什么。首版是否完成，由这三份材料共同判断。 可以先挑一个已经承诺的功能，把它的数据、时段、缺失行为和验收方法写完整。接口、权限及后续数据模块，就能围绕具体任务来选择。 代码与接入参考 TickDB的公开工具仓库包含MCP服务端实现与Skill接入资料，适合在复现查询或检查客户端配置时参考： https://github.com/TickDB/tickdb-unified-realtime-marketdata-api 仓库中的mcp/用于MCP服务端与接入参考，SKILL/包含对应的工具说明。本文的check_sample.py完整代码见第五节；仓库链接用于接入资料，不表示本文程序或样本已收录到仓库。公开工具代码的许可与行情数据使用权限应分别确认，实际数据调用仍需相应凭证和权限。 资料日期：2026年11月10日。行情样本来自当日TickDB MCP调用；GitHub仅作工具与接入参考。产品需求为构造案例，使用条件按目标市场、账户和用途确认。 一、为什么实时行情更适合使用 WebSocket？`` 股票、外汇、指数、贵金属和加密资产等行情具有持续变化的特点。对于实时盯盘、行情看板、量化监控和风险预警系统，客户端如果反复通过 HTTP 轮询获取数据，不仅会产生大量重复请求，也难以在请求间隔与服务端负载之间取得平衡。 WebSocket 建立长连接后，服务端可以在数据发生变化时主动推送，客户端也可以通过同一连接发送订阅请求。相比固定间隔轮询，这种模式更适合持续行情流。需要注意，WebSocket 只解决通信方式问题，端到端延迟仍受到数据源、网络距离、服务端处理、客户端消费速度等因素影响，不能仅凭使用 WebSocket 就承诺固定的毫秒级延迟。 1.1 典型应用场景 · 实时行情看板：订阅关注标的的实时报价，展示最新价格、涨跌幅和成交量，并与实时 K 线图表联动。 · 盘口监控：订阅买卖盘深度，观察挂单结构和盘口变化。 · 量化监控：将行情流接入策略监控、告警或内部消息总线。 · K 线图表：接收正在形成的 K 线，按标的和周期增量更新图表最后一根 K 线；报价数据用于同步展示最新成交/报价信息。 二、DeepTick WebSocket 接入流程 DeepTick WebSocket 接入地址为 wss://api.deeptick.cc/ws/v1。连接时在握手请求头中携带 deeptoken，连接建立后服务端会发送 welcome 消息。与原稿中使用的其他行情服务协议不同，DeepTick 使用 Topic 订阅模型：客户端发送 type=subscribe、topics 和 request_id 等字段；订阅请求应按同一种行情类型组织，不能将不同类型的 Topic 混在同一条订阅请求中，否则整批订阅可能失败。 2.1 接入前准备 · 在 DeepTick 平台申请 API Token，并通过环境变量保存，不要将密钥写入前端代码或提交到代码仓库。 · 准备 Node.js 运行环境，本文示例使用 ws 库作为 WebSocket 客户端及服务端。 · 确认要订阅的市场、标的代码和数据类型，并按 DeepTick 文档中的 Topic 规则生成订阅主题。 npm init -y npm install ws 2.2 连接与鉴权 下面示例展示 Node.js 如何在 WebSocket 握手阶段传递 deeptoken，并等待服务端首帧 welcome。示例没有再发送旧协议中的 auth 指令；认证信息随连接请求头提交。 const WebSocket = require("ws"); const WS_URL = "wss://api.deeptick.cc/ws/v1"; const TOKEN = process.env.DEEPTICK_API_TOKEN; if (!TOKEN) { throw new Error("请先设置环境变量 DEEPTICK_API_TOKEN"); } function connectDeepTick() { const ws = new WebSocket(WS_URL, { headers: { deeptoken: TOKEN } }); ws.on("open", () => { console.log("WebSocket transport connected"); }); ws.on("message", (buffer) => { const raw = buffer.toString(); let message; try { message = JSON.parse(raw); } catch { console.warn("收到非 JSON 消息：", raw); return; } // DeepTick 建连后会发送 welcome 首帧。 if (message.type === "welcome") { console.log("DeepTick welcome:", message); // 在这里启动订阅流程。 return; } handleDeepTickMessage(message); }); ws.on("error", (err) => { console.error("DeepTick WebSocket error:", err.message); }); ws.on("close", (code, reason) => { console.warn("DeepTick connection closed:", code, reason.toString()); }); return ws; } function handleDeepTickMessage(message) { if (message.type === "ack") { console.log("订阅回执:", { accepted: message.accepted || [], rejected: message.rejected || [] }); return; } // 行情推送通常包含 topic 与 data。 if (message.topic) { console.log("行情推送:", message.topic, message.data); return; } console.log("其他服务端消息:", message); } const ws = connectDeepTick(); 复制 三、订阅行情：使用 Topic 模型 DeepTick 的订阅请求采用 JSON 消息，核心字段包括 type、topics 和 request_id。下面以港股腾讯控股为例，实时报价 Topic 使用 quote.HK.00700；实时 K 线 Topic 则应按官方实时 K 线文档中的市场、标的和周期规则配置。报价与 K 线属于不同的行情类型，必须分成两条订阅请求发送。 function sendSubscribe(ws, topic) { if (ws.readyState !== WebSocket.OPEN) { throw new Error("WebSocket 尚未处于 OPEN 状态"); } const request = { type: "subscribe", topics: [topic], request_id: `sub-Date.now()-{Math.random().toString(16).slice(2)}` }; ws.send(JSON.stringify(request)); } // welcome 到达后调用：不同数据类型分开发送。 function subscribeHongKongExample(ws) { sendSubscribe(ws, "quote.HK.00700"); sendSubscribe(ws, "depth.HK.00700"); } 复制 生产代码建议将 Topic 列表按行情类型分组后逐组发送，并为每次请求生成唯一 request_id。收到 ack 后检查 accepted 与 rejected，不能只根据 send() 没有抛错就认定订阅成功。 3.1 订阅关系管理建议 · 在业务服务中维护“客户端 ID → Topic 集合”的映射，客户端断开时清理对应关系。 · 对相同 Topic 做去重，避免重复订阅造成无效请求。 · 区分客户端订阅与上游 DeepTick 订阅：多个前端订阅同一 Topic 时，上游可共享一份订阅，再由业务服务向多个客户端分发。 · 订阅失败时记录 request_id、Topic、错误回执和时间，便于定位参数错误或套餐权限问题。 四、心跳、断线重连与订阅恢复 长连接可能因为网络抖动、代理超时、服务端维护或客户端网络切换而断开。工程上需要将心跳检测、连接状态管理、重连退避和订阅恢复组合起来。DeepTick 文档提供心跳与短时间中断后的续传能力，实际项目应按官方心跳文档规定的消息格式、间隔和续传参数实现，不应继续沿用其他服务商的 ac=ping 或 pong 消息结构。 下面的 Node.js 片段使用 ws 库的 WebSocket 控制帧 ping/pong 做本地连接存活检测示例。它属于客户端链路健康检查示范，不代表替代 DeepTick 文档规定的应用层心跳或续传协议；如果官方文档要求特定 JSON 心跳消息，应以官方定义为准。 function attachHeartbeat(ws, intervalMs = 30000, timeoutMs = 10000) { let pongReceived = true; ws.on("pong", () => { pongReceived = true; }); const timer = setInterval(() => { if (ws.readyState !== WebSocket.OPEN) return; if (!pongReceived) { console.warn("心跳超时，主动关闭连接"); ws.terminate(); return; } pongReceived = false; ws.ping(); }, intervalMs); ws.on("close", () => clearInterval(timer)); ws.on("error", () => clearInterval(timer)); } 复制 4.1 自动重连与重新订阅 重连成功后，客户端需要重新发送仍然有效的 Topic 订阅。重连建议使用指数退避并增加随机抖动，避免服务端或网络故障恢复时大量客户端同时冲击连接入口。对于 DeepTick 文档支持的短时续传能力，应按文档约定保存续传所需的状态或标识，并在重连后执行补续流程；不要自行假设服务端会自动补齐所有离线期间的数据。 const desiredTopicsByType = { quote: ["quote.HK.00700"], depth: ["depth.HK.00700"] }; function resubscribe(ws) { for (const topics of Object.values(desiredTopicsByType)) { for (const topic of topics) { sendSubscribe(ws, topic); } } } function reconnectWithBackoff(start, attempt = 0) { const base = 1000; const max = 30000; const delay = Math.min(max, base * (2 ** attempt)); const jitter = Math.floor(Math.random() * 500); setTimeout(() => { const ws = start(); ws.once("open", () => { // 生产环境应等待 DeepTick welcome 后再恢复订阅。 // welcome 到达后调用 resubscribe(ws)。 }); ws.once("close", () => { reconnectWithBackoff(start, attempt + 1); }); }, delay + jitter); } 复制 五、实时 K 线订阅与处理 实时 K 线与普通报价是不同的数据类型。DeepTick 的实时 K 线能力用于订阅正在形成的 K 线，客户端收到更新后通常应更新图表的最后一根 Bar，而不是每次都把全部历史数据重新绘制。 K 线 Topic 的具体组成、周期参数、消息字段以及是否支持某些周期，必须以 DeepTick 实时 K 线文档为准。下面将 K 线 Topic 作为配置项传入，避免将其他行情服务商的 kline@1、ac=subscribe 等旧格式误用到 DeepTick。请将示例中的 CANDLE_TOPIC 替换为文档中与你的市场、标的和周期对应的完整 Topic。 // 请按 DeepTick「实时 K 线」文档填写准确的 Topic。 const CANDLE_TOPIC = process.env.DEEPTICK_CANDLE_TOPIC; function subscribeCandle(ws) { if (!CANDLE_TOPIC) { throw new Error("请配置 DEEPTICK_CANDLE_TOPIC"); } sendSubscribe(ws, CANDLE_TOPIC); } function handleCandleMessage(message) { if (!message.topic || !message.data) return; // 先保留原始字段，避免在未核对数据字典前误判字段含义。 const candle = message.data; console.log("实时 K 线更新:", { topic: message.topic, data: candle }); // 接入图表时，根据 DeepTick 文档字段映射为： // { time, open, high, low, close, volume } // 时间戳单位、成交量口径和周期边界均应按接口文档确认。 } 复制 5.1 K 线图表更新要点 · 历史 K 线可先通过 REST 接口加载，WebSocket 负责更新当前正在形成的 K 线。 · 同一根 K 线可能多次更新，应按标的、周期和 K 线时间定位并覆盖更新，而不是简单追加重复 Bar。 · 确认时间戳单位是秒还是毫秒，并统一转换到图表库要求的时间格式。 · 断线恢复后，结合官方续传能力和 REST 历史 K 线查询补齐缺口，再继续处理实时推送。 六、实时报价与实时 K 线联动 实时报价与实时 K 线面向不同的展示需求：报价流用于刷新最新价格、涨跌幅等即时行情摘要；K 线流用于更新图表中正在形成的 Bar。实际页面可以同时展示报价卡片和 K 线图，但上游订阅时应将两种行情类型拆成独立请求。 6.1 实时报价订阅 复制 DeepTick 实时报价 WebSocket 用于订阅后持续接收标的的最新报价。以下以港股腾讯控股为例，使用 quote.HK.00700 作为报价 Topic。收到消息后先保留服务端原始 data，并依据实时报价文档的数据字典映射字段，不要在未确认字段定义前假设价格、成交量或时间戳字段名称。 const QUOTE_TOPIC = "quote.HK.00700"; function subscribeQuote(ws) {\n sendSubscribe(ws, QUOTE_TOPIC);\n} 复制 6.2 报价与 K 线双订阅 下面将实时报价与实时 K 线放在同一条 WebSocket 连接中管理。两次 sendSubscribe() 会分别发送订阅请求，符合“同一条订阅请求只订阅同一种行情类型”的要求。请通过环境变量配置与当前市场、标的和周期匹配的 K 线 Topic；其具体格式以 DeepTick 实时 K 线文档为准。 const QUOTE_TOPIC = "quote.HK.00700";\nconst CANDLE_TOPIC = process.env.DEEPTICK_CANDLE_TOPIC;\n\nfunction subscribeQuoteAndCandle(ws) {\n if (ws.readyState !== WebSocket.OPEN) {\n throw new Error("WebSocket 尚未处于 OPEN 状态");\n }\n if (!CANDLE_TOPIC) {\n throw new Error("请配置 DEEPTICK_CANDLE_TOPIC");\n }\n\n // 报价和 K 线分开发送，不要合并成一条混合类型订阅。\n sendSubscribe(ws, QUOTE_TOPIC);\n sendSubscribe(ws, CANDLE_TOPIC);\n} 复制 6.3 统一处理两类行情消息 收到推送后，可根据服务端返回的 topic 将消息分流到报价处理器或 K 线处理器。下面的示例只负责消息路由并保留原始数据；字段映射、时间戳单位和 K 线周期边界应严格依据对应官方文档确认。 function handleMarketMessage(message) {\n if (!message || !message.topic || message.data == null) return;\n\n if (message.topic === QUOTE_TOPIC) {\n handleQuoteMessage(message);\n return;\n }\n\n if (message.topic === CANDLE_TOPIC) {\n handleCandleMessage(message);\n return;\n }\n\n console.log("收到其他行情推送:", message.topic, message.data);\n}\n\nfunction handleQuoteMessage(message) {\n // 按实时报价文档映射最新报价字段，再更新行情卡片。\n console.log("实时报价更新:", message.data);\n}\n\nfunction handleCandleMessage(message) {\n // 按实时 K 线文档映射 OHLCV，再更新图表最后一根 Bar。\n console.log("实时 K 线更新:", message.data);\n} 复制 6.4 前端展示与数据一致性 报价卡片与 K 线图应使用同一标的标识，并分别维护各自的数据状态。报价到达时只更新报价区域；K 线到达时按标的、周期和 K 线时间定位并更新当前 Bar。不要将每一条报价消息直接当作一根 K 线，也不要将重复到达的同一根 K 线简单追加到图表末尾。 页面初始化时可先通过历史行情接口加载图表所需的历史 K 线，再启动 WebSocket 实时报价和实时 K 线订阅。收到订阅确认后再将数据流状态标记为正常；重连后重新订阅，并结合官方续传能力或历史接口处理可能存在的数据缺口。 七、从示例走向生产环境：架构与优化 7.1 推荐架构 一个常见的行情接入架构可以拆分为四层： · 数据接入层：维护与 DeepTick 的 WebSocket 连接，负责鉴权、订阅、心跳、重连和消息解析。 · 消息处理层：完成字段标准化、时间戳校验、重复消息处理和必要的业务计算。 · 缓存与消息分发层：将最新行情写入 Redis，并通过 Kafka、Redis Pub/Sub 或内部消息总线分发给下游。 · 客户端接入层：通过自有 WebSocket 网关向浏览器、移动端或内部服务推送数据，避免将长期 API Token 暴露给终端用户。 7.2 关键工程实践 · 连接复用：不要为每个前端用户单独建立一条上游行情连接；根据订阅规模和服务商连接限制设计共享连接池。 · 背压处理：当下游消费速度低于上游推送速度时，设置有界队列、丢弃策略或按业务重要性降采样，避免内存持续增长。 · 订阅配额：在业务侧限制单用户订阅数、Topic 数和订阅变更频率，并监控服务商套餐约束。 · 消息幂等：对行情消息按标的、类型、时间戳或服务端提供的序列信息进行去重；具体唯一键以数据协议为准。 · 可观测性：记录连接状态、订阅确认率、重连次数、消息吞吐、端到端处理耗时、队列积压和异常消息比例。 · 安全：Token 只保存在服务端环境变量或密钥管理服务中；对外部客户端使用自有身份认证和权限校验。 八、常见问题排查 问题：连接后没有收到行情 处理建议：先确认是否收到 welcome；检查 deeptoken 是否有效、握手请求头是否正确，以及订阅是否在连接建立后发送。 问题：订阅请求被拒绝 处理建议：检查 Topic 拼写、市场和标的编码；确认单条请求只包含同一种行情类型；读取 ack 中的 accepted 与 rejected。 问题：报价有数据但 K 线没有数据 处理建议：确认是否使用实时 K 线文档规定的 Topic 和周期参数，并检查账号权限、市场交易状态及该标的是否支持对应周期。 问题：连接频繁断开 处理建议：检查代理或负载均衡的空闲超时，按官方心跳文档实现保活，并加入指数退避重连。 问题：重连后行情出现缺口 处理建议：按官方心跳与续传文档使用短时续传能力；超出续传窗口时，再通过历史行情接口补齐。 问题：前端收到重复行情 处理建议：检查上游是否重复订阅同一 Topic，以及业务层是否对多个客户端重复转发；按业务键做幂等处理。 九、总结 使用 DeepTick WebSocket 接入实时行情，关键不只是建立一条长连接，而是正确处理连接鉴权、Topic 订阅、订阅回执、心跳、断线恢复和数据消费。本文同时覆盖实时报价与实时 K 线：报价流用于更新最新行情摘要，K 线流用于更新正在形成的图表 Bar；两种行情类型应分开发送订阅请求，并依据各自的数据文档解析消息。 在生产环境中，建议将上游行情接入与终端用户连接解耦，配合缓存、消息队列、限流、监控和断线补偿，逐步构建可扩展、可观测的行情分发服务。 免责声明：本文代码用于技术接入演示，不构成投资建议。行情数据的使用、展示、存储和再分发应遵守 DeepTick 服务条款及相关市场的数据授权要求。** GitHub - deeptick-cc/deeptick-realtime-market-data-api: DeepTick · 实时金融行情数据 API · GitHub ** 
