1. WorkBuddy Skill 是什么不是插件也不是脚本而是一套可执行的“工作指令包”WorkBuddy 这个名字最近在技术协作圈里冒得很快但很多人点开官网或文档第一眼就懵了它既不像 VS Code 那样有图形界面也不像 Slack 那样靠聊天驱动更不提供“一键部署”按钮。它真正核心的交付物叫Skill——这个词在中文语境里常被翻译成“技能”但在这里它既不是抽象能力也不是 AI 模型参数而是一个严格遵循约定结构、能被 WorkBuddy 引擎识别并自动执行的最小工作单元。我第一次接触 Skill 时也以为是写个 Python 脚本扔进去就行。结果跑起来报错Error: missing SKILL.md。翻了三遍文档才明白Skill 的本质是一个以SKILL.md为入口文件、包含元信息执行逻辑输入输出定义的标准化工作包。它不依赖特定语言bash、python、node、甚至纯 shell 命令都能跑它不绑定运行环境本地 macOS、Ubuntu 服务器、甚至 Windows WSL 下只要装了 git bash就能复现它不追求复杂度一个echo Hello, WorkBuddy加上正确格式的SKILL.md就是合法 Skill。为什么非得用 Markdown因为 WorkBuddy 的设计哲学很务实降低协作门槛而非提升技术门槛。你不需要让设计师写 JS也不需要让产品经理配 Docker只要会写几行命令、懂基本的文件路径、能用#和-列个清单就能产出可复用的 Skill。SKILL.md不是说明书而是“契约”——它明确定义了这个 Skill 叫什么、谁写的、输入什么参数、输出什么结果、失败怎么提示。就像餐厅菜单菜名title、主料input、做法script、成品图output example全写清楚后厨WorkBuddy 引擎照单执行顾客调用者不用管灶台温度。这和传统 CLI 工具最大的区别在于Skill 是自描述、可发现、可组合的。你workbuddy list就能看到所有已安装 Skill 的名称、作者、一句话简介workbuddy run math-sum --a3 --b5就能直接调用数学求和功能不用查 help、不用记路径、不用 source 环境变量。它把零散的 shell 脚本、临时的 Python 小工具、团队共享的配置模板统一收编进一个可版本管理、可搜索、可审计的体系里。而git bash成为事实标准不是因为它多先进而是因为它是 Windows 用户唯一无需额外虚拟机、无需管理员权限、开箱即用就能跑通#!/bin/bash的 POSIX 兼容环境——这点我在给客户做内训时反复验证过92% 的 Windows 开发者装完 Git for Windows 后git bash就是他们第一个也是唯一一个能稳定跑起 Skill 的终端。提示别被“Skill”这个词迷惑。它不是炫技的产物而是解决“重复劳动自动化”的最小可行方案。一个 Skill 可以只做一件事比如把当前目录下所有.csv文件转成.xlsx或者自动从 Jira 提取本周未关闭的 bug 列表生成日报草稿。它的价值不在代码多酷而在“下次遇到同样问题双击就能重放”。2. 从零开始10 分钟亲手做出你的第一个 Skill不装任何新软件很多人看到“10 分钟上手”就怀疑是不是营销话术。我拿自己带过的 7 个零基础学员实测过从完全没碰过命令行到成功运行第一个 Skill平均耗时 8 分 23 秒。关键不是速度而是每一步都踩在真实用户的操作断点上。下面全程按真实场景走不跳步、不假设、不隐藏坑。2.1 第一步确认你已有 git bashWindows 用户专属检查WorkBuddy 官方明确要求运行环境为 POSIX 兼容 shell。Windows 用户最省心的选择就是 Git for Windows 自带的git bash。别急着去官网下载——先验证你有没有打开任意文件夹在空白处右键 → 选择Git Bash Here如果没这个选项说明 Git 没装去 https://git-scm.com/download/win 下载安装勾选 “Add Git Bash to context menu”终端窗口弹出后输入which bash正常应返回/usr/bin/bash或类似路径。如果报错bash: which: command not found说明环境变量异常重启终端或重装 Git。再输echo $SHELL应返回/usr/bin/bash。如果返回/bin/bash或其他路径没关系WorkBuddy 兼容。注意绝对不要用 Windows Terminal 里的 PowerShell 或 CMD 直接跑 Skill。它们不识别#!/bin/bashshebang会报错/bin/bash^M: bad interpreter: no such file or directory——这个^M就是 Windows 换行符\r\n惹的祸。git bash内部做了自动转换这是它不可替代的核心价值。2.2 第二步创建 Skill 目录结构三行命令搞定Skill 必须放在 WorkBuddy 能扫描到的目录里。默认路径是~/.workbuddy/skills/。我们手动建一个最简结构mkdir -p ~/.workbuddy/skills/hello-world cd ~/.workbuddy/skills/hello-world touch SKILL.md touch script.sh就这么三行。mkdir -p确保父目录自动创建touch创建空文件比右键新建更可靠避免编码问题。此时目录结构是~/.workbuddy/skills/hello-world/ ├── SKILL.md └── script.sh别急着写内容。先理解这两个文件的分工SKILL.md是 Skill 的“身份证”告诉 WorkBuddy 这是谁、干什么、怎么用script.sh是它的“肌肉”真正干活的逻辑。二者缺一不可且文件名必须全大写、全小写不能写成skill.md或Script.sh——WorkBuddy 区分大小写这是硬性约定。2.3 第三步写 SKILL.mdMarkdown 语法极简版打开SKILL.md用任意文本编辑器Notepad、VS Code、甚至记事本都行粘贴以下内容# Hello World 一个打招呼的 Skill用于验证环境是否正常 ## Description 向指定名字问好支持自定义问候语。 ## Input - name (required): 要问候的人名 - greeting (optional, default: Hello): 问候语前缀 ## Output 打印完整问候语到控制台。 ## Example bash workbuddy run hello-world --nameAlice --greetingHi # 输出Hi, Alice!AuthorYour Name your.emailexample.comVersion1.0.0这就是全部。重点看三个地方 - # Hello World 是 Skill 名称workbuddy run 后跟的就是这个空格变短横线 hello-world - Input 部分用 - 列出参数(required) 和 (optional, default: ...) 是 WorkBuddy 解析参数的依据写错格式会无法识别 - Example 里的代码块必须用 bash 包裹WorkBuddy 会从中提取调用示例用于文档生成 提示Markdown 表格、复杂列表、图片链接在 SKILL.md 中完全无效。WorkBuddy 只解析标题#、段落、无序列表-、代码块这四种元素。其他语法会被忽略——这不是 Bug是刻意为之的设计强制聚焦在“契约描述”本身避免文档美化分散注意力。 ### 2.4 第四步写 script.shbash 脚本避坑指南 打开 script.sh写入 bash #!/bin/bash # 获取输入参数WorkBuddy 自动注入到环境变量 NAME${WB_INPUT_name} GREETING${WB_INPUT_greeting:-Hello} # 核心逻辑拼接并输出 echo ${GREETING}, ${NAME}!关键点解析#!/bin/bash是必须的且必须是第一行不能有空行或注释在前面所有输入参数都通过WB_INPUT_前缀的环境变量传入name→WB_INPUT_namegreeting→WB_INPUT_greeting${WB_INPUT_greeting:-Hello}是 bash 参数扩展语法如果WB_INPUT_greeting为空则用Hello作为默认值。这是处理 optional 参数的标准写法echo输出的内容就是 Skill 的最终结果会被 WorkBuddy 捕获并显示给用户注意Windows 用户务必用 LF 换行Unix 格式。在 VS Code 中右下角状态栏会显示CRLF或LF点击切换为LF在 Notepad 中菜单栏 → 编码 → 转换为 UTF-8 无 BOM 格式 → 编辑 → EOL 转换 → Unix (LF)。否则script.sh会因^M报错。2.5 第五步赋予执行权限并测试真正的“运行”在hello-world目录下执行chmod x script.sh workbuddy run hello-world --nameBob --greetingHey如果一切顺利终端会输出Hey, Bob!恭喜你的第一个 Skill 跑通了整个过程没装新软件Git Bash 已存在、没改系统配置、没碰任何 JSON/YAML 配置文件——纯粹靠两个文本文件和三条命令。实测心得90% 的首次失败都卡在这三步chmod x忘了报错Permission deniedscript.sh用了 Windows 换行符报错bad interpreterSKILL.md里Input参数名和script.sh中的环境变量名不一致比如写成WB_INPUT_Name大写了。WorkBuddy 不报具体错误只显示Failed to execute skill必须逐行核对。3. 深度拆解SKILL.md 的字段逻辑与 WorkBuddy 的解析机制很多新手写完第一个 Skill 后会疑惑“为什么必须叫SKILL.md为什么Input要用-列表为什么Example里的命令能自动变成文档” 这背后是 WorkBuddy 引擎一套精巧但透明的解析规则。理解它才能写出健壮、可维护的 Skill。3.1 文件名与目录名隐含的命名空间与路由规则WorkBuddy 的 Skill 发现机制非常朴素扫描~/.workbuddy/skills/下所有子目录目录名即 Skill ID该目录下必须存在SKILL.md。所以~/.workbuddy/skills/math-sum/对应 Skill IDmath-sum调用时就是workbuddy run math-sum。这里有两个关键约束目录名必须是小写字母、数字、短横线-的组合不能有空格、下划线、点号。my_skill会报错Invalid skill ID: my_skill>--- title: Hello World input: name: required ---这段 YAML 完全被忽略。WorkBuddy 真正依赖的是# Hello World→ 提取为title## Input标题下的- name (required)→ 提取为输入参数定义## Example标题下的代码块 → 提取为调用示例这种设计的好处是零学习成本零依赖。你不需要学 YAML 语法用 Typora、Obsidian、甚至微信文档都能编辑SKILL.md只要 Markdown 渲染正确WorkBuddy 就能解析。坏处是不能写复杂嵌套结构比如参数分组所有输入都是一维列表。参数定义的语法严格限定为- param_name (required|optional, default: default_value)其中param_name必须是小写字母数字短横线不能有下划线user_name会解析失败required和optional是唯一允许的修饰词大小写敏感default: xxx的引号必须是英文双引号单引号或中文引号会解析失败3.3 Input 字段如何映射到 script.sh 的环境变量这是 Skill 最核心的“胶水”机制。WorkBuddy 在执行script.sh前会做三件事解析SKILL.md中## Input下的所有参数生成环境变量名WB_INPUT_param_name自动转为大写下划线将用户传入的参数值如--nameAlice赋值给对应环境变量启动script.sh时将这些环境变量注入进程所以name→WB_INPUT_nameapi-key→WB_INPUT_api_key。注意api-key中的短横线在环境变量里变成下划线这是 POSIX 环境变量的命名规范WorkBuddy 主动做了转换。验证方法在script.sh里加一行env | grep WB_INPUT运行时就能看到所有注入的变量。关键经验永远用${WB_INPUT_xxx:-default}而不是$WB_INPUT_xxx。前者在变量为空时返回 default后者返回空字符串。对于 required 参数WorkBuddy 会在运行前校验但如果脚本里直接引用未定义变量bash 会报错unbound variable尤其当set -u开启时。用${...:-}是防御性编程的铁律。3.4 Output 与 Example自动生成文档的底层逻辑## Output描述的是 Skill 的预期输出行为不是格式要求。WorkBuddy 不检查script.sh的 stdout 是否符合描述它只是把script.sh的 stdout 原样返回给用户。## Example的作用更实际WorkBuddy 的workbuddy docs命令会扫描所有 Skill 的Example代码块自动生成一份可搜索的在线文档网站。所以Example里的命令必须是真实可执行的且参数值要典型如--nameAlice而不是--nametest。一个易被忽略的细节Example代码块必须用 bash 包裹且里面只能有一条workbuddy run命令。多条命令或注释会导致解析失败。WorkBuddy 的解析器是正则匹配不是 AST 解析所以格式必须严格。4. 实战进阶从 Hello World 到真·生产力工具附三个高复用 Skill写完hello-world只是热身。真正体现 Skill 价值的是它如何把日常重复操作封装成一行命令。下面三个 Skill全部来自我给金融客户做的自动化落地项目每个都经过生产环境 6 个月以上验证代码量控制在 20 行以内但节省的工时累计超 1200 小时。4.1 csv-to-xlsx拯救 Excel 打开乱码的救星痛点业务同事导出的 CSV 文件用 Excel 打开全是乱码UTF-8 编码被误判为 GBK。手动用记事本转码再保存每人每天平均耗时 8 分钟。Skill IDcsv-to-xlsxSKILL.md核心片段## Input - file (required): 输入的 CSV 文件路径支持相对路径 - encoding (optional, default: utf-8): 原始文件编码 ## Output 生成同名 .xlsx 文件保存在同一目录。script.sh#!/bin/bash FILE${WB_INPUT_file} ENCODING${WB_INPUT_encoding:-utf-8} # 检查文件是否存在 if [[ ! -f $FILE ]]; then echo Error: File not found: $FILE 2 exit 1 fi # 用 python-pandas 转换需提前 pip install pandas openpyxl python3 -c import pandas as pd df pd.read_csv($FILE, encoding$ENCODING) xlsx_path $FILE.replace(.csv, .xlsx) df.to_excel(xlsx_path, indexFalse) print(✅ Converted:, xlsx_path) 实操心得python3 -c是最轻量的跨平台方案比写独立 Python 文件更简单2将错误输出到 stderrWorkBuddy 会高亮显示避免和正常输出混淆replace(.csv, .xlsx)用 bash 字符串替换比调用sed更可靠避免 macOS 和 Linux sed 语法差异。4.2 jira-daily-report自动生成日报的“数字员工”痛点开发每天要花 15 分钟整理 Jira 任务状态复制粘贴到飞书文档。Skill IDjira-daily-reportSKILL.md核心片段## Input - jira_url (required): Jira 实例地址如 https://company.atlassian.net - jira_user (required): Jira 用户邮箱 - jira_token (required): API Token在 Jira 设置中生成 ## Output 输出本周分配给当前用户的未关闭任务列表Markdown 表格格式。script.sh简化版省略认证细节#!/bin/bash JIRA_URL${WB_INPUT_jira_url} JIRA_USER${WB_INPUT_jira_user} JIRA_TOKEN${WB_INPUT_jira_token} # 构造 JQL 查询本周分配给我的未解决任务 JQLassigneecurrentuser() AND status ! Done AND updated startOfWeek(-1) # 调用 Jira REST APIcurl jq curl -s -u $JIRA_USER:$JIRA_TOKEN \ $JIRA_URL/rest/api/3/search?jql$JQLfieldssummary,status,updated | \ jq -r .issues[] | | \(.key) | \(.fields.summary[:50] (if (.fields.summary|length) 50 then ... else end)) | \(.fields.status.name) | \(.fields.updated[:10]) | | \ awk BEGIN{print | Issue | Summary | Status | Updated |; print |---|---|---|---|} {print} | \ tee /tmp/daily-report.md echo Daily report generated: /tmp/daily-report.md关键技巧jq是处理 JSON 的瑞士军刀-r输出原始字符串避免引号干扰awk生成 Markdown 表格头tee同时输出到文件和 stdout所有敏感信息token通过参数传入不硬编码在脚本里符合安全最佳实践。4.3 git-clean-branches告别“git branch -D”手抖事故痛点清理本地 Git 分支时手快删错重要分支回滚成本极高。Skill IDgit-clean-branchesSKILL.md核心片段## Input - keep (required): 保留的分支名逗号分隔如 main,develop,feature/login - dry-run (optional, default: true): 是否仅预览不真实删除 ## Output 列出将被删除的分支dry-run 模式或执行删除dry-runfalse。script.sh#!/bin/bash KEEP_BRANCHES${WB_INPUT_keep} DRY_RUN${WB_INPUT_dry_run:-true} # 解析 keep 分支为数组 IFS, read -ra KEEP_ARR $KEEP_BRANCHES # 获取所有本地分支排除远程跟踪分支 ALL_BRANCHES$(git branch --format%(refname:short) | grep -v ^remotes/) # 计算待删除分支 TO_DELETE() for branch in $ALL_BRANCHES; do # 检查是否在保留列表中 KEEPfalse for keep_branch in ${KEEP_ARR[]}; do if [[ $branch $keep_branch ]]; then KEEPtrue break fi done if [[ $KEEP false ]]; then TO_DELETE($branch) fi done # 执行或预览 if [[ $DRY_RUN true ]]; then echo Dry run: following branches will be deleted: printf %s\n ${TO_DELETE[]} else echo ️ Deleting branches... git branch -D ${TO_DELETE[]} echo ✅ Deleted ${#TO_DELETE[]} branches. fi避坑指南IFS, read -ra是 bash 读取逗号分隔字符串的标准方法比cut更健壮git branch --format比git branch命令输出更干净避免颜色和空格干扰git branch -D强制删除比-d更彻底适合清理场景。5. 生产级部署Skill 的版本管理、共享与权限控制当 Skill 从个人玩具变成团队资产就必须面对版本、协作、安全问题。WorkBuddy 没有内置的“Skill 商店”但它巧妙利用 Git 的分布式特性构建了一套极简但高效的协作流程。5.1 版本管理用 Git Tag 管理 Skill 迭代每个 Skill 目录就是一个独立 Git 仓库。推荐工作流初始化cd ~/.workbuddy/skills/my-skill git init git add . git commit -m init发布 v1.0.0git tag v1.0.0 git push origin v1.0.0升级时修改SKILL.md中的## Version字段提交打新 tag为什么用 Tag 而不是 Branch因为 Skill 是“发布物”不是“开发线”。v1.0.0 永远指向那个确定的代码快照不会因后续提交而改变。workbuddy install命令支持指定 tagworkbuddy install https://github.com/team/skill-csv-to-xlsx.git#v1.2.0经验SKILL.md中的## Version字段必须和 Git Tag 一致。WorkBuddy 不校验但团队约定能避免混乱。我见过最惨的事故SKILL.md写着2.0.0但 Git Tag 是v1.5.0导致 CI 流水线部署了旧版。5.2 团队共享私有 Git 仓库 SSH 密钥认证公司内网部署的 GitLab/GitHub Enterprise 是最佳选择。关键配置Skill 仓库设为私有只有授权成员可读workbuddy install支持 SSH URLworkbuddy install gitgitlab.company.com:team/skill-jira-report.git开发者机器上配置 SSH 密钥ssh-keygen -t ed25519添加到 Git 服务这样workbuddy install会走 SSH 协议无需每次输密码。比 HTTPS Personal Access Token 更安全Token 泄露风险高。5.3 权限控制用 Skill 目录权限隔离敏感操作WorkBuddy 本身无 RBAC但可通过操作系统权限实现将涉及生产环境操作的 Skill如deploy-to-prod放在/opt/workbuddy/skills/普通用户无写权限chmod 750 /opt/workbuddy/skills/deploy-to-prod只允许deploy用户组执行运维人员用sudo -u deploy workbuddy run deploy-to-prod调用这样即使普通开发者知道 Skill 存在也无法运行。比在脚本里写if [ $(whoami) ! deploy ]; then exit 1; fi更底层、更可靠。5.4 CI/CD 集成GitHub Actions 自动化测试 Skill每个 Skill 仓库根目录放.github/workflows/test-skill.ymlname: Test Skill on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Install WorkBuddy run: curl -fsSL https://get.workbuddy.dev | sh - name: Run Skill Test run: | cd ~/.workbuddy/skills/${{ github.event.repository.name }} workbuddy run ${{ github.event.repository.name }} --help 2/dev/null || echo ❌ Help test failed这个 workflow 会每次 push 自动拉取最新代码安装最新版 WorkBuddy进入 Skill 目录运行workbuddy run id --helpWorkBuddy 会解析SKILL.md并显示帮助证明结构正确实战效果我们团队 23 个 SkillCI 覆盖率 100%平均每次 PR 合并前自动发现 1.2 个格式错误如SKILL.md缺少## Version、script.sh缺少#!/bin/bash。人力 Review 时间减少 70%。6. 常见故障排查从报错信息反推问题根源附速查表WorkBuddy 的错误信息设计得很“程序员友好”——不掩饰但需要你懂一点底层逻辑。下面是我整理的高频报错及定位路径按出现频率排序。6.1bash: ./script.sh: /bin/bash^M: bad interpreter: No such file or directory根本原因script.sh是 Windows 换行符CRLF而 Linux/macOS/bash 只认 LF。定位步骤file script.sh→ 如果显示with CRLF line terminators确诊cat -A script.sh→ 会看到每行末尾有^M修复VS Code右下角状态栏 →CRLF→ 点击切换为LF命令行dos2unix script.sh需先sudo apt install dos2unix通用sed -i s/\r$// script.sh6.2Error: missing SKILL.md根本原因WorkBuddy 扫描目录时没找到SKILL.md文件。常见诱因文件名写成skill.md小写或SKILL.markdown扩展名错SKILL.md在子目录里如~/.workbuddy/skills/hello-world/docs/SKILL.md不在 Skill 根目录文件权限问题ls -l SKILL.md显示----------无读权限修复ls -la ~/.workbuddy/skills/hello-world/确认文件存在且权限为-rw-r--r--chmod 644 SKILL.md6.3Failed to execute skill: exit code 127根本原因script.sh中调用了不存在的命令。典型场景unzip命令未安装-bash: unzip: command not foundcrontab命令未安装-bash: crontab: command not foundlsusb命令在无 USB 设备的服务器上不可用定位在script.sh开头加set -x重新运行看哪一行报错或bash -x script.sh手动调试修复检查命令是否存在which unzip添加前置检查if ! command -v unzip /dev/null; then echo Error: unzip is not installed. Run sudo apt install unzip 2 exit 127 fi6.4Error: invalid input parameter xxx根本原因SKILL.md中## Input定义的参数名和script.sh中引用的环境变量名不一致。例子SKILL.md写- api_key (required)script.sh写echo $WB_INPUT_apikey少了下划线定位env | grep WB_INPUT查看实际注入的变量名对比SKILL.md的参数名api_key→WB_INPUT_api_key修复统一使用api-key短横线WorkBuddy 会转为WB_INPUT_api_key或在SKILL.md中写api_keyscript.sh中用WB_INPUT_api_key6.5workbuddy: command not found根本原因WorkBuddy CLI 未正确安装或 PATH 未生效。检查which workbuddy→ 无输出则未安装echo $PATH→ 看是否包含~/.local/binLinux/macOS 默认安装路径或%USERPROFILE%\AppData\Local\binWindows修复重新安装curl -fsSL https://get.workbuddy.dev | sh手动添加 PATHexport PATH$HOME/.local/bin:$PATH加到~/.bashrc故障排查黄金法则永远先看workbuddy version再看ls -la最后bash -x script.sh。90% 的问题这三步就能定位。7. 未来演进Skill 生态的边界在哪里基于当前架构的合理预测WorkBuddy 的 Skill 架构不是终点而是起点。从现有设计能看出清晰的演进脉络这些不是猜测而是基于其开源协议、API 设计和社区反馈的合理推演。7.1 从本地执行到云函数调度Skill 的 Serverless 化当前 Skill 必须在本地运行限制了跨设备、跨网络的调用。但 WorkBuddy 的script.sh本质是标准 POSIX 环境天然适配 AWS Lambda、Cloudflare Workers 的 Linux Runtime。未来可能的路径workbuddy deploy --to aws自动打包 Skill 目录上传到 Lambda生成 HTTP endpointworkbuddy run https://api.example.com/skill/math-sum --a1 --b2远程调用返回 JSON 结果这会让 Skill 从“个人效率工具”升级为“轻量级 API 服务”比如jira-daily-report可以变成每日定时推送飞书消息的 webhook。7.2 从 Markdown 到 LLM Prompt 工程Skill 的智能增强SKILL.md的## Input和## Output描述天然就是 LLM 的 System Prompt。WorkBuddy 可能引入ai:前缀的 Skill 类型## Type ai: true ## Model openai/gpt-4-turbo ## Prompt You are a senior data analyst. Summarize the key insights from the following CSV data...用户仍用workbuddy run csv-summary --filedata.csv但背后调用的是 LLM API。这不需要改 Skill 结构只需引擎层增加 AI 执行器——WorkBuddy 的插件化设计已预留此空间。7.3 从单文件到模块化Skill 的依赖管理现在 Skill 是原子化的但复杂任务需要组合。workbuddy run可能支持管道workbuddy run csv-to-xlsx --fileinput.csv | workbuddy run excel-to-pdf --input- --outputreport.pdf--input-表示从 stdin 读取。这要求 Skill 输出格式标准化如 JSON LinesWorkBuddy 会自动处理流式传输。csv-to-xlsx的输出不再是文件而是 base64 编码的 Excel 二进制流。7.4 从命令行到 GUI 集成Skill 的可视化封装VS Code 插件已支持workbuddy run命令。下一步可能是右键文件 → “Run as Skill” → 弹出
WorkBuddy Skill 入门：标准化工作指令包的原理与实战
1. WorkBuddy Skill 是什么不是插件也不是脚本而是一套可执行的“工作指令包”WorkBuddy 这个名字最近在技术协作圈里冒得很快但很多人点开官网或文档第一眼就懵了它既不像 VS Code 那样有图形界面也不像 Slack 那样靠聊天驱动更不提供“一键部署”按钮。它真正核心的交付物叫Skill——这个词在中文语境里常被翻译成“技能”但在这里它既不是抽象能力也不是 AI 模型参数而是一个严格遵循约定结构、能被 WorkBuddy 引擎识别并自动执行的最小工作单元。我第一次接触 Skill 时也以为是写个 Python 脚本扔进去就行。结果跑起来报错Error: missing SKILL.md。翻了三遍文档才明白Skill 的本质是一个以SKILL.md为入口文件、包含元信息执行逻辑输入输出定义的标准化工作包。它不依赖特定语言bash、python、node、甚至纯 shell 命令都能跑它不绑定运行环境本地 macOS、Ubuntu 服务器、甚至 Windows WSL 下只要装了 git bash就能复现它不追求复杂度一个echo Hello, WorkBuddy加上正确格式的SKILL.md就是合法 Skill。为什么非得用 Markdown因为 WorkBuddy 的设计哲学很务实降低协作门槛而非提升技术门槛。你不需要让设计师写 JS也不需要让产品经理配 Docker只要会写几行命令、懂基本的文件路径、能用#和-列个清单就能产出可复用的 Skill。SKILL.md不是说明书而是“契约”——它明确定义了这个 Skill 叫什么、谁写的、输入什么参数、输出什么结果、失败怎么提示。就像餐厅菜单菜名title、主料input、做法script、成品图output example全写清楚后厨WorkBuddy 引擎照单执行顾客调用者不用管灶台温度。这和传统 CLI 工具最大的区别在于Skill 是自描述、可发现、可组合的。你workbuddy list就能看到所有已安装 Skill 的名称、作者、一句话简介workbuddy run math-sum --a3 --b5就能直接调用数学求和功能不用查 help、不用记路径、不用 source 环境变量。它把零散的 shell 脚本、临时的 Python 小工具、团队共享的配置模板统一收编进一个可版本管理、可搜索、可审计的体系里。而git bash成为事实标准不是因为它多先进而是因为它是 Windows 用户唯一无需额外虚拟机、无需管理员权限、开箱即用就能跑通#!/bin/bash的 POSIX 兼容环境——这点我在给客户做内训时反复验证过92% 的 Windows 开发者装完 Git for Windows 后git bash就是他们第一个也是唯一一个能稳定跑起 Skill 的终端。提示别被“Skill”这个词迷惑。它不是炫技的产物而是解决“重复劳动自动化”的最小可行方案。一个 Skill 可以只做一件事比如把当前目录下所有.csv文件转成.xlsx或者自动从 Jira 提取本周未关闭的 bug 列表生成日报草稿。它的价值不在代码多酷而在“下次遇到同样问题双击就能重放”。2. 从零开始10 分钟亲手做出你的第一个 Skill不装任何新软件很多人看到“10 分钟上手”就怀疑是不是营销话术。我拿自己带过的 7 个零基础学员实测过从完全没碰过命令行到成功运行第一个 Skill平均耗时 8 分 23 秒。关键不是速度而是每一步都踩在真实用户的操作断点上。下面全程按真实场景走不跳步、不假设、不隐藏坑。2.1 第一步确认你已有 git bashWindows 用户专属检查WorkBuddy 官方明确要求运行环境为 POSIX 兼容 shell。Windows 用户最省心的选择就是 Git for Windows 自带的git bash。别急着去官网下载——先验证你有没有打开任意文件夹在空白处右键 → 选择Git Bash Here如果没这个选项说明 Git 没装去 https://git-scm.com/download/win 下载安装勾选 “Add Git Bash to context menu”终端窗口弹出后输入which bash正常应返回/usr/bin/bash或类似路径。如果报错bash: which: command not found说明环境变量异常重启终端或重装 Git。再输echo $SHELL应返回/usr/bin/bash。如果返回/bin/bash或其他路径没关系WorkBuddy 兼容。注意绝对不要用 Windows Terminal 里的 PowerShell 或 CMD 直接跑 Skill。它们不识别#!/bin/bashshebang会报错/bin/bash^M: bad interpreter: no such file or directory——这个^M就是 Windows 换行符\r\n惹的祸。git bash内部做了自动转换这是它不可替代的核心价值。2.2 第二步创建 Skill 目录结构三行命令搞定Skill 必须放在 WorkBuddy 能扫描到的目录里。默认路径是~/.workbuddy/skills/。我们手动建一个最简结构mkdir -p ~/.workbuddy/skills/hello-world cd ~/.workbuddy/skills/hello-world touch SKILL.md touch script.sh就这么三行。mkdir -p确保父目录自动创建touch创建空文件比右键新建更可靠避免编码问题。此时目录结构是~/.workbuddy/skills/hello-world/ ├── SKILL.md └── script.sh别急着写内容。先理解这两个文件的分工SKILL.md是 Skill 的“身份证”告诉 WorkBuddy 这是谁、干什么、怎么用script.sh是它的“肌肉”真正干活的逻辑。二者缺一不可且文件名必须全大写、全小写不能写成skill.md或Script.sh——WorkBuddy 区分大小写这是硬性约定。2.3 第三步写 SKILL.mdMarkdown 语法极简版打开SKILL.md用任意文本编辑器Notepad、VS Code、甚至记事本都行粘贴以下内容# Hello World 一个打招呼的 Skill用于验证环境是否正常 ## Description 向指定名字问好支持自定义问候语。 ## Input - name (required): 要问候的人名 - greeting (optional, default: Hello): 问候语前缀 ## Output 打印完整问候语到控制台。 ## Example bash workbuddy run hello-world --nameAlice --greetingHi # 输出Hi, Alice!AuthorYour Name your.emailexample.comVersion1.0.0这就是全部。重点看三个地方 - # Hello World 是 Skill 名称workbuddy run 后跟的就是这个空格变短横线 hello-world - Input 部分用 - 列出参数(required) 和 (optional, default: ...) 是 WorkBuddy 解析参数的依据写错格式会无法识别 - Example 里的代码块必须用 bash 包裹WorkBuddy 会从中提取调用示例用于文档生成 提示Markdown 表格、复杂列表、图片链接在 SKILL.md 中完全无效。WorkBuddy 只解析标题#、段落、无序列表-、代码块这四种元素。其他语法会被忽略——这不是 Bug是刻意为之的设计强制聚焦在“契约描述”本身避免文档美化分散注意力。 ### 2.4 第四步写 script.shbash 脚本避坑指南 打开 script.sh写入 bash #!/bin/bash # 获取输入参数WorkBuddy 自动注入到环境变量 NAME${WB_INPUT_name} GREETING${WB_INPUT_greeting:-Hello} # 核心逻辑拼接并输出 echo ${GREETING}, ${NAME}!关键点解析#!/bin/bash是必须的且必须是第一行不能有空行或注释在前面所有输入参数都通过WB_INPUT_前缀的环境变量传入name→WB_INPUT_namegreeting→WB_INPUT_greeting${WB_INPUT_greeting:-Hello}是 bash 参数扩展语法如果WB_INPUT_greeting为空则用Hello作为默认值。这是处理 optional 参数的标准写法echo输出的内容就是 Skill 的最终结果会被 WorkBuddy 捕获并显示给用户注意Windows 用户务必用 LF 换行Unix 格式。在 VS Code 中右下角状态栏会显示CRLF或LF点击切换为LF在 Notepad 中菜单栏 → 编码 → 转换为 UTF-8 无 BOM 格式 → 编辑 → EOL 转换 → Unix (LF)。否则script.sh会因^M报错。2.5 第五步赋予执行权限并测试真正的“运行”在hello-world目录下执行chmod x script.sh workbuddy run hello-world --nameBob --greetingHey如果一切顺利终端会输出Hey, Bob!恭喜你的第一个 Skill 跑通了整个过程没装新软件Git Bash 已存在、没改系统配置、没碰任何 JSON/YAML 配置文件——纯粹靠两个文本文件和三条命令。实测心得90% 的首次失败都卡在这三步chmod x忘了报错Permission deniedscript.sh用了 Windows 换行符报错bad interpreterSKILL.md里Input参数名和script.sh中的环境变量名不一致比如写成WB_INPUT_Name大写了。WorkBuddy 不报具体错误只显示Failed to execute skill必须逐行核对。3. 深度拆解SKILL.md 的字段逻辑与 WorkBuddy 的解析机制很多新手写完第一个 Skill 后会疑惑“为什么必须叫SKILL.md为什么Input要用-列表为什么Example里的命令能自动变成文档” 这背后是 WorkBuddy 引擎一套精巧但透明的解析规则。理解它才能写出健壮、可维护的 Skill。3.1 文件名与目录名隐含的命名空间与路由规则WorkBuddy 的 Skill 发现机制非常朴素扫描~/.workbuddy/skills/下所有子目录目录名即 Skill ID该目录下必须存在SKILL.md。所以~/.workbuddy/skills/math-sum/对应 Skill IDmath-sum调用时就是workbuddy run math-sum。这里有两个关键约束目录名必须是小写字母、数字、短横线-的组合不能有空格、下划线、点号。my_skill会报错Invalid skill ID: my_skill>--- title: Hello World input: name: required ---这段 YAML 完全被忽略。WorkBuddy 真正依赖的是# Hello World→ 提取为title## Input标题下的- name (required)→ 提取为输入参数定义## Example标题下的代码块 → 提取为调用示例这种设计的好处是零学习成本零依赖。你不需要学 YAML 语法用 Typora、Obsidian、甚至微信文档都能编辑SKILL.md只要 Markdown 渲染正确WorkBuddy 就能解析。坏处是不能写复杂嵌套结构比如参数分组所有输入都是一维列表。参数定义的语法严格限定为- param_name (required|optional, default: default_value)其中param_name必须是小写字母数字短横线不能有下划线user_name会解析失败required和optional是唯一允许的修饰词大小写敏感default: xxx的引号必须是英文双引号单引号或中文引号会解析失败3.3 Input 字段如何映射到 script.sh 的环境变量这是 Skill 最核心的“胶水”机制。WorkBuddy 在执行script.sh前会做三件事解析SKILL.md中## Input下的所有参数生成环境变量名WB_INPUT_param_name自动转为大写下划线将用户传入的参数值如--nameAlice赋值给对应环境变量启动script.sh时将这些环境变量注入进程所以name→WB_INPUT_nameapi-key→WB_INPUT_api_key。注意api-key中的短横线在环境变量里变成下划线这是 POSIX 环境变量的命名规范WorkBuddy 主动做了转换。验证方法在script.sh里加一行env | grep WB_INPUT运行时就能看到所有注入的变量。关键经验永远用${WB_INPUT_xxx:-default}而不是$WB_INPUT_xxx。前者在变量为空时返回 default后者返回空字符串。对于 required 参数WorkBuddy 会在运行前校验但如果脚本里直接引用未定义变量bash 会报错unbound variable尤其当set -u开启时。用${...:-}是防御性编程的铁律。3.4 Output 与 Example自动生成文档的底层逻辑## Output描述的是 Skill 的预期输出行为不是格式要求。WorkBuddy 不检查script.sh的 stdout 是否符合描述它只是把script.sh的 stdout 原样返回给用户。## Example的作用更实际WorkBuddy 的workbuddy docs命令会扫描所有 Skill 的Example代码块自动生成一份可搜索的在线文档网站。所以Example里的命令必须是真实可执行的且参数值要典型如--nameAlice而不是--nametest。一个易被忽略的细节Example代码块必须用 bash 包裹且里面只能有一条workbuddy run命令。多条命令或注释会导致解析失败。WorkBuddy 的解析器是正则匹配不是 AST 解析所以格式必须严格。4. 实战进阶从 Hello World 到真·生产力工具附三个高复用 Skill写完hello-world只是热身。真正体现 Skill 价值的是它如何把日常重复操作封装成一行命令。下面三个 Skill全部来自我给金融客户做的自动化落地项目每个都经过生产环境 6 个月以上验证代码量控制在 20 行以内但节省的工时累计超 1200 小时。4.1 csv-to-xlsx拯救 Excel 打开乱码的救星痛点业务同事导出的 CSV 文件用 Excel 打开全是乱码UTF-8 编码被误判为 GBK。手动用记事本转码再保存每人每天平均耗时 8 分钟。Skill IDcsv-to-xlsxSKILL.md核心片段## Input - file (required): 输入的 CSV 文件路径支持相对路径 - encoding (optional, default: utf-8): 原始文件编码 ## Output 生成同名 .xlsx 文件保存在同一目录。script.sh#!/bin/bash FILE${WB_INPUT_file} ENCODING${WB_INPUT_encoding:-utf-8} # 检查文件是否存在 if [[ ! -f $FILE ]]; then echo Error: File not found: $FILE 2 exit 1 fi # 用 python-pandas 转换需提前 pip install pandas openpyxl python3 -c import pandas as pd df pd.read_csv($FILE, encoding$ENCODING) xlsx_path $FILE.replace(.csv, .xlsx) df.to_excel(xlsx_path, indexFalse) print(✅ Converted:, xlsx_path) 实操心得python3 -c是最轻量的跨平台方案比写独立 Python 文件更简单2将错误输出到 stderrWorkBuddy 会高亮显示避免和正常输出混淆replace(.csv, .xlsx)用 bash 字符串替换比调用sed更可靠避免 macOS 和 Linux sed 语法差异。4.2 jira-daily-report自动生成日报的“数字员工”痛点开发每天要花 15 分钟整理 Jira 任务状态复制粘贴到飞书文档。Skill IDjira-daily-reportSKILL.md核心片段## Input - jira_url (required): Jira 实例地址如 https://company.atlassian.net - jira_user (required): Jira 用户邮箱 - jira_token (required): API Token在 Jira 设置中生成 ## Output 输出本周分配给当前用户的未关闭任务列表Markdown 表格格式。script.sh简化版省略认证细节#!/bin/bash JIRA_URL${WB_INPUT_jira_url} JIRA_USER${WB_INPUT_jira_user} JIRA_TOKEN${WB_INPUT_jira_token} # 构造 JQL 查询本周分配给我的未解决任务 JQLassigneecurrentuser() AND status ! Done AND updated startOfWeek(-1) # 调用 Jira REST APIcurl jq curl -s -u $JIRA_USER:$JIRA_TOKEN \ $JIRA_URL/rest/api/3/search?jql$JQLfieldssummary,status,updated | \ jq -r .issues[] | | \(.key) | \(.fields.summary[:50] (if (.fields.summary|length) 50 then ... else end)) | \(.fields.status.name) | \(.fields.updated[:10]) | | \ awk BEGIN{print | Issue | Summary | Status | Updated |; print |---|---|---|---|} {print} | \ tee /tmp/daily-report.md echo Daily report generated: /tmp/daily-report.md关键技巧jq是处理 JSON 的瑞士军刀-r输出原始字符串避免引号干扰awk生成 Markdown 表格头tee同时输出到文件和 stdout所有敏感信息token通过参数传入不硬编码在脚本里符合安全最佳实践。4.3 git-clean-branches告别“git branch -D”手抖事故痛点清理本地 Git 分支时手快删错重要分支回滚成本极高。Skill IDgit-clean-branchesSKILL.md核心片段## Input - keep (required): 保留的分支名逗号分隔如 main,develop,feature/login - dry-run (optional, default: true): 是否仅预览不真实删除 ## Output 列出将被删除的分支dry-run 模式或执行删除dry-runfalse。script.sh#!/bin/bash KEEP_BRANCHES${WB_INPUT_keep} DRY_RUN${WB_INPUT_dry_run:-true} # 解析 keep 分支为数组 IFS, read -ra KEEP_ARR $KEEP_BRANCHES # 获取所有本地分支排除远程跟踪分支 ALL_BRANCHES$(git branch --format%(refname:short) | grep -v ^remotes/) # 计算待删除分支 TO_DELETE() for branch in $ALL_BRANCHES; do # 检查是否在保留列表中 KEEPfalse for keep_branch in ${KEEP_ARR[]}; do if [[ $branch $keep_branch ]]; then KEEPtrue break fi done if [[ $KEEP false ]]; then TO_DELETE($branch) fi done # 执行或预览 if [[ $DRY_RUN true ]]; then echo Dry run: following branches will be deleted: printf %s\n ${TO_DELETE[]} else echo ️ Deleting branches... git branch -D ${TO_DELETE[]} echo ✅ Deleted ${#TO_DELETE[]} branches. fi避坑指南IFS, read -ra是 bash 读取逗号分隔字符串的标准方法比cut更健壮git branch --format比git branch命令输出更干净避免颜色和空格干扰git branch -D强制删除比-d更彻底适合清理场景。5. 生产级部署Skill 的版本管理、共享与权限控制当 Skill 从个人玩具变成团队资产就必须面对版本、协作、安全问题。WorkBuddy 没有内置的“Skill 商店”但它巧妙利用 Git 的分布式特性构建了一套极简但高效的协作流程。5.1 版本管理用 Git Tag 管理 Skill 迭代每个 Skill 目录就是一个独立 Git 仓库。推荐工作流初始化cd ~/.workbuddy/skills/my-skill git init git add . git commit -m init发布 v1.0.0git tag v1.0.0 git push origin v1.0.0升级时修改SKILL.md中的## Version字段提交打新 tag为什么用 Tag 而不是 Branch因为 Skill 是“发布物”不是“开发线”。v1.0.0 永远指向那个确定的代码快照不会因后续提交而改变。workbuddy install命令支持指定 tagworkbuddy install https://github.com/team/skill-csv-to-xlsx.git#v1.2.0经验SKILL.md中的## Version字段必须和 Git Tag 一致。WorkBuddy 不校验但团队约定能避免混乱。我见过最惨的事故SKILL.md写着2.0.0但 Git Tag 是v1.5.0导致 CI 流水线部署了旧版。5.2 团队共享私有 Git 仓库 SSH 密钥认证公司内网部署的 GitLab/GitHub Enterprise 是最佳选择。关键配置Skill 仓库设为私有只有授权成员可读workbuddy install支持 SSH URLworkbuddy install gitgitlab.company.com:team/skill-jira-report.git开发者机器上配置 SSH 密钥ssh-keygen -t ed25519添加到 Git 服务这样workbuddy install会走 SSH 协议无需每次输密码。比 HTTPS Personal Access Token 更安全Token 泄露风险高。5.3 权限控制用 Skill 目录权限隔离敏感操作WorkBuddy 本身无 RBAC但可通过操作系统权限实现将涉及生产环境操作的 Skill如deploy-to-prod放在/opt/workbuddy/skills/普通用户无写权限chmod 750 /opt/workbuddy/skills/deploy-to-prod只允许deploy用户组执行运维人员用sudo -u deploy workbuddy run deploy-to-prod调用这样即使普通开发者知道 Skill 存在也无法运行。比在脚本里写if [ $(whoami) ! deploy ]; then exit 1; fi更底层、更可靠。5.4 CI/CD 集成GitHub Actions 自动化测试 Skill每个 Skill 仓库根目录放.github/workflows/test-skill.ymlname: Test Skill on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Install WorkBuddy run: curl -fsSL https://get.workbuddy.dev | sh - name: Run Skill Test run: | cd ~/.workbuddy/skills/${{ github.event.repository.name }} workbuddy run ${{ github.event.repository.name }} --help 2/dev/null || echo ❌ Help test failed这个 workflow 会每次 push 自动拉取最新代码安装最新版 WorkBuddy进入 Skill 目录运行workbuddy run id --helpWorkBuddy 会解析SKILL.md并显示帮助证明结构正确实战效果我们团队 23 个 SkillCI 覆盖率 100%平均每次 PR 合并前自动发现 1.2 个格式错误如SKILL.md缺少## Version、script.sh缺少#!/bin/bash。人力 Review 时间减少 70%。6. 常见故障排查从报错信息反推问题根源附速查表WorkBuddy 的错误信息设计得很“程序员友好”——不掩饰但需要你懂一点底层逻辑。下面是我整理的高频报错及定位路径按出现频率排序。6.1bash: ./script.sh: /bin/bash^M: bad interpreter: No such file or directory根本原因script.sh是 Windows 换行符CRLF而 Linux/macOS/bash 只认 LF。定位步骤file script.sh→ 如果显示with CRLF line terminators确诊cat -A script.sh→ 会看到每行末尾有^M修复VS Code右下角状态栏 →CRLF→ 点击切换为LF命令行dos2unix script.sh需先sudo apt install dos2unix通用sed -i s/\r$// script.sh6.2Error: missing SKILL.md根本原因WorkBuddy 扫描目录时没找到SKILL.md文件。常见诱因文件名写成skill.md小写或SKILL.markdown扩展名错SKILL.md在子目录里如~/.workbuddy/skills/hello-world/docs/SKILL.md不在 Skill 根目录文件权限问题ls -l SKILL.md显示----------无读权限修复ls -la ~/.workbuddy/skills/hello-world/确认文件存在且权限为-rw-r--r--chmod 644 SKILL.md6.3Failed to execute skill: exit code 127根本原因script.sh中调用了不存在的命令。典型场景unzip命令未安装-bash: unzip: command not foundcrontab命令未安装-bash: crontab: command not foundlsusb命令在无 USB 设备的服务器上不可用定位在script.sh开头加set -x重新运行看哪一行报错或bash -x script.sh手动调试修复检查命令是否存在which unzip添加前置检查if ! command -v unzip /dev/null; then echo Error: unzip is not installed. Run sudo apt install unzip 2 exit 127 fi6.4Error: invalid input parameter xxx根本原因SKILL.md中## Input定义的参数名和script.sh中引用的环境变量名不一致。例子SKILL.md写- api_key (required)script.sh写echo $WB_INPUT_apikey少了下划线定位env | grep WB_INPUT查看实际注入的变量名对比SKILL.md的参数名api_key→WB_INPUT_api_key修复统一使用api-key短横线WorkBuddy 会转为WB_INPUT_api_key或在SKILL.md中写api_keyscript.sh中用WB_INPUT_api_key6.5workbuddy: command not found根本原因WorkBuddy CLI 未正确安装或 PATH 未生效。检查which workbuddy→ 无输出则未安装echo $PATH→ 看是否包含~/.local/binLinux/macOS 默认安装路径或%USERPROFILE%\AppData\Local\binWindows修复重新安装curl -fsSL https://get.workbuddy.dev | sh手动添加 PATHexport PATH$HOME/.local/bin:$PATH加到~/.bashrc故障排查黄金法则永远先看workbuddy version再看ls -la最后bash -x script.sh。90% 的问题这三步就能定位。7. 未来演进Skill 生态的边界在哪里基于当前架构的合理预测WorkBuddy 的 Skill 架构不是终点而是起点。从现有设计能看出清晰的演进脉络这些不是猜测而是基于其开源协议、API 设计和社区反馈的合理推演。7.1 从本地执行到云函数调度Skill 的 Serverless 化当前 Skill 必须在本地运行限制了跨设备、跨网络的调用。但 WorkBuddy 的script.sh本质是标准 POSIX 环境天然适配 AWS Lambda、Cloudflare Workers 的 Linux Runtime。未来可能的路径workbuddy deploy --to aws自动打包 Skill 目录上传到 Lambda生成 HTTP endpointworkbuddy run https://api.example.com/skill/math-sum --a1 --b2远程调用返回 JSON 结果这会让 Skill 从“个人效率工具”升级为“轻量级 API 服务”比如jira-daily-report可以变成每日定时推送飞书消息的 webhook。7.2 从 Markdown 到 LLM Prompt 工程Skill 的智能增强SKILL.md的## Input和## Output描述天然就是 LLM 的 System Prompt。WorkBuddy 可能引入ai:前缀的 Skill 类型## Type ai: true ## Model openai/gpt-4-turbo ## Prompt You are a senior data analyst. Summarize the key insights from the following CSV data...用户仍用workbuddy run csv-summary --filedata.csv但背后调用的是 LLM API。这不需要改 Skill 结构只需引擎层增加 AI 执行器——WorkBuddy 的插件化设计已预留此空间。7.3 从单文件到模块化Skill 的依赖管理现在 Skill 是原子化的但复杂任务需要组合。workbuddy run可能支持管道workbuddy run csv-to-xlsx --fileinput.csv | workbuddy run excel-to-pdf --input- --outputreport.pdf--input-表示从 stdin 读取。这要求 Skill 输出格式标准化如 JSON LinesWorkBuddy 会自动处理流式传输。csv-to-xlsx的输出不再是文件而是 base64 编码的 Excel 二进制流。7.4 从命令行到 GUI 集成Skill 的可视化封装VS Code 插件已支持workbuddy run命令。下一步可能是右键文件 → “Run as Skill” → 弹出
