在上家公司，组织 AI 培训时，总会遇到一个熟悉的场景。老师带着大家使用公司的 AI 工具，搭建一套客服工作流。

老板在年会或其他场合演示的是这个场景，各种 AI 培训中，老师教大家搭建的也是这个场景。全员都要学习，其中也包括日常工作与客服没有直接关系的职能和研发同事。

从事学习与发展工作，让我很难忽略这种距离。课堂上讲解的是客服的需求，坐在台下的人却有各自要处理的工作。即使跟着老师完成了练习，回到岗位后，也还需要弄清楚这些操作究竟能用在哪里。

客服场景可以作为入门案例。员工可以借此认识工作流的组成，练习如何提供信息、连接步骤和检查输出。但如果后续培训仍然围绕同一个案例展开，一个做培训、做招聘或做研发的人，就需要自己完成从课堂到岗位的迁移。

培训结束后，我们可以统计出勤和课程完成情况，也可以检查大家是否搭好了客服工作流。可我更想知道，一个同事回到岗位后，能借助 AI 完成什么。换一种材料、换一个需求，他是否还知道怎么做。

看到Claude Frontier Academy 的项目安排时，我留意到了它对学习迁移的设计。首个面向工程师的项目安排了四天集训。前三天在模拟企业场景中完成系统搭建、安全审查和交接，第四天换一个新场景考核。通过后，学员还要回到自己的组织，开展十二周的实际项目，再接受最终实操评估。

工程师项目的内容和周期当然不能直接搬到所有岗位上。但让学员换一个场景，再回到工作中实践，给了我一些启发。如果企业希望建立内部 AI 能力认证，HR 首先需要想清楚，培训怎样才能接上员工原本就在做的工作。

先让同事展示工作h2

如果由我来推进，我会在共同的工具入门之后，增加一段岗位任务练习。大家可以使用同一个平台，但练习材料、交付成果和验收要求，应当与各自的工作有关。

比如，培训同事可以尝试整理课程反馈，招聘同事可以尝试核对岗位需求与面试评价标准，研发同事则可以选择一个适合练习的测试或文档任务。这些只是候选方向，需要业务同事一起判断是否有价值，以及哪些材料适合使用。

不过，要走到这一步，简单地让大家自由选题，可能仍然不够。即使 HR 向各部门发出问卷，询问“你希望在哪些场景使用 AI”，也未必能收到清楚的答案。

已经熟悉工具的同事，可能很快就能列出几个方向。对尚未尝试的同事来说，这道题却不容易回答。他知道每天要做什么，也知道哪一步最麻烦，但未必知道 AI 能够参与其中的哪一部分。

如果需求征集停在这里，我们可能听到了积极使用者的声音，却漏掉了其他人的困难。看懂一个演示案例，与找到自己工作中的应用机会，仍然是两件需要分别练习的事。

我更愿意先问问同事，上周哪项工作最耗时，哪些材料需要反复查找、比较和复制。也想知道一份成果为什么被退回，资深同事能发现什么，而新人容易漏掉什么。

如果能带着适合展示的材料，把一次工作从头到尾做给我们看，这些困难就会更容易被理解。

比如“写一份报告”，实际可能包含收集数据、统一口径、计算、解释异常、核对结论，以及等待其他部门确认。只有把这些步骤看清楚，才能讨论 AI 适合介入哪里。如果时间主要花在等待审批上，生成再快，也未必能让报告更早交付。

HR 当然不需要先成为每个岗位的专家。但我们需要愿意听懂工作，遇到不理解的术语，请业务同事用具体例子解释。还没有理解的判断，不宜匆忙写进培训要求和考试标准。

把“做得好”说清楚h2

听懂工作之后，HR 还需要帮助业务专家把经验说清楚。

一位资深同事可能知道什么样的成果可以交付，却未必已经把判断整理成文字。他会说“这里不对”“这个结论太早了”“这份材料还不能发”，但新人需要知道的是，哪里不对，缺少什么，以及接下来应该怎么核查。

可以先把一份合格成果和一份有问题的成果摆在一起，请专家解释差别，再把这些差别整理成能够观察的要求。

