AI 数据通道：JSON·Markdown

元认知：MCP 解决了什么问题，又制造了什么幻觉 #

Anthropic 在 2024 年 11 月发布 MCP 时，给出的定位非常明确：

“Even the most sophisticated models are constrained by their isolation from data—trapped behind information silos and legacy systems. Every new data source requires its own custom implementation, making truly connected systems difficult to scale.”

MCP 解决的是连接问题——给 AI 一条标准化的管道，让它能访问外部系统的数据。这是真问题。在 MCP 之前，每个数据源都需要定制集成，N 个客户端 × M 个数据源 = N×M 条适配代码，这是不可扩展的。MCP 把它降为 N+M——N 个客户端实现一次 MCP 协议，M 个数据源实现一次 MCP Server，任意互通。

但这里有一个被集体忽略的逻辑跳跃：连接能力 ≠ 创造能力。

USB-C 是一个伟大的协议。它统一了充电、数据传输、视频输出的接口。但你不会因为有了 USB-C 就觉得”我拥有了所有设备”——USB-C 是管道，插什么设备才决定价值。插一个 U 盘，你得到存储能力；插一个只是 LED 灯的装饰品，你得到一个亮着的灯。

MCP 同理。它是 AI 世界的 USB-C，解决了”怎么连”的问题，但没有解决”该不该连”和”连了之后做什么”的问题。而当前 MCP 生态的主流叙事，恰恰停留在”连上了”就宣告胜利——demo 里 AI 成功调用了 search_workitems，评论区一片”wow”，没有人问：这个调用，如果没有 AI，人需要几秒钟完成？

这就是 MCP 制造的幻觉：把”连接”等同于”价值”。一个 MCP Server 暴露了 194 个工具，demo 里 AI 调了 3 个，看起来很强大。但强大的是 AI 的推理能力，不是 MCP 管道本身。管道只是把水送过来，水质好不好、送来的水能不能喝，管道不负责。

根本矛盾：能连 ≠ 该连 #

所有 MCP 使用场景都可以用一个问题拷问：这个动作，如果没有 AI，人能做到吗？成本是多少？

场景没有 AI 时有 AI 后AI 增量
查 sprint 待办打开网页，3 秒调 MCP，消耗 token，5 秒负数
读工单详情点开链接，5 秒调 MCP，消耗 token，10 秒负数
早会前生成 sprint 摘要翻 5 个工单 + 3 条流水线 + 问 1 人，15 分钟AI 跑 30 秒高
流水线失败根因诊断 + 历史经验匹配读日志 + 翻历史工单 + 人工关联，1 小时AI 读日志 + 自动匹配历史，2 分钟极高

前两个场景，AI 增量是负数——你花了更多时间、更多钱，得到完全相同的结果。这不是 AI Native，这是AI 负优化：用更贵的方式做同样的事。

后两个场景，AI 增量是正数——人需要跨系统整合、关联推理、经验匹配，这些认知劳动耗时且容易遗漏，AI 能在秒级完成。这才是 AI Native。

搭积木：AI 增量价值判别框架 #

要区分真需求和伪需求，需要一个可操作的判别框架。我从第一性原理出发，给出一个三层分类法。

第一性原理：AI 增量价值公式 #

1
AI 增量价值 = (AI 后能做到的事 - AI 前能做到的事) - (AI 成本 - 人力成本)
  • 如果增量价值 ≤ 0：伪需求。AI 没有创造新能力，或新能力的成本高于它替代的人力成本。
  • 如果增量价值 > 0 但低：边界需求。AI 确实省了事，但省的是低价值劳动。
  • 如果增量价值 >> 0：真需求。AI 创造了人难以做到或成本极高才能做到的能力。

这个公式的关键在于：不是”AI 能不能做”，而是”AI 做了之后，比人做多了什么”。

三层分类法 #

所有 MCP 场景落在三层：

第一层：信息搬运（伪需求区） #

特征：AI 的角色是”替人点一下网页”。输入是查询参数，输出是系统返回的原始数据，AI 没有加工、没有推理、没有创造。

典型场景：

  • “帮我查待办” → search_workitems → 返回工单列表
  • “帮我查流水线状态” → list_pipeline_runs → 返回运行状态
  • “帮我查仓库列表” → list_repositories → 返回仓库列表

AI 增量：零。人打开网页就能做，而且更快（0 延迟 vs token 生成延迟）、更便宜（0 成本 vs token 费用）、更可靠（确定性 UI vs 概率性工具调用）。

