企业官网建设流程全解析

背单词这个场景，放到 Notion 里做知识库是个好主意，但手工录入的成本一直劝退很多人：一个单词要查音标、查释义、找例句、填属性、选标签，再复制粘贴到 Notion 页面，平均一个词花两分钟，积累 100 个词就是一个下午。这次要聊的是怎么用 Workbuddy 把这个过程变成一键自动化——把生词清单丢过去，自动生成结构化的单词卡片，再按字段写入 Notion 数据库。

Workbuddy 是腾讯推出的效率智能体（Agent）产品，整体定位是在个人工作台里用自然语言完成多步自动化任务。它和 CodeBuddy 属于两条产品线：CodeBuddy 侧重代码开发和编程辅助，Workbuddy 更侧重办公场景、数据整理、信息同步和流程自动化。从当前公开信息看，Workbuddy 的核心能力来自三个方向：skill 技能扩展、连接器对接外部服务、自定义指令固化个人工作流。这对“生成单词卡片并导入 Notion”这类任务来说，恰好是完整闭环：用 skill 定义卡片模板，用连接器打通 Notion 数据库，用自定义指令固定整个执行流程。

这篇文章会围绕这个场景展开，内容包括 Workbuddy 的定位与核心能力、部署和连接器配置方式、自动化生成单词卡片的完整流程设计、功能测试与效果验证、Notion API 批量写入示例、常见问题排查以及使用建议。如果你已经在用 Notion 管理生词，或者正在调研用什么 Agent 工具承载固定重复的内容生产流程，这篇可以参考。

这里先把阅读预期说清楚：下面所有涉及 Workbuddy 的界面按钮、skill 配置格式、连接器名称的内容，都会尽量给出通用可用的方案，但由于不同版本界面存在差异，实际配置时请以你自己安装的版本为准。

1. Workbuddy 核心能力速览

从材料看，Workbuddy 的社区讨论集中在：skill 怎么编写、连接器怎么对接 Notion/Obsidian/钉钉多维表、定时任务怎么配置、自定义指令怎么写，以及如何用它搭建个人工作台。这些能力正好对应自动化内容生产的两类需求：一类是“把外部数据拉进来加工”，另一类是“把加工结果写到目标系统里”。

2. 适用场景与使用边界

2.1 适合谁用

• 外语学习者：每天积累生词，希望在 Notion 里形成带音标、释义、例句的单词卡片库。
• Notion 重度用户：已经建立了单词数据库、阅读笔记库或案例库，需要批量录入结构化数据。
• 内容生产者：需要批量生成术语表、产品名词解释、知识卡片。
• 效率工具折腾党：正在评估 Agent 工具能否替代重复复制粘贴操作。

2.2 能解决什么问题

手工录入单词卡片的流程，通常要经历查词、整理、录入三步。查词需要打开词典，整理需要确定卡片字段，录入需要在 Notion 里新建一条数据库记录并逐字段填写。Workbuddy 的方案是把这三步合并成一个指令：输入生词列表，自动查词并生成结构化卡片，再写入 Notion 指定数据库。

2.3 不适合什么场景

• 对释义准确性要求极高的场景：AI 生成的释义和例句需要人工复核，不能直接当作词典级内容发布。
• 需要严格版权合规的词典内容：不建议让模型直接复制有版权的词典释义和例句。
• 需要实时同步的高频协作场景：如果多人同时操作 Notion 数据库，建议先确认连接器的写入机制是否能满足并发要求。
• 离线环境且不想配置模型服务：如果本地无法访问模型服务，也不具备外部调用条件，自动化链路会受限。

2.4 合规边界

使用 Workbuddy 生成单词卡片并导入 Notion，需要注意：Notion 工作区内的数据是你自己的账号数据，批量写入前要确认数据库的权限范围，避免误写他人共享空间；生成内容涉及词典释义、例句、图片时，优先使用无版权或已授权的数据源；如果要对卡片内容进行二次分发，应人工审核并标注来源；不要把个人学习数据无防护地写入公共空间。

3. 环境准备与前置条件

3.1 需要准备什么

3.2 在 Notion 中创建单词卡片数据库

