AI自动化75%后剩25%：人机协作与人工兜底实战

1. 为什么“75%自动化”这句话值得深挖过去一年我听过太多团队在做同一件事把某个业务流程交给 AI。有人用大模型做客服有人用 Agent 做代码审查有人让模型自动填报表。结果也惊人地相似——头两周效率提升明显一个月后问题开始暴露。“In AI-native firms, tech automates 75% of the work” 这句话最初是很多人对 AI 原生企业的描述。75% 这个数字本身未必精确但它指出了一个值得认真对待的事实一家真正以 AI 为核心驱动力的公司绝大多数标准化工作可以被自动化。但这句话更关键的是后半句——剩下的 25% 是什么不同的人会给出不同答案。管理者说那 25% 是“判断力”产品经理说那是“用户同理心”工程师说那是“边缘 Case 和异常处理”。这些答案都对但都太笼统。如果我们要真的把这 25% 变成可工程化、可管理、可训练的能力就必须把它拆开来看。这篇文章想解决三个问题AI 自动化的边界到底在哪里——为什么很多团队做到 70% 就卡住了。剩下的 25% 具体包含哪些东西——不是抽象地讲“人类价值”而是列出可识别、可分类的任务类型。如何用工程手段管理这 25%——通过置信度阈值、人工审批流、提示词设计和日志分析让“人机协作”不再是口号而是可运行的机制。这篇文章适合正在做 AI 应用开发、Agent 设计、RPA 替代方案或者正在公司内部推动智能化改造的工程师和技术管理者。2. 自动化能做到 75%AI 原生企业到底自动化了什么先做一个简单的分类。AI 原生企业里真正能被大规模自动化的任务通常符合以下几个特征。特征一输入输出结构明确。比如把一段客服对话转成工单从发票 PDF 里提取金额和日期把英文邮件翻译成中文。这类任务的输入是一份有边界的材料输出是一个可以校验的格式。大模型做这类事情不需要创造只需要提取和变换。特征二有标准答案或可验证的答案。代码生成、单元测试编写、SQL 查询生成、数据清洗脚本都属于这一类。虽然代码风格可能有差异但最终能否通过编译、测试是否通过、查询结果是否正确是客观可验证的。特征三重复度高、上下文完整。每周要写的周报、每日要同步的进度、定时要生成的报表都有固定的模板和明确的信息来源。给 AI 足够的上下文它就能稳定产出。符合这三个特征的工作在知识型团队里往往占 60% 到 80%这就是 75% 这个数字的由来。但并不是说只要用了 AI这些工作就会自动完成。达到这个比例需要配套工程改造例如把流程拆成标准化的步骤节点而不是端到端让 AI 自由发挥。为每个任务建立清晰的 Prompt 模板和数据 Schema。增加人工抽检和自动校验机制。把失败案例沉淀成知识库反哺 Prompt 和规则。回到团队视角75% 的自动化意味着三层变化。第一层执行层的人力被释放这是最直观的效率提升。第二层中层管理者的角色从“盯进度”变成“定标准”因为 AI 需要你告诉它什么是对的而不是事后检查它做了什么。第三层工程师要维护的不再只是代码仓库还包括 Prompt、评测集、知识库和自动化链路这是一套新的系统工程。很多团队卡在 70% 附近原因也很一致组织结构没变流程没变只是把某个环节替换成了 AI。自动化一个点容易自动化一整条链需要重新设计接口和决策点。这就是后面要展开的重点。3. 剩下的 25%不是“人类智慧”而是四类具体任务如果你把 25% 理解成“创造力和领导力”那就没法落地了。我倾向于把这 25% 拆成四类可识别的任务3.1 第一类高风险的“最后一步”决策AI 可以生成一封措辞严厉的催款函但要不要真的发给一位合作了三年的老客户这个决定通常得由人来做。AI 可以生成一份裁员沟通的草稿但怎么在具体团队里沟通、什么时候说、先跟谁说这不是提示词能覆盖的。这类任务的共同点是一旦出错修复成本远高于自动化节省的成本。从工程角度看这类任务应该被识别为“高风险动作”在系统设计时显性地加入人工确认环节。3.2 第二类无法被完整描述的边缘情况很多工作 80% 都是标准化流程20% 是各种意外。比如自动处理发票报销绝大多数发票格式清晰但偶尔会有褶皱扫描件、手写备注、多币种混合、折扣分摊不清的情况。你可以在提取规则里写一百条规则仍然会漏掉第一百零一种情况。边缘情况的核心特征是很难在事前枚举只能靠事后发现。AI 原生系统要解决的不是“彻底消灭边缘情况”而是“当边缘情况出现时系统知道自己在边缘状态并且知道该把问题转交给谁”。这比追求 100% 自动化更有价值。3.3 第三类跨系统、跨部门的协调在真实企业里一个任务往往要经过多个系统。比如客户说“我想把账户从个人版升级到企业版但希望保留历史数据”。这个请求涉及计费系统、数据迁移、权限映射、合同签署四个系统三个团队。AI 可以很聪明地理解客户意图但真正执行时每一步都可能因为内部流程规则而被阻断。比如某个系统只有运营团队才能操作某个数据迁移必须走审批流。这些协调工作短期来看仍然需要人来完成因为 AI 没有账号权限也没有跨团队的信任背书。3.4 第四类价值方向的创造AI 可以生成十个营销文案但选择哪个方向跟品牌调性一致这是价值判断。AI 可以列出产品功能的十个优化方向但决定下一季度把资源投在哪里这是商业判断。这类任务无法自动化不是因为 AI 算力不够而是因为价值排序本身需要有人承担责任。AI 可以做辅助分析可以列出利弊但最终决策者必须是人——这不是技术限制而是责任逻辑。这四类任务第一类可以靠流程设计来管理第二类可以靠系统反馈循环来覆盖第三类需要人和系统逐步磨合第四类永远需要人。理解这个分类之后再去看“人机协作”就有抓手了我们不是笼统地说“人要做有价值的事”而是可以精确地说系统应当把第四类任务默认给人类同时把第一、二、三类尽可能显性标注、转交和升级。4. 从模型能力到工程能力补齐 25% 场景的技术支撑既然确定了 25% 需要人来兜底接下来的技术问题就是系统怎么知道什么时候应该找人这不能靠人的自觉必须靠一套机制。典型的技术手段有三个置信度阈值、意图识别分类、人工审批流。4.1 置信度阈值让模型自己知道“不会”大语言模型在生成答案时可以通过 logprobs 或者采样一致性来估算置信度。你可以在任务分类之后设置一个阈值比如置信度低于 0.75 的任务自动进入人工队列。这个方案的意义不在于阈值本身而在于在系统设计时就把“不确定性”作为一种状态来管理。不要等模型输出错误结果后才发现问题而是在输出前就分流。4.2 意图分类把“25% 类型”前置识别更常见的做法是在流程入口做一个意图分类和风险分级。比如一个单据处理系统先用一个分类模型判断任务的复杂度和风险等级。低风险、结构化的任务直接进入自动化高风险、模糊描述的任务默认分配给人。4.3 人工审批流把“人”嵌进流程节点纯技术手段只能减少 25% 的任务量但无法消灭它们。所以流程引擎里需要人工节点支持分配、退回、补充材料、加签、批注。这一层通常不是模型能力决定的而是工程架构决定的。4.4 日志与复盘让 25% 的案例反哺模型这可能是最容易忽略的一环。每次人工处理了一个边缘情况都应该被记录下来形成新的标注数据。积累到一定程度后原本的 25% 会逐步缩小。这个迭代进度的关键指标就叫自动化覆盖率。从工程角度看这里有一张不断进化的蓝图阶段主要任务人工介入比例核心技术初跑期自动化主流程50% 以上基础 LLM 调用、标准 Prompt稳定期异常处理和规则固化25% 左右意图分类、置信度阈值、人工审批成熟期边缘案例反哺模型10% 以下评测集、微调、知识库、反馈闭环5. 最小可运行示例一个“自动化 人工兜底”的任务处理系统这里我们用一个贴近日常开发的场景来说明完整思路假设我们要做一个 AI 客服工单分类系统系统能自动识别客户意图但拿不准时转人工。这是一个非常典型的价值点——它刻意保留了 25% 的决策空间。5.1 系统设计系统分为三个模块意图识别模块调用大模型判断用户请求属于哪一类。置信度评估模块根据模型返回的 logprobs 或多次采样一致性计算置信度。人工队列模块置信度低于阈值的请求进入人工审理队列。整体流程如下用户提交请求 → 系统调用模型 → 计算置信度 → 决定自动处理或转人工 → 人工处理结果记录反馈 → 反馈用于后续优化。5.2 环境准备示例使用 Python 3.9 以上版本用到以下依赖pip install openai python-dotenv pandas注意不同版本的库可能存在 API 差异示例代码以常见可用接口为准具体版本请结合你的实际环境调整。重点演示工程结构而非某个厂商的 SDK 细节。5.3 核心代码实现先写一个意图识别与置信度评估模块# 文件路径src/intent_router.py import os import json from openai import OpenAI client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) INTENT_LIST [退款, 换货, 发票, 订单查询, 投诉, 其他] def classify_intent(user_message: str) - dict: 通过大模型识别意图并返回置信度。 这里使用多次采样一致性作为置信度参考不依赖单一 logprob。 responses [] for _ in range(3): # 采样 3 次观察结果是否一致 resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: f你是一个工单意图分类器。请从以下列表选择最合适的类别{INTENT_LIST}。只输出类别名。}, {role: user, content: user_message} ], temperature0.2 ) responses.append(resp.choices[0].message.content.strip()) # 统计三次采样结果 from collections import Counter counter Counter(responses) top_intent, top_count counter.most_common(1)[0] confidence round(top_count / len(responses), 2) return { intent: top_intent, confidence: confidence, all_responses: responses }这段代码的逻辑是什么它三次调用模型看返回的意图是否一致。如果三次都返回“退款”置信度就是 1.0。如果三次返回两个不同答案置信度就是 0.67。这种“采样一致性”的方法不依赖大模型底层的 logprobs兼容性更好尤其在调用不同厂商模型时非常实用。接着写决策模块。系统根据置信度决定走自动处理还是人工队列# 文件路径src/decision.py from src.intent_router import classify_intent # 人工介入阈值低于此值的任务转人工 HUMAN_THRESHOLD 0.7 # 不同意图对应的自动化通道 AUTO_CHANNEL_MAP { 退款: auto_refund_workflow, 换货: auto_exchange_workflow, 发票: auto_invoice_workflow, 订单查询: auto_order_lookup_workflow, } def route_task(user_message: str) - dict: result classify_intent(user_message) intent result[intent] confidence result[confidence] if confidence HUMAN_THRESHOLD: return { decision: human, reason: f置信度不足{confidence}, intent: intent, message: user_message, } if intent in AUTO_CHANNEL_MAP: return { decision: auto, channel: AUTO_CHANNEL_MAP[intent], intent: intent, confidence: confidence, message: user_message, } # 意图是“投诉”或“其他”默认需要人工处理 return { decision: human, reason: f意图需要人工处理{intent}, intent: intent, message: user_message, }这里有一个关键设计不是所有低置信度才转人工有些意图本身就默认需要人工。比如“投诉”即使 AI 很有把握地识别出了这是投诉也应该交给人来处理因为投诉的处理策略高度依赖具体情境不是一个标准模板能覆盖的。这就是把“25%”显性编码到系统里。然后是人工处理模块和反馈记录模块# 文件路径src/human_review.py import json import datetime class HumanReviewQueue: def __init__(self, queue_file: str human_tasks.jsonl): self.queue_file queue_file def add_task(self, task: dict): 将转人工的任务写入队列文件等待人工处理 task[created_at] datetime.datetime.utcnow().isoformat() task[status] pending with open(self.queue_file, a, encodingutf-8) as f: f.write(json.dumps(task, ensure_asciiFalse) \n) def resolve_task(self, task_id: str, resolution: str, feedback: str ): 人工处理完成后记录处理方案和反馈。 feedback 可用来积累边缘案例数据后续用于优化模型或提示词。 # 实际项目中这里通常需要更新数据库记录 # 这里演示记录到反馈文件 with open(feedback.jsonl, a, encodingutf-8) as f: record { task_id: task_id, resolution: resolution, feedback: feedback, resolved_at: datetime.datetime.utcnow().isoformat(), } f.write(json.dumps(record, ensure_asciiFalse) \n)最后写一个入口文件把整个流程跑起来# 文件路径src/main.py from src.decision import route_task from src.human_review import HumanReviewQueue def main(): queue HumanReviewQueue() test_messages [ 你好我上周买的手机屏幕碎了想申请退款。, 麻烦帮我看看我订单号 12345 现在到哪里了很着急。, 你们的服务太差了我要投诉, 我想问一下充电器的保修期一般多久, ] for msg in test_messages: result route_task(msg) print( * 50) print(f用户消息: {msg}) print(f决策: {result[decision]}) if result[decision] human: queue.add_task(result) print(f原因: {result.get(reason, )}) print(→ 已转入人工队列) else: print(f→ 进入自动通道: {result[channel]}) if __name__ __main__: main()5.4 配置文件示例实际项目中阈值、提示词、意图列表都不应该硬编码在代码里。建议用 YAML 或 JSON 配置文件统一管理# 文件路径config/config.yaml model: name: gpt-4o-mini temperature: 0.2 sample_times: 3 thresholds: human_review_confidence: 0.7 intents: auto: - refund - exchange - invoice - order_query human_default: - complaint - other human_review: queue_file: data/human_tasks.jsonl feedback_file: data/feedback.jsonl配置管理的意义在于当你发现 0.7 的阈值让太多任务转人工时不需要改代码只需要调配置文件。生产环境里这种可调性非常重要。6. 运行与验证如何判断“75% 25%”设计是否合理运行上面的最小示例你会得到类似输出 用户消息: 你好我上周买的手机屏幕碎了想申请退款。 决策: auto → 进入自动通道: auto_refund_workflow 用户消息: 麻烦帮我看看我订单号 12345 现在到哪里了很着急。 决策: auto → 进入自动通道: auto_order_lookup_workflow 用户消息: 你们的服务太差了我要投诉 决策: human 原因: 意图需要人工处理投诉 → 已转入人工队列 用户消息: 我想问一下充电器的保修期一般多久 决策: human 原因: 置信度不足0.33 → 已转入人工队列如果第四条消息被三次采样分到了不同意图比如一次“发票”、一次“订单查询”、一次“其他”置信度就是 0.33低于阈值 0.7于是转人工。这种情况恰恰是系统设计期望发生的模型拿不准时把问题交给人是正确选择而不是硬猜。那如何评估系统是否有效建议关注四个指标自动化覆盖率自动处理的任务数占总任务数的比例。你希望这个值逐渐升高但不要追求极端。人工处理准确率人工处理的结果是否被用户接受。这个指标反映人机协作的最终质量。升级及时率应该转人工的任务是否真的转到了人工。如果转人工率只有 2%但投诉率很高说明你的系统过度自信了。反馈闭环率人工处理的案例有多少被记录并反馈到模型优化。没有这一步系统不会进步。如果运行失败怎么办排查顺序问题现象可能原因排查方式解决方案调用模型时报 401 错误API Key 未正确配置检查环境变量和.env文件正确设置OPENAI_API_KEY返回内容不是预期意图Prompt 指令不够明确打印模型原始返回内容修改 System Prompt限制输出格式所有任务都转人工阈值设置过高查看置信度分布日志统计历史置信度调整阈值自动处理结果错误率偏高某些意图不适合完全自动化对比自动与人工处理的效果将高风险意图加入human_default列表人工反馈没有产生效果反馈数据未用于模型迭代检查反馈日志是否沉淀建立定期用反馈数据更新 Prompt 的机制7. 常见误区为什么很多团队做不到“75% 25%”在接触过不少相关项目之后我发现几类反复出现的问题。7.1 误区一以为阈值能解决所有问题置信度阈值是必要但不充分的。模型可能在低置信度时给出正确答案也可能在高置信度时给出错误答案。阈值只能帮助你建立一个兜底机制但是语义层面的风险判断——比如这件事涉及财务、法务、人身安全——必须由规则或应用层逻辑去识别不能只看置信度。换句话说阈值是概率层判断有些任务根本不需要判断概率它本身就属于高风险类别应该从一开始就默认转人工。7.2 误区二把“转人工”看成一个失败状态很多设计者希望系统尽可能自动处理把转人工当成产品不够智能的表现。这个想法是危险的。在产品初期转人工恰恰是系统最可靠的保护网。更合理的做法是把人工队列视为一个学习通道而不是一个失败出口。每一次人工处理都是在为系统标注一个新的边界案例。你在前面记录 feedback.jsonl正是为了这个目的。7.3 误区三忽略决策过程的审计很多团队只关注 AI 的预测结果不关注这个结果的推理过程。但在生产环境中你可能需要回答“为什么这个工单被自动退款了”。如果没有日志记录没有决策链路追踪出了问题很难溯源。推荐的做法是为每次请求生成唯一的 request_id把模型输出、置信度、最终决策、人工处理结果全部记录在日志中。这不仅是排查问题的需要更是一套合规边界保护。7.4 误区四静态 Prompt没有迭代很多团队把 Prompt 当成一次性工作写完就固定了。但 Prompt 本身就是代码它需要被版本管理、测试和迭代。你可以从每月的高频反馈中提炼出新的规则把它补充到 Prompt 或配置里。8. 最佳实践把这套系统放进真实项目如果你要在真实项目里落地这套“自动化 75% 人工 25%”的系统这里有几条经过验证的建议。8.1 从流程设计开始而不是从代码开始先梳理你的业务流程画出任务节点识别哪些节点需要判断、哪些节点需要外部授权、哪些节点出错成本最高。在这一步你就能看出哪些任务应该自动化哪些必须留人。8.2 先跑通 60% 的简单场景再慢慢扩展不要一开始就追求 75% 的自动化率。先选择结构最清晰的一类任务比如订单查询跑通系统积累反馈数据再把系统推广到更复杂的场景。快速验证的成本远低于全量改造。8.3 自动化要有退路生产环境的自动化链路必须支持手动切换。比如当模型连续多次超时或返回错误格式时系统应当自动进入“全量人工”的降级模式。这个开关比任何告警都重要。8.4 建立一个可评测数据集评测集至少包含三类样本成功的自动化案例、需要人工介入的案例、曾经造成问题的案例。每次更新 Prompt 或模型都用这个评测集跑一遍对比准确率和转人工率有没有异常。8.5 把人工处理记录变成知识库人工处理的边缘案例不要处理完就丢弃。按类型归纳把它沉淀成知识库。比如“发票模糊但能识别出公司名称”的案例积累到一定数量后可以作为一个专门的预处理规则。这个知识库是自动化率提升的最重要燃料。8.6 权限与安全边界涉及资金、个人信息、法律条款的操作即使 AI 正确识别了意图也不要让它在没有授权的情况下自动执行。在系统架构层面将这类操作与自动执行通道隔离确保每一次操作都有审计记录并且按最小权限原则设计服务账号。9. 落到你自己的项目里回到题目本身AI 原生企业里技术自动化了 75% 的工作剩下的 25% 是什么我的回答是剩下的不是“人的价值”“创造力”这些大词而是高风险决策、边缘情况、跨系统协调、价值方向这四类具体任务。它们是任何 AI 系统都无法完全替代的部分。但更重要的是这 25% 不是静态固定的。它会随系统成熟而缩小。当你持续沉淀边缘案例反馈、不断调整阈值、优化评测集、完善人工审批流之后原本需要人工的 25% 中会有一部分逐渐变成可自动化的规则系统整体自动化率将进一步上升。而与此同时新的业务形态和新的需求又会持续产生新的 25%。这不是一个“把 AI 用起来”就能解决的问题而是一个需要持续工程化改造的系统工程。如果你正在为自己的团队设计这样的人机协作体系建议从最小闭环开始一个任务入口、一个分类模型、一个置信度阈值、一个人工队列。先跑通再迭代。真正的 AI 原生企业不是把所有工作都交给 AI 的企业而是清楚知道哪些工作必须由人来完成并且能用工程手段保障这些工作在正确的人手中完成的企业。