跳转到主要内容
Product6 min read

无论在哪个界面,数字都一样:TradingFlow 的已治理指标层

作者

TradingFlow 自己的页面与 Cookbooks 报告,从同一个小型的、已治理的注册表中计算 Net DEX、DEI 与情绪——AI 助手与 MCP 也构建在同一套注册表之上,正在逐步向内部账户之外开放。这篇文章讲清楚它是怎么运作的,以及为什么它被刻意做得很小。

大多数数据平台都有这样一种失败模式,却很少有人公开谈论:仪表盘说某只股票的资金流是看涨的,聊天机器人说是中性的,导出的报告又说是介于两者之间——因为三段不同的代码,用三种略有差异的方式计算了"情绪"。没有人会注意到,直到有人把它们摆在一起对比。一旦对比之后,用户不会只是不再相信那个错的——三个都会失去信任。

TradingFlow 对这种失败模式的回应,不是雇更多人手动去对齐数字,而是一小块刻意做得很窄的基础设施:一个已治理的指标注册表(governed metrics registry)——每个界面都被设计为从这里读取,而不是各自计算一份自己的版本。目前应用自己的页面与 Cookbooks 报告已经在这样做;TradingFlow AI 与 MCP 也接入了同一套注册表,正在逐步向内部账户之外开放。

Rank Symbols 表格,展示五个标的的 Net DEX、Net DEI、Bullish DEI、Bearish DEI 与 Sentiment 列

Rank Symbols 上的 Net DEX、Net DEI 与 Sentiment,并不是三套恰好算出一致结果的独立计算——它们就是本文接下来描述的同一套已治理定义。

"已治理"在这里究竟意味着什么

这个注册表里的一个指标,不只是一条公式。每一个都是一小捆一次性定义好的事实:

  • 它叫什么,回答的是哪个问题——Net DEX 回答"方向性资金流倾向哪一边",DEI 回答"相对这个标的的正常规模,这有多大"。
  • 它来自哪里——读取的是哪份底层数据,按什么节奏更新。
  • 符号与量纲如何约定——这样"正值"在任何出现的地方含义都一致。
  • 谁有权看到它——一个付费专属的指标,无论哪个界面来问,都依然是付费专属。

这种"打包在一起"比听起来更重要。这正是为什么你会在 GEX 每一次出现的地方都看到同一句新鲜度提示——不是因为有人记得在四个地方分别重新打一遍,而是因为这句提示本身就附着在指标的定义上,而不是附着在展示它的某一个具体界面上。

一个注册表,四个消费方

示意图:一个已治理的指标注册表一次性编译为 SQL,应用页面与 Cookbooks recipe 区块目前已实时读取它,AI 助手的 get_metric 工具与 MCP 的 semantic_query 工具正在逐步向内部账户之外开放

四个界面,都被设计为从同一个地方读取——应用页面与 Cookbooks 目前已经在实时使用它;AI 助手与 MCP 接入了同一套注册表,正在逐步向内部账户之外开放。四者都没有一个能写回它——这个注册表只回答问题,从不改变市场上或你账户里实际发生的事。

具体来说,有四类东西被设计为读取完全相同的注册表:

  • 应用页面——RankOption Trades 直接从这里计算它们的列。目前已上线。
  • Cookbooks——像 Daily Market Recap 这样的 recipe,正是基于同一个目录里的已命名查询构建的。下面就是一次真实运行中、以这种方式计算出的当日权利金与情绪划分。目前已上线。
  • TradingFlow AI——当你向助手提出一个数据问题时,它被设计为不自己写 SQL,而是调用一个从同一套已命名指标中组装答案的工具,所以它的数字不会悄悄偏离旁边页面展示的内容。目前正在逐步向内部账户之外开放。
  • MCP——对于把自己的 AI 工具连接到 TradingFlow 数据的读者来说,这些工具被设计为查询同一个已治理目录,外部工具不会走一条能得到与应用不同数字的"后门"。目前正在逐步向内部账户之外开放。

Daily Market Recap 标头展示时段 KPI:总权利金、看涨权利金、看跌权利金、看涨占比权利金、看跌占比权利金

Daily Market Recap 运行顶部的权利金与情绪划分——与上面 Rank Symbols 列使用的是同一套已治理定义,只是聚合到了整个交易时段,而不是单一标的。

为什么这个注册表被刻意做得很小

看到"已治理的指标层"这个说法,很容易联想到某种庞大的东西——一整套数据目录,一张囊括业务中每个实体及其关系的图谱。TradingFlow 的实现刻意不是那样。它只覆盖一份简短、封闭的指标清单(权利金、净权利金、Net DEX、DEI、情绪,以及少数几个成交笔数类计数),并且只做一件事:把一个问题编译成一条单一的、安全的、只读的查询。

有两条限制才是真正的重点,而不是需要致歉的短板:

  • 它只读。 这一层里的任何东西——无论是 AI 助手、MCP,还是某个 Cookbooks recipe——都不能用它来修改数据、下单交易,或更改你的账户。它只回答问题,从不采取行动。
  • 模型不能针对你的数据自己写 SQL。 当 TradingFlow AI 或某个 MCP 客户端提出一个问题时,它是在一组已命名、预先批准的指标与筛选条件中做选择——而不是自由组合任意查询。这比通用的"文本转 SQL"工具能力更窄,而这是刻意为之:正是这份"窄",才让"数字不会漂移"成为 TradingFlow 能真正兑现的承诺,而不只是一句期望。

一个更大、更通用的系统本来更容易搭建,却更难被信任。现在这套足够小,"助手给出的数字是否与页面一致"是一个有机械式答案的问题,而不是一个 QA 流程才能回答的问题。

这对你实际意味着什么

使用 TradingFlow 时,你完全不需要考虑这些——这正是它的意义所在。但这确实意味着,当你在不同界面之间比对证据时,以下几点是成立的:

如果你在这里看到这个指标……它在这里的含义完全相同
Rank Symbols 上的 Net DEXCookbooks 报告"敞口"章节里的 Net DEX
Rank Symbols 上的 SentimentDaily Market Recap 运行中聚合到整个时段的 Sentiment

如果这两者出现不一致,那是一个值得报告的 bug,而不是"页面对比报告"这件事本身固有的特性。等 TradingFlow AI 与 MCP 向内部账户之外开放后,同样的校验方式也会延伸到"页面对比聊天机器人的回答"或"页面对比你自己连接的工具"——同一个注册表,同一条底线。

阅读指标背后的概念

以上均不构成投资建议,跨界面的一致性也不等同于交易信号——它只是意味着,当 TradingFlow 两次向你展示同一个数字时,你可以相信它确实是同一个数字。

准备好亲自体验了吗?打开 TradingFlow

相关文章

Product

Filter GEX wall flow by horizon: All and 0DTE in Rank

Rank Contracts now separates all-expiration and exact-0DTE Wall Flow filters, so paid users can narrow the same-session evidence to the horizon they are researching.

Product

Daily Market Recap: Read a Full Options Session in TradingFlow Cookbooks

TradingFlow's Cookbooks turn a live options-flow session into a guided report. Daily Market Recap walks eight chapters — tone, money flow, timing, DEX/DEI, volatility, GEX, movers, and a headline name — each with real evidence next to the explanation, not baked-in prose.

Product

Options Chart That Matters: GEX, Walls, and Flow—Not a Pretty Candlestick

Looking for an options chart? Map gamma exposure, call/put walls, and same-session option flow in TradingFlow Rank—not just another price chart.