Data Horizon / 数据视界 当前工程实践画像

状态：初版画像 最后更新：2026-05-12 项目：Data Horizon / 数据视界 本地实践仓库：/Users/mlabs/Programs/data-horizon 画像目的：为挑战优先对齐、inventory、第三方参考评估和后续工程输入提供事实底座

1. 本文档定位

本文档记录当前本地 data-horizon 工程实践的实际能力、证据、声明能力与实现能力差异、已知漂移和初始挑战点。

本文档不是：

• 正式产品定义；
• MVP 定义；
• 工程重构方案；
• 对当前实现正确性、充分性或最优性的证明；
• 后续增强建议。

本文档用于回答：

当前本地工程实践到底已经是什么，已经做到哪里，哪些只是声明或历史设想，哪些地方需要被 Data Horizon 的上位定位反向挑战？

2. 证据范围

本轮画像基于静态仓库阅读，不包含本地运行、数据库现场数据、线上任务状态、真实采集样本或端到端接口调用。

已阅读的主要证据包括：

• 根文档：README.md、CLAUDE.md、CONTEXT.md
• 后端任务与标准化：server/internal/job/*、server/internal/standardize/*
• 后端 API：server/api/*.api
• 数据模型：docs/sql/*.sql
• 前端控制台：web/src/router/routes/modules/datahorizon.ts、web/src/views/datahorizon/*
• Python 采集服务：python-service/*
• 旧 PRD / 分析材料：docs/prd/product-definition.md、docs/analysis-equity-news-expansion.md、docs/third-party-important-news-api-analysis.md

3. 总体画像摘要

当前本地工程实践不是空白原型，已经形成了一个以 Go 后端为主、Vue 控制台为人类运营面、MySQL / Redis / Weaviate 为数据与任务支撑、LLM / 翻译 / 推送为增强链路的金融信息采集与标准化系统。

它已经具备：

• 多来源金融信息采集任务；
• dn_raw_news 原始 / 标准化混合存储；
• 基于来源配置的清洗、翻译、图片识别、LLM 分类和关键词抽取；
• Weaviate 语义去重；
• Agent 分发、定时分析、直接推送和 push log；
• Open API 查询标准化新闻；
• MCP API Key 式鉴权和日限额；
• 内部控制台雏形；
• LLM / 翻译调用统计和成本估算能力；
• 部分权益新闻扩展分析材料。

同时，它也存在明显的定义漂移和工程边界问题：

• 根 README 与旧 PRD 仍把核心链路写成推送给 Trading Matrix；
• 旧 PRD 将 Data Horizon 描述为“交易信号”“深度情报”“认知层”和 RMF 闭环；
• Python 服务声明覆盖金融 / 股票新闻，但实际实现主要是 CoinDesk 示例和 TODO；
• 当前标准化对象偏 subjects/category/keywords，provenance、质量、授权、适用限制、生命周期和证据包表达不足；
• 当前控制台已覆盖许多管理页面，但还不能仅凭页面存在证明完整的内部运营工作流；
• 成本统计已有基础，但采集、标准化、翻译、图片识别、向量索引、推送、重试和人工复核的整体成本治理尚未形成完整产品能力。

4. 当前系统边界

4.1 工程构成

当前本地仓库结构可确认：

• server/：Go 后端，基于 go-zero；
• web/：Vue 3 前端控制台；
• python-service/：Python 定时抓取服务；
• watchdog/：独立 watchdog 服务；
• docs/sql/：MySQL 表结构；
• docs/prd/、docs/task/、docs/skill/、docs/research/：历史产品、任务、技能和研究材料。

证据：

• README.md:7 到 README.md:12 明确列出 server、web、python-service；
• README.md:23 到 README.md:28 声明技术栈为 Go、Vue、MySQL、Redis、Weaviate 和多家 LLM；
• CLAUDE.md:5 到 CLAUDE.md:7 重复确认感知层定位和技术栈。

4.2 当前工程主线

当前主线不是 Python 服务，而是 Go 后端 Cron + MySQL + 标准化 + Agent / 直推 / PushJob。

证据：

• CLAUDE.md:11 到 CLAUDE.md:15 将主链路写成 ScraperJob -> dn_raw_news -> AgentJob -> PushJob；
• server/internal/job/cron_manager.go:122 到 server/internal/job/165 注册了标准化、RawNews 分发、推送、分析师定时聚合、多个新闻 / RSS / 宏观 / 市场信号抓取任务；
• docs/analysis-equity-news-expansion.md:27 到 docs/analysis-equity-news-expansion.md:30 明确判断权益新闻扩展主战场应在 Go 侧 Job + 渠道配置，Python 只是补充。

5. 信息源与采集能力画像

5.1 当前已出现的信息源类型

静态代码和文档能确认当前工程已经覆盖或预留以下来源类型：

• 加密媒体和 RSS：CoinDesk、Cointelegraph、Decrypt、Bankless、Crypto RSS；
• 全球英文财经媒体：Bloomberg、WSJ World / Business / Markets；
• 中文快讯：金十；
• TelegramRSS：电报时报、华尔街见闻财经时讯、财经慢报；
• 宏观 / 市场信号：Treasury、GSCPI、Yahoo Finance；
• 更广义事件源预留：GDELT、FRED、CISA KEV、WHO、FIRMS、ReliefWeb、NOAA、Space、USAspending、Patents、EPA、Comtrade、BLS 等部分任务已存在但在 Cron 注册中处于注释状态。

证据：

• server/internal/job/cron_manager.go:126 到 server/internal/job/140 注册 Bloomberg、Jin10、CoinDesk、Cointelegraph、WSJ、Decrypt、Crypto RSS、Bankless、Telegram topic sync；
• server/internal/job/cron_manager.go:146 到 server/internal/job/160 显示 Crucix / 宏观 / 市场信号任务，其中 Treasury、GSCPI、YFinance 启用，多个事件源注释；
• server/internal/job/cron_manager.go:162 到 server/internal/job/165 注册 TelegramRSS 三个频道；
• docs/analysis-equity-news-expansion.md:16 到 docs/analysis-equity-news-expansion.md:25 对加密媒体、中文快讯、美媒、Bloomberg、YFinance、Treasury、GSCPI 做了现状归类。

5.2 当前来源配置能力

dn_crawler_source 已把信息源抽象为可运营对象，具备平台、来源类型、语言、外部 ID、状态、分类、KOL、标准化配置和业务标签。

证据：

• docs/sql/dn_crawler_source.sql:1 到 docs/sql/dn_crawler_source.sql:23 定义 source_no、platform、source_type、language、external_id、status、category_id、kol_id、std_config、tags；
• server/api/crawler_source.api:6 到 server/api/crawler_source.api:21 暴露来源列表字段；
• server/api/crawler_source.api:83 到 server/api/crawler_source.api:90 限定更新字段包括 status、categoryId、kolId、stdConfig、tags；
• server/api/crawler_source.api:133 到 server/api/crawler_source.api:158 提供标准化测试返回清洗、翻译、AI 分析和耗时。

5.3 Python 服务实际状态

Python 服务文档声明覆盖加密、金融和股票新闻抓取，但实际代码显示金融和股票抓取仍是 TODO，当前只有 CoinDesk 示例级实现。

证据：

• python-service/README.md:5 到 python-service/README.md:10 声明新闻抓取、定时任务、数据库和结构化日志；
• python-service/main.py:20 到 python-service/main.py:24 注册 crypto、finance、stock 三类任务入口；
• python-service/tasks/scraper_tasks.py:28 到 python-service/tasks/scraper_tasks.py:36 只映射了 coindesk，并注释“更多 scraper 待实现”；
• python-service/tasks/scraper_tasks.py:85 到 python-service/tasks/scraper_tasks.py:91 明确 finance scraper 尚未实现；
• python-service/tasks/scraper_tasks.py:114 到 python-service/tasks/scraper_tasks.py:120 明确 stock scraper 尚未实现；
• python-service/scrapers/crypto/coindesk_scraper.py:41 到 python-service/scrapers/crypto/coindesk_scraper.py:43 标注选择器仍需按真实网站结构调整，是 placeholder。

6. 标准化与处理链路画像

6.1 当前主处理链路

当前处理链路可以概括为：

采集 Job
  -> dn_raw_news(status=0)
  -> StandardizeJob
  -> dn_raw_news(status=1，写入 std_content / subjects / std_extra)
  -> RawNewsJob
  -> AgentTask + DirectPushTask
  -> dn_push_log
  -> PushJob
  -> Telegram / Webhook / Trading Matrix 类 HTTP 目标

证据：

• server/internal/job/standardize_job.go:10 到 server/internal/job/17 描述标准化任务职责；
• server/internal/standardize/standardize.go:125 到 server/internal/standardize/standardize.go:139 读取 pending 新闻并逐条处理；
• server/internal/job/raw_news_job.go:17 到 server/internal/job/raw_news_job.go:23 描述读取已标准化新闻并执行 AgentTask + DirectPushTask；
• server/internal/job/push_message_job.go:20 到 server/internal/job/push_message_job.go:30 说明 PushJob 只负责按 target_url 协议发送 payload。

6.2 当前标准化阶段

当前标准化链路包含：

• Weaviate 语义去重；
• 规则清洗；
• 可选翻译；
• 可选图片识别；
• LLM 抽取 subjects、category、keywords；
• 写回 std_content_zh、std_content_en、subjects、std_extra、std_cost_ms、last_err。

证据：

• server/internal/standardize/standardize.go:190 到 server/internal/standardize/standardize.go:194 描述清洗、翻译、AI 分析三阶段；
• server/internal/standardize/standardize.go:195 到 server/internal/standardize/standardize.go:199 执行去重检查；
• server/internal/standardize/standardize.go:201 到 server/internal/standardize/standardize.go:214 执行规则清洗与截断；
• server/internal/standardize/standardize.go:216 到 server/internal/standardize/standardize.go:254 执行翻译；
• server/internal/standardize/standardize.go:256 到 server/internal/standardize/standardize.go:275 执行可选图片分析；
• server/internal/standardize/standardize.go:277 到 server/internal/standardize/standardize.go:295 执行 LLM 分析；
• server/internal/standardize/standardize.go:297 到 server/internal/standardize/standardize.go:307 写入 Weaviate 并返回结果；
• server/internal/standardize/standardize.go:56 到 server/internal/standardize/standardize.go:75 定义当前标准化结果和 std_extra 结构。

6.3 当前 LLM 标准化边界

当前 LLM 标准化主要抽取最多 6 个加密 ticker、一个分类和最多 3 个关键词。它更像轻量分类 / 索引增强，而不是完整金融事件建模。

证据：

• server/internal/standardize/standardize.go:77 到 server/internal/standardize/standardize.go:91 的系统提示词限制 subjects、category、keywords；
• docs/third-party-important-news-api-analysis.md:88 到 docs/third-party-important-news-api-analysis.md:93 明确当前 std_extra 只包含 category 和 keywords；
• docs/third-party-important-news-api-analysis.md:130 到 docs/third-party-important-news-api-analysis.md:142 明确当前缺少重要度、四段式 insight / impact / strategy / risk、标签和图标等字段。

7. 数据模型画像

7.1 当前核心表

当前核心表包括：

• dn_raw_news：原始内容、来源、语言、状态、标准化内容、关联标的、扩展数据、耗时、错误；
• dn_crawler_source：来源配置；
• dn_agent：Agent 配置；
• dn_agent_execution：Agent 执行记录；
• dn_subscriber：订阅者配置；
• dn_raw_news_direct：直推配置；
• dn_push_log：推送日志；
• dn_llm_call_log / dn_translate_call_log：LLM 和翻译调用记录；
• dn_mcp_api_key：Open API Key 管理和日限额。

证据：

• docs/sql/dn_raw_news.sql:1 到 docs/sql/dn_raw_news.sql:29 定义原始 / 标准化混合新闻表；
• docs/sql/dn_agent.sql:8 到 docs/sql/dn_agent.sql:45 定义 Agent 的触发、处理、输入、输出和状态；
• docs/sql/dn_agent_execution.sql:11 到 docs/sql/dn_agent_execution.sql:37 定义执行记录；
• docs/sql/dn_subscriber.sql:1 到 docs/sql/dn_subscriber.sql:16 定义订阅者和过滤条件；
• docs/sql/dn_push_log.sql:1 到 docs/sql/dn_push_log.sql:35 定义推送日志、幂等 key、目标、payload、状态、错误和耗时；
• docs/sql/dn_llm_call_log.sql:9 到 docs/sql/dn_llm_call_log.sql:29 定义 LLM 调用日志；
• docs/sql/dn_translate_call_log.sql:8 到 docs/sql/dn_translate_call_log.sql:29 定义翻译调用日志；
• docs/sql/dn_mcp_api_key.sql:1 到 docs/sql/dn_mcp_api_key.sql:17 定义 API Key、日限额、使用次数、过期和状态。

7.2 当前 provenance 与质量表达

当前已经具备部分基础 provenance 字段：

• 来源 ID、来源名称、来源作者；
• 来源类型；
• 原始 URL；
• 原始发布时间；
• 入库时间；
• 处理状态；
• 标准化耗时；
• 最后错误；
• 重复新闻 ID。

但当前还未充分表达：

• 版权 / 授权状态；
• 来源可信度；
• 信息适用限制；
• 缺失字段；
• 修订历史；
• 撤回 / 过期 / 生命周期；
• 多源证据包；
• 质量标签；
• 重要度和置信度；
• 人工复核状态。

证据：

• docs/sql/dn_raw_news.sql:3 到 docs/sql/dn_raw_news.sql:22 覆盖基础来源、时间、语言、状态、标准化和错误字段；
• docs/third-party-important-news-api-analysis.md:48 到 docs/third-party-important-news-api-analysis.md:63 列出第三方接口通常仍需要的 id、发布时间、入库时间、来源、重要度、作者、相关资产和生命周期状态；
• docs/third-party-important-news-api-analysis.md:140 到 docs/third-party-important-news-api-analysis.md:142 指出 Open API 未暴露原文时间，且缺少重要度。

8. 输出与接口画像

8.1 Open API

当前 Open API 已提供：

• 最新标准化新闻；
• 关键词搜索；
• 新闻详情；
• 事件分类；
• 热门资产；
• KOL source signal list；
• KOL source list。

这些接口使用 McpApiKeyMiddleware，而不是 JWT。

证据：

• server/api/open.api:45 到 server/api/open.api:73 定义 OpenNewsItem 和 OpenNewsDetail；
• server/api/open.api:91 到 server/api/open.api:142 定义 latest、search、detail、categories、hot assets；
• server/api/open.api:145 到 server/api/open.api:179 定义 /v1/open 服务和 MCP API Key 中间件；
• server/internal/middleware/mcp_apikey_middleware.go:31 到 server/internal/middleware/mcp_apikey_middleware.go:75 校验 X-API-Key、日限额并异步增加使用量。

8.2 内部后台 API

当前内部后台 API 已覆盖：

• 来源管理；
• 标准化配置测试；
• 新闻 feed 树、列表、统计、作者；
• Agent 管理；
• Agent 执行记录；
• 订阅者管理；
• 原始新闻直推配置；
• Telegram channel / topic；
• KOL；
• LLM provider / config；
• MCP API Key；
• push log；
• statistics。

证据：

• server/api/crawler_source.api:161 到 server/api/crawler_source.api:198 提供来源 CRUD、清洗模板和标准化测试；
• server/api/news_feed.api:109 到 server/api/news_feed.api:130 提供 news-feed source-tree、list、header、authors；
• server/api/subscriber.api:102 到 server/api/subscriber.api:131 提供订阅者 CRUD 和 options；
• server/api/raw_news_direct.api:79 到 server/api/raw_news_direct.api:108 提供直推配置管理；
• server/api/statistics.api:147 到 server/api/statistics.api:176 提供 LLM、新闻、翻译统计。

8.3 推送与订阅

当前有两类主要输出路径：

• Agent 处理路径：启用 Agent 对已标准化新闻进行实时或定时分析，再写 push log；
• 直推路径：按来源直推到 Telegram、Webhook 或 TM 类目标。

证据：

• server/internal/job/raw_news_job.go:79 到 server/internal/job/raw_news_job.go:106 将标准化新闻分发给启用 Agent；
• server/internal/job/raw_news_job.go:108 到 server/internal/job/raw_news_job.go:167 读取直推配置并根据 output type 写入 push log；
• server/internal/job/push_message_job.go:55 到 server/internal/job/push_message_job.go:67 通过 tg:// 或 http 前缀决定发送路径；
• docs/sql/dn_subscriber.sql:7 到 docs/sql/dn_subscriber.sql:10 支持按 subjects、categories、source types、source urls 订阅；
• server/api/raw_news_direct.api:31 到 server/api/raw_news_direct.api:38 支持批量添加消息源直推配置。

9. 控制台画像

9.1 当前页面能力

当前前端已经存在 DataHorizon 模块路由，包含：

• Agent；
• Crawler Source；
• KOL；
• RawNewsDirect；
• Telegram Topic；
• Crawler Source Category；
• Event Category；
• LLM Provider；
• LLM Config；
• Agent Execution；
• MCP API Key。

证据：

• web/src/router/routes/modules/datahorizon.ts:5 到 web/src/router/routes/modules/datahorizon.ts:118 定义 DataHorizon 路由；
• web/src/views/datahorizon/* 下存在对应页面、表单和组件；
• docs/data/init_menu.sql:80 到 docs/data/init_menu.sql:156 定义数据库菜单中的 DataHorizon 目录和多个管理项。

9.2 控制台初步判断

当前控制台已经覆盖“后台管理对象”，但还需要按工作流能力重新评估：

• source operations：部分具备；
• ingestion monitoring：部分具备，news-feed 有统计；
• processing observability：部分具备，Agent execution、LLM / 翻译统计存在；
• information review：部分具备，news-feed 列表可查看内容；
• quality labeling：证据不足；
• search / retrieval：Open API 有 search，内部控制台检索能力待进一步核验；
• subscription management：具备部分订阅者和直推配置；
• cost monitoring：LLM 和翻译成本有基础，完整链路成本不足；
• failure recovery：有状态和错误字段，但恢复工作流证据不足；
• export / evidence packaging：证据不足。

这个判断只是画像，不是控制台改造建议。

10. 成本与可观测画像

当前已具备若干成本和可观测基础：

• 标准化耗时；
• 推送耗时；
• LLM 调用 token、耗时、成功 / 失败；
• 翻译调用字符数、耗时、成功 / 失败；
• LLM 配置日限额；
• MCP API Key 日限额；
• Dashboard 新闻 / LLM / 翻译统计接口。

证据：

• docs/sql/dn_raw_news.sql:19 定义 std_cost_ms；
• docs/sql/dn_push_log.sql:24 定义 push cost_ms；
• docs/sql/dn_llm_call_log.sql:17 到 docs/sql/dn_llm_call_log.sql:21 记录 token、耗时、状态和错误；
• docs/sql/dn_translate_call_log.sql:16 到 docs/sql/dn_translate_call_log.sql:21 记录字符数、语言、耗时、状态和错误；
• server/pkg/llm/selector.go:66 到 server/pkg/llm/selector.go:113 按标签选择 LLM 并检查 daily limit；
• server/pkg/llm/selector.go:116 到 server/pkg/llm/selector.go:178 记录 LLM 调用日志并增加使用次数；
• server/internal/logic/statistics/llm_config_stats_logic.go:57 到 server/internal/logic/statistics/llm_config_stats_logic.go:62 基于 input / output token 价格估算成本。

当前不足：

• 采集成本、反爬维护成本、向量索引成本、图片识别成本、重试成本、人工复核成本尚未形成统一视图；
• 成本控制目前偏 LLM / 翻译 / API Key 维度，还不是 Data Horizon 整体感知链路成本模型；
• 没有证据显示系统能按信息价值、风险、消费需求自动选择低成本或高质量路径。

11. 文档与定义漂移

当前本地工程文档和旧 PRD 与上游治理定义存在明显漂移。

漂移点包括：

• 将 Data Horizon 定义为“交易信号”和“深度情报”输出方；
• 将第一用户定义为 Trading Matrix；
• Stage 1 目标写成服务 Trading Matrix、跑通 RMF 闭环；
• 将系统总结为“认知层”；
• 引入 PnL 反馈、信源信誉动态调整、后验校准等偏认知 / 反馈学习能力。

证据：

• README.md:3 将系统写成采集全球金融新闻、AI 标准化后推送给 Trading Matrix；
• README.md:30 到 README.md:34 的核心流程以 Trading Matrix 为终点；
• docs/prd/product-definition.md:7 将 Data Horizon 定义为输出“交易信号”和“深度情报”；
• docs/prd/product-definition.md:18 到 docs/prd/product-definition.md:23 将第一用户写成 Trading Matrix，并给出带 probability / impact 的事件输出；
• docs/prd/product-definition.md:37 到 docs/prd/product-definition.md:43 将信源评级、信号打分和 PnL 反馈列入 scope；
• docs/prd/product-definition.md:87 到 docs/prd/product-definition.md:93 将 Stage 1 写成服务 Trading Matrix 和跑通 RMF；
• docs/prd/product-definition.md:108 到 docs/prd/product-definition.md:115 将 Data Horizon 总结为“认知层”。

治理判断：

• 这些文档可作为历史实践和待挑战材料；
• 不能反向覆盖 Data Horizon 当前正式定位；
• 不能直接作为产品定义、MVP 或工程 backlog 的依据。

12. 初始 Challenge Inventory

以下不是解决方案，只是下一阶段必须逐项挑战的问题。

12.1 定位挑战

当前实现和文档仍存在强 Trading Matrix 附属倾向。需要判断哪些对象、命名、接口或流程只是历史残留，哪些确实已经让 Data Horizon 进入认知 / 执行支持边界。

12.2 输出对象挑战

当前主输出集中在 dn_raw_news 标准化字段、Open API 新闻项、push log payload、Agent 分析结果。需要确认哪些应成为 Data Horizon 信息对象，哪些只是内部实现产物或历史接口。

12.3 数据模型挑战

当前 dn_raw_news 同时承载原始和标准化内容，是否足以支撑 Raw Store、Normalized Store、Evidence Package、Dataset / Export Store 和质量 / provenance metadata，需要后续参考评估再判断。

12.4 标准化挑战

当前 LLM 标准化对象偏加密 ticker、category、keywords。若 Data Horizon 面向更广义金融信息感知，需要挑战这套抽取对象是否过窄、是否混淆分类与认知判断、是否缺少质量与来源约束。

12.5 架构挑战

当前 Go Cron 任务密集、高频轮询、多源 scraper、LLM、翻译、Weaviate、MySQL 和推送耦合在一个后端服务中。是否适合长期高频、持久、低成本、可追溯的金融信息感知，需要结合参考评估再判断。

12.6 Python 服务挑战

Python 服务目前声明大于实现。需要判断它是应补强为采集适配器层，还是降级为实验 / 示例层，或者被 Go 侧主线吸收。

12.7 控制台挑战

当前控制台存在多个管理页，但是否覆盖真实内部运营控制台工作流，不能按页面数量判断。必须按 source operations、ingestion monitoring、processing observability、review、quality labeling、search、subscription、cost、failure recovery、export 评估。

12.8 成本挑战

当前已有 LLM / 翻译调用统计和估算，但 Data Horizon 作为最高频、持久化、成本密集节点，需要挑战是否已有全链路成本观测、限额、分层处理和价值驱动路由。

12.9 接口挑战

当前存在 Open API、Webhook、Telegram、Trading Matrix 类 HTTP push、MCP API Key，但还没有证明这些接口就是未来的外部接口协议或内部对象协议。必须先放入参考评估问题域，不应直接冻结为接口设计。

12.10 参考评估挑战

当前仓库已有第三方高重要度新闻接口分析和权益新闻扩展分析，但这些材料还不是完整 Data Horizon reference evaluation gate。后续参考筛选必须从 Data Horizon 第一性问题出发，而不是从已有文档或单一竞品类型出发。

13. 当前画像结论

当前本地 data-horizon 仓库已经具备可继续盘点和挑战的工程基础：

• 它不是空白原型；
• 它已经有多源采集、标准化、后台管理、推送和 Open API；
• 它已经有部分成本和调用统计；
• 它已经具备内部运营控制台的雏形；
• 它也已经积累了明显历史漂移、实现不完整、对象表达不足和架构待挑战问题。

因此，下一步不应直接写增强建议，也不应进入字段、结构定义、接口或工程实施设计，而应继续完成：

1. 第三方参考项目筛选原则；
2. 参考评估问题域；
3. 第一批参考对象筛选方法；
4. 参考项目筛选、体验、测试、评估和交叉对比；
5. 当前实践画像与参考评估结果的对照吸收。

14. 吸收建议

本文档可作为以下文档的事实输入：

• projects/data-horizon/current-state.md
• packets/sync/data-horizon-alignment-packet-2026-05-12.md
• projects/data-horizon/output-object-inventory.md
• 后续 Data Horizon reference evaluation packet
• 后续 Data Horizon 参考评估材料

本文档不应直接吸收为：

• 产品定义；
• MVP；
• PRD；
• 工程实施计划；
• 架构决策记录。