Google 的 AI 专业能力研究：新用户引导该教会用户怎样判断

10 月 7 日，Google Research 公开解读了一项持续三个月、面向专利律师的实验：AI 辅助下的工作质量提高了，但离开 AI 后的专业判断能力，并没有在所有人身上同步提高。相关 NBER 工作论文于 9 月发布，本周的新进展是研究团队的公开讨论，而不是刚刚完成了一次新实验。Google 的研究解读提醒产品创始人区分两件事：帮助用户拿到一个结果，与帮助用户理解一项决定，衡量的是不同成果。

如果你正在开发 AI 客服、方案起草工具、研究工作台或应用搭建产品，新用户引导的数据面板大概会庆祝“第一次成功生成”。它能说明用户开始获得价值，却不能说明用户明天遇到错误前提时，会不会修改范围、纠正建议，或停止一项不合适的操作。

本文把这个问题转化为一份可执行的引导设计稿：先展示有用的结果，再让用户看见一个关键选择，在安全示例中练习纠正，并随时能够求助。你会得到一份可复用的设计表，以及不把每位客户都变成测试对象的评估方法。这些是产品建议，专利实验并未验证这套设计。本文也没有测量任何引导效果、留存变化或客户使用结果。

1. 先看清研究结果，别把它变成普遍警告

NBER 对这项研究的介绍指出，随机试验涉及美国十一家事务所的 133 名专利律师，成果由不知道分组情况的专业评审打分。AI 使用权限改善了辅助起草表现；三个月后，无 AI 的修改审查优势集中在资深律师身上。初级律师的平均表现没有改善，低分和较好分数都更多。这既不是“所有人能力下降”，也不是“新人无法通过 AI 学习”。

样本、职业、工具和观察时间都限制了结论的适用范围。审查专利与配置客服助手是两种任务。某个工作流程的实验，不能证明你的注册引导会让人产生依赖。可以借鉴的是把不同成果分开衡量的思路，之后还要研究自己的用户。

对 AI 产品，更有用的问题是：为了负责任地使用这个功能，用户需要做出什么判断？日程助手可能要求用户识别时区冲突；方案工具可能要求用户发现一项没有依据的功能承诺；应用搭建产品则可能要求用户识别预览中的客户记录只是示例数据。

先把这种判断说清楚，再写教程文案。否则，引导往往只会教最容易埋点的交互动作：点击“生成”。用户可以非常熟悉按钮，却仍然不会做产品留给他的关键决定。

还要区分工具质量与用户能力。如果模型准确率提高，用户需要纠正的次数减少，是合理的进步。不要为了显得产品“有教育价值”，人为制造错误或阻力。应该保证的是：剩下的关键选择有清楚的依据、可用的控制，以及能接手问题的人。

2. 产品承诺中，分清激活、可独立使用与学习

本文使用三个工作定义。激活，是用户获得第一次有用成果；可独立使用的准备程度，是用户能处理下一项真实任务中必须由他判断的问题；学习，是相关能力能够保持，或迁移到不完全相同的情境。这不是行业统一的认证标准。

它们分别回答不同问题：用户是否拿到了可用草稿？是否能识别没有依据的承诺？过一段时间遇到另一种请求时，是否还能运用同样的判断？一次“完成引导”事件回答不了全部问题。

即时价值仍值得保留。《Generative AI at Work》研究在客服工作中发现了生产率收益，经验较少的员工获益尤其明显，也提供了有关学习的提示性证据。它的场景和指标与专利试验不同。两项研究合起来，更不支持“AI 辅助一定培养能力”或“一定破坏能力”这样的简单说法。

营销承诺应该对应你真正提供的成果。“帮你完成第一份草稿”是交付承诺；“帮你更会判断哪些内容应该发出去”是能力承诺，需要额外证据。如果只测量了生成成功率，不要悄悄把它改写成教育效果。

准备程度也取决于角色。一线操作人员可能只需要识别可疑建议并转交；管理员需要制定政策并处理转交事项。操作人员不必理解模型训练，但必须知道哪个来源具有权威性，以及按钮究竟是发送消息，还是只保存草稿。

为每个角色写一句话：“在把这个功能用于真实工作之前，此人必须能够____。”空白处要填可观察的动作。“理解 AI”无法指导设计评审；“发送退款说明前，确认适用的政策日期”可以。

