产品经理重用户体验的要求早已稀松平常，今天来聊聊策略设计。
为什么要单独开一篇文章介绍？
一方面是现今产品同质化严重，同个领域的产品无论是产品核心流程、设计结构还是视觉风格，都殊途同归；另一方面，AI硬科技的浪潮下，仅从产品的外观表现你很难真正了解一款产品，产品的差异不再是多么花哨的视觉和别出心裁的交互体验，更多的是底层策略的高下之分。回到今天的话题，我的论断是：大模型产品百花齐放的时代，产品策略的建设变得比过去更稀缺、更核心。究其原因，主要有以下几点：首先是大模型产品的泛化能力，不再是即插即用，而要看你如何将特定的能力封装成产品功能。这近似是一个条件优化的问题：基于当前的大模型能力，找到一个最能产出价值的业务场景，选一个刚需、可控又能衡量ROI的点，先把这个点打穿。这个转化过程强依赖产品经理定义适用场景和约束边界；其次是成本敏感的特征，不像传统软件服务的边际成本趋近于0，模型的每次推理都有显著成本，产品经理得在调用频率、外围工程、用户路径之间做资源的权衡。比如，你可以定义一些工程手段，把大模型变得尽量稳定，例如加入一些规则引擎、知识图谱、RAG、提示词模板、审核和兜底机制等，确保大模型的输出是成本可控且体验稳定的。最后是反馈的不确定。即便你应用场景找对了，工程手段也上了，但产品的输出效果非线性，缺乏闭环的反馈机制，也纯粹只是静态试验品。真实用户的使用数据、问题记录和满意度反馈，得作为迭代优化的依据。你需要设计闭环反馈和能力评估机制，这些都属于策略性的工作。

当需求场景已经明确，用户体验和产品策略的设计都应该齐头并进。如果说，用户体验设计就像是在搭房子，比如设计房间布局、功能、装修风格；那么产品策略设计就是在建设水电气暖，让整个房子合理运转且节能高效。二者缺一不可。

1. 策略产品：从业务出发，用数据驱动

先来介绍下策略产品。

策略产品的本质是：基于数据和业务洞察，制定科学的产品策略，并通过数据体系、算法策略和能力封装，将这些策略落地为具体可执行的产品功能。

划重点：一个是从业务出发，一个是用数据驱动。

图1:策略产品的核心工作内容

举个例子，你在负责电商平台“猜你喜欢”的推荐策略优化，该模块的推荐点击率低，用户转化不佳，影响整体 GMV。

你的工作重心绕不开以下几点：

1）从业务出发，识别策略机会：

转化率低 → 用户推荐不精准 → 用户兴趣未被满足，将该问题转化为策略问题：如何让推荐结果更贴合用户兴趣？

为此你可能需要调整推荐优先级逻辑与召回策略。你可以定义目标场景与优先级：提升首页推荐点击率 + 后续转化率 → 优先攻关“高活跃用户 + 高客单价商品”场景。

2）以数据为驱动，设计底层数据体系：

• 输入数据：用户画像（性别、年龄、消费偏好）、浏览行为（近期点击、停留时长）、商品特征（品类、价格、促销力度）；
• 输出指标：推荐点击率（CTR）、推荐转化率（CVR）、单位推荐位 GMV 贡献；

在此基础上，你可以跟数据团队协作，补充用户兴趣标签字段，建立“推荐行为-转化”的映射关系，完善数据埋点。

3）策略模型与算法联动：

接着上一步，你将用户兴趣标签作为算法的输入，用以召回商品，再对模型打分排序。同时你需要与算法团队共建：优先召回近期互动频繁品类，去做个性化的加权，比如用户的历史消费金额*点击偏好。

4）制定产品方案，包括策略逻辑、交互设计和后台配置能力：

• 策略逻辑说明：比如，“猜你喜欢”优先展示用户最近3次浏览品类下的高转化商品；
• 交互设计：推荐位样式不变，后台策略调整，确保用户在交互时无感知；
• 后台配置能力：将数据指标经由数仓计算后落库，再通过策略运营平台下发，形成圈选用户的下发策略。

5）策略协同与冲突解决：

多条策略难免会遇到冲突场景。比如，首页也有“限时促销”推荐，两个模块都想抢流量位。

这种情况并不罕见，此时你需要定义策略之间的协同机制，设计优先级配置系统，根据用户画像动态分配推荐位。比如，高消费用户优先“猜你喜欢”，低消费用户优先“促销”，让所有推荐策略进入统一的策略运营平台，方便后续持续优化。

