事实的设计与管理

1. 回顾

在 00-opframework.md 中，事实被定义为：

记录已经发生的事情。数据、指标、实验结果、会议决策、用户反馈原文——回答"发生了什么 / 现状是什么"。

事实是四类资产中唯一不可以被"优化"的——它只能被采集或被忽略。你可以优化采集方式（更快、更准、更全），但你不能优化事实本身。

本文讨论事实的多速制管理、采集偏差、溯源和存储策略。

2. 事实的四速制

事实的变化速率跨度极大，从毫秒级到年级。不存在单一的管理方式——不同速度的事实需要不同的采集频率、存储介质和消费模式。

| 速率 | 变化频率 | 示例 | 存储 | 消费者 | |------|----------|------|------|--------| | 实时 | 毫秒~秒 | 汇率、订单、库存水位、现金流 | 数据库 / 消息队列 | 机器（聚合、告警、自动化） | | 高频 | 小时~天 | 相关方态度、会议决策、市场情绪 | 笔记 / CRM / 消息记录 | 人 + Agent | | 中频 | 周~月 | 行业价格、交期、政策变化、供应商报价 | 数据库 / 配置文件 | 人（定期审视） | | 低频 | 季~年 | 企业战略调整、行业范式变化、法规修订 | 代码仓库 / 结构化文档 | 人（决策输入） |

四速制按变化速率切分事实。与之正交的另一个维度是按生成角色：

| 角色 | 特征 | 维护方式 | 示例 | |------|------|----------|------| | 驱动数据 | 每个项目/实例不同，必须逐次采集或填写 | 手工填入或 API 拉取 | 本周 DAU、本次活动预算、当前库存水位 | | 参考数据 | 跨实例复用，变化相对较慢 | 集中维护，由团队或职能部门管理 | 人员清单、资质库、人员证书、公司业绩 |

两个维度互补，不互斥：一条参考数据可以是中频的（如供应商报价），也可以是低频的（如公司资质）；一条驱动数据可以是实时的（如当前在线数），也可以是高频的（如本周 DAU）。关键差异在于治理——参考数据的错误会污染所有消费它的实例，因此它的新鲜度管理和来源标注比驱动数据更为关键。

2.1 实时事实

实时事实的变化速度远超人类可以理解的频率。人无法逐条阅读订单流或汇率跳动——只能通过聚合、告警、自动化规则来响应。

这类事实的管理重点不是"记录"（记录是自动的），而是降采样策略——从连续的实时流中提取什么粒度、什么窗口的聚合值作为"有意义的事实"进入中频层。

2.2 高频事实

高频事实的变化速度大致与人类认知带宽对齐。一次观测可以在相当长时间段内保持稳定。一次会议上的态度表态、一封邮件中的承诺、一通电话后的判断——这些事实不会每秒变化，但可能在下次互动时被更新。

这类事实的管理挑战是从非结构化载体中提取。相关方态度存在于对话语境中，不是数据库字段。会议决策存在于录音和笔记中，不是 API 响应。将高频事实从自然语言转化为可查询的结构化记录，是运营工作中最被低估的能力。

2.3 中频事实

中频事实按周或月变动，适合放在数据库或定期更新的配置文件中。这是最"舒适"的频率——足够稳定，不紧急，但也足够新鲜，不陈旧。

这类事实的管理重点是新鲜度标记——每一条中频事实都应携带"最后更新时间"和"下次应更新"的元数据。过期的中频事实比缺失的中频事实更危险——它看起来可用，但实际上是错的。

2.4 低频事实

低频事实以季度或年为周期变化，应进入代码仓库中的结构化文档。它与框架资产的边界模糊——一个行业规范的低频变化，既是一个事实（"新规要求披露 X"），也可能触发框架变更（在维度集中增加"X 披露状态"）。

2.5 同一事实的多速投影

同一个事实概念，在不同时间尺度上属于不同类别：

