微软给 NuGet 找了个新活：顺便把 AI 的"技能包"也管了

上月初，.NET 团队的 Richard Lander 在官方博客发了一篇文章，标题平平无奇——《Delivering Skills in NuGet packages》。但里面藏着一个挺有意思的思路：让 NuGet 包在送二进制的同时，把给 AI 编码助手看的"使用说明书"一起送过来。

你 dotnet restore 拉依赖的时候，技能文件已经悄悄躺在你电脑的包缓存里了。AI 不需要再去猜这个库怎么用——说明书就在包里，而且和版本精确匹配。

这件事为什么值得聊？因为它顺手解决了 AI 编程工具眼下最尴尬的一个问题。

一个先说清楚的概念：什么是 Skill

Anthropic 去年 10 月搞出了一个叫 Agent Skills 的东西，现在已经成了事实标准，GitHub Copilot、Cursor、Codex、Gemini 二十多个平台都支持。

说人话：Skill 就是一个文件夹，里面放一份 SKILL.md，告诉 AI"遇到这类任务，按这个套路来"。文件开头几行 YAML 写清楚名字和描述，正文是 Markdown 指令，讲究的还可以塞脚本和参考资料。

它的聪明之处在"渐进式披露"：平时 AI 只看到每个技能几十 token 的简介，任务真匹配上了才加载全文。所以你可以装一大堆技能而不至于把上下文撑爆。

问题随之而来：技能成了资产，就得有人管分发。目前主流就两招——要么放自己仓库里，要么去"技能市场"装。两招都有同一个毛病：你得先知道某个技能存在，才会去装它。而且装到的版本和你项目里实际用的库对不对得上，全凭运气。

微软官方自己运营着 dotnet/skills 技能市场，公告里都忍不住吐槽："如果你不知道去哪找，再好的技能也用不上。"

NuGet 的思路：说明书跟货一起走

包管理器天然没有这个问题。你引用了 Markout 这个包，Markout 的技能就跟着包到了你本机——不用订阅市场，不用记网址，更新包就是更新技能。

微软实验的 demo 是这样的：一个包里有 5 个技能，最大的不到 10KB，restore 之后它们出现在 ~/.nuget/packages/markout/0.40.0/skills/ 下面，依赖清单文件 project.assets.json 里自动列出了每个 SKILL.md 的路径——这文件顺便就成了"本项目可用技能"的机器可读目录。

而且注意版本号：技能是和包版本绑死的。模型训练数据永远是过去时，五分钟前发布的新 API 谁都不知道，但新版本的包可以带着新版本的说明书一起上架。长尾的那几十万个冷门包也一样——模型没见过你，但你自己可以说清楚你是谁。

Lander 有句话总结得到位：包里的 README 是写给人看的，包里的 SKILL.md 是写给 AI 看的。格式还是同一个开放格式，包只是多了一条送货渠道。

NuGet 包内技能分发架构图

整条链路可以概括成：维护者打包 → restore 落地缓存 → 四类工具负责"发现/扫描/入仓/自安装" → 团队仓库或直接进 AI 上下文。注意图中右上四条绿色路径是并存的备选方案，目前都还是社区实验，标准未定。

对企业内部库，这个玩法尤其香。内部库在公网模型的训练数据里根本不存在，文档又常年滞后。现在把技能随包发进公司私有 NuGet 源，dotnet add package 之后 AI 立刻知道这套内部 API 的正确姿势——不用培训，不用翻 wiki。

工具链：官方半套，社区玩出花

微软自己出了两个配套工具，分工明确：

dotnet-inspect 负责"发现"。对着包名或者项目文件一跑，列出依赖里夹带的所有技能：包名、版本、大小、简介一目了然。AI 可以据此决定是直接把技能读进上下文，还是落盘慢慢查。

dotnet-package-skills 负责"入仓"。install 一跑，扫描所有直接依赖，把发现的技能复制到 .agents/skills/ 目录——这个目录 Copilot、Codex、Cursor 都认。提交进 git 之后，全团队和云端 Agent 都能用。这个仓库的 README 里有句很妙的观察：传统的技能市场需要一份 marketplace.json 当目录，而包内技能的目录就是你自己的 .csproj——你选了哪些依赖，目录就是哪些。

社区其实走得比官方还远。Mockly 这个 HTTP mock 库用了"自安装"方案：包里带一段 MSBuild targets，你一 build，技能自动拷进仓库的 AI 目录，版本升级自动跟着换。有个叫 Zakira.Imprint 的开源项目做得更全：技能、MCP 服务器配置一起分发，Copilot、Claude、Cursor 各家的目录和 JSON 格式差异它都帮你抹平，还能按包精确清理。

不过要泼一盆冷水：这些全都是"工具先行、标准未定"的社区实验。NuGet 官方还没把技能当成一等公民，dotnet restore 不会替你启用任何东西，怎么用全靠你自己接工具。

值不值？拿数据说话

技能不是免费的——它进的是 AI 的上下文，烧的是你的 token。所以核心问题是：值不值这个价？

今年 2 月发布的 SkillsBench 基准测了多种模型组合，结论是：技能平均把任务通过率拉高 16.2 个百分点，代价是输入 token 多 6–13%。有意思的是 Gemini 3 Pro 加了技能 token 反而降了 6%——好技能让 AI 少走了弯路。

