你让 AI 把 Newtonsoft.Json 升到安全版，它回你一句改好了。打开 csproj 一看，版本号写成了 13.0.4，NuGet 上根本没这个版本。这种事我遇到过不止一次，而且每次都发生得很自然：模型对版本号没有真值概念，它只是在预测一串看起来合理的数字。
依赖管理恰好是 LLM 最容易翻车的角落。包名叫错一个字母、版本跳到不存在的号、PackageReference 写进了错误的 ItemGroup，这些错误都不会立刻报错。它们会安静地躺在那儿，等到 CI 或者线上才炸，而那时候你已经忘了是哪次对话改的。
nuget-manager 是 Smithery 上一个冷门得有点过分的 Skill，挂在 github/nuget-manager 下面，出自 smithery/ai 仓库，2026 年 2 月收录，归类 Productivity。页面显示累计使用 20,589、安装 18 次。安装量小到可以忽略，但它的设计思路值得单独拿出来说一嘴。
我的判断是：这东西的价值不在教 AI 用 dotnet CLI，那部分任何一个 .NET 工程师都会。它真正做的是划边界，把哪些操作绝对不许做、哪些可以破例、破例之后必须补什么，用三条规则钉死。约束型 Skill 才是 Agent 时代真正稀缺的货。
使用场景
先说它管什么。三类操作：加包、删包、改版本。前两类是纯机械劳动，dotnet add package 和 dotnet remove package 足够，Skill 的全部工作只是确保 AI 不会自作聪明去手写 XML。
dotnet add src/WebApi/WebApi.csproj package Serilog
dotnet remove src/WebApi/WebApi.csproj package Newtonsoft.Json有戏的是第三类。升级版本这件事，AI 的直觉是打开文件改字符串，人做这件事的直觉是先在 NuGet.org 上确认这个版本真的存在。Skill 把后者变成了强制步骤，两步之间隔了一整个网络请求，也正是这道请求把幻觉挡在了外面。
第二种场景是中央包管理，也就是 CPM。仓库根目录有 Directory.Packages.props 时，版本号集中在一处，各项目 csproj 里只留 PackageReference 且不带 Version。这个机制从 NuGet 6.2（.NET SDK 6.0.300）开始支持，现在几乎是多项目仓库的默认姿势。开启之后，仓库根目录多一个文件，各项目的 csproj 里版本号全部消失：
<!-- Directory.Packages.props，仓库根目录 -->
<ItemGroup>
<PackageVersion Include="Newtonsoft.Json" Version="13.0.3" />
</ItemGroup>
<!-- src/WebApi/WebApi.csproj -->
<PackageReference Include="Newtonsoft.Json" />版本只在一个地方定义，这是好事，也是事故源。AI 如果不知道这规矩，会去改 csproj 里的版本，改完发现没生效，然后转头再改一遍别的地方，最后两个文件状态不一致，谁也没法判断哪个才是真的。
第三类场景是批量。让 AI 把整个 solution 的某个包统一升到指定版本，人拿到这个活儿会先想清楚版本定义在哪一层，AI 则倾向于全局搜索替换。Skill 里那句先判断是 per-project 还是 central，堵的就是这个口子。
它不管的场景同样清楚：不查漏洞，不做过时包的批量扫描，不管 lock file，不碰还在用 packages.config 的老项目。你要的是依赖审计而不是安全修改，那得去找别的工具。
改版本这条路径上，Skill 规定死了四个动作，缺一步都不许往下走。
技术架构与设计决策
三条 Core Rules 摆得很直白：
- 加包删包绝对不许直改 .csproj / .props / Directory.Packages.props
- 只有改已存在包的版本号时允许直改
- 改版本必须走完验证、定位、修改、restore 四步
这三条不是建议，是判定条件。第二条是唯一的破例口，其余两条在任何情况下都不接受商量。这个写法的好处在于可验证：每一条都能对应到一条命令或一个文件位置，而不是靠模型自己理解什么叫小心一点。
第一条的理由比看上去硬。csproj 不是配置文件，它是 MSBuild 脚本。AI 手写 XML 时会漏掉条件属性、ItemGroup 分组、按目标框架区分的引用，漏掉的东西不会报错，只会在某些构建配置下悄悄失效。dotnet add package 走的是 NuGet 官方写入路径，它维护的状态比一个 XML 节点多得多。
第二条是个有意思的破例。为什么改版本反而允许直改？因为 dotnet add package 在 CPM 开启时的覆盖行为随 SDK 版本有差异，同一个命令在不同环境下可能改 csproj，也可能改 Directory.Packages.props，结果不确定。Skill 选择绕开这种不确定性，先定位再手写，代价是引入了一处必须被规则兜住的风险。
第三条里的第一步最见功力。验证版本存在用的是 dotnet package search 配 –exact-match 和 –format json，再用 jq 做等值筛选：
dotnet package search Newtonsoft.Json --exact-match --format json \
| jq -e '.searchResult[].packages[] | select(.version == "13.0.3")'jq 后面那个 -e 才是关键。它让没匹配到变成退出码 1，于是这一步从提示升级成闸门：命令失败，后面的编辑就不该发生。Skill 还给了 PowerShell 的等价写法，Windows 用户不用为它专门去装 jq。
这里有个它自己没说清的前提。dotnet package search 需要 .NET 8.0.2xx 及以上的 SDK，SKILL.md 只写了 .NET 8.0 SDK or later，8.0.1xx 的用户会直接撞上命令不存在。另外官方文档的 JSON 示例里字段名是 latestVersion 而不是 version，实际跑之前建议先不带 jq 打一次原始输出确认字段形状，别让闸门变成一扇永远推不开的门。
restore 作为验收门，强度其实一般。它做的是还原图解析，能抓到 NU1605 这类降级冲突和明显找不到的版本，但抓不到 API 破坏性变更。包在、版本对、编译过不去，这种结果 restore 给不出来。CPM 仓库里它还容易被 NU1507 干扰，多个包源没做 source mapping 时会刷一堆警告，真正的错误反而被淹掉。
把这几层摊开看，你会发现这个 Skill 本质上是在 Agent 和工程文件之间插了一层强制代理。
洞察与反思
用下来我最认可的一点，是它把验证版本存在前置了。大多数 Skill 的写法是告诉 AI 要小心、要确认，这种软提示在长对话里撑不过三轮。nuget-manager 把它变成一条必须执行且带退出码的命令，模型就算想跳也得先编出一段看起来通过的输出，难度高了一个量级。
第一个暗坑是验证的深度。它只查版本是否存在，不查这个版本跟你的目标框架兼不兼容，也不查依赖约束。包存在、版本合法、装上去运行时报 TypeLoadException，这条链路它完全没覆盖。正确的补法是在 restore 之后加一次 build，但 Skill 里没写。
第二个暗坑是视野太窄。dotnet list package 后面挂 –vulnerable、–deprecated、–outdated 能直接拿到官方审计结果，这些才是 .NET 团队真正高频的需求，而这个 Skill 一个都没接。它管的是修改动作的安全，不是依赖状态的健康，两件事经常被混为一谈。
第三个暗坑是回滚策略留白。规则说 restore 报错就 revert 并排查，但 revert 用什么、是 git checkout 还是手动改回原字符串，全靠模型临场发挥。在有未提交改动的工作区里，这一句很容易被理解成 git checkout .，那比改错版本号严重多了。
还有一点值得记下来：那四步流程一步都不是给 AI 用的，全是留痕动作。先证明版本真实存在，再确认版本定义写在哪一层，然后落笔改动，最后用一次 restore 把结果钉住。这种可审计性在团队场景里的价值，比自动化本身高得多，尤其当改动是 Agent 做的时候。
几条路线放在一起，差异比想象中大：
| 维度 | nuget-manager | AI 直接改 csproj | dotnet-outdated | Renovate |
|---|---|---|---|---|
| 幻觉版本防护 | 有，命令级闸门 | 无 | 无此问题 | 无此问题 |
| 写入路径 | dotnet CLI + 受控直改 | 手写 XML | 只报告不改 | 自动 PR |
| CPM 感知 | 有，显式判断 | 经常漏 | 有 | 有 |
| 漏洞/过时审计 | 无 | 无 | 有 | 有 |
| 适用对象 | 交互式改包 | 不该用 | 人工批量升级 | CI 自动流转 |
nuget-manager 和 Renovate 不是替代关系，它们守的是两个完全不同的时刻：一个守你在编辑器里随口说一句帮我升个包的瞬间，另一个守 CI 里每周定时跑的流水线。真正有意思的是左边两列的差距，同一件事，加了三条规则就从不可控变成可控，这个杠杆比任何新功能都值钱。
如果你手上的客户端已经接了 NuGet MCP Server，那 Skill 和 MCP 也不冲突。MCP 负责给能力，Skill 负责定规矩，能力和纪律本来就该分开。
资源地址
| 资源 | 链接 |
|---|---|
| Smithery 页面 | https://smithery.ai/skills/github/nuget-manager |
| 源码仓库 | https://github.com/smithery/ai |
| 安装命令 | npx skills add https://github.com/smithery/ai –skill nuget-manager |
| dotnet package search 文档 | https://learn.microsoft.com/dotnet/core/tools/dotnet-package-search |
| 中央包管理文档 | https://learn.microsoft.com/nuget/consume-packages/central-package-management |
总结
你要是 .NET 团队、仓库里开了 CPM、平时会让 AI 帮你动依赖，装上它，成本几乎为零。特别是团队里有人习惯让 Agent 一口气改十几个 csproj 的场景，这三条规则能省掉好几次事后排查。
反过来的情况也明确：想要依赖审计、想要批量升级、想要自动 PR，别指望它。它不管这些，装上只会让你误以为有人在看。
最后提醒一句时效性。Skill 生效依赖 dotnet CLI 的具体行为，而 CLI 每个大版本都在变，dotnet add package 对 CPM 的处理尤其如此。今天这套规则对得上，明年 .NET 10 时代未必。用之前花两分钟跑一遍自己环境里的命令，比相信任何 Skill 描述都靠谱。
说到底，装不装它是次要的。真正该学的是它的写法：不要告诉模型要谨慎，而是给它一条会失败的命令。前者是期望，后者是机制。