跳到主要内容

Data Horizon / 数据视界 战略白皮书（大白话版）

这份文档用尽量直白的语言解释 Data Horizon 战略白皮书。它是解释性派生层，不独立承载战略、产品或治理决定；正式战略口径只以获批后的白皮书为准，产品与治理分别回到对应事实源。

一句话讲明白​

Data Horizon 是一套独立的金融信息感知和信息产品生产系统。

它把新闻、公告、宏观数据、行情、社媒、KOL、图片、音视频等杂乱输入，持续整理成来源可查、权利可判断、质量可说明、变化可追踪、能被人和机器复用的金融信息产品。

它不是新闻爬虫的豪华版，也不是 FinBayes 的数据后台、Trading Matrix 的信号工厂或任何外部客户的专属后端。

世界发生了什么变化​

过去，优势常常来自更早拿到一份数据。现在，结构化数据越来越容易获得，非结构化内容又以更快速度产生、复制、改写和传播。AI 同时加速理解和制造信息，结果不是“信息不足”，而是：

  • 同一事实出现多个版本，却没有稳定身份；
  • 来源、发布时间、采集时间和修订时间混在一起；
  • 权利、适用范围和再分发限制不清楚；
  • 噪声、重复、错误和过期内容大量占用注意力；
  • 一个消费者的字段和流程容易反过来绑架上游系统。

因此，新竞争不只是“更快抓到”，而是能否把复杂信息持续变成可信、可管理、可重放、可复用的信息产品。

DH 到底负责什么​

DH 负责：

  • 接入多种金融信息；
  • 保留原始证据和来源关系；
  • 解析、清洗、去重、标准化和组织信息；
  • 管理身份、时间、质量、权利和生命周期；
  • 让内部人员能够检索、复核、干预和恢复；
  • 通过合适的 Interface 向内部机器和外部客户交付。

DH 不负责：

  • 代替 FinBayes 形成最终研究结论；
  • 代替 Trading Matrix 决定策略、仓位或下单；
  • 用消费者的收益或点击率定义 DH 的信息质量；
  • 把某个客户的页面、字段和业务流程写进公共核心；
  • 在尚未完成评估前宣布正式 Perception Record、Feed、Dataset 或 C 端产品。

DH 真正要积累的壁垒​

DH 的长期价值不在某一个 API 或某一张表，而在六件事能长期一起成立：

  1. 同一条信息有稳定身份，不因来源改名或消费者变化而失去连续性。
  2. 原始证据、处理过程和来源关系能被追溯。
  3. 能判断某项信息允许向谁、为哪个用途、以哪种形态输出。
  4. 质量判断有证据和不确定性，不冒充交易结论。
  5. 修正、撤回、重放和版本变化有清楚语义。
  6. 同一份中立信息资产可以通过不同 Interface 和 Adapter 服务多个消费者。

这才是“一项资产，多次复用”的前提。没有独立权利、质量和生命周期判断，多次输出只会放大风险。

系统可以分成哪几层​

用最简单的方式看，DH 有五层：

  1. Perception Core：处理身份、时间、来源、权利、质量和生命周期等中立语义。
  2. Information Products：面向明确任务组织可消费的信息产品。
  3. Interfaces：REST、stream、文件、bulk、dataset 等交付方式。
  4. Consumer Adapters：把中立产品映射到某个消费者的字段和流程。
  5. Independent Consumer Products：外部独立产品自己的编辑、排序、用户、品牌和商业逻辑。

判断边界有一个实用问题：如果删掉某个消费者，这项能力是否仍对 DH 和其他消费者有独立价值？如果没有，它更可能属于 Adapter，而不是 DH Core。

第一阶段先服务谁​

顺序已经明确：

  1. 内部人类；
  2. 内部机器；
  3. 外部 B 端消费者；
  4. 外部 C 端用户。

这不是说外部客户不重要，而是 DH 必须先证明自己能独立生产和管理信息产品，不能只靠某个下游系统“用上了”来证明成立。

第一阶段要跑通什么​

第一阶段的核心不是再做更多菜单和接口，而是跑通一个独立闭环：

在一个受控信息范围内，DH 能持续完成接入、处理、身份与来源组织、质量标记、人工复核、生命周期管理、检索和受控输出，并能从故障中恢复。

内部人员至少要能持续回答：

  • 现在有哪些来源和信息在运行？
  • 哪些内容可用、待复核、受限制、已修正或应撤回？
  • 为什么系统得出这个状态，证据在哪里？
  • 哪些任务失败了，怎样恢复，恢复是否留下审计记录？
  • 哪些内容能向哪个消费者、以什么用途和形态输出？
  • 同一内容再次到达或被修订时，系统如何保持身份与历史连续？

只有这些问题长期可回答，DH 才是独立信息产品系统，而不是一组运行中的采集脚本。

现有系统算什么​

截至 2026-08，DH 已有大量真实工程能力：来源管理与健康控制、人工 review、来源授权、Open API、News Stream、宏观日历与 actual、行情直连、KOL 工作台、Provider Config、Cron、运维控制台等。

这些能力很重要，但必须分清四件事：

  • 代码存在，不等于生产已经验证；
  • 生产运行，不等于业务已经验收；
  • 客户正在使用，不等于产品模型已经冻结；
  • 技术授权通过，不等于法律和商业权利已经证明。

现有工程是实践证据和兼容资产。未来正式对象、Interface 和架构要从跨场景不变量中提炼，而不是从现有表结构或某个 API response 直接反推。

和几个具体协同对象怎么相处​

FinBayes​