为什么它不是真需求：信息搬运的瓶颈不在”获取”，在”理解”。你查到待办列表后，仍然需要自己读、自己判断优先级、自己决定做什么。MCP 把”查”这一步从 3 秒变成 5 秒，后面的认知劳动一点没少。

第二层：信息加工（边界需求区） #

特征：AI 的角色是”替人整合信息”。输入是多个数据源，输出是加工后的摘要、报告、分类。

典型场景：

  • “早会前给我一份 sprint 摘要，按完成/进行中/阻塞分类” → AI 调 search_workitems + list_pipeline_runs + 整合分类
  • “总结这个 MR 的评审意见” → AI 调 list_change_request_comments + 摘要
  • “这个工单的历史变更时间线” → AI 调 list_workitem_activities + 整理

AI 增量：中等。人确实能做，但耗时 10-30 分钟，AI 在秒级完成。省的是时间，不是能力。

边界在哪：信息加工的真伪分界线是”加工的复杂度”。简单分类（完成/进行中/阻塞）是边界需求——人做很快，AI 做稍快，增量有限。复杂关联推理（”这个 MR 的改动会影响哪些下游服务”）是真需求——人需要跨文件、跨模块、跨系统关联，AI 能在秒级完成人需要小时级才能做的推理。

第三层：信息创造（真需求区） #

特征：AI 的角色是”替人思考 + 判断 + 预测”。输入是原始数据 + 上下文，输出是人无法快速得出的结论、预测、方案。

典型场景：

  • “流水线失败了，告诉我根因是什么，历史上同类问题怎么修的” → AI 读日志 + 匹配历史工单 + 推理根因 + 给修复方案
  • “我接到这个工单，复述一遍我的理解，预判可能踩的坑” → AI 读工单 + 关联代码库结构 + 预判风险
  • “这个 MR 改了哪些模块，影响哪些下游服务，验收点应该是什么” → AI 读 diff + 关联依赖图 + 生成验收清单

AI 增量：极高。人需要跨系统关联、长上下文推理、经验匹配，这些是认知带宽瓶颈——人脑同时处理的信息量有限，AI 能在超大上下文里同时关联几十个变量。

为什么它是真需求：不是”更快”，而是”人做不到或成本极高才能做到”。一个资深工程师分析流水线失败根因要 1 小时，AI 在 2 分钟内完成，且能同时匹配半年内的历史工单——人脑记不住半年的工单历史，AI 能。

判别速查表 #

信号判定
工具返回的数据，人看一眼就能用伪需求——AI 只是搬运工
工具返回的数据，人需要读 5 分钟才能用边界——AI 帮你省了跳转时间
工具返回的数据，人需要跨系统关联 30 分钟才能得出结论真需求——AI 帮你做了认知劳动
没有这个 MCP 工具，人完全做不到这件事真需求——AI 创造了新能力
没有这个 MCP 工具，人打开网页 3 秒能做到伪需求——AI 负优化
工具调用的 token 成本 > 你省下的时间的时薪伪需求——经济上不成立

案例即原理：云效 MCP 的真伪剖析 #

我接入云效 MCP Server 后，实际跑了一遍 194 个工具，按上面的框架分类，结果如下：

伪需求案例：查待办 #

1
2
3
你: 帮我查 sprint 里的待办
AI: 调用 search_workitems(organizationId=xxx, category=Req, spaceId=xxx)
    → 返回 [{id: "xxx", title: "头像上传", status: "Pending"}, ...]

剖析：AI 花了 ~2000 token 调用工具 + ~500 token 格式化输出，总共 ~2500 token。按 Claude Sonnet 定价约 $0.0075。你花了 5 秒等待。结果？一个工单列表。

如果没有 AI：你打开云效网页 → 点”工作项” → 看到 sprint 待办。3 秒。0 元。

AI 增量价值 = 0 - $0.0075 - 2秒 = 负数。这是典型的伪需求。

边界需求案例：早会 sprint 摘要 #

1
2
3
4
你: 早会前给我一份 sprint 摘要，按完成/进行中/阻塞分类
AI: 调用 search_workitems(updatedAfter=yesterday)
    → 分类：完成 3 个、进行中 5 个、阻塞 2 个
    → 阻塞原因：等设计稿、等接口联调

剖析：AI 花了 ~5000 token（多次工具调用 + 整合），约 $0.015。30 秒完成。人做需要翻 10 个工单 + 判断状态 + 分类，15 分钟。

