运营工作的框架

1. 定义：排除法

定义运营的一种方式是从组织中排他。排除研发、产品、设计之后，剩下的是运营——但这还不够精确。更严格地，排除以下七类工作之后，剩余的部分即为运营：

| 维度 | 排除 | 特征 | 运营的特征（对立面） | | ---- | -------- | ---------------------------------------- | -------------------------------- | | 建造 | 研发 | 将需求转化为可运行系统 | 使用已有系统完成工作 | | 定义 | 产品 | 决定做什么、优先级 | 在已决定的范围内执行 | | 表达 | 设计 | 决定信息的感官形态 | 按照既定规范组织信息 | | 决策 | 战略 | 不完备信息下做出判断并承担后果 | 完备信息下按照既定逻辑执行 | | 影响 | 销售 | 改变他人意图以服务于组织利益 | 不改变他人意图，只传递信息 | | 对抗 | 博弈 | 最优策略取决于对手行为，不能拟合静态标准 | 环境稳定，标准固定，无策略性对手 | | 探索 | 创新 | 通过未被广泛使用的策略优化业务结果 | 使用已验证的、标准化的方法 |

七类排除中，前三个是传统分工（研发 / 产品 / 设计），后四个是认知性质的区分：

战略排除在外，是因为它的核心动作——在信息不完备时做出判断并承担后果——不可工程化。一旦信息完备、逻辑既定，工作就退化为执行，即落入运营范畴。
销售排除在外，是因为它涉及对他人的意图干预——这需要临场判断、人际感知和实时策略调整，本质上不可模板化。
博弈排除在外（风控、内控、审计），是因为博弈环境中最优解取决于对手行为，不存在独立于对手的"正确标准"。无法收敛到静态规则的工作，不可管道化。
创新排除在外（艺术创作、产品创新），是因为它依赖未被验证的策略。一旦某种策略被验证有效并稳定复用，它就不再是创新，而已沉淀为运营方法。

综上，运营是可以工程化的信息工作：环境稳定、标准固定、方法已知、信息完备。运营人员的工作方式是：接收需求、处理信息、产出交付物。广义上，任何岗位都包含运营成分——产品经理写 PRD、工程师写方案、设计师做评审记录——因为这些动作本身满足上述四个条件。

本框架讨论的是运营的方法论：如何将这部分工作从人的判断变成可复用的系统。

工作分类提示：在应用本框架之前，建议先判断任务属于哪种模式。OpStack 的排除法定义可以与一个更前置的三分类模型配合使用——将工作分为运营（低偏差，系统把关）、创作（高偏差，人类把关）、工程（中偏差，人机共创）。详见 07 — 运营、创新与工程。

2. 三层架构

运营工作可以分解为三层：产物、内容、数据。

产物  ── 最终交付物（文档、报表、看板、邮件、PPT）
  │
内容  ── 产物的实质性信息（文字、数据表、图表、指标）
  │
数据  ── 原子化的事实碎片（数字、事实、记录、事件）

2.1 产物层

产物是运营工作的对外界面。它回答的问题是：我交付了什么？

一份周报、一个活动方案、一张数据看板、一封通知邮件——这些是产物。产物的评价标准是接收方的体验：是否清晰、是否完整、是否在规定时间内到达、是否引发了正确的下一步行动。

2.2 内容层

内容是产物的实质性信息，剥离了视觉表现后的"干货"。它回答的问题是：我说了什么？

内容层的独立性是框架的核心假设。同一份内容可以表现为 Word 文档、PPT 幻灯片、飞书消息、邮件正文——载体不同，信息相同。将内容从样式中分离，是自动化铺开的先决条件。

2.3 数据层

数据是内容层的原材料，未经加工的事实。它回答的问题是：我基于什么得出这个内容？

数据层包括数值指标、用户反馈原文、实验结果、会议录音转写、制度条款原文——一切在进入内容层之前尚未被组织、解释、筛选的原始信息。

