WorkBuddy × 企鹅教师助手：教学能力是怎样接进来的

最近，看到了企鹅教师助手接入 WorkBuddy 的消息。

作为一个重度 AI 工具使用者，同时又在做教学相关的技术支持工作，我对这组产品有些好奇：它能帮教师做出什么，这些教学能力背后又是怎样运行和配合的？

于是，我分别在企鹅教师助手网页端和 WorkBuddy 中试了物理、化学的教学需求，看看生成的东西能不能用于课堂，也跟着 AI 工作记录往下看，它们背后的专家、Skill 和工具究竟怎样配合。

一、从用户视角看功能和效果

先看看官方披露的能力：

企鹅教师助手可以生成教学大纲、幻灯片草稿、教学活动、互动仿真实验和初步报告。进入 WorkBuddy 后，产品组合还包括 33 位教育专家、15 个教学 Skill，以及课件制作、创意教学、剧本教学和素材加工四类能力。

我给 WorkBuddy 和企鹅教师助手平台提了两个课堂需求。

一个是物理课上的电磁感应：让学生改变条形磁铁运动的方向和速度，观察感应电流怎样变化，理解磁通量变化与电流之间的关系。

另一个是化学课上的乙醇催化氧化：展示乙醇生成乙醛的实验装置、步骤、现象、方程式和安全提示，并让学生根据实验现象判断反应是否发生。

两项需求都要求交付可以直接在课堂使用的单文件 HTML。最后得到的是几份可以在浏览器中打开的互动演示。

在物理演示里，教师可以改变磁场、线圈或运动状态，让抽象的电磁感应关系变成屏幕上的实时变化。做得较完整的版本不只显示动画，还会同步更新数值与概念解释。学生不必先在脑中想象一整套过程，教师也多了一个可以边操作、边提问、边纠正直觉的媒介。

在化学演示里，实验不再只是几张装置图。较好的版本把加热、伸入铜丝、观察颜色变化和判断反应现象串在一起，还加入了错误选项与解释。它已经接近一个小型的课堂互动活动，而不是把教材段落重新排版了一遍。

做出来的教学材料还不够完善。有的页面信息排得太满，投屏讲解时需要有所取舍；有的演示下载到本地后仍需联网加载资源；同一个入口生成的结果，也有能顺畅操作和交互失效的区别。这些地方还需要打磨，但前面几份演示已经能在课堂上派上用场。

它确实降低了一部分非标准教学资源的制作门槛。过去，一名教师想为某个知识点做一份可交互演示，通常要自己写代码、找技术人员，或者放弃自己的具体设想，去资料库里寻找一个勉强合适的现成作品。现在，他可以先把教学意图说出来，再花时间筛选、修改和组织课堂使用。

和我用过的多种 AI 产品相比，我会给这组产品一个“良好”的评价，整体处在中等偏上的水平。它已经能把教师的具体设想做成可操作的教学演示，实际使用中的稳定性还有提升空间。

二、从产研视角看运行机制和产品设计

1. 企鹅教师助手的能力是怎样进入 WorkBuddy 的

做完这些测试，除了实际的产品效果，站在技术工作者的角度，我也更好奇这些任务背后是怎样完成的。

企鹅教师助手原本就有自己的课件、动画和素材制作能力。进入 WorkBuddy 后，这些能力是被直接调用，还是以另一种方式重新实现？

沿着几次任务的调用记录往下看，两边走的是不同的生成流程。企鹅教师助手网页端调用自己的专业生成管线；WorkBuddy 里的企鹅教师助手专家则读取本地教学方法论，使用 WorkBuddy 的通用工具生成文件。本轮任务中，没有出现调用企鹅教师助手平台创建教学产物的步骤。

把几个对象分开以后，当前关系更接近下面这张图：

企鹅教师助手 Web
  └─ 自己的专业生成管线 → 生成、检查并交付 H5 等教学产物

WorkBuddy 中的企鹅教师助手专家
  └─ 本地方法论 + WorkBuddy 通用工具 → 独立生成文件

教学 Skills
  └─ 以具体任务命名的可复用工作流

企鹅教师助手网页端有自己的生成流程，包括网页制作、文件编辑、代码检查和 H5 质量检查。平台在后台完成生成，并在任务页提供产物。

WorkBuddy 中的专家会先读取本地教学方法论，再使用 WorkBuddy 的通用工具制作 HTML。 在这几次任务中，进入 WorkBuddy 的是指导生成的教学方法，文件的生成与检查也由 WorkBuddy 完成。

