AI 能力地图：从模型能力到产品能力
一句话定义
AI 能力地图是把「模型能做什么」（原子能力）、「系统能把模型变成什么」（工程能力）、「产品能向用户承诺什么」（产品能力）分层组织起来的一张检索表，用于从场景反查能力组合。
为什么重要
AI 产品经理最容易犯的两类错误都源于能力认知错位：一是把模型的原子能力直接当产品卖（「我们的产品有 GPT-4」），用户却感知不到价值；二是承诺了系统层没有的能力（「它连接了我们的知识库」实际没做检索校验）。有了能力地图，立项时能准确回答「这个场景需要哪几层能力的组合、哪些我们现在就有、哪些要新建」。
前置知识
kp-001 AI 产品的定义与边界——先明确「能力」服务于概率性价值来源。
核心概念
三层地图：
- 模型原子能力：理解（分类、抽取、摘要、情感判断）、生成（文本、图像、音频、视频）、推理（多步推导、规划）、感知（语音识别、OCR、图像理解）。大语言模型（LLM，Large Language Model）以理解与生成为主，多模态模型跨文本、图像、音频统一处理。
- 系统工程能力：检索增强生成（RAG，Retrieval-Augmented Generation，先检索知识库再作答）、工具调用（Function Calling，模型决定调用外部接口）、微调（Fine-tuning，用自有数据调整模型）、模型路由（按任务难度分流到不同大小的模型）、缓存与重试、内容安全过滤。
- 产品能力：评测体系、置信度展示与降级、成本控制、反馈闭环、合规能力。模型能力同质化的今天，产品能力才是差异点。
原理与机制
地图的用法是「场景反查」：把场景拆成任务链，逐环标注所需能力，缺口即立项的工程量。以「智能客服」为例：用户提问 → 理解意图（模型理解能力）→ 检索产品文档（RAG）→ 生成答复（生成能力）→ 判断能否解决（推理）→ 不能解决则转人工（工具调用 + 降级）→ 记录对话用于改进（反馈闭环）。五层能力里有三层是工程与产品层——这解释了为什么「换更强的模型」往往不是客服产品的最优改进路径（对照 kp-005 场景驱动派的观点）。
公式或模型
不适用——本节是分类框架而非量化模型。
图示
| 层级 | 内容举例 | 谁负责 |
|---|---|---|
| 模型原子能力 | 理解、生成、推理、感知 | 模型厂商 / 自研团队 |
| 系统工程能力 | RAG、工具调用、微调、路由、缓存 | AI 平台 / 后端工程 |
| 产品能力 | 评测、降级、成本、反馈、合规 | 产品经理主导 |
实例或案例
- Perplexity：理解+生成（模型能力）+ 联网检索与来源标注（系统能力）+ 引用可核查（产品能力），三层齐备所以体验成立。
- 反例：某「AI 周报助手」只调用了模型生成能力，没有接入用户的实际工作数据（缺系统能力），生成内容空洞，上线即流失——能力地图缺环的典型。
常见误区
- 把模型能力当产品能力：模型会写代码不等于产品能交付可用的代码服务，中间隔着评测、降级、成本三层。
- 能力堆砌：不是每一环都要上大模型，规则能解决的环节用规则（见 kp-006 的「AI 杠杆检验」）。
- 忽视系统能力的成本：RAG 引入检索延迟与知识库维护成本，要计入 kp-025 的单位经济测算。
直观类比
模型能力像食材，工程能力像厨房设备与菜谱，产品能力像餐厅的服务与品控。客人评价的是整家餐厅，不是某块和牛；但再好的服务也救不了馊掉的食材——三层都要在线。
自测题
- 用户问「我们公司的年假政策是什么」，智能助手要答对，最少需要哪两层能力配合？
要点：RAG（检索内部制度文档）+ 生成（组织答案并标注来源）；仅靠模型参数记忆必然幻觉。
- 能力地图为什么把「评测体系」列为产品能力而非测试环节？
要点：因为概率性输出无法穷举测试，评测体系是持续定义「可用」的产品基础设施（见 kp-020）。
- 「模型升级了，产品自动变好」这句话错在哪？
要点：模型升级不改变系统与产品层的缺口（降级、评测、成本），甚至引入新回归，需要重跑评测（见 kp-032）。
与其他知识点的关系
kp-008 的技术路线选型本质上是决定三层能力各层「买还是建」；kp-013 讲系统层中提示词的接口化管理；kp-025 证明工程层的每次调用都有单价，能力组合越重成本越高。
延伸阅读
- "Attention Is All You Need"，Vaswani et al.，2017——Transformer 架构原始论文，现代能力地图的技术源头。
- 《AI 3.0》（Artificial Intelligence: A Guide for Thinking Humans），Melanie Mitchell——对模型真实能力边界的清醒盘点。