用 Badges Ninja 替换 Moodle 原生 Open Badges（更好的设计器，同一套 API）

Moodle 从 2.5 版本开始就原生支持颁发 Open Badges，对很多课程管理员来说，光凭这一点就足以让他们从不考虑其他方案。它是内置的、免费的，而且在技术上也能生成符合标准的数字凭证。那么，为什么这么多 Moodle 管理员在颁发到第五十枚徽章时会感到沮丧呢？

诚实的答案是：Moodle 的徽章系统从设计之初就只是为了勾选一个合规选项，而不是打造一款真正的凭证产品。它能用，但用起来就像是硬塞进 LMS 里的一个功能——能跑，但过时、局促，被所依附的平台的种种限制死死束缚着。如果你曾经试图让一枚 Moodle 徽章看起来不像圆形剪贴画图标，或者听到毕业生问“等等，我到底该去哪里看这个东西？”，你就已经明白这道鸿沟了。

这并不是在否定 Moodle——它是一款出色的 LMS，其徽章条件引擎（课程完成、活动完成、手动颁发、群组成员资格）在“触发”一枚凭证这件事上确实设计得很周到。问题出在触发之后的一切：设计工具、接收者体验，以及徽章在你的 Moodle 实例之外的可见度。这恰恰正是 badges.ninja 所要解决的问题，而且使用它并不需要放弃 Moodle 的完成度判定逻辑——你只需要把触发器指向另一个颁发引擎即可。

Moodle 原生徽章的短板在哪里

设计器只是一个基于坐标的图像合成工具，算不上真正的设计工具。 Moodle 的徽章编辑器只允许你选择一张底图、叠加几个预设的图标，再用像素偏移量来调整位置。这里没有形状库，没有配色系统，除了图标集里自带的字体之外也没有任何字体可选。如果你的机构有自己的品牌——一枚 logo、一套配色方案、一套专属于你认证体系的视觉语言——Moodle 的编辑器根本无法呈现出来。大多数机构最终都是在 Photoshop 或 Canva 里做好徽章图案，再上传一张平面 PNG 图片，这就完全违背了内置设计器本应存在的意义。

接收者必须登录 Moodle 才能查看自己的徽章。 学员获得的徽章保存在他们的 Moodle 个人主页里。如果他们已经结课、忘记了机构账号密码，或者机构已经注销了他们的账户，那么徽章在他们那一端实际上就等于消失了——尽管底层的断言可能仍然可以通过 Moodle 的 backpack 连接器或公开徽章页面来解析。这里没有一个专属的、带品牌标识的、随时可访问的地方，让接收者只需用邮箱登录，就能查看他们在所有课程中获得过的每一枚凭证。

分享功能完全是事后补充的。 Moodle 可以把徽章推送到兼容 Mozilla Backpack 的服务，也为每枚徽章提供一个公开的验证链接，但它没有内置的“添加到 LinkedIn”流程，没有一键分享按钮，也没有任何关于徽章颁发后是否有人查看过的互动分析。对于希望徽章能起到口碑营销作用的项目——训练营、继续教育机构、企业培训——这就是实实在在的机会成本损失。

批量操作很笨拙。 如果整个群组的学员都在同一时间于 Moodle 内完成了触发条件，那么给整个群组颁发徽章还算顺利。但如果你需要为过去某一届学员补发徽章、从电子表格导入历史完成记录，或者为完全发生在 LMS 之外的事情颁发一枚徽章，你就只能直接对 Moodle 数据库写 SQL，或者跟那些根本不是为徽章场景设计的 CSV 导入工具死磕。

替换方案：保留 Moodle 的触发条件，更换颁发方

要解决这个问题，你并不需要彻底迁移出 Moodle。最干净的做法是让 Moodle 继续做它擅长的事情——追踪课程完成、活动完成、群组成员资格——然后在完成条件被触发的那一刻，让它调用 Badges Ninja 的 API，来代替（或配合）颁发它自己的原生徽章。

Moodle 有几种方式可以支持这一点：

