ITA：从流程驱动到判断驱动

ITA（Important-True-Acceptable）是一个面向运营自动化与业务流程重构的元方法论框架。它提出一个核心主张——任何运营任务都可以被解构为三个元问题的回答，并以此替代流程驱动范式。

---

1. 定义领域——OA 与 BPR

办公自动化（Office Automation）和业务流程重构（Business Process Reengineering）自诞生以来就是同一枚硬币的两面：OA 负责把现有流程搬上线，BPR 负责在搬上线之前重新设计流程。二者的共同前提是——流程是正确的分析单元。

这个前提统治了企业软件四十年。

从 1990 年代的 Lotus Notes 到 2020 年代的飞书审批，技术栈换了一轮又一轮，但底层范式从未改变：画流程图 → 配置审批节点 → 数据沿着流程图流动 → 人在节点上做判断。BPMN、工作流引擎、RPA、低代码/无代码审批流构建器——它们共享一个信仰：定义流程，然后执行流程。

这个信仰是错的。流程不是本质，流程是表象。

你填一张报销单不是因为存在一个"报销流程"，而是因为组织需要回答一个问题：这笔钱花得对不对？ 流程只是回答这个问题的众多可能方式之一。把流程当本质的后果是：我们优化了流程的流转效率，却从来没有系统性地定义过"对"意味着什么。

---

2. 现状——流程驱动的霸权与代价

当前 OA/BPR 领域的主导理论可以归结为三类，它们共享同一个根本缺陷：

BPMN / 工作流引擎（Camunda、Flowable、飞书审批） 核心假设：业务流程可以被建模为节点图，节点之间通过条件分支连接。 根本缺陷：流程图混淆了路由与判断。"谁来审批"是一个路由问题。"什么叫批了"是一个判断问题。BPMN 只回答第一个，然后把第二个外包给每个节点上的人——而每个人的判断标准从未被显式化。

RPA（UiPath、Automation Anywhere） 核心假设：人工操作可以被录制和回放。 根本缺陷：RPA 模拟的是人的操作，而不是人的判断。它让机器人点击按钮更快，但当表单字段变化、业务规则更新时，录制脚本变成技术债务。RPA 自动化的是操作，不是推理。

低代码审批流（飞书、钉钉、企业微信的 OA 模块） 核心假设：让业务人员自己拖拽出审批流程。 根本缺陷：门槛降低了，范式没变。一个业务人员拖出来的流程图和一个程序员写出来的流程图，犯的是同一个错误——它们都在定义"怎么流转"，而不是"什么叫合格"。

这三类解决方案的共同盲区是：它们认为运营工作的本质是信息的流动，而实际上是判断的传递。

当一个报销单经过"提交人 → 直属上级 → 财务 → 出纳"这一串节点时，真正发生的事情不是"数据在流动"，而是判断在逐层升级：

• 直属上级判断：这笔支出是否在业务上合理？
• 财务判断：是否符合公司财务制度和税法要求？
• 出纳判断：账户余额是否充足、收款信息是否准确？

流程驱动的范式把这些判断逻辑全部压进了"审批"这个黑箱里。每个节点上的人都在自己的大脑里运行一套从未被形式化的判断规则。这套规则通过"老员工带新员工""内部培训""踩过坑就知道了"的方式扩散——效率低下、不可测试、无法版本化。

---

3. AI Agent 进入后，为什么组织还是那么慢、那么笨

Agent 被寄予厚望。如果每个审批节点上的人可以被 Agent 替代，流程自动化不就完成了吗？

现实是，Agent 进入企业两年后，组织的运营效率没有结构性改善。原因不是 Agent 不够聪明，而是 Agent 被塞进了一个错误的架构里。

3.1 重复的事实被多次写入

同一条信息——一笔支出的金额、日期、供应商、预算科目——在报销单里填一次，在财务系统里录一次，在预算追踪表里再记一次。这些系统的数据模型彼此独立，Agent 的作用变成了"帮你在三个系统里自动填表"。问题的根源不是填表太慢，而是事实没有单一来源——数据模型（I）没有被统一定义，事实源（T）没有被声明和引用。

Agent 只是在三个孤岛之间搬运数据，搬运得再快，三个孤岛还是三个孤岛。

3.2 重复的判断依赖肉身执行

每个报销单都需要"直属上级审批"。直属上级面对每一笔报销，都在默默运行同一套判断逻辑：金额在预算内吗？供应商是合作过的吗？支出类别和项目阶段匹配吗？这些规则从未被形式化，它们活在直属上级的直觉里。