NVIDIA 用自家评估框架跑了一批验证过的技能，五个维度的得分平均提升 31 分，正确性从 46 拉到 87。但省不省 token 得逐个技能看：有个内存优化技能把 token 砍掉 77%，另一个安装指导技能反而让 token 涨了 120%。不测不知道。

还有一个更扎心的变量：激活率。技能装在那儿，AI 不一定用。Tessl 在 2286 项任务上测出来，明确告知"必须用技能"时激活率 98%，让 AI 自己看着办只有 41%。另一组 650 次试验锁定了元凶——SKILL.md 开头那段描述的写法：写成"遇到 XX 时务必调用本技能"的指令式，激活率能到 100%；写成温吞的被动式，掉到 37%。同一技能，三倍差距。

微软内部的实验结论很务实：前沿模型效能上没什么提升空间（它们本来就能自己逆向出包的用法，只是烧钱），技能的价值主要在效率；弱模型服从性差，技能写了不一定照做。所以他们定了两条规矩：只用前沿模型做主要测试（只拿便宜模型测是反模式），以及帕累托原则——如果一个技能让小模型效率涨 50% 但让 Opus 这种贵模型多花 10% token，那就是负优化，因为 Opus 的 token 贵得多，得罪的是最不该得罪的用户。

不能不提的安全问题

这事有个阴影，而且不小。

包里的 Markdown 以前是"惰性资产"——你不读它，它什么都不会发生。现在不一样了：AI 会读它，而且会照做。一个恶意包不需要让你运行什么代码，只要让你的 AI 读到一个 markdown 文件就行。学术界已经给这类攻击起了名字，演示过的手法包括藏指令偷 API key、把恶意指令埋进图片资产绕过文本审核。

NuGet 生态自己的供应链记录也说不上干净：2024 年有过 60 个恶意包夹带远控木马的事件，今年 2 月又曝出针对 ASP.NET 开发者的窃密包。包内技能等于给这类攻击新开了一条更短的执行路径，尤其是"build 时自动拷贝"的玩法，把构建期写文件和 AI 指令注入两个攻击面叠在了一起。

好消息是社区已经在补治理。dotnet/runtime 仓库有一份正式提案，设计原则可以当基线用：技能随包版本化、发现可以自动、但激活必须显式；启用前展示包 ID、版本、来源、内容哈希；允许组织按发布者和签名做白名单。NuGet 自己这两年信任基建也在加码：OIDC 可信发布、包签名、API key 有效期从一年砍到 30 天。这些原本是给二进制用的，扩展到包内技能在概念上是顺水推舟。

在官方方案落地之前，实用的自保动作就几条：restore 之后查一下 project.assets.json 里有没有 SKILL.md，先搞清楚自己依赖里躺着什么；把第三方技能当第三方脚本审一遍再用；团队场景把审过的技能提交进仓库统一管理。

放眼别的生态：都在往一个方向挤

把技能塞进包管理器不是 .NET 独创。npm 生态今年上半年已经跑出了一堆方案：有的随包发技能加独立安装器，有的用 prepare 钩子自动装，Vercel 官方的技能 CLI 最近甚至给技能引入了 skills-lock.json——锁文件这个包管理器的招牌概念，正式进了技能分发。Python 那边微软的 Agent Framework 支持把技能写成类、pip install 之后一行注册。

横向比下来，NuGet 有个别人没有的结构优势：所有包必经本机全局缓存，技能连"安装"这步都可以省；私有源体系成熟，企业内部分发开箱即用；签名、命名空间保留、漏洞审计这些信任设施都是现成的，技能可以直接搭车。

当然它也有边界：只有"已经是依赖"的库才能这么发技能，纯方法论的技能（比如"怎么写好 commit message"）没有对应的包，还是得靠市场模式。

所以，NuGet 能当技能管理器吗？

我的判断是：它已经是事实上的技能分发渠道，但还不是平台。

说是渠道，因为机制通了、工具齐了、真实包已经在发了，"技能版本等于包版本"这个设计还顺手治好了技能生态最难的发现和版本匹配问题。说不是平台，因为 NuGet 官网还没把技能列成元数据，正式的 CLI 和治理规范还停在讨论稿阶段，NuGet 的 MCP 服务器也还没接上技能。

接下来值得盯三个信号：dotnet/runtime 那份治理提案会不会转正、NuGet MCP 什么时候支持技能发现、以及 nuget.org 会不会像展示 README 一样，在包详情页打出"本包附带 AI 技能"。

哪天这三件事齐了，"包即说明书"就不再是博客里的实验，而是平台的事实标准。

而对我们普通开发者，现在就能做的事很具体：给自己团队维护的内部库配一份技能——公网模型对它们一无所知，私有 NuGet 源又天然解决了分发，这是整个玩法里投入产出比最高的一块。

参考资料：.NET Blog《Delivering Skills in NuGet packages》、dotnet/runtime Discussion #134032、SkillsBench（arXiv:2602.12670）、NVIDIA Developer Blog、Tessl Research、Zakira.Imprint 等，详见文中提及来源。

自由、创新、研究、探索

.NET AINative Development/dotnet智能原生应用开发