1. 项目概述这不是一个发型而是一套轻量级 CLI 工具链的命名哲学“ponytail”这个词在中文互联网里刚冒头时我第一反应是扎马尾辫——毕竟搜索热词清一楚楚写着“ponytail”“ponytail skill”还混着“npx skill add dietrichgebert/ponytail”这种明显带 npm 生态味儿的命令。但点开 GitHub 仓库dietrichgebert/ponytail一看根本不是美妆教程也不是前端 UI 组件库而是一个极简、无依赖、纯 Bash 写成的 CLI 工具集核心就干一件事把零散的 shell 脚本、配置片段、环境变量注入逻辑封装成可复用、可发现、可组合的“技能”skill单元并通过统一入口按需加载执行。它不碰 Web 框架不依赖 Node.js 运行时虽然支持 npx 调用也不改写你的 shell 配置文件——它只是安静地蹲在$PATH里等你敲下ponytail list或ponytail run dev-server。这个命名非常狡猾也极其精准。“ponytail”在这里不是指物理发型而是取其“束起、收拢、轻便、可快速甩动”的意象它把开发者日常那些散落在~/.bashrc里粘着胶带的 alias、藏在~/bin/下积灰的.sh脚本、写在 Notion 里却永远找不到的调试命令统统“扎成一束”不臃肿、不固化、不侵入用完即走。它解决的不是某个具体技术问题而是现代开发者普遍存在的“工具熵增”困境——项目越多本地环境越杂重复造轮子越多调试路径越绕。一个团队里A 同学写了个一键清理 Docker 残留的脚本存在自己电脑上B 同学重写了三遍类似的逻辑C 同学还在手动ps aux | grep node找端口。ponytail 就是那个帮你把这三个人的“私有技能”标准化、版本化、共享化的轻量协议层。它适合谁不是给刚装完 Ubuntu 就想配 Zsh 主题的新手看的而是给那些已经用熟了make、just、taskfile但发现它们要么太重要写 YAML/DSL、要么太死每次改都要 reload shell、要么太散每个项目都得维护一套的中高级开发者。如果你常在终端里输入超过 5 个单词的命令来启动开发环境或者你的~/.zshrc里有 37 行以alias dev开头的定义那你就是 ponytail 的天然用户。它不承诺替代你的构建系统也不试图统一你的 CI 流程它只做一件事让“执行一个开发任务”这件事回归到最原始、最直接、最可传播的状态——就像扎起马尾头发不乱了动作也利索了。2. 核心设计思路拆解为什么是 Bash为什么是 “skill”为什么拒绝 Node.js 运行时2.1 选择纯 Bash 实现不是怀旧而是对“最小可信基线”的执念ponytail 的整个核心逻辑包括ponytail主命令、skill管理器、run执行器全部由不到 800 行的 POSIX 兼容 Bash 脚本构成。有人看到这第一反应是“过时”“难维护”“功能弱”。但恰恰相反这是作者 Dietrich Gebert 在多年服务端运维和跨平台 CLI 开发中踩坑后做出的最清醒的技术取舍。先说现实约束一个 CLI 工具它的第一道门槛不是功能多强大而是“能不能在目标机器上跑起来”。你写一个基于 Node.js 的工具用户就得先装 Node写一个 Python 的就得确认python3是否在 PATH、是否带venv写一个 Rust 的二进制包虽小但 macOS 和 Linux 的 ABI 兼容性、musl vs glibc 的链接问题又是一堆隐形雷。而 Bash 呢它是 POSIX 标准的一部分只要是个像样的 Unix-like 系统macOS、Linux 发行版、WSL、甚至部分嵌入式 BusyBox 环境/bin/sh或/usr/bin/env bash就一定存在。ponytail 的安装命令curl -sL https://raw.githubusercontent.com/dietrichgebert/ponytail/main/install.sh | bash之所以能一行搞定底气就来自这里——它不下载二进制不编译源码只是把几个.sh文件chmod x后扔进$HOME/.local/bin然后确保该路径在$PATH前端。整个过程没有网络请求失败回退逻辑没有依赖解析树没有版本冲突提示只有cp和chmod两个原子操作。再看维护成本。Bash 脚本确实不如 TypeScript 那样有类型检查、IDE 自动补全、单元测试框架成熟。但 ponytail 的设计哲学是“功能极简边界清晰”。它的核心就三个函数ponytail_list_skills()列出所有可用 skillponytail_load_skill()按名称加载 skill 定义ponytail_run_skill()执行 skill 的main()函数。每个 skill 本身就是一个独立的.sh文件里面只定义main()和可选的help()不涉及任何状态管理、异步调度、模块导入。这意味着调试极其简单ponytail run my-skill --debug会直接set -x输出每一步执行流你一眼就能看到是哪行grep没匹配上哪次curl返回了 404修改极其安全改一个 skill只影响这个 skill不会因为改了utils.sh就导致所有 skill 失效审查极其透明cat ~/.ponytail/skills/dev-server.sh就是全部源码没有node_modules里的 2000 个依赖没有Cargo.lock里层层嵌套的版本锁。这不是技术保守主义而是对“工具链可靠性”的极致追求。当你在客户现场一台只装了 CentOS 6 的老服务器上需要快速诊断一个 Java 进程内存泄漏而你唯一能用的就是bash和jstack这时候一个纯 Bash 的诊断 skill比任何花哨的 Web UI 都管用。2.2 “Skill” 模型把命令抽象成可发现、可组合、可文档化的单元ponytail 最颠覆认知的设计是它没有采用传统 CLI 的“命令-子命令”树状结构如git commit,git push而是引入了“skill”这个概念。一个 skill 不是一个命令而是一个自包含的、带元数据的、可独立分发的执行单元。它看起来就是一个普通 shell 脚本但被 ponytail 赋予了额外的语义可发现性Discoverability每个 skill 文件必须以.sh结尾放在~/.ponytail/skills/目录下且文件名即为 skill 名如dev-server.sh对应ponytail run dev-server。ponytail 会自动扫描该目录读取每个文件开头的注释块类似 Go 的 doc comment提取# name,# desc,# author,# version字段生成ponytail list的输出。这意味着你不需要记住./scripts/start-dev.sh这个路径只需要知道“有个叫 dev-server 的技能”ponytail list | grep dev就能把它揪出来。可组合性Composabilityskill 之间可以互相调用。比如你写了一个setup-env.sh负责安装项目依赖、配置.env文件另一个dev-server.sh可以在自己的main()函数里直接写ponytail run setup-env。ponytail 会自动处理 PATH 注入、环境变量继承、错误传播set -e默认开启。这打破了传统 shell 脚本“孤岛式”组织的局限——以前你要么把所有逻辑塞进一个大脚本要么用source硬链接一旦setup-env.sh路径变了所有引用它的脚本全挂。现在ponytail run dev-server这条命令本身就是一条“声明式工作流”它不关心setup-env存在哪只关心“我能调用它”。可文档化Documentability每个 skill 的# desc字段会被ponytail help skill命令直接渲染成帮助文本。更妙的是# example字段支持多行示例ponytail help dev-server会输出Start the local development server with hot reload. Examples: ponytail run dev-server ponytail run dev-server --port 3001 ponytail run dev-server --debug这些示例不是静态字符串而是被解析成实际可执行的命令模板。用户复制粘贴就能跑不用再去翻 README。而且这些注释字段是纯文本可以用任何编辑器修改不需要学习新的 DSL 或 YAML 语法。这个模型的价值在于它把“如何执行一个任务”的知识从隐性的、口头的、文档里的变成了显性的、可执行的、可验证的代码资产。当新同事入职你不再说“哦启动后端要先跑./scripts/db-migrate.sh再cd backend npm start”而是直接给他一条命令ponytail run start-backend。这条命令背后可能封装了数据库迁移、环境变量校验、依赖安装、进程守护、日志聚合……但新同事不需要知道这些细节他只需要知道“这个 skill 是做什么的”以及“怎么用”。2.3 拒绝 Node.js 运行时npx 只是“门面”不是“心脏”网络热词里反复出现npx skill add dietrichgebert/ponytail很容易让人误以为 ponytail 是一个 Node.js 工具。其实这是一个精巧的“双模发布”策略。npx命令在这里扮演的只是一个便捷的安装代理和跨平台启动器而非运行时依赖。具体来说npx skill add dietrichgebert/ponytail这条命令底层执行的是npx临时下载并运行skill这个 Node.js 工具它本身是一个轻量 CLI用于管理各种技能仓库skill工具根据dietrichgebert/ponytail这个地址去 GitHub 获取 ponytail 的install.sh脚本skill工具再调用bash install.sh完成真正的纯 Bash 安装。也就是说npx只参与了“下载和启动安装脚本”这一瞬间之后 ponytail 的所有运行都与 Node.js 彻底无关。你完全可以不用npxcurl -sL https://raw.githubusercontent.com/dietrichgebert/ponytail/main/install.sh | bash效果完全一样安装完成后ponytail命令本身就是一个普通的可执行 shell 脚本which ponytail输出的是/home/user/.local/bin/ponytailfile $(which ponytail)显示的是POSIX shell script, ASCII text executable。为什么要设计这个npx入口答案很务实降低初次接触门槛。很多前端开发者电脑里已经有 Node.jsnpx是他们最熟悉的“一键安装”方式。对他们来说npx skill add ...比记一个 curl 命令、理解~/.local/bin是什么、确认$PATH是否生效要友好得多。但这绝不意味着 ponytail 依赖 Node.js。恰恰相反它的核心竞争力正是这种“零运行时依赖”的纯粹性。你可以把它部署在一台只装了 Alpine Linux 和 BusyBox 的容器里只要bash在ponytail就能跑。这种能力在云原生场景下价值巨大CI/CD runner 镜像可以做得极小FROM alpine:latest无需预装 Node.js节省镜像体积和拉取时间Serverless 函数的启动冷延迟更低因为没有 Node.js 引擎初始化开销。所以“ponytail skill” 这个热词组合本质是描述一种技能分发范式skill是通用的技能管理协议由skill这个 Node.js 工具实现而ponytail是该协议下的一个具体实现用 Bash 写的轻量版。它们可以共存但彼此解耦。你完全可以用skill工具去添加一个 Python 写的 skill或者一个 Rust 编译的二进制 skillponytail只是其中一种选择。这种设计体现了作者对“协议”与“实现”边界的清晰认知——不把生态绑定在单一技术栈上才是长期生命力的保障。3. 核心实操环节从零搭建你的第一个 ponytail skill3.1 环境准备与基础安装三分钟完成“无感”集成ponytail 的安装刻意设计得没有任何仪式感。它不修改你的 shell 配置文件.bashrc,.zshrc不创建全局符号链接不向/usr/local/bin写文件。整个过程就是把几个脚本文件放到你家目录下的一个隐藏文件夹里并确保该文件夹在$PATH的搜索路径中。这种“非侵入式”安装是它能在任何环境下稳定运行的基石。第一步确认你的系统满足最低要求。打开终端依次执行# 检查 bash 版本需 4.0绝大多数现代系统都满足 bash --version | head -n1 # 检查 curl 是否可用用于下载安装脚本 which curl # 检查 $HOME/.local/bin 是否已在 $PATH 中推荐位置 echo $PATH | grep -q $HOME/.local/bin echo OK || echo Need to add如果最后一行输出Need to add说明你需要手动将~/.local/bin加入$PATH。这只需在你的 shell 配置文件末尾如~/.bashrc或~/.zshrc添加一行export PATH$HOME/.local/bin:$PATH然后执行source ~/.bashrc或source ~/.zshrc使其立即生效。注意这一步是唯一一次需要你手动编辑配置文件ponytail 后续的所有操作都不再需要。第二步执行安装。官方推荐两种方式任选其一方式一推荐最干净使用 curl 直接执行安装脚本curl -sL https://raw.githubusercontent.com/dietrichgebert/ponytail/main/install.sh | bash方式二适合离线或审计环境分步下载并执行# 下载安装脚本到本地 curl -sL https://raw.githubusercontent.com/dietrichgebert/ponytail/main/install.sh -o install-ponytail.sh # 查看脚本内容确认无恶意操作这是好习惯 cat install-ponytail.sh | head -n 20 # 执行安装 bash install-ponytail.sh安装脚本会做三件事创建~/.ponytail/目录存放所有 skill 和配置创建~/.ponytail/skills/子目录skill 的默认存储位置将ponytail主命令脚本约 700 行 Bash复制到~/.local/bin/ponytail并赋予可执行权限。安装完成后验证是否成功# 检查 ponytail 命令是否在 PATH 中 which ponytail # 查看 ponytail 版本和基本信息 ponytail --version # 列出当前所有可用的 skill此时应该为空 ponytail list如果which ponytail输出了路径且ponytail --version显示了版本号如ponytail v0.3.1恭喜你已经完成了 90% 的工作。剩下的就是往~/.ponytail/skills/里放东西了。提示ponytail 的安装脚本是幂等的。你可以放心地多次运行它它只会覆盖已有的文件不会重复创建目录或破坏现有 skill。这在自动化部署脚本中非常有用——你可以在 CI 流水线的每个 job 开头都加一句curl ... | bash确保环境始终有一份最新版 ponytail。3.2 编写第一个 skill“hello-world” 的完整生命周期现在我们来亲手创建第一个 skill。它不解决任何实际问题但会完整走通 ponytail 的整个开发流程编写、测试、文档化、发布、复用。我们把它命名为hello-world。首先创建 skill 文件# 进入 skills 目录 cd ~/.ponytail/skills # 创建 hello-world.sh 文件 touch hello-world.sh然后用你喜欢的编辑器nano,vim,code打开hello-world.sh填入以下内容#!/usr/bin/env bash # name hello-world # desc A simple greeting skill that prints a personalized message. # author Your Name # version 1.0.0 # example ponytail run hello-world # example ponytail run hello-world --name Alice # example ponytail run hello-world --name Bob --greeting Hi there # Parse command line arguments NAMEWorld GREETINGHello while [[ $# -gt 0 ]]; do case $1 in --name) NAME$2 shift 2 ;; --greeting) GREETING$2 shift 2 ;; *) echo Unknown option: $1 2 exit 1 ;; esac done # The main function - this is what gets executed main() { echo ${GREETING}, ${NAME}! echo This is running from: $(realpath $0) } # This line is mandatory - it tells ponytail where the main logic is main $这段代码看似简单但包含了 ponytail skill 的所有关键要素Shebang 行(#!/usr/bin/env bash)明确指定解释器保证跨平台兼容。元数据注释块(# name,# desc等)这些是 ponytail 解析 skill 信息的唯一来源ponytail list和ponytail help全靠它们。参数解析逻辑使用经典的while [[ $# -gt 0 ]]循环支持--name和--greeting两个选项。ponytail 本身不提供参数解析库它把这件事完全交给 skill 作者——这保证了最大灵活性你可以用getopts也可以用更复杂的argparse风格。main()函数这是 ponytail 执行 skill 的入口点。ponytail run hello-world实际上就是source hello-world.sh main。main $调用这是最后也是最关键的一行。它把所有传入ponytail run的参数原封不动地转发给main()函数。没有这行你的 skill 就不会接收任何参数。保存文件后给它加上可执行权限虽然 ponytail 不强制要求但这是良好实践chmod x hello-world.sh现在测试它# 列出所有 skill应该能看到 hello-world ponytail list # 查看它的帮助信息自动从注释块提取 ponytail help hello-world # 执行默认行为 ponytail run hello-world # 输出Hello, World! # 执行带参数的行为 ponytail run hello-world --name DevOps Engineer --greeting Welcome aboard # 输出Welcome aboard, DevOps Engineer! 注意ponytail 的run命令内部实现是source当前 skill 文件然后调用其main函数。这意味着 skill 文件里的所有变量、函数定义都在当前 shell 的上下文中执行。这既是优势可以轻松访问当前 shell 的所有环境变量和函数也是需要注意的风险避免污染全局命名空间。因此ponytail 的最佳实践是在main()函数内部定义所有局部变量使用local关键字声明不要在文件顶层定义全局变量。3.3 进阶实战构建一个真实可用的 “dev-server” skill光有hello-world还不够我们来做一个真正能提升日常效率的 skilldev-server。它的目标是一键启动一个前端项目的本地开发服务器并自动处理端口冲突、环境变量注入、进程守护等琐事。我们将以一个典型的 React/Vite 项目为例但这个 skill 的设计是通用的稍作修改即可适配 Vue、Next.js 等。首先创建dev-server.shcd ~/.ponytail/skills touch dev-server.sh编辑dev-server.sh填入以下内容我会逐段解释其设计意图#!/usr/bin/env bash # name dev-server # desc Start the local development server for the current project. # author Your Name # version 1.1.0 # example ponytail run dev-server # example ponytail run dev-server --port 3001 # example ponytail run dev-server --host 0.0.0.0 --https # --- Configuration Section --- # Default values, can be overridden by command line args PORT3000 HOSTlocalhost HTTPSfalse PROJECT_ROOT. # Path to the package.json file (used to detect project type) PACKAGE_JSON${PROJECT_ROOT}/package.json # --- Utility Functions --- # Function to check if a port is free is_port_free() { local port$1 if command -v lsof /dev/null 21; then # macOS and most Linux ! lsof -i :$port -sTCP:LISTEN -t /dev/null 21 elif command -v ss /dev/null 21; then # Modern Linux ! ss -tuln | grep -q :$port else # Fallback: try to bind to the port (echo | nc -w1 $HOST $port 2/dev/null) || return 0 return 1 fi } # Function to find an available port starting from a base find_available_port() { local base_port$1 local max_attempts10 local attempt0 local port$base_port while [ $attempt -lt $max_attempts ]; do if is_port_free $port; then echo $port return 0 fi port$((port 1)) attempt$((attempt 1)) done echo Error: No free port found in range $base_port-$((base_port max_attempts - 1)) 2 return 1 } # --- Argument Parsing --- while [[ $# -gt 0 ]]; do case $1 in --port) PORT$2 shift 2 ;; --host) HOST$2 shift 2 ;; --https) HTTPStrue shift ;; --root) PROJECT_ROOT$2 PACKAGE_JSON${PROJECT_ROOT}/package.json shift 2 ;; *) echo Unknown option: $1 2 exit 1 ;; esac done # --- Main Logic --- main() { # Step 1: Validate project root if [[ ! -d $PROJECT_ROOT ]]; then echo Error: Project root $PROJECT_ROOT does not exist. 2 exit 1 fi # Step 2: Detect project type from package.json if [[ ! -f $PACKAGE_JSON ]]; then echo Error: No package.json found in $PROJECT_ROOT. Is this a valid project? 2 exit 1 fi local framework if jq -e .dependencies.react-dom $PACKAGE_JSON /dev/null 21; then frameworkreact elif jq -e .dependencies.vue $PACKAGE_JSON /dev/null 21; then frameworkvue elif jq -e .dependencies.next $PACKAGE_JSON /dev/null 21; then frameworknext else frameworkunknown fi echo Detected framework: $framework echo Using project root: $(realpath $PROJECT_ROOT) # Step 3: Handle port conflict if ! is_port_free $PORT; then echo Warning: Port $PORT is in use. Finding a free one... PORT$(find_available_port $PORT) if [[ $? -ne 0 ]]; then exit 1 fi fi echo Starting server on http$([[ $HTTPS true ]] echo s)://$HOST:$PORT # Step 4: Change to project directory and start the server cd $PROJECT_ROOT || { echo Failed to change to $PROJECT_ROOT; exit 1; } # Build the command based on framework local cmd() case $framework in react|vue) # For Vite-based projects (React/Vue) cmd(npm run dev -- --port $PORT --host $HOST) if [[ $HTTPS true ]]; then cmd(--https) fi ;; next) # For Next.js cmd(npm run dev -- -p $PORT -H $HOST) if [[ $HTTPS true ]]; then echo Warning: HTTPS is not natively supported by next dev. Consider using a reverse proxy. 2 fi ;; unknown) # Generic fallback: look for common dev scripts if jq -e .scripts.dev $PACKAGE_JSON /dev/null 21; then cmd(npm run dev -- --port $PORT --host $HOST) else echo Error: Could not determine how to start the dev server for this project. 2 echo Please ensure your package.json has a dev script. 2 exit 1 fi ;; esac # Step 5: Execute the command echo Running: ${cmd[]} exec ${cmd[]} } main $这个dev-server.sh技能展示了 ponytail 在真实场景中的威力智能端口探测它不硬编码3000而是先检查该端口是否被占用如果被占则自动寻找下一个空闲端口find_available_port。这解决了多人协作时端口冲突的经典痛点。框架自动识别通过解析package.json它能自动判断当前项目是 React、Vue 还是 Next.js并选择对应的启动命令。你不需要为每个项目单独写一个 skill一个 skill 通吃。环境隔离cd $PROJECT_ROOT确保所有命令都在正确的项目目录下执行避免了因当前工作目录错误导致的npm run dev失败。错误防御每一步都有明确的if判断和错误提示比如PROJECT_ROOT不存在、package.json找不到、dev脚本未定义等让用户第一时间知道问题出在哪而不是看到一堆 npm 的报错堆栈。测试它# 在你的 React 项目根目录下执行 ponytail run dev-server # 指定端口和主机 ponytail run dev-server --port 3005 --host 0.0.0.0 # 指定项目根目录在任意目录下都能启动 ponytail run dev-server --root /path/to/your/vue-project你会发现它比直接敲npm run dev更可靠、更智能、更少出错。而且这个 skill 是完全可移植的——你可以把它拷贝到任何一台装了 ponytail 的机器上立刻就能用。4. 深度应用与避坑指南从个人工具到团队知识库4.1 构建团队共享的 skill 仓库Git Ponytail 的协同工作流ponytail 的单机模式很好用但它的真正价值在于将个人经验沉淀为团队可复用的知识资产。一个成熟的团队不应该有“只有 A 同学知道怎么部署测试环境”这种知识孤岛。ponytail 提供了一套极简的、基于 Git 的共享机制让技能的分发、更新、版本控制变得像git pull一样简单。核心思想是将~/.ponytail/skills/目录变成一个 Git 仓库的工作区。团队维护一个中央仓库例如https://github.com/your-org/ponytail-skills里面存放所有经过审核、测试的 skill 脚本。每个成员的本地~/.ponytail/skills/就是这个远程仓库的一个克隆。具体操作步骤如下第一步初始化中央仓库在 GitHub/GitLab 上创建一个新的空仓库ponytail-skills。然后本地克隆它并将其设为~/.ponytail/skills/的新家# 备份原有的 skills可选 mv ~/.ponytail/skills ~/.ponytail/skills-backup # 克隆中央仓库到 skills 目录 git clone https://github.com/your-org/ponytail-skills.git ~/.ponytail/skills # 进入目录设置上游分支 cd ~/.ponytail/skills git remote add upstream https://github.com/your-org/ponytail-skills.git第二步添加和提交第一个团队 skill假设你们决定共享一个deploy-staging.sh技能用于一键部署到预发环境。创建它cd ~/.ponytail/skills touch deploy-staging.sh # 编辑 deploy-staging.sh加入你的部署逻辑... chmod x deploy-staging.sh然后像标准 Git 工作流一样提交git add deploy-staging.sh git commit -m feat(skills): add deploy-staging for CI/CD pipeline git push origin main第三步团队成员同步更新其他成员只需要执行一条命令就能获取所有最新技能# 进入 skills 目录 cd ~/.ponytail/skills # 拉取最新变更 git pull upstream main # 可选查看更新了哪些 skill git log --oneline HEAD{1}..HEAD --name-only这个工作流的优势在于其零摩擦和强一致性零摩擦没有额外的 CLI 工具需要学习没有新的配置文件需要管理。git pull是每个开发者都懂的命令它天然支持分支、标签、PR 审核、历史追溯。强一致性所有成员运行ponytail run deploy-staging执行的都是完全相同的脚本。不存在“A 同学的脚本是 2023 年写的B 同学的是 2024 年改的C 同学自己魔改了一个版本”这种混乱局面。版本号# version和 Git 提交哈希共同构成了技能的唯一标识。提示为了进一步规范化可以在中央仓库的根目录下添加一个CONTRIBUTING.md文件规定 skill 的编写规范如必须包含# name,# desc,# example、测试要求如必须在 Ubuntu 22.04 和 macOS Sonoma 上测试通过、以及 PR 模板。这样新加入的技能从诞生之初就具备了可维护性和可信赖性。4.2 常见问题排查与独家避坑技巧在实际推广 ponytail 的过程中我和几个团队一起踩过不少坑。下面整理出最典型、最高频的五个问题以及我总结的、文档里找不到的独家解决方案。问题一ponytail run my-skill报错command not found: my-skill但ponytail list能看到它原因分析这是 ponytail 新手最容易遇到的陷阱。ponytail list只是扫描~/.ponytail/skills/目录下的.sh文件而ponytail run的执行依赖于 skill 文件中main()函数的正确定义。最常见的错误是忘记写main()函数或者main函数名拼错了比如写成了mainn或Main或者main $这一行被注释掉了或删掉了。排查技巧不要猜直接用bash -n语法检查。bash -n会进行语法检查但不执行bash -n ~/.ponytail/skills/my-skill.sh如果有语法错误它会立刻报出第几行。如果没有报错再检查main函数是否存在grep ^main() ~/.ponytail/skills/my-skill.sh如果输出为空说明main()函数缺失或格式不对必须是main()不能有空格或参数。独家避坑在你的~/.ponytail/skills/目录下创建一个template.sh文件作为所有新 skill 的起点。它应该包含一个最简但完整的骨架#!/usr/bin/env bash # name template # desc This is a template for new skills. # version 1.0.0 # example ponytail run template main() { echo Template skill executed successfully! } main $