Agent 进入后的"改进"是这样的：Agent 帮忙起草审批意见，甚至自动通过"明显合规"的单子。但判断规则仍然没有被显式化——Agent 是在模仿人的判断输出，而不是执行一套可审计的判断逻辑。当审计来了、预算超了、供应商有问题了——谁负责？Agent 只是一个更快的审批者，不是一个更好的判断系统。

3.3 方法论依赖内部培训扩散

"我们公司怎么做费用管理"——这是一套存在于 PDF 文档、老员工大脑和入职 buddy 对话里的方法论。Agent 可以读 PDF、可以 fine-tune 在历史审批数据上，但它学到的是一个黑箱的统计近似，而不是一个可验证的判断标准。

3.4 为什么"小龙虾"Agent 没有动摇现状

小龙虾——看起来有壳、有钳子，姿态唬人，但肉少，且横向移动。

当前的 Agent 产品（无论是 Copilot 式的审批辅助还是 Autopilot 式的自动审批）共享一个特征：它们是流程兼容的，不是流程挑战的。 它们把自己插入现有的流程图里，让现有流程跑得更顺畅。但流程本身——它的数据冗余、它的判断黑箱、它的知识散落——从未被质疑。

Agent 当前被设计为流程中的一个新节点，而不是流程范式的替代方案。它就像给马车装了一个法拉利引擎——地基决定了天花板。

---

4. ITA——声明式、关注本质、不定义 Process

ITA 框架的根本重置是：不定义过程，定义 DoD——或者更准确地说，DoA（Definition of Accepted）。

任何运营任务 = I（重要，测什么）+ T（真，事实从哪来）+ A（可接受，什么叫合格）。

ITA 是声明式的。它不关心执行单元是人还是 Agent，不关心它在哪一步做了什么操作、用了什么工具、经历了多少次迭代——它只关心最终提交物是否满足三个维度的准入条件。

4.1 I：应当测量与追踪什么？

I 是数据模型。它定义了一个运营任务涉及哪些实体、每个实体有哪些字段、每个字段的类型和约束。

以报销为例：

ExpenseReport:
  - amount: Decimal(gt=0)
  - category: ExpenseCategory (enum)
  - date: Date (not in future, not before fiscal year start)
  - department: DepartmentCode
  - budget_line: BudgetLineId
  - vendor: VendorId
  - receipt: AttachmentHash
  - justification: MarkdownText (required if amount > 5000)

I 模型是稳定且可执行的。它不描述"报销的流程"，它声明"一份报销是什么"。这类似于领域驱动设计中的聚合根——I 模型是运营领域的聚合根。

4.2 T：状态转变的事实依据从何而来？

T 分两个子维度：

T₁——驱动事实：谁说了什么？操作者提交了什么？ → 来自表单、登记、上传。操作者的主张（"我花了 3000 元请客户吃饭"）。

T₂——参考事实：系统记录了什么？什么是不可自证的？ → 来自业务系统（SoR，System of Record）。预算余额来自财务系统，供应商状态来自采购系统，部门编码来自 HR 系统。

T 的核心原则是事实源声明：每一个字段的权威来源必须被显式声明。amount 是 T₁（操作者自述），budget_remaining 是 T₂（财务系统查询）。你不能用操作者自述的金额去验证操作者自述的金额——这是循环论证，但它恰好是大多数审批流程的实际做法。

4.3 A：变化被接受前须通过何种分层判断？

A 是 ITA 框架最核心的贡献。它将"审批"这个黑箱拆解为三层本质不同的判断：

| 层次 | 类型 | 特征 | 容错性 | 执行者 | |------|------|------|--------|--------| | Validate | 基于常识与物理规律的确定性规则 | 格式、类型、非空、数值范围、日期合法性 | 零容忍 | 系统自动 | | Verify | 与业务系统事实的比对 | 预算余额、供应商状态、合规规则 | 容忍系统噪声与规则过时 | 系统自动 + 异常降级人工 | | Review | 基于原则或评估标准的模糊判断 | 业务必要性、成本合理性、战略对齐 | 本质模糊，需人机协同 | Rubric 引导 + 人类兜底 |

这个分层的意义在于：每一层消耗的认知资源完全不同。 Validate 消耗计算资源（机器擅长）。Verify 消耗查询和比对资源（机器擅长，但需要人类处理系统噪声）。Review 消耗判断力和上下文理解（人类擅长，但需要 Rubric 引导以保持一致性）。

