企业官网建设流程全解析

WorkBuddy 这套教程最值得肯定的一点，不是把飞书和企业微信的接口文档罗列一遍，而是把两个办公平台接入同一个自动化流程这件事，拆成了零基础也能照着跑的 10 节课。我按资料里的顺序走了一遍之后，先说结论：如果你手头有 AI 服务、网页工具或内部脚本，想让它们在飞书、企业微信里变成机器人、定时任务、待办提醒，这套内容可以帮你少踩掉一大半配置坑。

但也要补一句：原始资料里没有直接给出明确的版本号、安装包下载方式，也没有逐张截图。所以我后面写到的示例配置统一按通用格式处理。开始实操前，先确认自己安装的 WorkBuddy 版本，再看对应文档里的字段名。示例配置可以帮你理解逻辑，不要无脑复制。

1. 先判断：WorkBuddy 接飞书和企业微信，对你到底有没有用

1.1 它解决的其实是“办公消息 + 业务流程”的联通

很多人一开始容易把这类工具当成聊天机器人插件，觉得装上就能自动聊天，其实不是。WorkBuddy 更准确的角色是“消息中枢 + 任务编排器”。它把飞书、企业微信回调进来的事件接收下来，再转成你能控制的流程，最后调用你配置好的脚本、AI 接口或网页工具。

先还原一个真实场景。你有一个内部 AI 问答服务，单独用网页玩没问题。但如果想让同事在飞书群里直接艾特机器人，把最近一周的销售数据总结成日报，再把日报推到企业微信工作群，这就涉及三个问题：消息怎么收、数据怎么读、返回结果怎么发。

WorkBuddy 解决的就是这一整条链路。它不负责替你写业务逻辑，也不保证你随便填一个接口地址就能跑通。它把平台接入、消息解析、流程调度这些重复工作收拢在一起，让你把精力放在真正要做的处理和输出上。

1.2 和 Coze、低代码平台有什么不一样

很多人会拿 WorkBuddy 和 Coze 智能体、飞书多维表格自动化、企业微信机器人插件放在一起比。我的理解是：Coze 偏向在云端把事情做完，你更多是选择已经封装好的节点；低代码平台偏表单、审批和页面搭建；而 WorkBuddy 更适合你手上已经有自己的代码、脚本或模型服务，缺的是一个能自由控制消息收发的桥。

这里没有谁绝对更好的说法。如果你完全不想碰配置，想用图形化界面快速搭一个客服机器人，直接用云平台也完全够用。如果你想留住数据、自己把控回调地址和权限，WorkBuddy 这种方式的灵活度会更高，但代价是前面几节课程里的配置步骤必须认真走一遍。

1.3 什么样的人建议直接按这套资料练习

根据这套资料的标题和常见使用场景，我建议下面几类人可以直接上手：

• 零基础，但身边有飞书或企业微信测试环境的开发者。
• 有 AI API 能力，但一直没有把模型能力接进办公 IM。
• 用飞书多维表格管理数据，想通过机器人自动读取、写入记录。
• 需要把日报、告警、待办推送到企业微信个人或群聊。

如果你是这几类，不要跳过前两课直接去配企业微信。先按 10 节课里的最小消息链路跑通，再继续往后加能力。否则，报错时你很难判断是平台配置问题，还是 WorkBuddy 本身的问题。

2. 零基础动手前，先把账号、回调地址和消息链路想清楚

2.1 检查三件事：账号权限、运行环境、回调地址

连接飞书和企业微信不是准备一个账号就行。动手之前，先把下面这些前置条件列出来。

不要以为有个人微信就能完成全部接入。飞书机器人通常要有一个企业主体，企业微信机器人也要先在管理后台创建自建应用。很多管理权限个人账号是开不了的。

2.2 回调地址为什么是重灾区

很多新手卡在“本地跑通了，但机器人没反应”。原因很简单：你在本地用的是 127.0.0.1，飞书和企业微信的服务器是不可能访问到这个地址的。平台要回调你的服务，你必须提供一个公网能访问到的地址。

开发阶段可以用云服务器、云函数或临时公网应用来充当回调地址。生产环境更建议直接使用 HTTPS。不要为了省事，把本地开发机长期暴露到公网，更不要把 App Secret 写死在网页前端代码里。

