做智能体机甲驾驶员 ——《可托付智能》第6章《专家不会消失，只会换位置》

原创

走向未来

发布于 2026-09-21 21:26:34

590

第 6 章专家不会消失，只会换位置

1. 医生的工作，远不止给出诊断

设想一位医生接诊了病情复杂的患者。病人的主诉、既往病史、化验和影像结果、正在服用的药物，以及其他医院的就诊记录，散落在不同系统里。有的记录来自几年前，有的刚刚更新，还有些信息只有病人和家属知道。医生要弄清的，不只是哪个数值超出了正常范围，还包括异常是什么时候出现的，几份记录是否相互矛盾，病人眼下最需要解决的究竟是什么。

AI 可以先把这些材料按时间整理，标出明显变化和互相冲突之处，列出需要补问的问题，也可以提出几种供医生核查的解释。不过，一份写得完整的病情摘要，仍可能把“没有查到过敏记录”写成“没有过敏史”，把已经停用的药物列入当前用药。前一种写法说明资料缺失，后一种却把缺失当成了事实。医生若只看摘要，不回查关键原文，整理材料时的一处疏漏就可能影响后续判断。

因此，系统交给医生的，不应只有一段通顺的结论。重要事实要能找到出处，过往记录与当前情况要分清，尚未核实的信息也要保留。医生据此补充问诊、核对检查，结合患者的意愿和实际条件作出决定。AI 帮助医生更快掌握情况，也可能提醒他注意原先忽略的线索；医生则要判断这些线索是否适用于眼前的病人。

专业工作的变化，正发生在这样的细节里。检索资料、比较文本、撰写初稿，过去占用了专家大量时间。如今，这些工作有一部分可以交给机器，某些分析和推理任务也已能由模型完成。专家需要重新安排精力：哪些结果可以直接采用，哪些需要核实，什么时候应当改变原有方案，又该怎样把这些要求落实到日常工作中。

能力与权限应当分别判断。一个系统即使能提出很好的治疗建议，也不意味着它在具体医疗机构中获准独立执行；反过来，低风险、规则明确、经过充分验证的常规步骤，也未必需要专家逐项签字。分工要看任务的实际表现、出错后果和既有授权，不能只凭“这是 AI 做的”就一概放行或一概拦住。

本章所说的“专家不会消失”，并不是保证每一种岗位、每一份工作都能保留。部分任务会被替代，岗位数量和培养方式也可能改变。需要继续存在的是专业能力：有人懂得怎样把问题问清楚，怎样判断工作是否合格，怎样处理例外，并且有权纠正错误、对决定负责。这些工作的重要性，不会随着答案变得便宜而降低。

2. 有了 AI 帮忙，不等于有了专业眼光

一名律师可以借助 AI 迅速比较两版合同；一位风控分析师可以从大量交易中筛出需要核查的记录；一名工程师可以先查看设备日志中反复出现的异常。原本来不及细看的材料，现在有了初步整理；原本想不到的方案，也可能得到提示。对经验不足的人来说，这降低了上手的难度；对熟悉业务的人来说，则有机会把工作做得更细。

但能拿出一份像样的成果，不等于已经知道它为什么成立。合同助手发现责任限制条款偏离了公司模板，律师还要了解：这次交易有什么特殊约定，其他条款是否已经分担了相应风险，公司是否愿意接受这种安排。模型若能取得这些背景，也可以参与比较和分析。问题在于，使用者要知道哪些背景不能缺，哪些说法尚未证实，哪些条件变化后，原先的建议就不再适用。

2026 年 3 月，哈佛商学院介绍的一项跨岗位研究提供了一个具体例子。在同一家企业的写作任务中，借助 AI，营销人员的成稿质量接近专门撰写此类文章的员工，技术岗位人员则仍有差距。参与者原有的相关知识和技能，影响了他们使用 AI 的效果。这项研究针对特定企业、任务和当时使用的工具，不能据此断言新手永远追不上专家；它提醒我们，同样的工具，交给不同基础的人，未必产生同样的结果。

专业眼光也不是说不清的直觉。它往往体现在几个朴素的问题上：眼下要解决的是什么？这份资料是否适用于当前对象？有没有足以推翻结论的证据？如果判断错了，损失有多大，还能不能补救？经验的作用，在于让人知道什么时候必须追问，什么时候已有足够依据，不必再无休止地查下去。

