摘要
AI 工具能帮研究员取行情数据，但前提是先接上外部行情工具——否则 AI 会凭空编价格。本文用 TickDB MCP 跑通"工具可见 → 查询真实 symbol → 核对字段 → 导出研究表"的最短路径，最终产出一张带 symbol、checked_at 和 note 字段、每一行都可复核的记录表。导出的 CSV 可以顺手存到阿里云 OSS，形成可追溯的研究资产。
你让 AI 查行情，它可能给你编一个价格
研究员用 AI 工具做金融研究时，最隐蔽的错误不是分析逻辑，而是数据源头：AI 凭空编造了一个不存在的价格，或者把昨天的收盘价当成实时价填进了表格。等你发现时，已经基于错误数据做了好几步推演。
解决这个问题的第一步，不是换模型，而是给 AI 接上一个它能直接调用的真实行情工具。
TickDB 通过 MCP 接口，让 AI 在回答你之前先去查询真实行情，再基于查询结果做分析。下面这张表帮你快速判断它是否适合你的场景：
| 维度 | 说明 |
|---|---|
| 适合谁 | AI 工具用户、个人研究员、量化开发者——需要在 AI 对话中直接取到真实行情数据的人 |
| 解决什么问题 | AI 凭模型记忆编造行情数据；研究员需要反复离开 AI 工具去网页查价格 |
| 用哪条入口验证 | TickDB MCP（端点 mcp.tickdb.ai/，鉴权 Header X-TickDB-Key） |
| 不适合什么 | 生产级持续推送（应选 WebSocket）、自动交易、未审核的高频监控 |
诚实让位：如果你只是偶尔查一两只股票，用 MCP 对话式查一下就够了。这套"四道门"流程是为需要留存复核痕迹的研究场景设计的。
从"AI 帮我查行情"到"导出一张可信的研究表"，中间要过四道门
| 门 | 检查项 | 通过标准 |
|---|---|---|
| ① 工具可见 | AI 环境能否列出 TickDB MCP 工具 | 可看到 get_ticker 在工具列表中 |
| ② 真实 symbol | 查询一个已知品种，如 600519.SH |
返回 code=0，data 非空 |
| ③ 字段契约 | 核对 symbol、type、last_price、timestamp |
字段存在、类型正确、数值可解析 |
| ④ 导出记录 | 将查询结果填入研究表，保留核对痕迹 | 包含 checked_at 和 note，可回溯 |
第一道门：工具可见
在 Cursor 或 Claude Code 中配置好 TickDB MCP Server 后，在对话中输入：
"列出 tickdb 提供的所有 MCP 工具"
如果返回的工具列表中包含 get_ticker，第一道门通过。如果看不到任何工具，检查端点 URL（mcp.tickdb.ai/）和 Header（X-TickDB-Key）是否正确配置、网络是否可达。
第二道门：真实 symbol
工具可见后，发起第一次真实查询：
"用 get_ticker 查询 600519.SH，type=stock"
两个参数：symbols 填 "600519.SH"，type 填 "stock"。返回 code=0 且 data 非空，这道门通过。如果 data 为空，检查 symbol 格式和 Key 权限，不自行断言原因。
图：TickDB MCP get_ticker 查询 600519.SH 的一次真实调用结果。截图仅用于展示字段结构和本次调用返回，不构成实时报价、投资建议、延迟或 SLA 承诺。
第三道门：字段契约
查询成功后，逐项核对返回字段。这是最关键的一道门——它决定了你填进研究表的数据能不能经得起事后复核。
| 字段 | 核对点 | 失败处理 |
|---|---|---|
symbol |
与请求的 600519.SH 完全一致 |
停止，检查请求参数 |
type |
为 "stock" |
停止，检查品种类型 |
last_price |
为非空字符串；可解析为有限 Decimal（非 NaN/Infinity） | 停止，不默认成 0 |
timestamp |
为整数且非 bool | 停止，检查返回结构 |
MCP
get_ticker是单次查询，不是 WebSocket 持续推送。一次成功只代表本次调用有效。last_price为字符串类型，导出时不应直接当数值计算，需用 Decimal 等精度保持类型处理。
第四道门：导出一张带核对痕迹的研究表
前三道门通过后，把查询结果填入研究表。这张表的核心不只是价格，而是每一行都能追溯到"什么时候、用什么工具、核对是否通过"。
建议字段设计：
| 字段名 | 来源 | 说明 |
|---|---|---|
symbol |
请求参数 | 600519.SH |
type |
返回字段 | stock |
last_price |
返回字段 | 接口返回的字符串值 |
timestamp |
返回字段 | 整数时间戳 |
checked_at |
客户端生成 | 核对时间，如 2026-06-15 10:30:00 |
note |
手动或自动 | 字段核对通过 或异常原因 |
为什么 checked_at 和 note 是必填的？ 一个月后你回看这张表，只有价格和代码，你不记得这条数据是正常返回的还是补过默认值的、是在交易时段查的还是盘后查的。有了核对时间戳和备注，每一行数据的"身世"才是清楚的。
研究表导出后，存到阿里云 OSS
核对完成的研究表（CSV 或 JSON 格式），如果只放在本地笔记本里，团队其他人看不到，机器故障也可能丢失。一个简单的做法是把研究表上传到阿里云对象存储 OSS，给文件加上核对日期前缀，形成可追溯的研究资产目录：
oss://research-records/checked/
├── 2026-06-15/
│ └── ticker_check_600519.SH.csv
├── 2026-06-16/
│ └── ticker_check_600519.SH.csv
上传方式可以直接用阿里云控制台，也可以通过 OSS SDK 在导出脚本里加几行代码自动上传。核心原则不变：每条记录保留 checked_at 和 note，OSS 上每次上传都是一份可独立回溯的核对快照。
失败分支速查
| 现象 | 处理方向 |
|---|---|
| 工具不可见 | 检查 mcp.tickdb.ai/ 和 X-TickDB-Key |
| Key 暴露风险 | Key 通过环境变量注入，不提交到版本控制 |
| symbol 查不到 | 核对后缀（.SH/.SZ），必要时查可用品种列表 |
data 为空 |
不自行补默认值，检查 symbol 状态和当前时段 |
last_price 解析失败 |
阻断，不默认成 0 |
timestamp 类型错误 |
阻断，按当前工具语义判断 |
下一步：换上你自己的 symbol，跑一次完整验证
图：TickDB MCP get_ticker 查询 600519.SH 的一次真实调用结果。截图仅用于展示字段结构和本次调用返回，不构成实时报价、投资建议、延迟或 SLA 承诺。
本文的 600519.SH 只是帮你确认工具通路。接下来换上你自己的研究标的：
- 用你的 symbol 列表逐条跑一遍四道门。
- 把成功的记录导出到 CSV，保留
checked_at和note。 - 上传到 OSS，形成按日期归档的研究记录。
- 查阅 TickDB 官方文档和 GitHub 示例，了解
get_kline等其他 MCP 工具——单次快照用 MCP 或 REST，需要持续推送时再考虑 WebSocket。
📡 本文行情数据示例由 TickDB.ai 提供
⚠️ 本文为技术教程，不构成任何投资建议
