两个 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 是从市场部转来的客户投诉中获知的，因为客户使用的是“语气”一词，而不是“退化”。

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

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

标准答案——“对齐路线图 (roadmap)”——在这里行不通，因为路线图的粒度不对。路线图对齐的是我们要构建的内容。而回归 (regression) 发生在发布之间。正确的产物是一个共享的发布日历，并遵循两条规则：

提示词或模型变更在没有产品负责人 (product-owner) 签字前不能发布。签字并不意味着产品经理 (PM) 要阅读代码差异 (diff)。它意味着平台 PM 已经用产品语言说明了用户可见的行为变化，并且产品 PM 已经决定了面向客户的仪表盘、支持团队和帮助中心文案是否需要随之调整。

呈现新意图的 UX 变更在没有评估 (eval) 覆盖前不能发布。覆盖并不意味着完美的评估；它意味着在进入流量之前，平台 PM 已经获知了新的意图，并在评估套件中添加了至少一个切片——哪怕是粗略的。否则，新的意图就会在无人监管的情况下悄悄上线。

发布日历存在于一个统一的地方，且两位 PM 都必须查看。这听起来像是一种流程税。确实是，但它比事后补救的成本要低。

终结争论的单一仪表盘

两个 PM 的问题催生了两个仪表盘：一个是由产品 PM 关注的行为仪表盘（CSAT、完成率、升级率、解决时间），以及一个由平台 PM 关注的质量仪表盘（评估得分、延迟、拒绝率、单次调用成本）。每一方都会将对方的指标合理化为“不同的关注点”。

补药是一个包含两部分的仪表盘，放在同一个页面上，按相同的群组 (cohorts) 进行切片，并带有标注，标明提示词或模型变更发布的时刻以及 UX 变更发布的时刻。不是一个统一的分数——那会抹平信号。而是一个字面意义上的垂直堆叠：上方是行为，下方是质量，变更标注作为垂直线贯穿两者。当 CSAT 在提示词更改的同一天下降时，任何一位 PM 都无法拿另一张图表来争辩。当 CSAT 在 UX 更改一周后下降时，因果关系也清晰可见。

行业建议将仪表盘保持在 5 到 8 个指标，这里同样适用。重点不在于更多的指标。重点是将它们放在同一个框架内，这样两位 PM 就无法只看互不重叠的信号。

从第一分钟起建立跨职能事故频道

当回归发生时，两个 PM 的分工会产生分类 (triage) 问题。产品 PM 开启一个事故单；平台 PM 在 40 分钟后才通过工程师的提醒得知。40 分钟足够让产品 PM 认定一个不包含提示词在内的解释，这足以让平台 PM 产生先入为主的防御心理，也足以让解决时间增加一天。

一个从第 0 分钟起就同时呼叫两位 PM 的常设事故频道——不是作为一种礼貌，而是作为强制出席——解决了小问题。它解决的更大的问题是制度层面的：它教会组织，AI 的回归是共同的回归，而且“这是产品问题还是模型问题？”这个问题的答案通常是“都是”。

四个产物的 RACI 模型

针对四个边界产物，明确写下 RACI。不是针对整个 AI 功能的 RACI——那已经做过了，但没起作用。而是针对以下每一项的 RACI：提示词 (prompt)、评估集 (eval set)、工具描述 (tool descriptions)、帮助中心文案。对于每一项，指明谁负责执行 (Responsible，进行修改)、谁负责问责 (Accountable，签字确认)、谁需咨询 (Consulted，必须征询意见)、谁需知会 (Informed，必须告知)。

在实践中行之有效的惯例是：平台 PM 是提示词和评估集的负责人 (Responsible)，产品 PM 负责问责 (Accountable)。产品 PM 是帮助中心文案的负责人 (Responsible)，平台 PM 需被咨询 (Consulted)。工具描述由双方共同负责 (Responsible) 并需要双方签字，因为它们是最常被作为“小微调”修改，却最常导致行为变化的产物。关于跨职能 AI 治理团队的行业数据表明，拥有明确所有权模型的组织部署速度更快，且部署后的合规问题更少——其机制仅仅是因为更少的产物在边界处被遗弃。

RACI 不会自动执行。但它在复盘时提供了具体的依据，当追问“谁本该发现这个问题”时，这个在未回答状态下会演变成下一次回归的问题，就有了答案。

更深层次的领悟

这个问题不断反复的原因在于，AI 功能是第一种实现语言本身就是一等用户体验产物的产品表面。在传统的 SaaS 功能中，实现语言（TypeScript、Go、SQL）对用户是不可见的——UX 是表面，代码是底层。提示词不是底层。它是表面，用编写帮助中心时所用的同一种英语表达，由不同的 PM 根据不同的变更控制流程、基于不同的“发布”定义进行编辑。

这就是为什么两个 PM 的分工比传统 SaaS 中类似的“平台团队对阵产品团队”问题更难。在传统 SaaS 中，平台与产品的边界是 API 合约；边界处的产物是强类型的，围绕 API 合约的变更控制仪式也是广为人知的。在 AI 功能中，边界处的产物是自然语言，而自然语言的变更控制是大多数组织尚未建立的新仪式。

识破这一点的团队不一定会合并这两个 PM 角色。他们会保留分工并建立仪式——共享日历、单一仪表盘、联合事故频道、四个产物的 RACI——使这种分工变得可行。没能做到的团队将继续支付协调税，而这种税将持续体现为仪表盘无法解释的用户流失指标。

本周行动建议

如果你的团队符合这种模式，并且你想做出一个具体的改变，那就从仪表盘（Dashboard）开始。共享发布日历是杠杆率最高的工具，但它需要两名 PM 重新协商各自的节奏，这往往需要一个季度的沟通。仪表盘是构建成本最低的工具，而且它能立即改变对话氛围：下次有人再说“这不是模型问题”时，反驳该观点的图表就与他们所指的图表呈现在同一个屏幕上。从那时起，发布日历、事故频道和 RACI 往往会接踵而至，因为每一个工具都会显而易见地成为下一个缺失的关键环节。

“两个 PM”的问题是可以解决的。只是它无法由任何一位 PM 单独解决，而这恰恰是导致该问题长期存在的原因。