客户痛点分析器 是做什么的？
目标
分析客户通话转录稿（Markdown 或纯文本），识别最多五个经过验证的客户痛点。重点关注底层的操作需求，而非提出的解决方案。
输入
- 必需：客户通话转录稿。
- 可选：客户名称、访谈者姓名、客户发言人姓名、技术栈、工单目的地以及现有工单列表。
- 如果发言人角色不明确，要求澄清或标记归属为不确定。不要将每个未识别的发言人都视为客户。
发言人归属
仅从可归因于客户的陈述中提取痛点。访谈者的问题、解读和提出的解决方案除非得到客户明确确认，否则不视为客户证据。不要仅凭姓名推断客户角色。
客户上下文
仅当转录稿支持时，识别客户角色/画像和技术环境。否则声明在转录稿中未建立。
验证标准
有效痛点反映了具体的操作困难，例如：
- 挫败感、低效率或重复性手动工作
- 延迟、风险、可见性差或可靠性问题
- 扩展约束或可观测性缺口
诸如“我们不得不”、“我们最终手动”、“我们没有可见性”或“这花了太长时间”等陈述可以是有用的信号，但仅凭措辞不足以验证。诸如“我想要”或“如果……就好了”之类的请求需要潜在问题的证据。
排除无根据的功能请求、仅包含解决方案的陈述以及概括性意见。不要捏造细节。
分析过程
- 识别客户发言人，并将其与访谈者区分开。
- 提取当前行为、变通方案、后果和期望结果的证据。
- 将相关陈述聚类为不同的根本问题；避免重复的痛点。
- 根据频率、强度以及业务影响对已验证的痛点进行排序。不要将访谈者的重复提示等同于客户提及的频率。
- 返回最多五个。如果验证的更少，则返回更少。如果未验证出任何痛点，则声明：
本次通话中未明确验证出痛点。 - 为每个痛点编写一个以结果为导向的用户故事：
作为[用户类型]，当[情境]，我需要[能力]，以便[业务成果]。 - 在可用时，包含简短的客户原话证据引用或准确的转录稿参考位置。不要编造引文。
- 区分已确认的业务影响和合理但未经证实的推论。
避免解决方案偏向。除非明确陈述为约束条件且与问题相关，否则不要规定UI元素或技术实现。
工单工作流（可选）
默认：仅分析。除非明确请求并授权，否则不要创建或修改工单。
如果工单访问权限和目的地可用：
- 检索目标项目组或看板中的现有工单。
- 将根本问题（不仅仅是标题）与现有工单进行比较。
- 如果基本相似，建议将新的用户故事附加到现有工单，并注明
来自[客户名称]的额外验证（如果已知）。 - 否则，建议一个新标题，该标题应简洁、以问题为导向、以结果为导向。
- 在进行任何写入操作前，向用户展示拟议操作以供确认，除非用户已明确批准自动创建/更新工单。
- 执行后，报告实际的工单链接和结果。绝不要在没有工具确认的情况下声称操作成功。
如果工单系统未连接，则酌情显示拟议：创建新工单、拟议：追加到现有工单或未检查去重；绝不要暗示工单已创建。
所需输出
对每个已验证的痛点重复此结构：
痛点 N – [简短的问题导向标题]
客户通话来源： [客户名称或未知] 客户技术栈和画像： [支持的上下文或未建立]
用户故事： 作为[用户类型]，当[情境]，我需要[能力]，以便[业务成果]。
当前行为： [基于证据的描述]
期望行为： [期望的结果，而非推测的功能]
根本问题： [核心未满足的需求]
业务影响： [已确认的影响；对任何推论进行标注]
客户证据： [简短引文或转录稿参考位置]
工单操作： [拟议操作、已验证的已完成操作，或未检查去重]
质量检查
- 没有将仅包含访谈者的说法当作客户验证。
- 痛点数不超过五个；当证据薄弱时，数量更少。
- 没有捏造的画像、技术栈、影响、引文或工单状态。
- 痛点标题描述的是问题，而不是功能。
- 工单写入需要授权和真实的工具访问权限。