如果一家公司把日常工作的 75% 交给技术自动化剩下的 25% 应该由谁来做、做什么、怎么做这个问题是很多团队在引入大模型、AI Agent 之后都会遇到的真实困惑。本文不打算讨论宏观趋势而是从 AI 工程实践的视角出发把这 75% 与 25% 的边界拆清楚并给出一套从自动分流到人工复核的落地示例希望能给正在做 AI 应用开发、AI 产品设计和后端工程的同学一些思路。1. 理解“AI 原生企业”与 75% 自动化1.1 什么是 AI 原生企业AI 原生企业并不是指“用了很多 AI 工具”的公司而是指业务流程、组织架构、技术架构在最初设计时就以大模型、AI Agent、自动化流水线为核心组成部分的企业。传统企业通常先把业务系统搭好再考虑“要不要接入 AI”AI 原生企业则相反它默认每一步业务动作都应该由机器完成只有在机器无法处理、风险过高或需要责任人拍板时才会把任务交给人类。这种企业里代码仓库、工单系统、客户支持、数据分析、内容生产等环节通常都已经接入大模型。以研发团队为例开发者可能不再逐行手写所有代码而是先让 AI 生成实现思路和代码骨架再由人工 review 和修改。客服团队也可能不再逐条回复消息而是由 AI 先对用户问题进行分类、检索知识库、生成草稿再由人工确认后发送。在这种背景下“75% 的工作被自动化”并不是某个官方机构的统计而是不少 AI 原生团队在对外分享时给出的经验值。它背后的含义是在一个成熟的人机协作流程中绝大多数高频、重复、有明确规则的任务都可以交给自动化完成剩下的 25%恰恰是需要判断力、责任感和创造力的事情。1.2 75% 不是绝对指标而是一种工程取舍不同业务形态下自动化比例差异很大。一个以内容生成和数据分析为主的公司自动化率可能超过 90%一个涉及医疗、金融、法律等强监管业务的公司自动化率可能只有 50%因为每一步都需要留痕和人工审核。所以在看到“75%”这个数字时不建议把它当成一个必须达成的 KPI而应该把它理解为一种工程取舍的结果。团队在搭建 AI 原生系统时会不断问自己三个问题这个任务是否有明确的输入和输出这个任务失败后造成的损失是否可以接受这个任务是否需要某个角色来承担最终责任如果三个问题答案都是“是”就可以考虑优先自动化如果其中任何一个回答是否定就值得保留人工环节。真正成熟的做法不是追求 100% 自动化而是找到一条自动化和人工之间的最优分界线既保证效率又守住质量和安全底线。1.3 为什么要特别关注剩下的 25%很多团队在刚开始做 AI 改造时会把注意力全部放在“如何提升自动化比例”上却忽略了剩下的 25% 才是决定系统能不能长期稳定运行的关键。你可能会发现AI 自动分类工单偶尔会出错AI 生成的代码偶尔会引入安全漏洞AI 客服的情绪判断偶尔会偏离用户预期。这些偶发问题如果没有人兜底就会逐步积累成系统性风险。因此研究剩下的 25%本质上是在研究“自动化系统的边界和治理”。这 25% 不是自动化的失败而是让自动化变得可信的必要成本。一个有经验的技术负责人在规划 AI 原生系统时往往先设计人工介入点和反馈回路再倒推哪些环节可以放心交给自动化而不是先做自动化再补丁式地加人工。2. 哪些工作更容易进入自动化的 75%2.1 适合自动化的工作特征并不是所有工作都适合交给大模型和 AI Agent。从工程经验来看适合自动化的任务通常具备以下特征高频重复每天都会发生人工处理成本高。边界清晰输入是文本、数据或结构化信息输出可以被校验。可标准化有明确的处理规则或模板不需要太多创造性判断。失败成本低即使出错能在后续环节被修正或拦截。反过来那些需要跨部门沟通、需要在模糊信息中做决策、需要承担法律或财务责任的任务则更适合留在人工环节。举例来说给一封用户工单自动打上“技术故障”标签是一个典型的可自动化任务但决定是否给客户赔偿通常需要人工确认。2.2 一张从研发到运营的任务拆分表工作场景可自动化的任务更适合人工的任务研发AI 生成代码、单元测试、变更摘要、代码 review 初筛技术方案评审、发布审批、重大故障决策客服自动分类、知识库检索、草稿回复、满意度预测高危客户安抚、投诉定责、赔偿方案运营内容生成、标签提取、数据报表、异常告警活动策略制定、品牌风险判断数据数据清洗、指标计算、异常检测业务口径确认、数据合规审核人事简历初筛、面试纪要、入职问答薪资谈判、离职面谈、晋升评审这张表不是绝对的但它展示了一个重要原则自动化的优先级应该按照“规则清晰、频率高、风险低”来排序。很多团队在初期容易踩的坑是把高风险任务直接交给 AI 全自动处理等到出现问题后再回头补救这样反而会增加系统的不确定性。2.3 AI 编程与 AI Agent 在其中的位置在 AI 原生企业的研发链路中AI 编程是自动化率最直观的体现。代码生成、接口文档生成、测试用例生成、提交信息整理都属于典型的 75% 自动化范围。AI Agent 则更进一步它能把“写代码”和“执行命令”连接起来例如自动拉取代码、运行测试、分析失败日志、修复简单问题并重新跑测试。但 AI Agent 的能力并不是无限的。当前常见的问题是Agent 在遇到多个依赖项报错时可能会陷入“修一个错引出另一个错”的循环甚至产生 AI 幻觉把不存在的配置项当成修复方案。所以在实际项目中我会建议把 AI Agent 的自动执行范围限制在低风险操作例如生成 PR 草稿、运行静态检查、自动添加单元测试而涉及合并到主干、修改权限、操作生产数据等动作必须经过人工确认。这既是对业务负责也是对 AI 系统的稳定性负责。3. 剩余 25% 为什么必须由人处理3.1 模糊目标与复杂语境同样一句“这个功能太慢了”不同用户背后可能有完全不同的期待。有人希望提升页面加载速度有人希望缩短订单处理时间还有人只是想抱怨网络环境差。大模型虽然能理解自然语言但在面对多义、省略、反讽或隐含需求时仍然可能出现判断偏差。自动化系统适合处理“目标明确”的任务而模糊目标需要人来澄清。例如 AI 可以快速生成一版功能说明文档但产品负责人需要结合业务背景和用户反馈判断这个说明是否准确把握了真实需求。这 25% 的人工工作本质是在为机器补充“语境”。3.2 决策责任与风险兜底大模型可以给出建议但不能承担法律责任也无法在处罚结果出现后向客户道歉。企业在做高风险决策时需要有一个自然人负责这在金融、医疗、法律等行业尤其严格。贷款审批可以做成 90% 自动化但最终的授信额度往往需要风险官确认医疗影像可以被 AI 初步识别但诊断结论必须由医生签字。因此决策责任是人工环节存在的最强理由。一个 AI 原生系统如果没有设计“责任人”节点那么在出问题时就会陷入“不知道找谁”的窘境。设计人工介入点不是对 AI 能力的不信任而是负责任地使用技术。3.3 安全合规与数据边界大模型在处理数据时通常会把数据发送到模型服务端。如果企业处理的是客户隐私数据、核心业务代码或敏感日志就不能简单地把所有内容直接交给公有云大模型。常见的做法是数据脱敏用规则或模型把身份证号、手机号、密钥等字段替换为占位符。本地化部署在私有化环境部署开源模型让数据不出内网。分级访问只有经过授权的人工角色能看到明文敏感信息AI 只接受到脱敏后的内容。这些合规要求决定了某些环节必须保留人工处理能力。当自动化链路遇到涉敏数据时系统需要自动停下来转交给人工处理而不是绕过限制强行调用模型。3.4 AI 幻觉是 25% 的最直接来源AI 幻觉指的是模型生成看起来合理、但实际上与事实不符的内容。这是大模型在生成式任务中的一个固有风险尤其在模型缺乏相关知识或上下文不足时更容易出现。例如让 AI 总结一段模糊日志它可能会补充出日志里根本不存在的错误原因让 AI 生成代码修复方案它可能会建议一个已经废弃的 API。应对 AI 幻觉不能只靠“提示词写严一点”而需要工程手段兜底。常见做法包括让 AI 在不确定时直接说“不确定”而不是强行生成答案为生成结果增加引用来源方便人工核对对生成内容设置置信度阈值低置信度样本自动进入人工队列。因此从工程角度讲AI 幻觉不是“偶尔出现的 bug”而是 25% 人工兜底设计中最常见、最直接的输入来源。4. 最小落地示例自动分流 人工复核闭环4.1 流程设计我们先画出一个典型的人机协作流程它适合工单分类、客服回复审核、内容审核等场景。用户提交原始任务例如一条工单、一段文本、一份变更日志。AI 对任务进行自动分析输出结构化结果同时给出置信度。系统判断置信度置信度高于阈值直接进入自动处理。置信度低于阈值转人工复核。置信度极低直接标记为异常要求补充信息。人工复核后如果认为 AI 判断有误可以修正结果并将修正内容写入反馈库。反馈库中的修正数据定期被用来优化提示词、微调模型或更新规则。这个流程看起来不复杂但它同时在处理“自动化”和“人工兜底”两件事。后面我们用 Python 代码实现一个简化版本重点演示分流逻辑而不是真实的大模型调用细节。4.2 项目结构与配置为了方便演示我们建立一个简单的项目目录ai-workflow/ ├── config.yaml ├── main.py ├── requirements.txt └── README.mdrequirements.txt内容如下openai pyyaml这里使用 OpenAI 风格的 Python SDK 作为示例实际项目请以你所使用的大模型官方 SDK 为准。配置文件config.yaml用来管理关键参数# 文件路径ai-workflow/config.yaml llm: api_key_env: LLM_API_KEY base_url_env: LLM_BASE_URL model: gpt-4o-mini temperature: 0.1 routing: auto_handle_threshold: 0.85 human_review_threshold: 0.6 reject_threshold: 0.5 sensitive_fields: - username - phone - id_card把阈值放到配置文件里能让我们在不改代码的情况下调整路由策略。例如上线初期可以把auto_handle_threshold调高到 0.95让更多任务进入人工复核等系统评估稳定后再逐步降低阈值提高自动化比例。sensitive_fields用来提示我们在真实环境中需要对哪些字段做脱敏处理。4.3 核心代码实现在main.py中我们假设已经有一个函数analyze_ticket会调用大模型返回工单的分类、紧急程度、摘要和置信度。这里为了便于运行我们先用一个模拟函数代替真正的模型调用重点展示分流和人工复核逻辑。# 文件路径ai-workflow/main.py # 演示思路调用大模型对工单做自动分析并根据置信度分流到自动处理或人工复核。 # 注意生产环境请先做数据脱敏并遵守合规要求。 import json import os import yaml def load_config(): 加载配置文件并把环境变量配置转换为运行时配置。 with open(config.yaml, r, encodingutf-8) as f: config yaml.safe_load(f) llm config[llm] llm[api_key] os.getenv(llm[api_key_env]) llm[base_url] os.getenv(llm[base_url_env]) config[llm] llm return config def analyze_ticket_by_llm(ticket_text: str, config: dict): 实际项目中这里会调用真实的大模型接口。 返回结构固定为 { category: 故障恢复, priority: P1, summary: 用户无法登录系统, confidence: 0.92, reason: 关键信息完整匹配历史故障模板 } # 模拟大模型返回结果实际使用时替换为真实调用 if 无法登录 in ticket_text: return { category: 故障恢复, priority: P1, summary: 用户无法登录系统, confidence: 0.92, reason: 关键信息完整匹配历史故障模板, } return { category: 需求变更, priority: P2, summary: 用户希望增加批量导入功能, confidence: 0.71, reason: 意图较清晰但缺少使用场景说明, } def route_ticket(ticket_text: str, config: dict): 根据置信度执行路由策略。 result analyze_ticket_by_llm(ticket_text, config) confidence result.get(confidence, 0) auto_threshold config[routing][auto_handle_threshold] human_threshold config[routing][human_review_threshold] reject_threshold config[routing][reject_threshold] if confidence auto_threshold: auto_handle(result) elif confidence reject_threshold: send_to_human(ticket_text, result) else: reject_and_ask_for_more_info(ticket_text, result) def auto_handle(result: dict): 自动化处理的简化逻辑。 # 实际项目里这里可能调用工单系统的 API自动打标签、创建任务、发送通知。 print(自动执行直接根据 AI 结果创建工单) print(f分类{result[category]} 紧急程度{result[priority]}) print(f摘要{result[summary]}) print(结果自动处理完成\n) def send_to_human(ticket_text: str, result: dict): 人工复核的简化逻辑。 print(转人工复核AI 置信度不够需要人工确认) print(f原始工单{ticket_text}) print(fAI 候选结果{json.dumps(result, ensure_asciiFalse)}) print(结果已进入人工队列等待处理\n) def reject_and_ask_for_more_info(ticket_text: str, result: dict): 置信度极低时拒绝自动处理并要求补充信息。 print(拒绝处理信息不足需要用户补充说明) print(f原始工单{ticket_text}) print(fAI 判断{result.get(reason, 未知原因)}) print(结果已请求用户补充信息\n) def main(): config load_config() sample_ticket 我刚刚无法登录系统点击登录按钮没有反应请尽快处理。 route_ticket(sample_ticket, config) second_ticket 希望下次版本更新时支持批量导入用户数据。 route_ticket(second_ticket, config) if __name__ __main__: main()这段代码的核心在于route_ticket函数。它把大模型返回的置信度作为核心信号分别对应三种处理策略自动处理、人工复核、拒绝处理。这样做的好处是即使大模型的判断偶尔不准系统也不会把所有错误结果直接发布出去而是会在关键节点引入人工环节。参考真实的调用代码如下注意不要在生产环境中把敏感数据直接传给模型# 以 OpenAI Python SDK 风格为例实际使用时需要按模型厂商要求调整。 from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL), ) def analyze_ticket_by_llm(ticket_text: str, config: dict): prompt f 你是一个工单质量分析助手。请对下面的工单执行三件事 1. 分类技术支持 / 故障恢复 / 需求变更 / 投诉建议 2. 紧急程度P0 / P1 / P2 3. 一句话摘要 请以 JSON 格式返回并给出 0 到 1 的置信度。 工单内容 {ticket_text} resp client.chat.completions.create( modelconfig[llm][model], messages[{role: user, content: prompt}], temperatureconfig[llm][temperature], ) content resp.choices[0].message.content return json.loads(content)4.4 运行与验证在项目目录下先导出环境变量再运行main.pycd ai-workflow export LLM_API_KEYyour-api-key export LLM_BASE_URLhttps://api.example.com/v1 python main.py如果使用模拟函数预期输出大致如下自动执行直接根据 AI 结果创建工单 分类故障恢复 紧急程度P1 摘要用户无法登录系统 结果自动处理完成 转人工复核AI 置信度不够需要人工确认 原始工单希望下次版本更新时支持批量导入用户数据。 AI 候选结果{category: 需求变更, priority: P2, summary: 用户希望增加批量导入功能, confidence: 0.71} 结果已进入人工队列等待处理第一条工单因为信息完整、置信度高被自动处理第二条工单因为缺少使用场景说明置信度只有 0.71被转人工复核。这就是一个最简单的 75% 自动化 25% 人工兜底的落地闭环。4.5 这个示例揭示了什么这个示例展示了三个关键结论第一自动化的“边界”不是静态的。只要调整配置文件中的阈值就能改变自动处理和人工复核的比例。这是工程实践中最有价值的一点因为它让你在不确定模型能力时可以先用较保守的配置上线再通过数据观察来逐步放开。第二人工复核不是简单的“重新看一遍”。在真实系统中人工复核的结果应该被记录下来形成一个标注反馈库。当大量复核结果表明“AI 在某类问题上置信度虚高”时你就知道应该优化提示词、补充边界样例或者针对这类问题单独降低自动处理阈值。第三置信度本身也不是绝对可靠的。不同模型、不同提示词模板下置信度分布会不一样。因此在真正生产系统中除了依赖模型给出的置信度还要结合规则判断例如敏感词检测、长度异常检测、服务状态检测等。综合多个信号来路由会比只依赖大模型置信度更加稳定。5. 把 25% 变成产品能力人机协作的工程方法5.1 置信度分流让 AI 知道何时停下置信度分流是人机协作中最基础、最有效的手段。它的核心思想是让 AI 在处理任务时不仅输出结果还输出“我有多大把握”。当把握不足时就停下来把任务交给人工。在设计置信度分流时有几个细节需要注意。一是置信度阈值要与业务风险挂钩退款、删除操作等高危场景的置信度阈值应该更高。二是要为大模型设置“拒绝回答”的能力让模型在输入信息不足时明确输出“需要补充信息”而不是强行生成答案。三是对于模型给出的低置信度结果要保留原始上下文方便人工快速理解问题。5.2 建立人工决策的反馈回路人工复核如果只是单向兜底时间长了会变成团队的负担。正确做法是让每一次人工复核都产生价值把修正结果沉淀为系统资产。一个通用做法是建立反馈表至少包含以下字段字段说明原始输入用户提交的文本或任务描述AI 输出模型给出的分类、摘要、置信度人工结果人工最终确认或修正后的结果修改原因为什么机器判断不正确处理人责任人或处理角色处理时间用于统计效率有了这批反馈数据你就可以定期分析 AI 的错误模式。比如发现“某个分类的置信度普遍偏高”那么大概率是提示词里对分类的定义不够清晰或者训练数据存在偏差。把这些发现反哺到提示词模板、示例优化甚至模型微调中人机协作的效果就会越来越好。5.3 AI 产品经理的新职责在很多 AI 原生企业中产品经理的角色也在发生变化。传统产品经理更关注功能体验和需求排期而 AI 产品经理需要额外关注“人类介入点”的设计什么时候询问用户、什么时候请求确认、什么时候直接拒绝。把这个职责落到具体工作中可以表现为梳理业务链路中的风险点标注必须人工确认的动作。为人工审核设计队列、SLA 和操作界面让审核者能快速做出判断。建立自动化系统的灰度发布机制先在小流量下运行再逐步扩大自动化范围。用数据衡量自动化和人工协作的效果而不是只看自动化率。换句话说剩下的 25% 不是“产品没做好才需要人”而是产品设计的一部分。一个成熟的人机协作产品应该在界面设计上主动引导用户从“AI 生成结果”进入“人工确认结果”的流程而不是让用户自己去猜测这个 AI 是否可信。6. 常见问题与排查思路6.1 高频问题速查表在实际项目中团队最常见的几个问题如下问题现象常见原因解决思路AI 自动分类结果频繁出错提示词边界模糊模型缺少业务示例补充 few-shot 示例明确分类定义对新分类先人工审核AI Agent 长时间不结束缺少最大轮次、超时时间、成本上限在 Agent 外层增加轮次限制和超时熔断人工复核工作量过大置信度阈值过低导致很多简单任务也转人工调高自动处理阈值或对低风险任务启用快速自动处理敏感数据被发送给外部模型未做脱敏或者流程设计里没有过滤敏感字段增加脱敏层配置敏感字段拦截规则模型升级后效果明显变差缺少模型回归评估直接切换了版本建立离线评测集上线前做效果对比人工修正结果没有沉淀缺少反馈表修正动作没有保存统一记录人工修正记录定期分析6.2 一个 Agent 循环不终止的排查案例之前调试一个自动修复工单的 Agent 时遇到过一个问题它反复尝试同一个错误的 API 参数一直报错但一直重试。表面看是模型没有理解错误信息实际上问题出在 Agent 的“重试策略”上。排查步骤可以按以下顺序进行查看 Agent 执行日志确认它每次重试是否更换了参数。检查 Agent 的最大重试次数和超时时间配置。检查模型在收到错误信息后是否具备“决定放弃当前方案”的能力。在提示词中增加明确的“终止条件”例如让 Agent 在连续两次失败后必须向用户求助。增加预算限制设置单次任务的最大 token 消耗超过后强制中断。这个案例说明很多 AI 原生系统中的问题根因并不在模型本身而在于工程上缺少保护机制。给 AI 系统加上边界条件和给业务代码做参数校验、异常捕获是同样重要的事情。7. 最佳实践与工程建议7.1 自动化接入前的设计清单在把一个流程改造为 AI 自动化之前建议先完成以下设计画出原始业务流程图标记每个节点的输入、输出、责任人和风险等级。明确哪些节点是“必须人工确认”的这类节点不要一刀切自动化。为每个 AI 节点设计输入输出格式校验异常数据优先转人工。定义灰度策略先让 AI 在小范围业务上运行再用数据证明可靠性。为失败场景设计降级方案例如 AI 服务不可用时直接回退到全人工流程。这组清单的价值在于它迫使团队在写代码之前思考自动化的边界。很多自动化项目失败不是因为模型能力不够而是因为流程设计阶段没有想清楚“什么情况必须让人介入”。7.2 可观测性与成本控制AI 原生系统最容易被忽略的是可观测性。传统系统关注 QPS、耗时、错误率AI 系统还需要额外关注 token 消耗、模型响应质量、置信度分布、幻觉发生频率等指标。建议为每个 AI 调用写入结构化日志至少包括trace_id方便串联一次任务的完整流程。输入摘要不记录敏感明文只记录长度、类型等元信息。模型名称和版本避免模型升级后无法追溯。输出内容保留模型返回的结构化结果。置信度用于统计阈值合理性和稳定性。耗时和成本为后续优化提供依据。成本控制方面建议为每个 Agent 任务设置 token 上限。不要在大循环里不断调用模型而是尽量通过提示词优化、缓存命中、小模型优先等方式降低成本。AI 原生企业的成本模型和传统 SaaS 不同模型调用费会随着业务增长非线性上升所以提前建立成本监控非常重要。7.3 安全、隐私与合规底线安全是 AI 原生系统绕不开的话题。在将数据接入大模型之前必须明确数据的密级和敏感字段。代码、工单、日志中可能包含密钥、数据库连接串、个人隐私信息直接传给外部模型服务不仅可能泄露数据也可能违反合规要求。一些可落地的措施包括所有接入大模型的数据必须先经过敏感信息扫描。对敏感字段做脱敏替换不要因为“内部系统”就放松要求。涉及生产环境变更的命令必须经过人工审批AI Agent 只能生成脚本不能直接执行。模型服务的访问密钥使用独立账号并配置最小权限不要在所有服务中复用同一个 token。保留系统操作的审计日志确保每一步自动化和人工动作都可追踪。如果你发现自己无法判断某些数据是否可以传给外部模型最稳妥的做法是在部署阶段分离网络环境或者在本地私有化部署一个模型服务从物理层面隔绝数据外流风险。8. 总结把 25% 设计成接口而不是例外如果现在有人问我AI 原生企业里那 25% 到底该由谁负责我的回答是它应该被设计成一个接口而不是一个例外。接口的输入是置信度低、风险高、意图模糊的任务接口的输出是决策、修正、标注和规则。自动化负责顺畅地跑完 75%人负责在剩下的 25% 处守住质量和底线。只要这条闭环还在不断回流数据系统就会越来越可靠。与其盯着自动化率这个数字不如先画出你业务链路里的人工介入点再为这些介入点设计清晰的触发条件、处理流程和反馈回路这比追求 100% 自动化更值得投入精力。