流程驱动范式把三层全部塞进"审批"一个动作里，让一个年薪百万的总监去检查发票金额有没有超过预算余额——这是对人类判断力的系统性浪费。

4.4 DoA：提交即判断

ITA 不定义 Process，它定义 DoA（Definition of Accepted）。执行单元——无论是一个人还是一个 Agent——的任务是：提交一个满足 I/T/A 全部准入条件的产物。

完整性的检查（I 模型所有必填字段是否填写？）→ CI 里的 Pydantic 校验。 正确性的检查（金额是否在预算内？供应商是否在准入名单里？）→ CI 里的 Pytest 测试套件。 合规性的检查（是否符合差旅政策？是否触发反贿赂规则？）→ CI 里的规则引擎。 业务主管的 LGTM → Review 层的一个审批 gate。 职能部门的 LGTM → Review 层的另一个审批 gate。

所有的 gates——系统的和人的——在 CI/CD 管道中被统一编排。 提交 = Push。审查 = CI 运行。批准 = Merge。

"流程"变成了 CI/CD 管道的执行顺序，而不是一张预先绘制的 flowchart。

---

5. ITA 怎么落地

ITA 不是一个哲学主张，它有一套直接的工程映射。

5.1 I → Pydantic Model

from pydantic import BaseModel, Field, validator
from enum import Enum
from datetime import date
from decimal import Decimal

class ExpenseCategory(str, Enum):
    TRAVEL = "travel"
    ENTERTAINMENT = "entertainment"
    OFFICE_SUPPLIES = "office_supplies"
    PROFESSIONAL_SERVICES = "professional_services"

class ExpenseReport(BaseModel):
    """I-model: an expense report is THIS."""
    amount: Decimal = Field(gt=0, description="支出金额")
    category: ExpenseCategory
    expense_date: date = Field(description="支出发生日期")
    department_code: str = Field(regex=r"^DEPT-\d{4}$")
    budget_line_id: str
    vendor_id: str
    receipt_hash: str = Field(description="附件哈希，指向云空间文件")
    justification: str | None = Field(
        default=None,
        description="金额>5000 时必填的业务理由"
    )

    @validator("justification")
    def justification_required_for_large_amount(cls, v, values):
        if values.get("amount", 0) > 5000 and not v:
            raise ValueError("金额超过 5000 时必须提供业务理由")
        return v

5.2 T → API Gateway / 配置文件

# fact-sources.yaml —— T 声明
facts:
  budget_remaining:
    source: finance-api.internal
    endpoint: /v1/budgets/{budget_line_id}/remaining
    method: GET
    cache_ttl: 300s
    fallback_on_error: escalate_to_review  # 财务系统挂了→升级到 Review

  vendor_status:
    source: procurement-api.internal
    endpoint: /v1/vendors/{vendor_id}/status
    method: GET
    cache_ttl: 3600s

  department_valid:
    source: hr-api.internal
    endpoint: /v1/departments/{department_code}/exists
    method: GET

T 层的工程要点：

• 每个事实源有明确的 API endpoint 或配置文件路径
• 每个事实源有容错策略（缓存、降级、升级）
• fallback_on_error 实现了"容忍系统噪声"——当 SoR 不可用时，不阻塞流程，但升级判断层级

5.3 A → Pytest + Rubric + CI/CD

Validate 层——Pydantic Validator，CI 自动运行：

def test_expense_report_validates(report: ExpenseReport):
    """此测试在任何 CI 环境中自动运行。"""
    # Pydantic 自身验证在模型实例化时触发
    # 自定义验证逻辑
    assert report.amount > 0
    assert report.expense_date <= date.today()
    assert report.expense_date >= date.today().replace(month=1, day=1)

Verify 层——Pytest + 事实源适配器：

def test_expense_within_budget(report: ExpenseReport, adapters):
    remaining = adapters.budget.get_remaining(report.budget_line_id)
    assert report.amount <= remaining, (
        f"超预算: 报销金额 {report.amount} > 预算余额 {remaining}"
    )

def test_vendor_approved(report: ExpenseReport, adapters):
    status = adapters.vendor.get_status(report.vendor_id)
    assert status == "approved", (
        f"供应商 {report.vendor_id} 不在准入名单中, 当前状态: {status}"
    )

def test_no_duplicate_receipt(report: ExpenseReport, adapters):
    existing = adapters.expenses.find_by_receipt_hash(report.receipt_hash)
    assert not existing, (
        f"附件已用于报销单 {existing[0].id}, 疑似重复报销"
    )

Review 层——Rubric + 人工 gate：

# 报销评审 Rubric

