【无标题】 - 技术栈

把客服对话交给 Agent 生成问题报告，关键是让每条判断都有明确身份：用户实际说了什么，团队据此推断了什么，还需要验证什么。先摘录事实并绑定来源，再归类问题，最后写建议；不能让模型直接把零散抱怨拼成已经确认的产品故障。表达流畅的报告，也可能把使用困惑、功能需求和真实异常混在一起。

这类分析适合放进 Agent Runtime：固定反馈范围，读取材料，输出结构化摘录，再交给人核对结论。ZGI 是可自托管的 Agent Runtime，可以组织文件输入、模型调用与可视化 Workflow，并检查运行步骤和结构化输出。具体的来源字段、归类标准和复核规则，需要团队围绕反馈材料设计。

输入范围应写清渠道、时间段和材料类型。客服工单、访谈纪要与公开评论的表达方式不同，不能混成同一种证据。资料进入分析流程前，先去除无关个人信息，为每段材料保留内部可查的来源编号；提供给模型的内容只包含完成分析所需的信息，原始记录仍按团队既有权限管理。

事实摘录可以保留来源编号、原话、发生场景和用户描述的结果。以流程设计示例来看，"找不到导出入口"能说明入口发现困难，不能直接证明导出功能损坏；"导出后文件打不开"说明用户遇到结果异常，仍需核对文件、操作步骤和环境。模型应保留这种差别，不在摘录时替用户补上未经提供的原因。

归类标准也要先确定。可以区分操作困惑、结果异常、功能需求和资料不足，并允许一段反馈带有多个标签。用户同时提到找不到入口和希望增加格式，就应分别保留两个问题。信息不足时标成待确认，比强行塞进一个确定类别更便于后续排查。

统计之前还要确定计数对象。一个人在多轮对话里反复提到同一问题，不能每次都算作新的受影响用户。反馈条数、对话数和去重后的用户数是不同口径；缺少能可靠去重的标识，就只报告材料范围内的反馈条数。样本来自某个渠道时，结论也只能说明这批材料，不能扩展成所有用户的意见。

问题摘要应同时保留支持材料与相反线索。某条反馈说操作失败，后续客服回复却说明补齐配置后已完成，报告就应呈现问题如何变化。只提取最初的负面句子，会让已解决的使用问题看起来仍是持续故障；只读取最后的成功回复，又会掩盖用户此前遇到的障碍。

建议与事实采用不同字段。事实写"材料中出现了哪些描述"，原因推断写"可能与什么有关"，建议写"下一步检查或调整什么"。每项建议关联来源编号，并说明还缺哪些证据。入口位置难找可以提出检查导航与说明文案；性能抱怨需要运行记录或复现材料，不能凭反馈直接给出延迟结论。

优先级也需要人的业务判断。模型可以整理问题类别、材料数量和影响描述，但不能仅凭语气强烈就认定问题严重。团队可以结合受阻步骤、是否有替代路径和已核实的影响范围排序。没有完整材料的项保留为待核实，不与已经复现的问题采用相同确定语气。

在 ZGI 的 Workflow 中，可以将事实摘录、问题归类和建议整理保存为独立产物，再用运行步骤与输出检查哪一环引入了推断。这个流程需要自行定义字段和检查条件，不能把结构化输出等同于内容已经真实。来源存在，只能说明材料可追溯；结论是否符合材料，还要逐项复核。

验收时选取一段多问题对话、一段缺少操作细节的反馈，以及一段后续已解决的记录，检查报告是否保留原话、是否重复计数、是否把推断标成事实。每条建议能找到对应材料，并能说清下一步还需确认什么，这份报告才具备进入产品讨论的基础。