企业官网建设流程全解析

1. 从手动整理日报到自动推送：openclaw SKILL 与飞书机器人联动到底解决什么问题

每天临近下班，很多人都会经历同一个场景：翻聊天记录、回忆今天做了什么、把零散结论拼成一段话，再复制到飞书群里。事情本身不难，但重复、琐碎、容易漏。openclaw 的 SKILL 机制正好切中这个痛点——它把「总结今天聊了什么」变成一条可复用的技能，配合飞书机器人 Webhook，就能把日报按固定时间推到目标群。

openclaw 是一个支持 SKILL 扩展的智能体运行环境，SKILL 可以理解为一份带说明文档和源码的「技能包」，里面写清楚触发条件、执行逻辑和输出格式。飞书机器人则是飞书开放平台提供的群消息入口，只要拿到 Webhook 地址，就能用 HTTP 请求往群里发消息。把这两者接起来，日报助手就成型了：白天正常对话，晚上 22:00 自动生成结构化总结，或者你说一句「总结一下今天」立刻触发。

这套方案适合谁？适合每天需要在飞书群里同步进度的小团队、需要写日报但不想手打的开发者、以及想把重复汇报流程自动化的运营同学。它不依赖复杂的中台系统，一个 SKILL 目录、一个 Webhook、一份配置就能跑起来。下面我会从 SKILL 的目录结构讲起，给出可复制的 config.json、飞书消息卡片模板，再演示手动触发和定时触发两种验证方式，最后把常见的 401、local proxy failed、reading choices 报错逐个拆开。

核心检索词先明确：openclaw SKILL 飞书日报自动推送，指的是用 openclaw 的 SKILL 能力生成每日总结，并通过飞书机器人 Webhook 定时或手动推送到群。理解这一点，后面的配置就不会迷路。

2. TaoToken 前置准备：给 openclaw SKILL 接上模型能力与飞书 Webhook 配置

openclaw 的 SKILL 本身负责意图识别和总结生成，但「总结」这一步需要调用大模型。这里我用 TaoToken 作为模型接入层，它的 API 地址是 https://taotoken.net/api，兼容常见的对话补全接口格式，配置起来比较直接。你需要先准备好两样东西：一个可用的 API Key，以及飞书群的 Webhook 地址。

先拿 API Key。打开 https://taotoken.net/api-keys ，登录后创建一个新的 Key，复制保存。注意 Key 只在创建时完整显示一次，丢了就重新建。这个 Key 后面会写进 openclaw 的环境变量或 config.json，不要硬编码到会提交到 Git 的文件里。

再配飞书 Webhook。在飞书群里点「设置」→「群机器人」→「添加机器人」→「自定义机器人」，起个名字比如「日报助手」，然后复制生成的 Webhook 地址，形如 https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxxxx。如果你希望消息只发给某个人而不是群，可以用 Open ID 方式，但群推送用 Webhook 最简单，本文以群 Webhook 为主。

接下来确认 openclaw 的 SKILL 目录能被识别。openclaw 一般会扫描指定目录下的 SKILL.md 和 src/，所以你要把 daily-summary-skill 放到它约定的 skills 路径里。不同版本路径可能不同，常见的是 ~/.openclaw/skills/ 或项目根目录下的 skills/。放好后重启 openclaw，让它重新加载技能列表。

模型侧建议单独建一个环境变量文件，比如 .env，内容如下：

TAOTOKEN_API_KEY=你的Key TAOTOKEN_BASE_URL=https://taotoken.net/api FEISHU_WEBHOOK=https://open.feishu.cn/open-apis/bot/v2/hook/你的hook

这样 SKILL 里的代码通过 os.environ 读取，既安全又方便切换环境。如果你更习惯用配置文件，也可以写进 config.json，但记得把该文件加入 .gitignore。前置准备做完，就可以进入 SKILL 的具体配置了。

3. 可复制配置：openclaw SKILL 的 config.json、飞书消息卡片模板与定时任务

这一节是全文最核心的部分，所有片段都可以直接复制后改参数。先看 SKILL 的目录结构，保持和 openclaw 约定一致：

daily-summary-skill/ ├── SKILL.md ├── src/ │ ├── __init__.py │ ├── intent_recognizer.py │ └── summary_generator.py └── data/ └── config.json

SKILL.md 是技能说明，openclaw 靠它判断什么时候加载这个技能。内容要写清楚触发词和用途，例如：