请从以下三个维度对报销进行评审，每个维度 1-5 分：

## 1. 业务必要性
- 5: 支出直接支撑当前季度的关键业务目标
- 3: 支出与业务相关但时机或对象可商榷
- 1: 支出与业务目标的关联不明确

## 2. 成本合理性
- 5: 价格显著低于市场均价，有明显的成本控制意识
- 3: 价格与市场均价持平
- 1: 价格明显高于市场均价，且无合理解释

## 3. 合规性
- Pass: 符合全部已知的合规要求
- Fail: 存在任何已知合规风险 → 触发合规审查子流程

总分 ≥ 8 且合规性为 Pass → 建议批准
总分 5-7 且合规性为 Pass → 需要额外说明，升级到二级审批
总分 < 5 或合规性为 Fail → 建议驳回

5.4 全部装进沙盒——Agent 的任务是提交有效 Patch

# .ita/expense-report/pipeline.yaml
name: "报销单 DoA 管道"
trigger:
  on: push  # 任何新提交或修改提交

stages:
  - stage: validate
    runner: pydantic
    config:
      model: ExpenseReport
      input: "submission/*.json"

  - stage: verify
    runner: pytest
    config:
      test_dir: tests/expense/
      adapters_config: config/adapters.production.yaml
      allow_network: true  # 允许访问内网 API

  - stage: review
    depends_on: [validate, verify]
    gates:
      - name: manager_lgtm
        type: human_review
        rubric: rubrics/expense-review.md
        approvers: ["${report.department.manager}"]
        sla: 1 business day

      - name: finance_lgtm
        type: human_review
        rubric: rubrics/expense-finance-review.md
        approvers: ["finance-team@company.com"]
        sla: 2 business days
        condition: report.amount > 10000  # 大额才触发

      - name: compliance_spot_check
        type: human_review
        rubric: rubrics/compliance-spot-check.md
        approvers: ["compliance@company.com"]
        probability: 0.05  # 5% 抽检

  - stage: merge
    depends_on: [review]
    action: merge_to_main

在这个架构中，Agent 的工作方式发生了根本变化。Agent 不需要"执行一个流程"——它只需要：

1. 读取 I 模型（理解"一份报销单是什么"）
2. 从操作者获取 T₁（对话收集信息、扫描发票、提取关键字段）
3. 按 I 模型生成初始 Patch（一个填充了所有已知字段的 JSON）
4. 本地运行 Validate（Pydantic 校验，快速迭代直到通过）
5. 本地运行 Verify（Pytest，发现事实冲突时向操作者追问或标记异常）
6. Push → CI/CD 管道接管（自动运行全部检查，触发必要的人工 Review gate）
7. 如果 CI 返回未通过 → 拉回修正 → 重新 Push
8. Merge → 完成

Agent 不替代判断层，Agent 是提交者。判断层是 CI/CD 管道——其中确定性规则自动执行，模糊判断人工兜底。

---

6. ITA 的影响

6.1 真正的运营杠杆

杠杆不是来自"自动化了几个步骤"，而是来自一次定义，多次执行。

一套 I/T/A 定义——一个 Pydantic 模型、一组事实源声明、一组测试用例、一个 Review Rubric——一旦被版本化并纳入 CI/CD 管道，就成为了该运营活动的可执行标准。每一个后续的报销单、合同审批、请假申请——都是一次"Push → CI → Merge"。

这与软件开发从手工部署到 CI/CD 的转变是同构的。在手工部署时代，每一次发布都依赖一个 DevOps 工程师的临场判断。在 CI/CD 时代，发布决策由管道中的 gates 自动裁定。ITA 把完全相同的范式应用到运营工作。

杠杆的数量级取决于 I/T/A 定义的复用次数。一个 ExpenseReport 模型每年可能被实例化数万次——这意味着 I 模型的任何一个字段定义错误，或者 A 管道中任何一个测试的遗漏，都会以数万次的规模放大。

6.2 更高的爆炸半径，更高的定义责任

这正是 ITA 的第二个影响：爆炸半径变大了，而这是好事。

流程驱动时代的"爆炸半径"是一张单子。一个审批人犯了错误，影响的是一张报销单。但同样，一个审批人做对了一千次，这一千次的经验没有沉淀为任何可复用的资产。

ITA 的爆炸半径是整个定义。一个 Verify 测试写错了（比如把 <= 写成了 <），影响的可能是全年所有该类报销单。这是更高的风险——但也因此带来了更高的定义责任。

