MCP 在 Vibe 工作流中的定位与价值

讨论时间：2026-02-12

1. 核心演进路径

Vibe 实践的工具链演进方向：

旧模式：结构化文本 + skill式的规范文档
新模式：必要结构化文本 + MCP + skill式的结构化文档

引入 MCP 的核心驱动力：减少 AI 的上下文负担 和 降低文档的维护成本。

2. 核心转化链路

从 AI 到流程化产出的关键转化：

人类语义 → 结构化文本 → 确定性产出

• 结构化文本的本质价值在于消除二义性
• AI 面对自然语言指令时，输出是概率性的；面对结构化文本（JSON schema、明确参数列表、严格模板），输出的确定性显著提升
• 结构化文本对应确定的产出，这是整条链路成立的基础

3. 两类规范文档的区分

规范文档实际上包含两种本质不同的文档：

类型	职责	内容特征
构成规则文档	描述"结构化文本长什么样"	目标格式定义、API 参数、数据结构
过程约束文档	描述"AI 如何从输入到达目标格式"	转换规则、业务逻辑、流程编排

关键问题： 这两类文档在实践中经常被混写在一起（尤其在功能设计文档中），导致：

• 调整一类规则时，另一类被不必要地加载到上下文
• 文档之间缺乏显式关联，细调一个规则集会大量消耗 Token

4. MCP 的核心价值

4.1 本质定位

MCP 是对"构成规则文档"的结构化封装。 MCP 天然是一系列工具调用的文档封装。

没有 MCP 时，规范文档需要详细描述 API 的每一个参数、调用方式、返回值格式（例如描述如何制作一个 Unity Animation 动画，需要在规范文档中完整罗列 API）。引入 MCP 后，这些信息被编码进了工具本身的 schema 和 description 中，规范文档中只需告知 AI 使用对应的 MCP 工具即可。

4.2 三个维度的优势

上下文压缩：

• MCP 将 API 知识编码为工具 schema/description，对 AI 来说是"内置"的，不占用对话上下文
• 规范文档从"API 说明书"瘦身为"业务意图和流程约束"

维护成本降低：

• 底层 API 变化时，只需更新 MCP 工具，规范文档不需要联动修改
• 文档之间建立了显式的关联关系（规范文档引用 MCP 工具名，而非内联 API 细节）

关注点分离：

• MCP 层：封装"怎么做"的能力（API、工具调用、原子操作）
• 规范文档层：描述"做什么"和"为什么这么做"（业务规则、约束条件、流程编排）

4.3 不仅是文档封装，还是执行能力的封装

MCP 让 AI 从"生成指令"变成"直接执行"。传统规范文档告诉 AI 应该生成什么样的代码/配置，然后由人或其他工具去执行。MCP 让 AI 直接执行操作（如在 Unity 中创建 GameObject、修改组件属性），进一步缩短了从意图到结果的链路。

5. 实践要点

5.1 MCP 工具粒度选择

粒度	问题	适用场景
太细（每个 API 一个工具）	AI 需要自行编排大量原子调用，过程约束文档反而变复杂	极少
太粗（一个工具完成整个功能）	灵活性不足，难以复用	极少
适中（一个有意义的操作单元）	既不是裸 API，也不是完整业务流程	推荐

5.2 MCP 与规范文档的边界

知识类型	归属
确定性的、不随业务变化的知识	封装进 MCP 工具
与业务上下文相关的、可能灵活调整的规则	留在规范文档中

必要时可以在规范文档中为 MCP 工具附加介绍和底层原理说明，但应保持精简。

6. 总结

MCP 在 Vibe 工作流中的核心定位：

将规范文档中关于"结构化文本构成规则"的部分提取出来，封装为可直接调用的工具，从而让规范文档回归到其本质职责 — 描述业务意图和过程约束。

这套体系的分层架构：

人类语义（自然语言意图）
    ↓ [过程约束文档] 指导转换
结构化文本（明确的参数/指令）
    ↓ [MCP 工具] 封装执行能力
确定性产出（代码/资源/配置）