技术思考问题7：AI应用越多，人均产出为何不涨？

AI应用越多，人均产出为何不涨？

接入数量上去了，有效产出却没动，问题出在口径。

[读者] 负责AI落地的架构师与技术负责人
[痛点] 接入了一堆AI能力，人均产出与成本基线没动
[现在读] 需要一个能算净收益的口径，而不是一张接入清单
[读完] 拿到置信度分层路由与单位有效任务成本的落地方案

[旧方案] 按"接入场景数 / 调用量"考核AI价值
    |
    v
[新需求] 提升全要素生产率，算同等业务产出的总成本
    |
    v
[冲突] 考核奖励接入，隐性成本却没人记在账上
    |
    v
[后果] 看着在增产，实际人均有效产出不涨

我是老李，做企业级系统的架构与落地。上个月我参与了一个客服与工单平台的技术复盘，会议室里挂着两组数字：一组是"AI已接入场景数"和"每日AI调用量"，曲线很漂亮；另一组是"人均有效处理工单数"和"单工单综合成本"，半年几乎没动。有人问了一句：那我们这半年到底省了谁的时间。会议室安静了两秒。

这不是某一家公司的问题。《关于发展新质生产力的意见》把"大幅提升全要素生产率"放在很显眼的位置，围绕科技创新、产业融合、发展方式、体制机制、人才工作等方面提出重点举措（具体条目与表述需按当前官方文档核验）。全要素生产率算的是总账：同样的人力与资金投入，能不能换来更多有效产出，而不是"上了多少套AI系统"。

芒格的两个模型很适合拆这件事。一个是激励机制：考核什么，团队就把精力投在哪里。另一个是反演思维：不要先问AI能带来什么收益，而是先问它会在哪些地方失败、会新增哪些成本，把这部分扣掉之后再看净收益是否为负。两个模型合起来，结论其实很硬：新技术投入不等于生产率提升，只有完成同等业务任务的总成本下降，才算真实增益。

当考核口径是"接入了多少AI"，团队会优先去优化什么？

如果换成"完成一单有效业务的总成本"，同一套系统又会被优化成什么样子？

如果净收益是负的，那前半年我们到底在为什么买单？

01、故事

工单平台的结构并不复杂：上游接客服会话、内部提单、邮件与IM消息，中间是意图识别与分派，下游是各业务线的处理人。任务是让高频、重复、口径明确的工单尽量少占人，把人的时间留给真正需要判断的部分。

V1 的路线是"全场景接入"：意图识别、回复草稿、字段抽取、自动分派、知识库问答，能接的地方全接上。配套的考核口径也很自然------每周统计接入场景数与AI调用量，接得越多说明用得好。为了不出错，所有AI生成的回复都要人工点一次"确认发送"，抽取出来的字段也由人工校对一遍。

上线第一个月确实好看：接入场景数在涨，调用量也在涨。第二个月开始，几个信号同时出现：客服的审核队列变长；AI抽取错字段导致工单被退回重填；业务线开始抱怨"AI填的东西还得改一遍"；平台团队被拉去处理各业务线接入后的联调、口径不一致与失败重试。最扎心的评价来自业务方：响应是快了，但活没少干。

冲突就在这里：考核口径奖励"接入与调用"，成本却落在"审核、返工、集成、合规"上，两者不在同一张账上。一个只盯分子的口径，几乎必然把系统推向低置信度场景，因为那里的调用量最容易涨。

接入非产出

调用非效益

口径定方向

账本见真章

02、问题

旧方案在接入铺满之后失效：指标失去区分度，真正该做的事------划边界、记账、评估------反而被挤到一边。因为"再接一个场景"永远比"把一个场景的成本算清楚"更容易交差。

业务影响有三层。第一层是一线时间被挤占：审核本意是防错，结果让同一件事做了两遍。第二层是返工：AI抽错字段，业务侧要退单、重填、重新排队。第三层是平台排期：集成维护与失败恢复吃掉人力，新需求被推后。到最后，管理层看到的是"AI投入在涨、人均产出不动"，耐心会先耗尽。

技术表现是可以被定位的：置信度不参与路由，全量走人工确认；失败路径没有降级，异常即转人工，但转完仍走同一套费用；成本没有按任务归集，只统计了模型调用；质量指标（一次解决率、返工率、人工接管率）根本没有采集。

可验证的完成标准如下：

1. 单位有效任务成本可以被计算，并按任务类型拆分到模型、审核、返工、集成运维、失败恢复五类；
2. 一次解决率不低于改造前的基线，而不是只看"响应时长"；
3. 返工率与人工接管率有明确阈值，越界自动降级为人工；
4. 指标在连续多个观测周期内可对照，而不是一次汇报用的快照。