建议先在 Notion 中创建一个数据库，并预先设计字段。一个常见的单词卡片库结构如下：

这里的关键是：Notion 数据库里必须有一个标题类型的属性。Workbuddy 或 API 写入时，标题字段是必填的。如果数据库里没有标题列，创建页面时会报错。

3.3 Notion 集成 Token 的准备方法

如果走 API 写入，需要在 Notion 里创建一个集成（Integration），然后获取 Token 并授权给目标数据库。流程大概是：进入 Notion 的设置页面，找到“连接”或“集成”入口，新建集成后复制 Internal Integration Secret；然后在目标数据库页面右上角菜单里，把该集成添加为可连接对象。这个 Token 会作为请求头的 Authorization 使用。具体入口名称以你的 Notion 版本为准。

4. Workbuddy 部署与启动配置

4.1 安装与启动

从材料看，Workbuddy 提供常规客户端安装和本地部署两种路线，Linux 也有对应版本。实际安装方式以官方安装包和文档为准。

通用安装流程：

# 示例：下载安装包后，在终端启动（实际文件路径以你下载的版本为准） chmod +x workbuddy-installer ./workbuddy-installer # 启动客户端 workbuddy

如果使用一键包或安装向导，双击安装包后按提示完成安装即可。第一次启动通常需要登录账号，并选择一个工作目录用于存放任务配置、日志和导出文件。

4.2 新建自动化任务或技能

启动后先不急着生成卡片，建议按三件事走一遍：

1. 确认 Workbuddy 能正常对话或运行 skill。
2. 找到连接器配置页面，确认是否已提供 Notion 或 HTTP 类连接器。
3. 准备一段最简单的词表，跑通“输入 -> 生成 -> 写入”的最小链路。

如果你的版本没有内置 Notion 连接器，也可以让自动化流程输出符合 Notion API 格式的 JSON，再由一段脚本或 HTTP 连接器调用 Notion API 完成写入。后面第 7 节会给出一个可直接修改的 API 示例。

4.3 连接器配置思路

连接器的主要作用是让智能体能够写外部系统。针对 Notion，有两种联通方式：

• 方式一：使用 Workbuddy 内置的 Notion 连接器，在连接器配置里粘贴 Notion Token，并指定目标数据库 ID。
• 方式二：使用 HTTP 连接器，让自动化流程向 Notion API 发起 POST 请求。

方式二更通用，兼容性也更好，缺点是需要在流程里自己拼 JSON 报文。方式一配置更简单，但前提是你的 Workbuddy 版本确实支持 Notion 连接器。建议首次验证时优先用方式一；如果找不到相关配置，就切到方式二。

5. 一键生成单词卡片的自动化流程设计

5.1 整体链路

整个自动化流程可以拆成四步：

1. 输入：用户提供一批生词，可以手动粘贴，也可以导入一个生词文本文件。
2. 生成：Workbuddy 根据预设的单词卡片模板，为每个单词生成音标、词性、释义、例句等字段。
3. 结构化：把生成结果组装成符合 Notion 数据库字段的 JSON 数据。
4. 写入：通过连接器或 API 把数据写入 Notion 数据库，并返回写入结果。

5.2 自定义指令模板

如果 Workbuddy 支持在对话中调用自定义指令，可以准备这样一段固定指令，每次直接调用：

你是一个单词卡片助手。请把用户给出的单词列表，逐个生成单词卡片。 每个卡片必须包含以下字段： word：单词本身 phonetic：英式音标 part_of_speech：词性 definition：中文释义（简洁，不超过一行） example：一个英文例句 example_cn：对应中文翻译 tags：一个或多个标签，用逗号分隔 输出格式为 JSON 数组，示例： [ { "word": "mitigate", "phonetic": "/ˈmɪtɪɡeɪt/", "part_of_speech": "v.", "definition": "缓和，减轻", "example": "The policy helped mitigate the impact.", "example_cn": "该政策有助于减轻影响。", "tags": "六级,商务英语" } ] 只输出 JSON，不要输出多余解释。

这里有个实用技巧：指令最后一定要加“只输出 JSON，不要输出多余解释”。否则模型会在 JSON 前后输出说明文字，后续解析会比较麻烦。

