系统视角
AI 产品不是一个模型，而是一套由多层能力组成的系统
模型只负责推理和生成，真正的产品体验还取决于上下文、知识、工具、流程和治理。
AI Product Cognition
AI 产品知识地图
不是术语堆砌，而是系统判断
产品经理需要理解的不是零散名词，而是一套 AI 产品系统：模型、提示、上下文、记忆、知识增强、工具、工作流、Agent、评估、治理。 这页把 AI 产品底层结构、概念边界、方案选择和失败模式全部串起来，帮助你建立完整认知。
模型能力
上下文与记忆
知识增强
工具与工作流
Agent
评估与治理
最大误区
把所有问题都交给 Agent，把所有知识问题都交给 RAG
很多场景只需要 Prompt + 模板，或者 Workflow + Tool Use，没必要上复杂架构。
产品判断
先想任务和失败成本，再决定技术方案
方案不是越“高级”越好，而是越贴合任务、越稳定、越可控、越可经营越好。
Page Pair
配套页面：AI 商业产品经理地图
当前页解决“AI 产品系统怎么理解”，配套页解决“AI 商业产品经理如何把这些能力做成商品、增长和经营闭环”。
AI System Atlas
AI 产品底层系统地图
中心是“AI 产品系统”，外层是九个常见能力层。把它们看成一套组合系统，而不是孤立术语。
系统中心
AI 产品系统
由模型能力、输入设计、外部知识、工具执行、运行控制和治理共同组成。
- 生成与推理
- 信息注入
- 外部执行
- 多步任务
- 评估与安全
LLM / SLM / 多模态
负责推理、生成、抽取、总结，是能力引擎，不是完整产品。
Prompt 与结构化输出
决定模型如何被指令化、限制化和模板化，影响稳定性与可用性。
Context Window
模型当下可见的信息范围，影响记忆容量、检索策略和多轮体验。
Short-term / Long-term Memory
解决跨轮会话和跨任务信息保留，不等于上下文，也不等于 RAG。
RAG / Search / Grounding
把外部知识在运行时接入模型，解决事实更新和私有知识访问。
Tools / Function Calling
让模型调用外部工具、API 和系统，突破“只会说不会做”的限制。
Workflow Orchestration
用确定性流程把多个模型步骤和工具编排起来，适合稳定业务任务。
Agent / Multi-Agent
适合多步目标、动态决策和环境交互，但复杂度和不确定性明显更高。
Evals / Safety / Observability
负责质量评估、安全边界、日志监控、成本、时延和人审机制。
Concept Distinctions
最容易混淆的概念关系
真正影响产品判断的，不是是否知道这些词，而是能不能分清它们解决的到底是不是同一个问题。
上下文 ≠ 记忆
- 上下文：模型本轮推理时能看到的信息
- 记忆：跨轮、跨任务保留下来的信息
- 上下文更像“眼前桌面”
- 记忆更像“长期档案”
记忆 ≠ RAG
- 记忆解决“记住用户/任务历史”
- RAG 解决“临时访问外部知识库”
- 记忆偏个体化与持续性
- RAG 偏知识访问与事实 grounding
Workflow ≠ Agent
- Workflow 是预定义步骤，确定性强
- Agent 会自主决定下一步动作
- Workflow 更稳定、好控成本
- Agent 更灵活，但更难控结果
Tool Use ≠ Agent
- Tool Use 只是调用工具的能力
- Agent 是围绕目标进行规划、调用、修正的一套运行方式
- 会调工具，不代表就是智能体
- 很多产品只需要 Tool Use，不需要 Agent
Prompt ≠ 产品能力
- Prompt 是输入设计，不是最终产品价值
- 用户买的是结果，不是提示词本身
- 产品体验还依赖流程、知识、工具、治理
- Prompt 强不代表产品就强
模型能力 ≠ 产品可用性
- 模型能力强，不等于系统整体稳定
- 可用性取决于输出结构、数据接入、回退机制和运营承接
- 产品经理关心的是“可用且可控”
- 不是单轮演示效果有多惊艳
Layer Deep Dive
AI 产品知识模块详解
每一层都按四个问题拆开：是什么、解决什么问题、典型组件是什么、产品经理怎么判断。
1. 大模型基础
模型层决定“能推理到什么程度”，但不会自动变成好产品。
是什么
- LLM / SLM / 多模态模型
- Token、Context Window、Sampling
- Inference 与模型调用
- 基座模型 vs 行业模型
解决什么
- 生成、总结、抽取、分类、问答、初步推理
- 文本、多模态理解与输出
- 把复杂任务压缩为概率推理问题
典型组件
- 基础模型 API
- 模型路由
- 输出控制参数
- 多模型组合策略
产品判断
- 模型越强不代表产品越好
- 先看任务要求，再选模型规格和成本
- 容错率低的任务不能只靠裸模型输出
2. Prompt 与结构化输出
Prompt 是输入设计系统，不只是“写一句话问模型”。
是什么
- System / User / Assistant / Tool 角色
- 指令、约束、格式要求
- Few-shot、模板提示、输出 schema
解决什么
- 让模型尽量按目标执行
- 提升稳定性和输出结构化程度
- 减少随机发挥和偏题
典型组件
- Prompt 模板库
- 变量注入
- JSON / schema 输出
- 链式提示与重试策略
产品判断
- Prompt 能优化表现，但不能替代知识和执行系统
- 越高风险的任务，越要结构化输出和校验
3. 上下文与会话状态
上下文决定模型当前“看见什么”，直接影响准确性、成本和多轮体验。
是什么
- 上下文窗口
- 对话历史
- 会话状态与临时变量
- 上下文裁剪与压缩
解决什么
- 多轮交流连续性
- 当前任务的有效信息输入
- 减少模型脱轨和信息丢失
典型组件
- Conversation Buffer
- Summarized Context
- Session State
- Context Pruning
产品判断
- 不是把历史全塞进去就更好
- 上下文过长会抬高成本并污染注意力
4. Memory 系统
记忆解决的是“跨轮和跨任务持续知道你是谁、之前做过什么”。
是什么
- 短期记忆
- 长期记忆
- 用户偏好记忆
- 工作记忆 / 任务记忆
解决什么
- 减少重复输入
- 个性化体验
- 跨任务连续性
- 让系统逐渐“认识用户”
典型组件
- Memory Store
- Read / Write Policy
- Memory Ranking
- User Profile Layer
产品判断
- 记忆要有读写策略，否则只会越记越乱
- 高隐私场景必须谨慎处理长期记忆
5. RAG 与知识增强
RAG 不是“把知识喂给模型”，而是运行时按需检索并 grounding。
是什么
- Embedding、Chunking、Vector Search
- Hybrid Search、Rerank
- Grounding 与引用来源
解决什么
- 私有知识访问
- 事实更新
- 减少脱离资料的胡编
典型组件
- Document Pipeline
- Retriever
- Reranker
- 引用与证据展示
产品判断
- RAG 适合知识访问，不适合替代业务规则
- 低质量分块和检索会让系统看起来“像会查，但查不准”
6. Tools / Function Calling
让模型从“只会生成内容”升级为“可以调用系统执行动作”。
是什么
- Tool Use
- Function Calling
- API 调用
- 结构化参数传递
解决什么
- 查询真实数据
- 调用业务系统
- 执行操作而不只是描述操作
典型组件
- Tool Registry
- Schema Validation
- Tool Router
- Error Handling
产品判断
- 能调用工具不代表就要做 Agent
- 高价值动作必须有权限和回退机制
7. Workflow 编排
很多业务问题更适合确定性工作流，而不是完全开放的 Agent。
是什么
- 多步骤编排
- 规则驱动的执行路径
- 模型与工具的固定顺序组合
解决什么
- 提高稳定性
- 控制成本与时间
- 把复杂任务拆成可管理小步骤
典型组件
- Step Engine
- Branch Logic
- Retry / Fallback
- State Store
产品判断
- 规则清晰、目标稳定的业务，优先考虑 Workflow
- Workflow 比 Agent 更容易控成本、控质量、控风险
8. Agent 系统
Agent 适合复杂目标与动态环境，但也最容易把复杂度和不确定性带进产品。
是什么
- Planning
- Acting
- Reflection
- Multi-step / Multi-agent
解决什么
- 多步目标推进
- 动态决策
- 环境交互和任务执行
典型组件
- Planner
- Tool Executor
- Critic / Reflector
- Human-in-the-loop
产品判断
- 不是所有多步任务都值得上 Agent
- 失败成本高、路径明确的任务，优先 Workflow
9. 评估、监控与安全治理
没有 Evals、日志和安全边界的 AI 产品，无法规模化经营。
是什么
- Evals
- Task Success
- Latency / Cost
- Safety / Guardrails / Observability
解决什么
- 知道系统好不好
- 知道失败在哪
- 知道成本是否可接受
- 知道风险是否可控
典型组件
- Offline / Online Evals
- Trace Logs
- Human Review Queue
- Safety Filters
产品判断
- AI 产品的优化不是靠感觉，而是靠 Evals + Observability
- 没有治理层，增长越快风险越大
Decision Guide
产品经理最重要的 6 个方案判断题
不是知道概念就够，而是要能在实际业务里判断“这里到底该上什么，不该上什么”。
什么时候只需要 Prompt + 模板
- 任务边界清晰
- 输入格式相对稳定
- 结果主要是内容生成或改写
- 不需要真实外部知识和复杂执行
什么时候需要 RAG
- 要访问不断变化的知识
- 要引用私有文档、知识库或规则
- 用户关心事实性和来源依据
- 仅靠训练或记忆无法覆盖最新内容
什么时候需要 Memory
- 用户会持续使用同一个系统
- 系统需要记住偏好、历史状态和上下文延续
- 重复输入成本太高
- 个性化和长期关系很重要
什么时候优先 Workflow
- 业务路径明确且可拆步骤
- 错误成本较高
- 需要稳定性、低成本和可解释性
- 每一步都有固定输入输出
什么时候才值得上 Agent
- 任务有明确目标但路径不固定
- 需要多步决策和环境交互
- 工具多、状态多、步骤动态变化
- 业务能承受更高复杂度和调试成本
什么时候不该用 AI
- 规则非常确定且传统程序更稳定
- 高精度、零容错、强合规任务没有兜底
- 用 AI 不比规则系统更省钱或更高效
- 产品只是为了蹭热点而非提升结果
Evaluation & Failure Modes
AI 产品必须看的指标与常见失败模式
关键指标
Task Success Rate
First Useful Result Time
Hallucination Rate
Answer Grounding Rate
Tool Call Success
Workflow Completion
Latency
Token Cost
Retry Rate
Human Handoff Rate
Safety Trigger Rate
User Satisfaction
常见失败模式
幻觉回答
检索不到关键资料
引用资料但答非所问
记忆污染
工具调用参数错误
Agent 死循环
多步任务中途丢状态
成本过高
时延不可接受
缺少人工兜底
输出难以评估
安全边界缺失
AI Capability Ladder
AI 产品认知能力分层
Junior
初级：知道概念，会解释术语
- 知道大模型、上下文、RAG、Agent 的基本定义
- 能描述常见技术名词的表面区别
- 对 AI 产品有直觉，但无法稳定做方案判断
Mid
中级：能做方案选择和边界判断
- 知道什么时候用 Prompt，什么时候用 RAG 或 Workflow
- 能识别场景边界、成本问题和失败风险
- 能和技术一起定义一个靠谱的 AI 产品方案
Senior
高级：能把 AI 系统做成稳定产品
- 能综合模型、知识、工具、治理和业务目标做系统设计
- 能平衡质量、时延、成本、风险和商业目标
- 能让 AI 能力长期可用、可评估、可经营
Learning Order
AI 产品知识的正确学习顺序
先理解系统层，再学概念边界，再做方案判断，最后才谈复杂架构。
先学模型与交互层
先搞懂模型能做什么、不能做什么，以及 Prompt 和结构化输出如何影响结果。
再学上下文、记忆和 RAG
先分清上下文、记忆、知识增强各自解决的问题，再做知识型产品。
再学工具、Workflow、Agent
先掌握稳定可控的执行系统，再理解 Agent 为什么强、也为什么容易失控。
最后学评估和治理
没有评估、日志、成本和安全视角，AI 产品永远只能停留在 Demo 阶段。