指标失分辨

成本无人记

边界不曾画

效率自然停

03、原理

本篇只需要三个原理，但它们必须能被后面的架构、故障与优化直接引用。

第一个：考核口径是一种看不见的架构约束。它和路由规则、超时参数一样，会真实改变系统里的流量走向------考核接入数，流量就涌向低置信度场景；考核单位有效任务成本，流量会自动收敛到高置信度路径。

第二个：新技术投入不等于生产率提升。生产率的分母是"完成的同等业务任务"，分子是"为之付出的全部成本"。只升级分子里的工具，不动分母里的任务结构，效率不会变。

第三个：反演思维。先枚举失败模式与隐性成本，再谈收益。人工审核、错误返工、集成维护、失败恢复、合规审计，这五类成本在传统口径里常常"看不见"，但它们真实占用人力。

反直觉判断：AI落地的第一波产出，往往不是省人，而是先造出新的工作------审核、纠错、解释、维护。如果这些工作不计账，效率提升只会停留在汇报材料里。

反直觉判断：把"AI覆盖率"当目标，系统会自动漂移到低置信度场景；而低置信度场景的单位总成本，经常比纯人工更高，因为它把同一件事做了两遍甚至三遍。

口径即约束

投入非产出

先算失败账

再谈净收益

04、架构

[输入] 客服会话 / 内部提单 / 邮件与IM
    |
    v
[模块] 意图识别 + 置信度评分 + 分层路由
    |
    v
[数据/状态] 任务成本账本（模型/审核/返工/运维/合规）
    |
    v
[处理] 自动执行 / 人工确认 / 人工兜底 + 结果回流评估
    |
    v
[输出] 工单结果 + 单位有效任务成本

边界：自动执行只覆盖高置信度、可回滚、低合规风险的路径；人工确认覆盖中置信度与关键字段；低置信度、低频高风险、数据低质、受监管场景一律人工兜底，AI只做检索与草稿。

收益：成本第一次变得可归因------每一单的成本能被拆到五类账上，于是"该不该自动化"从立场之争变成算术题。

代价：需要维护置信度评分与成本账本，路由分支变多，阈值需要按任务类型分别校准；系统复杂度确实上升了。

适用条件：高频、口径相对稳定、有历史基线、结果可观测可回滚的流程（客服、工单、审核类任务最典型）；低频高风险与监管场景不满足这个条件。

分层定路径

账本记真成本

高信免人审

低信自动退

05、实战一次

环境与版本：Python 3.11，仅使用标准库（不引入第三方依赖）。依赖：无。以下实现是一个最小但完整的 V1：读取任务样本，按置信度分层路由，按五类成本归集，输出单位有效任务成本与质量指标。

配置文件 routes.json：

{
  "auto_threshold": 0.85,
  "human_threshold": 0.55,
  "hourly_wage": 60.0,
  "model_cost_per_call": 0.02,
  "review_minutes": 2.0,
  "rework_minutes": 6.0,
  "ops_cost_per_task": 0.05,
  "compliance_cost_per_task": 0.03
}

核心实现 unit_cost.py：

"""单位有效任务成本 + 置信度分层路由（V1 最小实现）。"""

from __future__ import annotations

import json
import sys
from dataclasses import dataclass
from typing import Literal

Route = Literal["auto", "review", "human"]


@dataclass
class Config:
    auto_threshold: float
    human_threshold: float
    hourly_wage: float
    model_cost_per_call: float
    review_minutes: float
    rework_minutes: float
    ops_cost_per_task: float
    compliance_cost_per_task: float

    @classmethod
    def load(cls, path: str) -> "Config":
        with open(path, "r", encoding="utf-8") as f:
            return cls(**json.load(f))


@dataclass
class Task:
    task_id: str
    category: str
    confidence: float
    reworked: bool
    resolved_first_time: bool


def load_tasks(path: str) -> list[Task]:
    with open(path, "r", encoding="utf-8") as f:
        raw = json.load(f)
    return [Task(**item) for item in raw]


def decide(confidence: float, cfg: Config) -> Route:
    if confidence >= cfg.auto_threshold:
        return "auto"
    if confidence >= cfg.human_threshold:
        return "review"
    return "human"