5.3 词卡结构设计

在设计 Notion 数据库字段时，建议把尽量多的信息放到“富文本”和“多选”字段，避免使用复杂的关系属性和公式属性。原因很简单：API 写入富文本和多选字段最稳定，公式字段通常不能由 API 直接写入，需要 Notion 端预先定义公式逻辑。

一个推荐的结构：

• 标题字段：word
• 富文本字段：phonetic, part_of_speech, definition, example, example_cn
• 多选字段：tags
• 时间字段：created_time（可让 Notion 自动记录，或 API 写入）

5.4 批量词表输入

Workbuddy 处理批量任务时，输入规模会直接影响生成耗时。建议分批输入，每次 10 到 20 个单词。一个原因是生成质量更好，另一个原因是即使中途失败，也能快速定位是哪一批出了问题。可以在输入中明确提示“本次共有 15 个单词，请逐个生成”。

6. 功能测试与效果验证

6.1 单词语义生成测试

目的：验证 AI 是否准确理解单词含义并生成正确卡片。

操作：输入 5 个常见单词，检查输出 JSON 中每个字段是否有内容。

判断标准：

• 音标格式完整。
• 词性准确。
• 中文释义无歧义。
• 例句语法正确，翻译与例句对应。

如果发现释义偏差，检查自定义指令里是否写清了“使用英汉双解词典风格”，或者模型本身对冷门单词了解不足。冷门词建议在指令中补充“如果无法确定释义，请标注【待确认】”。

6.2 卡片结构完整性测试

目的：验证生成结果能否被下游脚本或连接器解析。

操作：让模型生成 5 个单词的 JSON 数组，将输出复制到一个 JSON 校验工具中检查格式。

判断标准：

• JSON 格式合法。
• 数组长度与输入单词数量一致。
• 每个对象字段完整，没有缺失。
• 字段值没有出现换行符导致 JSON 解析失败。

常见失败原因是模型在 JSON 字符串中加入了未转义换行，尤其是例句字段。如果出现这种情况，可以在指令中补充：example 字段不要包含换行。

6.3 Notion 导入测试

目的：验证数据能否真实写入 Notion 数据库。

操作：在 Notion 中创建一个测试数据库，只包含 word 标题字段和 definition 富文本字段，然后用 Workbuddy 的 Notion 连接器或 API 写入一条记录。

判断标准：

• Notion 数据库中出现了一条新记录。
• 标题字段的单词正确。
• definition 字段显示了中文释义。
• 重复执行同一条指令不会产生意外重复页面。

6.4 批量与重复执行测试

目的：验证批量任务稳定性和幂等性。

操作：输入 20 个单词，完整跑一遍流程，再输入同样的 20 个单词跑一遍。

判断标准：

• 第一次全部写入成功。
• 第二次如果没有做幂等控制，应该能看到重复记录；如果做了幂等控制，则不应新增重复记录。

更稳妥的做法是在 Notion 数据库里增加一个“唯一检查”逻辑：先按 word 查询数据库中是否已有该单词，如果已存在则跳过或更新，而不是直接插入。这个逻辑可以在自动化流程中写成“先查询再写入”。

7. 接口 API 与批量任务扩展

7.1 用 Notion API 写入单词卡片

如果你不希望依赖 Workbuddy 内置连接器，或者想把这个流程接入自己的脚本，可以直接调用 Notion API。下面是一个创建数据库页面的 Python 示例：