2.4 层间关系

三层之间是单向依赖：数据支撑内容，内容组成产物。下层不需要知道上层的存在：

同一组数据，可以生成不同视角的内容（乐观版、保守版、不同受众版）
同一份内容，可以输出为不同格式的产物（Word 用于审批、PPT 用于汇报、消息用于同步）
内容的修改不应反向污染数据源
产物的格式变更不应导致内容重写

3. 核心公式

产物 = 内容 + 样式

样式是内容的呈现方式：字体、字号、颜色、布局、页边距——以及更广义的"格式"：是段落还是列表，是表格还是图表，是 PPT 的哪一页模板。

这个公式的工程意义在于：样式和内容可以独立修改。给同一份活动方案套用不同的 PPT 模板，内容不变，产物就变了。这意味着运营工作中大量"排版""调格式""美化"的劳动，本质上是样式层的操作，不应与内容生产耦合。

样式还包括语境适配：同一个数据解读，给 CEO 看和给执行团队看，内容的深度和粒度不同——这不是样式问题而是内容变体问题，但在框架中可以建模为"同一数据源 → 不同内容模板 → 不同样式 → 不同产物"的派生链。

内容 = 模板 + 数据

模板是内容的结构骨架：周报的固定板块、活动方案的章节大纲、数据看板的指标排列顺序。模板捕获的是可重复的模式。

数据是填充进模板的具体值：本周的 DAU 数值、活动预算金额、用户反馈的原文引用。数据捕获的是本次实例的特征。

这个公式的工程意义在于：模板沉淀经验，数据驱动实例。一旦模板被明文化，生成一份新周报就只需填入本周数据，不必每次重新构思结构。运营工作中大量"写周报""写方案""做汇总"的时间消耗，都可以通过模板 + 数据管道的方式消除。

4. 运营工作的本质

基于以上框架，运营工作的核心动作可以归纳为三类：

| 动作 | 描述 | 对应层 | | -------- | ------------------------------------------------ | ------ | | 采集 | 从环境中获取原始数据（查询、抓取、询问、观察） | 数据层 | | 加工 | 将数据组织为结构化内容（分析、归纳、筛选、解释） | 内容层 | | 呈现 | 将内容按照指定样式输出为产物（排版、渲染、分发） | 产物层 |

一个运营人员的专业水平，不在于单项动作的执行速度，而在于：

采集的完整性——是否遗漏了关键数据源
加工的判断力——是否能从数据中识别信号而非噪声
呈现的适配性——是否能根据受众和场景选择正确的样式

以及，更高阶的能力：

模板化——是否能把重复性内容结构抽象为模板，使下次同类工作降为数据填入
管道化——是否能把采集→加工→呈现串联为自动化流程
分层意识——是否能意识到自己当前工作在哪个层，不把层间责任混淆

5. 四类知识资产

第 2–4 节描述的是文档工程——如何将运营工作的产物分解为可独立演化的三层，通过模板与数据的分离实现自动化生产。它回答"怎么把东西做出来、做对"。

本节描述的是知识工程——一个组织在运营中积累的知识（什么是对的、什么是风险可接受的、发生过什么、如何让人理解）本身需要工程化管理。这些知识不是一次性的产物，而是持续演化的资产：被定义、被版本化、被自动执行、被考核、被日落。

二者叠加，加上组织文化，构成运营工业化的完整公式：

运营工业化 = 文档工程 + 知识工程 + 诚实文化

前两项是工程问题，本框架提供方法论和工具链。第三项是领导和治理问题，本框架不解决——但本框架假设它存在。没有诚实文化，事实会被"优化"，策略会被绕过，owner 会缺席，日落不会被执行。工程决定了能力的上限，文化决定了工程的下限能不能被守住。

运营工作中产生的知识资产可分为四类，按从抽象到具体的依赖关系排列。同一份文档可能同时包含多类资产，但拆解后各有归属。

5.1 框架（Framework）

