ARTICLE · 1121248
workbuddy接入飞书指南:把AI助手放进团队协作流
如果 AI 只能停留在聊天窗口里，它很难真正参与团队工作。把 WorkBuddy 接入飞书后，AI 可以在群聊、私聊、文档和任务流之间被调用，成为团队随时可唤醒的协作助手。
这篇文章面向想把 AI 用进日常工作的爱好者。你不需要一开始就懂复杂的接口，只要理解“消息从哪里来、AI 做什么、结果送到哪里、谁负责兜底”这四件事，就能搭出第一版。全文按照教程卡片组织，从架构、配置到测试，带你完成一条可复用的接入流程。
01 先理解：WorkBuddy 接入飞书，究竟接入了什么
很多人第一次做接入，会把注意力放在“能不能在群里问一句话”。真正稳定的系统，至少包含五层：
- 入口层： 飞书群聊、私聊、机器人卡片或快捷指令。
- 身份层： 用户、部门、群组和应用身份，决定谁能触发什么能力。
- 编排层： WorkBuddy 负责理解任务、调用技能、整理上下文。
- 工具层： 知识库、表格、日历、工单、搜索和内部 API。
- 交付层： 把回答、卡片、文档或任务回写到合适的位置。
这五层中，最容易被忽略的是身份层和交付层。没有身份边界，机器人可能把内部资料发给不该看到的人；没有交付设计，AI 只能“说得很好”，却不能把结果变成任务、文档或下一步动作。
02 第一步：先写清楚你的第一个使用场景
不要从“我要做一个万能机器人”开始。先挑一个每天都会发生、规则相对清晰、结果容易验收的场景。比如：
群里有人发送“会议纪要”，WorkBuddy 自动整理最近对话并生成待办。 销售发送客户问题，WorkBuddy 从产品资料中检索答案，并给出可复制的话术。 项目群发送“日报”，WorkBuddy 按固定格式收集进度、风险和明日计划。 新人私聊机器人，获得团队规范、工具入口和常见问题说明。
可以用下面这段需求描述作为起点：
我希望在飞书项目群中，通过“日报”指令触发 WorkBuddy。它需要询问成员今天完成的事项、遇到的阻塞和明日计划，将结果整理成统一格式，并在群里生成一张摘要卡片。涉及个人评价、薪资、客户隐私和未确认事实时，不做推断，必要时转人工。
这段话包含了触发词、输入字段、输出形式和安全边界。描述越具体，后面越不容易返工。
03 第二步：创建飞书应用并准备凭证
在飞书开放平台创建一个企业自建应用，填写应用名称、图标和用途说明。建议名称直接体现用途，例如“项目协作助手”或“WorkBuddy 运营台”。
创建后，记录以下信息，但不要把它们写进公开文档或聊天记录：
App ID：应用身份标识。 App Secret：应用密钥，只放在安全配置中。 Verification Token：用于校验事件来源。 Encrypt Key：用于事件内容加密时的解密。
凭证不是越多越好，而是要分环境管理。测试环境和正式环境最好使用不同应用；如果团队暂时只有一个应用，也至少把密钥放在环境变量或密码管理器中，不要直接写进 WorkBuddy 的公开提示词。
04 第三步：配置机器人能力与事件订阅
在飞书应用后台开启机器人能力，再配置事件订阅。常见的第一版事件包括：接收消息、机器人被加入群聊、群成员变更和消息已读状态。刚开始不要一次订阅所有事件，先只打开业务真正需要的部分。
事件订阅通常需要一个可访问的请求地址。飞书会向这个地址发送验证请求和事件通知，你的接入层需要完成三件事：
验证请求来源和校验字段。 快速返回成功，避免飞书重复推送。 将事件交给 WorkBuddy 编排层异步处理。
如果你使用现成的 WorkBuddy 连接器，通常只需填写回调地址和验证信息；如果自行搭建中转服务，则要特别注意重试、超时和幂等。所谓幂等，就是同一条消息重复到达时，系统不会重复创建任务或发送多次回复。
05 第四步：设计“触发—理解—执行—回复”链路
一个好用的飞书机器人，不是收到任何消息都回答，而是有明确的触发策略。推荐采用三种触发方式：
- 关键词触发： 适合日报、纪要、查制度等固定动作。
- @机器人触发： 适合群聊中的临时问题，避免打扰所有人。
- 按钮触发： 适合流程较长的任务，例如创建项目、提交请假、发起复盘。
收到触发后，WorkBuddy 可以按四步处理：
理解：识别用户意图、语言和上下文，判断是否需要追问。
检索：从已审核的知识库或指定文档中查找信息，不能靠猜测补齐事实。
执行：调用表格、日历、任务或内部系统，完成真正的业务动作。
回复：用一张简洁卡片呈现结论、来源、下一步和异常提示。
例如，用户说“把这周的客户反馈整理一下”，WorkBuddy 不应马上输出一篇长文，而应先确认范围：哪些群、什么时间段、输出给谁、是否需要脱敏。确认后再执行检索、归类和回写。
06 第五步：把飞书知识库接到 WorkBuddy
知识库是接入质量的分水岭。建议先整理四类资料：产品说明、流程规范、常见问答、异常处理。每份资料都标注负责人、生效时间、适用范围和版本号。
给 WorkBuddy 的规则可以这样写：
只使用已审核资料回答业务事实。若资料中没有答案，明确说明“暂时无法确认”，并给出人工入口。不得根据用户语气推断预算、职位、情绪或购买意愿。引用资料时，在内部记录文档名称和版本，不必把内部路径直接展示给外部客户。
如果团队资料分散在多个文档，先做主题归档，再做检索。不要把几十个互相矛盾的页面直接丢给模型。真正有效的知识库不是文件越多越好，而是每条规则都能找到负责人。
07 第六步：用飞书卡片承载结果
纯文本适合简单问答，结构化结果更适合工作协作。建议把以下内容做成卡片字段：
结论：一句话说明发生了什么。 明细：关键条目、负责人和截止时间。 风险：缺失信息、冲突内容或需要人工确认的地方。 操作：查看原文、创建任务、重新生成、转人工。
例如日报卡片可以分为“已完成、阻塞、明日计划、需要支持”四栏。会议纪要卡片则可以展示“决策、行动项、负责人、截止时间”。卡片越结构化，后续越容易被人复核，也越容易继续自动化。
注意不要把内部调试信息、密钥、完整用户隐私或模型思考过程放进卡片。对外只展示完成任务所需的信息。
08 第七步：设置权限、分组和人工接管
权限设计建议遵循“最小够用”。WorkBuddy 只申请完成当前场景所需的权限；需要读群消息，就不要顺便申请修改所有文档；需要创建任务，就不必默认拥有删除任务的权限。
可以按三类角色设计：
普通成员：查询公开资料、提交日报、查看自己的任务。 项目负责人：查看项目汇总、创建协作任务、触发复盘。 管理员：修改配置、管理知识库、查看审计记录。
当遇到投诉、付款、隐私、权限冲突或连续两次无法回答时，必须转人工。交接给人工时，至少附上客户或成员身份、最近对话摘要、已确认事实、待确认问题和建议下一步。不要把模型猜测写成事实。
09 第八步：建立测试清单，再逐步放量
上线前准备一组正常与异常输入：
□ 用户只说“你好”。
□ 用户在群里没有 @ 机器人。
□ 用户发送图片、语音或混合语言。
□ 知识库中没有对应答案。
□ 同一消息被重复推送。
□ 用户要求删除或导出个人信息。
□ 用户要求越权查看其他部门资料。
□ 飞书接口超时或 WorkBuddy 暂时不可用。
每条测试记录预期结果、实际结果和修复动作。上线时先选择一个群、一个流程和少量成员，观察一周再扩大范围。重点看四个指标：有效完成率、人工接管率、重复回复率和错误信息率。不要只看机器人回复了多少条。
10 给 WorkBuddy 的可复用提示词
请帮我设计一个 WorkBuddy 接入飞书的协作助手。第一阶段只支持项目群中的“日报”和“会议纪要”两个场景。请先输出：触发规则、字段字典、状态流转、知识库结构、飞书权限清单、卡片消息结构、失败处理和测试用例，不要直接生成最终代码。所有业务事实必须来自已审核资料；无法确认时要明确标记并转人工。对涉及隐私、权限、财务和投诉的问题停止自动化。每个模块都给出输入、输出、异常路径和验收标准。
让 WorkBuddy 先做方案，再做实现。每完成一个模块，就要求它给出输入输出示例和可观察日志。这样你能知道系统为什么做出某个动作，也能在出错时快速定位。
结语：让 AI 进入协作现场，但把边界留在人手里
WorkBuddy 接入飞书的价值，不是让群里多一个会说话的机器人，而是把重复的信息整理、查询、提醒和交接变成可复用流程。飞书负责承载团队协作，WorkBuddy 负责理解任务和编排工具，人负责确认业务事实、权限边界与关键决策。
建议从一个小场景开始：只接入一个群，只服务一个流程，只输出一种卡片。等团队愿意使用、知识库有人维护、异常有明确去向，再逐步扩展到文档、表格、日历和更多智能体能力。这样搭出来的 AI，才会真正成为团队的一部分。