这也是专家参与大模型应用时容易被忽略的一项工作：决定系统此刻需要看什么。把全部档案塞给模型，并不保证它能抓住关键。审阅一份合同，可能首先需要的是现行模板、此次交易的特殊约定和相关审批记录，而不是公司历年来的所有合同。所谓“上下文工程”，用在这里，就是把任务需要的资料、规则和当前进展组织好，让系统在需要时能够查到。Anthropic 在 2025 年的相关实践总结中，已把资料取舍和持续更新作为智能体设计的重要工作；这项工作仍需要熟悉业务的人参与。

复核也要找对对象。模型列出了一条引用，要看原文是否真能支持结论；写出了一串计算步骤，要核对数据和结果；声称已经办妥某件事，要查看业务系统里的实际记录。一段解释再有条理，也不能代替这些检查。让另一个模型提出异议可以帮助发现问题，但几个模型意见一致，并不等于已经取得了独立证据。

人的意见同样需要接受检验。专家可能沿用过时的经验，也可能先入为主。条件允许时，可以让复核者先阅读关键材料、形成初步判断，再与 AI 的建议比较，减少被第一份答案带着走的机会。人机协作应当让双方的疏漏更容易被发现，也让结论有更充分的依据。

3. 把经验讲清楚，还要让它经得起检验

许多重要经验并没有写进手册。资深客服知道哪种投诉需要尽快处理，老工程师知道哪些异常不能等到下一次例行检修，经验丰富的项目经理知道什么时候应当重新确认需求。这些人未必能立即讲出一套完整方法，却常能从一句话、一处变化或一份缺失的材料中发现问题。

要让这些经验帮助更多人，也帮助系统做事，可以先回看具体案例。上一次为什么转交主管？当时多核实了哪项事实？少看哪份材料就可能作出错误决定？同样的处理办法，换到另一类客户或设备上是否还合适？比起笼统地要求 AI “像资深专家一样思考”，把这些问题逐一说明，更容易形成可执行、可检查的工作要求。

例如，一家企业准备让智能体协助处理售后退款。专家不能只写“重视客户体验”，还要与业务和技术人员一起说明：订单状态从哪里查询，哪些事实必须核实，什么条件下可以按常规办理，哪些争议需要转交，谁有权批准例外。退款额度和执行权限要由业务系统实际限制；客户上传的附件只是待核查的材料，其中即使写着“主管已同意”，也不能替代正式审批。

这些要求还应变成一组测试案例。其中既要有应当退款的情形，也要有不符合条件的情形；既要检查系统能否识别争议，也要检查它是否把普通申请一律推给人工。材料缺失、记录冲突、接口暂时不可用，以及同一申请被重复提交，都值得纳入测试。专家的经验由此有了具体用途：帮助团队发现哪些情况最容易出错，怎样才算处理得当。

2026 年 1 月，Anthropic 发布的智能体评估实践强调，要区分系统的回答、执行过程和最终结果。套到退款案例中，“已为您办理”只是一句话，订单状态、退款记录和实际金额才是需要核验的结果。对开放性的答复，可以借助模型初步评分，再由专家校准；对金额、权限和是否重复执行等明确事项，则应尽量直接检查。还要反复运行案例，了解系统能否稳定做好。

专业人员之间有分歧时，也不能把某一位专家的习惯直接写成唯一标准。分歧可能来自资料不全、规则含糊，也可能是确实存在几种合理方案。前两类问题需要补资料、改规则；后一类则应说明可接受的范围和取舍依据。评价标准应当容许合理的不同做法，同时守住不能遗漏的事实和不能违反的要求。

纠正一次错误之后，还要找到应该修改的地方。资料过期，就更新资料；系统取错了订单，就修查询和核对步骤；权限设置过宽，就调整权限；标准本身有问题，就重新讨论标准。不能每次出错都只在提示词末尾补一句“请务必注意”。这样的补丁多了，指令之间还可能互相冲突。

人改过一次，并不意味着系统以后就能做对。一次对话里更正的内容，下一次未必还在；存进记忆或案例库，也不代表它适用于所有业务。团队需要记录修改理由、适用范围和版本，经过复核后更新相应资料、规则或工具，再用保留的测试案例检查：新问题是否解决，原本做对的事情有没有做错。涉及真实客户或患者的案例，还应按资料使用权限和保留要求处理。

专家由此多了一项长期职责：把经验整理成别人能学、系统能用、结果能检验的工作方法。他不必把每个念头都写成规则，但需要讲清楚哪些可以照章办理，哪些必须另作判断。

