策略的设计与管理

1. 回顾

在 00-opframework.md 中，策略被定义为：

定义什么是正确的、什么是风险可接受的。包括多层级的不变式（invariant）和风险阈值。回答"什么样的结果可以通过"。

策略管的是验收条件（Acceptance Criteria）。它不决定怎么做——只声明什么算合格。

本文讨论策略的四层形态、自动化迁移方向、运行时锚定和治理机制。

2. 策略的四层形态

策略从完全自动化的机器规则到完全依赖人判的决策节点，分布在四个层次上。

                        HITL 节点
                       (人做决策)
                           ↑
                     结构化评估项
                   (人/Agent 按规则判定)
                           ↑
                      Assertion
                   (pytest, 测试时)
                           ↑
                      Validator
                  (Pydantic, 入库时)

从上到下，自动化程度递增、执行成本递减、判定确定性递增。策略工程化的核心方向是向下迁移——让今天需要人判断的规则，明天变成机器可执行的断言。

2.1 Validator —— 字段级与对象级的自动校验

Validator 是嵌入数据模型的自洽性检查，在数据入库或流转时自动触发。它是最稳固的策略层——不需要上下文，不需要外部数据，纯粹的声明式约束。

存在形式：Pydantic @field_validator / @model_validator、数据库 CHECK 约束、JSON Schema allOf/if-then。

覆盖的不变式（回顾 00 文档 5.2 节）：

| 粒度 | Validator 示例 | | ------ | ------------------------------------------------------ | | 字段级 | DAU >= 0、email 匹配正则、status 在枚举值中 | | 对象级 | start_date < end_date、budget >= spent + committed | | 子图级 | 审批流中所有节点的 approver_id 属于同一个部门 |

特征：确定性（相同输入必定相同输出）、无副作用（不访问外部系统）、零延迟（数据写入时同步执行）。

2.2 Assertion —— 测试时的行为校验

Assertion 是写入测试代码的不变式，在 CI/CD 管道中执行。它与 Validator 的核心区别在于：Assertion 可以访问外部资源（数据库、API、文件系统），可以在测试 fixture 的上下文中运行，可以表达跨时间、跨系统的复杂条件。

存在形式：pytest 断言、great_expectations 数据质量检查、自定义 CI 检查脚本。

Validator 做不到而 Assertion 能做到的事：

• 从数据库读取过去 7 天的 DAU 做环比检查
• 验证生成的 docx 文件页数与预期一致
• 调用外部 API 校验供应商状态的实时有效性

特征：有 setup/teardown 成本、运行在 CI 环境中、可以访问 fixture 和外部系统、失败时阻断流水线。

2.3 结构化评估项 —— 自然语言描述的判定规则

结构化评估项是用自然语言写成的、有明确判定标准的检查点。它可能由人执行（评审者逐项检查），也可能由 Agent 执行（LLM 读取规则后判定通过/不通过并给出理由）。

结构化评估项不是一句"请评估质量"——它必须有明确的维度、每个维度的通过标准、以及判定结果的格式要求。它介于机器可执行的断言和完全自由裁量的人判之间。

存在形式：评审 checklist、验收条件列表、Agent prompt 中的结构化判定规则。

示例：

## 活动方案评审项

### A. 目标可衡量性

- [ ] 目标包含数值指标（DAU / 转化率 / 收入）
- [ ] 目标有明确的时间窗口
- [ ] 目标与公司级 OKR 的映射关系有说明

### B. 风险覆盖

- [ ] 至少列出 3 个风险点
- [ ] 每个风险有应对措施（规避 / 缓解 / 接受）
- [ ] 最高影响的风险有预案

特征：人/Agent 可执行、判定标准明确但允许解释空间、执行结果可记录和审计。

2.4 HITL 节点 —— 人类决策的最终关口

HITL（Human-in-the-Loop）节点是策略体系中最上层、最昂贵的决策点。当一个决策满足以下任一条件时，它不应被自动化：

• 信息不完备（需要人通过非结构化渠道补充）
• 后果不可逆（上线、付款、合同签署）
• 需要承担后果（回顾 00 文档第 1 节——这是战略的范畴，但运营流程中也有少量残留）

HITL 节点的设计目标不是消除它，而是明确它的边界——让人只做机器做不了的判断，让机器的判定结果作为人的输入。

存在形式：审批按钮、confirm 步骤、签字确认。

特征：最慢、最贵、最不可规模化。HITL 节点应该被持续审视——这个决策是否仍然需要人的判断？如果判定规则已经足够清晰，下沉到结构化评估或断言。

3. 向下迁移：自动化路径

策略四层的核心动态不是静态分工，而是向下迁移。一个今天在 HITL 层的决策，随着规则的明确化和数据的完备化，可以逐步下沉。

向下迁移的本质是将检测策略转化为预防策略：Validator 是预防——不符合约束的数据根本无法写入系统；Assertion 是检测——错误已发生但在合并前被拦截。全检替代抽检的前提不是增加检查点，而是将检查点逐层下沉，降低单次判定成本直至经济上可行——目标不是"更快发现错误"，而是"让错误不可能发生"。

HITL ──→ 结构化评估 ──→ Assertion ──→ Validator
  ↑                    ↑              ↑
  │  规则被明确为       │  判定逻辑    │  判定完全不
  │  可文本化的判定标准  │  可编码      │  依赖外部上下文

