摘要：让开发者可以借助 AI 助手直接访问代码仓库，读取文件内容、查看 PR 变更、理解 Issue 描述，甚至直接操作代码管理任务，比如创建 PR、合并分支、发布版本等。
Gitee 发布官方 MCP Server
，让开发者可以借助 AI 助手直接访问代码仓库，读取文件内容、查看 PR 变更、理解 Issue 描述，甚至直接操作代码管理任务，比如创建 PR、合并分支、发布版本等。简单来说，Gitee MCP Server 让 AI 不再是「代码的旁观者」，真正成为了参与软件开发过程的智能助手。
开源地址：
这个内容的出现，是因为跟人聊到底做不做 MCP Market Place 的话题，自然聊到了生态路径、应用场景、商业逻辑、技术实现、运营逻辑、投入规模、回报周期等方面，然后因为 MCP 这东西本质上很简单，我们猜测当初 Anthropic 搞定这东西的投入应该是极小的，但目前才过了几个月就已经至少在整个大模型生态里有较大的影响力了。
这时候我脑子里就出来一个层级结构，下图。为了更简洁，点到为止了：
4 层：使用者使用下一层提供的【应用】
3 层：开发者使用下一层提供的【通用开发能力】为上一层使用者提供【应用】
2 层：基于【通用标准】的能力抽象封装的【通用开发能力】
1 层：基于更底层设施抽象封装的【通用标准】
……
【应用】：直接给最终端用户的，比如英雄联盟手游。
【通用开发能力】：IDE、测试工具、代码版本管理工具、DevOps 全流程平台、服务接口调用……
【通用标准】：编程语言（本质上也是协议规范）、Git 协议、MCP 协议、HTTP 协议……
连同这个层级一起来的，是这几个想法：
本质是抽象封装的能力
得抽象封装到点上，也就是真正实际的场景需求
处于越底层越好去做抽象封装。因为越往上走需要面对越多的具体需求，所谓抽象就是抽取共性
但基于通用标准的能力去抽象封装上一层开发能力，去服务开发者再往上一层做应用，在 MCP 这儿显得很难受（其它标准先不管，这里只看 MCP）
为什么难受？
从第 2 层到第 3 层的过程中，其实有重要的分支选择：做通用，还是做垂直？做通用做到多大范围？
本质上是对于抽象的思考。
这个选择，向左是生态，向右是技术与产品，在资本市场也好，在第 3 层的受用情况也好，各有各的优势和难处，当然也各有各的回报空间。
单纯来考虑技术生态的话，可以更好地思考。
MCP 这东西，现在不好想象把它拿去抽象封装【通用开发能力】的路子，因为它受限于体系内大模型这一封闭角色的介入，更好想象的是做垂直，比如根据具体业务去只做服务器端（直观类比去做 API 服务），或者只做客户端，然后深入去发展单一场景与能力。
这样顺下来，要做通用的话，其实直观类比提供能力给开发者做 API 的场景，有一些抽象方向参考：
而如果再往底一层去思考，便利了 API 的设计、生成和管理等场景外，其实 API 背后本质是业务功能，往下一层思考也就是去便利实现业务功能的场景，又有一些抽象方向参考：
但同样地，都受限于 MCP 体系内大模型这一封闭角色的介入，拳脚施展难开。前边的类比参考一下，或许有更多突破口，只能这样了。
别再去做 MCP 服务器罗列这样的东西了！它就像“Free Public APIs，A collection of 386 Free Public APIs for Students and Developers. Tested every single day.”这种网站服务，虽然做精也有得玩，但在资本市场，在开发者使用市场，在技术生态中不值一提。
最后一句话，一并共勉之（话题更大一些，本文就不扯远了）：
当下火热的 MCP 协议不过是开发者服务领域的又一个缩影。你想做非顶层应用，你想做通用，残酷性在于：成功者必须同时具备哲学家的抽象能力、经济学家的生态思维，以及革命者的颠覆勇气。
来源：opendotnet