定义：识别一个问题域中存在哪些维度和自由度。哪些维度需要测量（可能是外部决定的、不可商量的），哪些自由度可以调整（取决于组织的权力半径和可游说的相关方）。回答"我们在一个什么样的空间里操作"。

特征：框架不定义什么是好的、什么是正确的。它只做映射——把问题域展开成一组可观测的坐标轴和一组可操作的杠杆。维度的选择决定了你看得见什么（也决定了你会忽略什么），自由度的识别决定了你能动什么（也决定了你接受了哪些动不了的东西）。

示例：

用户增长框架：维度 = {DAU, 留存率, LTV, CAC}，自由度 = {渠道预算分配, 投放素材, 落地页文案, 推送频次}
本框架（三层架构）：维度 = {交付物格式, 信息结构, 原始数据}，自由度 = {模板设计, 样式选择, 数据源切换}
审批规则框架：维度 = {金额, 部门, 合同类型, 供应商评级}，自由度 = {谁审批, 几级审批, 会签还是或签}

5.2 策略（Tactic）

定义：定义什么是正确的、什么是风险可接受的。回答"什么样的结果可以通过"。

特征：策略是验收条件（Acceptance Criteria）的总称——它不决定怎么做，只声明什么算合格。不变式（invariant）是策略中已被充分形式化、可以做出二值判定（通过/不通过）的子集。尚未形式化的策略以结构化评估项或 HITL 判断的形式存在，随着规则的明确化逐步向不变式转化。

不变式按两个正交维度分类。第一维是按粒度——从简单到复杂：

| 粒度 | 描述 | 示例 | | ---------- | -------------------------------------- | -------------------------------------------------------------------- | | 字段级 | 单个属性的自洽约束 | DAU > 0、金额 ≠ NaN、日期格式 YYYY-MM-DD | | 对象级 | 同一对象内跨字段的自洽约束 | 开始日期 < 结束日期、预算 ≥ 已支出 + 待支付 | | 子图级 | 跨对象的关联约束（依赖图中的局部闭包） | 发布上线 && 监控就绪 && 回滚脚本准备完毕、所有审批节点均为"通过" |

第二维是按领域归属——谁负责定义和维护这条约束：

| 领域 | 约束范围 | 维护者 | 示例 | | -------------- | ------------------------------ | ------------------------ | ------------------------------------ | | 领域不变式 | 业务问题域本身的固有规则 | 领域专家、合规、风控 | 预算 ≥ 已支出、监管阈值、行业逻辑 | | 叙事不变式 | 信息架构的完整性与受众适配性 | 客户经理、业务负责人 | 周报必含风险板块、高管摘要不超过一页 | | 视觉不变式 | 产物的感官形态与品牌一致性 | 品牌团队、设计团队 | 色板、字体层级、信息密度上限 |

领域归属与粒度是正交的：一条领域不变式可以是字段级的（金额 > 0），也可以是子图级的（审批流中所有节点通过）；一条视觉不变式同样可以是字段级的（颜色值在色板中）或对象级的（标题字号 > 正文字号）。

此外，策略还定义风险阈值——特定时间窗口内、特定维度上的可接受范围：周环比降幅不超过 15%、P99 延迟不超过 200ms、单个渠道预算占比不超过 60%。风险阈值与不变式的区别在于：阈值被触发不意味着逻辑矛盾，只意味着需要关注。

策略与第 1 节排除的战略不同：战略自行定义目标和边界（在信息不完备时做出判断并承担后果）；策略在框架已划定的空间内声明验收条件，不做判断，只定义什么是"对"的。

5.3 设计（Design）

定义：让产物被人理解。最终用户或相关方——任何一个需要消费这个产物的人——能够看懂、找到他们关心的信息、做出下一步判断。回答"人看到的是什么"。

