跳到主要内容

Sync: Data Horizon Challenge-First Alignment Packet

日期：2026-05-12 来源项目 / 材料：Data Horizon / 数据视界、Labs-FinTecAI-Gov、/Users/mlabs/Programs/data-horizon 提交人 / 责任人：Curvature Labs ecosystem owner 当前状态：Draft / alignment packet skeleton 当前实践画像：projects/data-horizon/current-practice-profile.md 当前输出对象清单：projects/data-horizon/output-object-inventory.md

0. 当前定位​

本文是 Data Horizon / 数据视界 的挑战优先对齐包初版。

它用于承载：

  • 上游生态定义和 Data Horizon 正式定位；
  • 当前本地工程实践画像；
  • 当前实现需要被挑战的问题；
  • 待建立的参考评估问题域；
  • 第三方参考评估准入；
  • 后续方案建议、工程输入和 sync / escalation 候选。

本文不是：

  • 最终产品定义；
  • MVP 定义；
  • 工程实施计划；
  • backlog；
  • 对当前 /Users/mlabs/Programs/data-horizon 实现正确性或最优性的证明。

1. 上游定位​

当前已对齐口径：

  • Data Horizon / 数据视界 是 FinTec AI Ecosystem 中的独立金融信息感知系统和产品；
  • 它是金融信息链路中的“感知”环节，是金融“眼”；
  • 它可以服务生态内对象，也可以形成 To B / To C 的独立商业化产品或系统；
  • 它不承担主要金融认知中枢、最终研究结论、策略判断、交易执行或执行风控职责；
  • 它的第一阶段价值不应被定义为“成功向 FinClaw 或 AI Trading Matrix 供数”，而应证明独立金融信息产品闭环成立。

当前治理事实源：

  • baseline/03-current-baseline.md
  • registry/project-registry.md
  • projects/data-horizon/project-anchor.md
  • projects/data-horizon/inherited-context.md
  • projects/data-horizon/current-state.md

2. 当前工程实践画像​

本地工程仓库：

  • 路径：/Users/mlabs/Programs/data-horizon
  • 当前性质：早期工程实践资产，不是正式产品定义源。

初步已观察到的工程能力：

  • Go 后端：server/，基于 go-zero；
  • Python 采集服务：python-service/，当前更像补充或示例层；
  • 前端控制台：web/；
  • Watchdog：watchdog/；
  • 数据存储：MySQL、Redis、Weaviate；
  • 核心链路：采集任务写入 dn_raw_news，标准化任务处理 pending 信息，后续进入 Agent / direct push / push log；
  • 已存在信息源管理、标准化配置、订阅者配置、Open API、后台 news-feed 管理接口、Telegram / webhook / Trading Matrix 推送路径。

初步已观察到的信息源范围：

  • 加密媒体与 RSS；
  • 全球英文财经媒体；
  • 中文快讯；
  • TelegramRSS；
  • 宏观 / 市场信号；
  • 部分权益新闻扩展分析材料；
  • 部分宏观、财政、供应链、Yahoo Finance 信号任务。

初步已观察到的标准化能力：

  • 内容清洗；
  • 翻译；
  • 可选图片分析；
  • LLM 抽取 subjects、category、keywords；
  • Weaviate 语义去重；
  • 处理状态、错误、耗时记录。

初步已观察到的输出能力：

  • dn_raw_news 标准化记录；
  • std_content_zh / std_content_en；
  • subjects；
  • std_extra.category / std_extra.keywords；
  • Open API news latest/search/detail；
  • categories / hot assets；
  • Telegram / webhook / Trading Matrix push log；
  • 后台 news-feed source tree、list、header、authors。

3. 当前文档漂移​

本地工程仓库存在旧 PRD / 产品定义材料，其部分语言与当前上游口径冲突或需要降级为历史材料。

已识别的漂移包括：

  • 将 Data Horizon 写成“认知层”；
  • 将输出重点写成“交易信号”和“深度情报”；
  • 将 Stage 1 目标写成服务 Trading Matrix 和跑通 RMF 闭环；
  • 过早强调 PnL 反馈、信源信誉和信号准确率校准；
  • 容易把感知层能力推向认知、执行支持或交易触发。

处理原则：

  • 旧 PRD 不能反向覆盖 Labs-FinTecAI-Gov 中的上位生态定义和 Data Horizon 项目定义；
  • 旧 PRD 可作为工程历史、实践线索和待挑战材料；
  • 是否保留其中某些概念，必须通过当前对齐包和参考评估准入后再判断。

4. 挑战清单​

后续 Data Horizon alignment 必须从上位定义反向挑战当前实现，而不是替当前实现背书。