3. 找出顺利演示里被隐藏的决定

多数演示会主动消除不确定性：输入整齐、来源齐全、答案显而易见，示例即使出错也容易补救。这有助于展示价值，也容易遮住真实用户必须动用判断的地方。

逐步走一遍演示，问自己：什么信息会改变正确的下一步？缺失的需求？过期的来源？不在适用范围内的客户？语气自信、却漏掉关键限定的草稿？挑一个目标用户确实会遇到的问题。如果普通歧义已经解释了大量支持请求，就不必从夸张的对抗攻击开始。

哈佛商学院对“参差不齐的技术能力边界”的研究介绍强调，AI 的效果可能在同一工作流的不同任务之间发生变化。这支持逐项检查具体决定，而不是把整个岗位贴上“适合 AI”的标签。它并没有替你确定自己产品的边界。

把选中的决定拆成四个朴素问题：

• 哪条信息会改变答案？
• 用户在哪里能查看这条信息？
• 信息缺失时，用户能安全地做什么？
• 用户解决不了时，由谁接手？

任何一个问题没有答案，教程文字都补不上产品缺口。例如，告诉用户“核验来源”，但来源只有管理员能打开，没有帮助；告诉用户“找主管”，但产品没有交接入口，或主管看不到案件，也没有帮助。

围绕真实边界设计，包含权限与工作流程的限制。有时需要补一个来源面板；有时需要禁用发送按钮并解释原因；有时则应该修改产品承诺，把“自动执行”收窄为“提供草稿”。

4. 用安全的纠错示例，不做突然袭击

设想一个虚构产品 ReplyDesk，帮助一家小型软件公司的客服团队起草回复。这是设计场景，不是真实客户或经过测试的部署。

旧版引导让新人粘贴问题、生成答案，再把它发到沙盒收件箱。新版使用一位虚构客户询问套餐是否包含某项功能的案例。屏幕上的套餐记录，与生成的草稿相互矛盾。整个练习不涉及真实客户信息，也不发送真实消息。

流程先展示一个正确示例，让操作人员理解产品的价值。接着明确说明练习中有一处人为设置的不一致：“这份草稿里有一项承诺，发送前应该核验。”事先说明很重要。培训不应诱导用户犯一次真实错误，也不应靠隐蔽测试制造不信任。

操作人员打开套餐记录，找到没有依据的功能承诺，删除它，并保存修订后的草稿。最后再给一个不熟悉的案例：这次根本没有套餐记录。合理操作是索取信息或转交，而不是猜答案。存在的来源仍然可以查看；练习暂时不提供 AI 建议，却不会拿走判断所需的证据。

在开发自适应辅导之前，设计师可以先做一个静态练习页面。它只需要虚构记录、一份草稿、可编辑区域和明显的求助入口。纠正的范围要小，让用户看得懂为什么重要。不要把关键判断埋在一份布满无关错误的长文档里。

对应用搭建产品，可以使用类似场景：一个漂亮的客户目录，实际填的是示例数据。用户发现示例数据提示后，选择继续预览，而不是宣布已经正式上线。他练习的是产品判断，不是被迫调试陌生代码。

5. 分层提供帮助，同时让真实工作保持顺畅

练习可以逐步提供帮助：先显示相关来源，再指出冲突的句子，然后解释规则，最后展示修订示例。这是待验证的交互方案，应当结合用户研究评估，不能变成紧急工作中的强制障碍。

PNAS 的数学学习实验比较了普通 AI 界面与专门保护学习过程的辅导设计。普通界面改善了练习表现，却损害了随后无 AI 的表现；辅导设计大体缓解了这种损害，但没有证明无 AI 表现获得正向提升。这是学校实验，不是 SaaS 引导实验。它说明帮助方式值得认真设计，并不证明提示功能会改善你的激活或留存。

在 ReplyDesk 的练习中，第一层提示可以是“查看套餐记录”；下一层可以标出相关权益；最终示例解释为什么必须删除草稿里的无依据承诺。每层帮助都应该把动作与可核验事实联系起来。AI 生成的解释本身也可能错误，因此练习答案要以经过确认的来源为准维护。