你不会像对待一张审批单那样对待一个 Pydantic 模型。你会 review 它。你会为它写测试。你会在变更它之前做影响分析。正是更高的爆炸半径，倒逼了更严肃的定义过程。 这恰恰是运营工作所需要的——把"审批单上的草率判断"升级为"被版本化、被测试、被 review 的规则定义"。

6.3 人类如何保持心流而非盲目自动驾驶

这是一个合理且深刻的担忧：如果 Validate 和 Verify 全部自动化了，人类只做 Review 层的模糊判断，人会不��脱离业务？

答案是：人类不是做得更少，而是做得更高。

| 今天的人类 | ITA 下的人类 | |-----------|-------------| | 检查发票金额是否填了 | 不需要你做 | | 检查金额是否在预算内 | 不需要你做 | | 凭直觉判断"这顿饭该不该报" | 对照 Rubric 做结构化评审 | | 重复审批 100 张相似的单子 | 只介入异常和升级案例 | | 花 80% 时间在 Validate/Verify 层 | 花 80% 时间在 Review 和规则迭代 |

人类的"心流"不来自于重复的机械检查——那叫疲劳。心流来自于能力与挑战的匹配：任务不能太简单（无聊），也不能太难（焦虑），需要在"刚好能做到但需要全神贯注"的区域。

Validate（检查格式）对所有正常成年人都太简单，做 100 次就是 100 次精神损耗。Verify（比对预算）对系统太简单，对人类太枯燥。真正需要人类判断力的——"这笔支出在当前业务背景下是否合理"——反而因为人类被前两层消耗殆尽而得不到充分的注意力。

ITA 把人类从 Validate 和 Verify 中解放出来，让他们把全部注意力投向 Review 层的真正判断。Rubric 的存在保证了注意力的结构化——不是"凭感觉批"，而是对照明确的评估维度进行判断。

保持人类感知业务状态的机制不是让他们做更多的机械检查，而是：

• I 模型的设计和演化需要人类参与（"我们测量什么？为什么这个字段重要？"）
• Review Rubric 的迭代需要人类参与（"什么算'业务必要性 5 分'？这个标准需要根据上一季度的案例调整吗？"）
• Verify 层的异常降级把系统噪声和规则盲区暴露给人类（"财务系统返回了一个奇怪的状态码，预算余额看起来不对——你要看一下吗？"）
• 抽检和审计随机把已自动通过的案例拉入 Review 层，让人类定期接触真实案例，校准判断标准

这不像飞机的自动驾驶——飞行员在自动驾驶接管时会失去对飞行状态的感知。这更像一个外科医生和手术机器人的关系：机器人处理精准的切割和缝合（Validate 和 Verify），但医生始终在观察、判断、在关键决策点接管。

6.4 组织记忆的形式变化

最后一项影响是组织记忆的载体发生了根本转变。

今天：运营知识储存在 PDF 制度文件、老员工的直觉、新员工的入职培训笔记、审批流的历史数据里。无法测试、无法版本化、无法持续改进、无法确保一致性。

ITA 下：运营知识是 可执行资产——I 模型 + T 事实源声明 + A 测试套件 + Review Rubric。它们被版本化在 Git 仓库中，可以被 pytest 验证，可以在 PR review 中讨论，可以在生产数据上回归测试，可以 fork 出来为不同部门做适配。

这不是"把制度写成代码"——制度本身已经是代码。改制度就是提 PR。制度的执行就是 CI/CD 管道的运行。制度的验证就是测试通过/失败。

---

7. 框架的边界

ITA 不是万能框架。它有几条明确的边界：

不适用于无预设目标的纯粹探索活动。 ITA 要求 I 可以被定义——如果"测什么"本身是不确定的（比如在 0→1 的产品探索阶段），ITA 不适用。

在极端不确定性下（T 完全不可知），需与实验性方法结合。 如果事实源不存在、不可靠、或在快速变化中，Verify 层会持续降级到 Review 层——此时 ITA 退化为"带 Rubric 的人工审查"。

当 I 涉及不可调和的价值观冲突时，框架仅提供对话结构。 如果市场部和财务部对"什么是合理的营销支出"有根本分歧，ITA 不会给出答案——但它会要求双方把分歧显式化为 Review Rubric 中的不同评估维度，而不是把分歧埋在审批流的权力博弈中。

---

ITA 的根本目的是将运营活动从流程驱动转变为判断驱动。通过显式化、分层化地定义"重要、真、可接受"，实现对运营逻辑的系统性解耦、工程化落地与持续评估。流程不再是设计的第一公民——它是 I/T/A 管道编排的涌现结果。