大家这两年已经被 coding agent 训练得很诚实了：模型当然越来越强，但你要是不给它足够贴身的上下文，它还是会一本正经地猜。
尤其是 .NET 这种生态，运行时、框架、CLI、调试、性能分析、诊断日志、构建链路，门道全在细节里。你让一个通用 agent 直接冲进这些场景，它不是做不到，而是经常要先踩一轮坑，才慢慢摸到正解。微软这篇新文章的价值，就在于他们终于把“团队自己怎么教 agent 干活”这件事，打包成了一个公开仓库：dotnet/skills。
真正有用的 Skill，不是多给模型几段说明书，而是把已经被验证过的工作流，变成它随手可取的默认经验。
这次放出来的，不只是几个提示词
文章先把话说得很直接。所谓 Agent Skill，本质上就是一份轻量级能力包，里面装的是某类任务的意图、上下文和配套材料，让 agent 在处理具体问题时少走弯路。
这个概念本身不新，GitHub Copilot CLI、VS Code、Claude Code 这类 coding agent 现在都在往这个方向靠。真正值得看的是，微软这次不是站在观察者位置讲趋势，而是把 .NET 团队自己内部已经在用的流程公开出来了。
他们给 dotnet/skills 的定位很清楚：不是教你怎么写一个很酷的 prompt，而是把 .NET 团队在真实工程里验证过的模式直接发布出来，让 agent 从一开始就别用“泛用开发建议”糊弄你。
这件事的味道其实挺对。因为 developer experience 里最浪费时间的，往往不是“不会”，而是“差一点就对了”。agent 给出的建议看起来八九不离十，结果关键命令不对、排查顺序不对、上下文取样不对，最后你还得自己兜底。Skill 的意义，就是把这些本来要靠反复纠错才能学会的路径，提前固化下来。
Skill 真有用吗，微软没有靠嘴硬
这篇文章里我最喜欢的一段，不是“我们支持标准”，也不是“生态在进步”，而是他们明确说了一件很朴素的事：不是上下文越多越好，也不是加了 Skill 就一定更强。
这个判断非常对。
模型最近几个月确实进步很快，三个月前还非塞不可的一堆说明，现在可能已经成了噪音。所以微软在做 Skill 时，没有默认“多加点就好”，而是给每个 Skill 跑轻量验证器（validator），拿“有 Skill”和“没 Skill”的结果做基线对比，看它到底有没有把任务做得更稳。
这套思路很像给 Skill 做单元测试。不是去证明整个智能体系统天下无敌，而是盯住一个问题：这个特定 Skill，到底有没有让目标行为变好。
这种姿势很务实。因为 Agent 场景里很多评估都带点主观性，你很难用一个绝对分数给所有工作流判生死。微软也没装得很绝对，他们承认有些结果带“口味差异”，所以重点不是追一个漂亮数字，而是不断看结果、回调、再测一轮。
这才像工程团队会做的事。不是信仰驱动，是反馈驱动。
文中还举了一个挺有意思的真实反馈。有开发者在 Discord 里说，一个 Skill 直接帮他从现有日志里找到了正确的 debug symbol，最后把问题定位到 heap corruption，而且栈轨迹还指向了 GC 代码。你可以把这理解成 Skill 最理想的价值：它未必替你收工，但它能把你从“完全没头绪”直接推到“下一步很明确”。这已经很值钱了。
重点不只是仓库，而是分发方式终于顺了
很多 Skill 生态一直有个很烦的问题：你知道这玩意儿存在，但你根本不知道去哪找，也懒得手动抄来抄去。
微软这次把 dotnet/skills 按 plugin marketplace 的方式组织，意思很简单，你不用再把一堆 SKILL.md 文件散装搬运到本地环境里，而是可以把整个仓库作为 marketplace 注册进工具里，再从里面浏览和安装需要的插件。
在 GitHub Copilot CLI 里，大概是这条路子：
/plugin marketplace add dotnet/skills
/plugin marketplace browse dotnet-agent-skills
/plugin install <plugin>@dotnet-agent-skills装好之后，agent 就能在环境里自动发现这些 Skill。你也可以显式调用，比如文章里给了一个例子：
/dotnet:analyzing-dotnet-performance这件事看起来像“安装体验优化”，其实影响很大。因为 Skill 这类东西，真正的门槛通常不是写出来，而是被看见、被装上、被愿意试用。分发入口一旦顺手，采用率会完全不一样。
文章里还提到，VS Code 也能把 https://github.com/dotnet/skills 配成 marketplace 来源，在扩展视图里浏览并安装，然后直接在 Copilot Chat 里执行对应 slash command。
这一步很关键。因为 Skill 真要进入日常工作流，最好别要求开发者切上下文、查文档、再回到工具里手敲一堆路径。能在原地发现、原地安装、原地调用，才有机会变成习惯。
微软这次的边界感，反而让我更看好它
这篇文章还有个很加分的地方：它没有摆出“官方来了，其他社区方案都可以退下了”的姿态。
微软明确说了，他们知道社区里已经有很多成熟的 Agent Skill 资源，比如 github/awesome-copilot 这类项目，对特定库和架构模式已经积累出不少价值。他们并不认为 .NET 生态最后只会剩下一个赢家通吃的 marketplace。
这个判断我基本同意。
Skill 这种东西天然适合分层存在。官方团队最适合沉淀与平台本身强相关的知识，比如 runtime、工具链、框架、诊断和性能分析；社区则更适合覆盖垂直库、具体架构、团队约定和真实项目里的细碎经验。两边不是互斥，反而应该互补。
如果官方仓库硬要什么都包，最后大概率会变胖、变慢、变含糊。现在这种边界更健康：微软先把自己最懂、最该负责的那一层做好，剩下的空间留给社区长。
他们到底想把 Skill 做成什么样
文章最后也讲了几个原则，我觉得可以浓缩成一句话：先做简单、可靠、任务导向的 Skill，不急着把一切都做成“大而全的平台能力”。
这很重要。
AI 扩展生态现在最大的诱惑，就是动不动就想把新能力堆成一个万能框架，好像只要接更多工具、更多协议、更多自动化脚本，agent 就会立刻变神。现实往往更反过来：边界没收住，复杂度先爆了。
微软这里显然吸取了不少一线经验。他们承认需要的时候会接 MCP、脚本或者 SDK 工具，但前提是 Skill 本身先足够清晰、够聚焦、能证明自己在真实任务里有效。
这个顺序很对。先把工作流讲明白，再谈工具接入；先让 agent 少犯错，再追求它会七十二变。否则最后很容易变成“工具接了很多，结果哪样都没稳”。
这件事对 .NET 开发者真正意味着什么
如果你平时已经在用 GitHub Copilot、Claude Code 或其他 coding agent，这个仓库最实际的意义，不是让你多学一个新名词，而是让你有机会直接复用 .NET 团队已经踩过坑的工作流。
尤其在这些场景里，它会很有吸引力：
- 诊断复杂错误日志，想让 agent 少走排查弯路
- 做性能分析，希望它按靠谱顺序看证据而不是胡乱猜
- 处理常见 .NET 工程任务，想让输出更贴近平台团队自己的经验
- 团队内部也准备沉淀自己的 Skill，希望先参考一个靠谱的官方样板
更重要的是，dotnet/skills 其实也在释放一个信号：官方团队已经不再把 coding agent 当成“陪聊式辅助工具”，而是把它视作一个需要工程化喂养、可验证、可分发、可迭代的工作伙伴。
这就是这篇文章真正值得看的地方。不是又多了个 GitHub 仓库，而是 .NET 团队已经开始把“如何让 agent 在这个生态里更会干活”当成正式产品面的一部分来做了。
接下来会不会好用到离谱，我先不吹。毕竟 Skill 这种东西，最后还是得看你装上之后，真遇到麻烦时它能不能把你从坑里拽出来。
但至少现在，这条路开始像回事了。
参考
- 原文: Extend your coding agent with .NET Skills — Tim Heuer / .NET Blog
- dotnet/skills — 微软公开的 .NET Agent Skills 仓库
- Agent Skills specification — Agent Skills 通用规范