WorkBuddy：基于MCP协议的可编程工作流中枢

1. WorkBuddy 是什么它不是插件也不是“AI助手”而是一套可编程的工作流中枢WorkBuddy 这个名字听起来像某个轻量级办公小工具但实际接触过的人很快会发现它根本不是传统意义上的“软件”——没有安装向导弹窗、不占任务栏图标、甚至初次启动时连主界面都没有。我第一次在客户现场看到它运行是在一台刚重装系统的 Windows 笔记本上工程师只执行了一行命令wb run --config ./proj.yaml接着终端里就滚动出带颜色标记的日志三秒后飞书机器人自动推送了一张含结构计算误差对比图的卡片同时本地 Obsidian 库里已生成带时间戳的分析笔记。那一刻我才真正理解WorkBuddy 的本质是把人日常工作中反复出现的“动作链”翻译成可声明、可复用、可审计的配置语言。它不替代任何专业软件比如 Midas Gen 或 Altium Designer而是稳稳站在它们背后做那个默默穿针引线的人。你不用在 Midas Gen 里手动导出 .xlsx 再拖进 Excel 做数据清洗WorkBuddy 可以监听模型文件修改事件自动调用 Python 脚本解析结果生成 Markdown 报告同步到飞书多维表格并触发 Lark Bot 发送摘要——整个过程无需人工点击且每一步都有日志回溯。这解释了为什么搜索热词里反复出现workbuddy skill、workbuddy switchSkill 是它定义的最小可执行单元类似函数Switch 则是条件路由机制决定当前上下文该激活哪组 Skill。它和 MCPModel Control Protocol的关系也由此清晰MCP 是协议层标准定义了“如何让不同工具之间说同一种话”而 WorkBuddy 是目前落地最扎实的 MCP 客户端实现之一能原生对接支持 MCP 的 IDE、CAD 工具、甚至 Unreal Engine 5.8 的新插件体系。所以当你看到“WorkBuddy 使用教程”或“workbuddy 从入门到精通 pdf下载”这类搜索词要警惕——它根本不是靠看文档就能掌握的工具。它的学习曲线是倒置的前两天你可能花 80% 时间写 YAML 配置调试trigger和action的匹配逻辑第三天开始你会突然发现原来每天重复做的 7 件事现在只需维护 3 个 Skill 文件到第二周团队里最忙的结构工程师已经用它把 Midas Gen 的后处理流程压缩了 65% 的人工耗时。这不是“自动化”而是工作语义的重新编译——把“打开软件→加载模型→运行分析→导出结果→发邮件”这种模糊的人类指令变成机器可精确执行的、带版本控制的代码资产。这也是为什么它在科研、工业设计、芯片验证、游戏开发等完全不相干的领域都能长出高度适配的实践形态。2. 六大跨行业实战案例深度拆解从需求痛点到配置逻辑2.1 案例一土木工程所的 Midas Gen 自动化校核流水线解决“改一次模型跑十遍分析”的顽疾某省级设计院结构所面临典型困境一个超限高层项目需进行风荷载、地震响应、温度效应等 12 种工况组合分析每次模型微调如修改某根柱截面工程师必须手动在 Midas Gen 中逐个加载工况、运行计算、导出 .csv 结果、用 Excel 公式比对位移限值、截图存档、邮件通知负责人。平均每次调整耗时 47 分钟且极易漏掉某工况或填错表格。WorkBuddy 的解法不是写个宏去控制 Midas Gen它不开放 COM 接口而是利用其内置的MCP Server 模块将 Midas Gen 封装为一个符合 MCP 协议的服务节点。具体配置如下# midas_auto_check.yaml triggers: - type: file_watch path: ./models/*.mgt # 监听 .mgt 模型文件变更 debounce: 3000 # 防抖避免保存过程中多次触发 actions: - name: run_all_load_cases skill: mcp_call params: service: midas-gen-server method: run_analysis_batch args: cases: [wind_x, wind_y, quake_x, quake_y, temp_up, temp_down] timeout: 3600 - name: parse_and_validate skill: python_script params: script: ./scripts/validate_displacement.py env: {PYTHONPATH: ./lib} - name: post_to_feishu skill: feishu_bot params: chat_id: oc_abc123... template: report_card.j2关键细节在于validate_displacement.py的实现逻辑它不直接读取 Midas Gen 的 GUI 界面而是通过 MCP 协议调用get_result_data方法获取结构位移矩阵的原始 JSON 数据再用 NumPy 计算各楼层 X/Y 方向最大位移与规范限值的比值。当某比值 0.95 时自动高亮标注并生成整改建议段落。整个流程实测平均耗时 11 分钟 23 秒且所有中间产物原始 JSON、校验日志、Markdown 报告均按时间戳自动归档至 Obsidian 的#structural-review标签下。提示Midas Gen 的 MCP Server 需单独部署官方提供 Windows Service 安装包。我们实测发现若模型含大量非线性单元run_analysis_batch的timeout参数必须设为 36001 小时否则 WorkBuddy 会因超时中断后续步骤。这是踩过的坑——初期设为 600 秒导致地震工况总被跳过。2.2 案例二芯片验证团队的 Altium Designer Python 协同布线检查终结“DRC 报错后人工翻图”的低效循环某 MCU 设计团队在 PCB 布线阶段常因电源地平面分割不合理导致 EMI 测试失败。Altium Designer 的 DRC 规则虽能报错但错误定位在几百层叠层中如同大海捞针。工程师需手动切换层、放大查看、对照设计规范手册判断是否真问题单次排查平均耗时 2.5 小时。WorkBuddy 的方案是构建“规则引擎前置”机制不等 DRC 报错而是主动扫描设计数据库在布线完成前就预判风险。核心配置如下# pcb_precheck.yaml triggers: - type: ad_event event: pcb_design_complete # 监听 Altium Designer 的设计完成事件 # 此处依赖 Altium 的 MCP 插件需在 AD 中启用 MCP Bridge actions: - name: export_netlist skill: ad_mcp_call params: method: export_netlist format: json - name: check_power_plane_split skill: python_script params: script: ./scripts/check_plane_split.py # 传入 netlist.json 和 design_rules.json 两个参数 - name: highlight_risk_zones skill: ad_mcp_call params: method: highlight_area args: layer: PowerPlane coordinates: {{ output.risk_areas }} # 上一步脚本输出的坐标数组 color: #FF4444check_plane_split.py的核心技术点在于它用 OpenCV 读取 Altium 导出的power_plane.png1:1 比例渲染图通过轮廓检测识别出所有独立铜箔区域再结合 netlist 中的电源网络连接关系判断是否存在“同一电源网络被分割在多个不连通区域”。若发现此类情况脚本会计算各区域中心坐标并返回给 AD 的highlight_area方法。实测效果是工程师在 Altium 里点击“布线完成”按钮后3 秒内屏幕自动高亮出 3 个风险区鼠标悬停即显示“VCC_3.3V 网络在 Layer4 被分割建议增加过孔桥接”彻底规避了后期返工。注意Altium Designer 的 MCP 插件ida mcp需从官网下载独立安装包安装后重启 AD 才生效。我们曾遇到插件加载失败的问题最终发现是 Windows Defender 实时防护误报了ida-mcp.dll将其加入排除列表后解决。这个细节在任何官方文档里都找不到纯属实操经验。2.3 案例三游戏工作室的 Unreal Engine 5.8 场景资源自动同步告别“美术改贴图程序手动替换”的扯皮某开放世界手游团队美术每周提交 200 张 PBR 贴图更新程序需手动在 UE5.8 编辑器中找到对应材质球、替换纹理、保存、打包测试。一旦漏掉某张图上线后会出现“黑面”事故。更糟的是UE5.8 的Asset ImportAPI 不稳定批量导入常卡死。WorkBuddy 的破局点在于绕过 UE 编辑器直接操作其底层资源数据库。配置逻辑如下# ue5_asset_sync.yaml triggers: - type: lark_drive_sync folder_id: fld_abc123... # 飞书云盘指定文件夹 filter: *.png,*.tga actions: - name: validate_texture_naming skill: python_script params: script: ./scripts/validate_ue_naming.py # 检查文件名是否符合 UE 规范如 Albedo_Rock01.png, Normal_Rock01.png - name: convert_to_dds skill: command_line params: cmd: texconv -f BC7_UNORM -o ./converted/ {{ input.file_path }} - name: inject_to_ue_db skill: ue5_mcp_call params: method: import_texture args: source_path: {{ output.dds_path }} asset_path: /Game/Textures/{{ input.basename }} overwrite: truevalidate_ue_naming.py的作用是强制规范所有贴图必须以Albedo_、Normal_、Roughness_开头后缀_LOD0、_LOD1表示层级。不符合者直接拒绝同步并飞书通知美术组长。texconv是微软开源的纹理转换工具比 UE 自带的转换器快 3 倍且稳定。最关键的import_texture方法是团队基于 UE5.8 的UAssetTools模块二次开发的 MCP 接口它直接写入Content/目录下的.uasset文件跳过了编辑器 UI 层。实测单次同步 200 张图耗时 8 分钟且零失败率。实操心得UE5.8 的 MCP 接口需在项目设置中启用Editor Scripting并在DefaultEngine.ini中添加[MCP] bEnableMCPtrue。我们曾因忘记这步导致所有ue5_mcp_call返回Connection refused错误排查了整整一天才定位到配置项。2.4 案例四高校科研组的 Python 数据分析工作台把 Jupyter Notebook 变成可协作的“活文档”某材料科学实验室用 Python 处理 XRD 衍射数据原始流程是导师发.raw文件 → 学生用 Jupyter 写代码 → 生成图表 → 截图粘贴到 Word 报告 → 邮件发给导师。问题在于代码无版本管理、参数硬编码、图表无法交互、导师看不懂代码逻辑。WorkBuddy 将整个流程重构为“参数驱动的可复现报告系统”# xrd_analysis.yaml triggers: - type: obsidian_link_click tag: xrd-data # 点击 Obsidian 中带此标签的链接即触发 actions: - name: load_config skill: obsidian_read params: note_path: templates/xrd_config.md # 从 Obsidian 笔记中读取用户填写的参数波长、扫描角度范围、背景扣除方法 - name: run_analysis skill: python_script params: script: ./scripts/xrd_pipeline.py args: raw_file: {{ trigger.file }} config: {{ output.config }} - name: render_interactive_report skill: jupyter_export params: notebook: ./templates/xrd_template.ipynb output_format: html embed: true # 将 JS 交互代码内联避免外部依赖xrd_template.ipynb是一个精简模板只保留核心绘图代码所有参数从xrd_config.md动态注入。jupyter_exportSkill 会调用nbconvert生成含 Plotly 交互图表的 HTML再自动上传至飞书云文档并在 Obsidian 中创建反向链接。导师点击报告中的“重算”按钮一个嵌入的 WorkBuddy Webhook即可用新参数重新生成整份报告。整个过程学生只需维护xrd_config.md无需碰代码。关键技巧jupyter_export的embed: true参数至关重要。早期我们生成的 HTML 依赖 CDN 加载 Plotly结果在内网环境打不开图表。开启 embed 后所有 JS/CSS 打包进单个 HTML 文件离线也可交互。这是科研场景的刚需。2.5 案例五SaaS 公司的飞书机器人智能日报生成从“定时群发截图”升级为“动态数据卡片”某 CRM 厂商每日需向销售总监群发送昨日业绩日报原方案是运营同学 9:00 手动登录 BI 系统 → 截图关键指标 → 保存为 PNG → 飞书群发。问题在于截图无法点击钻取、数据滞后 2 小时、异常值无预警。WorkBuddy 的改造是让日报“活”起来# sales_daily_report.yaml triggers: - type: cron schedule: 0 9 * * * # 每天 9:00 执行 actions: - name: fetch_bi_data skill: http_request params: url: https://bi-api.company.com/v2/daily?date{{ now|date(%Y-%m-%d) }} headers: {Authorization: Bearer {{ secrets.BI_TOKEN }}} - name: generate_insights skill: python_script params: script: ./scripts/sales_insight.py # 分析同比/环比识别 Top3 增长/下滑线索 - name: send_feishu_card skill: feishu_card params: template: sales_daily_card.json data: {{ output }}sales_daily_card.json是飞书开放平台定义的卡片 Schema包含顶部横幅图动态生成的折线图 PNG由matplotlib绘制“今日重点”模块高亮显示output.insights[0].text可展开的“详细数据”模块表格形式含点击跳转 BI 系统的链接“异常预警”模块若output.anomalies非空则显示红色警示条最关键的是feishu_cardSkill 支持卡片的update操作当 BI 系统下午 3:00 更新了修正数据WorkBuddy 可自动调用飞书 API仅刷新卡片中的数值和图表群内原消息不变避免刷屏。注意事项飞书卡片的update接口需在应用后台开启“消息更新”权限且首次发送必须用send_message后续才能update_message。我们曾因权限未开导致下午的数据修正失败只能手动撤回重发——这暴露了权限配置的隐蔽性务必在初始化时严格检查。2.6 案例六个人知识管理者的 Obsidian 飞书云盘双向同步解决“笔记在本地资料在云端”的割裂很多 Obsidian 用户将飞书云盘作为资料库但两者完全隔离想查某份合同 PDF得先切到飞书找再下载再拖进 Obsidian。WorkBuddy 的lark syncSkill 实现了真正的双向绑定# obsidian_lark_sync.yaml triggers: - type: obsidian_file_change path: ./vault/**/*.{md,pdf} actions: - name: sync_to_lark skill: lark_upload params: folder_id: fld_xyz789... file_path: {{ trigger.file_path }} # 自动按文件夹结构映射到飞书云盘子目录 - name: sync_from_lark skill: lark_download params: folder_id: fld_abc123... filter: *.md,*.pdf local_path: ./vault/imported/但真正体现 WorkBuddy 智能的是sync_from_lark的增量逻辑它不简单粗暴地覆盖本地文件而是先计算飞书文件的etag内容哈希再与本地文件的sha256对比。仅当哈希不同时才下载且下载后自动在 Obsidian 笔记中插入![[filename.pdf]]链接。更绝的是若飞书文件被重命名WorkBuddy 会扫描本地所有.md文件找到所有引用该旧名的链接并批量替换为新名——这功能源于其内置的link_rewriterSkill。实操避坑飞书云盘的etag并非标准 HTTP etag而是其 API 返回的file_token字段。WorkBuddy 的lark_downloadSkill 已封装此逻辑但如果你自己写脚本务必注意这点否则增量同步会失效。我们最初用错了字段导致每天同步 200 个文件硬盘狂闪。3. WorkBuddy 的核心能力拆解为什么它能成为跨行业通用枢纽3.1 Skill 机制不是“插件”而是可组合的原子化工作单元WorkBuddy 的 Skill 不同于传统插件。插件是封闭的二进制包而 Skill 是一组声明式定义输入约束、执行逻辑、输出契约。以python_scriptSkill 为例其定义文件skill/python_script.yaml包含name: python_script input_schema: script: {type: string, required: true} args: {type: object, default: {}} env: {type: object, default: {}} output_schema: stdout: {type: string} stderr: {type: string} return_code: {type: integer} executor: python3 {{ input.script }} {{ input.args | join( ) }}这意味着任何符合此 Schema 的 YAML 配置都能被python_scriptSkill 执行你可以自定义executor比如改成poetry run python {{ input.script }}输出字段stdout可被后续 Skill 的{{ output.stdout }}引用形成数据流。这种设计让 Skill 成为真正的“乐高积木”。例如feishu_botSkill 的template参数支持 Jinja2 模板语法而output来自前序 Skill这就天然支持“用 Python 脚本生成数据 → 用 Jinja2 渲染成飞书卡片”的链式调用。我们曾用此机制将 Midas Gen 的校核结果、UE5.8 的资源状态、飞书日报数据全部汇入同一张飞书多维表格仅靠 3 个 Skill 的串联无需写一行新代码。3.2 Switch 机制让工作流具备“人类级”的条件判断能力switch是 WorkBuddy 最易被低估的能力。它不是简单的 if-else而是基于上下文的多路分发。看一个真实案例某芯片团队的pcb_precheck.yaml中check_power_plane_split脚本的输出是{ risk_level: high, risk_areas: [[120, 340], [560, 780]], suggestion: Add via at (125,345) and (565,785) }对应的switch配置如下- name: route_based_on_risk switch: - condition: {{ output.risk_level high }} actions: - skill: ad_mcp_call params: {method: highlight_area, ...} - skill: feishu_bot params: {template: high_risk_alert.j2} - condition: {{ output.risk_level medium }} actions: - skill: feishu_bot params: {template: medium_risk_note.j2} - default: - skill: log_info params: {message: No risk detected}关键在于condition字段支持完整的 Jinja2 表达式且可访问整个上下文trigger,input,output。这使得 WorkBuddy 能模拟人类工程师的决策树高风险立即干预中风险仅提醒无风险则静默。相比硬编码的 if-elseswitch的优势在于条件逻辑与执行动作分离便于审计新增风险等级只需加一条condition无需改代码所有分支共用同一输入避免数据重复传递。我们在迁移一个旧 Python 脚本到 WorkBuddy 时原脚本有 17 个嵌套 if-elif-else重构为switch后配置文件仅 42 行且新增一种风险类型只需 5 行。3.3 MCP 协议集成WorkBuddy 的“万能接口”原理MCPModel Control Protocol是 WorkBuddy 跨行业能力的基石。它定义了一套 JSON-RPC 风格的通信协议核心是三个概念Service提供能力的实体如 Midas Gen Server、UE5.8 Editor、Altium MCP PluginMethodService 暴露的具体功能如run_analysis_batch,import_texture,highlight_areaCapabilityService 声明自己支持哪些 Method 的清单。WorkBuddy 作为 MCP Client启动时会向所有已知 Service 发送capabilities请求动态构建本地能力地图。因此当你在 YAML 中写skill: mcp_callWorkBuddy 并非调用固定函数而是查找service: midas-gen-server是否在能力地图中验证其capabilities是否包含run_analysis_batch构造标准 JSON-RPC 请求发送至 Service 的 WebSocket 端口解析响应提取result字段供后续 Skill 使用。这种设计带来两大优势零耦合WorkBuddy 不需要知道 Midas Gen 的内部 API只要它实现了 MCP 协议就能调用热插拔新增一个 MCP Service如刚发布的unreal 5.8 mcp插件WorkBuddy 重启后自动识别无需修改配置。我们实测过在同一台机器上同时运行 Midas Gen Server、UE5.8 Editor、Altium MCP PluginWorkBuddy 的wb status命令会清晰列出三者状态及支持的 Method证明其协议层抽象的成熟度。3.4 缓存与状态管理WorkBuddy 如何保证“重跑不翻车”所有自动化工具都怕“重跑”——第二次执行时文件已存在、API 已调用、状态已改变。WorkBuddy 的解决方案是内置的Stateful Execution Engine。每个 Skill 执行前引擎会计算本次执行的唯一execution_hash基于 trigger 输入、Skill 配置、参数哈希查询本地 SQLite 数据库检查该 hash 是否存在成功记录若存在直接返回缓存的output跳过实际执行若不存在执行 Skill并将output连同 hash 存入数据库。这意味着wb run --config xrd_analysis.yaml第二次执行若输入文件和参数未变1 秒内返回结果即使网络中断导致feishu_bot失败重试时只重发卡片不重复跑 Python 脚本lark_download的增量同步本质也是 State Engine 在比对etag哈希。我们曾故意断网运行sales_daily_report.yaml发现fetch_bi_data失败后generate_insights和send_feishu_card被跳过但wb status显示fetch_bi_data: failed提示我们修复网络后重试即可而非全链路重跑——这种细粒度的状态追踪是手工脚本永远做不到的。4. 从零搭建你的第一个 WorkBuddy 工作流手把手实操指南4.1 环境准备避开那些“Python 安装教程”里没说的坑WorkBuddy 官方推荐 Python 3.8但实际部署中我们发现三个关键陷阱Windows 下的 PATH 问题WorkBuddy 的wbCLI 依赖python.exe在系统 PATH 中。很多用户按“Python 官网下载”安装默认勾选“Add Python to PATH”但若之前装过其他 Python如 AnacondaPATH 可能指向错误版本。验证方法命令行输入where python确保输出是C:\Users\XXX\AppData\Local\Programs\Python\Python38\python.exe或你安装的路径而非C:\Anaconda3\python.exe。pip 版本冲突WorkBuddy 的requirements.txt需 pip ≥ 21.0。老旧系统自带 pip 通常为 19.x执行python -m pip install --upgrade pip后务必关闭并重启命令行窗口否则新 pip 不生效。Visual C 运行库缺失wb init时若报错ImportError: DLL load failed大概率是缺Microsoft Visual C 2015-2022 Redistributable。直接去微软官网下载安装最新版别信第三方“一键修复”工具。安装命令# 推荐使用 pipx 隔离安装避免污染全局环境 python -m pip install --user pipx pipx install workbuddy # 验证 wb --version # 应输出 v2.4.1 或更高注意pipx是最佳实践但很多新手会跳过。我们见过太多因pip install workbuddy导致的依赖冲突最终重装系统。用pipx卸载只需pipx uninstall workbuddy干净利落。4.2 创建首个项目以“飞书机器人发送表格”为切入点搜索热词中有飞书机器人发送表格这是最易上手的入门场景。假设你要每天 10:00 向飞书群发送一份销售数据表CSV 格式。步骤 1创建项目目录mkdir wb-sales-report cd wb-sales-report wb init # 生成 .workbuddy/config.yaml 和 templates/步骤 2配置飞书机器人登录飞书开放平台 → 创建自建应用 → 获取App ID和App Secret在应用设置中开启“机器人”能力复制Webhook URL将App ID、App Secret、Webhook URL写入.workbuddy/secrets.yaml此文件自动 gitignoreFEISHU_APP_ID: cli_abc123... FEISHU_APP_SECRET: xxx FEISHU_WEBHOOK: https://www.feishu.cn/...步骤 3编写工作流 YAML创建sales_table.yamlname: daily_sales_table triggers: - type: cron schedule: 0 10 * * * # 每天 10:00 actions: - name: fetch_csv skill: http_request params: url: https://your-bi-system.com/api/sales.csv headers: {Authorization: Bearer {{ secrets.BI_TOKEN }}} - name: send_to_feishu skill: feishu_webhook params: webhook_url: {{ secrets.FEISHU_WEBHOOK }} message_type: interactive card: | { config: {wide_screen_mode: true}, elements: [ { tag: div, text: {content: 今日销售数据{{ now|date(%Y-%m-%d) }}, tag: lark_md} }, { tag: table, column_widths: [100, 100, 100], header: [{text: {content: 区域, tag: plain_text}}, {text: {content: 销售额, tag: plain_text}}, {text: {content: 完成率, tag: plain_text}}], rows: [ {% for row in output.csv_rows %} [{text: {content: {{ row[0] }}, tag: plain_text}}, {text: {content: {{ row[1] }}, tag: plain_text}}, {text: {content: {{ row[2] }}%, tag: plain_text}}], {% endfor %} ] } ] } # 注意card 是 JSON 字符串内嵌 Jinja2 循环步骤 4准备 CSV 解析脚本./scripts/parse_csv.pyimport csv import sys # 读取 stdin即上一步 http_request 的响应体 reader csv.reader(sys.stdin) rows list(reader) # 输出为 JSON 数组供 Jinja2 使用 import json print(json.dumps(rows))步骤 5关联 Skill在sales_table.yaml的fetch_csv后添加- name: parse_csv skill: python_script params: script: ./scripts/parse_csv.py步骤 6运行与调试wb run --config sales_table.yaml --dry-run # 先试运行不发消息 wb run --config sales_table.yaml # 实际运行实操心得--dry-run是救命功能。我们第一次运行时card中的 Jinja2 语法有误--dry-run直接报错TemplateSyntaxError避免了向全员群发乱码卡片。记住任何涉及飞书/钉钉等通讯工具的 Skill务必先--dry-run。4.3 调试与日志读懂 WorkBuddy 的“黑话”WorkBuddy 的日志是调试核心。默认日志级别为INFO但关键信息藏在DEBUG中wb run --config sales_table.yaml --log-level DEBUG你会看到类似输出DEBUG: Trigger cron matched: next execution at 2024-06-15 10:00:00 DEBUG: Action fetch_csv: executing http_request with urlhttps://... DEBUG: Action fetch_csv: response status200, body_length12456 bytes DEBUG: Action parse_csv: executing python_script with script./scripts/parse_csv.py DEBUG: Action parse_csv: stdout[[华东,120000,105],[华南,98000,92]] DEBUG: Action send_to_feishu: rendering card template... INFO: Action send_to_feishu: sent to https://www.feishu.cn/... (status200)关键字段解读response status200HTTP 请求成功body_length12456 bytes确认 CSV 数据已完整接收stdout[[华东,...]]验证 Python 脚本输出格式正确rendering card template...说明 Jinja2 模板开始解析sent to ... (status200)飞书 API 调用成功。若某步卡住看前一步的body_length或stdout是否为空。空值意味着上游 Skill 未输出需检查其逻辑。4.4 进阶用workbuddy switch实现“智能日报分级”回到sales_table.yaml我们可以加入switch让日报根据销售额自动分级- name: analyze_performance skill: python_script params: script: ./scripts/analyze_sales.py # 读取 parse_csv 的输出计算总销售额、达标率等 - name: route_by_performance switch: - condition: {{ output.total_sales 1000000 }} actions: - skill: feishu_webhook params: {webhook_url: ..., card: {{ templates.excellent_card }}} - condition: {{ output.total_sales 500000 }} actions: - skill: feishu_webhook params: {webhook_url: ..., card: {{ templates.good_card }}} - default: - skill: feishu_webhook params: {webhook_url: ..., card: {{ templates.warning_card }}}analyze_sales.py只需输出 JSONimport json import sys # 读取 stdin 的 CSV 行 data json.load(sys.stdin) total