MVP已不足以承载AI产品的复杂性与商业预期，MCP（Minimum Commercial Product）正在成为新范式。本篇文章将从AI产品的特性出发，拆解MCP的设计逻辑、关键要素与落地路径，帮助产品经理在技术驱动与商业落地之间找到最优解。
什么是MCP？
MCP是Model Context Protocol的缩写，即模型上下文协议。
根据MCP官网的定义：
MCP 是一个开放协议，它为应用程序向 LLM 提供上下文的方式进行了标准化。你可以将 MCP 想象成 AI 应用程序的 USB-C 接口。就像 USB-C 为设备连接各种外设和配件提供了标准化的方式一样，MCP 为 AI 模型连接各种数据源和工具提供了标准化的接口。
更准确的理解：MCP是AI的工具箱
现在的大模型能够理解用户的输入，并且将用户的目标拆解成可以执行的任务。执行任务需要对应的工具。例如安排行程，需要读取日历、写入行程。这时候AI需要和日历App交互。
- 传统模式：使用API进行跨应用交互
- AI时代：使用MCP进行交互
MCP的本质：带说明书的函数
MCP为应用给AI提供的接口。我们来看对比：
普通函数（AI看不懂）
def send_email(to, subject, content):
pass
MCP函数（AI完全理解）
{
“name”: “send_email”,
“description”: “发送电子邮件给指定收件人”,
“parameters”: {
“to”: “收件人邮箱，格式：user@example.com”,
“subject”: “邮件主题，简洁概括内容”,
“content”: “邮件正文，纯文本格式”
},
“when_to_use”: “用户需要发送、回复、转发邮件时”
}
MCP就是给AI的详细工具说明书，就像工具箱的标签：
- 没标签的工具箱：一堆工具扔在里面，不知道哪个是螺丝刀，哪个是扳手
- 有标签的工具箱：每个工具都贴着”螺丝刀-拧螺丝用”、”扳手-拧螺母用，适合10mm规格”
MCP如何工作？
AI的思考过程
场景：用户说”明天去上海出差，帮我准备”
第1步：AI理解需求
“明天去上海” → 需要天气、交通信息
“出差” → 需要行程安排
“帮我准备” → 需要制定计划、提醒
第2步：AI查看工具箱
📊 get_weather
– 获取天气预报
📅 check_calendar
– 查看日程安排
✈️ search_flights
– 搜索航班
📱 set_reminder
– 设置提醒
第3步：AI读说明书选工具
看到get_weather的说明：
{
“description”: “获取指定城市天气预报”,
“when_to_use”: “用户出行规划时使用”
}
AI想：✅ 出行需要天气，选这个！
第4步：AI制定计划并执行
1. check_calendar(date=”明天”) → 下午2点有会议
2. get_weather(city=”上海”) → 下雨，16-22度
3. search_flights(arrive_before=”13:00″) → 推荐10点航班
4. set_reminder(“今晚8点”, “出差准备：雨伞、外套、10点航班”)
第5步：AI整理回复
“出差安排完成：🌧️明天上海下雨16-22度，带雨伞外套；✈️推荐10点航班12:30到达；⏰已设置提醒”
如何设计MCP？
AI不是人，它需要极其明确的指令才能做对事。设计MCP要遵循**”零歧义原则”**：
原则1：语义明确 – AI必须一眼看懂
核心问题：AI没有人类的常识，无法从模糊的名字推测功能。
想象你告诉一个外国人”去买点东西”，他完全不知道买什么。AI也是如此，function_a这种名字对它毫无意义。
人类的思考：看到process_data会想”大概是处理数据的”
AI的思考：process_data只是一串字符，不知道处理什么数据，怎么处理
正确做法：用动词+对象的格式命名
send_email
– AI知道这是”发送邮件”
get_weather_forecast
– AI知道这是”获取天气预报”
book_meeting_room
– AI知道这是”预订会议室”
原则2：功能描述具体 – 避免AI误用
核心问题：模糊的描述让AI无法判断什么时候该用这个工具。
比如”获取数据”这个描述，AI会困惑：
- 用户问“今天天气怎么样？”-这算获取数据吗？要用这个工具吗？
- 用户问“我的邮件有什么？”-这也是获取数据，要用同一个工具吗？
- 用户问“帮我查个资料”-这还是获取数据…
结果：AI要么选错工具，要么不知道选哪个。
正确做法：描述要包含”做什么”+”针对什么”+”产生什么结果”
{
“description”: “获取指定城市未来1-7天的详细天气预报，包括温度、降水、风力等信息”
}
这样AI就知道：只有涉及城市天气预报的需求才用这个工具。
原则3：参数说明详细 – 保证输入正确
核心问题：AI不知道你要什么格式的输入，经常传错参数导致工具失效。
常见错误：
- 工具要求城市名，AI传了“上海市浦东新区”（太详细）
- 工具要求日期格式“YYYY-MM-DD”，AI传了“明天”
- 工具要求数字1-7，AI传了“一周”
正确做法：像给小学生写作业要求一样详细
{
“city”: {
“type”: “string”,
“description”: “城市名称，只需要城市级别，不要区县。支持中文（北京、上海）或英文（Beijing、Shanghai）”,
“example”: [“上海”, “Beijing”, “深圳”],
“invalid_example”: [“上海市”, “浦东新区”, “北京朝阳区”]
}
}
原则4：使用场景明确 – 指导AI何时调用
核心问题：这是最关键的！AI选择工具完全依赖这个信息。
人类的判断：用户问”明天穿什么？”，人类知道这需要天气信息
AI的困惑：用户没有直接说”天气”，AI不知道要查天气
解决方案：把所有可能的使用场景都列出来
{
“when_to_use”: [
“用户直接询问天气：’今天天气怎么样？"”,
“用户询问穿衣建议：’明天穿什么？’、’要不要带伞？"”,
“用户规划出行：’明天去北京，需要准备什么？"”,
“用户关心户外活动：’明天能野餐吗？’、’适合跑步吗？"”
]
}
分类说明：
- 直接场景：明确提到功能关键词
- 间接场景：需要这个功能才能回答的问题
- 关联场景：相关但不明显的需求
原则5：返回格式清晰 – 让AI知道如何处理结果
核心问题：AI调用工具后，需要知道返回的数据意味着什么，才能正确解释给用户。
没有说明的后果：
- 工具返回数字“25”，AI不知道这是温度还是湿度
- 工具返回数组，AI不知道每个元素代表什么
- 工具返回复杂对象，AI可能只使用部分信息
正确做法：像API文档一样详细
{
“returns”: {
“type”: “object”,
“description”: “天气预报完整信息”,
“properties”: {
“current_temp”: {
“type”: “number”,
“description”: “当前温度，单位摄氏度，用于告诉用户现在的温度”
},
“forecast”: {
“type”: “array”,
“description”: “未来几天预报，每个元素包含日期、最高温、最低温、天气状况”
},
“clothing_suggestion”: {
“type”: “string”,
“description”: “基于温度和天气的穿衣建议，可以直接告诉用户”
}
}
}
}
关键点：不只说数据结构，还要说”这个数据用来干什么”，这样AI才知道如何向用户解释。
总结
MCP作为AI时代的工具接口标准，其设计核心是让AI能够准确理解和使用工具。通过遵循”零歧义原则”和五大设计原则，我们可以构建出真正适合AI使用的工具生态系统，让AI助手变得更加智能和实用。
本文由 @跹尘 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
