夜雨聆风
OpenClaw 数据源分层:官方公告、行情资金、媒体新闻、热搜线索可信度完全不同
说明：本文不是荐股。本文讨论的是 OpenClaw / AI Agent 如何整理公开市场信息、设计数据源可信度分层和事实核查流程。文中出现的公告、资金、新闻、热搜等，只作为信息工程样例，不构成任何投资建议，不代表任何买卖操作，也不承诺任何收益。
前面量化信息工程文章里，我一直强调一个判断：AI 量化系统最先要做的不是预测涨跌，而是把市场信息流整理成可检索、可核验、可复盘的证据库。
但只建新闻库还不够。
如果系统把“上市公司公告”“交易所披露”“行情资金聚合”“媒体报道”“热搜榜”“群聊截图”“小作文”全部放在同一个字段里，再让大模型统一总结，风险会非常大。
因为它们的可信度完全不是一回事。
这篇文章讲一个更底层的设计：在 OpenClaw 的量化信息工程里，如何给数据源分层，如何设计 source_type、verification_status、source_reliability，以及如何避免把热搜和小作文当成事实。
读完你至少可以带走三件事：
-
一个概念：数据源可信度分层是什么； -
一个方法：如何把不同来源写进统一 schema； -
一个 checklist：发布或入库前如何检查“这到底是事实，还是线索”。
1. 为什么数据源必须分层？
在市场信息流里，同一句话可能来自很多地方。
比如“某公司获得大额订单”。它可能是：
-
● 公司正式公告； -
● 交易所互动平台回复； -
● 财经媒体报道； -
● 券商研报摘录； -
● 行业论坛转述； -
● 社交平台热搜； -
● 聊天群截图； -
● 一段没有出处的小作文。
它们看起来都在表达同一个主题，但在证据链上完全不同。
对 AI Agent 来说，如果不先区分来源等级，后面很容易出现三类错误：
- 把注意力当事实
：热搜只能说明“很多人在讨论”，不能证明事情是真的。 - 把转述当原文
：媒体摘要、用户截图、二次解读都可能丢失限定条件。 - 把解释当结论
：资金流、龙虎榜、主题热度可以记录，但不能自动推出“后续一定上涨”。
所以，数据源分层的核心不是“谁更高级”，而是让系统在每一步都知道：
这条信息能支撑什么结论，不能支撑什么结论。
2. 一句话定义：什么是数据源可信度分层？
我的定义是：
数据源可信度分层，是把每条市场信息按来源、原始性、可追溯性、更新时点和核验状态标注清楚，避免 AI Agent 把线索、传言、解释和事实混成同一种东西。
这里有三个关键词。
第一，来源：信息从哪里来？是官方披露，还是媒体报道，还是社交平台？
第二，原始性：它是一手原文，还是别人转述？有没有链接、公告编号、发布时间、原始文本？
第三，核验状态：它只是单一来源，还是已经被多源交叉确认？有没有官方原文支撑？
这三个问题，比“这条新闻看起来重要不重要”更基础。
3. 我会把市场数据源粗分成六层
下面这个分层不是法律意义上的证明标准，而是信息工程里的实用分级。
|
|
|
|
|
|
|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这个表对 OpenClaw 很重要。
因为 Agent 每天早上醒来后，不只是“把信息总结一下”，而是要先判断：这条信息应该进入哪个层级，后续能触发什么动作。
例如：
-
● L1 官方公告：可以进入事实库，并触发结构化字段抽取； -
● L3 资金数据：可以进入行情行为库，但必须记录口径和时点； -
● L5 热搜：可以进入注意力库，但默认不能进入事实库； -
● L6 小作文：只能进入待核查或风险样本，不能作为结论依据。
4. 三个字段：sourcetype、verificationstatus、sourcereliability
如果只在数据库里存一个 source 字段，通常不够。
我更建议至少拆成三个字段。
4.1 sourcetype：它是什么类型的来源？
source_type 用来描述来源类别。
示例：
“`json
{
“source_type”: “official_disclosure”,
“source_name”: “交易所公告”,
“source_url”: “https://example.com/disclosure/xxx”,
“published_at”: “2026-06-01T08:00:00+08:00”
}
“`
它回答的是：这条信息来自哪一类渠道。
不要把 source_name 和 source_type 混在一起。source_name 是具体来源名称，source_type 是系统可识别的分类。
4.2 verificationstatus：它核验到哪一步？
verification_status 用来描述核查状态。
我常用这几个值：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这里特别要注意：
source_only 不等于“已经证实”。
它只表示“我知道这条信息从哪里来”，不表示“这条信息是真的”。
4.3 sourcereliability：这类来源默认多可靠？
source_reliability 是一个系统默认权重，可以是枚举，也可以是分数。
例如：
“`json
{
“source_type”: “social_attention”,
“source_reliability”: “low”,
“verification_status”: “source_only”
}
“`
或者：
“`json
{
“source_type”: “official_disclosure”,
“source_reliability_score”: 0.95,
“verification_status”: “verified”
}
“`
但要小心：分数不是魔法。
它只能帮助排序和降权，不能替代事实核查。尤其在财经内容里，“看起来可靠”的来源也可能转述错误、标题夸张、口径不一致。
5. 一个推荐 schema：先记录证据，再让 AI 总结
我会让 OpenClaw 先存结构化证据，再生成摘要。
一个简化版入库记录可以这样设计：
“`json
{
“id”: “news_20260601_0001”,
“title”: “某行业出现新的政策或订单线索”,
“raw_text”: “保留原文或可追溯摘要，不能只存 AI 改写版。”,
“source_name”: “示例财经媒体”,
“source_type”: “professional_media”,
“source_url”: “https://example.com/news/xxx”,
“published_at”: “2026-06-01T07:42:00+08:00”,
“collected_at”: “2026-06-01T08:01:00+08:00”,
“source_reliability”: “medium”,
“verification_status”: “source_only”,
“claim_type”: “reported_event”,
“tags”: [“半导体”, “政策”, “待核查”],
“related_watchlist”: false,
“requires_human_review”: true,
“allowed_use”: [“clue”, “topic_tracking”],
“blocked_use”: [“fact_claim”, “trading_signal”, “public_conclusion”],
“notes”: “缺少官方原文，不能作为事实结论。”
}
“`
这里最关键的是两个数组：allowed_use 和 blocked_use。
它们强迫 Agent 明确：这条信息可以用来做什么，不能用来做什么。
比如热搜可以进入 topic_tracking，但不能进入 fact_claim；资金流可以进入 market_behavior，但不能直接进入 buy_signal。
这比只写一个“重要新闻”安全得多。
6. 热搜、小作文和截图：为什么只能当线索？
热搜不是没价值。
它的价值在于告诉你：市场正在把注意力投向哪里。
但注意力和事实之间隔着很长一段路。
一条热搜可能来自真实事件，也可能来自标题党、断章取义、情绪传播、营销号放大，甚至是旧闻重炒。小作文和截图的问题更明显：
-
● 不知道原始出处； -
● 不知道发布时间； -
● 不知道是否被截断； -
● 不知道是否经过篡改； -
● 不知道转发者是否加入了自己的解释； -
● 很难追溯责任主体。
所以在 OpenClaw 里，我倾向于给这类信息设置硬规则：
“`text
如果 source_type ∈ [social_attention, unverified_claim]
并且 verification_status 不是 verified 或 cross_checked
则不得进入事实结论，不得生成确定性判断，不得作为交易建议。
“`
它们最多触发三个动作：
-
搜索官方来源； -
搜索可靠媒体或交易所披露； -
进入人工复核队列。
换句话说，热搜的正确用法不是“热搜说了，所以是真的”，而是：
热搜提示我应该去找更可靠的证据。
7. 行情资金和龙虎榜：不是谣言，但也不是因果解释
行情资金、成交额、涨跌幅、龙虎榜这类数据，比热搜更结构化，也更容易量化。
但它们仍然需要谨慎使用。
原因是：这类数据通常能证明“发生了什么市场行为”，但不能单独证明“为什么发生”。
例如：
-
● 主力资金净流入：要记录统计口径、数据供应商、时间窗口； -
● 龙虎榜席位：要记录上榜原因、买卖金额、席位类型和日期； -
● 成交额放大：要记录基准区间，而不是只写“放量”； -
● 涨跌幅：要记录交易日、复权口径、所属市场和停复牌情况。
因此，在 schema 里，行情资金类数据通常应该是：
“`json
{
“source_type”: “market_data”,
“claim_type”: “market_observation”,
“verification_status”: “source_only”,
“metric_name”: “net_inflow”,
“metric_window”: “2026-06-01 intraday”,
“data_provider”: “example_provider”,
“allowed_use”: [“market_behavior”, “backtest_feature”],
“blocked_use”: [“causal_claim”, “guaranteed_prediction”]
}
“`
它可以成为回测字段，也可以成为复盘线索，但不能自动变成“因为资金流入，所以明天会上涨”。
8. OpenClaw 的处理流程：先分层，再核查，再生成
我比较推荐的工作流是五步。
第一步：采集原文
尽量保留 raw_text、url、published_at、collected_at。
AI 摘要不能替代原文。没有原文的摘要，以后很难复盘。
第二步：识别来源类型
让系统先判断 source_type：官方公告、行情资金、媒体新闻、热搜线索，还是未核验转发。
第三步：抽取 claim
不要只存一整篇文章。要把其中的可核查主张拆出来。
例如：
“`text
claim：某公司披露了某项合同。
claim_type：official_event
claim_subject：公司 / 行业 / 政策 / 指数
claim_time：公告或报道时间
“`
第四步：设置核验状态
根据来源和证据链设置 verification_status。
没有官方原文，不要轻易写 verified。
第五步：限制输出用途
根据核验状态决定它能不能出现在日报、公众号、回测特征、人工复核列表里。
一个实用规则是：
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
9. 给读者的可复制 checklist
如果你也在用 OpenClaw 或其他 AI Agent 做市场信息整理，可以用下面这张清单检查自己的系统。
数据源入库 checklist
-
● [ ] 是否保留原始链接或原始文本？ -
● [ ] 是否记录发布时间和采集时间？ -
● [ ] 是否区分 source_name和source_type？ -
● [ ] 是否标注 source_reliability？ -
● [ ] 是否标注 verification_status？ -
● [ ] 是否区分事实、报道、观点、解释、传言？ -
● [ ] 是否记录数据口径，例如资金流统计窗口？ -
● [ ] 是否把热搜和小作文默认降权？ -
● [ ] 是否为未核验信息设置 requires_human_review？ -
● [ ] 是否明确 allowed_use和blocked_use？
公众号发布前 checklist
-
● [ ] 标题是否暗示“买入、暴涨、确定收益”？ -
● [ ] 是否把热搜写成了事实？ -
● [ ] 是否把媒体报道写成了官方公告？ -
● [ ] 是否把资金流写成了因果解释？ -
● [ ] 是否公开了个人持仓、成本或操作计划？ -
● [ ] 是否保留“不构成投资建议”的边界？ -
● [ ] 是否说明未核验内容只是线索？ -
● [ ] 是否避免使用“必涨、稳赚、躺赢、翻倍”等词？
10. 一个常见坑：让大模型直接给“可信度评分”
很多人会说：那我让大模型直接给每条新闻打 0 到 100 分不就行了？
我不建议一上来就这么做。
因为如果没有结构化字段，模型的评分很容易变成“看起来像真的”。它可能受标题长度、措辞强度、来源名熟悉度影响，而不是基于证据链。
更稳的方法是：
-
先用规则确定来源类型； -
再用检索补全原文和交叉来源； -
再由模型解释“为什么这个状态是 source_only / needs_check / verified”； -
最后才考虑给排序分。
也就是说，模型应该参与解释和辅助归类，而不是替代证据。
11. FAQ
Q1：官方公告一定真实吗？
官方公告是一手来源，可信度最高，但不等于不需要理解上下文。
公告可能有会计口径、前提条件、风险提示、尚未生效条款。OpenClaw 可以把它标为 verified，但不能因此直接生成投资结论。
Q2：媒体新闻还有价值吗？
有。媒体新闻适合做线索发现、背景补充和事件跟踪。
但如果文章要写成事实结论，最好继续追到公告、监管披露、公司原文或多家可靠来源。
Q3：热搜完全不能用吗？
不是。热搜适合做注意力指标和复核触发器。
它告诉系统“这里可能有市场关注”，但不能证明事件本身为真。
Q4：资金流是不是比新闻更客观？
资金数据通常更结构化，但不同供应商口径可能不同。它能记录市场行为，不等于能证明资金背后的真实动机，也不能单独推导后续走势。
Q5：AI Agent 可以自动根据这些信号交易吗？
不建议。至少在这个系列里，OpenClaw 的定位是信息整理、证据库建设、事实核查和复盘辅助，不接自动实盘交易权限。
12. 风险边界：这套方法解决什么，不解决什么
数据源分层能解决的是：
-
● 减少把传言当事实； -
● 减少把热度当结论； -
● 减少把 AI 摘要当原文； -
● 让后续回测和复盘有证据链； -
● 让公开写作更安全、更可核查。
它不能解决的是：
-
● 预测市场一定怎么走； -
● 消除数据供应商口径差异； -
● 保证官方披露没有遗漏或后续变化； -
● 替代人工判断和合规审查； -
● 把未核验信息变成可交易信号。
这也是我反复强调“不荐股”的原因。
OpenClaw 在这里不是股神，而是一个纪律更稳定的信息工程助理。
13. 总结：先问“证据等级”，再问“它说明什么”
如果只能记住一句话，我希望是：
在 AI 量化信息工程里，先问数据源的证据等级，再问这条信息说明什么。
官方公告、行情资金、媒体新闻、热搜线索、小作文，不应该被塞进同一个“新闻”抽屉。
一个更安全的 OpenClaw 工作流，应该先给每条信息标注 source_type、verification_status、source_reliability，再决定它能进入事实库、线索库、注意力库、回测特征库，还是只能进入人工复核队列。
给自己的系统三个行动建议：
-
从今天开始，不要只存 AI 摘要，必须保留原文、链接和时间戳； -
给每条信息加上来源类型和核验状态； -
对热搜、小作文、截图类信息设置硬限制：未核验不得写成事实。
你现在的信息流里，最容易被 AI 误当成事实的是哪一类来源？欢迎拿这个问题反查一次自己的数据管道。
本文是 AI 量化信息工程与证据库建设记录，所有标的、主题和数据仅用于说明信息收集、标签归类、事实核查和复盘方法，不构成任何投资建议。市场有风险，投资决策需基于公开披露、独立研究和个人风险承受能力。
后续我会继续精读 RAG、搜索、Agent 与大模型工程化相关论文/框架。如果你关心“论文里的方法到底怎么落到工程系统里”，欢迎关注 Alten观AI，也欢迎在评论区聊聊你遇到过的 RAG 难题。