AI 增量价值 = 15分钟 × 时薪 - $0.015 = 正数。这是边界需求——省了时间，但没创造新能力。如果你时薪 100 元，省了 25 元。值得做，但不是 AI Native 的核心价值。

真需求案例：流水线失败根因诊断 + 经验沉淀 #

1
2
3
4
5
6
7
你: 流水线失败了，帮我看看
AI: 调用 list_pipeline_runs → 找到失败的 run
    调用 get_pipeline_job_run_log → 读 2000 行日志
    AI 分析：编译错误，src/avatar.js 第 47 行 undefined 变量
    AI 关联：半年内 3 个工单有同类错误，根因都是接口返回结构变更未同步
    AI 输出：根因 + 修复方案 + 历史案例链接
    AI 沉淀：create_work_item_comment 把根因写回工单

剖析：AI 花了 ~15000 token（读日志 + 推理 + 关联 + 沉淀），约 $0.045。2 分钟完成。

人做需要：读 2000 行日志（20 分钟）→ 定位错误（10 分钟）→ 翻历史工单找同类问题（30 分钟）→ 关联分析（20 分钟）→ 写复盘（10 分钟）。总计 1.5 小时。

但关键不在时间——人脑记不住半年的工单历史。即使给你无限时间，你也很难想到”半年前那个工单的根因跟这次一样”。AI 能在秒级遍历所有历史工单并匹配相似度。这是人做不到或成本极高才能做到的能力。

AI 增量价值 = 1.5小时 × 时薪 + 不可量化的经验复用价值 - $0.045 = 极高。这是真需求。

三个案例的本质差异 #

维度查待办早会摘要根因诊断
AI 做了什么搬运数据分类数据推理 + 关联 + 预测
人能做到吗能，3 秒能，15 分钟能，但需要 1.5 小时 + 记不住历史
AI 创造了什么无时间新能力
没有这个场景 AI 行不行完全行勉强行不行
判定伪需求边界真需求

核心分界线是最后一行：没有这个场景，AI 行不行？ 查待办没有 AI 完全行——网页更好用。根因诊断没有 AI 不行——人脑的上下文窗口太小，记不住半年历史。

缺陷与批判：MCP 泡沫的结构性原因 #

既然伪需求如此明显，为什么 MCP 生态里伪需求反而占主流？这不是偶然，是结构性因素驱动的。

原因一：Demo 效应——展示性压倒实用性 #

MCP 的传播路径是 demo 驱动的。一个 MCP Server 发布，标配是一条推文/一篇博客，里面是 AI 成功调用工具的录屏。录屏里最抢眼的是”AI 调用了 XXX 工具”——这个动作本身就是展示价值。

但 demo 隐藏了两个关键信息：

  1. 这个调用花了多少 token？ 录屏不会显示账单。
  2. 没有 AI，人做这个要多久？ 录屏不会做对照实验。

结果就是：展示效果最好的场景，往往是实用性最差的场景。”AI 帮我查待办”在 demo 里看起来很酷——AI 自己调用了工具、返回了数据、格式化展示了！但这个”酷”是技术展示的酷，不是实用价值的酷。真正有价值的场景（根因诊断 + 经验沉淀）反而不好做 demo——它需要长时间上下文、需要失败历史、需要复杂推理，30 秒的录屏装不下。

原因二：工具爆炸导致 AI 变笨 #

云效 MCP Server 暴露了 194 个工具。每个工具的 schema（参数名、类型、描述）占用 context，194 个工具占 30-50k token。这直接压缩了 AI 的推理空间。

实测对比：

  • 默认 194 工具全开 → AI 调用工具时经常选错、参数填错
  • 裁剪到 3 个 toolset 约 60 工具 → 推理质量明显改善
  • 只开 9 个核心工具 → 推理质量最佳

这是一个二阶效应陷阱：你为了”让 AI 能做更多事”而接入更多工具，但更多工具让 AI 变笨了，导致它做的事质量更差了。伪需求不仅浪费 token，还污染了真需求的推理质量。

解决方案是 toolsets 裁剪——但这本身就说明了一个问题：不是所有工具都值得开。如果你需要裁剪，那被裁掉的就是低价值工具，也就是伪需求工具。

原因三：供给推动而非需求拉动 #