def task_cost(task: Task, route: Route, cfg: Config) -> dict:
    minutes = 0.0
    cost = cfg.ops_cost_per_task + cfg.compliance_cost_per_task
    if route == "auto":
        cost += cfg.model_cost_per_call
    elif route == "review":
        cost += cfg.model_cost_per_call
        minutes += cfg.review_minutes
    else:
        cost += cfg.model_cost_per_call
        minutes += cfg.review_minutes * 3.0
    if task.reworked:
        minutes += cfg.rework_minutes
    cost += minutes / 60.0 * cfg.hourly_wage
    return {"route": route, "minutes": minutes, "cost": cost}


def main(tasks_path: str, config_path: str) -> None:
    cfg = Config.load(config_path)
    tasks = load_tasks(tasks_path)

    total_cost = 0.0
    effective = 0
    rework_count = 0
    handover_count = 0
    by_route = {"auto": 0, "review": 0, "human": 0}

    for task in tasks:
        route = decide(task.confidence, cfg)
        detail = task_cost(task, route, cfg)
        total_cost += detail["cost"]
        by_route[route] += 1
        if route != "auto":
            handover_count += 1
        if task.reworked:
            rework_count += 1
        if task.resolved_first_time and not task.reworked:
            effective += 1

    n = len(tasks)
    unit_cost = total_cost / effective if effective else float("inf")
    print(json.dumps({
        "tasks": n,
        "effective_tasks": effective,
        "unit_effective_task_cost": round(unit_cost, 4),
        "first_time_resolution_rate": round(effective / n, 4) if n else 0.0,
        "rework_rate": round(rework_count / n, 4) if n else 0.0,
        "handover_rate": round(handover_count / n, 4) if n else 0.0,
        "route_distribution": by_route,
    }, ensure_ascii=False, indent=2))


if __name__ == "__main__":
    main(sys.argv[1], sys.argv[2])

样例输入 sample_tasks.json：

[
  {"task_id": "T001", "category": "退款查询", "confidence": 0.93, "reworked": false, "resolved_first_time": true},
  {"task_id": "T002", "category": "退款查询", "confidence": 0.91, "reworked": false, "resolved_first_time": true},
  {"task_id": "T003", "category": "发票问题", "confidence": 0.67, "reworked": false, "resolved_first_time": true},
  {"task_id": "T004", "category": "发票问题", "confidence": 0.72, "reworked": true, "resolved_first_time": false},
  {"task_id": "T005", "category": "账号申诉", "confidence": 0.41, "reworked": false, "resolved_first_time": true},
  {"task_id": "T006", "category": "账号申诉", "confidence": 0.38, "reworked": true, "resolved_first_time": false}
]

启动：

python unit_cost.py sample_tasks.json routes.json

未在当前环境实测，以下为预期结果（示例输出，非生产数据）：

{
  "tasks": 6,
  "effective_tasks": 4,
  "unit_effective_task_cost": 7.15,
  "first_time_resolution_rate": 0.6667,
  "rework_rate": 0.3333,
  "handover_rate": 0.6667,
  "route_distribution": {"auto": 2, "review": 2, "human": 2}
}

验证要点：同一批任务，只把 auto_threshold 从 0.85 调到 0.6，路由分布、返工率与单位成本都会变化。这说明阈值本身就是成本参数，不能拍脑袋定，必须用基线数据校准。

先跑通一版

再计量成本

阈值即参数

数据来定夺

06、排查

现象一：AI调用量在涨，人均有效处理工单数不动。

怀疑：模型生成质量不够，导致人还得改。

检查：抽取被"确认发送"的回复，统计修改比例，并记录审核员从打开草稿到点确认的耗时。

证据：审核耗时接近从零写一条回复；部分场景的草稿修改比例很高，说明审核员实际上是在重写。

根因：低置信度任务也走了自动草稿路径，并且强制全量人工确认------同一件事做了两遍，第二遍并不比第一遍快。

修复：把置信度引入路由，高置信度免审、中置信度只审关键字段、低置信度直接给人工。

错误尝试： 第一反应是换一个参数更大的模型。为什么错：瓶颈在流程与边界，不在生成质量。换模型会同时抬高单次生成成本与延迟，而审核与返工的结构一点没变，单位有效任务成本反而上升。这是典型的"用技术手段解管理问题"。

现象二：单位有效任务成本没有下降，甚至轻微上升。

怀疑：模型调用太贵。

检查：按任务把成本拆成五类归集------模型、审核、返工、集成运维、失败恢复。

证据：集成维护与失败恢复的人工工时占比很高，而且此前从未进入任何成本口径，全部沉淀在平台团队的工时里。

根因：考核口径只统计接入数量与调用量，运维成本被转移到平台侧，业务侧感知不到，于是"接入越多越划算"的错觉被持续强化。

