Decagon 产品负责人对谈：把十万级客服对话变成产品决策素材的 AI 工作流

AI小蝌蚪AI 前沿2026-09-18895 阅读💛 31 收藏

一句话结论

AI 智能体时代，产品经理与客服团队的分工正在被重写：过去产品团队靠每周翻看过时的仪表盘和 Excel 报表、在质检抽样的工单里碰运气找客户洞察；现在借助于大模型（Anthropic、OpenAI 等带来的阶跃式变化），每周十万级客服对话可以被 AI 直接筛出信号，产品经理能更快定位要修的产品问题，并与客服专家共同编写 AI 智能体的工作流（AOP）——Decagon 智能体产品总监 Max Lithal 与核心产品负责人 Behan 在这场对谈中，完整拆解了这套新协作方式的落地细节。

对谈开场：Max 与 Behan 讨论产品与客服的协作

背景：为什么产品经理和客服越走越近

对谈的背景是 Decagon 的业务观察：Decagon 为企业构建 AI 客服智能体，过去几年与客户体验（CX）团队紧密合作，但最近明显感受到产品经理（PM）这个群体开始更深度地介入 AI 智能体项目。Max Lithal 开场即点题：AI 智能体正在改变产品经理的角色本身，这场对谈就是要讲清楚产品团队和客服团队的协作关系正在发生什么变化。

嘉宾 Behan 是 Decagon 的核心产品负责人（core product lead）。他先回顾了 AI 智能体普及之前的典型状态：产品团队和客服团队的接触往往是定期例会或固定触点，每个产品团队负责一个产品领域，客服组织里有深耕该领域知识的支持专员，双方靠这种”专家对专家”的接口维持信息流动。但问题在于规模——随着公司增长，即使两个团队在同一栋楼里，这条信息通道也会越来越吃力。

过去的工作流：十万级对话前的盲区

Behan 用一个具体数字还原了产品团队过去的困境：假设一个产品每周收到十万（100,000）条客户对话，从纯体量上看，想深入理解全部对话里发生了什么是不可能的——噪音太多，很难从噪音里过滤出信号。产品团队某种意义上是”盲”的，只能寄希望于质检抽样的那批工单里，恰好包含那一两条有价值的线索。

对谈中双方还还原了 AI 出现前的典型分析链路：支持团队靠笨重过时的仪表盘（bulky outdated dashboards）或 Excel 电子表格查看联系率等趋势线的变化，然后可能每周开会把情况同步给产品团队。这条链路的滞后性和粗粒度，决定了客户声音很难直接影响产品排期。

讨论旧流程里数据仪表盘的局限

Behan 特别指出一个关键变化：因为过去没有生成式 AI，团队缺乏强大的客户之声（voice of the customer）理解能力，无法深入钻取每一段对话、精确定位最好的证据。而现在大模型改变了这件事——对话级的理解与聚类成为可能，客户声音从”趋势线”变成了”可点开的具体证据”。

现在的工作流：AI 把对话变成产品决策素材

谈到 AI 时代的新流程时，对谈给出了两个具体的能力支点。第一个是对话理解：借助大模型，产品团队可以把海量客服对话按主题聚类、按严重度排序，直接定位”用户来信在写什么”的高价值话题。Max 在对谈中提到，AI 分析工具（对谈中提到的智能分析能力）在这方面是巨大的助力（huge advent），让产品团队能聚焦在正确的话题上。

第二个支点是对话设计与实验：Decagon 在产品内建了相当完整的 A/B 测试和实验平台（AB testing and experimentation platform），让产品经理能快速迭代和验证自己的想法。Behan 对比了前后差异：过去团队需要先争论”该怎么做”，现在可以直接把两个版本放进实验里跑，让数据回答争论——迭代速度从”会议节奏”变成了”实验节奏”。

介绍实验平台如何加速智能体迭代

Behan 还补充了一个务实的观察：没有任何 AI 智能体的工作流（AOP）从第一天起就是完美的，总有边界情况需要随时间改进。而生成式 AI 的价值在于能快速识别这些缺口，让团队知道该补哪里。

AOP：产品经理和客服专家共建的智能体工作流

