TickDB 博客：市场数据分析、API 接入教程与 AI 行情工具实践。按市场和主题查找文章。
When I first built a China A-share strategy in Python, I pulled daily OHLCV kline data, ran a backtest, and the equity curve looked good. I thought the data layer was done. Then the bugs arrived one b
TickDB Research ·
如果你用Python拉过A股1分钟K线、算过量比因子、跑过开盘段策略——下面这个坑，我大概率不是唯一踩过的人。 拉K线、算量比、跑回测、曲线好看、上实盘、信号失灵。我最近又走了一遍这个循环。一开始怀疑策略逻辑，改了几版参数，回测还是好看，实盘还是失灵。后来换了个方向查——不查策略，查数据。问题出在9:30那根K线上。 你的量比因子，可能从第一根K线就已经算错了——而你的回测结果，恰好证明了它“有效
TickDB Research ·
When you start building a quant strategy or market data pipeline, the first thing you usually do is pull historical OHLCV data. A few lines of Python, a REST call, daily kline bars flowing into a Data
TickDB Research ·
早期做A股策略，用Python拉通了日K线，回测曲线挺好看，以为数据层搞定了。实盘上线后问题一个接一个：除权日跳空被策略当成下跌信号，两天后才反应过来是K线没做复权；想估滑点，发现手里只有K线，没有盘口，只能拍一个固定值；想做多因子，打开数据源一看，基本面覆盖哪些标的、不覆盖哪些，谁也说不清。 这些坑不是因为接口调不通，而是因为一开始就没看清A股数据到底有几层。 A股数据远不止“行情”两个字。至少
TickDB Research ·
我用 Claude 辅助做过一版估值草稿。它给了我 AAPL 的价格，我拿这个价格算了一个倍数，写进了草稿。 第二天开盘我才发现，那个价格和当时盘中的差了一截。草稿里所有基于价格算出来的东西，基准日不对，得从头再对一遍。 那次之后我才意识到：Claude 给我的数字，不是不能信，是我没办法验证它新不新。它可能来自实时接口，也可能来自训练记忆。从返回的内容上，我看不出区别。 MCP 能解决"拿到实时
TickDB Research ·
Meta description: Configure TickDB MCP to give Claude access to live market data with millisecond timestamps. Step-by-step setup for Claude Desktop, real JSON output, and a timestamp verification meth
TickDB Research ·
做多市场研究的量化团队和做行情看板的集成商，对数据接入层的核心需求不是“能拿到数据”——能拿到数据的方案太多了。真正的需求是：数据接入层的结构，必须能支撑你的策略逻辑做正确归因。 归因的意思是：实盘表现和回测对不上时，你能追溯出问题出在数据口径、时段划分还是连续性假设。如果数据层不透明，归因链在第一步就断了。 本文从三个最容易被忽视的结构性断层展开：报价口径、时段划分、连续性假设。每个断层都会在你
TickDB Research ·
国内期货数据源选型这件事，大多数人从第一天就做错了。他们从“哪个数据源的接口好用”开始，而不是从“国内期货的制度规则和其他市场差多少”开始。结果是：你选了一个接口很顺手的数据源，但你的回测从第一根 K 线起，就在一个错误的时间框架里运行。 2025 年全年，中国期货市场成交额超过 766 万亿元（中期协口径），商品期货成交量占全球的 72.3%（FIA 口径）。这个量级的市场里没有新手保护期。它的
TickDB Research ·
去年底参与的一个跨市场策略项目启动基准搭建。需要同时接入沪深300、恒生指数和纳斯达克100的日线历史和实时快照。 用yfinance拿到了IXIC，用AKShare调通了000300.SH，恒生指数也从另一个源查到了历史。三条链各自都能跑。 合并DataFrame之后，同一天的数据对不上。三个源用的时区基准完全不同。删掉错位的K线之后，又发现各市场历史数据的除权方式没有声明。两周时间消耗在数据层
TickDB Research ·
周一早上，你打开Jupyter，准备跑一个10年A股历史回测。Tushare的调用写到第3000次，返回空数据。你停下来，打开知乎，开始搜“Tushare限频怎么办”。 翻完十几个回答，你发现所有人都在教你攒积分：传数据、发帖、邀请好友。没人在教你算清自己每天的实际调用量，没人在教你优化调用策略，更没人在教你判断——你的需求到底是不是积分能解决的。 你缺的不是更多积分攻略，而是一个框架：什么时候该
TickDB Research ·
你9:15打开自己的行情脚本，用AkShare拉A股实时数据。终端弹出一行红字：。你以为是参数写错了，改了重跑，还是报错。你换成Tushare，返回倒是正常了，但价格栏全是空的，直到9:30才突然跳出第一行数据。 你以为是自己代码的问题。其实不是。 你在用个人开发者能拿到的公开接口，而这些接口在9:15到9:25这个窗口，集体选择了沉默。你的策略在等数据，而开盘价早在9:25就已经确定了。 这10
TickDB Research ·
你第一次把A股数据接进研究脚本，终端很快打印出价格。你看了一眼，觉得没问题，继续写因子。 直到回测跑到第三个小时，你开始怀疑数据不对。你回头检查，发现自己从来没验证过返回行里的代码，是否真的对应你请求的那两只股票。如果应用层没有把返回行与请求代码对齐，可能发生错配——你拿到的可能不是你要的那只票的数据。 有价格，只能说明这一次快照请求成功。它还没有回答这份数据是否满足你的研究任务。免费是成本条件，
TickDB Research ·