我见过最典型的安全问题，就是回调地址指向一台没有鉴权的服务，任何人拿到地址都能伪造请求。正确做法是：回调地址固定、密钥放服务端、请求必须校验签名。

注意：开发环境需要公网回调地址时，请先确认这台服务器或云函数是你自己可控的，并做好访问控制。

2.3 先画一条消息链路，别急着改代码

建议在文档里先画一条最简链路：

用户发消息 -> 平台事件回调 -> WorkBuddy 接收 -> 你的业务逻辑 -> 返回内容 -> 平台推送结果。

每一步的输入和输出是谁，谁触发下一步，一定要明确。排错时按这条链路一层层看，而不是直接怀疑代码有问题。如果这条链路你画不出来，说明对资料里的消息部分还没理解透，回看前两节课会更高效。

3. 飞书接入：从自建应用、事件订阅，到多维表格写入

3.1 创建应用，拿 App ID 和 App Secret

在飞书开放平台里新建企业自建应用，你会拿到 App ID 和 App Secret。App ID 在大多数场景下可以暴露，App Secret 不能。开通机器人能力时，平台会提示你申请权限；建议按最小权限原则，先只开接收消息、读取多维表格这一组，不够再加。

一个容易漏的步骤：创建完应用后，还要发布，让企业内成员可见。否则配置再正确，同事在飞书群里也搜不到你的机器人。

3.2 配置事件订阅，处理 URL 校验

接下来在事件订阅里填写回调地址，并设置校验令牌。飞书验证地址时，会向你的回调地址发一个 challenge，你的服务需要把这个值原样返回，校验才通过。

WorkBuddy 一般会提供现成的 challenge 处理逻辑，不需要自己重复实现。但你得确认回调地址对应的路由已经被正确声明。下面是一份通用配置示例：

{ "app_id": "cli_xxxxxxxx", "app_secret": "请放在服务端环境变量，不要写进前端代码", "callback_url": "https://your-domain.example.com/callback/feishu", "verify_token": "自定义字符串，仅用于 URL 校验" }

注意，这只是一个结构示例，具体字段名要以你安装的 WorkBuddy 版本文档为准。不同版本对变量命名差异很大，照搬很容易踩坑。

3.3 接收私聊消息和群聊 @ 消息

飞书机器人可以接收私聊消息，也能接收群聊里艾特它的消息。事件订阅中要添加接收消息事件，并为应用开启消息权限。群聊场景下，需要正确解析 chat_id、message_id 和文本内容。

这里最容易出的问题有两个：一是事件订阅开了，但权限没申请，平台回调会提示权限不足；二是机器人没有拉进群聊，导致事件根本不会触发。

我一般会先把机器人单独私聊一句纯文本，确认日志里有回调记录后，再去做群聊和多维表格的联动。这样能把平台配置问题隔离在业务逻辑之前。

3.4 再往下接飞书多维表格

飞书多维表格经常被拿来当轻量数据库用。WorkBuddy 可以读取多维表格里的记录，也可以把 AI 返回结果写回指定视图中。配置时一般需要拿到 App Token、表格 ID 和视图 ID。

一个比较实用的组合是：企业微信收到用户发来的申请，WorkBuddy 把文本拆成结构化字段，写入飞书多维表格，再自动创建一条待办。整个过程串起来之后，很多人工复制粘贴的工作就可以去掉。

但要注意，多维表格接口对数据格式有要求，日期、人员、附件字段的处理方式不完全一样。第一次接入时，先手动写入一条测试记录，确认字段类型能对齐，再考虑批量写入。

4. 企业微信接入：自建应用、消息推送，再到任务待办

4.1 创建内部应用，收集四个关键参数

企业微信接入之前，先创建一个内部自建应用。你需要重点关注四个参数。

创建好应用后，把成员加入应用可见范围。否则即使接口调用成功，目标成员也收不到消息。

发送消息前，还有一个非常容易忽略的配置：可信 IP。企业微信要求调用接口的服务器 IP 必须在可信列表中。如果你的服务器出口 IP 换了，接口会直接报错。网上不少旧教程把这一步省略了，新手对着教程配完还是不生效，多半就卡在这里。

4.2 从发送文本升级到 Markdown 消息

如果只是快速验证，直接发一条文本消息就够了。

