赋能工作坊的成败在实验环节，不在幻灯片

离交付还有两周。你搭建的 Agent 已经在客户的数据上运行，对方经理发来消息：“能不能给我们 AI 团队做一次工作坊？大概两小时。”这个团队有五六名工程师，这次课之后，修 prompt、加测试、处理故障都要靠他们自己。

如果你的第一反应是打开 PowerPoint，不妨再想想。讲两小时课，并不能帮任何人在凌晨两点独自修好 Agent。这次课的成败取决于实验环节，以及你为课后几天准备了什么。

这项技能的重要性常被低估。只有客户团队能够独立运转，一次部署才算真正完成，而赋能工作坊正是把这种能力交还给他们的环节。

做得好，你就能放心转去下一个项目；做得不好，一个月后你仍是唯一敢动这套系统的人。

两小时能装下多少内容？

PreSales Collective 指出，面向客户的技术工作坊短则一小时的午餐分享会，长则一整天的讲师带教培训。两小时居中：足够让每个人亲手做一遍，但远不够把你会的都教完。

所以第一件事是做减法。Maven 关于如何办工作坊的指南建议，每次课围绕 2-3 个核心学习目标展开。两小时里，两个目标是稳妥的数字，因为每个目标都既要讲解，也要留出动手时间。

设想一家保险公司的 AI 团队，即将接手一个理赔分类 Agent。你可以给他们讲架构、模型选型、向量库、成本监控。

但到交付那天，他们只需要两件事。第一，Agent 分错类时能修好 prompt。第二，能往评测集里加一条测试用例，让同样的错误不再出现。其余内容都可以放进文档。

学习目标要写成学员能做到的事，而不是他们“理解”的事。“离开教室时，每个人都能修好一个分错类的 prompt，并用评测证明修好了”，这个目标可以检验；“理解提示词工程”则不行。

120 分钟课程方案，逐段拆解

PreSales Collective 强调，工作坊需要一个经过充分测试的实验环境，课程大纲和学习目标也要提前规划。下面是为前文保险团队设计的一份逐分钟示例方案。

分钟	环节	学员做什么
0-10	开场与背景故事	看一条被 Agent 分错类的理赔，猜原因
10-30	目标 1：读懂并修改 prompt	跟着演示走，每一步后回答快速提问
30-55	实验 1	为三条分错类的理赔修改 prompt，重新运行
55-65	休息	卡住的人找助教
65-80	目标 2：往评测里加测试	跟着演示，逐行操作
80-100	实验 2	把实验 1 中的错误写成测试用例，运行评测集
100-108	发放作业	领取任务、数据和截止时间
108-120	结构化问答	课上收集的问题按主题统一解答

注意，即便是演示环节也不能变成独白。Maven 建议大约每 3-5 分钟切换一次状态，比如提一个问题、组织小组讨论或分组练习，避免课程滑向单向灌输。

所以在 20 分钟的演示里，你要停下来四到六次，问类似这样的问题：“如果改掉这一行，你觉得输出会怎么变？”

学员的提问则集中到最后。Maven 建议在工作坊结尾专门留出结构化问答时段。实验期间，大家把问题发到共享频道；到第 108 分钟，你按主题归类后一次性解答，既不打断实验，也不会漏掉任何问题。

实验需要故事，而不只是步骤清单

Skillable 关于动手实验设计的资料区分了两样东西：学习目标、任务和预期结果是给实验作者看的指引；背景故事则是给学员的，它给了学员动手的理由。

对保险团队来说，背景故事在项目里现成就有：“周一早上，理赔部门反馈 Agent 把三条水灾损失理赔归到了车险事故下。离你和他们开会还有 25 分钟。”

这三条理赔应当来自部署期间真实出现的错误，并做匿名化处理。学员一眼就能看出，这正是他们即将接手的工作，而不是为练习而练习。

如果需要模板，可以参考 Anthropic 在 GitHub 上发布的交互式提示词工程教程。它共九章，每章包含一节课和一组练习。每节课末尾都有一个“Example Playground”，学员可以在里面自由试验示例；另外还为讲师单独准备了一份参考答案。

这三个特点都值得借鉴。先讲后练的结构让每个实验环节有清晰的起止；练习区让先做完的人有事可做；独立的参考答案让你或同事在帮卡住的人时，不必临场现想。

还有一个细节。这份教程还有 Google Sheets 版本，作者推荐它为更易上手的版本。如果现场有不熟悉 notebook 的业务专家或 QA 人员，用他们已经熟悉的工具来跑实验，可能就决定了他们是“动手做”还是只在“旁观”。

以陌生人的视角测试实验

Skillable 提醒，内部自测与学员的实际体验并不相同，像样的测试需要时间，也需要对每个细节都足够细心。

你对系统了如指掌，所以不会在新人会绊倒的地方绊倒：API key 还没发下来、没有 bucket 的读权限、库版本不一致、某个环境变量只存在于你自己的机器上。

实用的做法是：把实验交给一个从没接触过这个项目的人，用一台干净的机器，用和客户完全同类型的账号。什么都别解释。他每问你一次，就意味着说明文档里要补一行。

至少提前几天做这件事，这样还来得及找客户那边申请权限。

另一种值得了解的形式：UNC-Chapel Hill 曾办过一场 90 分钟的动手工作坊，参与者扮演 FDE，为一个真实的客户问题搭建原型。工作坊越短，环境越要提前准备好，因为根本没有一分钟可以花在环境搭建上。

作业是课程的后半场

PreSales Collective 建议为工作坊参与者准备好下一步。对 FDE 来说，这个下一步应当是一份基于客户真实数据的作业，截止日期定在下一次例行沟通（check-in）当天。

对保险团队，作业可以是：每人拿一周内被分错类的五条理赔，至少修好其中一条对应的 prompt，在评测集里加上相应的测试用例，然后提交一个 pull request。

下一周的 check-in 就用来评审这些 pull request。从中你能看出谁已经可以独立上手，谁还需要额外的一对一辅导。

浪费两小时的常见错误

最常见的错误是目标塞得太多：四五个主题，实验被压缩到十分钟，结果没人做完。几乎同样常见的是只有你自己跑过实验，于是课程前半小时都耗在理顺访问权限上。还有一口气讲二十分钟不停顿，这正是 Maven 建议避免的独白。

有两个错误更不容易察觉。一是任由提问频繁打断，破坏了正在做实验的人的专注。二是课程结束时没有布置任何后续任务，刚学到的东西还没等到第一次用上就淡忘了。

从职业角度看：读 FDE 岗位描述时，留意那些关于培训客户或向客户交接的条目，那说的就是这项技能。

写简历时，别只写“负责客户培训”。要写清楚你教的是哪个团队、学习目标是什么，以及他们课后能独立完成哪些原先必须找你的事。

检验赋能工作坊的，不是课后的反馈表，而是你离开后 Agent 第一次出故障时，客户团队还没想到要给你打电话，就已经把它修好了。