跟两位顶尖AI产品大佬学设计经验（附原版视频）

跟两位顶尖AI产品大佬学设计经验（附原版视频） 跟两位顶尖AI产品大佬学设计经验（附原版视频） Modified June 10, 2025 关于这方面，凯文所在的 OpenAI 也敏锐地意识到了这一点，他们甚至设立了专门的训练营，旨在培养产品经理撰写评估标准的能力。这种培训方式让产品经理们深入理解什么是优质评估，什么是欠佳评估，从而在产品开发过程中做出更加明智的决策。这不仅提高了产品质量，还培养了产品经理的批判性思维和分析能力。虽然不要求每个产品经理都成为专业研究员，但他们需要对技术研究有一定认识，投入时间学习相关技术术语，并逐步建立对技术运作机制的直觉。这种技术洞察力能帮助产品经理做出更明智的决策，并更有效地与技术团队沟通。 进一步，迈克补充了一个观点：利用 AI 模型进行原型设计是一项被严重低估但极为实用的技能。例如，在讨论用户界面设计方案时，产品经理或工程师可以借助大语言模型生成不同 UI 设计方案的对比效果。这种方法不仅能加速设计过程，还能激发创新思维。 📌 剑客的经验之谈： 1. 懂AI技术的产品经理才是好AI产品经理🦾 如果你在这行做的够久，那么你应该已经察觉到近年来产品开发领域的显著变化。 过去，AI 产品开发团队通常是独立存在的，与传统信息化项目（如 OA、RPA、ERP 等）的团队分开。但随着 AI 革命的到来，这种格局发生了变化。AI 功能因其普世价值而被各类产品争相引入，就像突然间每个人都拥有了一根魔法棒。这种变革主要源于 AI 在处理文字内容方面的广泛应用。 而现在，许多人要么负责全新的 AI 产品，要么在现有产品中植入 AI 功能或理念。然而，普遍存在的问题是对 AI 的认识不足，更不用说 AI 技术了。 在这种情况下，产品经理如果不具备 AI 知识，将难以胜任工作。缺乏对 AI 技术的了解会导致无法制定合适的规则和标准，甚至可能出现 "外行领导内行" 的尴尬局面。因此，尽管 AI 技术已发展两年，但许多产品经理仍然对其知之甚少，这是非常不可取的。 我认为，现阶段的 AI 产品经理至少应该了解以下几点： 1. 模型的基本参数、尺寸、适应性方向 2. 模型的数据集来源 3. 原始模型是如何被训练出来的 4. 模型的迭代优化的理论过程和对应指标 5. 模型的微调方法，包括使用类似 LoRA 的模型训练手段和提示词技术 另外，在国内，提示词工程师的生存空间很狭窄，除非是专业的大模型公司，否则很少有单独预算去设立一个专门写prompt的职位，常见的情况就是产品经理身兼两职，以后可能会长期持续下去，要做好心理准备。 话题5：应对随机性 此外，AI 产品经理还面临着一个独特的挑战：AI 系统的随机性和不确定性。与传统软件系统不同，AI 模型的输出并非完全可预测。在这种情况下，产品经理需要建立有效的反馈机制来实现系统的闭环管理。具体而言，他们需要： • 当模型输出偏离预期时，能够判断这种偏离是否在可接受范围内 • 快速收集和分析用户反馈 • 设置合理的防护措施，避免模型出现严重错误 同时，产品经理还需要从整体上了解模型在大规模用户使用过程中的表现情况。这与传统软件 bug 反馈有本质区别。传统软件问题通常表现为明确的功能异常，如按钮点击无反应。而 AI 模型的问题可能更加复杂和隐蔽，需要产品经理从多个维度进行分析和处理。 在适应这种非确定性用户界面的过程中，产品经理面临着双重挑战。他们不仅要自己理解和接受这些变化，还要站在用户的角度去思考问题。对大多数用户来说，这种违背传统计算机使用直觉的情况可能会引起困惑。因此，产品经理需要在产品设计中考虑如何减少这种困惑，同时巧妙利用这些新特性为用户创造更优质的体验。而这种平衡需要求产品经理具备： • 深刻的用户同理心 • 创新的界面设计思维 • 出色的沟通和教育能力 📌 剑客的经验之谈： 在这里，这两位所说的话，显然是充满了漂亮国风格的内容。但我想就着这个话题说点更接地气的内容。 1. 无论C端还是B端产品。在设计初期，都需要特别关注随机性和敏感性问题。在中国的社会环境下，有些内容是禁止讨论的，如果你想让自己的产品活得更久，这就是你必须考虑的一个方面。从此角度出发，在产品设计中，你需要设计输入和输出的防护机制。输入防护主要防止用户进行有意“搞事”。而输出防护主要防止模型“胡说八道”。常见的手段有提示词层防护、敏感词库防护、二次训练对抗样本植入等。 2. 用户理解模型输出是一个复杂的过程。如果我们有一个引用库，可以快速帮助用户理解某些术语或概念的含义，这将大大提高交互效率。比如，当模型输出了一个没有进一步解释的名词时，我们可以考虑对这个名词添加引用，用户点击后就可以快速得到释义。这些辅助功能可以减少不必要的对话环节。 3. 此外，对于模型在不同时间给出的不一致答案，我们可以尝试建立一个包含相同问题的对话框架。这样，用户可以参考其他人对类似回复的评论，有助于采纳大多数的回复。但这个需要注意用户隐私的问题。慎用。 话题6：对用户的教育和培训 接下来，讨论转向了在面向消费者的产品领域如何利用 AI 来教育用户的问题。这个话题尤为重要，因为它直接关系到新技术的普及和接受度。 凯文指出了一个有趣的现象：随着 AI 技术的飞速发展，产品更新换代的速度极快，这无疑对用户的接受能力提出了挑战。然而，令人欣慰的是，人类适应新事物的速度实际上是惊人的。 凯文以自动驾驶汽车为例生动地阐述了这一点： • 初次体验：用户在最初的 30 秒可能充满紧张和担忧。 • 5 分钟后：他们开始享受这种新奇体验，仿佛置身未来世界。 • 10 分钟后：用户可能已经习以为常，甚至开始无聊地刷手机。 接着，迈克分享了 Anthropic 在产品教育方面的实践经验，他们正在努力改进产品的教育功能，使产品能够更主动地向用户介绍自己。这包括几个关键方面： 1. 基本信息透明： ◦ 向用户说明模型的训练集来源 ◦ 介绍产品的开发公司等基本信息 2. 功能使用指导： ◦ 直接向用户介绍产品功能的使用方式 ◦ 提供更加准确、实用的帮助 Anthropic 发现，许多用户在使用产品时会遇到困惑，经常询问 "我该怎么用这个？" 早期产品的回答往往不能满足用户需求。为此，他们现在致力于让产品能够为用户提供更加精准和实用的帮助，例如： • 提供确切的文档链接 • 及时给出类似 "哦，你遇到困难了，让我来帮你" 的回应 这种方法不仅提高了用户体验，还有助于建立用户对 AI 产品的信任。通过主动、透明和有针对性的教育，Anthropic 正在努力缩小 AI 技术与用户理解之间的鸿沟。 📌 剑客的经验之谈： 对于培训教育这方面的经验，我觉得作为一个经常在企业内部展开内训的项目经理，还是有一定话语权的，我来谈谈我的感受。 在 AI 产品教育领域，我们面临着 C 端和 B 端两个截然不同的环境。 C 端产品的主要挑战是如何吸引用户参与到学习教育中来，因为主动学习从来不是多数人参与的事情，也没有那么多人为爱发电。一个有效的方法是为产品创建辅助社区和学院。例如，我们可以设立一个专门的学院板块，邀请共建者制作内容，提升产品的整体价值。同时，开展定期的直播教学，如Way to AGI 经常举办的公益教学，也是吸引和保留用户的好方法。但这个过程中，最重要的是设计一套游戏规则——比如你可以为每个原意参与到学院中的人给一些持续性的奖励。 随着时间的推移，这种建设可能会演变成自发的粉丝组织或自治社区。这类似于 Web3 项目中的 DAO 模式，围绕产品形成一个非中心化的组织，进而在这种组织中定期让大家投票下一个想要的功能、对现有产品提出改进性意见——这种强连接不仅能帮助维护产品，还能为产品开发者提供宝贵的用户反馈，有助于了解核心用户对产品更新的真实反应。 再说B端。你首先需要清醒的认识到一点，B 端用户多为被迫学习者（这不是错别字）。他们往往是被逼着去学习的。 基于这种认识，B端的教育手段就完全不同了。常见的做法包括推动B端客户管理层进行自上而下的培训会议、考试，甚至将 AI 学习任务纳入员工的绩效考核中。在实际培训过程中，一些公司还会在内部成立专门的辅助项目业务组织来推广 AI 教育。 作为产品经历，虽然无法反客为主的单独推动整个企业的 AI 教育，但你仍然可以做很多工作。除了基本的产品说明书和文档编写外，你还可以录制详细的教学视频，展示产品的操作方法。最重要的是长期维护和更新这些教学材料。此外，通过在产品维保期间，定时在企业内部举办培训会，也可以有效地推动 AI 教育的普及。 记得列 TO DO LIST哟！ 话题7：不应因单模型性能损失用户体验 凯文介绍说，在实际应用中，用户很少单纯依赖单个模型来处理特定问题，尤其是在满足高级客户需求和处理公司内部业务场景时。由于不同模型各有独特优势，可以根据具体情况将它们组合起来，形成高效的工作流程和编排模式。 以 o1 模型为例，它的表现更接近人类解决难题时的思考过程。在查询时，它不会立即输出结果，而是会暂停 30 到 60 秒进行思考。然而，在某些需要即时反馈的场景中，如在线客服系统，用户难以接受等待 60 秒才得到回复。这时，多模型协同的重要性就凸显出来了。例如，可以安排一些模型先快速回答，然后让 o1 提供深入思考，甚至再安排一个模型进行复查。通过这种方式，公司能够充分发挥各个模型的优势。 在当前的用户体验中，人们通常期望输入问题后能迅速得到答案。这种即时反馈模式在某种程度上限制了 AI 处理复杂任务的能力。然而，未来的 AI 产品将打破这一局限。当用户向 AI 下达一个复杂任务时，比如进行早期用户界面探索，AI 会告知用户当前的工作内容和大致进度。用户可以选择等待，也可以先处理其他事务，稍后再回来查看结果。 在这个过程中，AI 可能需要一定时间进行思考研究，甚至可能需要与其他系统或数据源交互以获取更多信息，然后才会给出初步答案。之后，模型还可以对答案进行进一步验证和优化，并在一小时后向用户反馈更完善的结果。这种异步处理模式为 AI 开辟了更广阔的应用空间，使其能够处理比以往更加复杂的任务，例如根据最新市场变化修改产品需求文档，或根据最新市场趋势调整战略计划。 📌 剑客的经验之谈： 虽然在一些成熟的项目组中，架构师和产品经理的角色是分开的，但我认为产品经理仍然应该有这种意识：AI产品的生命力很大程度上取决于底层 AI 模型的稳定性和可靠性。 所以，单模型风险已成为许多产品经理，特别是 AI 产品经理们需要清醒认识的重要问题。由于模型迭代速度快，性能不稳定，甚至同一大版本中的不同子版本都可能造成不稳定影响，这就给产品带来了许多不确定的风险因素。因此，无论产品的表面形式如何，在进行产品设计时，底层架构通常都需要多个模型来辅助前台交互。 即我们不能让单个模型的不可控风险导致整个产品的失败。如果有些产品经理还没有意识到这个问题，那么现在正是亡羊补牢的时候，。 另一个值得关注的问题是如何提升用户体验，特别是在用户遇到疑问或问题时。这涉及到快思考和慢思考的区别和联系。现在许多大型企业的产品都会应用这种搭配，比如腾讯元宝的深度搜索功能，这种功能也经常被其他产品模仿和复刻。 在设计产品功能时，我们不仅要考虑人机交互的反馈机制，还需要考虑每个任务适合由什么类型的模型来执行。例如，对于复杂任务，我们需要在前端告诉用户需要等待，同时展示工作进度。在这个过程中，能处理复杂任务的模型可以帮助用户获得更好的回复。而对于一些简单功能，可能只需调用简单的模型即可完成。 基于这些考虑，我们又回到了多模型接入的问题。在底层设计时就需要考虑这个问题，包括在设计不同功能点时，要考虑每个模型能负责什么样的任务。这也反映了 AI 产品经理所需具备的素质：只有了解模型的训练过程和基本参数，才能判断模型是否能胜任特定任务，以及胜任的概率有多大。 话题8：用户期望扩展 此外，他还分享了当前模型在交互方式上一些令人兴奋的发展成果。高级语音模式的出现极大地改变了人们的交流体验，尤其在跨国交流场景中，实时翻译让跨语言沟通不再成为障碍，仿佛实现了星际迷航中的万能翻译器。 用户与模型的互动方式也正在发生深刻变化。语音模式发布后，TikTok 上涌现出大量年轻人与之互动的视频，他们向语音模式倾诉心事。这种新的互动模式展现了 AI 在情感陪伴和社交领域的潜在价值。同时，用户与模型之间的关系也在悄然演变，逐渐形成了一种类似于朋友的亲密关系。 人们开始关注模型的个性特点，甚至会因模型的某些表现而产生好感或不满。例如，有人可能觉得某个新模型更聪明了，但同时又显得有些疏远。这种情感层面的反馈表明，用户对模型的期望已不仅局限于功能层面。因此，产品经理需要更加注重在产品设计中融入情感因素，使模型更具亲和力和同理心。 此外，模型对用户的描述能力也引发了有趣的现象。一些实验表明，当用户询问模型如何根据以往所有互动信息来描述自己时，模型给出的回答会引起用户强烈的反应。这种体验就像在与一个真实的个体对话，模型不再仅仅是由代码和算法构成的工具，而是开始具备某种人格化的特征。 这些变化预示着 AI 将在未来更深入地融入人们的生活，成为不可或缺的一部分。产品经理需要紧跟这些趋势，不断优化产品设计，以满足用户在功能和情感上的双重需求。 话题9：AI产品未来的发展方向 关于这方面，凯文所在的 OpenAI 也敏锐地意识到了这一点，他们甚至设立了专门的训练营，旨在培养产品经理撰写评估标准的能力。这种培训方式让产品经理们深入理解什么是优质评估，什么是欠佳评估，从而在产品开发过程中做出更加明智的决策。这不仅提高了产品质量，还培养了产品经理的批判性思维和分析能力。虽然不要求每个产品经理都成为专业研究员，但他们需要对技术研究有一定认识，投入时间学习相关技术术语，并逐步建立对技术运作机制的直觉。这种技术洞察力能帮助产品经理做出更明智的决策，并更有效地与技术团队沟通。 进一步，迈克补充了一个观点：利用 AI 模型进行原型设计是一项被严重低估但极为实用的技能。例如，在讨论用户界面设计方案时，产品经理或工程师可以借助大语言模型生成不同 UI 设计方案的对比效果。这种方法不仅能加速设计过程，还能激发创新思维。 📌 剑客的经验之谈： 1. 懂AI技术的产品经理才是好AI产品经理🦾 如果你在这行做的够久，那么你应该已经察觉到近年来产品开发领域的显著变化。 过去，AI 产品开发团队通常是独立存在的，与传统信息化项目（如 OA、RPA、ERP 等）的团队分开。但随着 AI 革命的到来，这种格局发生了变化。AI 功能因其普世价值而被各类产品争相引入，就像突然间每个人都拥有了一根魔法棒。这种变革主要源于 AI 在处理文字内容方面的广泛应用。 而现在，许多人要么负责全新的 AI 产品，要么在现有产品中植入 AI 功能或理念。然而，普遍存在的问题是对 AI 的认识不足，更不用说 AI 技术了。 在这种情况下，产品经理如果不具备 AI 知识，将难以胜任工作。缺乏对 AI 技术的了解会导致无法制定合适的规则和标准，甚至可能出现 "外行领导内行" 的尴尬局面。因此，尽管 AI 技术已发展两年，但许多产品经理仍然对其知之甚少，这是非常不可取的。 我认为，现阶段的 AI 产品经理至少应该了解以下几点： 1. 模型的基本参数、尺寸、适应性方向 2. 模型的数据集来源 3. 原始模型是如何被训练出来的 4. 模型的迭代优化的理论过程和对应指标 5. 模型的微调方法，包括使用类似 LoRA 的模型训练手段和提示词技术 另外，在国内，提示词工程师的生存空间很狭窄，除非是专业的大模型公司，否则很少有单独预算去设立一个专门写prompt的职位，常见的情况就是产品经理身兼两职，以后可能会长期持续下去，要做好心理准备。 剑客的经验之谈： 1. 懂AI技术的产品经理才是好AI产品经理🦾 如果你在这行做的够久，那么你应该已经察觉到近年来产品开发领域的显著变化。 过去，AI 产品开发团队通常是独立存在的，与传统信息化项目（如 OA、RPA、ERP 等）的团队分开。但随着 AI 革命的到来，这种格局发生了变化。AI 功能因其普世价值而被各类产品争相引入，就像突然间每个人都拥有了一根魔法棒。这种变革主要源于 AI 在处理文字内容方面的广泛应用。 而现在，许多人要么负责全新的 AI 产品，要么在现有产品中植入 AI 功能或理念。然而，普遍存在的问题是对 AI 的认识不足，更不用说 AI 技术了。 在这种情况下，产品经理如果不具备 AI 知识，将难以胜任工作。缺乏对 AI 技术的了解会导致无法制定合适的规则和标准，甚至可能出现 "外行领导内行" 的尴尬局面。因此，尽管 AI 技术已发展两年，但许多产品经理仍然对其知之甚少，这是非常不可取的。 我认为，现阶段的 AI 产品经理至少应该了解以下几点： 1. 模型的基本参数、尺寸、适应性方向 2. 模型的数据集来源 3. 原始模型是如何被训练出来的 4. 模型的迭代优化的理论过程和对应指标 5. 模型的微调方法，包括使用类似 LoRA 的模型训练手段和提示词技术 另外，在国内，提示词工程师的生存空间很狭窄，除非是专业的大模型公司，否则很少有单独预算去设立一个专门写prompt的职位，常见的情况就是产品经理身兼两职，以后可能会长期持续下去，要做好心理准备。 话题5：应对随机性 此外，AI 产品经理还面临着一个独特的挑战：AI 系统的随机性和不确定性。与传统软件系统不同，AI 模型的输出并非完全可预测。在这种情况下，产品经理需要建立有效的反馈机制来实现系统的闭环管理。具体而言，他们需要： • 当模型输出偏离预期时，能够判断这种偏离是否在可接受范围内 • 快速收集和分析用户反馈 • 设置合理的防护措施，避免模型出现严重错误 同时，产品经理还需要从整体上了解模型在大规模用户使用过程中的表现情况。这与传统软件 bug 反馈有本质区别。传统软件问题通常表现为明确的功能异常，如按钮点击无反应。而 AI 模型的问题可能更加复杂和隐蔽，需要产品经理从多个维度进行分析和处理。 在适应这种非确定性用户界面的过程中，产品经理面临着双重挑战。他们不仅要自己理解和接受这些变化，还要站在用户的角度去思考问题。对大多数用户来说，这种违背传统计算机使用直觉的情况可能会引起困惑。因此，产品经理需要在产品设计中考虑如何减少这种困惑，同时巧妙利用这些新特性为用户创造更优质的体验。而这种平衡需要求产品经理具备： • 深刻的用户同理心 • 创新的界面设计思维 • 出色的沟通和教育能力 📌 剑客的经验之谈： 在这里，这两位所说的话，显然是充满了漂亮国风格的内容。但我想就着这个话题说点更接地气的内容。 1. 无论C端还是B端产品。在设计初期，都需要特别关注随机性和敏感性问题。在中国的社会环境下，有些内容是禁止讨论的，如果你想让自己的产品活得更久，这就是你必须考虑的一个方面。从此角度出发，在产品设计中，你需要设计输入和输出的防护机制。输入防护主要防止用户进行有意“搞事”。而输出防护主要防止模型“胡说八道”。常见的手段有提示词层防护、敏感词库防护、二次训练对抗样本植入等。 2. 用户理解模型输出是一个复杂的过程。如果我们有一个引用库，可以快速帮助用户理解某些术语或概念的含义，这将大大提高交互效率。比如，当模型输出了一个没有进一步解释的名词时，我们可以考虑对这个名词添加引用，用户点击后就可以快速得到释义。这些辅助功能可以减少不必要的对话环节。 3. 此外，对于模型在不同时间给出的不一致答案，我们可以尝试建立一个包含相同问题的对话框架。这样，用户可以参考其他人对类似回复的评论，有助于采纳大多数的回复。但这个需要注意用户隐私的问题。慎用。 剑客的经验之谈： 在这里，这两位所说的话，显然是充满了漂亮国风格的内容。但我想就着这个话题说点更接地气的内容。 1. 无论C端还是B端产品。在设计初期，都需要特别关注随机性和敏感性问题。在中国的社会环境下，有些内容是禁止讨论的，如果你想让自己的产品活得更久，这就是你必须考虑的一个方面。从此角度出发，在产品设计中，你需要设计输入和输出的防护机制。输入防护主要防止用户进行有意“搞事”。而输出防护主要防止模型“胡说八道”。常见的手段有提示词层防护、敏感词库防护、二次训练对抗样本植入等。 2. 用户理解模型输出是一个复杂的过程。如果我们有一个引用库，可以快速帮助用户理解某些术语或概念的含义，这将大大提高交互效率。比如，当模型输出了一个没有进一步解释的名词时，我们可以考虑对这个名词添加引用，用户点击后就可以快速得到释义。这些辅助功能可以减少不必要的对话环节。 3. 此外，对于模型在不同时间给出的不一致答案，我们可以尝试建立一个包含相同问题的对话框架。这样，用户可以参考其他人对类似回复的评论，有助于采纳大多数的回复。但这个需要注意用户隐私的问题。慎用。 话题6：对用户的教育和培训 接下来，讨论转向了在面向消费者的产品领域如何利用 AI 来教育用户的问题。这个话题尤为重要，因为它直接关系到新技术的普及和接受度。 凯文指出了一个有趣的现象：随着 AI 技术的飞速发展，产品更新换代的速度极快，这无疑对用户的接受能力提出了挑战。然而，令人欣慰的是，人类适应新事物的速度实际上是惊人的。 凯文以自动驾驶汽车为例生动地阐述了这一点： • 初次体验：用户在最初的 30 秒可能充满紧张和担忧。 • 5 分钟后：他们开始享受这种新奇体验，仿佛置身未来世界。 • 10 分钟后：用户可能已经习以为常，甚至开始无聊地刷手机。 接着，迈克分享了 Anthropic 在产品教育方面的实践经验，他们正在努力改进产品的教育功能，使产品能够更主动地向用户介绍自己。这包括几个关键方面： 1. 基本信息透明： ◦ 向用户说明模型的训练集来源 ◦ 介绍产品的开发公司等基本信息 ◦ 向用户说明模型的训练集来源 ◦ 介绍产品的开发公司等基本信息 2. 功能使用指导： ◦ 直接向用户介绍产品功能的使用方式 ◦ 提供更加准确、实用的帮助 ◦ 直接向用户介绍产品功能的使用方式 ◦ 提供更加准确、实用的帮助 Anthropic 发现，许多用户在使用产品时会遇到困惑，经常询问 "我该怎么用这个？" 早期产品的回答往往不能满足用户需求。为此，他们现在致力于让产品能够为用户提供更加精准和实用的帮助，例如： • 提供确切的文档链接 • 及时给出类似 "哦，你遇到困难了，让我来帮你" 的回应 这种方法不仅提高了用户体验，还有助于建立用户对 AI 产品的信任。通过主动、透明和有针对性的教育，Anthropic 正在努力缩小 AI 技术与用户理解之间的鸿沟。 📌 剑客的经验之谈： 对于培训教育这方面的经验，我觉得作为一个经常在企业内部展开内训的项目经理，还是有一定话语权的，我来谈谈我的感受。 在 AI 产品教育领域，我们面临着 C 端和 B 端两个截然不同的环境。 C 端产品的主要挑战是如何吸引用户参与到学习教育中来，因为主动学习从来不是多数人参与的事情，也没有那么多人为爱发电。一个有效的方法是为产品创建辅助社区和学院。例如，我们可以设立一个专门的学院板块，邀请共建者制作内容，提升产品的整体价值。同时，开展定期的直播教学，如Way to AGI 经常举办的公益教学，也是吸引和保留用户的好方法。但这个过程中，最重要的是设计一套游戏规则——比如你可以为每个原意参与到学院中的人给一些持续性的奖励。 随着时间的推移，这种建设可能会演变成自发的粉丝组织或自治社区。这类似于 Web3 项目中的 DAO 模式，围绕产品形成一个非中心化的组织，进而在这种组织中定期让大家投票下一个想要的功能、对现有产品提出改进性意见——这种强连接不仅能帮助维护产品，还能为产品开发者提供宝贵的用户反馈，有助于了解核心用户对产品更新的真实反应。 再说B端。你首先需要清醒的认识到一点，B 端用户多为被迫学习者（这不是错别字）。他们往往是被逼着去学习的。 基于这种认识，B端的教育手段就完全不同了。常见的做法包括推动B端客户管理层进行自上而下的培训会议、考试，甚至将 AI 学习任务纳入员工的绩效考核中。在实际培训过程中，一些公司还会在内部成立专门的辅助项目业务组织来推广 AI 教育。 作为产品经历，虽然无法反客为主的单独推动整个企业的 AI 教育，但你仍然可以做很多工作。除了基本的产品说明书和文档编写外，你还可以录制详细的教学视频，展示产品的操作方法。最重要的是长期维护和更新这些教学材料。此外，通过在产品维保期间，定时在企业内部举办培训会，也可以有效地推动 AI 教育的普及。 记得列 TO DO LIST哟！ 剑客的经验之谈： 对于培训教育这方面的经验，我觉得作为一个经常在企业内部展开内训的项目经理，还是有一定话语权的，我来谈谈我的感受。 在 AI 产品教育领域，我们面临着 C 端和 B 端两个截然不同的环境。 C 端产品的主要挑战是如何吸引用户参与到学习教育中来，因为主动学习从来不是多数人参与的事情，也没有那么多人为爱发电。一个有效的方法是为产品创建辅助社区和学院。例如，我们可以设立一个专门的学院板块，邀请共建者制作内容，提升产品的整体价值。同时，开展定期的直播教学，如Way to AGI 经常举办的公益教学，也是吸引和保留用户的好方法。但这个过程中，最重要的是设计一套游戏规则——比如你可以为每个原意参与到学院中的人给一些持续性的奖励。 随着时间的推移，这种建设可能会演变成自发的粉丝组织或自治社区。这类似于 Web3 项目中的 DAO 模式，围绕产品形成一个非中心化的组织，进而在这种组织中定期让大家投票下一个想要的功能、对现有产品提出改进性意见——这种强连接不仅能帮助维护产品，还能为产品开发者提供宝贵的用户反馈，有助于了解核心用户对产品更新的真实反应。 再说B端。你首先需要清醒的认识到一点，B 端用户多为被迫学习者（这不是错别字）。他们往往是被逼着去学习的。 基于这种认识，B端的教育手段就完全不同了。常见的做法包括推动B端客户管理层进行自上而下的培训会议、考试，甚至将 AI 学习任务纳入员工的绩效考核中。在实际培训过程中，一些公司还会在内部成立专门的辅助项目业务组织来推广 AI 教育。 作为产品经历，虽然无法反客为主的单独推动整个企业的 AI 教育，但你仍然可以做很多工作。除了基本的产品说明书和文档编写外，你还可以录制详细的教学视频，展示产品的操作方法。最重要的是长期维护和更新这些教学材料。此外，通过在产品维保期间，定时在企业内部举办培训会，也可以有效地推动 AI 教育的普及。 记得列 TO DO LIST哟！ 话题7：不应因单模型性能损失用户体验 凯文介绍说，在实际应用中，用户很少单纯依赖单个模型来处理特定问题，尤其是在满足高级客户需求和处理公司内部业务场景时。由于不同模型各有独特优势，可以根据具体情况将它们组合起来，形成高效的工作流程和编排模式。 以 o1 模型为例，它的表现更接近人类解决难题时的思考过程。在查询时，它不会立即输出结果，而是会暂停 30 到 60 秒进行思考。然而，在某些需要即时反馈的场景中，如在线客服系统，用户难以接受等待 60 秒才得到回复。这时，多模型协同的重要性就凸显出来了。例如，可以安排一些模型先快速回答，然后让 o1 提供深入思考，甚至再安排一个模型进行复查。通过这种方式，公司能够充分发挥各个模型的优势。 在当前的用户体验中，人们通常期望输入问题后能迅速得到答案。这种即时反馈模式在某种程度上限制了 AI 处理复杂任务的能力。然而，未来的 AI 产品将打破这一局限。当用户向 AI 下达一个复杂任务时，比如进行早期用户界面探索，AI 会告知用户当前的工作内容和大致进度。用户可以选择等待，也可以先处理其他事务，稍后再回来查看结果。 在这个过程中，AI 可能需要一定时间进行思考研究，甚至可能需要与其他系统或数据源交互以获取更多信息，然后才会给出初步答案。之后，模型还可以对答案进行进一步验证和优化，并在一小时后向用户反馈更完善的结果。这种异步处理模式为 AI 开辟了更广阔的应用空间，使其能够处理比以往更加复杂的任务，例如根据最新市场变化修改产品需求文档，或根据最新市场趋势调整战略计划。 📌 剑客的经验之谈： 虽然在一些成熟的项目组中，架构师和产品经理的角色是分开的，但我认为产品经理仍然应该有这种意识：AI产品的生命力很大程度上取决于底层 AI 模型的稳定性和可靠性。 所以，单模型风险已成为许多产品经理，特别是 AI 产品经理们需要清醒认识的重要问题。由于模型迭代速度快，性能不稳定，甚至同一大版本中的不同子版本都可能造成不稳定影响，这就给产品带来了许多不确定的风险因素。因此，无论产品的表面形式如何，在进行产品设计时，底层架构通常都需要多个模型来辅助前台交互。 即我们不能让单个模型的不可控风险导致整个产品的失败。如果有些产品经理还没有意识到这个问题，那么现在正是亡羊补牢的时候，。 另一个值得关注的问题是如何提升用户体验，特别是在用户遇到疑问或问题时