AI 帮我查行情，结果价格是编的——一次 MCP 取数校验的记录
摘要：AI 工具能帮研究员取行情数据，但前提是先接上外部行情工具——否则 AI 会凭空编价格。本文记录一次完整的取数校验过程：确认工具可见、查询真实 symbol、逐字段核对契约、导出带 checked_at 和 note 的研究表。每一步都有明确的通过标准和失败处理，跑通后你就有了一个可复用的校验骨架。关键词：AI 取数、行情校验、MCP 工具调用、研究表、字段核对。
一、先把问题说清楚：AI 编了一个价格
研究员让 AI 查一下 600519 最新价，AI 给了一个数字。他拿这个数字填进表格，做了好几步推演。后来才发现——这个价格是 AI 编的。
这不是模型能力问题。AI 没有接入真实行情工具时，它只能凭训练记忆回答——那个记忆可能是三个月前的快照，也可能根本不存在，模型自己“合理推测”了一个。在你让它分析数据之前，先得让它能取到真实数据。
TickDB 的 MCP 接口就是给这个场景用的。它在 AI 工具里注册一组行情查询函数——get_ticker、get_kline 等——AI 调用这些函数时，拿到的是真实行情服务的返回，不是训练记忆里的残留。配置方式：在 Cursor 或 Claude Code 中设置 MCP 端点 mcp.tickdb.ai，鉴权 Header 为 X-TickDB-Key。配置完成后，AI 就多了一组能直接调用的行情工具。
| 维度 | 说明 |
|---|---|
| 适合谁 | 用 AI 工具做研究、需要取数验证的个人和小团队 |
| 解决什么 | AI 编造行情数据；反复切窗口手动查价格 |
| 不适合什么 | 生产级持续推送（应选 WebSocket）、自动交易、高频监控 |
如果你只是偶尔查一两只股票，对话式问一下就行，不需要搭整套导出流程。本文的四道校验门是给需要留存复核记录的研究场景准备的。
二、四道门：从一句“帮我查”到一张可复核的研究表
| 门 | 检查项 | 通过标准 |
|---|---|---|
| ① 工具可见 | AI 能否列出 MCP 工具 | get_ticker 出现在工具列表中 |
| ② 真实 symbol | 查一个已知品种 | 返回 code=0，data 非空 |
| ③ 字段契约 | 核对四个关键字段 | 字段存在、类型正确、数值可解析 |
| ④ 导出记录 | 填入研究表，保留核对痕迹 | 包含 checked_at 和 note |
第一道门：工具可见
在 AI 工具里配置好 TickDB MCP Server 后，发一句：
“列出 tickdb 提供的所有 MCP 工具”
如果返回列表里有 get_ticker，第一道门通过。看不到工具？检查端点 mcp.tickdb.ai 和 Header X-TickDB-Key 是否正确，网络是否可达。
第二道门：真实 symbol
工具可见后，做第一次真实查询：
“用 get_ticker 查询 600519.SH”
参数：symbols 填 "600519.SH"，type 填 "stock"。返回 code=0 且 data 非空，这道门通过。data 为空时检查 symbol 格式和 Key 权限，别猜原因。
选 600519.SH 作为首次查询对象，是因为它在已有测试中返回稳定，symbol、type、last_price、timestamp 字段均可见——这个已知可复核的结果，是你判断工具是否正常工作的基准。
第三道门：字段契约
查询成功不是终点。返回的字段必须逐项核对——这决定了你填进研究表的数据能不能经得起事后复查。
| 字段 | 核对点 | 不通过怎么处理 |
|---|---|---|
symbol |
与请求的 600519.SH 完全一致 |
停止，检查请求参数 |
type |
为 "stock" |
停止，检查品种类型 |
last_price |
为非空字符串，可解析为有限数值（非 NaN/Infinity） | 停止，不默认成 0 |
timestamp |
为整数且非 bool | 停止，检查返回结构 |
MCP
get_ticker是单次查询，不是持续推送。一次成功只代表本次调用有效。last_price是字符串类型，导出时别直接当数值算——用 Decimal 做精度保持。
第四道门：导出带核对痕迹的研究表
前三道门全部通过后，把查询结果填入研究表。这张表的核心不是价格本身，而是每一行都能追溯到“什么时候查的、用什么工具查的、核对是否通过”。
| 字段名 | 来源 | 说明 |
|---|---|---|
symbol |
请求参数 | 600519.SH |
type |
返回字段 | stock |
last_price |
返回字段 | 接口返回的字符串值（此处不展示） |
timestamp |
返回字段 | 整数时间字段（单位按当前 MCP 返回语义核对） |
checked_at |
客户端生成 | 2026-06-15 10:30:00（示例） |
note |
手动或自动 | 字段核对通过 或异常原因 |
last_price和timestamp为字段占位说明，不构成实时报价展示。
为什么 checked_at 和 note 是必填的？ 一个月后你回看这张表，只有价格和代码——你分不清这条数据是正常返回的还是补过默认值的，是在交易时段查的还是盘后查的。有了核对时间戳和备注，每一行数据的“身世”才清楚，复核才有依据。
三、失败了怎么办：六个常见现象的排错方向
| 现象 | 处理方向 |
|---|---|
| 工具不可见 | 检查端点 mcp.tickdb.ai 和 Header X-TickDB-Key 配置 |
| Key 泄露风险 | Key 走环境变量注入，不提交到版本控制 |
| symbol 查不到 | 核对后缀（.SH/.SZ），必要时查可用品种列表 |
data 为空 |
不自行补默认值，检查 symbol 状态和当前时段 |
last_price 解析失败 |
阻断，不默认成 0 |
timestamp 类型错误 |
阻断，按当前工具语义判断 |
四、本文不做什么
- 不是持续推送：MCP
get_ticker是单次查询，一次调用一次返回。需要持续监控价格变化，应评估 WebSocket。 - 不是生产级数据流水线：本文只覆盖“工具验证 + 一次查询 + 导出研究表”的最短路径，不涉及定时调度、断线重连、数据库写入。
- 不是投资建议：所有价格字段均为接口返回值占位说明，不代表实时报价。
五、下一步：换上你自己的 symbol，跑一遍
图：TickDB MCP get_ticker 查询 600519.SH 的一次真实调用结果。截图仅用于展示字段结构和本次调用返回，不构成实时报价、投资建议、延迟或 SLA 承诺。
600519.SH 帮你确认了工具通路。接下来三件事：
- 用自己的研究标的逐条跑一遍四道门，别只验证一个品种。
- 把成功记录导出到 CSV 或数据库，保留
checked_at和note字段——这两个字段是未来复核的关键。 - 查 TickDB 文档（
docs.tickdb.ai）和 GitHub 示例，了解get_kline等其他 MCP 工具。单次快照 MCP 或 REST 都行，需要持续推送时再评估 WebSocket。
你用 AI 工具取行情数据时，有没有遇到过它编造价格的情况？在评论区说说你第一次跑 get_ticker 的结果——symbol 对得上吗、timestamp 是整数吗？
📡 本文行情数据示例由 TickDB.ai 提供
本文为技术教程，不构成任何投资建议。
标签：AI 取数 / 行情校验 / MCP 工具调用 / 研究表 / 字段核对
浙公网安备 33010602011771号