对谈中段，两人深入讨论了 AOP（Agent Operating Procedures，智能体操作程序）为什么是产品与客服协作变化的缩影。Behan 的核心论断是：一个好的 AI 智能体是自然语言和代码的结合体（a good AI agent is a combination of natural language and code），而 AOP 正是这种结合的具体形态——用自然语言描述意图和规则，用可执行的流程保证确定性。

这里的协作分工是：产品团队知道自己要构建什么、知道用户在为什么而挣扎，客服支持人员（support people）真正知道用户在说什么、知道每个话题下用户的具体痛点。两者结对（in partnership）共同打磨 AOP，才能保证 AI 智能体既真正解决用户问题，又不越出业务边界。Behan 强调，这与过去”产品写需求、客服执行”的单向关系完全不同，是一种共同创作（co-develop）的新关系。

讲解 AOP 如何由两个团队共同打磨

对谈还讨论了组织归属问题：Behan 观察到，客户之声（voice of the customer）职能的挂靠位置在不同公司差异很大——有的把它放在产品部门下，有的单独建组织，还有的挂到财务或运营下面。他的观察是，关键不在挂靠位置本身，而在于客户之声的洞察是否真的成为产品团队”所发布功能的生命线”（the lifeblood of what we are shipping）。

产品经理的第一步：用 AI 分析工单，主动出击

对谈最实用的部分，是 Behan 给产品经理的立即行动建议（immediate step）。他的原话拆解出来是一个三步操作：

第一步：reviewing support tickets（人工过一遍工单）。产品经理先亲自看一批客服工单，建立对用户真实语言和痛点的一手感知，而不是从报表数字开始。
第二步：applying AI to those support tickets（用 AI 分析全部工单）。把 AI 应用到工单集合上，让模型做主题聚类和优先级排序，找出 top areas of focus（最该关注的头部领域）。
第三步：proactively reach out（主动触达）。基于分析结果主动出击支持用户。Behan 的理由是：等到用户写工单时，他们往往已经相当沮丧，或者已经跨过了很高的行动门槛——每一条工单背后都是被压制了很久的问题，主动处理比被动等待更有效。

给出产品经理的立即行动建议

Behan 还提到新功能发布时的配套动作：产品团队在规划功能时就要想”支持团队要怎么处理它”，落地形式可能是写一篇帮助中心文章（help center article），或者给支持团队一页纸的处理指引（one-pager），讲清这类问题怎么解决。这同样是产品与客服协作的一部分，AI 生成的对话洞察让这类指引的编写更快、更贴近真实用户语言。

角色演化：从”修 bug 的人”到”智能体的共同构建者”

对谈结尾，两人讨论了这场变化对产品经理角色的长期影响。Max 总结道，产品组织现在可以更深地嵌入 AI 智能体的开发过程——这不只是”怎么配置一个 AI 智能体”的问题，还包括”怎么测试它、怎么持续改进它”。Behan 补充了一个支持团队的视角：CX 从业者能获得的杠杆不只来自减员增效（headcount reduction），更来自把每天听到的用户声音系统性地输入产品决策——过去这批洞察基本浪费掉了。

Behan 自己做过一线支持代理（support agent way back in the day），他回忆当时看到某些工单主题的反应是”这问题怎么还没修？“——这种一线直觉正是产品团队最缺的输入。AI 时代，这类直觉不再依赖个人回忆，而是通过智能体对话数据的持续分析变成组织能力。

对谈收尾：总结产品经理角色的演化方向

旧流程的原始形态：报表到路线图的漫长链条

对谈还原了生成式 AI 出现之前，客户声音进入产品决策的完整链条。信息载体是笨重过时的仪表盘（bulky outdated dashboards）或 Excel 电子表格，内容是联系率等趋势线随时间的变化；信息节奏是每周或每两周一次的例会，产品经理和深耕对应产品面的支持专员在会上对齐。Behan 确认这条链路”某种程度上确实有用”——但它有两个结构性缺陷：一是滞后，产品团队拿到的是上周甚至上上周的汇总；二是粗，趋势线能告诉你联系量涨了 15%，但说不出客户具体在抱怨什么。

