最近总有读者问我为什么同样是使用 AI别人一天能完成简历筛选、文档格式转换、资料整理自己却还在一个对话框接一个对话框地复制粘贴问题通常不是大模型不够聪明而是缺少一个真正属于自己的 AI 工作台。WorkBuddy 这类工具解决的核心问题不是“和你聊天”而是把模型能力变成可以反复调用的工作流。你可以把一次性的问答操作沉淀成技能、流程、自动触发规则让 AI 真正参与日常生产。本文不打算按“几十节课”的节奏慢慢讲而是用一篇保姆级教程把从安装到实战的完整链路讲清楚并给出可直接复制的代码片段与工作流设计思路。文章会围绕四个问题展开WorkBuddy 到底是什么怎么搭建个人 AI 工作台如何设计并跑通一条真实工作流实际项目中容易踩哪些坑。如果你正准备搭建个人工作台或者想把手边重复性的文档处理、信息整理任务交给 AI这篇文章值得读完并收藏。1. 这篇文章真正要解决的问题很多人第一次接触 WorkBuddy 时会把它当成一个普通的聊天工具试用几分钟后觉得“和网页版 ChatGPT 没什么区别”然后卸载。这个判断只看到了表面。WorkBuddy 这类 AI 工作台真正改变的是使用 AI 的方式从“临时提问”变成“流程编排”。可以对比两种工作场景。没有工作台时你要把一份 Markdown 文档转成 Word大概需要打开编辑器、复制内容、打开 Word、粘贴、调整格式、保存。如果这个动作每周要做 20 次你就浪费了大量时间在重复操作上。有工作台之后你可以把“读取 Markdown - 解析标题结构 - 生成 Word 文档”定义成一条工作流以后只需要把文件拖进去点击运行甚至通过关键词触发AI 就会自动完成转换。这还只是一个最小示例。更复杂的场景比如简历筛选、专利辅助检索、资料归档本质都是同一套逻辑把大模型能力嵌入到固定流程中。所以这篇文章真正要解决的问题有三个帮助零基础用户理解 AI 工作台的基本概念和常见误区。带读者亲手搭建一个 WorkBuddy 工作台并跑通一条完整工作流。给出实际项目中会用到的设计思路、代码片段和排错方法。判断也很明确WorkBuddy 的价值不在于大模型本身而在于“工作流 技能 上下文管理”这三层能力。谁能够把这层能力用起来谁才算真正拥有了属于自己的 AI 工作台。2. WorkBuddy 的核心概念与工作台原理2.1 什么是 AI 工作台AI 工作台不是一个新概念它本质上是“模型能力 工具链 业务流程”的集成环境。如果说大模型是一台发动机那工作台就是把发动机安装到车架、接上轮胎、配上方向盘之后的整车。发动机重要但没有整车你很难直接开着发动机上班。WorkBuddy 提供的就是这样一个整车框架。它允许你把大模型接入自己的工作环境定义输入输出组合多个处理步骤形成可复用的工作流。与单纯打开网页提问的区别在于所有操作都有结构、有状态、可重复、可扩展。2.2 Skill 与 Workflow 的区别使用 WorkBuddy 时有两个词会反复出现Skill 和 Workflow。很多人容易混淆这里用一个类比来解释。Workflow 是一条流水线描述“先做什么、再做什么、最后输出什么”。例如读取文件 - 提取关键信息 - 调用大模型总结 - 保存结果。Skill 是流水线上的一个工位封装了某个具体能力。例如“Markdown 转 Word”是一个技能“简历关键信息提取”也是一个技能。一个 Workflow 可以由多个 Skill 组合而成而一个 Skill 也可以被多个 Workflow 复用。理解这层关系后你就知道搭建工作台时第一步不是写代码而是拆解任务哪些动作是固定重复的把它们抽象成 Skill哪些流程是完整链路把它们编排成 Workflow。2.3 上下文Context为什么重要上下文是 AI 工作台里最容易被忽视、却又最容易出问题的概念。简单说上下文就是模型在某次任务中能看到的全部信息。你粘贴到对话框里的文字、工作流节点之间的传递数据、历史对话内容都会消耗上下文窗口。很多人遇到“上下文用量满了”的提示第一反应是抱怨模型窗口太小。实际上更常见的原因是工作流设计不合理把整本手册塞进提示词、把历史对话无限保留、把原始大文件直接传给模型。正确的做法是在进入大模型节点之前先做裁剪、摘要、字段提取。这个思想会在后面的实战案例中反复出现。2.4 WorkBuddy 与同类工具的定位差异市面上已经有不少工作流类工具比如 Dify、Coze、n8n。如果单看“流程编排”这件事它们有相似之处。但从产品定位看WorkBuddy 更偏向个人工作台场景强调技能管理、本地任务执行和轻量化集成。可以简单对比工具核心定位适合场景学习门槛WorkBuddy个人 AI 工作台个人任务自动化、技能复用较低Dify企业级 LLM 应用平台团队知识库、RAG 应用、模型管理中等Coze在线 Bot 搭建平台对话机器人、插件系统较低n8n通用自动化工作流系统间数据同步、API 编排中等这里不是要比出谁优谁劣而是帮助读者建立判断如果你要处理的是本地文档、个人任务、轻量自动化WorkBuddy 的路径更短如果你要构建面向团队的多用户应用可能需要考虑平台型工具。根据自己的场景选择比盲目跟随热词更重要。3. 环境准备与前置条件3.1 运行环境在开始搭建之前先确认电脑环境满足基本要求。从目前社区使用反馈看WorkBuddy 对系统的要求并不高Windows、macOS、Linux 都有可用的安装方式。建议环境操作系统Windows 10/11、macOS 12 或更新版本、主流 Linux 发行版均可。Python推荐 3.9 或更高版本主要用于运行自定义脚本扩展。网络需要能正常访问你要接入的模型服务商 API。内存8GB 以上更流畅16GB 体验更好。如果你只是先试用核心功能内存低于 8GB 也可以跑通简单流程但不要同时运行多个大模型任务。3.2 安装 WorkBuddyWorkBuddy 的安装分为安装包方式和命令行方式。不同版本的安装入口可能不同但通用思路一致先从官方渠道获取安装包或安装命令再按提示完成安装。安装前建议先检查 Python 环境。打开终端Windows 使用 CMD 或 PowerShellmacOS/Linux 使用 Terminal运行python --version pip --version如果没有输出或者提示命令不存在需要先安装 Python并勾选“Add Python to PATH”。为了不让 Python 依赖污染系统环境建议创建一个虚拟环境后续的 Python 扩展都装在里面python -m venv .venv激活虚拟环境# Windows .venv\Scripts\activate # macOS / Linux source .venv/bin/activate激活后终端提示符前面会出现(.venv)表示当前处于虚拟环境中。之后安装的 Python 包都会被隔离到这个环境里不会影响系统其他项目。3.3 准备模型服务与 API KeyWorkBuddy 本身不内置大模型它连接的是你选择的模型服务。所以你需要提前准备好模型服务的 API Key。不同类型的模型服务申请方式不一样。常见的有两类云服务商提供的模型 API通常在控制台创建 API Key按量计费。本地部署的开源模型需要自己配置服务地址和端口。无论使用哪种都需要在 WorkBuddy 的设置里填写 Base URL、API Key、模型名称等参数。建议先把模型服务的连通性测试通过再进入工作台搭建否则后面排查问题时很难分清是模型问题还是工作流问题。3.4 验证基础环境完成安装后先做一个最小验证在 WorkBuddy 中新建一个空白对话输入一句简单的测试内容确认模型能正常返回结果。同时在终端验证 Python 和 pip 可用python -c print(hello)如果看到输出hello说明 Python 环境正常。到这里基础环境就准备好了。4. 从零搭建 WorkBuddy 个人工作台4.1 创建并配置工作台打开 WorkBuddy 后第一步通常是创建工作台。不同版本的界面布局有差异但核心逻辑一般是统一的工作台是一组技能、工作流和资源的集合。建议按下述方式命名工作台名称与用途强相关例如doc_processing、resume_screening。描述信息写清楚这个工作台解决什么问题方便以后复用。创建一个新工作台后你会看到类似“节点”“技能”“工作流”等入口。先不用急着添加节点先花两分钟想清楚自己要实现的流程是什么。如果目标不明确后面很容易把工作台搭成一团乱麻。4.2 接入模型服务在工作台设置中找到模型配置入口。需要填写的信息一般包括配置项说明Base URL模型服务的接口地址API Key访问模型服务的密钥Model Name要使用的模型名称Temperature生成随机性控制一般知识处理任务设为 0.2 左右保存配置后先运行一次测试确认模型可以正常响应。测试时不要直接跑复杂工作流先用一句话验证。这里有一个容易被忽略的点API Key 属于敏感信息不要随手写在工作流配置文件里也不要把包含 API Key 的文件提交到公开仓库。尽量使用 WorkBuddy 提供的密钥管理能力或者通过环境变量引用。4.3 设计第一个工作流现在可以设计工作流了。仍然以“Markdown 转 Word”为例。在画布上依次添加节点输入节点接收 Markdown 文件路径。转换节点调用 Python 脚本读取 Markdown解析标题结构生成 Word。输出节点把生成的 Word 文件保存到指定目录。节点之间用连线连接数据从上一个节点流向下一个节点。每一次连线都要明确数据的字段名和类型。比如输入节点传给转换节点的字段是input_file类型是字符串路径。设计完成后先不要急着运行。先检查每个节点的配置项是否完整尤其是输入字段名是否前后一致。很多新手第一次跑工作流失败原因是节点 A 输出的是file_path节点 B 读取的却是input_file。4.4 绑定技能与触发方式如果这条工作流以后要频繁使用可以把它封装成一个 Skill。封装之后你可以在对话中通过自然语言触发它也可以手动运行。例如给技能命名为markdown_to_word再定义几个触发词md转word、markdown转word、文档转换。这样以后只需要在工作台对话框中输入这些触发词并附带文件路径就可以直接执行工作流而不需要每次打开画布手动连线。4.5 测试工作流完成绑定后用一个小体积的 Markdown 文件测试。先不要拿整本书去试测试文件越小定位问题越容易。如果测试失败优先查看运行日志中的节点执行顺序。哪个节点报错就从哪个节点开始排查先确认输入数据格式再确认脚本是否能读取到文件。5. 完整示例Markdown 转 Word 工作流这一节给出一个能直接复制的完整示例。这个示例包含三部分Python 转换脚本、技能注册文件、HTTP 调用示例。5.1 准备依赖在虚拟环境中安装必要的 Python 包。新建文件requirements.txt内容如下markdown3.5.1 python-docx1.1.0 requests2.31.0然后执行pip install -r requirements.txt如果安装失败很可能是版本兼容问题。可以去掉版本号改用最新兼容版本pip install markdown python-docx requests5.2 核心转换脚本新建文件nodes/markdown_to_word_workflow.pyimport argparse from pathlib import Path import markdown from docx import Document def load_markdown(path: Path) - str: return path.read_text(encodingutf-8) def convert_and_save(md_path: Path, out_path: Path) - None: md_text load_markdown(md_path) # 转换为 HTML 字符串用于触发 markdown 扩展 html_text markdown.markdown( md_text, extensions[tables, fenced_code] ) document Document() lines [line.strip() for line in md_text.splitlines() if line.strip()] for line in lines: if line.startswith(# ): document.add_heading(line[2:], level1) elif line.startswith(## ): document.add_heading(line[3:], level2) elif line.startswith(### ): document.add_heading(line[4:], level3) else: document.add_paragraph(line) document.save(str(out_path)) print(f已生成 Word 文件: {out_path}) if __name__ __main__: parser argparse.ArgumentParser(descriptionMarkdown 转 Word 工作流节点) parser.add_argument(input, typePath, help输入的 Markdown 文件路径) parser.add_argument( --output, typePath, defaultPath(output.docx), help输出 Word 文件路径, ) args parser.parse_args() input_path args.input.resolve() output_path args.output.resolve() if not input_path.exists(): raise FileNotFoundError(f输入文件不存在: {input_path}) convert_and_save(input_path, output_path)这个脚本的关键逻辑是读取 Markdown 文本跳过空行根据#、##、###前缀判断标题级别其它内容作为普通段落写入 Word。脚本可以通过命令行参数接收输入输出路径方便被 WorkBuddy 的工作流节点调用。5.3 技能注册文件新建文件skills/markdown_to_word.json{ skill: { name: markdown_to_word, description: 将 Markdown 文件转换为 Word 文档, trigger: [md转word, markdown转word, 文档转换], workflow: { entry: nodes/markdown_to_word_workflow.py, language: python, inputs: { input_file: { type: string, required: true, description: Markdown 文件绝对路径 }, output_dir: { type: string, default: ./output, description: 输出目录 } } } } }这个文件定义了技能的元数据。trigger中的关键词用于自然语言触发entry指向实际执行脚本inputs声明运行时需要的参数。不同的 WorkBuddy 版本对技能注册文件格式的要求可能不同但核心思想一致让一段脚本成为一个可被工作台调用的能力。5.4 调用工作流如果你的 WorkBuddy 版本暴露了本地 HTTP API或者你通过网关把工作流包装成了服务可以用下面的 Python 脚本调用import json import requests API_BASE http://127.0.0.1:8000 # 以实际服务地址为准 API_KEY your-api-key # 以实际密钥为准 def run_skill(skill_name: str, payload: dict) - dict: resp requests.post( f{API_BASE}/api/skills/{skill_name}/run, headers{Authorization: fBearer {API_KEY}}, jsonpayload, timeout60, ) resp.raise_for_status() return resp.json() if __name__ __main__: result run_skill( markdown_to_word, { input_file: ./README.md, output_dir: ./output, }, ) print(json.dumps(result, ensure_asciiFalse, indent2))这个脚本展示的是一种通用的 HTTP 调用模式。实际使用时服务地址和鉴权方式要以你本机 WorkBuddy 提供的接口为准。如果当前版本没有开放 HTTP API也可以直接在工作台界面里运行技能效果是一样的。6. 实战案例简历筛选工作流设计文档转换是入门简历筛选才是真正能体现工作流价值的场景。很多团队每天会收到大量简历如果每个岗位需求都要由 HR 手动阅读、提取、打分时间和人力成本都很高。用 AI 工作台可以搭建一条半自动简历筛选流水线。6.1 需求拆解简历筛选任务可以拆成五个步骤上传简历文件。解析 PDF/Word提取纯文本。利用大模型抽取关键字段。根据岗位要求规则打分。输出结构化评分表。6.2 工作流节点设计在 WorkBuddy 工作台画布上可以这样设计节点{ workflow: { name: resume_screening, nodes: [ { id: upload, type: file_upload, description: 接收简历文件 }, { id: parse, type: document_parser, description: 提取 PDF/Word 文本 }, { id: extract, type: llm_extract, prompt: 从简历中提取姓名、工作年限、技能列表、学历信息 }, { id: score, type: rule_score, rules: { require_skills: [Python, AI, 项目管理], min_years: 3 } }, { id: output, type: table_output, description: 生成打分表 } ] } }这个工作流的关键在extract节点。不要直接把整篇简历抛给模型而是先让模型抽取结构化字段再交给规则评分。这样做的好处是模型只负责它擅长的语义理解分数计算交给确定性规则结果稳定可解释。6.3 提示词与评分规则extract节点的提示词可以这样写请从以下简历文本中提取结构化信息并返回 JSON 格式 { name: 姓名, years: 工作年限数字, skills: [技能1, 技能2], education: 最高学历 } 简历文本 {resume_text}score节点根据返回的 JSON 计算得分。规则不需要复杂可以先用简单的加减分命中一个必需技能加 10 分。工作年限大于等于要求值加 20 分。学历达到要求加 10 分。这套规则的好处是透明。面试官看到 80 分的简历能明确知道分数来自哪里而不是模型给出一个凭空计算的“匹配度”。6.4 输出格式最终输出建议保存为 CSV 或 JSON方便后续导入表格工具。CSV 的列可以设计为姓名、工作年限、技能命中情况、学历、总分、是否进入面试。到这里一条简历筛选工作流就设计完成了。你还可在upload节点之前增加一个批量文件夹扫描节点实现一次处理多份简历。7. 运行结果与效果验证7.1 运行命令在虚拟环境中直接运行转换脚本python nodes/markdown_to_word_workflow.py README.md --output output/README.docx如果是在 WorkBuddy 工作台里运行只需要指定输入文件路径技能会自动调用底层脚本。7.2 预期输出正常情况下控制台输出已生成 Word 文件: output/README.docx打开output目录可以找到生成的 Word 文件标题层级和段落顺序应与 Markdown 源文件一致。7.3 验证清单运行成功后建议按以下清单检查一级标题是否变成了 Word 的一级标题。二级、三级标题层级是否正常。普通段落是否完整。生成的 Word 能否用 Office 或 WPS 正常打开。如果标题层级错乱优先查看 Markdown 源文件中的标题符号后面是否有空格以及工作流节点之间传递的字段名是否正确。8. 常见问题与排查方法实际搭建过程中新手遇到的问题基本集中在安装、依赖、上下文和节点配置四个方面。整理成下表方便直接对照排查。问题现象可能原因排查方式解决方案安装后无法启动系统缺少运行库或版本不兼容查看启动日志确认系统版本更新操作系统组件换用稳定版安装Python 脚本提示找不到模块依赖未安装或虚拟环境未激活运行pip list检查依赖执行pip install -r requirements.txt工作流节点之间数据为空字段名称不一致查看节点输入输出日志统一字段名确认大小写完全一致模型 API 连接超时Base URL 配置错误或网络不通单独测试 API 连通性检查地址和密钥确认服务商控制台可用上下文用量满了大量原始文档直接传入模型查看节点数据量先做摘要或字段提取减少传给模型的文本量技能触发不生效触发词没有配置检查技能注册文件补充trigger关键词并确认已保存生成的 Word 乱码编码不一致检查脚本读取编码在脚本中统一使用encodingutf-88.1 上下文用量满了怎么办这是高频问题。如果你遇到“上下文用量满了”提示不要急着换更大窗口的模型先做三件事检查工作流中是否有节点把整份大文档传给了模型。如果有改成先抽取关键字段再传。检查历史对话是否被保留。如果只是执行固定任务建议每次任务使用独立会话不要让历史消息持续累积。检查提示词中是否嵌入了大量静态说明。把固定说明移到系统提示词中减少每轮请求的重复消耗。上下文管理是工作台使用中最重要的工程能力之一。养成“能传摘要就不传全文能传字段就不传原文”的习惯可以显著降低成本和报错概率。9. 最佳实践与工程建议9.1 技能命名与目录规范建议按领域_动作的格式命名技能比如doc_markdown_to_word、hr_resume_extract。目录结构可以采用workbench/ ├── skills/ │ ├── markdown_to_word/ │ │ ├── skill.json │ │ └── main.py │ └── resume_screening/ │ ├── skill.json │ └── main.py ├── workflows/ ├── nodes/ ├── output/ └── requirements.txt命名规范的意义在于复用。一个月后你再打开工作台看到skill.json里的描述就能快速判断这个技能是干什么的而不用点开代码逐行阅读。9.2 配置与密钥管理API Key、服务地址、模型名称不要散落在脚本里。推荐做法把敏感配置写入环境变量或密钥管理模块。工作流配置中使用占位符引用。不要将.env文件提交到公开仓库。定期轮换 API Key降低泄露风险。9.3 工作流拆分原则一个工作流只做一件完整的事。如果发现某个工作流节点超过 5 个可以拆分成多个技能再组合。过度复杂的单条工作流会让排错变得非常困难。优先保证每个节点输入输出明确、单一。节点的作用越单一越容易被复用和测试。9.4 日志与异常处理在所有自定义脚本中建议加入日志输出。Python 的logging模块比print更适合排查生产问题。例如import logging logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) logger.info(开始读取文件: %s, input_path)日志要记录关键路径输入文件路径、解析结果条数、输出文件路径、异常堆栈。这样在工作流运行失败时可以快速定位到具体步骤。9.5 安全边界与最小权限如果工作台要访问公司内部系统务必遵守最小权限原则只授予完成当前任务所需的访问权限不要将管理员密钥配置到普通工作流中。还需要确认相关任务获得了合法授权在生产环境执行前先在测试环境验证。对于涉及隐私的文档比如简历、合同建议工作流只输出处理后的摘要字段不要将完整原始内容写入日志。9.6 备份与回滚工作台配置、技能文件、工作流定义本质上都是源码。建议纳入版本管理每次修改前打标签或提交记录。一旦新版本运行异常可以快速回滚到上一个可用版本。具体的做法是每次修改技能文件后提交一次记录并附带一句改动说明。这样即使工作台界面无法自动回滚你也可以通过版本记录手动恢复文件。10. 总结与后续学习方向回到开头那个问题为什么有人用 AI 像流水线有人还在复制粘贴差别不在于模型强弱而在于是否愿意把一次性的问答沉淀成可复用的技能与工作流。WorkBuddy 提供了这层能力但真正把工作台用起来的是你对任务的拆解能力、对上下文的控制意识以及持续迭代的耐心。读完这篇文章建议按顺序完成三个练习搭建一个空白工作台接入模型服务跑通一句对话。复现 Markdown 转 Word 技能理解节点、技能、工作流之间的关系。设计一条简历筛选工作流先不追求完美用 5 个节点把流程跑通。下一步可以继续研究的知识点包括RAG 知识库接入、多模型路由、定时触发工作流、以及如何把工作流封装成对外 API。每一条都建立在今天这套基础之上。收藏备用下次搭工作台的时候直接对着操作会少走很多弯路。
从零搭建个人AI工作台：WorkBuddy保姆级教程与工作流实战
最近总有读者问我为什么同样是使用 AI别人一天能完成简历筛选、文档格式转换、资料整理自己却还在一个对话框接一个对话框地复制粘贴问题通常不是大模型不够聪明而是缺少一个真正属于自己的 AI 工作台。WorkBuddy 这类工具解决的核心问题不是“和你聊天”而是把模型能力变成可以反复调用的工作流。你可以把一次性的问答操作沉淀成技能、流程、自动触发规则让 AI 真正参与日常生产。本文不打算按“几十节课”的节奏慢慢讲而是用一篇保姆级教程把从安装到实战的完整链路讲清楚并给出可直接复制的代码片段与工作流设计思路。文章会围绕四个问题展开WorkBuddy 到底是什么怎么搭建个人 AI 工作台如何设计并跑通一条真实工作流实际项目中容易踩哪些坑。如果你正准备搭建个人工作台或者想把手边重复性的文档处理、信息整理任务交给 AI这篇文章值得读完并收藏。1. 这篇文章真正要解决的问题很多人第一次接触 WorkBuddy 时会把它当成一个普通的聊天工具试用几分钟后觉得“和网页版 ChatGPT 没什么区别”然后卸载。这个判断只看到了表面。WorkBuddy 这类 AI 工作台真正改变的是使用 AI 的方式从“临时提问”变成“流程编排”。可以对比两种工作场景。没有工作台时你要把一份 Markdown 文档转成 Word大概需要打开编辑器、复制内容、打开 Word、粘贴、调整格式、保存。如果这个动作每周要做 20 次你就浪费了大量时间在重复操作上。有工作台之后你可以把“读取 Markdown - 解析标题结构 - 生成 Word 文档”定义成一条工作流以后只需要把文件拖进去点击运行甚至通过关键词触发AI 就会自动完成转换。这还只是一个最小示例。更复杂的场景比如简历筛选、专利辅助检索、资料归档本质都是同一套逻辑把大模型能力嵌入到固定流程中。所以这篇文章真正要解决的问题有三个帮助零基础用户理解 AI 工作台的基本概念和常见误区。带读者亲手搭建一个 WorkBuddy 工作台并跑通一条完整工作流。给出实际项目中会用到的设计思路、代码片段和排错方法。判断也很明确WorkBuddy 的价值不在于大模型本身而在于“工作流 技能 上下文管理”这三层能力。谁能够把这层能力用起来谁才算真正拥有了属于自己的 AI 工作台。2. WorkBuddy 的核心概念与工作台原理2.1 什么是 AI 工作台AI 工作台不是一个新概念它本质上是“模型能力 工具链 业务流程”的集成环境。如果说大模型是一台发动机那工作台就是把发动机安装到车架、接上轮胎、配上方向盘之后的整车。发动机重要但没有整车你很难直接开着发动机上班。WorkBuddy 提供的就是这样一个整车框架。它允许你把大模型接入自己的工作环境定义输入输出组合多个处理步骤形成可复用的工作流。与单纯打开网页提问的区别在于所有操作都有结构、有状态、可重复、可扩展。2.2 Skill 与 Workflow 的区别使用 WorkBuddy 时有两个词会反复出现Skill 和 Workflow。很多人容易混淆这里用一个类比来解释。Workflow 是一条流水线描述“先做什么、再做什么、最后输出什么”。例如读取文件 - 提取关键信息 - 调用大模型总结 - 保存结果。Skill 是流水线上的一个工位封装了某个具体能力。例如“Markdown 转 Word”是一个技能“简历关键信息提取”也是一个技能。一个 Workflow 可以由多个 Skill 组合而成而一个 Skill 也可以被多个 Workflow 复用。理解这层关系后你就知道搭建工作台时第一步不是写代码而是拆解任务哪些动作是固定重复的把它们抽象成 Skill哪些流程是完整链路把它们编排成 Workflow。2.3 上下文Context为什么重要上下文是 AI 工作台里最容易被忽视、却又最容易出问题的概念。简单说上下文就是模型在某次任务中能看到的全部信息。你粘贴到对话框里的文字、工作流节点之间的传递数据、历史对话内容都会消耗上下文窗口。很多人遇到“上下文用量满了”的提示第一反应是抱怨模型窗口太小。实际上更常见的原因是工作流设计不合理把整本手册塞进提示词、把历史对话无限保留、把原始大文件直接传给模型。正确的做法是在进入大模型节点之前先做裁剪、摘要、字段提取。这个思想会在后面的实战案例中反复出现。2.4 WorkBuddy 与同类工具的定位差异市面上已经有不少工作流类工具比如 Dify、Coze、n8n。如果单看“流程编排”这件事它们有相似之处。但从产品定位看WorkBuddy 更偏向个人工作台场景强调技能管理、本地任务执行和轻量化集成。可以简单对比工具核心定位适合场景学习门槛WorkBuddy个人 AI 工作台个人任务自动化、技能复用较低Dify企业级 LLM 应用平台团队知识库、RAG 应用、模型管理中等Coze在线 Bot 搭建平台对话机器人、插件系统较低n8n通用自动化工作流系统间数据同步、API 编排中等这里不是要比出谁优谁劣而是帮助读者建立判断如果你要处理的是本地文档、个人任务、轻量自动化WorkBuddy 的路径更短如果你要构建面向团队的多用户应用可能需要考虑平台型工具。根据自己的场景选择比盲目跟随热词更重要。3. 环境准备与前置条件3.1 运行环境在开始搭建之前先确认电脑环境满足基本要求。从目前社区使用反馈看WorkBuddy 对系统的要求并不高Windows、macOS、Linux 都有可用的安装方式。建议环境操作系统Windows 10/11、macOS 12 或更新版本、主流 Linux 发行版均可。Python推荐 3.9 或更高版本主要用于运行自定义脚本扩展。网络需要能正常访问你要接入的模型服务商 API。内存8GB 以上更流畅16GB 体验更好。如果你只是先试用核心功能内存低于 8GB 也可以跑通简单流程但不要同时运行多个大模型任务。3.2 安装 WorkBuddyWorkBuddy 的安装分为安装包方式和命令行方式。不同版本的安装入口可能不同但通用思路一致先从官方渠道获取安装包或安装命令再按提示完成安装。安装前建议先检查 Python 环境。打开终端Windows 使用 CMD 或 PowerShellmacOS/Linux 使用 Terminal运行python --version pip --version如果没有输出或者提示命令不存在需要先安装 Python并勾选“Add Python to PATH”。为了不让 Python 依赖污染系统环境建议创建一个虚拟环境后续的 Python 扩展都装在里面python -m venv .venv激活虚拟环境# Windows .venv\Scripts\activate # macOS / Linux source .venv/bin/activate激活后终端提示符前面会出现(.venv)表示当前处于虚拟环境中。之后安装的 Python 包都会被隔离到这个环境里不会影响系统其他项目。3.3 准备模型服务与 API KeyWorkBuddy 本身不内置大模型它连接的是你选择的模型服务。所以你需要提前准备好模型服务的 API Key。不同类型的模型服务申请方式不一样。常见的有两类云服务商提供的模型 API通常在控制台创建 API Key按量计费。本地部署的开源模型需要自己配置服务地址和端口。无论使用哪种都需要在 WorkBuddy 的设置里填写 Base URL、API Key、模型名称等参数。建议先把模型服务的连通性测试通过再进入工作台搭建否则后面排查问题时很难分清是模型问题还是工作流问题。3.4 验证基础环境完成安装后先做一个最小验证在 WorkBuddy 中新建一个空白对话输入一句简单的测试内容确认模型能正常返回结果。同时在终端验证 Python 和 pip 可用python -c print(hello)如果看到输出hello说明 Python 环境正常。到这里基础环境就准备好了。4. 从零搭建 WorkBuddy 个人工作台4.1 创建并配置工作台打开 WorkBuddy 后第一步通常是创建工作台。不同版本的界面布局有差异但核心逻辑一般是统一的工作台是一组技能、工作流和资源的集合。建议按下述方式命名工作台名称与用途强相关例如doc_processing、resume_screening。描述信息写清楚这个工作台解决什么问题方便以后复用。创建一个新工作台后你会看到类似“节点”“技能”“工作流”等入口。先不用急着添加节点先花两分钟想清楚自己要实现的流程是什么。如果目标不明确后面很容易把工作台搭成一团乱麻。4.2 接入模型服务在工作台设置中找到模型配置入口。需要填写的信息一般包括配置项说明Base URL模型服务的接口地址API Key访问模型服务的密钥Model Name要使用的模型名称Temperature生成随机性控制一般知识处理任务设为 0.2 左右保存配置后先运行一次测试确认模型可以正常响应。测试时不要直接跑复杂工作流先用一句话验证。这里有一个容易被忽略的点API Key 属于敏感信息不要随手写在工作流配置文件里也不要把包含 API Key 的文件提交到公开仓库。尽量使用 WorkBuddy 提供的密钥管理能力或者通过环境变量引用。4.3 设计第一个工作流现在可以设计工作流了。仍然以“Markdown 转 Word”为例。在画布上依次添加节点输入节点接收 Markdown 文件路径。转换节点调用 Python 脚本读取 Markdown解析标题结构生成 Word。输出节点把生成的 Word 文件保存到指定目录。节点之间用连线连接数据从上一个节点流向下一个节点。每一次连线都要明确数据的字段名和类型。比如输入节点传给转换节点的字段是input_file类型是字符串路径。设计完成后先不要急着运行。先检查每个节点的配置项是否完整尤其是输入字段名是否前后一致。很多新手第一次跑工作流失败原因是节点 A 输出的是file_path节点 B 读取的却是input_file。4.4 绑定技能与触发方式如果这条工作流以后要频繁使用可以把它封装成一个 Skill。封装之后你可以在对话中通过自然语言触发它也可以手动运行。例如给技能命名为markdown_to_word再定义几个触发词md转word、markdown转word、文档转换。这样以后只需要在工作台对话框中输入这些触发词并附带文件路径就可以直接执行工作流而不需要每次打开画布手动连线。4.5 测试工作流完成绑定后用一个小体积的 Markdown 文件测试。先不要拿整本书去试测试文件越小定位问题越容易。如果测试失败优先查看运行日志中的节点执行顺序。哪个节点报错就从哪个节点开始排查先确认输入数据格式再确认脚本是否能读取到文件。5. 完整示例Markdown 转 Word 工作流这一节给出一个能直接复制的完整示例。这个示例包含三部分Python 转换脚本、技能注册文件、HTTP 调用示例。5.1 准备依赖在虚拟环境中安装必要的 Python 包。新建文件requirements.txt内容如下markdown3.5.1 python-docx1.1.0 requests2.31.0然后执行pip install -r requirements.txt如果安装失败很可能是版本兼容问题。可以去掉版本号改用最新兼容版本pip install markdown python-docx requests5.2 核心转换脚本新建文件nodes/markdown_to_word_workflow.pyimport argparse from pathlib import Path import markdown from docx import Document def load_markdown(path: Path) - str: return path.read_text(encodingutf-8) def convert_and_save(md_path: Path, out_path: Path) - None: md_text load_markdown(md_path) # 转换为 HTML 字符串用于触发 markdown 扩展 html_text markdown.markdown( md_text, extensions[tables, fenced_code] ) document Document() lines [line.strip() for line in md_text.splitlines() if line.strip()] for line in lines: if line.startswith(# ): document.add_heading(line[2:], level1) elif line.startswith(## ): document.add_heading(line[3:], level2) elif line.startswith(### ): document.add_heading(line[4:], level3) else: document.add_paragraph(line) document.save(str(out_path)) print(f已生成 Word 文件: {out_path}) if __name__ __main__: parser argparse.ArgumentParser(descriptionMarkdown 转 Word 工作流节点) parser.add_argument(input, typePath, help输入的 Markdown 文件路径) parser.add_argument( --output, typePath, defaultPath(output.docx), help输出 Word 文件路径, ) args parser.parse_args() input_path args.input.resolve() output_path args.output.resolve() if not input_path.exists(): raise FileNotFoundError(f输入文件不存在: {input_path}) convert_and_save(input_path, output_path)这个脚本的关键逻辑是读取 Markdown 文本跳过空行根据#、##、###前缀判断标题级别其它内容作为普通段落写入 Word。脚本可以通过命令行参数接收输入输出路径方便被 WorkBuddy 的工作流节点调用。5.3 技能注册文件新建文件skills/markdown_to_word.json{ skill: { name: markdown_to_word, description: 将 Markdown 文件转换为 Word 文档, trigger: [md转word, markdown转word, 文档转换], workflow: { entry: nodes/markdown_to_word_workflow.py, language: python, inputs: { input_file: { type: string, required: true, description: Markdown 文件绝对路径 }, output_dir: { type: string, default: ./output, description: 输出目录 } } } } }这个文件定义了技能的元数据。trigger中的关键词用于自然语言触发entry指向实际执行脚本inputs声明运行时需要的参数。不同的 WorkBuddy 版本对技能注册文件格式的要求可能不同但核心思想一致让一段脚本成为一个可被工作台调用的能力。5.4 调用工作流如果你的 WorkBuddy 版本暴露了本地 HTTP API或者你通过网关把工作流包装成了服务可以用下面的 Python 脚本调用import json import requests API_BASE http://127.0.0.1:8000 # 以实际服务地址为准 API_KEY your-api-key # 以实际密钥为准 def run_skill(skill_name: str, payload: dict) - dict: resp requests.post( f{API_BASE}/api/skills/{skill_name}/run, headers{Authorization: fBearer {API_KEY}}, jsonpayload, timeout60, ) resp.raise_for_status() return resp.json() if __name__ __main__: result run_skill( markdown_to_word, { input_file: ./README.md, output_dir: ./output, }, ) print(json.dumps(result, ensure_asciiFalse, indent2))这个脚本展示的是一种通用的 HTTP 调用模式。实际使用时服务地址和鉴权方式要以你本机 WorkBuddy 提供的接口为准。如果当前版本没有开放 HTTP API也可以直接在工作台界面里运行技能效果是一样的。6. 实战案例简历筛选工作流设计文档转换是入门简历筛选才是真正能体现工作流价值的场景。很多团队每天会收到大量简历如果每个岗位需求都要由 HR 手动阅读、提取、打分时间和人力成本都很高。用 AI 工作台可以搭建一条半自动简历筛选流水线。6.1 需求拆解简历筛选任务可以拆成五个步骤上传简历文件。解析 PDF/Word提取纯文本。利用大模型抽取关键字段。根据岗位要求规则打分。输出结构化评分表。6.2 工作流节点设计在 WorkBuddy 工作台画布上可以这样设计节点{ workflow: { name: resume_screening, nodes: [ { id: upload, type: file_upload, description: 接收简历文件 }, { id: parse, type: document_parser, description: 提取 PDF/Word 文本 }, { id: extract, type: llm_extract, prompt: 从简历中提取姓名、工作年限、技能列表、学历信息 }, { id: score, type: rule_score, rules: { require_skills: [Python, AI, 项目管理], min_years: 3 } }, { id: output, type: table_output, description: 生成打分表 } ] } }这个工作流的关键在extract节点。不要直接把整篇简历抛给模型而是先让模型抽取结构化字段再交给规则评分。这样做的好处是模型只负责它擅长的语义理解分数计算交给确定性规则结果稳定可解释。6.3 提示词与评分规则extract节点的提示词可以这样写请从以下简历文本中提取结构化信息并返回 JSON 格式 { name: 姓名, years: 工作年限数字, skills: [技能1, 技能2], education: 最高学历 } 简历文本 {resume_text}score节点根据返回的 JSON 计算得分。规则不需要复杂可以先用简单的加减分命中一个必需技能加 10 分。工作年限大于等于要求值加 20 分。学历达到要求加 10 分。这套规则的好处是透明。面试官看到 80 分的简历能明确知道分数来自哪里而不是模型给出一个凭空计算的“匹配度”。6.4 输出格式最终输出建议保存为 CSV 或 JSON方便后续导入表格工具。CSV 的列可以设计为姓名、工作年限、技能命中情况、学历、总分、是否进入面试。到这里一条简历筛选工作流就设计完成了。你还可在upload节点之前增加一个批量文件夹扫描节点实现一次处理多份简历。7. 运行结果与效果验证7.1 运行命令在虚拟环境中直接运行转换脚本python nodes/markdown_to_word_workflow.py README.md --output output/README.docx如果是在 WorkBuddy 工作台里运行只需要指定输入文件路径技能会自动调用底层脚本。7.2 预期输出正常情况下控制台输出已生成 Word 文件: output/README.docx打开output目录可以找到生成的 Word 文件标题层级和段落顺序应与 Markdown 源文件一致。7.3 验证清单运行成功后建议按以下清单检查一级标题是否变成了 Word 的一级标题。二级、三级标题层级是否正常。普通段落是否完整。生成的 Word 能否用 Office 或 WPS 正常打开。如果标题层级错乱优先查看 Markdown 源文件中的标题符号后面是否有空格以及工作流节点之间传递的字段名是否正确。8. 常见问题与排查方法实际搭建过程中新手遇到的问题基本集中在安装、依赖、上下文和节点配置四个方面。整理成下表方便直接对照排查。问题现象可能原因排查方式解决方案安装后无法启动系统缺少运行库或版本不兼容查看启动日志确认系统版本更新操作系统组件换用稳定版安装Python 脚本提示找不到模块依赖未安装或虚拟环境未激活运行pip list检查依赖执行pip install -r requirements.txt工作流节点之间数据为空字段名称不一致查看节点输入输出日志统一字段名确认大小写完全一致模型 API 连接超时Base URL 配置错误或网络不通单独测试 API 连通性检查地址和密钥确认服务商控制台可用上下文用量满了大量原始文档直接传入模型查看节点数据量先做摘要或字段提取减少传给模型的文本量技能触发不生效触发词没有配置检查技能注册文件补充trigger关键词并确认已保存生成的 Word 乱码编码不一致检查脚本读取编码在脚本中统一使用encodingutf-88.1 上下文用量满了怎么办这是高频问题。如果你遇到“上下文用量满了”提示不要急着换更大窗口的模型先做三件事检查工作流中是否有节点把整份大文档传给了模型。如果有改成先抽取关键字段再传。检查历史对话是否被保留。如果只是执行固定任务建议每次任务使用独立会话不要让历史消息持续累积。检查提示词中是否嵌入了大量静态说明。把固定说明移到系统提示词中减少每轮请求的重复消耗。上下文管理是工作台使用中最重要的工程能力之一。养成“能传摘要就不传全文能传字段就不传原文”的习惯可以显著降低成本和报错概率。9. 最佳实践与工程建议9.1 技能命名与目录规范建议按领域_动作的格式命名技能比如doc_markdown_to_word、hr_resume_extract。目录结构可以采用workbench/ ├── skills/ │ ├── markdown_to_word/ │ │ ├── skill.json │ │ └── main.py │ └── resume_screening/ │ ├── skill.json │ └── main.py ├── workflows/ ├── nodes/ ├── output/ └── requirements.txt命名规范的意义在于复用。一个月后你再打开工作台看到skill.json里的描述就能快速判断这个技能是干什么的而不用点开代码逐行阅读。9.2 配置与密钥管理API Key、服务地址、模型名称不要散落在脚本里。推荐做法把敏感配置写入环境变量或密钥管理模块。工作流配置中使用占位符引用。不要将.env文件提交到公开仓库。定期轮换 API Key降低泄露风险。9.3 工作流拆分原则一个工作流只做一件完整的事。如果发现某个工作流节点超过 5 个可以拆分成多个技能再组合。过度复杂的单条工作流会让排错变得非常困难。优先保证每个节点输入输出明确、单一。节点的作用越单一越容易被复用和测试。9.4 日志与异常处理在所有自定义脚本中建议加入日志输出。Python 的logging模块比print更适合排查生产问题。例如import logging logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) logger.info(开始读取文件: %s, input_path)日志要记录关键路径输入文件路径、解析结果条数、输出文件路径、异常堆栈。这样在工作流运行失败时可以快速定位到具体步骤。9.5 安全边界与最小权限如果工作台要访问公司内部系统务必遵守最小权限原则只授予完成当前任务所需的访问权限不要将管理员密钥配置到普通工作流中。还需要确认相关任务获得了合法授权在生产环境执行前先在测试环境验证。对于涉及隐私的文档比如简历、合同建议工作流只输出处理后的摘要字段不要将完整原始内容写入日志。9.6 备份与回滚工作台配置、技能文件、工作流定义本质上都是源码。建议纳入版本管理每次修改前打标签或提交记录。一旦新版本运行异常可以快速回滚到上一个可用版本。具体的做法是每次修改技能文件后提交一次记录并附带一句改动说明。这样即使工作台界面无法自动回滚你也可以通过版本记录手动恢复文件。10. 总结与后续学习方向回到开头那个问题为什么有人用 AI 像流水线有人还在复制粘贴差别不在于模型强弱而在于是否愿意把一次性的问答沉淀成可复用的技能与工作流。WorkBuddy 提供了这层能力但真正把工作台用起来的是你对任务的拆解能力、对上下文的控制意识以及持续迭代的耐心。读完这篇文章建议按顺序完成三个练习搭建一个空白工作台接入模型服务跑通一句对话。复现 Markdown 转 Word 技能理解节点、技能、工作流之间的关系。设计一条简历筛选工作流先不追求完美用 5 个节点把流程跑通。下一步可以继续研究的知识点包括RAG 知识库接入、多模型路由、定时触发工作流、以及如何把工作流封装成对外 API。每一条都建立在今天这套基础之上。收藏备用下次搭工作台的时候直接对着操作会少走很多弯路。