修复：把集成维护与失败恢复按任务摊入单位成本，并在接入评审阶段前置估算，而不是上线后再补账。

现象三：某一类低频高风险工单出现了合规争议。

怀疑：模型判断不可靠。

检查：复核该类工单的自动执行比例与规则来源。

证据：该类场景历史样本极少、口径每年调整，且结果不可回滚。

根因：把"能自动化"当成了"该自动化"。

修复：低频高风险、数据低质与受监管场景默认人工，AI只承担检索与草稿，不进入自动执行路径。

现象非根因

换模不解事

成本要摊开

边界须退回

07、优化

V2 完全基于第 06 章的证据，不引入新的猜测。

根因收敛为三条：口径只奖励接入；成本只统计模型；边界没有按置信度与风险划分。

修改一：把路由改为三层。高置信度自动执行，中置信度人工确认关键字段，低置信度直接人工，高风险与受监管类型无论置信度一律人工。原因是第 06 章现象一与现象三都指向"全量确认"和"无差别自动"这两件事。

修改二：把成本账本从"模型单一科目"扩到五类，并规定项目评审必须提交改造前的基线（人时、质量、成本）与改造后的预计单位有效任务成本。原因是现象二的证据表明，最贵的部分不在模型调用，而在没有入账的运维与返工。

修改三：把质量指标写进上线门禁：一次解决率不得低于基线，返工率与人工接管率越界即自动回退为人工。原因是只有可回退，边界才不是一句口号。

新行为：低置信度任务不再产生草稿，直接进人工队列；高置信度任务免审；账本每周出一次单位有效任务成本；指标越界时路由阈值自动收紧。

验证方式：用第 06 章同一批任务的样本重跑，对比审核耗时、返工工单数与单位有效任务成本三项。这里只给出验证方法，具体数值需要按真实基线核验，不做假设。

根因定改法

五类成本摊

门禁可回退

样本再对照

08、演进

[同一输入] 客服会话 / 内部提单
    |
    +--[V1] 全场景接入 + 全量人工确认 / 审核与返工叠加，单位成本不降
    |
    +--[V2] 置信度分层路由 + 五类成本归集 / 需维护账本、阈值与回退机制
    |
[Trade-off]
得到：可归因的净成本与可回退的边界；失去："AI覆盖率"的漂亮数字与短期接入速度；边界：高频、可观测、可回滚、口径稳定的流程

正确性：V1 与 V2 都能把工单处理完，区别在于 V2 会把不确定的任务主动交还给人，因此错误外溢更少。

稳定性：V1 的稳定性依赖审核员的疲劳程度，人越累错越多；V2 把稳定性建立在阈值与回退机制上，波动更可预期。

复杂度：V2 明显更高，需要维护置信度评分、成本账本、阈值校准与门禁；这是一次真实的工程投入，不是"顺手加个开关"。

成本：V1 看起来省了模型以外的钱，实际上把成本推给了审核、返工与平台维护；V2 把全部成本显性化，短期账面可能更"贵"，长期取决于单位有效任务成本是否真的下降。

适用范围：V2 适用于高频、可观测的流程；低频高风险与监管场景只适合"AI做草稿、人做决定"。

遗留问题：置信度评分本身的校准需要标注与回流数据；成本分摊到单任务的规则仍带主观性，需要统一口径并定期复核。

旧版铺得广

新版算得清

得失去虚荣

换来回退权

09、洞见

9.1 考核口径是一种看不见的架构约束

团队不会按架构图工作，只会按考核表工作。把"接入场景数"写进考核，等于在系统里加了一条隐藏路由：所有精力流向"再多接一个"，而不是"把这一单的成本算清楚"。所以改口径往往比改代码更能改变系统行为，也更快。

反直觉判断：口径调整的成本极低，但它的杠杆比绝大多数技术优化都大------因为它改变的是所有参与者的默认选择。

9.2 反演思维：先枚举失败，再谈收益

正向推演会自然得出"能自动化就自动化"，因为收益容易想象、成本不容易枚举。反演要求先列出失败清单：审核、返工、集成、失败恢复、合规，并估算它们各自的时间成本。五类成本一旦写在同一张表上，很多项目的净收益结论会直接反转。

反直觉判断：一个AI项目失败的原因，通常不是模型不够强，而是从没有人被要求写出它会失败在哪里。

9.3 自动化的边界由置信度与代价共同决定