特征：设计只负责可理解性。不对正确性负责（那是策略的责任），不对数据真实性负责（那是事实的责任）。一段文字放在哪里、一个指标用什么图表、一组信息按什么顺序展开——都是设计决策，衡量标准只有一条：目标读者是否能用最少的心智成本获取他们需要的信息。

示例：周报的板块顺序（先结论后数据还是先数据后结论）、看板的布局（关键指标放最上面还是最左边）、表格的列序（用户最常筛选的列放前面）、文案的措辞（"下降 15%"还是"回落至正常区间"）。

5.4 事实（Fact）

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

特征：描述性的、可验证的、真值独立于观察者。事实是四类资产中唯一不可以被"优化"的——它只能被采集或被忽略。

示例：DAU 日报、A/B 实验结果、用户访谈录音转写、项目里程碑完成日期、审批流转记录。

5.5 四类资产的关系

框架、策略、事实三者构成一个闭合的互动循环。设计不在此循环中——它是正交的呈现层。

          ┌── 框架 ──→ 策略 ──┐
          │    ↑         ↓     │
          │    │         │     │
          │    │    定义AC于    │
          │    │    已知维度    │
          │    │               │
          │    │               ↓
          │    └──── 事实 ←────┘
          │               │
          │         对照AC判定
          │         通过/偏离
          │               │
          └──── 暴露盲区 ──┘
             (漏掉的维度、冻结的自由度、消失的相关性)

        设计  ←── 正交层：任何需要被人看的东西

三角互动：

框架 → 策略：策略只能在框架已识别的维度上定义验收条件。框架不声明维度，策略就没有可操作的坐标轴。
策略 → 事实：策略定义了"通过"的边界。事实一旦产出，对照策略判定偏离或合规。
事实 → 策略：事实持续偏离策略阈值，且执行端无明显问题时，说明阈值本身设置不当——策略需要校准。
事实 → 框架：事实可能暴露框架的盲区。一个从未被纳入维度的变量解释了大部分方差，一个被认为是自由度的杠杆实际上冻结了——这些信号触发框架修正。
框架 → 事实：框架决定了采集什么事实。你不测的东西不会出现在视野里，框架的维度选择就是注意力分配。

设计不在链中：

设计不参与上述循环。它不是"框架/策略/事实"序列中的一站，而是一个正交维度——任何需要被人消费的资产都可能需要设计。一份框架文档需要设计（让相关方理解维度的含义），一份策略规格需要设计（让执行者看懂 AC），一份事实报告需要设计（让数据可读）。设计只对可理解性负责，不对正确性负责。

5.6 资产的变化速率与治理

四类资产的变化速率差异极大，不能用同一种方式管理。

| 资产 | 变化速率 | 治理模式 | |------|----------|----------| | 框架 | 慢 | 代码仓库 + 分叉 + 保守演进 | | 事实 | 实时到低频 | 四速制：数据库(实时) / 笔记(高频) / 配置文件(中频) / 仓库(低频) | | 策略 | 快 | 明确 owner + 日落条款 + 可考核 | | 设计 | 快且碎 | 原则统一 + 资产共享 + 其余放权 |

5.6.1 框架——慢速，保守演进

框架的变化速度相对较慢。一个行业的分析维度、一个组织的权力半径在数月甚至数年内保持稳定。这决定了框架可以（也应该）使用代码的管理方式：版本控制、变更审查、向后兼容。

当需要优化框架时，优先分叉而非直接修改。分叉最好能与组织结构对齐——一个业务线可以基于公司级框架派生自己的维度集，但主干保持兼容，确保跨组织对话时不会因为框架差异而无法沟通。

框架甚至需要超越单个组织的边界。当你的框架影响了供应商的交付标准、行业的披露规范，它就不再是一个内部工具——它是协作协议。这要求框架有足够的保守性：不轻易增删维度，不随意重新定义术语，确保多个组织之间可以互相对话而不需要每次都做概念映射。

5.6.2 事实——极宽频谱，多速制管理

事实的变化速率跨度极大，不存在单一的管理方式：