# Daily Summary Skill ## 触发方式 - 手动：用户说“总结一下今天”“今日总结”“生成日报”“今天聊了些什么” - 自动：每晚 22:00 由定时任务触发 ## 功能 1. 提炼 3-5 个当日核心议题或结论 2. 整理待办事项，标注优先级 3. 识别未形成结论、值得跟进的潜在议题 4. 将结构化报告推送到飞书群

config.json 负责存配置。注意原文里 Open ID 是硬编码的，这里我改成从环境变量读取，同时保留 Webhook 字段，方便多用户扩展：

{ "model": { "base_url": "https://taotoken.net/api", "api_key_env": "TAOTOKEN_API_KEY", "model_id": "claude-3-5-sonnet", "max_tokens": 1200, "temperature": 0.3 }, "feishu": { "webhook_env": "FEISHU_WEBHOOK", "msg_type": "interactive", "card_title": "今日工作总结" }, "schedule": { "enabled": true, "cron": "0 22 * * *", "timezone": "Asia/Shanghai" }, "summary": { "max_topics": 5, "include_todo": true, "include_potential": true } }

飞书消息卡片用 interactive 类型，视觉上比纯文本清晰。下面是一个可复制的卡片模板，放在 summary_generator.py 里拼接：

def build_feishu_card(topics, todos, potentials): elements = [] elements.append({ "tag": "div", "text": {"tag": "lark_md", "content": "**核心议题**\n" + "\n".join(f"- {t}" for t in topics)} }) elements.append({"tag": "hr"}) elements.append({ "tag": "div", "text": {"tag": "lark_md", "content": "**待办事项**\n" + "\n".join(f"- {t}" for t in todos)} }) elements.append({"tag": "hr"}) elements.append({ "tag": "div", "text": {"tag": "lark_md", "content": "**潜在议题**\n" + "\n".join(f"- {t}" for t in potentials)} }) return { "msg_type": "interactive", "card": { "header": {"title": {"tag": "plain_text", "content": "今日工作总结"}}, "elements": elements } }

定时任务用 cron 表达式 0 22 * * *，表示每天 22:00。openclaw 如果自带调度器，直接在 config.json 里开 enabled 即可；如果没有，可以用系统 crontab 调一个触发脚本。触发脚本的核心是调用 SKILL 的入口函数，把当天对话内容传进去。手动触发则靠 intent_recognizer.py 匹配关键词，匹配到就调用 summary_generator。

这里要提醒一点：模型 ID 要和你 TaoToken 账号下可用的模型一致，不确定就先在模型对话页试一下。Base URL、Key、Model ID 这三件套必须同时正确，缺一个都会在请求阶段报错。配置写完后，先别急着上定时，手动跑一次确认链路通。

4. 验证请求与成功结果：手动触发一次日报推送并检查飞书群消息

配置写完，第一步是手动触发，确认从对话到飞书群的整条链路能跑通。先启动 openclaw，确认技能列表里出现 daily-summary-skill。然后输入触发词，比如「总结一下今天」。如果 intent_recognizer 正常，它会识别意图并调用 summary_generator。

手动触发时，建议先在代码里加一行日志，打印实际请求的 URL 和模型 ID，方便排错：

import os, requests, json def call_model(prompt): base = os.environ.get("TAOTOKEN_BASE_URL", "https://taotoken.net/api") key = os.environ["TAOTOKEN_API_KEY"] url = f"{base}/v1/chat/completions" headers = {"Authorization": f"Bearer {key}", "Content-Type": "application/json"} payload = { "model": "claude-3-5-sonnet", "messages": [{"role": "user", "content": prompt}], "max_tokens": 1200, "temperature": 0.3 } print("REQUEST URL:", url) resp = requests.post(url, headers=headers, json=payload, timeout=60) print("STATUS:", resp.status_code) return resp.json()

请求成功后，返回体里会有 choices 数组，取 choices[0].message.content 就是总结文本。拿到文本后，按前面的卡片模板拼成 JSON，再 POST 到飞书 Webhook：

def push_to_feishu(card): webhook = os.environ["FEISHU_WEBHOOK"] resp = requests.post(webhook, json=card, timeout=30) print("FEISHU STATUS:", resp.status_code, resp.text) return resp.json()

