两个 PM 的难题：当提示词所有权与产品所有权发生偏离时

周二早上收到了一张支持工单：一名客户收到了关于退款期限的、言之凿凿的错误回答。工程团队调取了追踪记录，发现模型识别错了意图。产品 PM 查看仪表板，发现上个迭代发布的“极速退款”入口触发了一个 Prompt 从未针对其进行过调优的意图。平台 PM 指着评估套件（eval suite）说，测试全是绿色的。两人在技术层面都是正确的。但客户得到的回答依然是错的。

这就是“两个 PM 问题”，大多数 AI 团队都存在这个问题，只是没有给它命名。产品 PM 负责面向用户的界面——意图、成功指标、支持升级路径。平台或 ML PM 负责 Prompt、模型选择、评估套件和成本上限。两者的路线图在季度规划层面是协调的，但在每周发布层面却在背道而驰，因为两个 PM 在不同的仪表板上针对不同的指标进行优化，且有着不同的变更控制流程。

这种有趣的失效模式并不是因为两个 PM 意见不合，而是因为他们都在各自的职责范围内正确地完成了发布，却共同导致了一个无人负责的退化（regression）。

为什么这种拆分最初会存在

将 Prompt 所有权与产品所有权拆分并非偶然，也不是不成熟的表现。它通常反映了真实的组织约束：产品 PM 来自现有的 SaaS 业务，了解客户；而平台 PM 的加入（或成长）则是为了负责模型账单、评估套件以及与推理供应商的集成。这两个角色都没有错。这种拆分解决了“我们没有一个人能同时兼顾两头”的人员配备问题。

这也符合行业对这些角色的定义。市场已经趋向于将 AI 产品经理（负责愿景、客户匹配、进入市场）与 AI 产品负责人或 ML PM（负责模型、Prompt 和评估的执行）区分开来。职业阶梯、招聘小组和薪酬等级都围绕这种拆分变得僵化。

问题在于，处于边界处的交付物——Prompt 及其评估套件——并不是后端实现细节。它是产品表面。组织为后端实现细节设立的变更控制流程，对于用户体验交付物来说是错误的。

在两种名义下被编辑的四个交付物

边界在四个特定的交付物周围坍塌。每一个交付物都有“产品形态”的含义和“平台形态”的含义，而大多数团队对于当双方解读不一致时谁该获胜没有约定。

系统提示词（System prompt） 在平台 PM 看来是平台代码（配置文件中的一个字符串，受评估套件约束），在产品 PM 看来是品牌语调（AI 的语气、拒绝什么、如何处理歧义）。当平台 PM 为了削减输出 Token 而调整“更加简洁”时，产品 PM 却是从客户那里得知 AI 变得不如以前友好了。

评估集（Eval set） 在平台方是回归检测器，在产品方是对“什么是好产品”的定义。产品 PM 很少将评估集视为他们可以编辑的东西；平台 PM 很少将其视为需要同步达成共识的东西。因此，评估集编码了一个团队对质量的假设，并据此卡住了另一个团队的发布。

工具描述（Tool description）——即模型读取以决定是否调用函数的 docstring 或 schema——在平台方是 API 文档，在产品方是行为契约。将“创建一个草稿”编辑为“创建一个草稿（仅在用户明确确认意图时）”看起来只是个澄清；实际上，它改变了该工具触发频率的行为。

帮助中心文案和产品内引导 是产品 PM 直接负责的产品文案，它构建了用户对 AI 功能的心理模型。当这些文案承诺了 Prompt 从未调优过的功能时，支持团队就得填补这个鸿沟。

这四个交付物在两种名义下、以不同的节奏被编辑，且没有共同的评审流程。这就是协调成本。

退化实际上是如何显现的

在复盘中反复出现的模式大致如下：

产品 PM 发布了一个 UX 变更，引入了一个新意图——一个按钮、一个建议提示词或一个空状态引导。评估套件对该意图没有覆盖，因为它在上个季度还不曾存在。生产环境的流量在几小时内发生偏移。模型处理新意图的效果很差。由于评估套件未变，平台 PM 查看的仪表板显示为绿色。产品 PM 查看的仪表板显示 CSAT 下降，团队将其归因于 UX 问题，然后是文案问题，直到三周后，才发现是 Prompt 的问题。

镜像式的失败也会发生。平台 PM 将模型更换为更便宜的新变体，运行评估套件，发布结果为绿色。模型在技术上更简洁了，但失去了一种产品 PM 曾私下训练用户去期待的语气风格。产品 PM 是从市场部转来的客户投诉中获知的，因为客户使用的是“语气”一词，而不是“退化”。

对于不拥有该交付物的组织一侧，这两种退化都是不可见的。事后看来，两者都显而易见。问题在于，什么样的纪律能让你有先见之明去捕捉它们。

共享发布日历，而非共享路线图

加载中…