{ "touser": "zhangsan", "msgtype": "text", "agentid": 1000002, "text": { "content": "WorkBuddy 测试消息，收到请回复" } }

确认能收到后，再改成 Markdown，把日报、告警、待办标题用加粗和换行整理好。企业微信的 Markdown 语法和公众号不完全一样，它不支持复杂 HTML，配色和排版能力也有限。不要把前端排版习惯直接搬过来。

{ "touser": "zhangsan", "msgtype": "markdown", "agentid": 1000002, "markdown": { "content": "**今日日报**\n> 已完成：3 项\n> 风险：1 项" } }

这里仍然要强调，字段名和接口地址以官方文档和你使用的 WorkBuddy 版本为准。我给出的只是最常用的消息结构。

4.3 指定接收人：个人、部门还是标签

企业微信消息的接收对象可以按人、部门、标签来设置，也可以设置成按部门或标签发送。这里要特别注意权限：应用只能给可见范围内的成员发消息。如果成员不在可见范围里，就算你填对了 touser，接口一样会拒绝。

推送群聊则要先分组：自建应用消息和群机器人是两套不同逻辑。自建应用更适合做审批、日报、待办这类需要指定成员的任务；群机器人更适合做告警通知。WorkBuddy 里建议把两类场景拆成两个不同流程，不要混在一个任务里。

4.4 把任务待办写进企业微信

除了发消息，企业微信还支持创建待办。常见做法是：WorkBuddy 识别出用户消息里的任务描述，调用待办接口创建一条待办，再把提醒消息推给负责人。

我建议把待办接口封装成一个独立 Skill，输入是标题、描述和时间，输出是创建结果。这样飞书触发、企业微信触发都能复用。第一次对接时，先创建一条手工待办，确认该应用有创建待办的权限，再做批量逻辑。

注意：不要一上来就把所有机器人能力都打开，更不要一次配置完所有权限。先用最小权限跑通消息，再逐步增加多维表格、待办、文件上传这些能力。

5. 把重复工作变成 Skill，别每次都从零写流程

5.1 Skill 到底是一层什么东西

Skill 不是某种神秘的 AI 能力，它本质上是一组可复用的输入规则、处理逻辑和输出格式。你可以把它理解成一个小程序包：来了什么任务，调什么函数，最后输出什么消息。

举例：周报总结 Skill 可以接收飞书群里的多条周报文本，调用大模型提炼成要点，再发到企业微信群里。如果没有 Skill，这个流程每次都要手动配置一遍，消息来源一变就要重新调。

5.2 一个通用 Skill 的配置结构

实际落地时，Skill 可以包含触发条件、执行步骤和输出动作。下面是一份结构示例：

{ "name": "weekly_summary", "trigger": { "type": "keyword", "source": ["feishu", "wecom"], "keywords": ["周报", "汇总"] }, "steps": [ { "action": "collect_text_from_feishu_group", "chat_id": "oc_xxx" }, { "action": "call_llm", "prompt": "把下面内容整理成周报，按完成、风险、计划分类" }, { "action": "send_wecom_message", "target": "group_xxx" } ] }

注意，这是一份逻辑示例，不是某个固定标准。WorkBuddy 的不同版本对 Skill 的字段名、触发器类型和执行动作都有差异。你需要看着自己的文档调整，而不是把这段 JSON 直接当成配置导入。

5.3 Skill 的边界：哪些任务不要急着 Skill 化

有三类任务不要一上来就 Skill 化。

第一，还没有调试稳定的任务。流程本身还会频繁改动，提前封装成 Skill 只会增加维护成本。第二，运行频率很低的临时任务。如果一个任务几个月才用一次，直接写死在流程里反而更直观。第三，和某个平台强绑定、几乎不可能复用的任务。Skill 化的核心价值是复用，如果整个场景只有一个入口，写死更简单。

比较好的习惯是：先在页面或代码里把脚本跑通，再提炼成 Skill，最后再考虑加定时触发和清理上下文。不要在一开始就追求完美的抽象设计。

6. 上下文用量满了、消息收不到、任务卡住，按这个顺序排

6.1 上下文用量满了怎么办

WorkBuddy 在处理长对话或长文本时，会遇到“上下文用量满了”的提示。字面意思很好懂：它用来保存对话或计算请求的临时空间不够了。但解决办法不是一律清空历史。