只按置信度划边界是不够的，必须叠加"出错代价"这一维。同样是 0.9 的置信度，退款查询错了可以重来，账号申诉错了无法回滚，两者的边界不可能一样。V2 里"高风险类型无论置信度一律人工"，就是把代价这一维显式写进路由。

9.4 单位有效任务成本是唯一能横向比较的刻度

不同团队、不同模型、不同场景之间，"准确率""调用量""覆盖率"都不可比。唯一可比的是：完成一单有效业务，总共花了多少钱、多少时间。把分母统一为"有效任务"，把分子拉到"全部成本"，效率讨论才会从立场之争变成算术题。

口径先对齐

失败先枚举

边界看代价

成本才可比

10、系统落地

原来有什么：一套工单平台，AI能力分散接入，考核看接入数与调用量，成本只统计模型调用，质量指标基本没有采集。

本篇新增了什么：一套五类成本账本（模型、审核、返工、集成运维、失败恢复），一套置信度与代价双维的分层路由，一套把一次解决率、返工率、人工接管率纳入门禁的回退机制。

现在能做什么：可以回答"这单做完，净成本是多少"；可以在接入评审阶段就否掉净收益为负的场景；可以在指标越界时自动收紧，而不是靠人盯。

还缺什么：置信度评分的校准数据与标注回流还没闭环；跨团队的成本分摊口径还需要统一；政策与合规要求是外部变量，具体条款需按当前官方文档核验，边界要随监管变化重新校准。

下一步如何演进：先把结论收紧到一条------新质生产力看业务净效益，不看AI系统数量。工程上则是把单位有效任务成本做成平台的一等指标，像可用性一样被监控、被门禁、被追责。

账本已在手

路由可回退

口径还待统

效益才可量

11、小结

Q1 → 考核接入数量，团队就优化接入数量，成本却落在从未入账的审核、返工、集成与合规上
Q2 → 换成单位有效任务成本，系统会自动收敛到高置信度路径，并对低置信度与高风险主动降级
Q3 → 不记隐性成本，买单的是一线被挤占的时间、被拖慢的平台排期和被消耗的管理信任
状态 → 交付"置信度分层路由 + 五类成本归集 + 指标门禁回退"的净收益核算方案

12、作业

12.1 理解题：为什么"AI调用量上涨"不能证明效率提升？

参考答案：调用量是投入侧的计数，不是产出侧的结果。效率的分母是完成的同等业务任务，分子是为之付出的全部成本；调用量既不进入分子也不进入分母，只能说明工具被用得更多。只有单位有效任务成本下降，且质量指标不退化，才构成效率增益。

12.2 实战题：给定一批工单样本，如何算出改造前后的单位有效任务成本？

参考答案：先定义"有效任务"（一次解决且未返工），再为改造前后各建一张账：模型成本、审核人时、返工人时、集成维护分摊、失败恢复分摊。把各自的总成本除以各自的有效任务数，得到两个单位成本做对比；同时校验一次解决率、返工率、人工接管率是否越界。样本量不足时用同一批任务做对照，而不是用两个时间段的整体数据。

12.3 排障题：某场景上线后单位成本不降反升，先查什么？

参考答案：先按任务拆成本，而不是先换模型。多数情况下问题出在两类：一是低置信度任务也走了自动路径并叠加了全量人工确认，导致同一件事做两遍；二是集成维护与失败恢复的工时没有入账，被沉淀在平台团队。确认这两项之后再评估模型成本，最后才考虑更换模型。

12.4 架构判断题：是否应该把所有可自动化的环节都自动化？

参考答案：不应该。自动化边界由置信度与出错代价共同决定。高频、可回滚、口径稳定的环节适合自动执行；低频高风险、数据低质、受监管的环节应保留人工决定权，AI只做检索与草稿。判断标准不是"能不能自动"，而是"自动之后单位有效任务成本是否下降，且错误代价可承受"。

会算再动手

能退才敢上

高频先小步

依据要留存

13、思考

回到最初那个问题：AI应用越多，人均产出为何不涨。答案并不在模型侧，而在账本侧------被考核的是接入，被记录的是调用，被忽略的是审核、返工、集成与合规。激励决定精力去向，反演决定成本是否被看见，两者缺一，技术投入就无法转化为效率。

可复用的工程判断只有四条：把"完成同等业务任务的总成本"作为唯一效率刻度；把置信度与出错代价作为自动化的双维边界；把隐性成本在项目评审阶段就计入账本；把质量指标做成可回退的门禁，而不是汇报材料。做到这四条，AI 才会从"系统数量"变成"业务净效益"。

激励定方向

反演见成本

净收益说话

效率才算真