在开发完MCP Tool服务后，我对AI的作用有了更深的体会。MCP文档
一开始，我需要对接小智的MCP服务，对方提供了一个wss连接，要求使用ClientWebSocket进行链接。我的第一反应是用Postman测试这个WebSocket，一连上就收到了初始化请求。
当时我对MCP协议完全不了解。为了不重复造轮子，我首先考虑了微软官方的AI扩展包（或者说MCP C# SDK），不过它仍处于预览阶段。这还不是主要问题，关键是我作为服务端需要主动连接客户端，而查到的方案大多建议通过HTTP反向代理将WebSocket请求转发到HTTP API终结点。
翻阅SDK或NuGet包的文档其实非常吃力。虽然阅读文档是程序员的基本能力，但能读下去的前提是快速定位到需要的内容。
我对.NET的System.Net不算熟悉，知道WebSocket是抽象类无法直接实例化，虽然以前用过ClientWebSocket，但太久没接触，一时没想起来。奇怪的是，我第一反应不是去查文档，而是直接问了DeepSeek“如何连接wss”。它给了我示例代码，而我只从中注意到了ClientWebSocket这个类型，就继续埋头动手了。
连接成功后，我开始仔细阅读MCP官方文档。这部分内容写得清晰易懂，正是我需要的，所以读起来很顺畅。不过，把JSON对象映射成C#强类型模型是件枯燥的事，我就直接把官方结构丢给DeepSeek处理了。这让我意识到，在实际项目中，AI真正能胜任的正是这类结构化、模式化的工作。
我并不认为AI能独立完成一个完整的项目，它更擅长处理一些小的、模块化的任务。人们对它的态度常常两极分化——要么过分神化，要么过分低估。我自己其实也在这两者之间摇摆：既依赖它，又不完全信任它。当需要总结文档、提取关键结构时，我觉得它很有用；但在给出具体编码建议时，我又常常觉得不够可靠。
那么，这和写MCP服务有什么关系呢？在整个开发过程中，我一边看文档，一边向DeepSeek提问，这确实大大减少了我的思考负担。但这也引出一个必须正视的问题：一旦形成路径依赖，人就容易越来越不愿思考，什么都丢给AI做。使用AI本身是有成本的，有时候你可能花费了时间，得到的却是无意义的输出。可正因为过于依赖，即使已经耗时良久，仍不愿放弃，总想着“都问了这么多次，应该快行了”。实际上，这些时间如果用来自己思考，问题或许早就解决了。
依然是散装文本(`・ω・´)