4. 为什么个人变快了，团队却未必省事

法务用 AI 起草审阅意见，几分钟就得到一份初稿。可业务部门不知道哪些问题必须回复，采购不清楚条款改动会影响哪张订单，几个部门手中又各有一份合同版本。初稿出来得越快，待协调的问题反而积得越多。律师写得快了，合同却没有更早签完。

这种情况并不难理解。一项工作要经过多个环节，最先加速的环节未必是原来最慢的地方。材料起草省下半小时，如果随后多出一小时核验和返工，总耗时就增加了。个人感受到的便利是真实的，组织是否因此受益，却要算完整笔账。

经济学中有一个相关概念，叫“生产率 J 曲线”。布林约尔松、罗克和赛弗森的研究指出，新技术往往需要配套的流程、培训和组织投入。这些投入会形成有价值的无形资产，却不容易在当期产出统计中得到充分体现，因此早期测得的生产率可能偏低。这个概念既涉及投入与收益的时间差，也涉及怎样衡量产出，并不意味着早期投入必然换来日后的收益。

回到企业，专家整理一套可靠的测试案例，短期内可能少处理了几份合同，却为日后的稳定运行打下了基础。但并非所有新增工作都是值得的投入。反复改错、重复录入、无人接手的异常，也会耗费大量时间。管理者需要分清：哪些工作正在形成可复用的方法，哪些只是系统设计不当造成的额外负担。

要准确算出 AI 究竟提高了多少效率，并不容易。METR 在 2026 年 2 月的实验设计更新中说明，一些开发者不愿参加可能被要求停用 AI 的实验，另一些人会选择性地提交任务；多个智能体同时工作，也使工时更难记录。这些因素妨碍了对提速幅度的可靠估计。因此，几份使用感受、一组旧模型的实验数据，或一次效果突出的演示，都不足以说明当前某个团队究竟能节省多少成本。

实际试点可以从一种范围明确的任务开始。先记录原流程的交付质量、总耗时和返工情况，再在相近难度的任务上比较。条件允许时，保留同期对照，避免把业务淡季或任务变简单误当成技术收益。成本应包括模型和工具费用、人工复核、等待与补救；质量则要分任务类型看，尤其留意少见但后果严重的错误。

上线也可以分步进行。先让系统处理历史案例，再让它根据真实业务生成建议供人比较；确认表现符合要求后，才开放有限的执行权限。这里先做建议的目的，是了解它在真实资料和流程中会怎样表现，不能把“建议正确”直接当成“执行可靠”。正式接入工具后，还要检查动作是否成功、失败后如何处理，并事先约定扩大范围、缩小范围或暂停的条件。

也不必一开始就安排多个智能体。Google Research 在 2026 年 1 月发表的研究介绍表明，在所测试的任务中，多智能体协作对可以并行拆分的工作有帮助，却可能拖累严格依赖前后步骤的任务。企业据此应当先试清楚：普通程序、固定流程或一个智能体，能否已经满足要求；增加协作环节所带来的收益，是否足以抵消沟通和核验的成本。

专家在这一阶段的作用，是帮助团队识别真正耗时、容易出错的地方。有时值得做的是补齐一份资料，有时是取消一次重复审批，有时才是换模型。只有后续的人少找一次文件、少核对一次版本、少返工一次，前面省下的时间才算真正留下来。

5. 别把“有人审核”当成万无一失

客服机器人答了几轮，仍没解决问题，客户最后还得向人工重新讲一遍；合同助手漏掉关键条款，法务临近签约才发现，只好连夜补救；自动分流把复杂申请送错部门，工单在几个队列之间来回转。系统报表上的“自动完成率”或许很好看，实际工作却落到了客户、一线员工和后续部门身上。

这类“伪自动化”并不一定意味着系统什么都没做，而是它做完的那一小段，被当成了整件事已经办好。检查成效时，应当继续往后看：客户是否再次联系，已经关闭的工单是否重开，人工需要补做多少工作，重要事项是否仍有遗漏。系统说“已转人工”也不够，还要有人接单、能看到已有材料，并在规定时间内处理。

即使设了审核岗位，也不等于风险已经受控。一个人面对几百份没有出处的结论，既没时间核实，也无权叫停，签字很容易变成例行手续。人工复核要有用，至少需要看得见依据，拿得到原始材料，有足够时间处理疑点，也能拒绝、退回或转交。安排审核的人数和时间，同样应当算进系统的运行成本。