MCP 生态目前是供给驱动的：云效做了一个 MCP Server，暴露 194 个工具，因为”能暴露的就暴露了”。不是用户说”我需要 AI 帮我诊断流水线失败”，所以做了 get_pipeline_job_run_log；而是”我们有这个 API，所以暴露成 MCP 工具”。

供给驱动的特征是：工具数量多，但工具之间的组合价值没有被设计。194 个工具里，真正有组合价值的组合（如 get_pipeline_job_run_log + search_workitems 做根因匹配）没有被显式设计成 workflow，需要用户自己发现。

需求驱动的特征相反：先问”用户最痛的认知劳动是什么”，再设计工具组合来解决。Harvey 不会暴露 194 个法律 API，它只暴露几个端到端的工作流：文档审查、案例分析、合同起草。每个工作流内部调多个 API，但用户看到的是一个完整的能力，不是一堆零件。

原因四：Token 税的隐蔽性 #

MCP 调用的成本是隐形成本：

成本类型可见性量级
工具 schema 占 context不可见30-50k token（194 工具）
单次工具调用不可见1-5k token
工具返回数据不可见2-20k token（日志、列表）
AI 推理 + 格式化可见1-3k token

一次”查待办”的显性输出可能只有 200 token，但隐形成本（schema + 调用 + 返回数据）可能有 10k token。用户只看到 200 token 的输出，觉得”很便宜”，没看到背后的 10k token 税。

长期来看，如果你每天调 50 次 MCP 工具，其中 40 次是伪需求（查待办、查状态、查列表），每天浪费的 token 可能是 400k——约 $1.2/天，$438/年。这还不算伪需求工具的 schema 污染导致的推理质量下降损失。

原因五：短期幻觉 vs 长期成本 #

MCP 伪需求能流行的根本原因是时间错配：

  • 短期：接入 MCP 的第一周，”AI 能查我的待办了”很新鲜，demo 效应带来多巴胺。这种新鲜感掩盖了成本。
  • 长期：新鲜感消退后，你发现自己每天花 $2 让 AI 做原本 0 元能做的事。而且因为工具爆炸，AI 做真需求（根因诊断）的质量也下降了。

这就是用户说的”短期可能会出现不需要应用这种幻觉”——短期看 AI 似乎能做更多事，但这个”更多”是数量的更多（能查待办、能查状态、能查列表），不是质量的更多（能做认知劳动）。长期成本不仅没有下降，反而上升了。

行动框架：砍掉伪需求，专注真需求 #

分析完为什么，给出怎么做。以下是一个可操作的行动框架，帮你在本周内砍掉 80% 的无效 MCP 场景。

步骤一：工具审计——给每个 MCP 工具贴标签 #

列出你当前接入的所有 MCP 工具，对每个工具回答三个问题：

  1. 这个工具返回的数据，人看一眼就能用吗？（是 → 伪需求标签）
  2. 没有这个工具，人能做到同样结果吗？成本是多少？（能做到且成本 < 5 分钟 → 伪需求标签）
  3. 这个工具的输出会被另一个工具消费吗？（是 → 可能是真需求，需进一步判断）

以云效 9 个核心工具为例：

工具问题1问题2问题3判定
search_workitems是能，3秒是（被 get_work_item 消费）管道工具，单独用是伪需求，组合用可能真需求
get_work_item是能，5秒是（被 AI 推理消费）管道工具，同上
list_workitem_activities是能，10秒是（被 AI 关联推理消费）管道工具，同上
list_repositories是能，3秒是（被 create_branch 消费）管道工具，同上
create_branch否（写操作）能，git 命令否边界——省了一个 git 命令
create_change_request否（写操作）能，网页提 MR否边界——省了跳转
list_pipeline_runs是能，3秒是（被 get_pipeline_job_run_log 消费）管道工具
get_pipeline_job_run_log否（2000行日志）能，但需要20分钟读是（被 AI 根因推理消费）真需求入口
create_work_item_comment否（写操作）能，网页评论否真需求出口——沉淀经验

关键发现：大部分工具单独使用是伪需求，它们的价值在于被组合进真需求工作流。search_workitems 单独用是伪需求（查待办），但作为”根因诊断 + 经验沉淀”工作流的第一步，它是真需求的管道。

步骤二：工作流重组——从工具视角切换到能力视角 #

不要问”我有哪些工具”，问”我有哪些真需求工作流”。

伪需求视角（工具驱动）：

  • 我能查待办了 ✓
  • 我能查流水线了 ✓
  • 我能查仓库了 ✓
  • 我能建分支了 ✓
  • 数量：194 个能力

