还记得第一次用大模型写代码，是在去年的夏天。那时我还把它当成“智能搜索引擎”——帮我写函数、查语法、改正错别字。但一年之后，事情完全变了。
如今我每天打开编辑器（Cursor、Claude Code、Codex Cli、Qwen Code、Trae）的第一件事，不是启动编译，而是“接入AI”。在我这里，AI已经不仅仅是对话窗口，而是一整套可调用的工具生态——MCP（Model Context Protocol）工具链。
这套体系，已经在潜移默化地改变我写代码、调试、甚至构建产品的方式。
01｜MCP工具的“进化意义”
MCP最初的设计是为了让AI能主动调用外部工具——像是给语言模型加上“手”。从数据库查询到网络请求，从绘图到测试执行，它都能在大模型的指令下完成。
但当你每天高频使用它时，你会发现MCP不只是“调用接口的标准”，而是一种AI与系统深度耦合的开发思维。
它让AI不再停留在对话框里，而是真正“接入了你的工程环境”。
02｜我高频使用的几个MCP工具
过去半年，我大概使用过几十种MCP工具，但真正留下的常用组合其实只有三个：
🧩 Playwright MCP —— 自动化测试的智能化入口
这是我最常用的一个。Playwright本身是强大的浏览器自动化框架，而Playwright MCP让AI能直接驱动它——
我只需一句话：“帮我验证登录页的验证码逻辑是否正确”，它就会自动打开浏览器、输入、截图、分析报错。
以前测试要写脚本、调试选择器；现在AI可以在上下文里推理出场景，并动态生成测试代码。这种“AI驱动自动化”不只是效率提升，更是一种人机协作的新形态：AI成为QA团队的一员。
🖼️ Replicate MCP —— 用Flux模型生成视觉素材
这类工具几乎改变了我对“设计资源”的认知。
我过去常常苦恼产品的Hero图、活动banner、icon素材——不是缺想法，而是缺执行。
Replicate MCP 连接了多个生成模型，比如Flux系列。通过AI接口，我只需要提供概念说明，它会生成风格一致的图像。
最妙的是，大模型会自动在上下文中判断尺寸比例（如1200×630）、风格方向（赛博、极简、企业蓝）等参数，几乎像一个懂产品语境的视觉设计师。
它不取代设计师，但它是我和设计之间的桥梁。
📚 Context7 —— 永远最新的产品API助手
如果说前两个是“执行型”工具，那Context7更像是一个“知识神经元”。
它可以实时访问各类官方产品API文档、开发手册、变更记录——比如我问“Cloudflare Tunnel 最近的配置参数有什么变化？”
它就能拉取官方最新说明，而不是依赖模型固化的旧知识。
这对开发者而言意义重大。我们都知道，文档更新频繁，模型知识滞后几个月甚至半年。Context7 让AI具备了“时效性”，它弥补了语言模型最大的一块短板。
03｜为什么我反而很少用 MySQL MCP
许多人喜欢用MySQL MCP做数据库查询，但我逐渐减少了使用。
原因很简单：在开发环节，大模型直接基于连接参数执行SQL往往更自然。
MCP虽然更安全、规范，但对于熟悉AI上下文编程的人来说，它反而多了一层抽象成本。
比如我想快速调表结构、验证查询逻辑，AI直接执行反应更快。MCP更适合在生产级AI代理中封装，而不是在研发阶段。
04｜一年之后的体会
这一年我最大的感受是——AI编程从“对话”变成了“协作”。
我不再把模型当作语言接口，而是当作“有工具、有上下文、有记忆”的虚拟同事。
- Playwright MCP 帮我测逻辑；
- Replicate MCP 帮我画图；
- Context7 帮我查文档；
- 其他MCP则像外包模块——随时待命。
它们构成了我的“AI开发栈”，也让我意识到一个趋势：未来的IDE，不是编辑器+插件，而是模型+工具集。
05｜结语：从“写代码”到“编排智能体”
如果说过去我们是写代码调用函数，那么现在我们是在用自然语言编排智能体。
这不只是技术演进，更是开发者角色的转变。
我们逐渐从“命令执行者”变成“智能系统的导演”。
或许十年后，MCP会像当年的HTTP或REST一样，被视作理所当然的基础设施。而我只是有幸，见证了它从实验性协议走入日常工作的那一刻。
见微知著 · TheSignalwise 
留下评论