复核的多少和时机要与风险相称。已经验证的低风险常规事项，可以自动处理并抽查；材料矛盾、适用条件不明、超出授权或后果重大的事项，则应按制度在执行前交由相应人员判断。转交条件不宜只看模型自报的“把握有多大”，还要结合资料是否齐全、规则是否满足，以及系统在同类任务中的实际表现。频繁弹出无关紧要的确认框，会消耗人的注意力。Anthropic 在 2026 年 4 月的可信智能体实践中也讨论了这种矛盾：既要让人保有控制权，也要避免过多打断使确认失去意义。

更长远的问题，是团队是否还在培养能做这项审核的人。2026 年 1 月，Anthropic 公布了一项涉及 52 名、以初级工程师为主的随机对照实验。参与者学习一个陌生的编程库后，使用 AI 的组在随后的测验中平均得分为 50%，未使用组为 67%；任务耗时的差异没有达到统计学上的显著水平。这是小样本、短期学习实验，不能据此认定 AI 会使所有人的技能长期退化，但它说明了一件值得重视的事：任务完成了，并不代表做任务的人已经学会。

这对带教方式提出了具体要求。新人可以用 AI 解释概念、寻找线索，也应有机会在适当的练习中先独立判断，再对照结果，亲自查清一处错误。资深人员不能只改好答案，还要说明为什么改、什么条件下可以采用另一种做法。团队也应练习在系统不可用、资料冲突或异常集中出现时接手工作。需要保留的是理解关键问题和发现错误的能力，而不是为了练习继续做所有重复劳动。

绩效要求也要跟着调整。如果组织只奖励处理数量，却不给核验、带教和复盘留时间，员工很难一边追求最快交付，一边保持独立判断。管理者应当同时看两类结果：眼前的事情是否做得更好，团队今后是否仍有人能够看出哪里不对。

6. 专家的新职责，贯穿工作的始终

把前面的变化合起来看，专家的职责正在向工作的前后两端延伸。开始之前，要说清目标、必要条件和合格标准；进行之中，要核实相互冲突的资料，处理规则未能涵盖的情况，参与重要决策；完成之后，要检查实际结果，找出反复出错的原因，推动改进。人工参与的价值，要看这些工作是否有效，不能只数审核按钮被点了多少次。

2026 年 2 月，OpenAI 公布的一项内部软件开发实践提供了具体参照。团队让智能体承担代码编写，工程师则着重明确需求、组织可查阅的项目资料，并建立测试和反馈机制。报告把人的工作描述为设计好智能体做事的环境。这是特定团队的实践，不能直接推广为所有行业的人员配置方案，但它展示了一种变化：专家可以通过改进工作条件和检查方法，影响系统持续产出的质量。

这不意味着专家从此只要在项目启动时提一次意见。模型会更新，资料会过期，业务条件也会变化。原来可靠的做法，需要在变更后重新检查；此前没有遇到的情况，需要补充进案例和标准。专家的参与应有明确安排，包括哪些变更需要复核、谁负责疑难问题、何时回看运行结果，而不是等事故发生后再临时找人。

责任也不能全压在最后签字的人身上。业务负责人明确目标和可以接受的风险，领域专家制定专业标准，技术团队保障资料更新、工具运行和权限控制，风险或合规人员核查是否符合相关要求。这些职责可能由同一人兼任，也可能分属不同团队，但出了问题，要能找到有能力、有权限处理的人。

专家本身也需要学习新的工作方法。除了熟悉本行，他还要能看懂系统查了什么、实际做了什么，能够区分模型判断错误、资料错误和工具执行失败。与此同时，组织应当把带教、制定标准、整理案例和复盘安排进正式工作，而不是把它们都当成忙完业务之后的额外任务。否则，最有经验的人越忙，团队越难把他的经验用到更多地方。

最终留在组织里的，是一套不断经受检验的共同做法：哪些资料可以采用，什么结果算合格，遇到例外找谁，发现错误怎样纠正，新人怎样学会独立工作。这也是上一章所说的“智能资本”的一部分。它来自专家、技术人员和业务人员的持续合作，无法仅靠购买模型获得。

专家会少做一些过去必须亲手做的事，也会承担一些过去没有的职责。职业价值不只取决于自己能答出多少问题，还取决于能否帮助整个团队把事情做对，并培养出下一批有能力接手的人。