很多人一接触 MCP，就会很自然地往一个方向想：既然它能接工具，那是不是以后很多事情都能自动化了？这个想法并不奇怪，但如果直接按这个逻辑往下走，通常很容易高估 MCP 的适用范围。我现在更愿意从工作流角度去看它：不是哪里都该上 MCP，而是要看它最适合接在哪些已经有明确工具入口的环节。为什么很多人会高估 MCP 的适用范围因为 MCP 的直观感受很强。一旦看到 AI 能进入浏览器、读设计稿、查某类资源，大家很容易产生一个联想：“那它是不是可以把整条流程都接过去？”但现实里，项目流程并不是每一段都适合工具化执行。有些环节本身就是高判断密度的，比如：需求取舍架构权衡业务优先级风险接受程度这些地方即使接了工具，也不代表判断会自动变容易。我认为最适合接 MCP 的几类环节我更看好的是那些本来就依赖外部工具、目标也比较明确的环节。比如：浏览器验证设计稿读取文档或资源查询某些环境和数据读取动作这类任务的共同点是：工具入口明确要执行的动作相对清晰输出结果更容易验证所以 MCP 在这里最容易产生实际价值。哪些环节我更愿意交给 Skill，而不是 MCP