先问大家一个问题你平时是怎么管理 AI 工具和提示词的是不是浏览器里堆了几十个标签页微信收藏里存了一堆提示词截图写个周报要在三四个 AI 工具之间来回切换如果你的答案是“是”那么 WorkBuddy 这类 AI 工作台工具就是为你准备的。这篇文章会把 WorkBuddy 从安装到实战完整拆开讲一遍。你不需要有编程基础只要会用命令行和文本编辑器就能跟着搭建一套属于自己的 AI 工作台。我会从核心概念讲起然后逐步完成一个“简历筛选 面试题生成”的完整工作流最后再补充自定义指令、插件使用、常见排错和工程化建议。目录导读什么是 WorkBuddy为什么需要 AI 工作台环境准备与安装核心概念工作流、Skill、自定义指令实战手把手搭建一个“简历筛选”工作流进阶把工作流接入本地文件与命令行工具常见问题与排查思路最佳实践与工程建议学习路线推荐1. 什么是 WorkBuddy为什么需要 AI 工作台1.1 从“多个 AI 工具”到“一个 AI 工作台”先说背景。最近两年 AI 工具越来越多每个工具都擅长不同的事有的擅长写代码有的擅长文本总结有的擅长生成图片。但问题也随之而来——工具之间的切换成本很高。你可能会遇到这些场景想让 AI 读一份本地 JSON 日志文件再把分析结果自动整理成 Markdown 文档。想让 AI 按固定模板输出周报但每次都要重新输入一大段提示词。想把某个 AI 助手接入自己的项目目录、脚本、甚至是命令行终端。WorkBuddy 这样的 AI 工作台本质上就是把“AI 对话能力”、“工作流编排能力”、“本地文件/命令执行能力”整合到一个统一界面里。你可以理解成它是给 AI 用的“操作系统桌面”。1.2 WorkBuddy 解决的核心问题WorkBuddy 主要解决四个问题环境统一。不需要在网页、桌面端、终端之间来回切换所有 AI 任务在同一个工作台里完成。流程固化。把多次重复的“提示词 工具调用 结果处理”组合成一条工作流下次一键运行。技能沉淀。把常用的提示词、脚本、模板封装成 Skill像安装插件一样按需加载。本地能力打通。在合法授权且你拥有对应文件/系统权限的前提下让 AI 能访问本地文件、执行命令完成自动化任务。这里要强调一句凡是涉及本地文件读取和命令执行的 AI 工具都要注意权限边界。建议只对你有所有权、且不影响系统稳定的文件或命令开放权限生产环境操作前务必先备份。1.3 常见应用场景从社区反馈和项目实践来看WorkBuddy 的典型使用场景包括场景具体任务工作量对比简历筛选读取一批简历文件按 JD 打分并输出排名人工 2 小时 → 工作流 10 分钟周报生成汇总 Git 提交记录和项目日志生成周报每周 40 分钟 → 一键生成代码审查对指定目录代码做静态风格检查和问题标注人工 1 小时 → 工作流 20 分钟文档转换将 Markdown 批量转入 Word 或 PDF手动复制排版 → 自动批处理知识库问答基于本地文档建立索引实现定向问答直接对话不再翻文件夹这篇文章后面的实战案例会重点演示“简历筛选”这条工作流因为它既涉及文件读取、又涉及 AI 打分、还涉及结果输出非常适合用来理解 WorkBuddy 的设计逻辑。2. 环境准备与安装2.1 操作系统与基础环境WorkBuddy 的定位是本地优先的 AI 工作台因此对操作系统主要要求是Windows 10/11macOS 12或者主流 Linux 发行版Ubuntu 22.04、Debian 12 等。命令行工具Windows 建议 PowerShell 7macOS/Linux 使用系统自带终端。网络面试题面试考查重点面试评价建议、候选人总评满分 10 分。映射到 WorkBuddy Skill 里就是三部分Skill 配置文件声明输入参数、输出格式。提示词模板包含 JD 要求、评分规则、输出格式约束。输出模板固定输出 Markdown 报告。Skill 的设计原则是“提示词和代码分离”。提示词负责定义“怎么判断”代码负责处理“怎么读文件、怎么写结果”。3.3 自定义指令让 AI 记住你的偏好自定义指令Custom Instructions是全局性的偏好设置。比如你希望 AI 都用中文回答。你希望代码示例包含注释。你希望输出尽量使用 Markdown 表格。你希望 AI 在不确定时直接说“不确定”而不是编造。这些偏好一旦配置成自定义指令就会在每次对话中自动生效不需要重复说明。WorkBuddy 里自定义指令的编写建议遵循“友好语气 明确要求 边界说明”。下面是一个示例你是我的 AI 工程师助手。 1. 所有回答使用中文技术术语保留英文原词。 2. 代码示例必须完整、可运行并添加中文注释。 3. 如果问题涉及生产环境需要先提示风险和备份要求。 4. 如果信息不足明确说明你的假设不要编造数据。 5. 回答尽量结构化善用列表和表格。3.4 工作流、Skill、自定义指令的关系用一个表格总结它们的分工概念作用范围类比工作流串联多个步骤自动化执行流程工厂流水线Skill复用一组能力按需加载工具箱里的工具自定义指令全局偏好影响每次交互员工手册理解了三者的关系后面动手做项目就不会混乱。简单说工作流是大框架Skill 是能力模块自定义指令是行为准则。4. 实战案例搭建“简历筛选 面试题生成”工作流这一节是文章的核心。我们通过 WorkBuddy 完成一次完整的简历筛选任务。整个流程如下准备 JD 和简历文件。读取简历文件并提取关键信息。按 JD 要求逐项打分。生成候选人排名报告。自动输出一组定制面试题。4.1 创建项目结构在本地创建一个项目文件夹名字随意例如workbuddy-recruit-demomkdir workbuddy-recruit-demo cd workbuddy-recruit-demo项目内部建议按下面结构组织workbuddy-recruit-demo/ ├── data/ │ ├── JD.md │ └── resumes/ │ ├── candidate_01.md │ ├── candidate_02.json │ └── candidate_03.md ├── skills/ │ └── resume-screener/ │ ├── config.yaml │ └── prompt.md └── output/4.2 编写岗位描述 JD在data/JD.md中写入招聘要求# 岗位Python 后端开发工程师 ## 基本要求 - 3 年以上 Python 开发经验 - 熟悉 FastAPI 或 Django 框架 - 熟悉 PostgreSQL 数据库设计 - 有 RESTful API 设计经验 ## 加分项 - 有 CI/CD 经验 - 有 Docker/K8s 部署经验 - 有 AI 应用开发经验4.3 编写 Skill 配置在skills/resume-screener/config.yaml中配置 Skillname: resume-screener description: 简历筛选与面试题生成 version: 1.0.0 inputs: - name: jd_text type: string description: 岗位描述文本 - name: resume_paths type: array description: 简历文件路径列表 outputs: - name: report type: markdown description: 候选人评价报告这个配置文件告诉 WorkBuddy该 Skill 接收两个输入JD 文本和简历文件路径输出一份 Markdown 报告。这样在工作流编排时WorkBuddy 就能知道如何传递参数。4.4 编写 Skill 提示词在skills/resume-screener/prompt.md中定义评分逻辑你是一名资深技术面试官。请根据以下岗位 JD 和候选人简历完成评估。 ## JD {jd_text} ## 评估规则 1. 逐一检查候选人简历中是否满足 JD 的基本要求。 2. 每满足一条就得 1 分不满足不得分。 3. 加分项每满足一条额外加 0.5 分。 4. 最终得分为百分制满分 100 分。 ## 输出要求 对每位候选人输出 - 姓名从简历中提取 - 工作年限 - 技术栈关键词 - 匹配得分 - 优势 - 风险点 - 建议通过 / 待定 / 不通过 - 针对性面试题3 道 最后输出一个候选人综合排名表格。注意{jd_text}是占位符WorkBuddy 运行工作流时会用真实的 JD 文本替换它。4.5 编写工作流定义在workflow.yaml中定义完整工作流name: resume-screening-workflow description: 简历筛选与面试题生成工作流 steps: - name: read_jd type: file.read params: path: data/JD.md - name: list_resumes type: file.list params: path: data/resumes extension: [md, json] - name: screen_resumes type: skill.run skill: resume-screener params: jd_text: ${steps.read_jd.result} resume_paths: ${steps.list_resumes.result} - name: save_report type: file.write params: path: output/report.md content: ${steps.screen_resumes.result}这个工作流定义了四个步骤读取 JD 文件。扫描简历目录下所有.md和.json文件。调用resume-screenerSkill 进行评估。把结果保存到output/report.md。这里的${steps.xxx.result}是 WorkBuddy 的变量引用语法用于把前一步的输出传给后一步。不同版本的 WorkBuddy 语法可能略有差异你可以在官方工作流编辑器中直接拖拽连线来生成等价配置。4.6 运行工作流在命令行中运行workbuddy run workflow.yaml如果你的环境变量或命令名不同请参考你本机安装版本的手册。运行过程中WorkBuddy 会按顺序执行每个步骤并在终端输出进度日志。4.7 预期输出示例运行成功后output/report.md的内容大致如下# 候选人评估报告 ## 综合排名 | 排名 | 候选人 | 匹配得分 | 结论 | | --- | --- | --- | --- | | 1 | 张三 | 92 | 通过 | | 2 | 李四 | 78 | 待定 | | 3 | 王五 | 45 | 不通过 | ## 张三92 分 - 工作年限5 年 - 技术栈Python, FastAPI, PostgreSQL, Docker - 优势同时满足基本要求和 CI/CD、Docker 加分项 - 风险点无 AI 应用经验 - 建议通过 ### 面试题 1. 介绍一下你在 FastAPI 项目中如何设计异步任务。 2. 如果 PostgreSQL 查询缓慢你会怎么排查 3. 你如何设计一个具备幂等性的 REST API到这个节点你已经完成了第一个完整的 WorkBuddy 工作流。整个过程不需要打开任何网页版 AI 工具也不需要手动复制粘贴属于“一键运行”的标准形态。5. 进阶技巧接入本地脚本和命令行工具工作流能串联的不只是 AI 对话和文件读写。WorkBuddy 也支持把本地脚本和命令行工具连接到工作流节点中。这在处理批量数据处理、代码检查、文档转换时非常有用。5.1 在 Skill 中调用命令行脚本假设你想在工作流结束后把报告自动转成 Word 文档。可以在 Skill 的配置中声明一个命令节点# skills/md-to-docx/skill.yaml 示意 name: md-to-docx description: Markdown 转 Word 文档 commands: - run: | pandoc report.md -o report.docx note: 执行前请确认本机已安装 pandoc在编排工作流时把这个节点添加到 report 生成之后即可steps: - name: save_report type: file.write params: path: output/report.md content: ${steps.screen_resumes.result} - name: convert_to_docx type: command.run skill: md-to-docx5.2 使用 Python 脚本扩展能力如果需要更复杂的本地数据处理你可以在 Skill 中定义 Python 脚本。下面以“读取候选人 JSON 简历并抽取技能标签”为例# skills/resume-screener/extract_skills.py import json import sys def extract_skills(resume_path): with open(resume_path, r, encodingutf-8) as f: data json.load(f) skills data.get(skills, []) return , .join(skills) if __name__ __main__: path sys.argv[1] print(extract_skills(path))这个脚本的作用是传入一个 JSON 简历文件路径提取其中的skills字段并输出。WorkBuddy 运行该脚本时会把脚本输出作为节点的返回值供下游节点使用。python extract_skills.py data/resumes/candidate_02.json # 预期输出Python, PostgreSQL, FastAPI注意这个示例脚本比较简单实际项目中你应该加上异常处理、路径校验等逻辑。5.3 推荐习惯把“跑命令”变成“磨流程”初学 AI 工作台的人容易把工作流做成“一次性脚本”。更推荐的做法是先手动跑通一次所有步骤记录每一步的输入、输出。再把稳定的步骤固化成工作流节点。最后把可复用的部分抽成 Skill。这样当任务量爆炸、输入文件变化时你只需要替换数据文件不需要重新设计流程。6. 常见问题与排查思路6.1 高频问题表格问题现象常见原因解决思路启动失败依赖版本不兼容或缺少 Python 环境查看日志统一 Python 版本重装依赖工作流运行到某个节点报错上游节点输出为空在可视化面板中检查该节点的输出详情提示“请安装缺失的包以使用此工作流”当前环境中缺少对应 Python 包按提示在 Python 环境中执行安装命令AI 生成的报告格式混乱提示词中没有给定输出模板在 Skill 提示词中明确输出格式和示例本地文件读取失败路径写错或权限不足检查文件路径是否为绝对路径确认进程拥有读取权限中文输出乱码编码问题通常缺少 UTF-8 设置在脚本文件头部指定 UTF-8 编码自定义指令不生效指令保存后没重启会话保存指令后新建对话测试6.2 “缺失包”问题的典型处理流程这个报错很常见。用户从别人分享的工作流里导入了配置但本地环境缺少若干依赖。处理流程如下打开终端进入 WorkBuddy 的 Python 虚拟环境。查看报错信息中列出的缺失包名。执行安装命令pip install 包名重启 WorkBuddy。如果缺失的包较多建议使用项目级requirements.txt统一管理pip freeze requirements.txt pip install -r requirements.txt还有一个小技巧在运行他人分享的工作流之前先检查它的requirements.txt或environment.yaml文件提前把依赖装好可以省去反复报错的麻烦。6.3 工作流逻辑排查建议如果工作流运行了但结果不符合预期可以按以下顺序排查先确认输入文件是否正确。查看 JD 文件是否为空简历路径是否存在。查看中间节点的输出。WorkBuddy 的可视化面板通常允许你查看每个节点的输出结果。检查提示词是否把结构化要求写清楚了。AI 模型对“请输出表格”和“请输出以下格式的表格”的理解差别很大。小样本测试。先用一个简历运行确认效果后再批量处理。7. 最佳实践与工程建议7.1 把提示词当代码管理这是我从实际项目中得到的最大体会。很多人把提示词存在 AI 对话框里想着“下次复制出来用”。但真实情况是你根本找不到上次写到哪里了。更好的做法是把提示词文件纳入 Git 管理。每次修改提示词后记录修改原因和效果。多版本对比时可以用 diff 工具查看变化。一个典型的仓库结构ai-workbench/ ├── skills/ │ ├── resume-screener/ │ ├── weekly-report/ │ └── code-review/ ├── workflows/ │ ├── resume-screening.yaml │ └── weekly-report.yaml ├── prompts/ │ └── common/ │ └── output-format.md └── requirements.txt在团队协作中这套结构可以保证提示词和工作流配置是可审查、可回滚的。注意如果项目涉及敏感数据不要把真实数据提交到 Git添加.gitignore忽略数据目录。7.2 注意信息安全和权限边界使用 WorkBuddy 读取本地文件、执行命令时必须守住这几个原则只处理你有权限访问的文件。脚本中不要硬编码密钥和 Token。生产环境的变更操作先在小范围测试再决定是否执行。涉及数据库删除、更新时必须有备份和回滚方案。不要轻易把工作流分享到公网除非确认其中没有敏感内容。尤其要注意AI 生成的命令不一定安全。当 AI 建议你执行一段命令时逐字检查后再执行特别是带有rm、drop、format等字样的命令。7.3 输出模板的稳定性设计在工作流场景中AI 的输出格式稳定性直接影响下游节点的处理。推荐在提示词中提供“输出模板示例”而不是只描述格式。例如请按以下 Markdown 表格输出不要增加额外字段 | 候选人 | 得分 | 结论 | 建议 | | --- | --- | --- | --- | | 张三 | 92 | 通过 | 进入二面 |当提示词中同时包含“规则描述”和“输出示例”时模型的遵循度会明显提高。7.4 设计可复用的 Skill 接口Skill 的输入参数名要语义化不要用a、b、data1这种名字。推荐参数命名规则用名词短语resume_paths、jd_text、output_format。参数默认值要合理避免每次调用都要填。在 Skill 配置中注明参数类型和是否必填。这样可以方便团队其他人复用你的 Skill也方便后续自己维护。7.5 日志与观测工作流一旦多了就需要关注运行记录。实践中有几个方向保留输出文件的历史版本而不是直接覆盖。在关键节点记录输入输出摘要。对失败的节点自动保存当时的错误日志。举个例子工作流运行失败时WorkBuddy 可能在终端输出一堆堆栈。你可以在工作流定义中增加一个catch逻辑- name: on_fail type: file.write params: path: output/error.log content: ${steps.xxx.error}这样就可以把错误信息固定到文件中方便排错。8. 学习路线与下一步建议8.1 你已经掌握的内容通过本文你应该已经理解WorkBuddy 是 AI 工作台用来统一管理 AI 对话、工作流、Skill 和自定义指令。工作流能够串联“读文件、跑Skill、写文件、执行命令”等步骤。Skill 是把提示词、脚本和配置打包复用的能力单元。自定义指令控制 AI 的全局行为。“简历筛选 面试题生成”是一个可以一键运行的完整工作流案例。遇到“缺失包”“文件读取失败”“格式混乱”等常见报错时知道从哪里开始排查。8.2 下一步可以尝试的方向如果你想把 AI 工作台应用到更广的场景推荐按这个顺序进阶周报自动化读取 Git 提交记录汇总项目进展生成周报。代码审查配置代码审查 Skill定时扫描项目代码并输出问题清单。文档批处理把批量 Markdown 文件转成 Word 或 PDF。本地知识库基于本地文档建立 AI 问答减少翻文件时间。团队 SOP 沉淀把团队定期执行的流程固化成工作流减少重复劳动。这些方向本质上都是同一套思路找到重复任务 → 拆解成步骤 → 用工作流串联 → 沉淀成 Skill → 持续优化提示词。8.3 两个实用建议第一先做小流程。不要把第一个工作流设计成“全自动处理所有简历”。先拿一个文件、一个小任务跑通再逐步扩展。第二保留自己的提示词库。每当你发现一个有效的提示词就立刻存到项目仓库里分类归好。时间久了这比任何教程都值钱。AI 工作台的价值不是“帮你写一段提示词”而是“帮你把提示词变成可复用、可编排、可维护的工程资产”。WorkBuddy 只是一个起点希望你在自己的项目里把这套工作流方法论真正用起来。如果这篇文章对你有帮助可以收藏备用。也欢迎在实际使用中带着具体问题来交流踩坑排错的经验比教程本身更有价值。 WorkBuddy实战：从零搭建AI工作台与简历筛选工作流
先问大家一个问题你平时是怎么管理 AI 工具和提示词的是不是浏览器里堆了几十个标签页微信收藏里存了一堆提示词截图写个周报要在三四个 AI 工具之间来回切换如果你的答案是“是”那么 WorkBuddy 这类 AI 工作台工具就是为你准备的。这篇文章会把 WorkBuddy 从安装到实战完整拆开讲一遍。你不需要有编程基础只要会用命令行和文本编辑器就能跟着搭建一套属于自己的 AI 工作台。我会从核心概念讲起然后逐步完成一个“简历筛选 面试题生成”的完整工作流最后再补充自定义指令、插件使用、常见排错和工程化建议。目录导读什么是 WorkBuddy为什么需要 AI 工作台环境准备与安装核心概念工作流、Skill、自定义指令实战手把手搭建一个“简历筛选”工作流进阶把工作流接入本地文件与命令行工具常见问题与排查思路最佳实践与工程建议学习路线推荐1. 什么是 WorkBuddy为什么需要 AI 工作台1.1 从“多个 AI 工具”到“一个 AI 工作台”先说背景。最近两年 AI 工具越来越多每个工具都擅长不同的事有的擅长写代码有的擅长文本总结有的擅长生成图片。但问题也随之而来——工具之间的切换成本很高。你可能会遇到这些场景想让 AI 读一份本地 JSON 日志文件再把分析结果自动整理成 Markdown 文档。想让 AI 按固定模板输出周报但每次都要重新输入一大段提示词。想把某个 AI 助手接入自己的项目目录、脚本、甚至是命令行终端。WorkBuddy 这样的 AI 工作台本质上就是把“AI 对话能力”、“工作流编排能力”、“本地文件/命令执行能力”整合到一个统一界面里。你可以理解成它是给 AI 用的“操作系统桌面”。1.2 WorkBuddy 解决的核心问题WorkBuddy 主要解决四个问题环境统一。不需要在网页、桌面端、终端之间来回切换所有 AI 任务在同一个工作台里完成。流程固化。把多次重复的“提示词 工具调用 结果处理”组合成一条工作流下次一键运行。技能沉淀。把常用的提示词、脚本、模板封装成 Skill像安装插件一样按需加载。本地能力打通。在合法授权且你拥有对应文件/系统权限的前提下让 AI 能访问本地文件、执行命令完成自动化任务。这里要强调一句凡是涉及本地文件读取和命令执行的 AI 工具都要注意权限边界。建议只对你有所有权、且不影响系统稳定的文件或命令开放权限生产环境操作前务必先备份。1.3 常见应用场景从社区反馈和项目实践来看WorkBuddy 的典型使用场景包括场景具体任务工作量对比简历筛选读取一批简历文件按 JD 打分并输出排名人工 2 小时 → 工作流 10 分钟周报生成汇总 Git 提交记录和项目日志生成周报每周 40 分钟 → 一键生成代码审查对指定目录代码做静态风格检查和问题标注人工 1 小时 → 工作流 20 分钟文档转换将 Markdown 批量转入 Word 或 PDF手动复制排版 → 自动批处理知识库问答基于本地文档建立索引实现定向问答直接对话不再翻文件夹这篇文章后面的实战案例会重点演示“简历筛选”这条工作流因为它既涉及文件读取、又涉及 AI 打分、还涉及结果输出非常适合用来理解 WorkBuddy 的设计逻辑。2. 环境准备与安装2.1 操作系统与基础环境WorkBuddy 的定位是本地优先的 AI 工作台因此对操作系统主要要求是Windows 10/11macOS 12或者主流 Linux 发行版Ubuntu 22.04、Debian 12 等。命令行工具Windows 建议 PowerShell 7macOS/Linux 使用系统自带终端。网络面试题面试考查重点面试评价建议、候选人总评满分 10 分。映射到 WorkBuddy Skill 里就是三部分Skill 配置文件声明输入参数、输出格式。提示词模板包含 JD 要求、评分规则、输出格式约束。输出模板固定输出 Markdown 报告。Skill 的设计原则是“提示词和代码分离”。提示词负责定义“怎么判断”代码负责处理“怎么读文件、怎么写结果”。3.3 自定义指令让 AI 记住你的偏好自定义指令Custom Instructions是全局性的偏好设置。比如你希望 AI 都用中文回答。你希望代码示例包含注释。你希望输出尽量使用 Markdown 表格。你希望 AI 在不确定时直接说“不确定”而不是编造。这些偏好一旦配置成自定义指令就会在每次对话中自动生效不需要重复说明。WorkBuddy 里自定义指令的编写建议遵循“友好语气 明确要求 边界说明”。下面是一个示例你是我的 AI 工程师助手。 1. 所有回答使用中文技术术语保留英文原词。 2. 代码示例必须完整、可运行并添加中文注释。 3. 如果问题涉及生产环境需要先提示风险和备份要求。 4. 如果信息不足明确说明你的假设不要编造数据。 5. 回答尽量结构化善用列表和表格。3.4 工作流、Skill、自定义指令的关系用一个表格总结它们的分工概念作用范围类比工作流串联多个步骤自动化执行流程工厂流水线Skill复用一组能力按需加载工具箱里的工具自定义指令全局偏好影响每次交互员工手册理解了三者的关系后面动手做项目就不会混乱。简单说工作流是大框架Skill 是能力模块自定义指令是行为准则。4. 实战案例搭建“简历筛选 面试题生成”工作流这一节是文章的核心。我们通过 WorkBuddy 完成一次完整的简历筛选任务。整个流程如下准备 JD 和简历文件。读取简历文件并提取关键信息。按 JD 要求逐项打分。生成候选人排名报告。自动输出一组定制面试题。4.1 创建项目结构在本地创建一个项目文件夹名字随意例如workbuddy-recruit-demomkdir workbuddy-recruit-demo cd workbuddy-recruit-demo项目内部建议按下面结构组织workbuddy-recruit-demo/ ├── data/ │ ├── JD.md │ └── resumes/ │ ├── candidate_01.md │ ├── candidate_02.json │ └── candidate_03.md ├── skills/ │ └── resume-screener/ │ ├── config.yaml │ └── prompt.md └── output/4.2 编写岗位描述 JD在data/JD.md中写入招聘要求# 岗位Python 后端开发工程师 ## 基本要求 - 3 年以上 Python 开发经验 - 熟悉 FastAPI 或 Django 框架 - 熟悉 PostgreSQL 数据库设计 - 有 RESTful API 设计经验 ## 加分项 - 有 CI/CD 经验 - 有 Docker/K8s 部署经验 - 有 AI 应用开发经验4.3 编写 Skill 配置在skills/resume-screener/config.yaml中配置 Skillname: resume-screener description: 简历筛选与面试题生成 version: 1.0.0 inputs: - name: jd_text type: string description: 岗位描述文本 - name: resume_paths type: array description: 简历文件路径列表 outputs: - name: report type: markdown description: 候选人评价报告这个配置文件告诉 WorkBuddy该 Skill 接收两个输入JD 文本和简历文件路径输出一份 Markdown 报告。这样在工作流编排时WorkBuddy 就能知道如何传递参数。4.4 编写 Skill 提示词在skills/resume-screener/prompt.md中定义评分逻辑你是一名资深技术面试官。请根据以下岗位 JD 和候选人简历完成评估。 ## JD {jd_text} ## 评估规则 1. 逐一检查候选人简历中是否满足 JD 的基本要求。 2. 每满足一条就得 1 分不满足不得分。 3. 加分项每满足一条额外加 0.5 分。 4. 最终得分为百分制满分 100 分。 ## 输出要求 对每位候选人输出 - 姓名从简历中提取 - 工作年限 - 技术栈关键词 - 匹配得分 - 优势 - 风险点 - 建议通过 / 待定 / 不通过 - 针对性面试题3 道 最后输出一个候选人综合排名表格。注意{jd_text}是占位符WorkBuddy 运行工作流时会用真实的 JD 文本替换它。4.5 编写工作流定义在workflow.yaml中定义完整工作流name: resume-screening-workflow description: 简历筛选与面试题生成工作流 steps: - name: read_jd type: file.read params: path: data/JD.md - name: list_resumes type: file.list params: path: data/resumes extension: [md, json] - name: screen_resumes type: skill.run skill: resume-screener params: jd_text: ${steps.read_jd.result} resume_paths: ${steps.list_resumes.result} - name: save_report type: file.write params: path: output/report.md content: ${steps.screen_resumes.result}这个工作流定义了四个步骤读取 JD 文件。扫描简历目录下所有.md和.json文件。调用resume-screenerSkill 进行评估。把结果保存到output/report.md。这里的${steps.xxx.result}是 WorkBuddy 的变量引用语法用于把前一步的输出传给后一步。不同版本的 WorkBuddy 语法可能略有差异你可以在官方工作流编辑器中直接拖拽连线来生成等价配置。4.6 运行工作流在命令行中运行workbuddy run workflow.yaml如果你的环境变量或命令名不同请参考你本机安装版本的手册。运行过程中WorkBuddy 会按顺序执行每个步骤并在终端输出进度日志。4.7 预期输出示例运行成功后output/report.md的内容大致如下# 候选人评估报告 ## 综合排名 | 排名 | 候选人 | 匹配得分 | 结论 | | --- | --- | --- | --- | | 1 | 张三 | 92 | 通过 | | 2 | 李四 | 78 | 待定 | | 3 | 王五 | 45 | 不通过 | ## 张三92 分 - 工作年限5 年 - 技术栈Python, FastAPI, PostgreSQL, Docker - 优势同时满足基本要求和 CI/CD、Docker 加分项 - 风险点无 AI 应用经验 - 建议通过 ### 面试题 1. 介绍一下你在 FastAPI 项目中如何设计异步任务。 2. 如果 PostgreSQL 查询缓慢你会怎么排查 3. 你如何设计一个具备幂等性的 REST API到这个节点你已经完成了第一个完整的 WorkBuddy 工作流。整个过程不需要打开任何网页版 AI 工具也不需要手动复制粘贴属于“一键运行”的标准形态。5. 进阶技巧接入本地脚本和命令行工具工作流能串联的不只是 AI 对话和文件读写。WorkBuddy 也支持把本地脚本和命令行工具连接到工作流节点中。这在处理批量数据处理、代码检查、文档转换时非常有用。5.1 在 Skill 中调用命令行脚本假设你想在工作流结束后把报告自动转成 Word 文档。可以在 Skill 的配置中声明一个命令节点# skills/md-to-docx/skill.yaml 示意 name: md-to-docx description: Markdown 转 Word 文档 commands: - run: | pandoc report.md -o report.docx note: 执行前请确认本机已安装 pandoc在编排工作流时把这个节点添加到 report 生成之后即可steps: - name: save_report type: file.write params: path: output/report.md content: ${steps.screen_resumes.result} - name: convert_to_docx type: command.run skill: md-to-docx5.2 使用 Python 脚本扩展能力如果需要更复杂的本地数据处理你可以在 Skill 中定义 Python 脚本。下面以“读取候选人 JSON 简历并抽取技能标签”为例# skills/resume-screener/extract_skills.py import json import sys def extract_skills(resume_path): with open(resume_path, r, encodingutf-8) as f: data json.load(f) skills data.get(skills, []) return , .join(skills) if __name__ __main__: path sys.argv[1] print(extract_skills(path))这个脚本的作用是传入一个 JSON 简历文件路径提取其中的skills字段并输出。WorkBuddy 运行该脚本时会把脚本输出作为节点的返回值供下游节点使用。python extract_skills.py data/resumes/candidate_02.json # 预期输出Python, PostgreSQL, FastAPI注意这个示例脚本比较简单实际项目中你应该加上异常处理、路径校验等逻辑。5.3 推荐习惯把“跑命令”变成“磨流程”初学 AI 工作台的人容易把工作流做成“一次性脚本”。更推荐的做法是先手动跑通一次所有步骤记录每一步的输入、输出。再把稳定的步骤固化成工作流节点。最后把可复用的部分抽成 Skill。这样当任务量爆炸、输入文件变化时你只需要替换数据文件不需要重新设计流程。6. 常见问题与排查思路6.1 高频问题表格问题现象常见原因解决思路启动失败依赖版本不兼容或缺少 Python 环境查看日志统一 Python 版本重装依赖工作流运行到某个节点报错上游节点输出为空在可视化面板中检查该节点的输出详情提示“请安装缺失的包以使用此工作流”当前环境中缺少对应 Python 包按提示在 Python 环境中执行安装命令AI 生成的报告格式混乱提示词中没有给定输出模板在 Skill 提示词中明确输出格式和示例本地文件读取失败路径写错或权限不足检查文件路径是否为绝对路径确认进程拥有读取权限中文输出乱码编码问题通常缺少 UTF-8 设置在脚本文件头部指定 UTF-8 编码自定义指令不生效指令保存后没重启会话保存指令后新建对话测试6.2 “缺失包”问题的典型处理流程这个报错很常见。用户从别人分享的工作流里导入了配置但本地环境缺少若干依赖。处理流程如下打开终端进入 WorkBuddy 的 Python 虚拟环境。查看报错信息中列出的缺失包名。执行安装命令pip install 包名重启 WorkBuddy。如果缺失的包较多建议使用项目级requirements.txt统一管理pip freeze requirements.txt pip install -r requirements.txt还有一个小技巧在运行他人分享的工作流之前先检查它的requirements.txt或environment.yaml文件提前把依赖装好可以省去反复报错的麻烦。6.3 工作流逻辑排查建议如果工作流运行了但结果不符合预期可以按以下顺序排查先确认输入文件是否正确。查看 JD 文件是否为空简历路径是否存在。查看中间节点的输出。WorkBuddy 的可视化面板通常允许你查看每个节点的输出结果。检查提示词是否把结构化要求写清楚了。AI 模型对“请输出表格”和“请输出以下格式的表格”的理解差别很大。小样本测试。先用一个简历运行确认效果后再批量处理。7. 最佳实践与工程建议7.1 把提示词当代码管理这是我从实际项目中得到的最大体会。很多人把提示词存在 AI 对话框里想着“下次复制出来用”。但真实情况是你根本找不到上次写到哪里了。更好的做法是把提示词文件纳入 Git 管理。每次修改提示词后记录修改原因和效果。多版本对比时可以用 diff 工具查看变化。一个典型的仓库结构ai-workbench/ ├── skills/ │ ├── resume-screener/ │ ├── weekly-report/ │ └── code-review/ ├── workflows/ │ ├── resume-screening.yaml │ └── weekly-report.yaml ├── prompts/ │ └── common/ │ └── output-format.md └── requirements.txt在团队协作中这套结构可以保证提示词和工作流配置是可审查、可回滚的。注意如果项目涉及敏感数据不要把真实数据提交到 Git添加.gitignore忽略数据目录。7.2 注意信息安全和权限边界使用 WorkBuddy 读取本地文件、执行命令时必须守住这几个原则只处理你有权限访问的文件。脚本中不要硬编码密钥和 Token。生产环境的变更操作先在小范围测试再决定是否执行。涉及数据库删除、更新时必须有备份和回滚方案。不要轻易把工作流分享到公网除非确认其中没有敏感内容。尤其要注意AI 生成的命令不一定安全。当 AI 建议你执行一段命令时逐字检查后再执行特别是带有rm、drop、format等字样的命令。7.3 输出模板的稳定性设计在工作流场景中AI 的输出格式稳定性直接影响下游节点的处理。推荐在提示词中提供“输出模板示例”而不是只描述格式。例如请按以下 Markdown 表格输出不要增加额外字段 | 候选人 | 得分 | 结论 | 建议 | | --- | --- | --- | --- | | 张三 | 92 | 通过 | 进入二面 |当提示词中同时包含“规则描述”和“输出示例”时模型的遵循度会明显提高。7.4 设计可复用的 Skill 接口Skill 的输入参数名要语义化不要用a、b、data1这种名字。推荐参数命名规则用名词短语resume_paths、jd_text、output_format。参数默认值要合理避免每次调用都要填。在 Skill 配置中注明参数类型和是否必填。这样可以方便团队其他人复用你的 Skill也方便后续自己维护。7.5 日志与观测工作流一旦多了就需要关注运行记录。实践中有几个方向保留输出文件的历史版本而不是直接覆盖。在关键节点记录输入输出摘要。对失败的节点自动保存当时的错误日志。举个例子工作流运行失败时WorkBuddy 可能在终端输出一堆堆栈。你可以在工作流定义中增加一个catch逻辑- name: on_fail type: file.write params: path: output/error.log content: ${steps.xxx.error}这样就可以把错误信息固定到文件中方便排错。8. 学习路线与下一步建议8.1 你已经掌握的内容通过本文你应该已经理解WorkBuddy 是 AI 工作台用来统一管理 AI 对话、工作流、Skill 和自定义指令。工作流能够串联“读文件、跑Skill、写文件、执行命令”等步骤。Skill 是把提示词、脚本和配置打包复用的能力单元。自定义指令控制 AI 的全局行为。“简历筛选 面试题生成”是一个可以一键运行的完整工作流案例。遇到“缺失包”“文件读取失败”“格式混乱”等常见报错时知道从哪里开始排查。8.2 下一步可以尝试的方向如果你想把 AI 工作台应用到更广的场景推荐按这个顺序进阶周报自动化读取 Git 提交记录汇总项目进展生成周报。代码审查配置代码审查 Skill定时扫描项目代码并输出问题清单。文档批处理把批量 Markdown 文件转成 Word 或 PDF。本地知识库基于本地文档建立 AI 问答减少翻文件时间。团队 SOP 沉淀把团队定期执行的流程固化成工作流减少重复劳动。这些方向本质上都是同一套思路找到重复任务 → 拆解成步骤 → 用工作流串联 → 沉淀成 Skill → 持续优化提示词。8.3 两个实用建议第一先做小流程。不要把第一个工作流设计成“全自动处理所有简历”。先拿一个文件、一个小任务跑通再逐步扩展。第二保留自己的提示词库。每当你发现一个有效的提示词就立刻存到项目仓库里分类归好。时间久了这比任何教程都值钱。AI 工作台的价值不是“帮你写一段提示词”而是“帮你把提示词变成可复用、可编排、可维护的工程资产”。WorkBuddy 只是一个起点希望你在自己的项目里把这套工作流方法论真正用起来。如果这篇文章对你有帮助可以收藏备用。也欢迎在实际使用中带着具体问题来交流踩坑排错的经验比教程本身更有价值。