Max 追问了一个关键细节：拿到这些报表和仪表盘之后，产品经理实际上怎么把它变成路线图事项？是不是就看一眼头部痛点、然后决定修哪些？Behan 的回答坦率地承认了旧流程的局限：产品经理能做的基本就是”看头部痛点、挑能修的修”，因为底层的对话数据没有能力打开——你不知道每条趋势线背后客户用的原话、具体的卡点、以及情绪强度，排期决策只能靠经验拍板。这正是 AI 介入后改变最大的地方：从”看总量”变成”读个案”，从”凭经验排优先级”变成”按证据排优先级”。

转折点：大模型的阶跃式变化

Behan 把变化归因于大模型带来的阶跃式（stepwise）能力跃迁。过去不是没有文本分析工具，但它们只能做关键词匹配和规则分类，理解不了”客户在描述同一个问题的两种说法”这种基础的语言现象。大模型让对话级的语义理解第一次变得可用：同样十万条对话，过去只能聚成几十个类别看数量，现在可以按语义聚类、按业务影响排序、按严重度分级，产品团队第一次拥有了”点开任何一条趋势看到原始证据”的能力。

对谈中 Max 补充了 Decagon 侧的观察：LLM 的阶跃变化横扫了几乎所有职能部门，客户体验只是最先被改造的一个；而产品经理是最近一年才大规模进入 AI 智能体项目的群体，他们带来的实验方法和数据敏感度，正在反过来改变智能体产品的迭代方式。

智能体 PRD：产品经理的新交付物

对谈中 Behan 提出了一个正在成型的概念——智能体 PRD（agent PRD）。传统产品经理的核心交付物是产品需求文档，定义功能、边界和验收标准；而在 AI 智能体项目里，这个角色的交付物变成了智能体的能力定义：它该会什么、不该会什么、遇到边界情况怎么处理、怎么判断一次交互算成功。Behan 认为构建一个好的智能体需要几个核心能力桶（core competencies or core buckets）——这正是产品经理的专长领域：定义问题、拆解场景、设计验收。

其中一个关键能力是”把人带回环里”（bring a human in the loop）：智能体在什么置信度下自己回答、什么情况下转人工、转人工时带给坐席哪些上下文——这些设计决策直接决定客户体验的下限。另一个能力是对 API 端点的理解：智能体的”能做事”最终要落到系统能力上，产品经理需要知道哪些动作可以开放给智能体调用、哪些必须锁死。这两个能力恰好横跨了产品经理的传统技能栈和 AI 时代的新要求。

从”拦截工单”到”消灭问题根源”：客服目标的上移

对谈中最具战略高度的一段，是关于客服目标函数变化的讨论。Max 提出一个内部争论已久的观点：支持团队”拦截工单、控制工单”（deflecting and containing tickets）这个目标本身，是历史条件的产物——它诞生于人力资源有限的年代，本质上是在”帮客户解决问题”和”有多少人力可用”之间做折中。这个目标函数优化到极致，最好的客服就是零接触的客服——问题都被挡在了发生之前。

Behan 认同这个框架的推论：当 AI 把单次交互的成本压到足够低，“拦截”就失去了优化价值，客服团队的目标函数应该上移到”消灭问题的根源”——每一次交互都是一次诊断机会，对话数据直接指向产品缺陷，修复缺陷比处理工单更根本。在这个框架下，CX 团队的杠杆不只来自人力 ROI（headcount ROI），更来自他们与产品经理做同一种分析的能力：哪些主题和工单该自动化、人工支持流程怎么优化、SOP 和培训怎么迭代。客服团队从”工单处理车间”变成”产品问题的前哨诊断站”。

组织挂靠的三种形态与共同命门

对谈专门讨论了客户之声（voice of the customer）职能的组织归属问题，因为这是很多公司启动 AI 分析项目时绕不开的第一个组织决策。Behan 观察到三种常见形态：第一种挂在产品部门下，理由是客户声音直接服务产品决策；第二种单独成立组织，直接向高管汇报，保持跨部门的独立性；第三种挂在财务或运营下，把客户声音当作经营指标的一部分。三种形态各有合理性，他也见过同一公司在不同阶段来回切换的案例。