1. 课程完成 Webhook / 轮询 Moodle Web Services（REST）。 Moodle 的 core_completion API 会按用户、按课程暴露完成状态。一个轻量级的定时任务（可以是 Moodle 自身的计划 cron 任务，也可以是一个访问 Moodle REST API 的外部 cron 作业）可以轮询新完成的选课记录，并为每一条记录调用 Badges Ninja 的颁发接口。

2. 本地插件钩子。 如果你的团队里有开发人员，Moodle 的事件系统（\core\event\course_completed）可以被一个小型本地插件监听，在完成事件发生的那一刻立即触发一个 HTTP 请求——没有轮询带来的延迟。

3. 用 Zapier / Make / n8n 做“胶水”，如果你不想改动 Moodle 的代码——Moodle 可以把完成事件推送到一个 Webhook 接收端，再由无代码自动化工具把它转换成一次颁发调用。

一旦你拿到了已完成课程的用户姓名和邮箱，实际的颁发调用是这样的：

curl -X POST https://api.badges.ninja/awards \
  -H "X-Api-Key: bws_3f9a1c2d4e5b6a7c8d9e0f1a2b3c4d5e" \
  -H "Content-Type: application/json" \
  -d '{
    "badgeId": "badge_moodle_course_completion",
    "recipient": { "name": "Jordan Alvarez", "email": "learner@example.edu" },
    "issuedOn": "2026-08-31"
  }'

或者在 Node 里，写在你所运行的任意定时任务或 Webhook 接收端内：

const response = await fetch("https://api.badges.ninja/awards", {
  method: "POST",
  headers: {
    "X-Api-Key": process.env.BADGES_NINJA_API_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    badgeId: "badge_moodle_course_completion",
    recipient: { name: completedUser.fullname, email: completedUser.email },
    issuedOn: Date.now(),
  }),
});
const award = await response.json();

接收者的邮箱会在静态存储时经过 SHA-256 哈希处理，每次颁发都会自动生成唯一的验证链接、一个二维码，以及一份 A4 尺寸的 PDF 证书——更关键的是，接收者可以通过 badges.ninja/me 上的魔法链接登录来认领它，完全不需要另外注册一个 Moodle 账号。完整的请求 / 响应格式可以参考 awards API 参考文档，API 密钥端到端的工作原理则可以参考 身份验证指南。

如果你更倾向于批量处理——比如一次性补发整个学期的完成记录，而不是搭建实时事件通道——可以把 Moodle 的完成记录导出成 CSV，直接使用支持大文件暂停 / 恢复的批量颁发流程。这一点在 如何通过 CSV 颁发 Open Badges 中有详细说明。

设计徽章本身

一旦底层管道搭建完成，徽章本身的设计只需要几分钟，而不必给你的网页团队提工单。这款可视化设计器提供了 80 多种形状模板、真正的配色系统、图标库，以及自定义字体上传功能——这样，一枚“高级统计学——已完成”的徽章才能真正看起来属于你机构的品牌，而不是一个通用的 Moodle 成就图标。

每一个 API 密钥都有明确的作用范围，并且可以在你管理徽章和颁发机构的同一个控制台里随时撤销，所以把集成凭证交给开发者（或者 Zapier 这类自动化工具）并不意味着要共享你的主账号登录信息。

对比一览：接收者体验

Moodle 在一点上仍然占优：如果你唯一的需求就是“徽章存在、技术上符合 Open Badge v2.0、并且就放在学员已经在用的 LMS 里”，那么原生徽章不需要额外花费，也不需要任何集成工作。但一旦你开始在意设计质量、课程结束后凭证的可携带性，或者想把颁发行为变成一种招聘 / 营销信号——而最终大多数机构都会走到这一步——原生方案的短板就会显现出来。

想更全面地了解其他 Open Badges 平台在价格和功能上的对比，可以参考 最便宜的 Open Badges 平台对比。如果你的机构正在权衡 Open Badge v2.0 与更新的可验证凭证规范，Open Badge v2 与 v3 详解 会告诉你今天到底该上线哪一种。

准备好颁发你的第一枚可验证凭证了吗？ 在 badges.ninja 免费开始——可视化设计器、公开验证页面、PDF 证书、Open Badge v2.0 输出格式，无需信用卡。