飞书在 2024 年 10 月 21 日支持了在外部群使用飞书机器人，终于你的外部群可以用飞书机器人管理起来啦！ 前置依赖 * 这个功能依赖机器人所在的飞书企业是完成认证的。如果没有认证过，则无法实现该功能。 具体操作说明 创建一个飞书机器人 首先，你需要创建一个机器人，然后添加对应支持的权限点，具体权限点可以在文档查看。 创建完成后，配置事件，并创建一个新的版本并发布。需要注意的是，在发布时，要勾选「对外共享」。 配置完成后，发版。 在外部群中添加机器人 在完成后，点击添加机器人，你会在添加机器人的界面当中看到你的新的机器人。 将这个新的机器人添加到外部群里。 完成开发逻辑 当你的机器人被拉到外部群后，就可以按照标准的处理逻辑，处理群里的事件信息啦！
飞书消息卡片
飞书开放平台最近开始内测了输入框的能力，基于输入框，为消息卡片提供了进一步业务系统打通的可能性，你可以不需要开发一整个网页应用，只需要借助飞书机器人和飞书消息卡片，就可以实现一套业务交互逻辑。 流程图示意 目标说明 这里首先确定要实现的逻辑：这里我要做的是一个短链接应用，功能很简单，点击下方的机器人菜单，并在弹出的窗口中输入对应的短链接后缀和要跳转的链接，点击确定就会帮我创建一个短链接。 具体效果如下： 如果后缀已经被占用，则展示如下内容： 在实现这个功能时，我首先使用了飞书提供的输入框组件的能力和表单组件能力，来实现整个业务交互，当然，你也可以根据业务形态，来选择合适的组件，构成一整个输入表单。 实现逻辑 整体的功能可以分为三步： 1. 点击按钮：机器人需要响应点击事件，并发送一个带有输入框的消息卡片。 2. 验证卡片输入内容：消息卡片中提供了输入框，但是用户的输入是否我们能用，需要设计一些验证的能力。 3. 反馈用户是否创建成功：当我们创建成功后，需要给开发者提示，告诉他是否已经创建成功，帮助他结束整个流程。 接下来就是具体的实现步骤了。 点击按
飞书消息卡片
在开发短链助手时，一个很大的痛苦的点是我希望通过消息卡片来完成开发者的交互，这意味着我需要有大量的行为是和消息卡片来完成的。而消息卡片又不同于 HTML，是一个比较明确的 DSL。消息卡片更多是基于 JSON 提供的一套 Schema，将其放在代码中管理也是一个非常麻烦的事情。 好在最近飞书开放平台迭代了消息卡片模板的功能，我可以不用把 JSON 存在代码中，而是只在代码中存一个 Template ID ，从而降低我在代码中维护这段 JSON 的难度。 在卡片构建工具中新建卡片 首先，你需要打开消息卡片搭建工具，并在其中创建一个新的卡片（你可以使用其提供的卡片组的能力，来管理你的卡片们）。比如我就要这个卡片组来管理短链助手和其他场景的卡片。 创建卡片完成后，你可以在 UI 上点击保存并发布，你就将你的卡片消息模板发布到了飞书的服务器。 此时，你就可以在代码中使用了。点击页面中间的 ID，复制消息卡片模板 ID，将你的调用代码替换为对应的逻辑即可。 使用模板需要注意，将消息卡片中的 Content 从过去的卡片内容，替换为 template 的 JSON。比如，
飞书消息卡片
在开发短链助手的时候，我需要实现一个查看当前用户创建的所有短链接的能力。这个依然希望通过消息卡片来完成。而作为一个 JSON，想要构建一套合适的内容，就变得十分的麻烦和复杂。 解构消息卡片 我要发送的消息卡片当中，可以区分为动态内容和静态内容，对于静态内容，我可能长期都不会变化，而静态内容，则会根据用户的数据发生变化。 如果整体都放在代码中生成，我就需要有一段又臭又长的代码来维护其中的变化的 JSON ，而我希望整个代码的简洁，不要有比较长的代码只是用来生成卡片的逻辑，所以就用上了消息卡片的新功能：循环对象数组。 而进一步看动态内容，则我们可以将其视为是变量 A 和变量 B 在不断的被重复赋予，最终形成了一行一行的结果。 而我们想要实现这样功能。首先，需要在卡片搭建工具中创建一个循环对象数组，并将其绑定在一个「多列布局」上。 绑定完成后，你的多列布局就有了被循环的可能性。 接下来你需要在多列布局中去构建你的每一行的结果，并在对应的位置绑定上变量，比如我这里就给多列布局防止了一个 Markdown 文本组件，并在这个文本组件中，填入了 ${source} 作为变量 A
网页应用
飞书在应用到更多的企业内部服务的过程中，会自然而然的衍生出通过网页跳转到飞书聊天框中，以进行下一步沟通的需求。如在企业内部的审批应用当中，可以跳转到审批人的聊天框，从而和审批人就当前问题进行进一步的沟通。 核心内容 飞书开放平台提供了 AppLink 的能力，支持从网页唤起飞书客户端的各项基本能力。因此，我们只需要借助于 AppLink 本身的打开聊天框 的能力，即可实现打开和特定人的聊天窗口。 你只需要在服务端获取到想要打开聊天框的人的 OpenID，即可实现这个能力。获取 OpenID 则可以使用现成的通过手机号或邮箱获取用户 ID。 流程图说明 伪代码 /** * 如何从网页中跳转到飞书聊天框？ * Author: 白宦成 <hi@feishu.io> */ function getOpenIDByPhoneOrMail() { // 服务端文档：https://open.feishu.cn/document/uAjLw4CM/ukTMukTMukTM/reference/contact-v3/user/batch_get_id
OpenAPI
飞书开放平台提供了获取会话历史的能力，开发者可以借助这个 API 来获取话题群当中的消息内容。 业务逻辑 话题群只是群的一种类型，因此，可以使用群类型通用的获取历史的方法，来获取话题群当中的内容。 此外，在获取群历史的时候需要注意，API 返回结果的信息当中包含 root_id / parent_id 的即为回复话题的消息，你需要先将对应的历史拉下来，再从子节点反向构建话题消息的历史。 示例代码 以下代码为伪代码，仅用于讲解逻辑。请自行替换为对应语言的逻辑实现。 /** * 获取话题群会话历史消息的位代码 * Author: 白宦成 <hi@feishu.io> */ function fetchGroupHistory() { // 此处为获取会话历史的封装 // 文档地址：https://open.feishu.cn/document/uAjLw4CM/ukTMukTMukTM/reference/im-v1/message/list // 服务端 SDK：https:
OpenAPI
在飞书开放平台上，有多个不同类型的 ID： * Open ID: 一般是大多数接口的默认参数 * Union ID：大部分接口的可选项 * User ID：有单独的权限管控，一般不太能用。 开发者往往在使用的过程中，会产生困惑：我到底应该如何选择这些 ID？ 一个比较简单的判断方式是 如果你可能会开发多个飞书开放平台的应用，那就选择使用 Union ID。对于绝大多数开发者来说，其实默认使用 Union ID 是最方便的。这样就算你暂时只开发一个应用，后续也有拓展的可能性。 至于 User ID：99% 的场景你是不需要使用的，如果你不是很确定这个场景是否需要使用 User ID，那么大概率是不需要使用的。 此外，这里附上一个快速判断逻辑图：
飞书云文档
目前飞书开放平台的云文档相关的权限管理 API 暂时不支持直接使用 appid 添加权限。但我们可以通过为群授权的方式，来给群内的机器人添加文档的管理权限，从而实现应用 A 将自己生成的文档授权给应用 B。 流程图 伪代码 /** * 批量为应用添加文档的管理权限。 * Author: 白宦成 <hi@feishu.io> */ const APP_ID = "cli_xxxxxxxxxxxxxxxxxx"; const ANOTHER_APP_ID = "cli_xxxxxxxxxxxxxxxxxx"; function createGroup() { // 服务端文档：https://open.feishu.cn/document/uAjLw4CM/ukTMukTMukTM/reference/im-v1/chat/create