框架的设计与管理

1. 回顾

在 00-opframework.md 中，框架被定义为：

识别一个问题域中存在哪些维度和自由度。哪些维度需要测量（可能是外部决定的、不可商量的），哪些自由度可以调整（取决于组织的权力半径和可游说的相关方）。

框架不定义什么是好的。它只做映射——把问题域展开成一组可观测的坐标轴和一组可操作的杠杆。

本文讨论框架的两种形态、设计原则和治理方式。

2. 框架的两种形态

框架有两种根本不同的使用场景，对应不同的存在形态和设计约束。

2.1 叙事框架

叙事框架存在于模板中。它规定一份文档、一份报告、一个仪表盘的信息架构：有哪些章节、什么顺序、每个位置放什么类型的信息、读者应该以什么路径穿过这些信息。

叙事框架的回答对象是人。它的输出是一份可供阅读、浏览、汇报的产物。设计叙事框架时，核心问题是：目标读者需要先知道什么、后知道什么，才能用最少的心智成本理解整件事。

示例：

• 周报模板：概览（一句话结论）→ 核心指标（3-5 个）→ 重点项目进展 → 风险与阻塞 → 下周计划
• 活动方案模板：背景与目标 → 目标用户 → 核心玩法 → 资源需求 → 时间线 → 风险评估
• A/B 实验报告模板：实验假设 → 实验设计（分组、样本量、时长）→ 结果（主要指标 + 置信区间）→ 结论与建议

叙事框架的自由度体现在信息的选择和排序。同一组事实，按不同叙事框架组织，读者得到的理解和行动冲动完全不同。先展示升还是先展示降，是"回落至正常区间"还是"较去年同期下降 15%"，都是叙事框架在起作用。

叙事框架与 00 文档中的设计资产密切协作——叙事框架定义"哪些信息以什么结构出现"，设计定义"这些信息以什么形态被人感知"。

2.2 数据框架

数据框架存在于 schema 中——Pydantic 模型、数据库 DDL、API 的请求/响应结构、Protobuf 定义。它规定数据的结构、类型、关系和约束。

数据框架的回答对象是机器（以及需要理解数据含义的人）。它的输出是一组数据实体及其关系的声明式定义。设计数据框架时，核心问题是：这个领域有哪些实体、它们之间如何关联、每个实体的哪些属性对业务是必要的。

示例：

• 用户增长数据框架：User(id, registered_at, channel, segment) → Event(user_id, type, timestamp, properties) → Metric(name, value, window, dimensions)
• 采购审批数据框架：PurchaseRequest(amount, department, vendor, items[]) → ApprovalNode(role, status, comment, timestamp) → PurchaseOrder(pr_id, approved_at, total)
• 本框架（三层架构本身就是一个数据框架）：Document(blocks[]) → Block(type, style, runs[] | rows[]) → Run(style, text, image, hyperlink)

数据框架的自由度体现在实体划分和关系建模。用户和事件是一对多还是多对多？审批流是状态机还是 DAG？维度的选择直接决定了后续所有分析、策略、设计的可能性空间。

2.3 两种框架的关系

数据框架                    叙事框架
  │                           │
  │  定义"存在什么"            │  定义"怎么讲"
  │  回答对象：机器            │  回答对象：人
  │  载体：schema / DDL        │  载体：模板 / 章节大纲
  │                           │
  └──────────┬────────────────┘
             │
       框架的两种投影
       同一组维度可以同时存在于两种框架中

同一个领域需要两种框架同时存在。用户增长的数据框架定义了 DAU、留存率、LTV 作为可查询的实体属性；用户增长的叙事框架定义了周报中这些指标以什么顺序、什么格式、配什么文字说明呈现给阅读者。它们共享同一组维度，但面向不同的消费者。

数据框架是叙事框架的上游约束——你不能在一个模板里展示一个 schema 里不存在的维度。但叙事框架也可以反向提出需求——"这个模板需要一个叫'风险等级'的字段，请加到数据框架里"。

3. 框架的设计原则