这是产品经理在策略建设中的 “数据-策略-算法-产品-业务”的工作闭环。

同理，产品经理在AI产品的策略设计中，也需要将业务场景转化为可落地的模型策略体系，包括策略设计、数据支撑、验证反馈与产品化，实现“业务目标→模型能力→产品形态”的完整链路。

2. AI 产品策略：模型能力的调优和外围工程的建设

除共性之外，说说AI 产品策略相较传统产品策略设计的核心区别。

仔细回想，原先所谓的产品策略更多是规则与数据驱动的产品设计范式，即：人制定策略规则+系统执行逻辑，比如：推荐策略、定价逻辑、排序规则、匹配机制、任务达标逻辑等。背后依赖的是：

• 结构化数据（标签、指标、用户行为等）
• 可解释的逻辑设计（if-then、权重模型、AB Test等）
• 可控可调的系统架构（策略平台、规则引擎、定时调度等）

而AI 产品改变了这套范式。

一方面，大模型引入了“能力即服务”。基座模型（如 GPT、Gemini、Claude）提供的是通用语言的理解+生成能力，系统不再依赖具体规则，而是：

• 从数据中学习模式（训练）
• 通过自然语言 prompt 驱动行为（提示）
• 通过外挂知识或模型微调提升上下文适应能力

底层范式转为：构建能力 → 套用能力 → 收集反馈 → 再强化能力。因此，算法团队需主导对基座模型进行预训练，产品经理则需要花更多精力在模型能力的调优上，比如模型微调，就是最常被考虑但最需要谨慎的行动点。

另一方面，策略设计由“显式逻辑”变成“能力配置”。传统策略的输入主要靠写规则、配权重，现在会更倾向于从设计提示词结构、配置知识库、判断模型是否微调逐层分析；而在策略的迭代调整上，传统产品以AB test为主调整策略，AI 产品依赖数据-反馈-能力多轮迭代去提升能力。

是的，当模型被训练完成后就拥有了通用和特定领域的知识和推理能力，但不一定能适配到特定的业务场景。大模型虽强，可天然是不稳定、不确定、不懂边界的，因此要围绕它建大量的工程体系来约束和监控它。

外围工程是什么？外围工程是指在不改变大模型本身参数和训练语料的前提下，通过外围能力增强模型的实用性和可靠性，从而更好地服务于垂直业务的需求。

换言之，真正把大模型从“能力”转化为“生产力”，就必须围绕它构建一套完整的工程化体系，也就是所谓的外围工程。

一般来说，外围工程主要覆盖几个方面：

• 提示工程（Prompt Engineering）：通过设计和编写提示文本，引导模型生成符合特定要求的内容；
• 知识库系统（RAG）：结合外部知识库（如企业文档、FAQ、数据库）进行检索和生成。比如，企业知识问答、IT 技术支持、财务/法律垂类助手等；
• 模型联网：顾名思义，让模型通过索引网站或搜索引擎上的内容，总结和引用后再输出内容。比如，股市信息摘要、跨境电商价格检索等；
• 插件系统/工具调用：为模型配置具备特定功能的插件，如搜索、计算、调用API等，使其具备“观察-决策-行动”的能力。背后通常集成多模态输入、外部系统接口、状态管理等能力，是当前智能体（Agent）应用的底座能力之一。

不止这些，还有上下文管理、多模型路由和策略控制、多模态输入和理解支持等，严格来说也都是工程化的一部分。

这套工程放到现在，已然成了AI 产品落地的基本盘，也是策略性工作的重点。尤其是当下的AI产品岗，无论你是服务于B端还是C端场景，几乎都会涉及到这部分职责。

图2:AI 产业上下游的分类

那么，在模型能力调优和外围工程方面，产品经理在其中的职责是什么，和算法、研发之间的分工如何，似乎都不太显性。

简言之，在大模型产品的策略设计中，产品经理不负责“怎么写代码或训练模型”，但必须负责“为什么要做、做哪些、怎么判断做得好”。

基于AI 产品最核心的三种策略手段，我们一个个来说。

2.1 提示词工程(Prompt Engineering)

提示工程是一个成本低、无需编程能力就能做策略调优的工作，产品经理更应该深入到提示工程优化里面去钻研。

很多人都解释过提示工程，这里再稍微澄清下。

