把命令行工具包成 AI 可调用的 Skill

视频下载这件事，yt-dlp 早就把难题解决了：格式协商、流合并、断点续传……一个成熟的命令行工具，功能完备到你几乎不需要自己写任何逻辑。但有一个问题：每次用都要想参数，质量怎么选、格式怎么选、输出目录怎么定——这些「参数决策」才是真正消耗注意力的地方。

把这个工具封装成 AI 可以直接调用的 skill，是我觉得性价比很高的一个工程动作。

封装的本质：把参数决策变成意图表达

原始用法是这样的：

yt-dlp -f "bestvideo[height<=1080]+bestaudio/best[height<=1080]" \
  --merge-output-format mp4 \
  -o "/path/to/output/%(title)s.%(ext)s" \
  "https://www.youtube.com/watch?v=VIDEO_ID"

写一遍没问题，写十遍就开始出错。格式选择器的语法是 yt-dlp 专有的，每次用都要回去翻文档。

封装之后，调用方式变成：

python scripts/download_video.py "URL" -q 1080p

背后做了什么？一个薄薄的 Python 脚本把「质量选项」映射到了 yt-dlp 的格式选择器，把「自动安装检测」处理成启动逻辑，把「默认输出路径」固化为约定目录。参数决策从调用时转移到了封装时——由写 skill 的人决定一次，调用方只需要表达意图。

这是工具代理化最核心的一步。

为什么要为 AI 单独封装

把工具包成 AI skill 和普通脚本封装有一个本质区别：AI 不擅长记忆和查文档，但很擅长解析意图。

给人用的脚本可以有 20 个参数，只要 --help 写清楚就行。给 AI 用的 skill 参数越少越好——AI 通过读 skill 的描述（description 字段）来判断「这个工具能不能解决用户的问题」，而不是通过枚举参数来决策。

所以好的 AI skill 应该：

• description 写清楚触发时机：「用户要下载/保存/抓取视频时调用」，比「视频下载工具」更容易被匹配到正确场景
• 参数设计要有合理默认值：默认最高质量、默认 mp4、默认固定目录——让零参数调用也能得到有用的结果
• 把安装依赖做进去：工具不在就自动装，AI 没有「先去装 yt-dlp」的步骤意识，所以封装层必须兜住这个

边界与取舍

这套做法有它的适用范围。

适合封装的工具：有成熟 CLI、参数集合固定、调用语义清晰（下载/转换/压缩/提取）。yt-dlp、ffmpeg、pandoc、ImageMagick 都是好候选。

不适合封装的工具：调用结果高度依赖上下文、需要交互式确认、或者输出格式复杂到 AI 没法解析后续结果的。这类工具包成 skill 反而会让 AI 陷入「调用了但不知道成没成功」的困境。

还有一个常被忽略的取舍：封装会固化决策。把「默认最高质量」写死在 skill 里，意味着以后每次下载都是最高质量——哪怕用户只是想快速预览。解法是暴露少量覆盖参数（-q 720p），但不要把所有 yt-dlp 的选项都透传，那样就退化成了对原始工具的薄薄包装，失去了封装的意义。

一句话心法

工具代理化不是把 CLI 的每个参数都翻译一遍，而是决定哪些参数值得由 AI 的调用者来关心，哪些应该在封装时就替他们想好。