建议按这个顺序处理：

1. 检查是否保留了太多历史消息，把历史保留条数调小。
2. 长文档按章节拆开处理，不要一次性全塞给模型。
3. 单次任务里减少不必要的附加上下文。
4. 最后才考虑调大上下文参数。上下文调大后，单次请求的消耗会明显上升。

如果只是写日报、总结消息这种短文本任务，用短上下文就够，不需要追求大窗口。开太大的上下文，速度会变慢，成本也会上升。

6.2 消息发不出去或收不到

消息相关的问题，不要上来就改代码。建议先按下面的优先级排查：

没有回调日志，说明问题出在平台配置，而不是 WorkBuddy 的业务逻辑。有回调日志但结果不对，才轮到检查代码和参数。

6.3 任务卡住，先看资源占用、输出目录和队列

如果任务不报错但一直卡住，我一般先看三样东西：进程是否还在、磁盘是否写满、输出目录是否可写。很多模型下载半路失败、本地文档解析生成临时文件失败，都会表现为卡住。

批量任务卡住就更要小心。先看看是不是把并发开得太高，把 CPU 和内存耗尽了。再把超时时间调短，给失败任务增加重试。低配置机器能跑通单条任务，不代表能扛批量任务。批量跑之前，先用小样本压一次，观察资源占用和平均耗时，再决定要不要加并发。

6.4 错误码和版本差异怎么处理

平台错误码不要靠猜。飞书、企业微信都有自己的错误码表，搜一下错误码更容易定位到是权限问题、IP 问题还是参数问题。WorkBuddy 自身版本相关的报错，先看它的更新日志，不要直接从旧文章复制配置。

从我之前的经验来看，大部分“服务异常”类错误，最后都发现是权限没开、IP 没加白名单或回调地址填错。真正需要深入代码的问题反而是少数。

7. 我的学习顺序：先跑通一条消息，再做完整场景

7.1 把 10 节课程重新排一个顺序

这套资料如果叫“从入门到精通”，我不建议按目录顺序一口气看下去。更推荐分成四个阶段：

• 阶段一：最小链路。安装、启动、发一条消息，理解 WorkBuddy 的基本界面和日志位置。
• 阶段二：单平台接入。先选飞书或企业微信其中一个，把机器人跑通。
• 阶段三：数据与 Skill。接入多维表格，把重复流程抽象成 Skill。
• 阶段四：生产化。定时任务、上下文管理、日志、安全、批量任务。

同时接飞书和企业微信的人，更建议先只接一个平台。等全流程稳定后，再复制到第二个平台。不要两边同时调，否则报错的时候很难分清是哪个平台的权限、回调或参数出了问题。

7.2 单任务稳定后，再考虑批量和自动化

如果只是学习，默认配置通常够用。但如果要放在生产环境长期跑，必须在任务队列上提前做设计。批量任务至少要有：输入清单、输出命名、失败重试、幂等控制。否则定时任务一次跑 50 条消息，中间失败 10 条，就只能靠人工补。

举例来说，多个机器人给不同群发日报，如果任务 A 失败、任务 B 成功，你至少能在日志里看到每个任务的成功与否，而不是只知道“整体跑了”。输出文件也要有统一命名规范，比如按日期、群名、任务 ID 组合，否则后期回查非常痛苦。

7.3 安全底线和日常维护

连接办公系统之后，数据隐私和权限边界就非常敏感。下面是几条底线：

• App Secret、Webhook 密钥、API Key 全部放服务端环境变量，不要提交到 Git。
• 回调地址强制使用 HTTPS，并对请求做验签。
• 平台权限使用最小集，不把所有接口权限都打开。
• 定期清理离职成员的账号和过期的应用凭据。
• 日志中不要明文打印密钥、手机号、完整聊天内容。

这些基础都做好之后，再增加更复杂的自动化场景。如果一开始就把安全放在最后，后面改起来会非常尴尬。

回到开头那句话：WorkBuddy 这类工具的真正难点，不是某一个字段有多难配，而是把飞书、企业微信、多维表格、AI 服务、日志和权限这条完整链路串起来。先跑通一条消息，再按阶段加功能，最后再考虑批量和生产化。把 10 节课程当成一份练习地图，按最小链路跑，比从第一页背到最后一页要实用得多。