提示词本质上是一种AI交互设计语言，可以直接影响输出质量，目标是通过优化输入，让大模型更好地“听懂”和“回答”。

因此，产品经理需要负责提示词的应用场景设计，规划提示词的体系，再由研发团队编写提示词的细节，从而让模型输出更符合业务预期和用户需求的结果。

听起来有点绕，简单来说：产品经理负责设计“怎么问”，算法负责“怎么算”。

相比传统的交互设计，提示词工程更像是意图层的UX设计，即：产品经理需要设计「用户意图如何被理解」+「模型如何被引导输出」的整个闭环。

如何提升提示词工程的设计能力？与其套用各种花式模板，我认为对产品经理而言，更可行的训练方式是：

• 把提示词设计流程，用 Figma + 流程图 + 表格做出来，像以前做多轮Bot对话那样设计，即：每一轮都要考虑意图触发 → 指令拆解 → 内容生成 → 格式输出；
• 建立Prompt组件库，就像你以前建立组件式UI库一样，以便快速复用到不同的Agent或场景中，降低跨部门的协作成本；
• 建议输出结构时，强约束格式，如 JSON、Markdown、表格等，就像你曾经设计标准返回格式一样。输出结构的格式化，非常便利后续的系统性ab实验，以及对失败case的分类和归因，形成可分析的 Prompt-to-Output Mapping。

本质上，这是将提示词设计上升到“产品工程化”的高度，让提示词不再只是对话玩具，或是一个唬人的心法，而是真正具备工程调用能力的接口设计。

2.2 外挂知识库

外围工程里另一个核心部分是知识库建设，本质是为了补充模型记不住、不知道、不能更新的内容。这种情况下，研发和算法团队会主导知识库的基建开发工作，产品经理负责知识库场景定义、内容策略、结构和召回规则的设计，确保系统满足落地需求。

具体职责包括：

• 明确哪些问题靠知识库，哪些靠大模型生成，可通过问题类型分类表和意图识别路由策略来实现；
• 制定知识来源标准（来源渠道、内容标准如准确性、更新时效性、安全性等）；
• 设计知识库的组织结构（FAQ型、实体型、文档型），比如实体型就是基于知识图谱或结构化数据组织的可查询实体，如酒店信息、商品数据等；
• 制定知识更新机制（静态 or 动态？由谁维护，是否需要人工审核，更新频率等）；
• 设定知识召回策略，即：模型调用知识库的时机和优先级。

举个例子，你正在做一个支持AI 智能客服的产品，模型回答一些标准问题经常答不准或产生幻觉，你判断：

• 大模型通识能力不够；
• 提示词的增强效果有限；
• 需要外挂知识库，采用RAG（Retrieval-Augmented Generation）架构。

那么，在策略考虑上，你需要主导知识库结构设计与RAG调用逻辑方案。

首先是知识库结构的整体规划，你要思考的核心问题是：

• 要注入什么知识？
• 知识以什么形式存储？
• 怎么让模型好用？

图3:知识库管理

1）知识导入：

明确知识来源，输出《知识内容源清单 & 类型归类表》。为此你要拉通业务团队、客服团队、知识库团队，确认知识结构包括：

2）知识抽取：

产品要负责设计知识颗粒度与分段策略：

• 分段太粗，可能会导致召回的信息干扰多；
• 分段太细，容易导致上下文丢失或无法覆盖完整答案。

常见的分段方式有：按文档结构分段，比如每个FAQ一段，每个操作步骤一段；按主题分段，比如按退货、丢件、配送等主题切分；按意图标签组织，比如「物流查询意图」的标准回答集合就是一段。

3）知识召回：

该过程涉及到的环节较多，其中产品经理要注意定义嵌入策略（Embedding），输出知识入库规则，再交给算法或工程团队接入到向量存储平台。

简单来说，Embedding 就是把一句话变成一串能让计算机理解的数字（向量）。当你把知识仓库搭建好，里面有大量的句子和文章，你希望将来别人来提问时，AI能准确找到相关的内容并回答。而 AI 不懂人类的语言，它只能理解数字。因此你需要把文字变成向量，以便后续的向量召回。

注意，你不需要写embedding算法，但你要确定：

• 分段内容中，哪些字段需要embedding（如正文+标题）
• 向量库结构：是否需要多模态向量？多个通道？
• 是否加索引字段用于召回过滤？