DAU：实时（当前在线数）、高频（今日 DAU）、中频（本周日均 DAU）、低频（年度 DAU 趋势）
供应商状态：实时（当前 API 可用性）、高频（本周响应延迟）、中频（季度 SLA 达标率）、低频（年度供应商评估）

管理系统的设计必须容纳这种多速并存——不是为每种速度建独立系统，而是为同一个事实的不同聚合窗口提供查询路径。

3. 采集偏差

事实是"被发现"的，不是"被制造"的。但采集行为本身会引入偏差。

3.1 框架决定的可见性偏差

框架决定了测量哪些维度——这同时决定了忽略哪些维度。你不测的东西不会出现在视野里。这不是技术问题，是认识论问题：框架的选择就是注意力的分配，注意力决定了什么事实能被采集到。

这种偏差无法消除（采集必然有选择），但可以被意识到。当一个事实反复出现意外模式时，问自己：是不是框架漏掉了解释这个模式的维度？

3.2 采集工具的格式偏差

"DAU 下降了 15%"和"用户在小红书上抱怨我们的登录流程"都是事实。但前者有数值、有数据库、有看板自动监控，后者分散在数十条帖子里，取决于是否有人主动搜索和阅读。

工具和渠道的结构化程度决定了哪些事实更有可能被采集。数值型、数据库中的事实更"可见"；文本型、分散在非结构化渠道中的事实更"不可见"。承认这种偏差比假装客观更诚实。

3.3 频率错配

用实时采集工具采集低频事实是浪费；用人工笔记采集实时事实是妄想。频率错配是最常见的采集失败模式——工具选对了，但粒度对不上。

4. 溯源与不可篡改

4.1 来源标注

每条事实应携带来源信息：谁采集的、什么时候、通过什么渠道、原始载体是什么。这使得事实可以被回溯和验证。

来源标注不需要复杂系统——一行注释、一个 metadata 字段、一个命名约定。但没有来源的事实是不可验证的，不可验证的事实和不存在的区别只在运气。

4.2 事实不应被覆盖

事实是历史的记录。它不应该被"修正"——如果你发现一个历史事实是错的，追加一条修正记录，而不是覆盖原始值。

覆盖原始事实会消除修正行为本身的痕迹。三个月后有人分析这条事实时，无法区分"这是采集时就正确的值"和"这是后来改了三次的值"。

5. 事实的存储策略

事实不需要一个统一的存储系统。不同速度的事实适合不同的载体——关键是让消费方能按需查询，而非强制统一。

实时：时序数据库、消息队列日志
高频：CRM、飞书聊天记录、Notion/飞书文档
中频：关系型数据库、定期更新的 YAML/JSON 配置文件
低频：Git 仓库中的 Markdown 文档、结构化 YAML

不同存储之间不需要实时同步。但需要查询路径：当一个人需要回答"上周的 DAU 是多少"或"上次和这个供应商谈的价格是多少"时，他知道去哪里找，不需要遍历四个系统。

6. 事实与另外三类资产的关系

框架 → 事实：框架决定了采集哪些事实。事实的缺失往往不是因为不存在，而是因为框架没有给它一个维度位置。这是事实和框架之间最深的耦合。
策略 → 事实：策略消费事实作为判定上下文（回顾 02 文档第 4 节——策略锚定事实）。策略定义了"对"的边界，事实对照边界被判定为合规或偏离。
事实 → 策略：事实持续偏离策略阈值且执行端无明显问题时，说明阈值本身不当——触发策略校准。
事实 → 框架：事实暴露框架盲区——一个未被纳入维度的变量解释了大部分方差，一个被认为是自由度的杠杆实际上被冻结——触发框架修正。
设计 → 事实：设计决定事实如何被呈现给人。同一条事实，"下降 15%"和"回落至正常区间"是完全不同的感知结果。但设计不改变事实本身。