3.1 声明式而非过程式

框架描述存在什么，不描述先做什么后做什么。一张审批表有哪些字段——这是框架。审批要经过三级、每级必须在 24 小时内响应——这是策略，不是框架。

更根本地，声明式的核心主张是：用验收条件替代执行步骤，用令牌模型替代流程模型。 不说"在提交前必须先给 A 审核、再给 B 签字"，而是声明"提交操作执行时必须同时持有有效的 A 令牌和 B 令牌"。不规定收集顺序，不假设流程路径——令牌何时获取、以什么顺序获取，是执行者的自由度。系统只负责在执行时刻校验令牌的有效性，不通过则阻断。

SOP、流程图、操作手册都是过程式的，不在框架的管辖范围内。

3.2 维度优先于粒度

先确定测什么，再确定测多细。把 DAU 拆成新用户 DAU 和老用户 DAU 是有意义的维度分解；把 DAU 精确到小数点后 8 位是粒度假象。框架设计中最常见的错误是在关键维度缺失的情况下过度细化已有维度。

3.3 稳定优先于完整

一个维度只要被纳入框架，就会触发数据采集、策略定义、设计呈现这一整条链路。删除一个维度的成本远超新增一个维度的成本。因此：宁可少纳维度，确保纳进来的每个维度都经得起长期检验。

3.4 术语一义性

框架中的每个术语在框架内必须有且仅有一个含义。"用户"在同一个框架内不能既指"注册用户"又指"活跃用户"又指"付费用户"——如果这些是不同的实体，给它们不同的名字。术语的一义性是跨组织对话的前提。

4. 框架的治理

（回顾 00 文档 5.6.1 节）框架变化速度慢，应使用代码仓库管理，分叉优先，保守演进。

4.1 版本控制

框架文件（无论是 YAML schema、JSON Schema、Pydantic 模型定义还是模板文件）应进入版本控制。每个版本变更有 changelog，说明增删了哪个维度、为什么。

数据框架天然适合代码仓库——schema 文件本身就是代码。叙事框架的模板文件（docx 模板、Markdown 模板）也应入库，尽管 diff 不那么可读——可借助 AtomDoc 将其拆分为 content.yaml 后比较。

4.2 分叉优先于直接修改

当一个业务线需要不同的维度集时，不要直接修改主干框架去妥协。从主干分叉，在分叉上做加法。主干保持最广泛的兼容性。

分叉与组织结构对齐：一个部门一个分叉，一个业务线一个分叉。分叉之间定期向主干合并经过验证的、通用的维度——类似开源项目的 upstream-first 策略，但方向是子→主。

4.3 跨越组织边界

当框架影响供应商、客户、行业标准时，它就不再是内部资产——它是协作协议。

这要求：

• 术语选择更加保守，避免组织内部的简称和黑话
• 维度变更需要更长的通知期和更明确的迁移路径
• 考虑发布"稳定版"框架和"实验版"框架，让外部合作方可以选择锁定稳定版

4.4 谁可以修改框架

框架的修改权限应与其影响范围成正比。一个只影响单个团队的叙事框架（如团队周报模板），团队自己改。一个影响跨部门数据交换的数据框架（如用户画像 schema），需要相关方代表共同审批。一个影响行业标准的框架（如披露规范），需要行业共识。

这不是技术问题，是治理问题。但技术可以提供护栏：代码仓库的 OWNERS 文件、CI 中的兼容性检查、变更的自动影响分析。

5. 框架与另外三类资产的关系

• 框架 → 策略：框架定义维度，策略在维度上定义 AC。框架不声明一个维度，策略就无法约束它。
• 框架 → 事实：框架决定采集哪些事实。事实的缺失往往不是因为不存在，而是因为框架没有给它一个维度位置。
• 框架 → 设计：框架向设计提供"可展示什么"的清单。设计不能展示框架中不存在的维度，但可以选择不展示某些维度（简化视图）。

框架是四类资产中最上游的——它的选择决定了策略的边界、事实的可见性、设计的可用素材。