专家与 Skill 承载了这部分方法。专家带有特定的角色与判断框架，Skill 则提供具体任务的方法和流程。WorkBuddy 中的 33 位教育专家，以及以班级活动、学情分析等任务命名的教学 Skill，分别承担这些工作。

2. 教学 Skill 与 MCP 怎样协同

从产品设计上看，更符合一般直觉的是：企鹅教师助手提供给 WorkBuddy 的专家团及其携带的 Skill、连接器开放的 MCP 工具，以及平台本身的专业能力，应该相互配合。专家根据教学需求选择方法，通过连接器调用平台服务，共同完成任务，让这次组合发挥出 1+1>2 的价值。

例如，企鹅教师助手已经有课件和教学演示的专业生成服务。当 WorkBuddy 按教学方法处理这类需求时，配套工具就应当支持创建任务、查询进度和取回产物，让这些服务参与实际工作。

但从实际测试和连接器页面上的可见信息发现，企鹅教师助手的 MCP 连接器只提供了名为 get_user_memory 的工具能力，用于读取用户记忆，并没有像我们预想的那样，提供创建教学任务、查询进度或取回产物的工具。 读取教师偏好可以帮助调整教学内容，但单靠这个工具，无法完成上述调用流程。

我接着测试了这个记忆工具。WorkBuddy 中的专家会调用它，但返回的是空数组。

我又在企鹅教师助手网页端说明了使用的年级、教材版本和探究式教学偏好，要求以后的教学设计按这些偏好来。平台回复说已经记录，并把内容保存成了一份 Markdown 文件。

等任务完成后，我再次让 WorkBuddy 读取记忆，结果仍然为空。新建一个 WorkBuddy 任务再试，也是一样。这些读取都发生在授权有效期间。 平台说已经记录的偏好，没有通过连接器传到 WorkBuddy。

预想中的专业任务工具没有接入，已经开放的记忆工具也始终没有返回内容。专家、Skill 和连接器虽然都已上线，实际任务中的协作却还没有跟上。

站在产研视角，我倾向于把这个藏在产品背后的功能缺口，理解为几个团队的工作还没有很好地对接起来。WorkBuddy 已经提供了开放的生态，支持专家、Skill、连接器等多种接入方式，企鹅教师助手要做的，是把自己的教学方法和专业服务接进来。 现在看到的落差，更像是具体接入还没做完。

我猜，企鹅教师助手内部负责专家团和 Skill、网页端专业服务、MCP 连接器的，也可能是几个不同的小团队。Web 侧管自己的网页服务，负责接入 WorkBuddy 专家和 Skill 的小组把网页端调试好的教学方法搬过去，负责 MCP 接入的小组夹在中间，却还没把两边连接起来。

对此我也能理解。我不觉得这首先是技术能力的问题，更像是整个项目定了一个上线节点，比如开学，各个小组还没对齐接口，甚至还没把协作流程想清楚，就得赶着 deadline 上线。

也可能还有另一种设计：企鹅教师助手正在做一次结构性的迁移，打算把原本在网页端处理的任务交给 WorkBuddy，原有平台则专门维护教师画像和工作中积累的记忆。这也是一种可以理解的解耦设计。不过，连唯一的 MCP 工具 get_user_memory 都始终读不到实际内容，我还是倾向于认为，时间紧、接入尚未完工，是眼前这些缺口更直接的解释。

如果先把时间紧、尚未完工造成的功能缺口放到一边，我更好奇的是，企鹅教师助手后续会往哪一种设计走：是把教学任务的执行都交给 WorkBuddy，自己主要维护教学方法和用户记忆，还是继续保留网页端的专业服务，让 WorkBuddy 通过连接器来调用？

如果走前一条路，教师日常的工作和反馈发生在 WorkBuddy 中，用户画像却由企鹅教师助手维护，那么教师换了年级、调整了教学偏好，或者在任务中纠正了助手的理解，这些变化要怎样传回去？谁来判断哪些信息值得记住，又怎样更新原来的画像？这部分如何设计，我觉得会比现在接入了多少专家和 Skill 更值得继续看。

---

PS

平时同时在使用千问办公和豆包工作这几款AI 办公产品，对比下来，WorkBuddy 有一个非常显著的优点：可以接入自己的模型 API。相比之下，千问办公和豆包工作还不支持这样接入，WorkBuddy 在模型选择上多了一些自由。

不过，Workbuddy 现在接入自定义的 MCP 的体验还不够顺。技术上能接进去，但接入的 MCP 并没有出现在Composer的连接器列表里，想在任务中选用时不够直观。这部分用起来，体感还有些别扭。