刚接手一个部门级的自动化需求时我最大的感受是工具其实不难找难的是把日常琐碎的工作流真正串起来。文件整理要写脚本发票报销要手工录入周报要翻聊天记录竞品分析要开十几个网页——这些事情单看都不难但每天都做就非常消耗精力。这篇文章不打算做浮于表面的功能罗列而是围绕 WorkBuddy 办公自动化实战完整拆解四个高频场景批量处理文件、发票识别与信息提取、自动生成周报、竞品分析报告。文章会从基础概念讲到本地部署与 Skill 配置再到 Python 脚本与实际工作流的结合方式。不管你是刚开始接触办公自动化的新手还是已经在用 AI 工具提升效率的进阶用户都能从里面找到可以直接复用的方案。1. WorkBuddy 是什么不止是一个聊天框1.1 办公自动化需求为什么越来越复杂传统办公自动化一般依靠几条路Excel 宏、Windows 批处理、Python 脚本、RPA 机器人。这些方案各有优势但普遍存在三个问题。第一门槛不低。写宏要懂 VBA写脚本要会 PythonRPA 拖拽流程同样有学习成本。第二维护成本高。业务一变流程就要跟着改脚本和流程经常在运行半年后变得没人敢动。第三智能化程度不够。传统自动化只能处理结构化、规则明确的任务遇到“把这周项目风险总结一下”这种模糊需求传统脚本完全无能为力。WorkBuddy 这类 AI 智能体工作台的出现正好补上了这块空缺。它把大模型能力、脚本执行、外部工具连接和定时任务放在同一个平台里让办公自动化从“写死规则”变成了“用自然语言描述任务由智能体调度工具完成”。需要说明的是WorkBuddy 仍在快速迭代中不同版本的界面布局和功能入口可能不一样。这篇文章说的配置思路和实战步骤重点是方法论具体入口请以你安装的版本为准。1.2 WorkBuddy 与 CodeBuddy 的区别很多同学第一次接触 WorkBuddy 时会把它和 CodeBuddy 搞混。从产品定位上看二者有明显分工产品定位典型用户主要场景CodeBuddyAI 编程助手 / 智能编程环境开发者代码生成、代码解释、单元测试、Debug、编译运行WorkBuddyAI 智能体工作台办公人员、运营、产品、开发者自动化工作流、文件处理、信息提取、报告生成、第三方工具联动简单理解CodeBuddy 是帮你写代码的WorkBuddy 是帮你干活的。WorkBuddy 内部的 Skill 和脚本能力会涉及代码但它面向的目标是把重复劳动自动化而不是替代 IDE。1.3 WorkBuddy 的核心概念在进入实战之前先统一几个关键词。后面所有案例都会用到智能体WorkBuddy 里可以理解为“一个拥有特定角色和任务的 AI 助手”。你可以创建多个智能体分别负责文件整理、周报生成、竞品分析等。Skill技能模块。相当于给智能体附加的工具能力可以是提示词模板也可以是一个可执行的 Python 脚本。Skill 是 WorkBuddy 自动化能力的核心。连接器用于连接外部系统比如钉钉、企业微信、飞书多维表、数据库、邮件服务等。连接器负责数据的读取与回流。工作流把多个步骤编排成一个自动化流程。例如定时触发 → 读取多维表 → 调用模型总结 → 生成周报 → 发送到指定群。定时任务给工作流配置触发时间实现“每天几点自动运行”。自动周报的核心依赖就是定时任务。从这些概念可以看出WorkBuddy 并不是简单套壳的聊天机器人它更接近一个轻量级自动化平台。你可以把它理解成“会调用工具的大模型 可编排的自动化流水线”。2. 环境准备与部署方式2.1 先明确你的使用方式WorkBuddy 的使用方式可以分成三类按从易到难排序网页版 / 客户端直连最简单注册账号后直接用平台提供的云端能力。本地容器部署把服务部署在自己电脑或内网服务器上数据不出内网适合对数据安全要求较高的团队。配合本地模型使用比如在 WorkBuddy 中配置本地部署的千问系列模型适合需要完全离线或私有化运行的场景。如果是个人学习和体验推荐先用网页版或客户端跑通流程。如果是企业场景尤其是涉及发票、合同、客户资料等敏感信息建议优先考虑本地部署或内网环境。2.2 本地部署的大致流程这里不写死具体命令因为不同版本差异较大。但整体步骤遵循下面的顺序准备一台 Linux 服务器推荐 Ubuntu 20.04 及以上版本。麒麟系统等国产化环境也有对应版本配置思路一致。安装 Docker 和 Docker ComposeWorkBuddy 服务端通常以容器方式运行。根据官方文档拉取镜像编写 docker-compose.yml配置端口、数据目录、模型服务地址等。启动服务后通过浏览器访问管理界面创建账号并配置模型。需要注意一个小细节如果你在 Linux 下使用 WorkBuddy 的 CLI 或者查看用户目录可能会看到类似.workbuddy这样的隐藏文件夹。前面带点号代表这是隐藏目录用来存放配置、日志、技能脚本等数据。Linux 下用ls -a才能看到。版本要求没有统一标准请以官方发布说明为准。本文示例重点演示配置思路不绑定某个特定版本号。2.3 模型服务的配置思路WorkBuddy 本身是一个智能体工作台它的“大脑”依赖大模型接口。常见的配置方式有两种第一种是使用平台内置的云端模型开箱即用适合快速验证。第二种是配置自定义模型地址例如在内网部署一套开源模型服务再把接口地址填到 WorkBuddy 的模型配置中。如果你打算用开源模型做本地部署建议优先关注上下文长度和工具调用能力。WorkBuddy 的 Skill 调用、连接器操作非常依赖模型遵循指令的能力参数规模太小的模型在复杂工作流中容易出现格式错乱、工具调用失败等问题。模型地址通常长这样http://192.168.1.100:8000/v1在 WorkBuddy 后台配置自定义模型时一般需要填写模型名称与本地模型服务注册的名称保持一致。API 地址指向模型服务的兼容接口。API Key如果本地服务开启了鉴权则需要填写。上下文长度根据模型实际支持长度填写避免超出限制导致报错。如果你只是体验功能直接用平台默认模型即可。生产环境建议在测试环境完整验证后再切换。3. 核心能力拆解Skill、连接器与工作流3.1 Skill让智能体拥有执行能力Skill 是 WorkBuddy 自动化架构里最核心的概念。没有 Skill 的智能体只能“动嘴”有了 Skill 的智能体才能“动手”。一个 Skill 通常包含两部分一是描述文件告诉智能体这个技能是干什么的、什么时候该用、参数怎么传二是执行脚本最常见的是 Python 脚本负责真正操作文件、调用接口、处理数据。举个例子如果我想让智能体具备批量重命名文件的能力Skill 描述文件可以这样写name: batch_rename description: 批量重命名指定目录下的文件支持添加前缀、后缀和替换关键字。 parameters: - name: directory type: string required: true description: 需要处理的文件目录路径 - name: prefix type: string required: false description: 添加的文件名前缀 - name: keyword type: string required: false description: 需要替换的旧关键字 - name: replacement type: string required: false description: 替换后的新关键字这只是描述部分告诉模型“这个技能可以做什么、需要哪些参数”。真正的执行逻辑由脚本完成。后面实战部分我会给出完整的 Python 脚本。这里有一个非常重要的设计原则不要让模型自己凭空写代码去操作文件系统而是让模型学会调用你提前写好的 Skill。前者不可控后者才是稳定的自动化方案。3.2 连接器打通外部系统连接器解决的是“数据从哪来、结果送到哪去”的问题。典型的连接器包括钉钉连接器读取钉钉审批、多维表、群消息也可以往群里发消息。飞书连接器类似钉钉支持多维表格、云文档。企业微信连接器支持消息推送、客户联系。数据库连接器连接 MySQL、PostgreSQL 等执行查询。Webhook 连接器以 HTTP 方式与任意系统交互。在实际项目中连接器最常见的用途是“定期同步”。例如把钉钉多维表中的任务记录同步到 WorkBuddy触发周报生成工作流。这里要注意所有连接器的授权都必须遵循最小权限原则只授予当前任务所需的读取或写入权限不要把管理员权限随便挂上去。3.3 工作流把步骤编排起来工作流解决的是“多个步骤按什么顺序执行”的问题。一个完整的自动周报工作流可能是这样的定时触发每周五 17:30 自动运行。读取数据通过钉钉连接器读取本周多维表中的任务记录。调用模型把任务记录和本周目标发送给大模型生成周报初稿。调用 Skill执行脚本把周报格式化为 Markdown。发送结果连接企业微信把周报发送到指定群或指定成员。使用表格创建工作流时不用把每一步想得特别复杂。核心思路就是“数据流”数据从哪里进、中间经过哪些加工、最终输出到哪里。4. 实战一批量处理文件4.1 需求分析批量处理文件是办公自动化里最普遍的需求典型场景包括每个月要把销售合同统一重命名为“客户名称_合同编号_日期.pdf”。要把多个 Excel 文件合并成一个总表。要把一批 Word 文档按规则拆分、合并或转换为 PDF。要把图片文件按拍摄日期归档到不同文件夹。下面的案例以“批量重命名 文件归档 Excel 合并”为例演示如何用 Skill 实现。4.2 创建 Skill 目录在 WorkBuddy 中创建一个新的 Skill命名为file_ops。Skill 目录结构可以参考下面的形式workbuddy_skills/ └── file_ops/ ├── SKILL.md └── main.pySKILL.md描述技能用途和参数main.py是真正的执行脚本。4.3 编写 Skill 描述文件文件路径workbuddy_skills/file_ops/SKILL.md# 文件批量处理技能 ## 功能 批量处理本地文件支持以下操作 1. 批量重命名文件 2. 按规则创建目录并归档文件 3. 合并一个文件夹下的所有 Excel 文件 ## 参数说明 - action: 操作类型可选值为 rename / archive / merge_excel - directory: 要处理的文件目录绝对路径 - prefix: 重命名时添加的前缀可空 - keyword: 重命名时需要替换的旧关键字可空 - replacement: 替换后的新关键字可空 ## 使用注意事项 - 所有操作都会打印日志。 - 出于安全考虑脚本默认不执行删除操作。 - 请确认真实业务需求后再调用。这段描述的作用是让 WorkBuddy 的智能体在遇到文件操作请求时能够自动判断该调用哪个脚本、传什么参数。4.4 编写文件处理脚本文件路径workbuddy_skills/file_ops/main.pyimport os import shutil import sys import argparse from datetime import datetime def batch_rename(directory: str, prefix: str , keyword: str , replacement: str ): 批量重命名文件 if not os.path.isdir(directory): print(f[ERROR] 目录不存在: {directory}) return for filename in os.listdir(directory): file_path os.path.join(directory, filename) if os.path.isfile(file_path): new_name filename if keyword and keyword in new_name: new_name new_name.replace(keyword, replacement) if prefix: new_name prefix new_name new_path os.path.join(directory, new_name) if new_path ! file_path: os.rename(file_path, new_path) print(f[RENAME] {filename} - {new_name}) def archive_by_date(directory: str): 按文件修改日期归档到 年/月 目录 if not os.path.isdir(directory): print(f[ERROR] 目录不存在: {directory}) return for filename in os.listdir(directory): file_path os.path.join(directory, filename) if os.path.isfile(file_path): mtime os.path.getmtime(file_path) dt datetime.fromtimestamp(mtime) target_dir os.path.join(directory, str(dt.year), f{dt.month:02d}) os.makedirs(target_dir, exist_okTrue) target_path os.path.join(target_dir, filename) if not os.path.exists(target_path): shutil.move(file_path, target_path) print(f[ARCHIVE] {filename} - {target_dir}) else: print(f[SKIP] {filename} 目标文件已存在) def merge_excel(directory: str): 合并目录下所有 Excel 文件到一个新的 Excel 文件 try: import pandas as pd except ImportError: print([ERROR] 缺少 pandas请先运行 pip install pandas openpyxl) return all_data [] for filename in os.listdir(directory): if filename.endswith((.xlsx, .xls)): file_path os.path.join(directory, filename) try: df pd.read_excel(file_path) df[来源文件] filename all_data.append(df) print(f[READ] {filename} 读取成功共 {len(df)} 行) except Exception as e: print(f[WARN] {filename} 读取失败: {e}) if all_data: merged pd.concat(all_data, ignore_indexTrue) output_path os.path.join(directory, fmerged_{datetime.now().strftime(%Y%m%d_%H%M%S)}.xlsx) merged.to_excel(output_path, indexFalse) print(f[MERGED] 合并完成共 {len(merged)} 行输出文件: {output_path}) else: print([INFO] 没有读取到任何 Excel 文件) if __name__ __main__: parser argparse.ArgumentParser(descriptionWorkBuddy 文件批量处理技能) parser.add_argument(--action, requiredTrue, choices[rename, archive, merge_excel]) parser.add_argument(--directory, requiredTrue) parser.add_argument(--prefix, default) parser.add_argument(--keyword, default) parser.add_argument(--replacement, default) args parser.parse_args() if args.action rename: batch_rename(args.directory, args.prefix, args.keyword, args.replacement) elif args.action archive: archive_by_date(args.directory) elif args.action merge_excel: merge_excel(args.directory)4.5 在 WorkBuddy 中调用配置好 Skill 后你不需要手动执行脚本。在 WorkBuddy 对话界面直接输入请帮我把 /data/contracts 目录下的所有 PDF 文件重命名添加前缀“2025_”并把文件名中的“合同”替换为“contract”。智能体会根据SKILL.md的描述自动识别出这是文件重命名任务并调用file_ops技能传入对应的 action 和参数。这里要提醒一点脚本运行在 WorkBuddy 所在机器的文件系统上。如果你使用网页版脚本可能运行在云端沙箱环境中如果你使用本地部署版本脚本直接运行在你的内网服务器上。建议所有路径参数都使用绝对路径避免因为工作目录不一致导致找不到文件。5. 实战二发票识别与信息提取5.1 业务背景发票识别是财务场景里最高频的自动化需求。报销时要把发票上的代码、号码、日期、金额、税额、购买方、销售方等信息录入系统还要做发票查重和真伪校验。人工录入不仅慢还容易看错数字。WorkBuddy 实现发票识别的思路很清晰通过 Skill 调用 OCR 能力提取发票图片中的文字。通过大模型对提取结果做结构化整理输出为 JSON。通过连接器把结构化数据写入报销系统或飞书/钉钉多维表。5.2 发票识别脚本示例这里给出一个基于 Python 的简化版方案。实际项目中你可能需要根据发票类型做更精细的字段适配。文件路径workbuddy_skills/invoice_ocr/main.pyimport os import json import sys import argparse from datetime import datetime try: import pdfplumber except ImportError: pdfplumber None try: from paddleocr import PaddleOCR except ImportError: PaddleOCR None def extract_text_from_pdf(pdf_path: str) - str: 从 PDF 发票中提取文本 if pdfplumber is None: return text_parts [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: page_text page.extract_text() if page_text: text_parts.append(page_text) return \n.join(text_parts) def extract_text_from_image(image_path: str) - str: 从图片发票中提取文本OCR if PaddleOCR is None: return ocr PaddleOCR(use_angle_clsTrue, langch, show_logFalse) result ocr.ocr(image_path, clsTrue) lines [] for line in result: for item in line: lines.append(item[1][0]) return \n.join(lines) def structure_invoice(raw_text: str) - dict: 将 OCR 原始文本交给大模型做结构化提取。 这里提供规则兜底方案生产环境建议调用模型接口。 # 简单兜底提取关键字段 data { invoice_code: , invoice_number: , date: , amount_total: , amount_tax: , buyer_name: , seller_name: , } for line in raw_text.split(\n): line line.strip() if 发票代码 in line or 发票号码 in line: # 如果 OCR 结果在同一行按冒号或空格切分 for key, label in [(invoice_code, 发票代码), (invoice_number, 发票号码)]: if label in line: val line.split(label, 1)[-1].strip().lstrip(: \t) data[key] val if 开票日期 in line: data[date] line.split(开票日期, 1)[-1].strip().lstrip(: \t) if 价税合计 in line or 小写 in line: val line.split(小写, 1)[-1].strip().lstrip((¥) ) if val: data[amount_total] val if 购买方 in line or 名 in line and 称 in line: # 简化逻辑实际需要更精细的行解析 pass return data def process_invoice(file_path: str, output_path: str): 处理单张发票 if not os.path.exists(file_path): print(f[ERROR] 文件不存在: {file_path}) return ext os.path.splitext(file_path)[1].lower() if ext .pdf: raw_text extract_text_from_pdf(file_path) elif ext in (.jpg, .jpeg, .png, .bmp): raw_text extract_text_from_image(file_path) else: print(f[ERROR] 不支持的文件格式: {ext}) return if not raw_text: print([ERROR] 未提取到任何文本请检查发票清晰度) return result structure_invoice(raw_text) result[source_file] os.path.basename(file_path) result[process_time] datetime.now().strftime(%Y-%m-%d %H:%M:%S) with open(output_path, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2) print(json.dumps(result, ensure_asciiFalse, indent2)) def batch_process(directory: str, output_dir: str): 批量处理目录下的所有发票 os.makedirs(output_dir, exist_okTrue) supported (.pdf, .jpg, .jpeg, .png, .bmp) for filename in os.listdir(directory): if filename.lower().endswith(supported): file_path os.path.join(directory, filename) output_path os.path.join(output_dir, os.path.splitext(filename)[0] .json) print(f\n 处理文件: {filename} ) process_invoice(file_path, output_path) if __name__ __main__: parser argparse.ArgumentParser(descriptionWorkBuddy 发票识别技能) parser.add_argument(--mode, requiredTrue, choices[single, batch]) parser.add_argument(--file, default) parser.add_argument(--directory, default) parser.add_argument(--output, default./output) args parser.parse_args() if args.mode single and args.file: process_invoice(args.file, os.path.join(args.output, single_result.json)) elif args.mode batch and args.directory: batch_process(args.directory, args.output) else: print([ERROR] 请检查参数single 模式需要 --filebatch 模式需要 --directory)5.3 让大模型优化提取精度上面代码里的structure_invoice函数只是兜底规则真实项目中建议把 OCR 原始文本直接发给大模型让大模型按字段输出 JSON。做法是在 WorkBuddy 中设置一个提取发票字段的提示词模板大致思路如下你是一个发票信息提取助手。请从下面的OCR原始文本中提取以下字段并以JSON格式输出 发票代码、发票号码、开票日期、购买方名称、销售方名称、不含税金额、税额、价税合计。 要求 1. 如果某个字段无法确定输出空字符串。 2. 不要编造数据。 3. 金额统一保留两位小数。 OCR原始文本 {raw_text}通过 WorkBuddy 的工作流可以让脚本负责 OCR 提取大模型负责结构化理解最后再合并输出。这种“OCR LLM”双引擎方案比单纯依赖规则正则要稳定得多。5.4 合规范式提醒发票属于敏感财务数据处理时务必注意识别后的 JSON 文件建议保存在内网环境不要随意上传到公网。使用网页版 WorkBuddy 时注意确认数据合规要求。配置连接器写入报销系统时只申请“新增单据”权限不要使用管理员账号。批量处理前先在测试目录放两张真实样票验证输出格式。6. 实战三自动生成周报6.1 周报为什么适合自动化周报的痛点不在于“写”而在于“收集”。一周的工作分散在任务系统、聊天记录、会议纪要、多维表里靠人工回忆往往漏掉细节。自动周报的本质不是让 AI 凭空编内容而是把散落的数据集中起来再由 AI 生成结构化的总结。6.2 用钉钉多维表同步数据假设你们团队用钉钉多维表管理任务那么周报工作流可以这样设计连接器定时读取多维表中的任务记录。将记录中的“任务名称、负责人、状态、完成时间、备注”提取出来。结合本周工作计划调用大模型生成周报。在 WorkBuddy 中配置连接器时通常需要选择数据源类型、授权方式以及同步范围。保存后可以手动触发一次同步确认数据能正确读取。有一点要注意多维表里的字段名最好规范统一。如果字段一会儿叫“任务标题”一会儿叫“任务事项”大模型在理解时会产生偏差。6.3 周报生成的提示词模板在 WorkBuddy 中可以创建一个“周报生成器”智能体并保存提示词模板你是一位项目助理请根据以下任务记录生成一份结构清晰的周报。 周报要求 1. 以 Markdown 格式输出。 2. 包含四个部分本周完成、当前风险、下周计划、需要协调的资源。 3. 每条任务用一两句话概括成果突出结果和价值。 4. 风险部分只列出确定性较高的问题不要强行凑数。 5. 语言简洁不要出现“赋能”“抓手”等空话。 本周任务记录 {task_records} 本周目标 {weekly_goal}{task_records} 和 {weekly_goal} 是变量工作流运行时会自动替换为真实数据。6.4 定时任务配置在 WorkBuddy 中把周报工作流保存后可以配置定时触发。建议的触发时间选在周五下班前 1 小时左右例如每周五 16:30留出人工检查和微调的时间。配置定时任务时需要考虑几个问题时区设置是否与团队所在时区一致。多维表数据是否已经更新到最新状态。生成后的周报是直接发送给群还是先推送给本人确认再发送。直接发送虽然省事但风险是 AI 生成的内容可能包含不准确的信息。稳妥的做法是先生成草稿通过企业微信或钉钉推送给成员确认再一键发布。6.5 定时发送微信消息的注意事项有同学希望 WorkBuddy 能“定时发送微信消息”。这个需求在个人微信上实现是有合规风险的不建议通过非官方接口操作。在企业微信、钉钉、飞书等办公协同软件中通过官方 API 推送消息是合规的。一个稳妥的替代方案是周报生成后推送到企业微信群机器人利用 Webhook 地址接收消息。这类机器人配置简单安全性高也是目前团队里最常见的做法。7. 实战四竞品分析报告7.1 需求分析竞品分析看起来简单做起来非常耗时。你需要人工访问竞品官网、翻阅行业新闻、查看应用商店评论、整理竞品的功能变化最后再形成一份报告。WorkBuddy 可以把“收集、整理、生成、发送”全流程自动化。不过要强调竞品信息收集必须遵守法律法规尊重版权和数据使用条款。不要用爬虫暴力抓取需要登录才能访问的内容也不要绕过对方的风控机制。优先使用官方公开资料、新闻稿、应用商店公开信息等渠道。7.2 设计竞品分析工作流一个基础的竞品分析工作流如下定时触发每天早上 9:00 执行。信息收集通过搜索 API 或 RSS 获取竞品相关新闻。网页内容抓取抓取目标网页正文过滤广告和导航噪音。大模型提炼把新闻内容归纳成功能更新、市场动态、潜在威胁三条线。报告生成按固定模板生成 Markdown 报告。推送发送到企业微信群或邮件。7.3 信息收集脚本示例下面是一个简化的新闻信息收集脚本思路可以作为 Skill 的一部分文件路径workbuddy_skills/competitor_analysis/main.pyimport os import json import argparse import requests from datetime import datetime, timedelta from bs4 import BeautifulSoup def fetch_news_from_rss(rss_urls, days7): 从 RSS 源获取近期新闻标题和链接 import feedparser cutoff datetime.now() - timedelta(daysdays) results [] for url in rss_urls: try: feed feedparser.parse(url) for entry in feed.entries[:20]: published entry.get(published_parsed) if published is None: continue pub_date datetime(*published[:6]) if pub_date cutoff: results.append({ title: entry.get(title, ), link: entry.get(link, ), summary: entry.get(summary, )[:500], published: pub_date.strftime(%Y-%m-%d %H:%M) }) except Exception as e: print(f[WARN] 读取 RSS 失败 {url}: {e}) return results def fetch_page_content(url: str) - str: 抓取单个页面的正文内容仅限公开页面 headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } try: resp requests.get(url, headersheaders, timeout15) resp.encoding resp.apparent_encoding soup BeautifulSoup(resp.text, html.parser) for tag in soup([script, style, nav, footer, aside]): tag.decompose() return soup.get_text(separator\n, stripTrue)[:3000] except Exception as e: return f[ERROR] {e} if __name__ __main__: parser argparse.ArgumentParser(description竞品信息收集技能) parser.add_argument(--rss, nargs, helpRSS 源地址列表) parser.add_argument(--output, default./competitor_news.json) args parser.parse_args() if args.rss: news fetch_news_from_rss(args.rss) with open(args.output, w, encodingutf-8) as f: json.dump(news, f, ensure_asciiFalse, indent2) print(f[DONE] 获取到 {len(news)} 条新闻输出到 {args.output}) else: print([ERROR] 请指定 --rss 参数)是的这里用了feedparser和BeautifulSoup。如果环境中没有安装可以用 pip 安装pip install feedparser beautifulsoup4 requests7.4 让模型生成竞品分析报告拿到新闻数据后把数据交给大模型生成报告。WorkBuddy 中可以设置如下提示词你是一名市场分析师。请根据以下收集到的竞品相关新闻生成一份竞品动态日报。 报告结构 ### 竞品动态概览 ### 功能与产品更新 ### 市场与商务动态 ### 潜在风险与机会 ### 建议采取的行动 要求 1. 每个条目都要注明信息来源链接。 2. 区分事实和推测推测内容必须标注“推测”。 3. 报告长度控制在 800 字以内。 4. 如果某个部分没有相关信息写“暂无明显动态”而不是编造。 新闻内容 {news_data}这份报告生成后可以通过企业微信连接器在每天早上推送到项目群。长期坚持下来团队对竞品的感知会明显加强。8. 常见问题与排查思路在实际使用 WorkBuddy 的过程中最容易遇到的问题集中在网络连接、Skill 调用、定时任务、本地部署几个方面。我整理了一些高频问题问题现象常见原因解决思路WorkBuddy 网络连接失败错误码 3002内网部署时网络代理配置不对或模型服务地址不可达检查 WorkBuddy 所在机器是否能访问模型服务检查代理设置用 curl 命令验证接口连通性找不到 Claw 面板或相关功能版本过低或该功能未在当前版本开放尝试升级到最新版本在设置中检查功能开关到官方文档确认入口名称Skill 脚本执行报错Python 依赖缺失、路径不对、权限不足查看 WorkBuddy 日志在命令行手动执行脚本定位问题确认脚本目录有执行权限定时任务不触发时区配置错误、定时任务未启用检查定时任务状态确认时区设置先手动触发一次确认工作流本身可用连接器同步失败授权过期、字段名不匹配、接口限流重新授权连接器检查数据源字段名稍后重试或调整同步频率本地模型响应很慢模型参数量过大、GPU 显存不足、并发过高降低并发数更换小参数模型检查 GPU 推理优化参数生成的周报内容偏差较大输入数据不完整、提示词不明确检查多维表字段补充周报模板示例增加 “基于以下数据” 的强约束遇到问题的时候不要急着删配置。按照下面的顺序排查先确认是 WorkBuddy 本身的问题还是外部服务的问题。最直接的方法是看日志。确认网络连通性。本地部署最容易踩的坑就是模型服务地址写成了 localhost但 WorkBuddy 运行在容器里localhost 指向的是容器本身。把 Skill 脚本从 WorkBuddy 里拆出来在命令行单独执行。这样可以快速区分是脚本问题还是智能体调用问题。查看输入的 prompt 和最终传给大模型的内容。如果大模型收到的数据就是乱的生成结果一定不会好。9. 最佳实践与工程建议9.1 从“单点自动化”开始不要一上来就搭建庞大的自动化体系。先选一个最耗时、规则最清晰的任务比如文件重命名或报销发票信息录入把它做成 Skill。跑通之后再逐步扩展。这种做法的好处是即使某个 Skill 设计得不合理影响范围也很小。随着你对 WorkBuddy 的能力边界越来越清楚再规划复杂工作流时成功率会高很多。9.2 Skill 设计要有明确的输入输出Skill 本质上是给智能体用的“工具接口”。设计 Skill 时要把参数说明写清楚把边界条件想清楚。脚本内部要打印足够详细的日志这样在 WorkBuddy 里面看不到执行细节时可以直接去日志文件里查。脚本的退出码也很重要。建议所有 Skill 脚本遵循统一约定0 表示成功非 0 表示失败。这样 WorkBuddy 工作流可以根据退出码判断是否继续执行后续步骤。9.3 Prompt 模板要固定版本不要频繁修改生产环境使用的提示词模板。每次修改前把旧版本另存一份在测试环境验证通过后再发布。AI 生成结果具有不确定性频繁调整提示词会导致输出格式和内容风格漂移影响下游数据处理。建议为常用模板建立命名规范例如weekly_report_v1.md invoice_extract_v2.md competitor_daily_v3.md9.4 重视数据安全与权限控制办公自动化涉及的数据往往比想象的更敏感。发票包含纳税人识别号周报可能包含项目进展和成本信息竞品分析报告可能涉及公司商业策略。以下几点务必落实连接器权限最小化只授予任务必要的数据权限。本地部署时对 WorkBuddy 管理后台设置强密码和访问白名单。涉及批量处理文件时先复制一份到测试目录不要在源目录直接执行高风险操作。涉及数据库操作时先明确事务边界重要操作前先备份。9.5 建立“人审 自动化”的双轨机制自动化不是完全取代人工而是把重复劳动干掉把人的精力集中到决策和审核上。周报、竞品分析这类内容型任务AI 生成之后一定要有人工审核环节。你可以把审核放在工作流内部也可以放在结果推送之前。比较稳妥的机制是自动化收集数据与生成初稿。人工在线修改。机器负责格式化和发送。这样既保证了效率又保证了内容质量。9.6 定期复盘工作流运行情况每个月花一点时间看看哪些 Skill 使用频率高、哪些工作流经常失败。长期不用的自动化任务建议先暂停不要让它每天空转浪费资源。经常失败的任务则要评估是不是设计思路有问题或者业务场景已经发生变化。10. 总结与下一步学习路线到这里我们已经完整走过了 WorkBuddy 办公自动化的核心闭环从产品概念到环境部署从 Skill 原理到四个实战场景再到高频问题排查和工程化建议。你可以从如下方向继续深入把批量处理文件技能扩展到更多格式例如 Word、PDF、PPT 的批量转换与内容抽取。在发票识别基础上接入报销系统实现“识别 → 校验 → 录入 → 推送审批”全链路自动化。在自动周报基础上加入月度总结、季度 OKR 复盘形成更完整的汇报体系。在竞品分析基础上加入舆情监控对行业热点事件进行实时追踪。研究 WorkBuddy 与 CodeBuddy 的联动用 CodeBuddy 写代码、用 WorkBuddy 跑自动化形成开发与业务的双通道效率提升。无论选择哪个方向都建议遵守一条原则让 AI 处理重复、繁杂、数据密集的环节让人处理判断、决策、审核的环节。这也是 WorkBuddy 这类智能体工作台最正确的打开方式。希望这篇 WorkBuddy 使用教程能帮你少走一些弯路尽快把自己的日常工作流自动化跑起来。
WorkBuddy办公自动化实战：AI智能体驱动的高频场景全拆解
刚接手一个部门级的自动化需求时我最大的感受是工具其实不难找难的是把日常琐碎的工作流真正串起来。文件整理要写脚本发票报销要手工录入周报要翻聊天记录竞品分析要开十几个网页——这些事情单看都不难但每天都做就非常消耗精力。这篇文章不打算做浮于表面的功能罗列而是围绕 WorkBuddy 办公自动化实战完整拆解四个高频场景批量处理文件、发票识别与信息提取、自动生成周报、竞品分析报告。文章会从基础概念讲到本地部署与 Skill 配置再到 Python 脚本与实际工作流的结合方式。不管你是刚开始接触办公自动化的新手还是已经在用 AI 工具提升效率的进阶用户都能从里面找到可以直接复用的方案。1. WorkBuddy 是什么不止是一个聊天框1.1 办公自动化需求为什么越来越复杂传统办公自动化一般依靠几条路Excel 宏、Windows 批处理、Python 脚本、RPA 机器人。这些方案各有优势但普遍存在三个问题。第一门槛不低。写宏要懂 VBA写脚本要会 PythonRPA 拖拽流程同样有学习成本。第二维护成本高。业务一变流程就要跟着改脚本和流程经常在运行半年后变得没人敢动。第三智能化程度不够。传统自动化只能处理结构化、规则明确的任务遇到“把这周项目风险总结一下”这种模糊需求传统脚本完全无能为力。WorkBuddy 这类 AI 智能体工作台的出现正好补上了这块空缺。它把大模型能力、脚本执行、外部工具连接和定时任务放在同一个平台里让办公自动化从“写死规则”变成了“用自然语言描述任务由智能体调度工具完成”。需要说明的是WorkBuddy 仍在快速迭代中不同版本的界面布局和功能入口可能不一样。这篇文章说的配置思路和实战步骤重点是方法论具体入口请以你安装的版本为准。1.2 WorkBuddy 与 CodeBuddy 的区别很多同学第一次接触 WorkBuddy 时会把它和 CodeBuddy 搞混。从产品定位上看二者有明显分工产品定位典型用户主要场景CodeBuddyAI 编程助手 / 智能编程环境开发者代码生成、代码解释、单元测试、Debug、编译运行WorkBuddyAI 智能体工作台办公人员、运营、产品、开发者自动化工作流、文件处理、信息提取、报告生成、第三方工具联动简单理解CodeBuddy 是帮你写代码的WorkBuddy 是帮你干活的。WorkBuddy 内部的 Skill 和脚本能力会涉及代码但它面向的目标是把重复劳动自动化而不是替代 IDE。1.3 WorkBuddy 的核心概念在进入实战之前先统一几个关键词。后面所有案例都会用到智能体WorkBuddy 里可以理解为“一个拥有特定角色和任务的 AI 助手”。你可以创建多个智能体分别负责文件整理、周报生成、竞品分析等。Skill技能模块。相当于给智能体附加的工具能力可以是提示词模板也可以是一个可执行的 Python 脚本。Skill 是 WorkBuddy 自动化能力的核心。连接器用于连接外部系统比如钉钉、企业微信、飞书多维表、数据库、邮件服务等。连接器负责数据的读取与回流。工作流把多个步骤编排成一个自动化流程。例如定时触发 → 读取多维表 → 调用模型总结 → 生成周报 → 发送到指定群。定时任务给工作流配置触发时间实现“每天几点自动运行”。自动周报的核心依赖就是定时任务。从这些概念可以看出WorkBuddy 并不是简单套壳的聊天机器人它更接近一个轻量级自动化平台。你可以把它理解成“会调用工具的大模型 可编排的自动化流水线”。2. 环境准备与部署方式2.1 先明确你的使用方式WorkBuddy 的使用方式可以分成三类按从易到难排序网页版 / 客户端直连最简单注册账号后直接用平台提供的云端能力。本地容器部署把服务部署在自己电脑或内网服务器上数据不出内网适合对数据安全要求较高的团队。配合本地模型使用比如在 WorkBuddy 中配置本地部署的千问系列模型适合需要完全离线或私有化运行的场景。如果是个人学习和体验推荐先用网页版或客户端跑通流程。如果是企业场景尤其是涉及发票、合同、客户资料等敏感信息建议优先考虑本地部署或内网环境。2.2 本地部署的大致流程这里不写死具体命令因为不同版本差异较大。但整体步骤遵循下面的顺序准备一台 Linux 服务器推荐 Ubuntu 20.04 及以上版本。麒麟系统等国产化环境也有对应版本配置思路一致。安装 Docker 和 Docker ComposeWorkBuddy 服务端通常以容器方式运行。根据官方文档拉取镜像编写 docker-compose.yml配置端口、数据目录、模型服务地址等。启动服务后通过浏览器访问管理界面创建账号并配置模型。需要注意一个小细节如果你在 Linux 下使用 WorkBuddy 的 CLI 或者查看用户目录可能会看到类似.workbuddy这样的隐藏文件夹。前面带点号代表这是隐藏目录用来存放配置、日志、技能脚本等数据。Linux 下用ls -a才能看到。版本要求没有统一标准请以官方发布说明为准。本文示例重点演示配置思路不绑定某个特定版本号。2.3 模型服务的配置思路WorkBuddy 本身是一个智能体工作台它的“大脑”依赖大模型接口。常见的配置方式有两种第一种是使用平台内置的云端模型开箱即用适合快速验证。第二种是配置自定义模型地址例如在内网部署一套开源模型服务再把接口地址填到 WorkBuddy 的模型配置中。如果你打算用开源模型做本地部署建议优先关注上下文长度和工具调用能力。WorkBuddy 的 Skill 调用、连接器操作非常依赖模型遵循指令的能力参数规模太小的模型在复杂工作流中容易出现格式错乱、工具调用失败等问题。模型地址通常长这样http://192.168.1.100:8000/v1在 WorkBuddy 后台配置自定义模型时一般需要填写模型名称与本地模型服务注册的名称保持一致。API 地址指向模型服务的兼容接口。API Key如果本地服务开启了鉴权则需要填写。上下文长度根据模型实际支持长度填写避免超出限制导致报错。如果你只是体验功能直接用平台默认模型即可。生产环境建议在测试环境完整验证后再切换。3. 核心能力拆解Skill、连接器与工作流3.1 Skill让智能体拥有执行能力Skill 是 WorkBuddy 自动化架构里最核心的概念。没有 Skill 的智能体只能“动嘴”有了 Skill 的智能体才能“动手”。一个 Skill 通常包含两部分一是描述文件告诉智能体这个技能是干什么的、什么时候该用、参数怎么传二是执行脚本最常见的是 Python 脚本负责真正操作文件、调用接口、处理数据。举个例子如果我想让智能体具备批量重命名文件的能力Skill 描述文件可以这样写name: batch_rename description: 批量重命名指定目录下的文件支持添加前缀、后缀和替换关键字。 parameters: - name: directory type: string required: true description: 需要处理的文件目录路径 - name: prefix type: string required: false description: 添加的文件名前缀 - name: keyword type: string required: false description: 需要替换的旧关键字 - name: replacement type: string required: false description: 替换后的新关键字这只是描述部分告诉模型“这个技能可以做什么、需要哪些参数”。真正的执行逻辑由脚本完成。后面实战部分我会给出完整的 Python 脚本。这里有一个非常重要的设计原则不要让模型自己凭空写代码去操作文件系统而是让模型学会调用你提前写好的 Skill。前者不可控后者才是稳定的自动化方案。3.2 连接器打通外部系统连接器解决的是“数据从哪来、结果送到哪去”的问题。典型的连接器包括钉钉连接器读取钉钉审批、多维表、群消息也可以往群里发消息。飞书连接器类似钉钉支持多维表格、云文档。企业微信连接器支持消息推送、客户联系。数据库连接器连接 MySQL、PostgreSQL 等执行查询。Webhook 连接器以 HTTP 方式与任意系统交互。在实际项目中连接器最常见的用途是“定期同步”。例如把钉钉多维表中的任务记录同步到 WorkBuddy触发周报生成工作流。这里要注意所有连接器的授权都必须遵循最小权限原则只授予当前任务所需的读取或写入权限不要把管理员权限随便挂上去。3.3 工作流把步骤编排起来工作流解决的是“多个步骤按什么顺序执行”的问题。一个完整的自动周报工作流可能是这样的定时触发每周五 17:30 自动运行。读取数据通过钉钉连接器读取本周多维表中的任务记录。调用模型把任务记录和本周目标发送给大模型生成周报初稿。调用 Skill执行脚本把周报格式化为 Markdown。发送结果连接企业微信把周报发送到指定群或指定成员。使用表格创建工作流时不用把每一步想得特别复杂。核心思路就是“数据流”数据从哪里进、中间经过哪些加工、最终输出到哪里。4. 实战一批量处理文件4.1 需求分析批量处理文件是办公自动化里最普遍的需求典型场景包括每个月要把销售合同统一重命名为“客户名称_合同编号_日期.pdf”。要把多个 Excel 文件合并成一个总表。要把一批 Word 文档按规则拆分、合并或转换为 PDF。要把图片文件按拍摄日期归档到不同文件夹。下面的案例以“批量重命名 文件归档 Excel 合并”为例演示如何用 Skill 实现。4.2 创建 Skill 目录在 WorkBuddy 中创建一个新的 Skill命名为file_ops。Skill 目录结构可以参考下面的形式workbuddy_skills/ └── file_ops/ ├── SKILL.md └── main.pySKILL.md描述技能用途和参数main.py是真正的执行脚本。4.3 编写 Skill 描述文件文件路径workbuddy_skills/file_ops/SKILL.md# 文件批量处理技能 ## 功能 批量处理本地文件支持以下操作 1. 批量重命名文件 2. 按规则创建目录并归档文件 3. 合并一个文件夹下的所有 Excel 文件 ## 参数说明 - action: 操作类型可选值为 rename / archive / merge_excel - directory: 要处理的文件目录绝对路径 - prefix: 重命名时添加的前缀可空 - keyword: 重命名时需要替换的旧关键字可空 - replacement: 替换后的新关键字可空 ## 使用注意事项 - 所有操作都会打印日志。 - 出于安全考虑脚本默认不执行删除操作。 - 请确认真实业务需求后再调用。这段描述的作用是让 WorkBuddy 的智能体在遇到文件操作请求时能够自动判断该调用哪个脚本、传什么参数。4.4 编写文件处理脚本文件路径workbuddy_skills/file_ops/main.pyimport os import shutil import sys import argparse from datetime import datetime def batch_rename(directory: str, prefix: str , keyword: str , replacement: str ): 批量重命名文件 if not os.path.isdir(directory): print(f[ERROR] 目录不存在: {directory}) return for filename in os.listdir(directory): file_path os.path.join(directory, filename) if os.path.isfile(file_path): new_name filename if keyword and keyword in new_name: new_name new_name.replace(keyword, replacement) if prefix: new_name prefix new_name new_path os.path.join(directory, new_name) if new_path ! file_path: os.rename(file_path, new_path) print(f[RENAME] {filename} - {new_name}) def archive_by_date(directory: str): 按文件修改日期归档到 年/月 目录 if not os.path.isdir(directory): print(f[ERROR] 目录不存在: {directory}) return for filename in os.listdir(directory): file_path os.path.join(directory, filename) if os.path.isfile(file_path): mtime os.path.getmtime(file_path) dt datetime.fromtimestamp(mtime) target_dir os.path.join(directory, str(dt.year), f{dt.month:02d}) os.makedirs(target_dir, exist_okTrue) target_path os.path.join(target_dir, filename) if not os.path.exists(target_path): shutil.move(file_path, target_path) print(f[ARCHIVE] {filename} - {target_dir}) else: print(f[SKIP] {filename} 目标文件已存在) def merge_excel(directory: str): 合并目录下所有 Excel 文件到一个新的 Excel 文件 try: import pandas as pd except ImportError: print([ERROR] 缺少 pandas请先运行 pip install pandas openpyxl) return all_data [] for filename in os.listdir(directory): if filename.endswith((.xlsx, .xls)): file_path os.path.join(directory, filename) try: df pd.read_excel(file_path) df[来源文件] filename all_data.append(df) print(f[READ] {filename} 读取成功共 {len(df)} 行) except Exception as e: print(f[WARN] {filename} 读取失败: {e}) if all_data: merged pd.concat(all_data, ignore_indexTrue) output_path os.path.join(directory, fmerged_{datetime.now().strftime(%Y%m%d_%H%M%S)}.xlsx) merged.to_excel(output_path, indexFalse) print(f[MERGED] 合并完成共 {len(merged)} 行输出文件: {output_path}) else: print([INFO] 没有读取到任何 Excel 文件) if __name__ __main__: parser argparse.ArgumentParser(descriptionWorkBuddy 文件批量处理技能) parser.add_argument(--action, requiredTrue, choices[rename, archive, merge_excel]) parser.add_argument(--directory, requiredTrue) parser.add_argument(--prefix, default) parser.add_argument(--keyword, default) parser.add_argument(--replacement, default) args parser.parse_args() if args.action rename: batch_rename(args.directory, args.prefix, args.keyword, args.replacement) elif args.action archive: archive_by_date(args.directory) elif args.action merge_excel: merge_excel(args.directory)4.5 在 WorkBuddy 中调用配置好 Skill 后你不需要手动执行脚本。在 WorkBuddy 对话界面直接输入请帮我把 /data/contracts 目录下的所有 PDF 文件重命名添加前缀“2025_”并把文件名中的“合同”替换为“contract”。智能体会根据SKILL.md的描述自动识别出这是文件重命名任务并调用file_ops技能传入对应的 action 和参数。这里要提醒一点脚本运行在 WorkBuddy 所在机器的文件系统上。如果你使用网页版脚本可能运行在云端沙箱环境中如果你使用本地部署版本脚本直接运行在你的内网服务器上。建议所有路径参数都使用绝对路径避免因为工作目录不一致导致找不到文件。5. 实战二发票识别与信息提取5.1 业务背景发票识别是财务场景里最高频的自动化需求。报销时要把发票上的代码、号码、日期、金额、税额、购买方、销售方等信息录入系统还要做发票查重和真伪校验。人工录入不仅慢还容易看错数字。WorkBuddy 实现发票识别的思路很清晰通过 Skill 调用 OCR 能力提取发票图片中的文字。通过大模型对提取结果做结构化整理输出为 JSON。通过连接器把结构化数据写入报销系统或飞书/钉钉多维表。5.2 发票识别脚本示例这里给出一个基于 Python 的简化版方案。实际项目中你可能需要根据发票类型做更精细的字段适配。文件路径workbuddy_skills/invoice_ocr/main.pyimport os import json import sys import argparse from datetime import datetime try: import pdfplumber except ImportError: pdfplumber None try: from paddleocr import PaddleOCR except ImportError: PaddleOCR None def extract_text_from_pdf(pdf_path: str) - str: 从 PDF 发票中提取文本 if pdfplumber is None: return text_parts [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: page_text page.extract_text() if page_text: text_parts.append(page_text) return \n.join(text_parts) def extract_text_from_image(image_path: str) - str: 从图片发票中提取文本OCR if PaddleOCR is None: return ocr PaddleOCR(use_angle_clsTrue, langch, show_logFalse) result ocr.ocr(image_path, clsTrue) lines [] for line in result: for item in line: lines.append(item[1][0]) return \n.join(lines) def structure_invoice(raw_text: str) - dict: 将 OCR 原始文本交给大模型做结构化提取。 这里提供规则兜底方案生产环境建议调用模型接口。 # 简单兜底提取关键字段 data { invoice_code: , invoice_number: , date: , amount_total: , amount_tax: , buyer_name: , seller_name: , } for line in raw_text.split(\n): line line.strip() if 发票代码 in line or 发票号码 in line: # 如果 OCR 结果在同一行按冒号或空格切分 for key, label in [(invoice_code, 发票代码), (invoice_number, 发票号码)]: if label in line: val line.split(label, 1)[-1].strip().lstrip(: \t) data[key] val if 开票日期 in line: data[date] line.split(开票日期, 1)[-1].strip().lstrip(: \t) if 价税合计 in line or 小写 in line: val line.split(小写, 1)[-1].strip().lstrip((¥) ) if val: data[amount_total] val if 购买方 in line or 名 in line and 称 in line: # 简化逻辑实际需要更精细的行解析 pass return data def process_invoice(file_path: str, output_path: str): 处理单张发票 if not os.path.exists(file_path): print(f[ERROR] 文件不存在: {file_path}) return ext os.path.splitext(file_path)[1].lower() if ext .pdf: raw_text extract_text_from_pdf(file_path) elif ext in (.jpg, .jpeg, .png, .bmp): raw_text extract_text_from_image(file_path) else: print(f[ERROR] 不支持的文件格式: {ext}) return if not raw_text: print([ERROR] 未提取到任何文本请检查发票清晰度) return result structure_invoice(raw_text) result[source_file] os.path.basename(file_path) result[process_time] datetime.now().strftime(%Y-%m-%d %H:%M:%S) with open(output_path, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2) print(json.dumps(result, ensure_asciiFalse, indent2)) def batch_process(directory: str, output_dir: str): 批量处理目录下的所有发票 os.makedirs(output_dir, exist_okTrue) supported (.pdf, .jpg, .jpeg, .png, .bmp) for filename in os.listdir(directory): if filename.lower().endswith(supported): file_path os.path.join(directory, filename) output_path os.path.join(output_dir, os.path.splitext(filename)[0] .json) print(f\n 处理文件: {filename} ) process_invoice(file_path, output_path) if __name__ __main__: parser argparse.ArgumentParser(descriptionWorkBuddy 发票识别技能) parser.add_argument(--mode, requiredTrue, choices[single, batch]) parser.add_argument(--file, default) parser.add_argument(--directory, default) parser.add_argument(--output, default./output) args parser.parse_args() if args.mode single and args.file: process_invoice(args.file, os.path.join(args.output, single_result.json)) elif args.mode batch and args.directory: batch_process(args.directory, args.output) else: print([ERROR] 请检查参数single 模式需要 --filebatch 模式需要 --directory)5.3 让大模型优化提取精度上面代码里的structure_invoice函数只是兜底规则真实项目中建议把 OCR 原始文本直接发给大模型让大模型按字段输出 JSON。做法是在 WorkBuddy 中设置一个提取发票字段的提示词模板大致思路如下你是一个发票信息提取助手。请从下面的OCR原始文本中提取以下字段并以JSON格式输出 发票代码、发票号码、开票日期、购买方名称、销售方名称、不含税金额、税额、价税合计。 要求 1. 如果某个字段无法确定输出空字符串。 2. 不要编造数据。 3. 金额统一保留两位小数。 OCR原始文本 {raw_text}通过 WorkBuddy 的工作流可以让脚本负责 OCR 提取大模型负责结构化理解最后再合并输出。这种“OCR LLM”双引擎方案比单纯依赖规则正则要稳定得多。5.4 合规范式提醒发票属于敏感财务数据处理时务必注意识别后的 JSON 文件建议保存在内网环境不要随意上传到公网。使用网页版 WorkBuddy 时注意确认数据合规要求。配置连接器写入报销系统时只申请“新增单据”权限不要使用管理员账号。批量处理前先在测试目录放两张真实样票验证输出格式。6. 实战三自动生成周报6.1 周报为什么适合自动化周报的痛点不在于“写”而在于“收集”。一周的工作分散在任务系统、聊天记录、会议纪要、多维表里靠人工回忆往往漏掉细节。自动周报的本质不是让 AI 凭空编内容而是把散落的数据集中起来再由 AI 生成结构化的总结。6.2 用钉钉多维表同步数据假设你们团队用钉钉多维表管理任务那么周报工作流可以这样设计连接器定时读取多维表中的任务记录。将记录中的“任务名称、负责人、状态、完成时间、备注”提取出来。结合本周工作计划调用大模型生成周报。在 WorkBuddy 中配置连接器时通常需要选择数据源类型、授权方式以及同步范围。保存后可以手动触发一次同步确认数据能正确读取。有一点要注意多维表里的字段名最好规范统一。如果字段一会儿叫“任务标题”一会儿叫“任务事项”大模型在理解时会产生偏差。6.3 周报生成的提示词模板在 WorkBuddy 中可以创建一个“周报生成器”智能体并保存提示词模板你是一位项目助理请根据以下任务记录生成一份结构清晰的周报。 周报要求 1. 以 Markdown 格式输出。 2. 包含四个部分本周完成、当前风险、下周计划、需要协调的资源。 3. 每条任务用一两句话概括成果突出结果和价值。 4. 风险部分只列出确定性较高的问题不要强行凑数。 5. 语言简洁不要出现“赋能”“抓手”等空话。 本周任务记录 {task_records} 本周目标 {weekly_goal}{task_records} 和 {weekly_goal} 是变量工作流运行时会自动替换为真实数据。6.4 定时任务配置在 WorkBuddy 中把周报工作流保存后可以配置定时触发。建议的触发时间选在周五下班前 1 小时左右例如每周五 16:30留出人工检查和微调的时间。配置定时任务时需要考虑几个问题时区设置是否与团队所在时区一致。多维表数据是否已经更新到最新状态。生成后的周报是直接发送给群还是先推送给本人确认再发送。直接发送虽然省事但风险是 AI 生成的内容可能包含不准确的信息。稳妥的做法是先生成草稿通过企业微信或钉钉推送给成员确认再一键发布。6.5 定时发送微信消息的注意事项有同学希望 WorkBuddy 能“定时发送微信消息”。这个需求在个人微信上实现是有合规风险的不建议通过非官方接口操作。在企业微信、钉钉、飞书等办公协同软件中通过官方 API 推送消息是合规的。一个稳妥的替代方案是周报生成后推送到企业微信群机器人利用 Webhook 地址接收消息。这类机器人配置简单安全性高也是目前团队里最常见的做法。7. 实战四竞品分析报告7.1 需求分析竞品分析看起来简单做起来非常耗时。你需要人工访问竞品官网、翻阅行业新闻、查看应用商店评论、整理竞品的功能变化最后再形成一份报告。WorkBuddy 可以把“收集、整理、生成、发送”全流程自动化。不过要强调竞品信息收集必须遵守法律法规尊重版权和数据使用条款。不要用爬虫暴力抓取需要登录才能访问的内容也不要绕过对方的风控机制。优先使用官方公开资料、新闻稿、应用商店公开信息等渠道。7.2 设计竞品分析工作流一个基础的竞品分析工作流如下定时触发每天早上 9:00 执行。信息收集通过搜索 API 或 RSS 获取竞品相关新闻。网页内容抓取抓取目标网页正文过滤广告和导航噪音。大模型提炼把新闻内容归纳成功能更新、市场动态、潜在威胁三条线。报告生成按固定模板生成 Markdown 报告。推送发送到企业微信群或邮件。7.3 信息收集脚本示例下面是一个简化的新闻信息收集脚本思路可以作为 Skill 的一部分文件路径workbuddy_skills/competitor_analysis/main.pyimport os import json import argparse import requests from datetime import datetime, timedelta from bs4 import BeautifulSoup def fetch_news_from_rss(rss_urls, days7): 从 RSS 源获取近期新闻标题和链接 import feedparser cutoff datetime.now() - timedelta(daysdays) results [] for url in rss_urls: try: feed feedparser.parse(url) for entry in feed.entries[:20]: published entry.get(published_parsed) if published is None: continue pub_date datetime(*published[:6]) if pub_date cutoff: results.append({ title: entry.get(title, ), link: entry.get(link, ), summary: entry.get(summary, )[:500], published: pub_date.strftime(%Y-%m-%d %H:%M) }) except Exception as e: print(f[WARN] 读取 RSS 失败 {url}: {e}) return results def fetch_page_content(url: str) - str: 抓取单个页面的正文内容仅限公开页面 headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } try: resp requests.get(url, headersheaders, timeout15) resp.encoding resp.apparent_encoding soup BeautifulSoup(resp.text, html.parser) for tag in soup([script, style, nav, footer, aside]): tag.decompose() return soup.get_text(separator\n, stripTrue)[:3000] except Exception as e: return f[ERROR] {e} if __name__ __main__: parser argparse.ArgumentParser(description竞品信息收集技能) parser.add_argument(--rss, nargs, helpRSS 源地址列表) parser.add_argument(--output, default./competitor_news.json) args parser.parse_args() if args.rss: news fetch_news_from_rss(args.rss) with open(args.output, w, encodingutf-8) as f: json.dump(news, f, ensure_asciiFalse, indent2) print(f[DONE] 获取到 {len(news)} 条新闻输出到 {args.output}) else: print([ERROR] 请指定 --rss 参数)是的这里用了feedparser和BeautifulSoup。如果环境中没有安装可以用 pip 安装pip install feedparser beautifulsoup4 requests7.4 让模型生成竞品分析报告拿到新闻数据后把数据交给大模型生成报告。WorkBuddy 中可以设置如下提示词你是一名市场分析师。请根据以下收集到的竞品相关新闻生成一份竞品动态日报。 报告结构 ### 竞品动态概览 ### 功能与产品更新 ### 市场与商务动态 ### 潜在风险与机会 ### 建议采取的行动 要求 1. 每个条目都要注明信息来源链接。 2. 区分事实和推测推测内容必须标注“推测”。 3. 报告长度控制在 800 字以内。 4. 如果某个部分没有相关信息写“暂无明显动态”而不是编造。 新闻内容 {news_data}这份报告生成后可以通过企业微信连接器在每天早上推送到项目群。长期坚持下来团队对竞品的感知会明显加强。8. 常见问题与排查思路在实际使用 WorkBuddy 的过程中最容易遇到的问题集中在网络连接、Skill 调用、定时任务、本地部署几个方面。我整理了一些高频问题问题现象常见原因解决思路WorkBuddy 网络连接失败错误码 3002内网部署时网络代理配置不对或模型服务地址不可达检查 WorkBuddy 所在机器是否能访问模型服务检查代理设置用 curl 命令验证接口连通性找不到 Claw 面板或相关功能版本过低或该功能未在当前版本开放尝试升级到最新版本在设置中检查功能开关到官方文档确认入口名称Skill 脚本执行报错Python 依赖缺失、路径不对、权限不足查看 WorkBuddy 日志在命令行手动执行脚本定位问题确认脚本目录有执行权限定时任务不触发时区配置错误、定时任务未启用检查定时任务状态确认时区设置先手动触发一次确认工作流本身可用连接器同步失败授权过期、字段名不匹配、接口限流重新授权连接器检查数据源字段名稍后重试或调整同步频率本地模型响应很慢模型参数量过大、GPU 显存不足、并发过高降低并发数更换小参数模型检查 GPU 推理优化参数生成的周报内容偏差较大输入数据不完整、提示词不明确检查多维表字段补充周报模板示例增加 “基于以下数据” 的强约束遇到问题的时候不要急着删配置。按照下面的顺序排查先确认是 WorkBuddy 本身的问题还是外部服务的问题。最直接的方法是看日志。确认网络连通性。本地部署最容易踩的坑就是模型服务地址写成了 localhost但 WorkBuddy 运行在容器里localhost 指向的是容器本身。把 Skill 脚本从 WorkBuddy 里拆出来在命令行单独执行。这样可以快速区分是脚本问题还是智能体调用问题。查看输入的 prompt 和最终传给大模型的内容。如果大模型收到的数据就是乱的生成结果一定不会好。9. 最佳实践与工程建议9.1 从“单点自动化”开始不要一上来就搭建庞大的自动化体系。先选一个最耗时、规则最清晰的任务比如文件重命名或报销发票信息录入把它做成 Skill。跑通之后再逐步扩展。这种做法的好处是即使某个 Skill 设计得不合理影响范围也很小。随着你对 WorkBuddy 的能力边界越来越清楚再规划复杂工作流时成功率会高很多。9.2 Skill 设计要有明确的输入输出Skill 本质上是给智能体用的“工具接口”。设计 Skill 时要把参数说明写清楚把边界条件想清楚。脚本内部要打印足够详细的日志这样在 WorkBuddy 里面看不到执行细节时可以直接去日志文件里查。脚本的退出码也很重要。建议所有 Skill 脚本遵循统一约定0 表示成功非 0 表示失败。这样 WorkBuddy 工作流可以根据退出码判断是否继续执行后续步骤。9.3 Prompt 模板要固定版本不要频繁修改生产环境使用的提示词模板。每次修改前把旧版本另存一份在测试环境验证通过后再发布。AI 生成结果具有不确定性频繁调整提示词会导致输出格式和内容风格漂移影响下游数据处理。建议为常用模板建立命名规范例如weekly_report_v1.md invoice_extract_v2.md competitor_daily_v3.md9.4 重视数据安全与权限控制办公自动化涉及的数据往往比想象的更敏感。发票包含纳税人识别号周报可能包含项目进展和成本信息竞品分析报告可能涉及公司商业策略。以下几点务必落实连接器权限最小化只授予任务必要的数据权限。本地部署时对 WorkBuddy 管理后台设置强密码和访问白名单。涉及批量处理文件时先复制一份到测试目录不要在源目录直接执行高风险操作。涉及数据库操作时先明确事务边界重要操作前先备份。9.5 建立“人审 自动化”的双轨机制自动化不是完全取代人工而是把重复劳动干掉把人的精力集中到决策和审核上。周报、竞品分析这类内容型任务AI 生成之后一定要有人工审核环节。你可以把审核放在工作流内部也可以放在结果推送之前。比较稳妥的机制是自动化收集数据与生成初稿。人工在线修改。机器负责格式化和发送。这样既保证了效率又保证了内容质量。9.6 定期复盘工作流运行情况每个月花一点时间看看哪些 Skill 使用频率高、哪些工作流经常失败。长期不用的自动化任务建议先暂停不要让它每天空转浪费资源。经常失败的任务则要评估是不是设计思路有问题或者业务场景已经发生变化。10. 总结与下一步学习路线到这里我们已经完整走过了 WorkBuddy 办公自动化的核心闭环从产品概念到环境部署从 Skill 原理到四个实战场景再到高频问题排查和工程化建议。你可以从如下方向继续深入把批量处理文件技能扩展到更多格式例如 Word、PDF、PPT 的批量转换与内容抽取。在发票识别基础上接入报销系统实现“识别 → 校验 → 录入 → 推送审批”全链路自动化。在自动周报基础上加入月度总结、季度 OKR 复盘形成更完整的汇报体系。在竞品分析基础上加入舆情监控对行业热点事件进行实时追踪。研究 WorkBuddy 与 CodeBuddy 的联动用 CodeBuddy 写代码、用 WorkBuddy 跑自动化形成开发与业务的双通道效率提升。无论选择哪个方向都建议遵守一条原则让 AI 处理重复、繁杂、数据密集的环节让人处理判断、决策、审核的环节。这也是 WorkBuddy 这类智能体工作台最正确的打开方式。希望这篇 WorkBuddy 使用教程能帮你少走一些弯路尽快把自己的日常工作流自动化跑起来。
