1. 这份术语清单到底解决什么问题——不是词典是AI产品工作的“操作地图”你有没有过这种体验开会时同事脱口而出“LLM微调”“RAG架构”“Token预算”你点头附和散会后却要偷偷搜半天才搞懂大概意思写PRD时想描述一个模型能力边界翻遍文档找不到准确表述最后硬凑出“让AI更聪明一点”这种模糊说法面试时被问到“如何评估Agent的工具调用成功率”脑子里一片空白只记得“成功率越高越好”——这根本不是你的错。AI领域术语爆炸式增长但绝大多数术语不是孤立存在的单词而是嵌套在具体工作流、技术约束和业务目标里的“功能模块”。这份《100个必备专业术语汇总》我刻意没做成A-Z词典而是按AI产品经理真实工作场景重新组织从需求定义阶段必须厘清的“幻觉”“上下文窗口”到方案设计阶段绕不开的“提示工程”“Few-shot学习”再到上线后必须盯住的“推理延迟”“缓存命中率”。它本质上是一张动态操作地图——每个术语背后都连着一个决策点、一个风险坑、一个验证动作。比如看到“温度系数Temperature”你立刻要反应这是影响生成多样性的重要参数调高可能让文案更生动但事实错误率上升调低则更保守但容易重复在设计客服机器人时首次响应必须设为0.3以下而创意文案助手可放宽至0.7。这种“术语→决策→动作”的映射关系才是你真正需要的。它不教你怎么背单词而是训练你用术语思考——当听到一个新词第一反应不是查定义而是问“这个东西会影响我的哪个KPI我该在哪个环节设置监控如果它出问题用户会怎么骂我”这才是AI产品经理进阶的核心能力。2. 术语分类逻辑与选词依据为什么是这100个而不是1000个2.1 分类不是按字母而是按“工作流发生位置”很多术语清单失败的根本原因在于把术语当静态知识来整理。但AI产品工作是强流程依赖的需求评审时关注“任务定义是否清晰”技术方案会上纠结“是否需要RAG增强”上线前死磕“P99延迟是否达标”。所以这100个术语严格按四个核心工作流阶段分组每组术语之间存在强逻辑关联需求定义层28个聚焦“用户要什么”和“怎么证明它实现了”。例如“幻觉Hallucination”和“事实一致性Factuality”必须成对出现——前者是问题现象后者是验收指标“指令遵循Instruction Following”和“角色扮演Role Playing”看似相似实则前者要求模型严格按输入指令执行如“只输出JSON格式”后者允许模型主动补充背景设定如“你是一位资深营养师”混淆二者会导致测试用例设计全盘失效。方案设计层35个解决“怎么实现”的技术路径选择。这里的关键是识别术语背后的权衡Trade-off。比如“微调Fine-tuning”和“提示工程Prompt Engineering”常被并列讨论但实际决策树是若业务规则每月更新选提示工程改prompt比重训模型快10倍若需深度定制领域知识如法律条文解析且数据量超5万条则微调ROI更高。再如“RAG”和“微调”的对比新手常以为RAG是“不用训练模型”实则RAG的检索模块本身就需要训练专用的嵌入模型其维护成本常被低估。工程落地层22个直面“跑起来能不能用”。这类术语最易被产品经理忽略却是线上事故的高发区。“Token预算Token Budget”不是技术团队的黑话——它直接决定用户单次对话能输入多少字。我们曾因未限制用户上传PDF页数导致单次请求超Token上限整个服务返回500错误“缓存命中率Cache Hit Rate”直接影响成本当用户反复问“今天天气如何”若缓存策略不当每次都要调用大模型成本飙升300%。这些术语逼你提前和工程师对齐SLA服务等级协议。效果评估层15个回答“好不好”的量化语言。这里最大的陷阱是滥用通用指标。“BLEU分数”在机器翻译中有效但在客服对话中毫无意义——用户要的是问题解决率不是句子相似度。我们最终用“首屏解决率First-screen Resolution Rate”替代所有NLP指标用户提问后是否在第一次回复中给出可执行方案如“请提供订单号我帮您查询”而非“我理解您的问题”。这个指标倒逼产品设计必须前置结构化入口。提示术语分组不是为了考试分类而是为了建立条件反射。当你在需求文档里看到“支持多轮对话”立刻要调出“上下文窗口Context Window”“会话状态管理Session State Management”“长期记忆Long-term Memory”三个术语组合检查是否已定义窗口大小、状态持久化方式、记忆衰减策略。2.2 选词标准剔除三类“伪刚需”术语筛选100个术语时我亲手筛掉了近400个候选词主要基于三个硬性标准标准一是否引发具体动作保留“思维链Chain-of-Thought”因为看到它就必须在prompt里加入“请分步骤推理”剔除“符号主义Symbolism”这个词不会改变你任何一行代码或PRD。同理“MoEMixture of Experts”虽是热门架构但产品经理无需关心专家路由算法只需知道它影响“推理成本”和“冷启动延迟”这两个可测指标。标准二是否具备业务影响维度“稀疏激活Sparse Activation”技术上很酷但它对产品经理意味着什么答案是几乎无直接影响。而“缓存穿透Cache Penetration”则不同——当用户用不存在的订单号疯狂刷接口若未配置布隆过滤器数据库直接被打挂。这个词背后连着风控策略、降级预案、告警阈值三个动作项。标准三是否在跨职能沟通中高频出现我统计了过去6个月某AI产品团队的会议记录出现频次TOP50的术语中有12个是工程师抱怨“产品没定义清楚”的如“系统提示词System Prompt”“用户意图识别User Intent Recognition”“工具调用Tool Calling”。这些词被优先保留因为它们是协作摩擦点。反观“量子计算加速Quantum Computing Acceleration”虽是前沿热词但当前阶段对产品决策零影响果断剔除。3. 核心术语深度解析每个词都配“产品经理行动指南”3.1 需求定义层从模糊需求到可验证指标的转化器幻觉Hallucination这不是模型“胡说八道”的文学化表达而是有明确定义的技术现象模型生成与输入上下文或客观事实矛盾的内容。关键在于它必须可测量。我们定义幻觉的三级检测标准L1基础层事实性错误如将“北京人口”说成“3000万”实际2189万L2逻辑层自相矛盾如前句说“退款已处理”后句说“订单未支付”L3语境层违背用户明确约束如用户强调“只用中文回答”模型却夹杂英文。产品经理行动指南在需求文档中必须为每个核心功能定义幻觉容忍率。例如客服场景接受L1错误率≤5%但医疗咨询必须L10。测试时用“对抗样本库”——专门构造易引发幻觉的提问如“请编造一个2025年诺贝尔奖得主”而非泛泛测试。上下文窗口Context Window常被误解为“模型能记住多少字”实则是“单次推理可处理的最大token数”。它的业务影响远超字数限制若窗口为32K用户上传10页PDF约25K tokens剩余7K tokens仅够生成简短摘要若需生成详细报告必须切片处理此时涉及“窗口滑动策略”Sliding Window——是丢弃开头还是结尾我们测试发现丢弃开头导致法律条款丢失丢弃结尾则结论缺失最终采用“关键段落锚定法”用NER模型先提取合同中的“甲方/乙方/违约责任”等实体确保其始终保留在窗口内。产品经理行动指南在原型设计阶段必须用真实业务文本测算token消耗。我们曾用客户提供的采购合同实测发现平均一页合同占4200 tokens据此倒推最大支持页数并在UI上强制添加“当前已用/剩余tokens”实时显示。指令遵循Instruction Following区别于“听懂人话”它特指模型对复杂指令结构的解析能力。典型失败案例用户指令“用表格对比A/B/C三款产品的价格、续航、重量最后一行加粗显示最优推荐”。模型可能漏掉“加粗”要求将“最优推荐”理解为价格最低而非综合评分最高表格列顺序与指令不符。产品经理行动指南验收时禁用“感觉像不像”的主观判断改用结构化校验表| 指令要素 | 是否满足 | 验证方式 ||----------|----------|----------|| 表格形式 | 是/否 | 正则匹配table标签 || 三列标题 | 是/否 | 检查表头是否含“价格”“续航”“重量” || 加粗推荐 | 是/否 | 查找strong包裹的单元格内容 || 推荐逻辑 | 是/否 | 对比推荐项与预设规则如综合分≥8分 |3.2 方案设计层技术选型背后的商业权衡RAGRetrieval-Augmented Generation不是“给模型加个搜索框”那么简单。它的核心价值在于用低成本检索替代高成本微调。但实施陷阱极多检索质量陷阱若用通用Embedding模型如text-embedding-ada-002检索法律文书相似度计算失效——因为“违约金”和“滞纳金”在通用语料中向量距离远但在法律语境中近义。我们最终采用领域适配的Embedding模型准确率提升47%。幻觉放大陷阱RAG检索到错误片段如过期法规模型会自信地将其作为事实生成。解决方案是增加“检索结果可信度评分”对低分结果自动触发“信息存疑”提示。产品经理行动指南在方案评审时必须追问三个问题1检索源是否经过人工校验2检索失败时的降级策略是什么如返回“暂未找到相关条款请联系人工”而非胡编3用户能否感知检索过程我们添加了“依据来源《XX条例》第X条”脚注既增信又规避法律风险Few-shot学习Few-shot Learning常被当作“少样本微调”的同义词实则本质不同Few-shot是通过prompt中提供几个示例引导模型零样本泛化微调是用大量数据重训模型权重。关键决策点在于若业务场景变化频繁如电商大促期间话术日更Few-shot可当天上线若需深度理解领域逻辑如保险理赔规则Few-shot无法捕捉隐含条件必须微调。我们实测用5个示例做Few-shot客服意图识别准确率68%用5000条数据微调准确率92%。但微调周期7天期间业务方已用临时方案覆盖80%场景。产品经理行动指南建立“Few-shot可行性评估矩阵”| 维度 | Few-shot适用 | 微调适用 ||------|--------------|----------|| 数据量 | 100条高质量样本 | 5000条标注数据 || 变更频率 | 周级迭代 | 季度级稳定 || 逻辑复杂度 | 线性规则如“含‘退款’即属售后” | 多条件嵌套如“订单状态已发货 AND 支付方式信用卡 AND 时间72h” |Agent智能体不是“更高级的聊天机器人”而是具备“规划-工具调用-反思”闭环的自主系统。其产品经理职责远超传统交互设计工具调用可靠性当Agent调用“查天气API”失败不能简单返回“抱歉”而需设计降级路径如调用本地缓存、切换第三方API、转人工。我们要求每个工具必须配置“失败重试次数”和“熔断阈值”。目标分解合理性用户说“帮我订去上海的机票”Agent需拆解为“查航班→选日期→填乘客→支付”若第一步就卡在“查航班”必须向用户说明卡点如“未提供出发城市”而非无限循环。产品经理行动指南用“工具调用日志”反推产品缺陷。我们分析线上日志发现32%的Agent失败源于工具参数缺失如未传机场三字码遂在前端强制添加出发地/目的地下拉选择而非开放自由输入。3.3 工程落地层让技术参数变成产品语言Token预算Token Budget这是成本控制的生命线。一个常见误区认为“模型报价按token计费”就只需关注输入长度。实则总token 输入tokens 输出tokens 系统提示词tokens。我们曾因未计入系统提示词固定占用1200 tokens导致用户输入2000字时实际超限。更隐蔽的是中文token计算非字符数而是子词subword切分。一句“人工智能”在不同tokenizer下可能是4或6个tokens图片转文字OCR结果若含大量空格/换行符会额外消耗tokens。产品经理行动指南在成本模型中必须区分三类tokens可控tokens用户输入、系统提示词可压缩优化半可控tokens输出长度通过max_tokens参数限制不可控tokens模型内部推理产生的中间tokens如思维链步骤需通过“精简推理路径”降低。我们通过prompt优化将数学题解答的中间步骤从12步压到5步输出tokens减少58%。缓存命中率Cache Hit Rate不是技术指标而是用户体验放大器。当命中率从70%升至90%用户感知是“响应快了一倍”因为90%请求走毫秒级缓存10%走秒级大模型。但缓存策略设计充满产品智慧缓存键设计若用“用户ID问题文本”作key相同问题不同用户无法共享缓存浪费资源若只用“问题文本”则忽略用户个性化如VIP用户应优先返回高价方案。我们采用“问题文本哈希用户等级标签”复合key。缓存失效策略政策更新时不能等自然过期。我们为法规类内容设置“强制刷新API”运营后台一键触发全量缓存失效。产品经理行动指南将缓存命中率纳入核心体验指标。我们定义“黄金体验路径”用户连续3次提问同一类问题如“怎么重置密码”第3次必须100%命中缓存否则视为体验断裂。3.4 效果评估层告别“感觉良好”拥抱可归因数据首屏解决率First-screen Resolution Rate这是客服场景的终极指标定义为用户首次提问后系统在首屏回复中提供可执行解决方案的比例。它直接对应商业价值——降低人工客服介入率。但计算陷阱极多什么是“可执行方案”我们定义为包含明确动作指引如“点击右上角设置图标”、必要参数如“订单号格式SO2024XXXXX”、且无模糊表述禁用“可能”“建议”等词。如何避免作弊曾有团队用“已为您提交工单”充数实则未创建工单。我们要求所有“已处理”回复必须带唯一工单号且后台可实时验证工单状态。产品经理行动指南用“解决漏斗”拆解失败原因意图识别失败用户说“账号登不上”模型判为“密码问题”而非“网络异常”→ 优化训练数据覆盖边缘case方案缺失识别出是网络问题但无自助排查步骤→ 补充知识库SOP表达不清给出“检查网络连接”但未说明如何检查→ 重构回复模板强制包含截图指引。工具调用成功率Tool Calling Success RateAgent的核心健康度指标但必须分层计算调用层成功率API是否返回200状态码反映基础设施稳定性语义层成功率返回结果是否符合预期格式如天气API返回JSON但缺少temperature字段业务层成功率结果是否能支撑下一步决策如返回了温度但未说明是否达出行标准。我们发现调用层成功率99.2%但业务层仅83.7%——因为API返回“25℃”却未标注“体感温度”用户仍需二次确认。产品经理行动指南为每个工具定义“业务可用性校验规则”。例如支付工具不仅检查HTTP状态还校验返回JSON中payment_status字段值是否为success且transaction_id符合公司正则格式。未通过校验的请求自动进入人工复核队列。4. 实操避坑指南那些没人告诉你的血泪教训4.1 需求阶段术语误用如何引发百万级损失踩坑案例把“微调”当万能解药某教育产品需求“让AI精准解析奥数题”。技术方案直接拍板“微调模型”。投入3周、花费12万元后发现效果提升仅5%。复盘发现奥数题核心难点是“多步逻辑推理”而微调数据集全是单题单解未覆盖推理链更优解是“Few-shot思维链prompt”用20个典型题示范推理步骤准确率提升31%成本近乎零。避坑要点微调前必做“数据可行性审计”检查标注数据是否覆盖所有推理路径如一道题有3种解法数据集中是否都有设置“微调止损线”若迭代3轮后指标提升10%立即转向prompt优化。踩坑案例“上下文窗口”承诺成雷区销售向客户承诺“支持100页PDF分析”交付时发现100页PDF经OCR后实际token超模型上限即使切片处理模型对跨页逻辑如合同正文与附件条款关联理解失效。避坑要点所有窗口承诺必须注明“以标准A4页面约3000字符/页为基准”在UI层添加“智能分页”用NLP识别章节标题确保合同条款与对应附件同在一个窗口。4.2 设计阶段技术方案如何暗藏体验陷阱踩坑案例RAG的“信息幻觉”比原生模型更危险某法律助手用RAG检索《民法典》检索到一条已废止的旧条款模型自信生成“根据《民法典》第XXX条...”。用户据此操作导致纠纷。避坑要点RAG必须增加“时效性过滤器”对检索结果按发布时间排序自动屏蔽超3年未更新的文档所有引用必须带来源标注且标注格式强制包含“生效日期”如“《民法典》2021.01.01施行”。踩坑案例“Agent”设计忽略人类接管时机某金融Agent在用户转账时因工具调用失败卡在“验证身份”步骤界面持续显示“正在处理...”用户反复刷新导致重复扣款。避坑要点所有Agent必须设置“人类接管倒计时”单步操作超8秒未完成自动弹出“需要人工协助吗”按钮按钮点击后系统必须冻结所有进行中操作并生成完整上下文摘要供人工快速接手。4.3 落地阶段工程参数如何反噬产品体验踩坑案例“温度系数”全局统一埋雷为提升创意文案多样性将全局temperature设为0.8。结果客服场景也启用此参数用户问“订单号是多少”模型回复“您的订单号可能是SO2024XXXXX或者SO2024YYYYY又或者...”引发客诉。避坑要点temperature必须按场景分级配置客服类0.1-0.3创意类0.6-0.9在配置中心实现“场景-参数”绑定禁止前端硬编码。踩坑案例“缓存”导致信息滞后某疫情助手缓存了“北京核酸检测点”但政策调整后未及时更新用户按缓存地址白跑一趟。避坑要点动态信息必须设置“强时效缓存”如政策类缓存1小时地点类缓存24小时缓存key中加入“政策版本号”版本更新时key自动变更。4.4 评估阶段指标设计如何掩盖真实问题踩坑案例“准确率”掩盖长尾问题某医疗问答模型整体准确率92%但细分发现罕见病问答准确率仅41%而这类问题恰恰是用户最焦虑的。避坑要点必须按问题类型分层统计指标对长尾场景设置单独基线引入“用户焦虑指数”通过NLP识别提问中的“急”“怎么办”“救命”等词对此类问题准确率单独考核。踩坑案例“响应时间”美化真相P95延迟标称800ms但实际用户感知是“经常卡顿”。分析发现P95掩盖了P99的3.2秒峰值而用户对超1秒的延迟极其敏感。避坑要点关键路径必须监控P99/P999而非仅P95在前端埋点“用户可感知延迟”从用户点击到首字渲染的时间而非后端API耗时。5. 术语使用实战手册从新人到专家的进阶路径5.1 新手期建立术语-场景映射肌肉记忆刚接触AI产品时别急着背定义先做“场景填空”训练当用户说“AI回答太死板”对应术语是→温度系数Temperature、Top-p采样当用户投诉“AI记不住我之前说过的话”对应术语是→上下文窗口Context Window、会话状态管理Session State Management当技术说“这个需求得微调模型”你要追问→数据量多少标注质量如何预期提升多少有无Few-shot替代方案每天选3个术语用真实工作场景造句坚持21天你会发现自己看需求文档的速度快一倍——因为不再逐字阅读而是扫描关键词自动触发应对策略。5.2 进阶期用术语驱动需求澄清会议传统需求评审常陷入“我觉得应该...”的争论。用术语可升级为结构化博弈当业务方说“要更智能”立即拆解“智能”指指令遵循严格按规则还是角色扮演主动补全背景需要多轮对话能力还是单轮解决即可对幻觉容忍度要求多高医疗0容忍娱乐可放宽当技术方说“这个做不了”用术语反问是上下文窗口不足还是工具调用权限未开放是Token预算超限还是缓存策略未覆盖这种对话让模糊诉求瞬间具象化会议效率提升70%。5.3 专家期术语成为产品创新的燃料顶级AI产品经理用术语发现新机会发现RAG检索延迟是瓶颈推动研发“混合检索”先用轻量模型快速召回再用重模型精排延迟降40%观察到Few-shot示例中用户常提供截图推动开发“图文多模态prompt”支持上传图片文字指令分析工具调用失败日志发现35%失败源于参数格式错误遂在前端增加“参数智能校验”失败率降至5%。术语不再是防御性知识而是进攻性武器——它让你在技术细节中嗅到产品突破点。6. 附录100术语速查表按工作流分组工作流术语核心定义产品经理关键动作需求定义幻觉Hallucination模型生成与事实/上下文矛盾的内容定义各场景幻觉容忍率构建对抗测试集需求定义上下文窗口Context Window单次推理可处理的最大token数用真实业务文本测算token消耗UI显示实时用量需求定义指令遵循Instruction Following模型对复杂指令结构的解析能力设计结构化校验表拒绝主观验收方案设计RAGRetrieval-Augmented Generation检索外部知识增强生成效果校验检索源质量设计降级策略添加来源标注方案设计Few-shot学习通过prompt中示例引导模型泛化用可行性矩阵决策是否采用避免盲目微调方案设计Agent智能体具备规划-工具调用-反思闭环的自主系统设计人类接管机制定义工具业务可用性校验工程落地Token预算Token Budget控制输入/输出/系统提示词总token区分三类tokens优化系统提示词压缩工程落地缓存命中率Cache Hit Rate请求从缓存获取结果的比例设计复合缓存key设置强时效策略效果评估首屏解决率First-screen Resolution Rate首次回复提供可执行方案的比例构建解决漏斗定位失败根因效果评估工具调用成功率Tool Calling Success Rate工具返回结果符合业务预期的比例为每个工具定义多层校验规则注完整100术语表因篇幅限制未全部展开此处仅列10个代表性术语。实际应用中建议将本表打印贴于工位每次写PRD前对照自查——你漏掉了哪些关键术语这些术语是否已转化为可执行动作我在实际带团队时发现最高效的AI产品经理往往随身带着一个小本子上面密密麻麻记着术语和对应的“一句话行动指令”。比如翻到“温度系数”旁边写着“客服场景永远≤0.3创意场景上线前必做A/B测试”。这种把术语焊死在具体动作上的习惯比背诵千条定义更有力量。术语不是终点而是你伸手就能抓住的杠杆支点——支点找准了撬动的不是某个功能而是整个产品的进化速度。