实时：汇率、订单、库存、现金流。变化速度远超人类可以理解的频率——人无法逐条阅读，只能通过聚合、告警、自动化规则来响应。持久化在数据库中，由机器消费。
高频：相关方态度、意图、市场情绪。一次会议、一封邮件就可能改变，但变化速度大致和人类认知带宽对齐——一次观测可以在相当长的时间段内保持稳定。管理方式可能是脑中的判断、PC 里的笔记，或轻量级的 CRM 记录。
中频：行业价格、交期、政策变化、供应商报价。按周或月变动，适合放在数据库或定期更新的配置文件中。
低频：企业战略调整、行业范式变化。以季度或年为周期，应进入代码仓库中的结构化文档。

同一个"事实"，在不同时间尺度上属于不同类别。DAU 是每天变化的数据点（中频），但"过去 12 个月的 DAU 趋势"是一个相对稳定的分析对象（低频）。管理系统的设计必须容纳这种多速并存——不是找一个统一存储，而是承认不同变化速度的事实需要不同的持久化策略。

5.6.3 策略——快速迭代，owner + 日落 + 考核

策略的变化速度较快。一端是相对稳定的——物理约束、行业规范、会计准则，这些可以持续数年；另一端是高速变化的——最佳实践、监管环境、内控规则，可能在季度甚至月度频率上调整。

策略的每条规则必须有明确的 owner：谁定义了这条 AC，当时的设计意图是什么。没有 owner 的策略是僵尸规则——它还在执行，但没人知道为什么，也没人敢删。

策略必须有日落条款：一条策略在被创建时，就应该声明它的预期生命周期和重新评估的触发条件。一个策略之所以存在，是因为它在某个时间点被判断为"免除的风险 > 增加的摩擦"。但这个不等式会随时间改变——风险降低、摩擦积累、环境变化。如果不强制重新评估，策略会无限囤积，最终摩擦总和超过收益。

策略甚至应该被考核：定期回顾一条策略在它的生命周期内实际避免了多少风险事件，以及它在日常执行中增加了多少延迟、多少例外处理、多少人的困惑。这个考核不需要精确——数量级足够。一条每年免除约 1 万元风险但每周消耗 10 个人各 5 分钟的审批策略，是值得商榷的。

5.6.4 设计——快且碎，原则统一 + 其余放权

设计的变化速度最快，碎片化程度最高。和行业惯例、公司架构、专业设计人才的规模都有关系——一家有 200 人设计团队的公司和一家没有专职设计师的公司，设计资产的管理方式截然不同。

设计已经摸到了艺术和工程的边界。试图在碎片化的日常设计决策上强加中央控制会失败——没人能审批每一份周报的配色和字体选择。

正确的策略是两层的：

原则层统一：品牌资产（logo、色板、字体）、设计原则（信息层级、可访问性标准）——这些变化慢，适合集中管理。
实现层共享：模板、组件、design token——提供一套默认即可用的资产，让非设计背景的人不需要从零做设计决策。
其余放权：每个人在模板和 token 的基础上自由调整，只要不违反品牌原则。

6. 框架与工具链的关系

本框架是 OpStack 的理论层。工具链（如 AtomDoc）是框架在特定问题域中的实现：

| 框架概念 | AtomDoc 实现 | | ------------------ | ------------------------------------------------- | | 产物 = 内容 + 样式 | content.yaml + style.yaml → .docx | | 内容 = 模板 + 数据 | 模板文档 + 数据填充（Agent 编辑 content.yaml） | | 样式独立修改 | 修改 style.yaml 不影响 content.yaml | | 模板沉淀 | patterns 命令识别重复格式 → 语义化命名 → 模板复用 | | 层间不耦合 | Passthrough 机制：只覆盖文本，XML 结构原样保留 |

OpStack 的目标不是写一个工具，而是建立一套运营工作的工程化方法论——让"流程"不再是口头约定或散落的文档，而是可执行、可验证、可复用的软件工件。