进入真实工作后，不要让用户每次都解同一道练习题。证据查看和修改要快捷，用户仍应能要求完整草稿，超出角色能力的案件应能交接。练习模式和工作模式可以共用控制，但采用不同节奏。

资深用户看过关键边界后，可以跳过基础练习；新用户也应能返回示例而不丢失手头工作。需要无障碍形式或更多时间的人，应获得支持。写出一段漂亮解释的能力，并不等于识别错误套餐权益的能力。

6. 让判断真正能改变产品行为

用户发现问题，却无法修改或停止操作，并不能算真正掌握了控制权。新用户引导走到这里，已经成为产品功能要求。

微软的人机 AI 交互指南涵盖能力预期、纠正与关闭建议，以及变化通知。HAX Toolkit则帮助团队在用户旅程中安排这些设计实践。两者都没有保证某种界面能培养持久能力。

对 ReplyDesk，可用控制很具体：查看套餐记录、编辑草稿、选择索取信息、转交案件，以及明确区分保存和发送。每个控制都要有清楚的后果。如果“批准”既保存内部备注，又给客户发邮件，这个按钮名称就隐藏了一项关键动作。

不要让教程依赖用户真实账号没有的能力。能查看所有记录的沙盒管理员，并不能代表权限有限的操作人员。用目标角色完成练习，解释权限不足时应该怎么解决，同时避免暴露受限信息。

反馈应该针对决定，而不是评价人的性格。“当前套餐记录里没有这项权益，回复却承诺提供它”有帮助；“你不懂 AI”既不准确，也不可执行。如果来源本身存在歧义，应当接受有理由的转交，而不是要求用户给出唯一、肯定的答案。

修改控制还必须能保存结果。否则，用户可能学会在本地改文字，下游却继续使用原始草稿。检查练习中可见的动作，与动作完成后的状态是否一致。这是产品行为校验，与用户有没有学到东西是两件事。

7. 把这份引导设计表带到下一次产品评审

以下表格只针对一个功能和一个角色。它是一份建议的设计稿，不是 benchmark，例子也只是示意。

填完表后，按顺序画出页面：价值示例、明确说明的练习案例、证据查看、修改操作、反馈、缺失信息案例，以及返回工作。每一页都写明用户看到什么、能做什么、接下来发生什么。只有点击动作、没有结果说明的设计稿还不完整。

再写出用户研究同意说明或参与指引中的一句话：“我们在检查这个流程是否把关键决定讲清楚，不是在评估你的工作表现。”务必根据真实情境调整，不能做不实承诺。如果练习会影响某项重要功能的使用资格，需要另外说明，并提供支持或复核路径。

把这份表交给搭建工具或开发人员，比一句“做智能 onboarding”更明确。它描述了可以观察的行为，不限定前端框架，也不要求训练定制模型。团队可以据此估算工作量，并围绕同一个问题评审页面。

8. 观察下一次决定，但别急着宣称用户学会了

先邀请少量知情同意的参与者，用虚构案例做可用性研究。让他们走完流程，再遇到一个需要同类判断、但内容不同的案例。观察他们查看什么、采取什么动作，记录使用了哪一层帮助。看过完整解答才选对，与查看来源后自己选对，不是相同证据。

微软与卡内基梅隆大学的调查研究了知识工作者自报的批判性思考投入。对 AI 更有信心，与自报投入更少存在关联。这并不是对你产品用户能力的因果检验。它提示我们把实际动作与信心评分一起观察，不要把“我觉得准备好了”直接当成最终效果。

每次研究记录任务版本、角色、来源是否可用、最终动作、使用的帮助，以及参与者的解释或可访问的替代表达方式。使用虚构数据，只收集研究必要的信息，说明谁能访问、保存多久，并允许参与者拒绝录制。加入合理答案可能是“请补充信息”的模糊案例。有争议时请领域负责人判定，不要把生成练习的同一个 AI 当成唯一裁判。

少数研究场次可以暴露按钮含义不清、来源打不开，或用户习惯跟着最醒目的建议走等问题，却不能变成总体通过率，也不能证明长期学习。更不能据此宣称引导提高留存，或者防住了所有错误。

以后如果比较不同版本，尽量保持底层功能、案例和判断标准稳定。区分模型质量变化与引导体验变化。若要声称用户形成持久能力，需要延后再观察陌生任务；立即重复同一道题，主要反映对示例的记忆。先决定你想提出什么结论，再决定什么证据足以支持它。