真需求视角（能力驱动）：

  • 我能让 AI 诊断流水线失败根因 + 匹配历史经验（需要 list_pipeline_runs + get_pipeline_job_run_log + search_workitems + create_work_item_comment）
  • 我能让 AI 接到工单后复述理解 + 预判风险（需要 search_workitems + get_work_item + list_workitem_activities + 代码库上下文）
  • 我能让 AI 早会前生成 sprint 摘要（需要 search_workitems + list_pipeline_runs）
  • 数量：3 个真能力

3 个真能力用到的工具加起来不超过 8 个。剩下 186 个工具，要么是伪需求，要么是你这辈子都不会调的。砍掉它们，context 省 80%，推理质量提升，token 成本下降。

步骤三：toolsets 裁剪——只开真需求需要的工具 #

用 MCP 的 toolsets 参数裁剪：

1
?toolsets=code-management,project-management

实测从 194 工具裁到 60 工具，context 省 70%+，推理质量明显改善。

更激进的做法：如果你只需要 3 个真需求工作流，手动指定只开工作流涉及的 8 个工具。大多数 MCP Server 支持工具级别的裁剪。

步骤四：建立”真需求准入门槛” #

以后每当你想”让 AI 用 MCP 做某件事”时，先过这三道门：

  1. 能力门：这件事，没有 AI 人能做到吗？

    • 能且快 → 关门，伪需求
    • 能但慢 → 过门，进入下一道
    • 不能 → 过门，真需求

  2. 成本门：AI 做这件事的 token 成本 < 你省下的时间的时薪吗？

    • 否 → 伪需求（即使 AI 能做，经济上不成立）
    • 是 → 过门

  3. 质量门：AI 做的结果，质量 ≥ 人做的结果吗？

    • 否 → 伪需求（省了时间但质量下降，得不偿失）
    • 是 → 真需求

只有三道门都过，才值得用 MCP。以”查待办”为例：能力门就过不了——人 3 秒能做到。直接关门。

以”根因诊断”为例：能力门过了（人需要 1.5 小时 + 记不住历史），成本门过了（$0.045 < 1.5 小时 × 时薪），质量门过了（AI 能匹配半年历史，人做不到）。三门全过，真需求。

总结：MCP 是什么，不是什么 #

MCP 是管道。它解决了 AI 与外部系统连接的标准化问题，让 N×M 降为 N+M，这是真价值。作为协议，MCP 不是伪需求——它是必要的基础设施。

MCP 不是水源。它不创造认知价值，不替代思考，不生成洞察。把 MCP 当成”AI 能力增强器”是误判——AI 的能力来自推理，不来自连接。

当前 MCP 生态的核心问题是把管道当水源：暴露 194 个工具，demo 里 AI 调了 3 个，宣布”AI 能做更多事了”。但”能查待办”不是新能力——是更贵的旧能力。

真正的 AI Native 价值不在”连接”，在”认知”：

  • 伪需求：AI 替你点网页 → 花钱做免费的事
  • 边界需求：AI 替你省时间 → 值得做但不是核心
  • 真需求：AI 替你思考 + 关联 + 预判 → 没有 AI 就做不到

判别标准只有一个问题：这件事，没有 AI，人能做到吗？ 如果答案是”能，只是慢一点”，那它不是 AI Native，是 AI Augmented——而且可能是负优化的 Augmented。

把时间花在真需求上的方法也很简单：砍掉 80% 的工具，只留 3 个真需求工作流。工具少了，context 干净了，AI 推理质量上升了，token 成本下降了，真需求的效果更好了。这是一个正反馈循环——砍掉伪需求，真需求会变得更强。

MCP 的未来不在于暴露更多工具，而在于设计更少但更深的工作流。Harvey 不会给你 194 个法律 API，它给你 3 个端到端的能力。那才是 AI Native 该有的样子。

延伸阅读：AI Native：应用的真需求必须是原生的（AI Native 的五层架构与三大陷阱）、云效 MCP Server 接入手册（MCP 实际接入时 4 阶段工作流的真伪场景）

参考资料：

  • Anthropic, “Introducing the Model Context Protocol”, 2024-11-25
  • Sequoia Capital, “AI 50: AI Agents Move Beyond Chat”, 2025-04-10
  • Simon Willison, “Introducing the Model Context Protocol”, 2024-11-25
  • Block CTO Dhanji R. Prasanna, MCP 发布声明, 2024-11-25