import requests import json import os NOTION_TOKEN = os.getenv("NOTION_TOKEN", "secret_替换为你的Token") DATABASE_ID = os.getenv("NOTION_DATABASE_ID", "替换为你的数据库ID") headers = { "Authorization": f"Bearer {NOTION_TOKEN}", "Notion-Version": "2022-06-28", "Content-Type": "application/json", } def create_word_card(word, phonetic, pos, definition, example, example_cn, tags=None): payload = { "parent": {"database_id": DATABASE_ID}, "properties": { "word": { "title": [ {"type": "text", "text": {"content": word}} ] }, "phonetic": { "rich_text": [ {"type": "text", "text": {"content": phonetic}} ] }, "part_of_speech": { "rich_text": [ {"type": "text", "text": {"content": pos}} ] }, "definition": { "rich_text": [ {"type": "text", "text": {"content": definition}} ] }, "example": { "rich_text": [ {"type": "text", "text": {"content": example}} ] }, "example_cn": { "rich_text": [ {"type": "text", "text": {"content": example_cn}} ] }, }, } if tags: payload["properties"]["tags"] = { "multi_select": [{"name": tag.strip()} for tag in tags.split(",") if tag.strip()] } resp = requests.post( "https://api.notion.com/v1/pages", headers=headers, json=payload, timeout=30, ) return resp.status_code, resp.json() if __name__ == "__main__": status, data = create_word_card( word="mitigate", phonetic="/ˈmɪtɪɡeɪt/", pos="v.", definition="缓和，减轻", example="The policy helped mitigate the impact.", example_cn="该政策有助于减轻影响。", tags="六级,商务英语", ) print(status) print(json.dumps(data, ensure_ascii=False, indent=2))

这段代码需要替换三个值：Token、数据库 ID、以及 Notion 数据库里的实际字段名。如果字段名不一致，请求会返回 400 错误，日志里会明确提示是哪个属性无效。

7.2 curl 写入示例

如果你只是想做一次快速验证，用 curl 也可以：

curl -X POST https://api.notion.com/v1/pages \ -H "Authorization: Bearer secret_替换为你的Token" \ -H "Notion-Version: 2022-06-28" \ -H "Content-Type: application/json" \ -d '{ "parent": {"database_id": "替换为你的数据库ID"}, "properties": { "word": {"title": [{"text": {"content": "ubiquitous"}}]}, "definition": {"rich_text": [{"text": {"content": "无处不在的"}}]} } }'

这个示例只写入了两个字段，验证链路完全够用。如果把字段名写错，Notion 会在响应里返回具体的属性错误。

7.3 批量任务设计

批量任务的关键是控制节奏和记录结果。参考实现思路：

words = [ {"word": "mitigate", "pos": "v.", "definition": "缓和，减轻"}, {"word": "ubiquitous", "pos": "adj.", "definition": "无处不在的"}, {"word": "pragmatic", "pos": "adj.", "definition": "务实的"}, ] success_count = 0 failure_records = [] for item in words: try: status, data = create_word_card( word=item["word"], phonetic=item.get("phonetic", ""), pos=item.get("pos", ""), definition=item.get("definition", ""), example=item.get("example", ""), example_cn=item.get("example_cn", ""), tags=item.get("tags", ""), ) if status in (200, 201, 202): success_count += 1 print(f"[OK] {item['word']}") else: failure_records.append({"word": item["word"], "status": status, "data": data}) print(f"[FAIL] {item['word']}: {status}") except Exception as exc: failure_records.append({"word": item["word"], "error": str(exc)}) print(f"[ERROR] {item['word']}: {exc}") print(f"写入完成，成功 {success_count}/{len(words)}，失败 {len(failure_records)} 条")

批量任务建议加两个机制：一是日志记录，把每条记录的写入状态落盘；二是失败重试，对 429 限流类错误和 5xx 服务错误做指数退避重试，重试次数控制在 3 次左右。

7.4 幂等控制

重复执行批量任务时，如果不做幂等控制，Notion 数据库里会出现重复卡片。建议用“先查询再写入”的策略：在调用创建接口之前，先调用查询接口检查该 word 是否已存在。Notion 的查询接口是 POST https://api.notion.com/v1/databases/{database_id}/query，请求体可以用 filter 过滤 word 标题字段。如果查询结果非空，就跳过创建或改为更新。

8. 资源占用与性能观察

8.1 观察什么

对于这类 Agent 自动化任务，性能重点不是显存，而是三个指标：单批任务耗时、接口成功率和输出稳定性。

建议在自动化流程里打印每个阶段的耗时：

import time start = time.time() # 调用 Workbuddy 技能生成单词卡片 cards = run_workbuddy_skill(words) print(f"生成耗时：{time.time() - start:.2f}s")

8.2 影响耗时的因素