飞书 Webhook 成功时返回 {"code":0,"msg":"success"}，群里会立刻出现一张卡片，包含核心议题、待办事项、潜在议题三个区块。如果返回 code 非 0，先看 msg 字段，常见的是签名校验失败或 Webhook 失效。

手动验证通过后，再验证定时触发。把 config.json 的 schedule.enabled 设为 true，cron 设成 0 22 * * *。为了快速验证，可以临时把 cron 改成两分钟后，比如当前 15:30，就写 32 15 * * *。等时间到，观察 openclaw 日志是否自动调用，以及飞书群是否收到消息。确认无误后再改回 22:00。

实测下来，最容易出问题的不是模型调用，而是飞书卡片的 JSON 结构。lark_md 的 content 里换行要用 \n，列表符号要自己拼，飞书不会自动渲染 Markdown 列表。另外卡片元素数量别太多，超过限制会被截断。手动和定时都跑通，这个日报助手就算真正落地了。

5. 本篇常见错排查：401、local proxy failed、reading choices 与 OAuth 报错逐个拆

链路跑不通时，报错信息通常很直接，关键是知道去哪查。下面按出现频率从高到低拆。

401 Unauthorized。这是最常见的一类，说明模型请求没通过鉴权。先确认 TAOTOKEN_API_KEY 是否写对、有没有多余空格、是否已过期。再确认请求头格式是 Authorization: Bearer ，少 Bearer 或拼错都会 401。如果 Key 是从环境变量读的，打印一下 os.environ.get("TAOTOKEN_API_KEY") 的前几位，确认真的读到了。还有一种情况是 Base URL 写成了 https://taotoken.net/api/ 带尾斜杠，拼接后变成 //v1/chat/completions，部分网关会拒绝，统一去掉尾斜杠。

local proxy failed。这个报错通常出现在请求根本没发出去的时候，说明本机网络层或代理配置有问题。检查环境变量里有没有 HTTP_PROXY、HTTPS_PROXY 指向一个不可用的地址，有就临时 unset 掉再试。如果你在容器里跑，确认容器能解析外部域名。这个错误和模型无关，纯粹是网络出口问题，先把 curl https://taotoken.net/api 跑通再谈其他。

reading choices 相关报错，比如 KeyError: 'choices' 或 reading 'choices' of undefined。这说明请求返回了，但返回体里没有 choices 字段，通常是返回了错误 JSON。打印完整 resp.text 看真实内容，常见原因是模型 ID 写错，网关返回了 model not found；或者 max_tokens 超限被拒。把 model 字段改成账号下确实可用的 ID，再重试。

OAuth 报错。如果你用的是需要 OAuth 的接入方式，报错往往和 token 刷新有关。检查 refresh token 是否过期、scope 是否包含所需权限。用 API Key 方式接入时一般不会遇到 OAuth，如果你混用了两种方式，确认请求头没有同时带冲突的凭证。

飞书侧还有两个高频问题：Webhook 返回 19021 表示签名校验失败，检查是否开启了签名校验但没传 secret；返回 19001 表示 Webhook 地址无效，重新复制一次。把这几类报错对照日志逐个排除，基本能覆盖 90% 的失败场景。

6. 语义一致 CTA：把 openclaw 日报助手接到长期编码与 Agent 工作流

日报助手跑通之后，你会发现它只是 openclaw SKILL 能力的一个切面。同样的机制可以扩展到周报生成、会议纪要归档、代码提交摘要推送。如果你打算把这类自动化长期跑下去，建议把模型接入和调度统一管理，避免每个 SKILL 各配一套 Key。

模型接入层继续用 TaoToken，API 地址 https://taotoken.net/api ，Key 在 https://taotoken.net/api-keys 管理。想先验证模型输出质量，可以去模型对话页 https://taotoken.net/model-chat 试几轮总结提示词，确认风格符合团队习惯再写进 SKILL。如果你要跑的是长期编码或 Agent 类任务，比如让 openclaw 持续处理仓库事件并推送，可以看 Coding Plan https://taotoken.net/coding-plan ，它更适合高频、长周期的调用场景。接入文档在 https://taotoken.net/doc ，配置细节以文档为准。

回到日报助手本身，最后给你一个实用技巧：把每天的总结文本同时落一份到本地 data/ 目录，按日期命名，比如 2025-06-01.md。这样即使飞书消息被刷走，你也能回溯。落盘逻辑加在 push_to_feishu 之前，几行代码的事，但长期看很值。