FinBayes 需要可追溯的研究材料、事件、宏观数据和证据。DH 提供信息与证据，FinBayes 负责认知、分析、反证和结论。当前协作仍需用具体任务确认最小对象与接口。

AI Trading Matrix​

Trading Matrix 是内部机器验证场。TM 专属的策略种子、绩效、赛马、资产状态和反馈字段留在 Adapter；这些反馈可以成为 DH 的外部证据，但不能自动改写 DH 的质量或生命周期。

另一方面，DH 的战略升级不能让已经工作的 TM 数据、API、流程和协同链路失效。内部可以重构，但对外要用版本、兼容 Adapter、迁移窗口和回归测试保证“不降级”。

独立外部 B 客户​

独立外部 B 客户只以匿名 benchmark case 进入 DH 文档。DH 记录需求场景、workload、rights、SLA 和验收证据，不记录客户品牌，也不让客户的页面、字段或产品流程定义 DH Core。

其他外部 B​

DH 需要多个使用方式明显不同的消费者证明接口和信息产品具有可移植性，而不是单客户定制；具体验收数量由产品 Gate 决定。

外部 C​

DH 自营 C 端产品当前是 Not approved。如果未来讨论，必须先由 Owner 做 go/no-go，并明确用户任务、权利、品牌、账户、编辑、个性化和渠道冲突；不能把 B 端 API 或任何独立外部产品直接改名后当作 C 端产品。

第一阶段现在到哪了​

第一阶段的收束工作（叫 Phase 1 Closure：把第一阶段的范围收住，把冻结的验收差距逐项关掉）已经完成：2026-08-31，Owner 判定收束通过（PASS），第一阶段作为执行阶段正式关闭。

要分清两件事：收束通过说的是"收尾目标完成了"，不是把历史成绩单改掉——第一阶段留下的四维状态（治理部分完成、实现大量存在、生产部分有证据、严格验收未完成）和个别没达标的指标，都原样保留为历史事实。

第二阶段是什么、到哪了​

第二阶段用四句大白话定义要交付什么：看得更广（覆盖更多全球官方披露、宏观政策、突发事件）、看得更清楚（每条信息说得清是谁说的、出处追到哪一步、归到哪类、当前有多少旁证与哪些不确定、可能牵动哪些市场、后来有没有被修订或否认）、看得更快（分段测延迟、按重要性分层定目标）、更容易使用（管理端按工作空间重新设计概念，个人向使用只做封闭验证的原型）。

还有一条同日定下的边界要说清楚：DH 是金融信息感知平台，不是事实核查或辟谣平台。市场里能动价格的消息，常常一时查不清真假——一句含糊的政策表态、一则被否认的调查报道，都可能几分钟内改变预期。所以 DH 不拿"查清楚了没有"当发不发的开关，而是先感知、后丰富、持续更新：先把信息送出去并说明当前有多少不确定，出处追溯与背景补充在后面异步做；后来被证实、被否认、被修订，都作为新进展追加，不把早先的记录抹掉——因为"它当时让市场动了"本身就是有用的情报。至于这条信息值不值得研究、要不要下注、怎么下单，那是下游的事，不是 DH 的输出。

第二阶段目前已提议、未启动：方案写在 第二阶段知识包。这个方向本身已经在 2026-08-31 通过治理评审（意思是"往哪个方向做"定了），但什么时候开始、先做哪一批，仍由 Owner 单独决定，任何工程实施都还没有被批准。

接下来怎么推进​

当前正确顺序是：

  1. 维护真实工程事实地图；
  2. 维护 output、interface、architecture、collaboration inventories；
  3. 对未决问题做参考评估并记录 Owner 决策；
  4. 再下推产品定义、Gap、Roadmap 和 Work Package；
  5. 最后才进入正式对象、schema、API 或新架构设计。

这套顺序的目的不是增加文档，而是避免把一个消费者的紧急需求、一个已经存在的数据库字段，或者一个看起来顺手的技术方案误写成 DH 的长期战略。

怎样判断战略正在成立​

DH 成立的证据应同时来自三类结果：

  • 独立性：内部人员和内部机器不用依赖单一下游，也能完成完整信息运营闭环；
  • 可信性：身份、来源、权利、质量、修正、撤回和运行证据可查；
  • 可移植性：同一中立资产能通过不同 Adapter 服务多个结构不同的消费者，而不污染 Core。

功能数量、页面数量、请求量、单个客户满意度或交易收益，都不能单独替代这三类证据。

Changelog / 演化记录​

2026-08-31（第二次更新）：按 Owner 第六项决定补充第二阶段边界——DH 不做事实核查与辟谣，不拿核实当交付开关，采用“先感知、后丰富、持续更新”；“看得更清楚”的说法由“可信度”改为出处、不确定性、相关市场与后续变化的分维表达。

2026-08-31：更新“第一阶段现在到哪了”为收束完成（2026-08-31 Owner 判定 PASS，历史四维状态与未达标指标原样保留）；新增“第二阶段是什么、到哪了”，用四句大白话登记第二阶段方向（已提议、未启动）。

2026-08-27：新增“第一阶段现在到哪了”：四轴为 Governance Partial / Implementation Substantial / Production Partial / Acceptance Not accepted，执行读法 Phase 1 Closure（不重启第一阶段、未验收通过、不进入第二阶段）。

2026-08-21：基于事实地图、四类 inventory、参考评估与 Owner 决策重写；明确独立信息产品闭环、消费者顺序、Core / Interface / Adapter / 独立消费者边界，以及 To B / To C 条件。