• 单词数量：单批越多，生成越慢，建议 10 到 20 个一批。
• 模型能力：生成音标、释义和例句属于多步推理任务，模型越复杂耗时越长。
• 网络延迟：每次调用 Notion API 都有网络往返，批量写入时尤其明显。
• 限流策略：如果请求过快触发 Notion API 限流，会进入重试等待，整体耗时明显上升。

8.3 如何优化

• 先小批量验证，再把规模放宽到 20 个以上。
• 批量写入时，在请求之间加 0.2 到 0.5 秒的延时，降低限流概率。
• 如果每天只需要同步一次，用定时任务在低峰期执行。
• 输出格式尽量稳定，减少后续清洗成本。

9. 常见问题与排查方法

9.1 启动相关排查

如果本地部署时遇到启动问题，先检查三点：安装包版本是否与操作系统匹配；首次启动是否生成了配置目录；日志输出在哪个位置。从材料看，Workbuddy 存在 Linux 版本和麒麟版等不同发行版本，安装时务必对照自己系统的架构和版本选择安装包，交叉安装容易出现动态库缺失或启动闪退。

9.2 Notion 连接器排查

连接器配置完成后，建议先用一条测试数据验证连接是否正常。如果连接失败，优先检查 Token 是否还有效、数据库 ID 是否属于该集成可访问的范围，以及 Notion 网络请求是否被防火墙拦截。不要直接跑大批量任务，避免连接失败后留下一堆半成品数据。

10. 最佳实践与使用建议

10.1 先跑最小闭环

第一次配置时，不要追求完整功能。先在 Notion 建一个只有 word 和 definition 两个字段的测试数据库，用 1 个单词跑通“生成 -> 写入”链路。链路通了之后，再逐步增加 phonetics、example 等字段。

10.2 给 Notion 数据库设计预留字段

建议在数据库里额外预留一个 status 字段，用于标记卡片的复核状态，例如：待复核、已复核、已掌握。自动化生成的卡片默认标记为“待复核”。这样既能享受自动化带来的效率，又能避免未经人工确认的内容直接进入正式学习列表。

10.3 把自定义指令当作配置文件管理

把 Workbuddy 的自定义指令保存到一个 Markdown 或文本文件里，同时记录：指令版本、适用字段、最后修改时间。这样当 Notion 数据库结构变化时，可以快速更新指令并沉淀出新的版本。

10.4 批量任务要有日志和重试

任何自动写外部系统的任务，都要在本地保留一份结果日志。建议至少记录：

• 输入单词清单。
• 每条记录的写入结果。
• 失败原因。
• 重试次数。

日志可以简单写成 CSV，也可以用 JSON Lines 每行一条。不要指望模型输出永远稳定，日志是排查问题的基础。

10.5 注意版权和数据安全

单词卡片中的例句、释义如果来自公开词典，优先选用无版权限制的词典数据；AI 生成的例句建议人工复核。不要在 Notion 中写入包含个人敏感信息的生词笔记，如果确实需要记录，使用私有页面并控制共享范围。

11. 总结与下一步

这个方案把“查词、做卡、录入 Notion”这一条高频重复链路压缩成了一个动作。最值得先验证的有三点：Workbuddy 是否能按固定指令输出结构化 JSON、Notion 连接器或 API 是否能真实写入数据库、重复执行时能否避免重复数据。第一个验证的是模型的可控性，第二个验证的是联通性，第三个验证的是工程化程度。

最容易踩的坑也在前面出现：JSON 输出格式不稳定、Notion 字段名不匹配、批量任务缺少幂等控制。这三个问题解决之后，整个流程基本就能稳定运行。

下一步可以考虑把范围扩大：从单词卡片扩展到阅读笔记、律所案例库、产品术语表；或者把触发方式从手动指令升级为定时任务，每天自动从生词本提取新词并生成卡片。这个链路里已经积累下来的连接器配置、自定义指令模板和 API 写入脚本，未来对接其他知识库工具时也可以复用。

建议收藏这篇文章，动手配置时对照着一步步操作。实际配置时如果遇到和上文不一致的界面或参数，以你安装的 Workbuddy 版本和 Notion 页面实际字段为准。