Microsoft 開源 174 個 AI 編碼技能

Microsoft 開源了 174 個 AI 編碼技能，讓 agent 在寫 Azure SDK 和 Foundry 程式時，先載入對的專案脈絡再動手。

說真的，這東西蠻實際。不是再塞一個萬能 prompt，而是把任務拆細。你可以直接用 microsoft/skills 這個 GitHub repo，讓 AI coding agent 先吃進對的規則，再開始產 code。

目前 repo 裡面已經有 174 個 skills。還有可安裝模板、AGENTS.md 範本，和 MCP 設定。對開發者來說，意思很簡單。少一點猜測，多一點上下文。

Microsoft 到底在賣什麼

這個 repo 不是只丟一堆 prompt 給你。它把 skills、plugins、角色型 agents、Agents.md 範本，還有 MCP server 設定都包進來。講白了，就是要讓 agent 直接進入工作狀態，不要每次都從零猜。

這件事很像你請一個很會寫 code 的新同事進團隊。你不會叫他自己猜公司規範。你會先給他文件、範例、lint 規則，還有資料夾結構。Microsoft 現在就是把這套流程搬到 AI agent 身上。

而且它還有一個 skill explorer。開發者可以只裝單一 skill，不用把整包資料灌進 context。這點很重要。因為 LLM 不是記憶體無限大，Token 也不是免費的。

• 核心 skills 包含雲端架構、GitHub issue、前端審查、MCP server。
• 語言套件有 Python、.NET、TypeScript、Java、Rust。
• Foundry 相關 skills 涵蓋 projects、hosted agents、toolboxes、workflows。
• 也有治理、記憶、觀測性這類偏系統面的項目。

為什麼 Microsoft 反而叫你別全載

這裡很有意思。Microsoft 直接提醒你，不要一次載入全部 skills。因為太多會造成 context rot。翻成白話，就是注意力被稀釋，Token 被浪費，模式還會互相打架。

這種講法很誠實。很多團隊在玩 AI 工具時，都會犯一個毛病。以為上下文越多越好。結果不是。上下文太雜，模型就容易抓錯重點。你給它 174 個規則，它可能一條都沒好好吃進去。

所以最佳做法不是全開，而是按任務裝。你要做 Cosmos DB，就裝 Cosmos 相關 skill。你要做 MCP server，就用 mcp-builder。你要設計 agent 行為，就看 skill-creator 的說明。

“The patterns are already in their weights from pretraining. All you need is the right activation context to surface them.” — Microsoft, microsoft/skills README

這句話很直白。Microsoft 的意思是，模型本來就學過很多模式。缺的不是更多廢話，而是對的啟動脈絡。這也解釋了為什麼 agent 工具現在越來越像「配置問題」，而不是單純「模型大小問題」。

我覺得這方向很務實。因為對大多數團隊來說，真正卡住的不是模型不會寫，而是它寫得不夠像你們團隊。規範、框架版本、資料夾慣例，這些才是日常最煩的地方。

這個 catalog 怎麼分層

整個 catalog 分得蠻清楚。先是語言無關的核心 skills，再來是 Foundry skills，接著是 Python、.NET、TypeScript、Java、Rust 這些語言包。這種分法很像在幫 agent 做模組化安裝。

另外，repo 也放了幾組預設 MCP 設定。像是 docs、GitHub、browser automation。這表示你不用每次都自己從頭接工具。對習慣寫自動化腳本的人來說，這種現成配置省很多時間。

更有趣的是，裡面不只有單純補 code 的 skill。還有 hosted agents、agent identity、managed memory、observability、multi-agent workflows。這代表 Microsoft 把 agent 當成一個系統在看，不只是 autocomplete 的加強版。

• Foundry skills：11 個，涵蓋 projects、models、toolboxes、治理。
• Python skills：39 個，是目前最多的語言包。
• .NET skills：28 個。
• TypeScript skills：25 個。
• Java skills：25 個。
• Rust skills：7 個。

跟 Copilot、Continue、其他 agent 比，差在哪

這個 repo 很明顯是給 GitHub Copilot 這類工具準備的，尤其是 Copilot CLI 和 VS Code 場景。但它不只綁 GitHub。文件裡也提到可以分享給其他 agent 設定，像 Continue 這種本地 agent 流程也能用。

這點很重要。因為很多公司不想被單一工具綁死。今天用 Copilot，明天可能換內部 agent。若 skills 可以跨工具搬移，這套東西的價值就不只是一個 repo，而是變成可攜式知識包。

安裝流程也做得很短。npx skills add microsoft/skills 這種指令，對工程團隊來說很友善。再加上 symlink 範例，表示它有考慮多專案共享同一套技能的需求。這種細節，通常才是工具能不能落地的分水嶺。

• 對 Azure SDK 開發者：減少亂猜 API 用法。
• 對 Foundry 團隊：讓 agent 更懂平台規則。
• 對多專案團隊：可以共享技能，不用複製貼上。
• 對本地 agent：也能用同一套脈絡設定。

這跟 AI 編碼工具市場的脈絡有關

這波不是單純多一個 repo 而已。它反映的是一個很現實的趨勢。大家開始從「模型會不會寫」轉向「模型懂不懂你的專案」。這差很多。

過去很多 AI coding 工具都主打補全速度、推理能力，或是 benchmark 分數。現在越來越多團隊在意的是，能不能吃進 repo 規範、能不能接 MCP、能不能照公司寫法出 code。說白了，實戰才是重點。

這也解釋了為什麼 Microsoft 把 skills、Agents.md、MCP、Foundry 全部串在一起。它不是只想讓你寫得快，而是想讓 agent 寫得像真的在你團隊裡工作。

如果拿競品來看，Anthropic 的 Claude Code 走的是另一條路，重點放在本地工作流和終端機操作。OpenAI 的 API 路線則偏向讓你自己組裝 agent。Microsoft 這次比較像是直接提供一包官方知識底座，讓你少走冤枉路。

這對台灣開發團隊有什麼用

如果你在台灣做軟體，我覺得這類工具最實際的價值，不是炫技，而是減少溝通成本。很多團隊都有自己的框架版本、部署規則、資料命名方式。AI 如果不懂這些，寫再快也只是製造後續修 bug 的成本。

尤其是 Azure、.NET、TypeScript、Java 這幾個生態，在企業環境很常見。Microsoft 把技能拆成細項，就很適合用在內部平台團隊、SRE、雲端遷移、或是新人成長訓練。你不用每次都從頭教 agent 一次。

更現實一點，這種 repo 也會影響團隊怎麼管理知識。以前文件是給人看的。現在文件也要給 agent 看。這代表 README、範例、規範、測試，都要寫得更清楚，不然 AI 只會把模糊變成更快的模糊。

接下來可以怎麼看

目前 repo 還標示在持續更新中。Microsoft 也說會持續補技能、更新 SDK 模式、增加測試。這很正常，因為 agent 工具的壽命很吃版本管理。今天有效的 skill，明天可能就跟新版 SDK 打架。

我會建議團隊先從最常用的 1 到 3 個 skill 開始，不要一口氣全裝。先測它在你們專案裡會不會真的少出錯，再決定要不要擴大。這比把 174 個技能全丟進去實際多了。

如果你們現在也在用 AI coding assistant，我會直接問一句：你們是讓模型自己猜，還是先幫它把專案規則講清楚？這次 Microsoft 的答案很明白。先把脈絡放對，code 才比較像樣。