有一个说法流传很广:产品经理不需要懂技术。
过去这话大体成立。你不懂 MySQL 的索引原理,不影响你设计一个电商系统的交互流程。技术是个黑箱,你关心输入和输出就够了,中间怎么跑的是工程师的事。
但到了 AI 产品这里,这套逻辑正在失效。而且失效的方式很隐蔽,不是那种"你做不了"的失效,是"你做了但做错了"的失效。
一个真实的决策失误
我参与过一个 B 端企业知识库问答项目。团队里两个 PM 负责不同模块,一个花了两周理解大模型的基本原理,另一个觉得「这些是技术的事」。
两个人在同一个决策上出现了分歧:用户问了一个知识库里没有的问题,AI 应该怎么回答?
第一个 PM 说:必须让 AI 回复"资料中未提及",然后引导用户去人工客服。他的理由是,模型的本质是预测下一个最可能的 Token,不是在查资料库,如果不做限制,它会"编"一个听起来合理但完全错误的答案。
第二个 PM 说:让 AI 尽量回答,回答不了再转人工。他觉得 AI 应该"智能"一点,用户体验更好。
最后项目按第二个方案上线。两周后,一个客户根据 AI 编造的合规条款做了业务决策,差点出事。紧急回滚,按第一个方案改。
这两个 PM 的能力差别在哪?不在交互设计,不在用户调研,就在于一个人理解"大模型本质上是概率生成器",另一个人以为"AI 就是一个更聪明的搜索引擎"。
PM需要懂LLM到什么程度
我说的「懂原理」不是让你去推导 Transformer 的注意力权重公式,也不是让你搞明白 BPE 分词的每一步合并过程。这些是工程师的领地。
PM 需要懂的是另一层东西。我把它概括成三个问题:
模型能做什么。 大模型能理解语义,不是匹配关键词。"建筑节能"和"绿色建筑的能耗优化"在传统搜索里是两个毫不相关的查询,但在语义搜索里它们几乎等价。如果你不理解 Embedding 把文字变成向量这回事,你可能还在让工程师做关键词匹配的方案,白白浪费了模型最强的能力。
模型不能做什么。 大模型没有"记忆"。它在一次对话里能记住的内容,取决于上下文窗口能装多少 Token。窗口满了,早期信息就丢了。这不是 bug,是架构决定的硬约束。如果你设计了一个需要 AI"记住"用户三个月前说过什么的功能,技术上不是做不到,但你得知道那需要额外的向量数据库和检索链路,成本和复杂度完全不同。
模型在什么条件下会失败。 幻觉不是偶发故障,是概率生成的必然结果。模型选的是"最可能的下一个词",不是"最正确的下一个词"。训练数据覆盖薄弱的领域,幻觉率会更高。问模型一个它不知道的问题,它不会说"我不知道",因为训练过程中,"给出回答"比"承认无知"得到的奖励更多。
这三个问题的答案,构成了一条认知边界。边界以内是你可以放心交给 AI 的领域,边界以外是你必须加防护栏的领域。不知道这条边界在哪的 PM,要么把 AI 用得太保守(浪费了能力),要么用得太激进(埋下了事故隐患)。
Token成本:被PM忽略的产品决策
还有一个容易被忽略的维度:钱。
同样一个 AI 客服产品,每天处理 1000 次对话,换一个模型月成本可以从 6600 块降到 84 块。差了 78 倍。这不是工程优化的问题,是产品决策的问题——你选哪个模型、你的 System Prompt 写多长、你的上下文窗口设多大,每一个选择都直接对应着账单上的数字。
我见过一个 PM 设计了一个 2000 Token 的 System Prompt,每次用户对话都带上。一天 1000 次对话,光 Prompt 部分每月就多花 3000 块。后来有人帮他把 Prompt 精简到 500 Token,功能没变,每月省了两千多。
不懂 Token 计费逻辑的 PM,连成本失控都无法提前发现。等到月底账单来了才知道超预算,但产品已经上线了。
AI时代,PM为什么必须懂技术
传统软件产品的技术栈是确定性的。你调用一个 API,传入同样的参数,得到同样的结果。系统的行为可预测,PM 不需要理解底层实现就能设计出合理的产品。
大模型不是这样。同一个 Prompt,同一个模型,每次输出可能都不一样。模型的能力边界是模糊的、动态的。它在某些任务上表现惊艳,在另一些任务上一本正经地胡说八道,而你没法提前用测试用例把所有情况跑一遍。
这意味着 PM 必须理解模型的行为特征,才能做出靠谱的设计。你需要知道:什么时候该信任 AI 的输出?什么时候需要加一道人工审核?什么场景下应该限制 AI 的回答范围?置信度低的输出要不要给用户看?
这些问题没法靠"产品感觉"来回答。每一个都需要你对模型能力边界有基本的判断。
举个例子:如果你知道大模型的本质是"注意力机制让它能同时关注整段文本中词与词的关系",你就能理解为什么它擅长总结、改写、翻译这类"理解+生成"的任务,但在精确计算和事实核查上不可靠。这个理解会直接影响你对产品功能的取舍——哪些功能可以全自动,哪些必须人机协作。
而如果你只把大模型当成一个"更聪明的工具",你的产品设计就会建立在错误的假设上。
认知边界是动态的
我得承认,这条认知边界不是静态的。模型能力在进化,去年做不到的事今年可能就做到了。幻觉率在下降,上下文窗口在变大,推理能力在增强。
但这恰恰说明 PM 更需要持续跟踪这条边界的变化。如果你连去年的边界在哪都不知道,你怎么判断今年的边界移动了多少?
我现在的做法是每个季度花几个小时,找几个跟产品相关的场景,亲手测几个模型的表现。不是看评测报告,报告是别人的场景,你的产品有你自己的边界条件。只有自己跑过,才知道模型在你的场景下到底行不行。
写在最后
回到开头那个问题。PM 到底需不需要懂大模型原理?
我的判断是:你不需要懂怎么训练模型,但你必须懂模型的行为边界。不是因为这样更「全面」,而是因为在 AI 产品里,不懂这些,你做的每一个产品决策都可能建立在错误的假设上——只是你自己不知道而已。
这也是我觉得「AI 产品经理」这个角色真正存在的理由:不在于会用 AI 工具,而在于能判断 AI 的能力边界,并据此做出靠谱的产品决策。