安装 Claude 技能前先审查随附脚本

安装 Claude Code skill，不能只读它承诺做什么，还要看它让模型执行什么。AgentCraft 作者检查了 5,036 个社区 skill，发现 979 个会在 SKILL.md 中引用随包脚本，约占五分之一；272 个引用的脚本包含网络访问模式，93 个还读取了名称像密钥的环境变量。

这组数字不等于恶意软件比例。它更有用的提醒是：skill 可能把说明文字、命令授权和本机代码绑在一起。对经常装开发辅助工具的程序员来说，安装前顺着入口读几份文件，比只看功能介绍更能判断执行范围。

为什么读完 SKILL.md 还不够

SKILL.md 可以要求 Claude 执行 skill 目录里的脚本。这些代码运行在你的机器上，使用你的权限。一个生成项目的工具可能创建目录，一个部署工具可能清理临时文件，一个网站审计工具则需要联网抓页面。这些行为都可能合理，但功能介绍未必交代了具体路径和执行方式。

作者建议先找 scripts/，再定位 SKILL.md 实际点名的文件。重点搜索四类操作：

• 用 curl、requests、fetch、wget 访问网络。
• 用 rm -rf、shutil.rmtree 递归删除目录。
• 在脚本内部运行 pip install、npm install。
• 读取名称带有 KEY、TOKEN、SECRET 的环境变量。

需要核对的是操作是否符合用途，以及它具体作用于哪里。

原文举了几个匿名例子：SEO 工具从 ~/.config/<tool>/.env 加载自己的 API 密钥；音乐视频工具用 shutil.rmtree 删除项目目录；幻灯片工具在自己的目录中运行 npm install，准备 PPTX 导出。不能仅凭这些调用判定危险，但密钥读自哪里、删除路径如何计算、依赖装到哪里，都应该能解释清楚。

脚本数量也不能代替判断。作者强调，带四十个辅助脚本的 skill 可能无害，只有一个脚本的 skill 也可能把密钥发出去。先读被引用的执行入口，才有针对性。

哪些命令可能在你确认之前运行

第二个入口是 SKILL.md 的 allowed-tools 字段。按原文对文档的描述，这里列出的工具，在调用该 skill 的当前轮次中可以免去权限提示。

Bash(git status *) 把授权限制在对应命令范围；单独的 Bash 则允许任意 shell 命令。作者举出的一个实验循环 skill，预先允许了 Read、Write、Edit、Bash 和 Agent，并调用自带的目录树脚本。理解它的权限，不能只盯着那个脚本。

原文还引用文档指出，workspace trust 不限制这个字段，即使项目文件夹从未被信任，项目 skill 仍可应用这项配置。这是作者援引的规则，文章没有进一步展开其他权限层之间如何交互。

第三个入口更容易漏掉：搜索 SKILL.md 中的 !`。例如 !`git diff HEAD` 会在 skill 加载时执行 shell 命令，再把输出填入内容，随后 Claude 才读取它。

因此，只审查「模型读完说明后准备做什么」还不完整。加载说明本身，也可能执行代码。

五分之一这个数字，究竟统计了什么

作者所在的 AgentCraft 目录当时共有 5,101 个 skill，其中 5,082 个是通过审核的社区 skill，另外 19 个是 Anthropic 官方 skill，未纳入研究。社区部分成功读取了 5,036 个，其余因仓库删除或抓取失败而缺失。

研究按仓库获取 GitHub 文件树，并从同一 commit 读取 SKILL.md 和脚本。脚本范围包括 .py、.sh、.js、.ts、.mjs、.rb、.pl、.ps1，最多深入三层，排除其他 skill 目录以及 node_modules、测试、fixtures 和构建产物。只有 SKILL.md 点名的脚本进入行为统计。

这是一份静态能力扫描，不是实际执行记录。

作者没有安装或运行这些工具，而是去掉注释后做模式匹配，再人工抽查，修正了四条过度计数的规则。例如，打印一句 pip install X 提示，并不代表脚本真的执行安装。

他们还检查了 11 月审核中被淘汰的 317 个 skill，该轮共审核了 783 个新 skill。因不安全被淘汰的一组，引用脚本的比例为 39.0%，是保留组 19.4% 的 2.0 倍；因规避平台规则被淘汰的一组为 48.6%，约为 2.5 倍。

两组的联网比例分别为 14.6%、20.0%，相比保留组的 5.4%，约为 2.7 倍和 3.7 倍。但所有淘汰项合并后，引用脚本的比例只有 20.2%，因为模板和演示类 skill 几乎不带脚本。

这些数字说明审核类别之间存在差异，不能证明「带脚本导致被淘汰」。

我的判断

我认同作者把检查重点放在执行入口和授权范围上。相比笼统地要求「安装前审计源码」，找出 SKILL.md 点名的脚本，再检查网络、文件、安装和凭据操作，是更容易落实的第一步。

但这套检查只能帮助筛选，不能提供安全保证。静态规则会漏掉运行时拼接的调用，也可能误中字符串；原文承认，联网统计包含部分加载本地文件的浏览器代码，凭据路径匹配也可能命中安全扫描器的拦截规则。被点名的脚本还未必每次都执行。

数据也有明确边界：样本来自 AgentCraft 自己的目录，淘汰原因来自他们自己的审核，并非随机抽样。作者参与运营 AgentCraft，文章同时介绍了目录的审核机制，这层关系需要保留在判断里。所有文件取自 2026 年 11 月 6 日的当前 commit，也不一定对应最初收录时的版本。

原文没有给出「检查后减少多少事故」的对照数据。因此，安装前检查的效果仍是经验建议。与隔离运行环境相比，读脚本帮助理解行为，隔离则限制行为能触及的资源；文章没有测试两者的效果，也没有判断任何具体脚本是否滥用了能力。

能拿来做什么

• 给前端或 Node 项目安装 skill 前，把 SKILL.md 引用的脚本找出来，核对网络请求目标、文件读写路径和删除路径，确认它们与工具用途一致。
• 看到 allowed-tools 中单独的 Bash 时，检查该任务实际需要哪些命令；编写自己的 skill 时，优先采用能够覆盖任务的具体命令范围。
• 检查加载时执行的 !` 表达式，以及脚本里的 pip install、npm install，把加载动作和依赖安装也计入审查范围。
• 团队复用 skill 时，记录审查过的 commit，并在更新后重读相关改动；这份研究已经说明，同一个收录条目对应的源码会变化。