但 Behan 强调，挂靠位置本身不是成败关键——真正的命门是客户之声的洞察有没有成为产品团队”所发布功能的生命线”（the lifeblood of what we are shipping）。如果洞察只是躺在报告里，挂在哪里都没用；如果洞察真的进入了每次发布的决策链，任何挂靠方式都能跑通。判断标准很简单：产品团队做排期决策时，会不会主动引用对话分析的证据？如果会，这个组织的客户之声就是活的。

这个讨论对正在立项的企业有直接参考价值：不要在组织架构上过度设计，先把”对话洞察进入排期会”这个流程跑通，挂靠问题让规模和复杂度倒逼出答案。

一线经验的回归：Behan 的工单直觉

对谈中一个容易被忽略的细节是 Behan 的个人背景：他职业生涯早期做过一线支持代理（support agent way back in the day），亲手处理过工单。他回忆当时的体验：看到某些反复出现的工单主题，第一反应是”这个问题为什么还没修？“——这种来自一线的直觉，是任何仪表盘都给不了的产品洞察。

他借此指出 AI 时代的一个机会：过去这种一线直觉依赖个人记忆和个人影响力（一个前支持代理要说服产品团队修某个问题，需要跨越组织层级），现在 AI 把全量对话分析摆到每个人面前，一线团队的直觉可以被数据即时验证，产品团队也能直接看到”哪个问题被客户反复提到”。直觉与数据的结合，让组织里最接近客户的角色第一次拥有了与产品团队对称的信息基础。

这也是他对 CX 从业者的职业建议背后的逻辑：客服背景不是转型的包袱，而是 AI 时代的稀缺资产——懂客户的人加上会用 AI 工具的人，就是新一代产品组织最需要的角色。

边界情况：智能体永远不会一次写对

对谈用相当篇幅讨论了一个务实话题：AI 智能体的 AOP（智能体操作程序）从第一天起就不可能是完美的，边界情况（edge cases）需要随时间持续识别和修补。Behan 用了一个对产品经理非常友好的表述：这本质上就是产品打磨的老问题——上线只是开始，真实用户会把你没想到的情况逐一暴露出来。区别在于，智能体的边界情况暴露得更快（每通对话都是一次测试），修补的反馈周期也更短（改一段自然语言规则，不用发版）。

具体到操作层面，Decagon 的做法是把 A/B 测试和实验平台内建到产品里：智能体的应答策略、话术、流程改动能以实验形式灰度上线，用真实对话数据判定胜负。Behan 说这改变了产品团队的争论方式——过去是会议室里比谁嗓门大、谁职级高，现在是”两个版本都跑一周，数据说话”。实验文化把迭代速度从”会议节奏”切换到”实验节奏”，这是 AI 智能体项目与传统软件项目在工程文化上的最大差异。

对准备立项的团队，这段讨论的启示是：不要把智能体的初始 AOP 当成需要一次做对的完美设计，把它当成实验计划的第一个版本。上线前想清楚核心场景的验收标准，上线后按周迭代边界情况，才是符合工具特性的工作方式。

客户成功的分水岭：长周期合作伙伴的共性

对谈后段，Max 分享了 Decagon 内部的一个观察：与那些合作周期较长的客户打交道时，能明显看到一个分水岭——走过某个阶段后，客户的智能体项目会从”工具采购”变成”能力内化”。标志性变化是产品团队开始主动参与智能体的构建和测试，而不是把项目完全外包给供应商；对话分析不再是一份购买的报告，而是内嵌进产品周会的常规输入。

Behan 补充了这些”毕业”客户的三个共性：第一，有明确的场景收口——不是全面铺开，而是先在一两个产品面上跑透；第二，建立了产品经理与客服专家的固定协作机制，AOP 的每次迭代都有双方签字；第三，把智能体的迭代节奏对齐到了产品发版节奏，智能体的能力升级跟着产品走。三个共性没有一个是技术问题，全部是组织与流程设计——这也是这场对谈反复出现的结论：AI 客服项目的成败，大头在组织，小头在技术。