初始挑战问题：

  1. 定位挑战

    • 当前文档和实现是否仍把 Data Horizon 推向“认知层”“交易信号层”或 Trading Matrix 附属模块？

  2. 架构挑战

    • 当前 Go + Python + MySQL + Redis + Weaviate + Web 的组合是否适合长期高频、低成本、可追溯的金融信息感知？
    • 哪些部分应保留，哪些部分应重构、拆分、替换或降级？

  3. 流程挑战

    • 当前是否过度依赖统一 AI 标准化流水线？
    • 是否需要将规则/解析器、传统 NLP/搜索、本地小模型、缓存复用、云端 LLM 和人工复核分层？

  4. 数据模型挑战

    • 当前 dn_raw_news 是否足以表达 provenance、质量、授权、覆盖、适用限制、生命周期、修订历史和证据包？
    • 当前 subjects/category/keywords 是否过窄？

  5. 接口挑战

    • 当前 Open API、webhook、push、news-feed 管理接口是否足以支撑内部人类控制台、机器消费、To B 和 To C 产品面？
    • 是否需要 MCP、CLI、Skills、streaming feed、bulk export 或 dataset manifest？

  6. 控制台挑战

    • 当前前端/后台是否应按现有菜单评估，还是按内部控制台工作流能力评估？
    • 当前是否覆盖 source operations、ingestion monitoring、processing observability、information review、quality labeling、search/retrieval、subscription management、cost monitoring、failure recovery、export 和 evidence packaging？

  7. 成本挑战

    • 当前采集、标准化、翻译、图片/多模态处理、向量索引、推送、重试、重复处理和人工复核的成本是否可被观测、约束和分层？

  8. 协同挑战

    • 当前是否过早绑定 Trading Matrix 或某个下游系统？
    • Data Horizon 与 FinClaw、AI Trading Matrix、RLE、FEFM 的协同模式是否先被清单化，而不是直接冻结接口契约？

5. 参考评估前置问题域​

本阶段暂不冻结最小产品输出对象、结构定义、接口和架构。

应先建立以下参考评估前置问题域：

  1. 输出对象

    • 初版：projects/data-horizon/output-object-inventory.md
    • 状态：current implemented / current partial / documented but not implemented / reference candidate / proposed later / should avoid
    • 范围：当前输出对象、文档中提出对象、参考对象、候选对象、应避免对象。

  2. 质量 / provenance 参考评估问题域

    • 评估当前实践是否可追溯、可解释、可复核、可治理；
    • 评估参考项目如何处理来源、时效、授权、覆盖、质量反馈和适用限制；
    • 避免把感知对象伪装成确定性判断或交易触发器。

  3. 感知能力

    • 评估当前实践和参考项目如何完成监听、采集、清洗、组织、标准化、来源 / 时间 / 质量标记和输出。

  4. 信息覆盖

    • 评估非结构化信息、结构化金融数据、跨市场主题、事件流、项目更新和合法授权信息源的覆盖方式。

  5. 标准化方式

    • 评估规则、解析器、传统 NLP / 搜索、本地或小模型、缓存复用、云端 LLM 和人工复核如何分工。

  6. 存储检索

    • 评估原始内容、规范化结果、搜索、语义检索、证据材料、数据集和缓存如何被组织，但不在当前阶段冻结结构设计。

  7. 订阅推送与接口形态

    • 评估 Open API、后台 API、Telegram / webhook / Trading Matrix push、MCP、CLI、Skills、streaming feed、bulk export 和 dataset package 等形态能回答哪些上位问题，但不冻结接口优先级。

  8. 产品交互

    • 评估内部运营控制台、人类信息产品、机器消费面、外部 B 端和外部 C 端产品面分别需要验证什么价值。

  9. 成本控制

    • 评估高频、持久、成本密集的金融信息感知链路如何在质量约束下控制采集、标准化、翻译、多模态处理、索引、推送、重试和人工复核成本。

  10. 治理合规

  • 评估来源授权、非公开信息、可追溯、可解释、可复核、可治理和用户误导风险。
  1. 生态协同
  • 评估 Data Horizon 与 FinClaw、AI Trading Matrix、Reinforcement Learning Engine、Financial Expert Foundation Model、外部 B 端 / C 端消费者的协同边界，但不冻结接口契约。

6. 参考评估准入​

Data Horizon 后续增强建议前必须完成 reference evaluation gate。

筛选方式：

  • 不从固定竞品分类出发；
  • 不先假定 Bloomberg、金融新闻 API、另类数据商或开源 Agent 项目就是参考池；
  • 先从 Data Horizon 的第一性角色、职责、场景和能力问题出发；
  • 再为每个问题选择最合适的参考产品、项目、架构、协议、服务或实现。

