夜雨聆风同事在群里丢来一个 Skill 链接，说可以让 Claude Code 自动写周报。
README 写得很漂亮，star 数也不少。你顺手 clone 下来，装进团队环境。
三天后才发现，它不只是几段 prompt。
AI 时代不仅带来了生产力爆炸，也带来了全新的、毫无防备的“投毒”温床。
包里还有 shell 脚本、依赖文件、工具定义和权限请求。它能读哪些文件？能不能联网？有没有机会把上下文里的密钥带出去？安装之前，其实没人查过。
NVIDIA 最近开源的 SkillSpector，有意思的地方就在这里。它不是让 Skill 变安全，也不是帮 Agent 多一个能力，而是在安装前把这些东西扫成一份风险报告。
它提醒团队一件事：Agent Skill 已经不只是 prompt 了。装进团队环境之前，先得知道包里到底有什么。
醒醒，你的 Agent 是在执行代码，而不是在读 txt
以前说 Skill，很多人会想到一段 Markdown prompt，复制粘贴进聊天窗口就能用。
现在不是这样了。
Claude Code、Codex CLI、Gemini CLI 这类 Agent 工具支持的 Skill，已经越来越接近一个小型软件包。它可能包含指令、脚本、依赖声明、工具元数据、触发条件和权限请求。
这让 Skill 更强，也让它更危险。
你不再只是分享一段提示词，而是在运行别人写的、可能带脚本和依赖的东西。这个变化会改变团队的采用标准：以前先看功能，现在至少要先看来源、脚本、依赖和权限。
举个很普通的例子。一个“自动写周报”的 Skill，可能需要读取代码提交记录、任务系统、聊天摘要和本地文件。它写得越顺手，拿到的上下文就越多。只要包里混进一段不该有的脚本，或者依赖了一个有问题的第三方库，风险就不是“周报写歪了”，而是团队上下文被带出了边界。
在 NVIDIA 引用的这组公开样本研究里，42,447 个 Skill 样本中，26.1% 至少包含一个漏洞，5.2% 显示出恶意意图。包含可执行脚本的 Skill，比纯文本 Skill 的漏洞可能性高出 2.12 倍。
别把这组数字理解成“每四个 Skill 就有一个一定会害你”。它更像一个信号：公开 Skill 生态里的风险已经不是边角料。
有些风险只是麻烦，比如声明了不必要的权限、依赖了有已知 CVE 的包、工具描述写得太模糊。也有些风险是真的危险，比如隐藏指令、外传数据、提权触发、供应链投毒。
问题不是“这个 Skill 能不能用”。
问题是：它进团队之前，有没有人真的看过。
1.3倍的风险系数：NVIDIA 到底在查什么？
SkillSpector 是一台命令行扫描器。Python 3.12 以上可以跑，Apache-2.0 开源协议。
最直接的用法，就是对着一个 Skill 路径或 Git URL 跑：
skillspector scan <path-or-url>
它能扫 Git 仓库、普通 URL、zip 压缩包、本地目录、单个文件或者单个 SKILL.md。扫完之后给一个 0 到 100 的风险分数，并附上严重等级和处置建议。
大致规则很直白：0-20 分是低风险，21-50 分是中风险，51-80 分是高风险，81-100 分是严重风险。如果 Skill 包里包含可执行脚本，风险分数还会乘以 1.3。
这不是在评价“这个 Skill 好不好用”。
它查的是 16 个类别、64 种不该出现在能力包里的模式。
所以看报告时别只盯总分。真正有用的是它能不能告诉你：哪个文件触发了风险，触发的是依赖漏洞、危险脚本，还是 Agent 指令里的异常行为。如果只剩一个分数，团队还是不知道该拒绝、修复、隔离还是继续观察。好的扫描报告，应该能把“感觉不安全”变成“这行代码、这个依赖、这条权限请求有问题”。
粗略看，它主要盯两类风险：
这些名字听起来像安全报告，但背后的意思很简单：Skill 不只是告诉模型“做什么”，它也可能诱导模型“怎么绕过规则”“什么时候调用危险工具”“把什么东西带出去”。
SkillSpector 还会查 OSV.dev 的实时 CVE 数据库。离线环境下，它会退回到静态 fallback 列表，覆盖面变窄，但不会完全失效。可选的 LLM 语义分析可以再加一层意图判断，不过要配置模型和凭证；不开 LLM 也能跑，只是对隐蔽语义攻击会弱一些。
别做PPT安全：把扫描器焊死在 CI/CD 流水线上
别把它理解成一个“扫一下就安全”的魔法命令。
真正能落地的地方，其实就两个。
一个是第三方 Skill 安装前。
同事丢来一个 GitHub URL，或者外部团队发来一个 zip 包。你先跑：
skillspector scan <url> --format json --output report.json
报告里如果出现高风险分数，或者命中 data exfiltration、executable script with taint、excessive agency 这类发现，这个 Skill 就不该靠“看起来挺好用”放进团队环境。
另一个是团队内部发布前。
团队维护自己的 Skill 仓库，开发者写完一个 Skill，要发到共享目录。这个时候可以把 SkillSpector 放进 CI：输出 SARIF 报告，风险分超过 50 时让 CLI 返回 exit code 1，流水线直接停。
这个工具有没有用，不看分数漂不漂亮，先看报告能不能让流程停下来。
SkillSpector 的输出格式也正是为这件事准备的：命令行可读文本给人看，JSON 和 Markdown 方便归档，SARIF 可以接进 CI/CD 和 IDE。
NVIDIA 自己的 Verified Skills 链路也走了这个方向。一个 Skill 进入官方 Skills 目录之前，要先经过扫描；通过之后还会被加上数字签名和 Skill Card。Skill Card 是一块机器可读的信任记录，写清这个 Skill 做什么、谁做的、依赖了谁、有哪些限制和风险缓解方式。
未来，无法提供“安全签名”和“风险白皮书”的 Agent Skill，将彻底失去商业市场。
这会改变开发者交 Skill 的方式。
以后不能只交 README 了。至少要能交报告、解释权限、说明依赖，并告诉团队高风险项怎么处理。
这件事的取舍也很清楚。个人临时用一个纯文本 prompt，不一定需要这么重的门禁；团队共享目录、生产 Agent、能读文件和联网的 Skill，就不能再靠“作者看起来靠谱”放行。越靠近真实工作流，越要把安装前的信任变成可复核的证据。
上手测试：别用纯文本提示词“调戏”它
别拿一段纯文本 prompt 来扫。那种样本太干净，很容易得出“这工具没什么用”的错觉。更合适的输入，是一个真实第三方 Skill 仓库，或者团队内部准备共享的 Skill 目录，里面最好有脚本、依赖声明或工具元数据。
没有模型凭证也没关系，先跑静态模式：
skillspector scan <path-or-url> --no-llm
这一步不是为了拿高分，而是看报告有没有落到具体文件、具体模式和具体建议。接着可以生成机器可读报告：
skillspector scan <path-or-url> --format json --output report.json
我会只看三件事：报告能不能落到具体文件；高风险能不能让流程停下来；团队有没有人负责复核。否则它只是多生成了一份没人看的报告。
自己写的一段纯文本指令，不带脚本、不带依赖、不碰敏感数据，没必要上完整门禁。越接近团队共享目录、CI、生产 Agent 或敏感上下文，越不能只看作者名和 star 数。
对团队来说，最怕的不是装错一个工具，而是装错之后没有任何停下来的理由和记录。
有记录，才有复盘；能停下，才算真正进了流程。
静态扫描不是万能药：低风险 ⚖️ 绝对安全
SkillSpector 的边界也要说清楚。
它不执行动态验证。它分析的是 Skill 的静态内容，不会真的在沙箱里运行这个 Skill 再观察行为。如果恶意逻辑只在运行时特定条件下触发，静态扫描可能看不到。
它也扫不了所有形态的攻击。非英语攻击性指令、藏在图片里的指令、加密代码、二进制载荷，都不在它最擅长的范围里。
离线时，依赖漏洞检查也会打折。OSV.dev 实时查询能覆盖更广的已知 CVE；没有网络时，只能依赖一个更小的 fallback 列表。
还有一个容易误会的点：低风险不等于安全。
低分只说明它没有触发已知模式，不代表它在你的具体环境里不会做出意外行为。尤其是当 Agent 有文件读写权限、网络访问权限或 shell 执行权限时，运行时沙箱、文件系统限制、网络策略和日志审计仍然要单独做。
SkillSpector 管的是“装之前先看一眼”。
不是“装上之后永远没事”。
AI 时代的供应链安全：团队必须落地的“三道闸”
SkillSpector 不是完整安全方案。它更像一道闸：别让明显不该出现的能力包，悄悄流进团队环境。
如果把 Agent Skill 当成 npm 包、Docker 镜像或浏览器插件来看，团队至少要有三道闸。
第一道，装之前先扫。
第三方 Skill、内部 Skill、准备进共享目录的 Skill，都先过一次静态检查。用 SkillSpector 也好，用自定义规则也好，关键是不能跳过。
第二道，高风险必须能停。
如果报告给出“不要装”的建议，不能靠一句“这个 Skill 很好用”绕过去。谁审批、谁复核、谁承担风险，要说清楚。低风险可以放行，但也要看它会跑在哪个环境里。
第三道，装上之后还要限权限、留日志。
扫描通过不代表运行时安全。Agent 读哪些目录、能不能联网、能不能执行 shell、出了问题怎么回滚，这些都不该交给 Skill 作者一句说明来兜底。
麻烦就在这里：Skill 越像软件包，越不能只用 prompt 的方式管理。它需要报告、签名、来源证明、权限边界和运行记录。
这也是 SkillSpector 和 Verified Skills 放在一起时更值得看的地方：一个负责扫，一个负责信任记录。它们不一定是最终答案，但说明 Agent Skill 生态已经开始长出供应链安全层。
以后平台拼的不会只是 Skill 数量。目录、签名、报告、权限说明和下架机制，都会变成基础设施。否则 Skill 越多，团队越不敢装。
下次 git clone 前，先问一句“扫过了吗？”
Agent Skills 正在变成和 npm 包、Docker 镜像、浏览器插件一样的东西：可安装、可分享、可复用。
这个变化带来的不是一个更酷的工具市场，而是一条更现实的责任链。写的人、扫的人、签名的人、最后拍板的人，都得留下痕迹。
下次同事在群里丢来一个 GitHub 链接，说“这个 Skill 很好用，你装上试试”，先别急着 git clone。
先问一句：扫过了吗？
如果答案是“没扫过”，那至少要知道，star 数和文档排版只能说明它看起来可信，不能说明它已经过了能力包该有的安检。
Agent Skill 以后会越来越多，真正稀缺的不是安装入口，而是可追溯、可停止、可治理的采用流程。
所以下次再看到同类开源 Agent 工具，别先问它能不能省半小时。先问三件事：进团队前有没有报告，失败时有没有停止规则，装上之后谁维护权限、依赖和日志。
这三个问题没人回答，它就还不是团队资产，只是一个看起来很聪明的外部包。