9. 把阻力当成设计信号，不归咎于用户

第一次操作变慢，可能有多种原因。用户可能正在学习必要边界，也可能在读不易理解的文案、等待来源加载，或猜一个含糊按钮的意思。只看完成时长，分辨不出这些情况。

在获得同意的前提下，按相关经验和角色分析观察结果，而不是默认所有新人有相同困难。有人熟悉客服，却不熟悉你的界面；有人熟悉界面，却不了解业务政策。帮助要补足实际缺少的能力，不能只根据“初级用户”这个标签安排。

把激活和准备程度的证据并列看，但不要压缩成一个分数。如果用户拿到了价值，也能处理练习中的关键边界，就继续观察真实流程；如果拿到了价值，却反复漏掉边界，先检查证据位置、默认值和转交入口，再考虑增加教程；如果理解决定，却完成不了操作，则检查交互成本。

两方面都看不到时，可能是功能范围太大、目标角色不对，或第一个例子与用户工作无关。先缩小功能，再决定是否扩充课程。只需要一份草稿的客户，不应被迫上完一门无关的课。

观察用户是否做出了合理转交，以及转交之后有没有人真正处理。发送率降低可能意味着合适的克制，并不一定是激活失败；发送率提高也可能藏着没有依据的承诺。指标必须结合动作含义，而不能只计算次数。

这些解释是供产品调查使用的假设，不是专利实验验证过的结果，也没有证明收入变化。它们的价值在于，把团队引向具体需要修改的页面、工作流程或产品承诺。

10. 持续维护边界，也要知道这套方法何时不适用

套餐、权限、来源和模型行为都会变化，引导示例也会过时。相关产品规则改变时，指定负责人复核练习，把来源版本与预期操作一起更新。教用户使用昨天的权益规则，还不如坦率说明政策正在调整。

NIST AI 风险管理框架的核心部分把监督角色、部署情境和持续评估作为明确的组织事项。这是自愿采用的指导，不是对本文设计稿的认证。在这里，对小团队最直接的要求是：明确谁维护引导，谁处理超出用户角色的问题。

这套方法适合用户确实需要做有限且有意义选择的功能，例如核验说法、修改草稿、识别缺失信息，或向他人求助。对后果轻微的装饰功能，或者用户根本没有决定权的功能，帮助较小。不要仅仅因为采用了 AI，就给配色生成器加入强制考试。

它也补不上专业知识缺失、不安全的自动化或无法查看的证据。需要合格专业人士判断的事项，教程不能赋予资格。应把动作保留给合适的角色、收窄功能范围，或提供真实的专家服务。有时用户该掌握的能力，就是“暂停并转交”。

在本周的产品评审中，选择一个真实功能、一个角色和一个关键判断。填好设计表，用这个角色的权限走一遍页面，再观察一个陌生但安全的案例。根据结果，决定下一处有明确范围的修改。Google 的最新研究讨论，让创始人有理由及时追问：用户收到 AI 带来的价值后，是否理解该如何使用它？答案仍然需要你的产品证据来提供。

参考资料

1. Google Research：Does better work always mean better workers?：2026 年 10 月 7 日的公开解读，与第 2 项是同一实验，不是独立复现。
2. NBER 工作论文 35720：Does AI Assistance Enhance or Erode Expertise?：2026 年 9 月的研究介绍和摘要；工作论文，不是普遍适用的产品结论。
3. NBER 工作论文 31161：Generative AI at Work：不同客服工作场景中的证据。
4. PNAS：Generative AI without guardrails can harm learning：教育实验；迁移到产品引导的效果尚未验证。
5. Microsoft Research：The Impact of Generative AI on Critical Thinking：自报调查，不是证明能力下降的因果实验。
6. 哈佛商学院 AI Institute：Navigating the Jagged Technological Frontier：原研究机构对任务相关 AI 表现的介绍。
7. Microsoft Research：十八项人机 AI 交互指南：设计指导，不是学习效果证明。
8. Microsoft HAX Toolkit：人机 AI 交互指南：相关设计资源，与第 7 项不是独立研究。
9. NIST：AI RMF Core：自愿采用的风险管理指导，不是认证，也没有规定一套产品引导检查表。