当前参考评估维度候选：

  1. 能力范围；
  2. 架构框架；
  3. 技术栈与开发语言；
  4. 金融信息覆盖；
  5. 标准化处理；
  6. 存储模型；
  7. 检索能力；
  8. 订阅 / 推送；
  9. 协议定义；
  10. 接口形态；
  11. 人类产品交互；
  12. 生态协同；
  13. 成本控制；
  14. 质量与合规边界。

参考评估结果形成前，不输出正式工程重构、迭代、优化或修复建议。

7. 消费对象优先级​

当前已对齐的第一阶段消费对象优先级：

  1. 内部人类操作员 / 研究员；
  2. 内部机器消费方；
  3. 外部 B 端用户；
  4. 外部 C 端用户。

含义：

  • 第一阶段人类产品面是 Curvature Labs 内部 Data Horizon 后台系统 / 控制台 / Dashboard；
  • 当前工程仓库已有部分实现，但不代表完整或最优方案；
  • 后续应按内部工作流能力评估，而不是按当前菜单或页面结构评估；
  • 不应一开始把 Data Horizon 变成 Trading Matrix 附属数据模块；
  • 不应一开始以 To C 内容应用为主线。

8. 决策候选​

以下内容目前只能作为候选，不应进入最终结论：

  • 是否保留当前 Go 后端主线；
  • Python 采集服务应保留、增强、替换还是降级；
  • 当前 MySQL 表结构是否继续作为主存储；
  • Weaviate 是否只用于去重，还是扩展为语义检索/聚类；
  • 是否引入独立 Search Index；
  • 是否引入对象存储和 dataset/export store；
  • 是否建立 MCP / CLI / Skills；
  • 是否重构控制台信息架构；
  • 是否重新定义 Open API；
  • 是否建立参考评估 case library；
  • 哪些当前输出对象应保留、合并、改名或废弃。

这些候选必须等待 inventory 和 reference evaluation gate 后再进入方案建议。

9. 工程输入候选​

当前仅记录候选，不形成 backlog：

  • 本地工程实践画像补全；
  • 当前实现挑战清单补全；
  • 输出对象清单初版已形成，后续补充运行样例和参考评估对照；
  • 质量 / provenance 参考评估问题域；
  • 感知能力参考评估问题域；
  • 信息覆盖参考评估问题域；
  • 标准化方式参考评估问题域；
  • 存储检索参考评估问题域；
  • 订阅推送与接口形态参考评估问题域；
  • 内部控制台工作流能力评估；
  • 生态协同参考评估问题域；
  • 参考评估计划；
  • 参考评估 case library；
  • 参考项目筛选、体验、测试、评估和交叉对比。

10. Sync / Escalation 候选​

后续若出现以下情况，应考虑 sync 或 escalation：

  • 当前实践证明生态基线中的 Data Horizon 感知边界不够用；
  • 某些本地对象、结构定义、质量维度或协议应上升为生态共享定义；
  • 当前实现已经进入认知、策略判断、决策支持或执行触发边界；
  • 非公开信息、授权、合规或用户误导风险超出当前治理口径；
  • Data Horizon -> FinClaw 或 Data Horizon -> AI Trading Matrix 协同模式需要正式裁决；
  • 参考评估发现当前项目定义需要重大修改；
  • 成本控制约束要求改变架构或产品范围。

11. 当前下一步​

建议下一步按顺序推进：

  1. 将本文作为 Data Horizon alignment packet draft 入口；
  2. 以 projects/data-horizon/current-practice-profile.md 作为当前工程实践画像初版；
  3. 基于画像建立当前实现挑战清单；
  4. 建立第三方参考项目筛选原则；
  5. 建立参考评估问题域，覆盖感知能力、信息覆盖、标准化方式、存储检索、订阅推送、接口形态、产品交互、成本控制、治理合规等上位问题；
  6. 制定参考评估第一批问题和参考对象筛选方法；
  7. 再进入参考项目筛选、体验、测试、评估和交叉对比。

12. 吸收状态​

当前本文为 draft sync。

可能吸收位置：

  • projects/data-horizon/current-state.md
  • projects/data-horizon/project-anchor.md
  • projects/data-horizon/inherited-context.md
  • 后续 projects/data-horizon/CONTEXT.md
  • governance/program-controller-operating-model.md
  • 后续 Data Horizon Program Controller handoff

当前不应吸收为：

  • 最终产品定义；
  • MVP 定义；
  • 工程实施任务；
  • 正式接口契约。