假设我们要围绕离职数据分析设计一项培训，我会先请业务负责人说明合格报告的要求。数据需要完整，统计口径需要一致，计算过程应当能够复核，被排除的记录也应有理由。报告中的原因分析尤其需要仔细看，不能把一种可能的解释写成已经确定的结论。

这些要求明确后，再尝试让 AI 辅助字段对应、异常识别或摘要起草。固定规则下的计算，可以交给表格工具或脚本；统计口径和原因判断，仍然需要负责的人确认。

比较效率时，也要把准备、核查、沟通和返工的时间算进去。初稿提前出来了，审核却多花了半天，至少还不能据此说整个流程更高效。

这仍然是一套待验证的设想。实际的题目、质量要求和效率目标，都需要经过小范围试用后再确定。

考核里，要留出人的判断h2

沿着这个思路，考核也需要接上岗位任务。共同的工具操作可以统一检查，专业成果则需要按岗位评价。对一位职能同事来说，复现客服工作流可以证明他完成了这项练习；要判断他能否在本职工作中使用 AI，还需要一项相关任务。

拿到成果之后，我还想听参评者讲讲过程。哪些输入经过了核对，哪一条 AI 建议被自己否决了，为什么没有采用，还有哪些地方不能确定，需要找谁确认。

在此基础上，可以再给任务增加一点变化。

仍以离职数据分析为例，可以临时调整一个统计条件，或者加入一批字段不一致的记录。观察参评者能否发现影响，重新计算，并解释哪些结论需要修改。这比只看最后一页汇总表，更有机会看见他对任务的理解。

能识别某一步不适合交给 AI，并及时请专业同事确认，也应当得到认可。实际工作需要这种判断。

专业质量应由业务专家评价。HR 负责组织评审、协调评分尺度、核对参评者的个人贡献，并让未通过的人知道具体还差在哪里。团队完成了一个好项目，不意味着每位参与者都已经能够独立完成同样的任务，评审时也需要看清每个人实际承担了什么。

在我看来，一张内部证书应该把认证范围写清楚。这个人在哪类岗位任务上，使用什么工具，达到了什么标准，何时通过评估，都应当有据可查。业务同事才知道可以把哪些工作放心交给他。

员工愿不愿意展示困难，也是文化的一部分h2

而员工是否愿意参与这样的学习，也让我想到自己的另一项工作，企业文化。

当一位同事说“这个场景和我的工作关系不大”时，我希望培训组织者愿意继续听下去。请他展示自己的任务，一起寻找连接点，也确认现有工具是否适合。这句话可以帮助我们发现课程还缺少什么。

一个同事是否愿意展示自己做得慢、容易错的流程，是否敢承认一份 AI 生成的材料还没有完全理解，都与团队日常如何对待问题有关。发现工具的错误后，他也需要能够及时说出来。

如果一次分享很快变成“为什么别人已经会了，你还不会”，下一次大家可能就只带着漂亮成果来了。HR 看到的应用案例会越来越完整，却越来越难看见真实的学习需要。

因此，组织 AI 学习时，我希望培训负责人能给员工练习和反馈的时间，业务负责人能说明质量要求，评审者能认真对待不确定项。提出问题的人，也应当知道这个问题会被谁接住。

HR 可以让业务专家参与练习反馈，让员工有机会补练和重考。回岗后遇到的困难，也应有人收集，并据此调整培训内容。这样的协作，需要在一次次具体反馈里慢慢建立。

证书发出去之后，也还要继续观察员工能否独立完成任务，错误和返工有没有减少，学到的方法是否真的用上了。工具和流程发生变化时，原来的标准也需要重新检查。培训是否让人更有能力，最终还是要回到工作里看。

我愿意从一项小任务开始。听一位同事讲清楚他的困难，请一位专家解释自己的判断，再留出一次练习、反馈和重新尝试的机会。

也许他起初学的是客服工作流。接下来，我们可以陪他走完从课堂案例到岗位任务的这一步，让他带走一种能在自己工作中继续使用的方法。

等到下一次类似任务出现，他能够更从容地接过来，知道怎么做，也知道哪里需要确认。作为 HR，我希望看见的培训成果，大概就落在这样的变化里。