Python + Codex 调实时行情 API：如何用 TickDB REST 给 AAPL.US 价格回答做证据卡

摘要当 Codex 回答AAPL.US的价格时最危险的回答不是“不知道”而是一个很完整、很流畅、看起来很像真的数字。行情数据是动态事实今天的价格和昨天的不是同一个事实盘前和盘后的价格也不是同一个时间语义。本文不讨论 Codex 能不能预测股价只讨论一件事怎么判断它给出的价格是真实通过工具查回来的还是只是生成了一个“看起来合理的数字”。我用 TickDB REST ticker 在 Codex 工作台里跑了一次真实取数把请求、返回、时间戳、原始快照和失败分支压进一张可复查的证据卡。一、Codex 回答行情时最危险的不是“不知道”当 Codex、Cursor、Claude Code 这类 AI 编程工具给出一个股票价格时大多数人的第一反应是看这个数字对不对。但真正该问的问题在前面一层它说这个数字之前真的查过数据吗这件事很容易被忽略。因为这类工具太擅长把话说顺了代码能写逻辑能解释一个价格数字夹在自然语言里看起来就像真的一样。但行情数据不是静态知识。价格会变时间戳有语义symbol有市场后缀接口返回 HTTP 200 也不等于业务数据真的回来了。对普通知识问答来说回答是否合理有时还能做粗略判断。但对行情数据来说这不够。同样是316.22如果没有 timestamp你不知道它属于哪个市场时刻。AAPL、AAPL.US、不同市场后缀、不同数据源命名规则都会影响最终取数。所以问题不是“Codex 能不能说出价格”而是它说这个价格之前有没有真正走过一次可复查的取数流程我把这条证据链压成一张卡要检查什么为什么重要请求了什么接口避免模型凭空生成请求的symbol是什么避免查错标的返回的symbol是否一致避免市场后缀混淆last_price是否存在避免没有价格却硬答timestamp是什么避免把旧数据说成当前价格checked_at是什么时候区分检查时间和行情时间原始快照有没有保存出问题后能回放失败分支怎么处理没数据时必须停止回答回答不是证据取数链路才是证据。二、我在 Codex 里用 TickDB 跑了一次真实取数这次我在 Codex 工作台里执行 Python 脚本用 TickDB REST ticker 查询AAPL.US并把终端输出、原始返回和证据卡都保存下来。真实终端输出记录API Key 已脱敏。这次实测里关键字段如下检查项本次样本请求对象AAPL.US返回对象AAPL.USlast_price316.22行情时间戳1783627200000行情时间 UTC2026-07-09T20:00:00Z本次检查时间 UTC2026-07-10T06:48:40ZHTTP 状态200字段校验symbol / price / timestamp均通过这里有一个非常重要的区别行情时间不是检查时间。timestamp_utc表示这条行情数据自己携带的时间checked_at_utc表示我这次在 Codex 里运行脚本检查它的时间。如果把这两个时间混在一起Codex 的回答就会变得很危险——它明明只是“在某个检查时间拿到了一条带有自身 timestamp 的行情数据”却被包装成“此刻价格就是这个数”。更稳妥的表达应该是本次在2026-07-10T06:48:40Z检查时TickDB REST ticker 返回AAPL.US的last_price为316.22返回数据中的行情时间为2026-07-09T20:00:00Z。这句话不夸张但可复查。三、Codex 回答前先过 4 个证据门Codex 给确定价格之前至少要有请求、返回、时间和留痕。我建议把 Codex 的行情回答拆成两层。第一层是最终回答给人看。第二层是证据卡给系统和复盘看。证据卡不是为了把文章写复杂而是为了防止模型把“空数据、旧数据、错 symbol、无 timestamp”说成确定价格。一张合格的证据卡至少要回答这些问题字段作用question用户原始问题是什么tool_or_api这次通过什么工具或 API 取数request请求方法、接口和参数是什么symbol_requested实际请求了哪个标的symbol_returned返回标的是否一致last_price最终回答引用的价格字段timestamp行情数据自身的时间语义checked_at这次检查发生在什么时候raw_snapshot_path原始返回快照保存在哪里final_answer_rule哪些字段缺失时不得回答确定价格这张卡的价值不在于漂亮而在于能追问。如果symbol_requested和symbol_returned不一致就不能回答价格。如果last_price不存在就不能回答价格。如果timestamp缺失就不能把它说成明确时点的行情。如果没有raw_snapshot出问题后就只能相信 Codex 当时那句自然语言回答。四、HTTP 200 不等于 Codex 真的拿到了价格这次我还跑了一个失败分支NOTREAL.US。结果很有代表性接口返回 HTTP 200但业务数据里的data是空数组。这就是很多 AI 工具接行情接口时容易踩的坑只看 HTTP 层成功没看业务数据是否真的存在。如果 Codex 只看到 HTTP 200就继续组织回答它可能会把一次“请求成功但没有可用行情”的结果包装成一个看起来很确定的价格答案。所以证据卡里必须有一条硬规则没有可核验data就不生成价格答案只记录失败分支。一个可靠的 Codex 行情工作流不是永远能回答价格而是在没有数据时敢于停止回答。五、这段脚本的核心逻辑下面是这次在 Codex 工作台里使用的核心代码。使用前需要在本地环境变量中配置TICKDB_API_KEY。它不是伪代码调用、字段处理、原始快照保存和失败分支都按 TickDB REST ticker 的真实流程编写。importjsonimportosimporthashlibfromdatetimeimportdatetime,timezonefrompathlibimportPathfromurllib.parseimporturlencodefromurllib.requestimportRequest,urlopen API_KEYos.environ[TICKDB_API_KEY]SYMBOLAAPL.USRAW_DIRPath(tickdb_codex_evidence/raw)RAW_DIR.mkdir(parentsTrue,exist_okTrue)urlhttps://api.tickdb.ai/v1/market/ticker?urlencode({symbols:SYMBOL,})requestRequest(url,headers{X-API-Key:API_KEY,Accept:application/json,},)checked_at_utcdatetime.now(timezone.utc).strftime(%Y-%m-%dT%H:%M:%SZ)withurlopen(request,timeout20)asresponse:http_statusresponse.status payloadjson.loads(response.read().decode(utf-8))raw_textjson.dumps(payload,ensure_asciiFalse,indent2)raw_pathRAW_DIR/fticker_{SYMBOL.replace(.,_)}_raw.jsonraw_path.write_text(raw_text,encodingutf-8)raw_sha256hashlib.sha256(raw_text.encode(utf-8)).hexdigest()datapayload.get(data)or[]itemdata[0]ifdataelseNoneifnotitem:evidence{symbol_requested:SYMBOL,http_status:http_status,checked_at_utc:checked_at_utc,raw_snapshot_path:str(raw_path),raw_snapshot_sha256:raw_sha256,answer_rule:data 为空不生成价格答案,}else:evidence{symbol_requested:SYMBOL,symbol_returned:item.get(symbol),last_price:item.get(last_price),timestamp_raw:item.get(timestamp),checked_at_utc:checked_at_utc,raw_snapshot_path:str(raw_path),raw_snapshot_sha256:raw_sha256,field_checks:{symbol_match:item.get(symbol)SYMBOL,last_price_present:item.get(last_price)isnotNone,timestamp_present:item.get(timestamp)isnotNone,},answer_rule:最终回答只能引用 evidence 中已校验字段,}print(json.dumps(evidence,ensure_asciiFalse,indent2))这段代码真正重要的不是“能调通接口”。真正重要的是它把 Codex 的回答拆成了几个硬动作先请求真实接口、保存原始返回、检查symbol、检查last_price、检查timestamp、记录checked_at、对空数据分支停止回答、最终回答只能引用 evidence 中已校验字段。Codex 不是直接“说一个价格”它必须先拿到证据再组织语言。六、把 Codex 的语言和数据证据分开Codex 负责组织语言TickDB 负责提供可调用行情入口证据卡负责把这次取数变成可复查记录。我现在更倾向于把这类 AI 行情工作流拆成三层。第一层Codex 负责理解和表达——它能把用户问题拆成步骤把脚本写出来把结果解释成人能看懂的话。第二层TickDB 负责真实取数——本文用的是 REST ticker如果在其他场景里也可以按官方能力使用 WebSocket、MCP、CLI 或 Skill 等接入方式。第三层证据卡负责留痕——请求参数、返回字段、检查时间、原始快照、失败分支都要能回头查。很多人把这三层混在一起Codex 说出了答案就以为它查了数据接口返回 200就以为业务数据可用模型解释得顺就以为结果可信。更稳的顺序应该反过来先取数再校验再让 Codex 组织回答。这样 Codex 的价值不是“凭空知道价格”而是把已经取到、校验过、留过痕的数据讲清楚。七、TickDB 在这里的合理位置TickDB 在这篇文章里的位置不是替 Codex 做投资判断也不是证明某个股票该买还是该卖。它适合作为一个可程序化调用的行情入口让 Codex 这类工具在需要行情数据时不靠记忆不靠猜而是通过明确接口拿到结构化返回。在本文这个例子里TickDB 提供的是 REST ticker 查询能力。脚本拿到symbol、last_price、timestamp等字段后再由证据卡做校验和留痕。如果你做的是 AI 行情助手、研究脚本、自动化复盘或监控面板这个思路都能复用接入方式更适合的场景REST脚本、服务端任务、证据卡生成WebSocket持续订阅、实时监控MCP让支持 MCP 的 AI 工具调用行情数据CLI / Skill轻量自动化和 AI 工作流但不管入口是哪一种核心问题都一样最终回答必须能回到真实取数而不是只停留在自然语言。八、下次看 Codex 行情回答先问这 8 个问题如果你准备用 Codex、Cursor、Claude Code 或其他 AI 工具接行情数据可以用这张清单判断回答有没有证据。问题如果回答不上意味着什么它请求的是哪个symbol可能查错标的返回的symbol是否一致可能发生市场后缀或代码混淆它调用的是哪个工具或 API可能只是模型生成原始返回有没有保存事后无法复盘价格字段是哪一个可能把不同价格口径混用timestamp是多少不知道价格属于哪个时刻checked_at是什么时候容易混淆检查时间和行情时间data为空时怎么处理可能在没有数据时继续编答案这 8 个问题不是为了为难 Codex而是为了给动态事实回答加一道闸门。行情数据进入 AI 工具之后最重要的不是让模型显得更懂金融而是让它每次回答都能回到数据现场。九、FAQQ1这篇文章为什么要提 TickDB因为本文讨论的不是“Codex 怎么把话说漂亮”而是“Codex 回答动态行情事实时背后有没有真实取数”。TickDB 在这里只是取数入口。它提供结构化行情返回让脚本能拿到symbol、last_price、timestamp这些字段再由证据卡记录checked_at和原始快照。它的作用很具体让 Codex 不靠记忆回答AAPL.US的价格而是先通过接口查一次再把这次查询留下来。Q2证据卡最依赖 TickDB 返回里的哪些信息在本文这个 REST ticker 样本里最关键的是三类信息symbol确认返回对象是不是请求的AAPL.US、last_price确认最终回答引用的是哪个价格字段、timestamp确认这条行情数据自身对应的时间。再加上脚本侧记录的checked_at、raw_snapshot_path和失败分支才组成一张能复查的证据卡。价格只是结果证据卡保存的是这个结果从哪里来。Q3如果我用 Cursor、Claude Code 或 MCP逻辑会变吗工具入口会变但证据逻辑不变。本文用的是 Codex 工作台里的 REST 脚本所以鉴权用的是 REST 的X-API-Key。如果换成支持 MCP 的 AI 工具入口可以变成 MCP 工具调用但你仍然要记录请求对象、返回字段、时间戳、检查时间和原始结果。不管是 Codex、Cursor、Claude Code还是其他 AI 工具只要它在回答行情这种动态事实就不应该跳过证据卡。Q4什么时候 Codex 不应该给确定价格至少这几种情况不应该给确定价格data为空、返回symbol和请求symbol不一致、last_price缺失、timestamp缺失、没有记录checked_at、没有保存原始返回、只能看到自然语言答案却看不到取数过程。这时更好的回答不是硬给一个数字而是说明本次没有拿到可核验价格。对 AI 工具来说知道什么时候停下来比永远给答案更重要。最后下次 Codex 给你一个股票价格不要先问它“准不准”。先问它证据卡在哪里如果它能告诉你请求了什么、返回了什么、timestamp 是多少、checked_at 是什么时候、原始快照在哪里这个回答至少有了可复查的基础。如果它只能给出一个流畅的自然语言答案没有工具调用、没有原始返回、没有字段校验那它可能只是在说一个看起来合理的数字。 本文 Codex 工作台实测以 TickDB REST ticker 作为行情取数入口⚠️ 本文只讨论 Codex 工具调用行情数据时的取数证据链、字段校验和工程留痕不构成任何投资建议。接口路径、字段语义和产品能力以 TickDB 官方文档为准。