迁移节奏不是均匀的。字段级 Validator 最容易到达——大多数数据类型和范围约束可以在设计阶段直接写入模型。子图级 Validator 和跨系统的 Assertion 需要更多积累——你需要先见过足够多的失败案例，才能把"什么是不对的"写成规则。

结构化评估是转换枢纽。当你发现同一个结构化评估项被执行了 10 次，每次都得出相同的判定逻辑时，问自己：这个判定逻辑能不能用代码表达？如果能，编写断言或 validator，把结构化评估项从 checklist 中删除。

4. 策略锚定事实

策略不是悬空的——它可以、也应该锚定事实。一条策略规则在评估时，不应只看待检查的对象本身，还应携带当时的运行时上下文。

4.1 动态数据绑定

策略执行时从实时数据源拉取上下文。CI 流水线中的 assertion 在运行前查询数据库，获取过去 7 天的 DAU 序列、当前的库存水位、供应商的最新报价——然后基于这些实时值执行判定。

# 策略锚定事实的示例
def test_dau_not_dropping():
    dau_today = db.query("SELECT dau FROM metrics WHERE date = today()")
    dau_7d_avg = db.query("SELECT avg(dau) FROM metrics WHERE date >= today() - 7")
    drop = (dau_7d_avg - dau_today) / dau_7d_avg
    assert drop < 0.15, f"DAU dropped {drop:.1%} vs 7d avg"

阈值是策略（15%），事实是动态的（实际 DAU 数值），二者在执行时结合。

4.2 执行结果存档

策略验证的执行结果应携带运行时信息后存档——不是只记录 pass/fail，而是记录完整的判定上下文：

• 策略规则 ID 和版本
• 执行时间
• 输入数据（待检查对象的快照）
• 运行时上下文（从外部系统读取的事实值）
• 判定结果（pass/fail/error）
• 失败时的诊断信息

这使得任何一次策略判定都可以在事后被审计：当时的规则是什么、当时的数据是什么、为什么通过或拒绝了。这对日落条款的重新评估至关重要——你不能在没有历史判定记录的情况下评估一条策略的实效。

5. 策略的治理

（回顾 00 文档 5.6.3 节）策略变化较快，必须有 owner、日落条款、可考核。

5.1 Owner 与设计意图

每条策略规则必须有一个明确的 owner。这不是"审批部门"——是写这条规则的人，理解当时为什么这样设定阈值的人。当规则触发异常、被质疑、或到达日落期需要重新评估时，owner 是对话的起点。

策略文件中应记录：

• 创建时间和创建者
• 最后修改时间和修改者
• 设计意图（一行文字说明这条规则保护什么、防止什么）

5.2 日落条款

每条策略在创建时必须声明一个重新评估日期或触发条件。到期时，owner 必须确认：这条策略的客观环境是否仍然成立？它免除的风险是否仍然大于它增加的摩擦？

没有日落条款的策略会无限累积——每次事故后新增一条规则，从没有人删除过期的规则。最终结果是策略总量单调递增，摩擦成本单调递增，而风险免除收益递减。

5.3 考核

策略应被量化评估：它在生命周期内实际避免了多少次风险事件？它在日常执行中增加了多少延迟、多少例外处理？

考核不需要精确到小数点——数量级足够。目标是识别明显失效率高的策略（阈值过于激进导致大量误报、或规则自身有逻辑漏洞）和明显收益为负的策略（阻止的风险近乎为零、但每个执行者每周都在绕行）。

5.4 四层策略的治理差异

| 层 | Owner | 日落 | 考核 | 变更触发 | | ---------- | -------------- | ------------------ | ------------------- | ------------------ | | Validator | 数据模型 owner | 随模型版本 | CI 中的误报率 | 字段变更、类型变更 | | Assertion | 测试用例 owner | 每个 release cycle | CI 中的 flaky rate | 业务逻辑变更 | | 结构化评估 | 流程 owner | 每季度 | 人/Agent 判定分歧率 | 流程变更、经验积累 | | HITL 节点 | 决策后果承担者 | 每半年 | 拒绝率、误放行率 | 规则成熟、可下沉时 |

5.5 联邦治理

不同领域归属的不变式由不同组织单元维护——这不是技术分工，而是治理分工：

• 领域不变式由领域专家、合规、风控按各自管辖范围分治。物理约束（金额 > 0）最稳定，几乎不需要日落；监管规则随法规变动，季度审视；风控阈值随业务环境变化，月度调优。
• 叙事不变式由客户经理或业务负责人把关。一条"周报必须包含风险板块"的规则，其合理性取决于受众的预期——受众换了，规则就该重新评估。
• 视觉不变式由品牌/设计团队集中维护，变化最慢。色板和字体层级的变更通常是年度甚至多年的事件。

联邦治理的核心原则：谁承担一条不变式被违反的后果，谁拥有这条不变式的定义权。 跨领域的不变式冲突（如合规要求披露某数据 vs. 设计原则要求简化视图）不应由执行者裁决——应在不变式定义层协商解决，执行者只需面对一致的、无冲突的约束集。

6. 策略与另外三类资产的关系

• 框架 → 策略：策略只能在框架声明的维度上定义约束。框架不提供维度，策略就无法操作。
• 策略 → 事实：策略定义了"对"的边界；事实一旦产出，对照策略判定合规或偏离。策略也直接消费事实——执行时从数据库拉取实时数据作为判定上下文。
• 策略 → 设计：策略不直接约束设计。但策略的判定结果（通过/不通过/风险等级）是设计需要呈现的信息——设计需要回答"如何让读者一眼看到哪些策略被触发、哪些在告警"。