其次是RAG调用逻辑的设计，核心目标是：当用户问一句话时，该应用能召回正确的知识段，并组织成有效的prompt，让大模型生成可靠答案。

1）设计检索逻辑，明确检索规则、召回数量和过滤机制，以确保知识的召回率。

2）设计Prompt拼接策略，你要定义：召回的知识段，如何拼到prompt中？拼什么？拼几段？拼的位置是哪？

比如，知识在拼接时要讲究结构的标准化，可以定义一些格式模板。这些结构化的知识可以拼在系统提示（system prompt）中，或是用户输入后作为背景补充。

此外，拼接的内容一般都会控制长度，结合数据相关度或分类做权重排序，避免超出token限制。

3）设计回答可信机制与兜底应对策略。可能输出幻觉，因此你要定义：

• 当召回失败时：输出「抱歉我没找到相关信息」or 其他兜底和引导话术；
• 当召回信息过多时：提示用户细化或进一步明确问题；
• 输出结果是否附带“参考信息”字段提升信任感（如“本回答来源于XXX知识文档”）

4）上线后的数据闭环。该过程在所有类型的产品落地时都会多次强调，对知识库而言，你需要重点关注知识的召回率与准确率，同时建立知识内容的版本管理与动态更新机制，确保知识库在实际应用中的持续有效性与业务匹配度。

这不仅是效果评估手段，更是推动知识库持续演进与模型能力迭代的关键机制。

2.3 模型微调

如果说，模型的预训练环节是通过海量的语料让模型学习通用规律，让模型在巨大的图书馆中自学成才，那么微调则是做模型的老师，定义标准答案，负责打磨优质的学生样本出来，对其针对性辅导，以便让模型去学习和模仿。

在预训练环节，参数量和语料的丰富多样几乎直接决定了预训练后模型的智商上限；而在微调环节，样本的质量和多样性决定了模型的专业度和可控性。

举个例子，你做了一个物流客服机器人，泛化模型回答太泛，于是你提出针对「快递物流问题」微调一个专用模型。在微调模型的过程，涉及到具体微调的方法、训练调参的工作，由算法团队支持；但关于微调场景的定义、数据策略和资源的优先级，由产品经理负责。

第一步：明确调优目标，输出能力调优的需求说明书，包含问题类型分析、失败示例、当前能力的评估结果。

你要正面明确以下几个问题：

• 哪类问题表现差？回答是否稳定？
• 提示词优化是否有效？
• 是否值得微调？

第二步：定义微调的数据范围与质量标准，输出《标注任务说明》，包括标签体系、数据格式、案例等，可交给数据团队执行。

第三步：定义微调的策略和能力边界，包括目标、调用逻辑、能力边界和风险点等。

第四步：设计评估机制与上线验收的标准，从业务视角定义「什么是好结果」，帮助算法明确优化方向。

衡量指标可以是：准确率的提升，同类问题回答的一致性，用户的满意度，推理成本的控制等，视具体的应用场景去调整。

第五步：上线后数据闭环与策略优化，输出《上线效果评估报告》，看是否达成目标，是否需要进一步迭代。

和前文的外挂知识库一样，上线后你需要监控模型微调后的核心指标变化，比如模型的调用次数、回答的准确率、用户的满意度等，并及时分析失败case，看是否存在一些意图识别错误、回答内容偏移的问题。

不同之处在于，模型微调的成本更高（研发投入+算力），以至于你必须把评估ROI纳入到每次微调的复盘工作中，去甄别微调带来的满意度提升是否匹配训练+推理的成本投入。

3. 小结

现阶段市面上所谓“AI产品经理”，很多其实只是用过API的“伪AI产品经理”，而真正能从“业务需求→模型能力→场景设计→效果评估与优化”的AI产品经理凤毛麟角。

传统产品经理大多分外关注用户体验路径和产品功能形态的落地，这无可厚非。但除此之外，AI产品经理更要重视技术上下游（算法、数据、工程团队）的协作，需重点考虑将能力调优和外围工程融入产品设计，并通过策略制定实现产品价值的最大化。

产品策略是方向盘，决定我们做对的事；用户体验是油门和刹车，决定我们把事做对。二者互为配合和牵制：向左走，你需要理解模型的能力边界、业务目标和反馈机制；向右走，你需要深入用户行为背后的动机，构建良好的交互体验和输出信任。

左右互搏的过程中，用户体验必须服务于产品的策略目标，产品策略也要为用户体验让路。

下次见！