把客服对话交给 Agent 生成问题报告关键是让每条判断都有明确身份用户实际说了什么团队据此推断了什么还需要验证什么。先摘录事实并绑定来源再归类问题最后写建议不能让模型直接把零散抱怨拼成已经确认的产品故障。表达流畅的报告也可能把使用困惑、功能需求和真实异常混在一起。这类分析适合放进 Agent Runtime固定反馈范围读取材料输出结构化摘录再交给人核对结论。ZGI 是可自托管的 Agent Runtime可以组织文件输入、模型调用与可视化 Workflow并检查运行步骤和结构化输出。具体的来源字段、归类标准和复核规则需要团队围绕反馈材料设计。先保留原话再决定问题属于哪一类输入范围应写清渠道、时间段和材料类型。客服工单、访谈纪要与公开评论的表达方式不同不能混成同一种证据。资料进入分析流程前先去除无关个人信息为每段材料保留内部可查的来源编号提供给模型的内容只包含完成分析所需的信息原始记录仍按团队既有权限管理。事实摘录可以保留来源编号、原话、发生场景和用户描述的结果。以流程设计示例来看“找不到导出入口”能说明入口发现困难不能直接证明导出功能损坏“导出后文件打不开”说明用户遇到结果异常仍需核对文件、操作步骤和环境。模型应保留这种差别不在摘录时替用户补上未经提供的原因。归类标准也要先确定。可以区分操作困惑、结果异常、功能需求和资料不足并允许一段反馈带有多个标签。用户同时提到找不到入口和希望增加格式就应分别保留两个问题。信息不足时标成待确认比强行塞进一个确定类别更便于后续排查。统计之前还要确定计数对象。一个人在多轮对话里反复提到同一问题不能每次都算作新的受影响用户。反馈条数、对话数和去重后的用户数是不同口径缺少能可靠去重的标识就只报告材料范围内的反馈条数。样本来自某个渠道时结论也只能说明这批材料不能扩展成所有用户的意见。改进建议要带着证据和待验证项交付问题摘要应同时保留支持材料与相反线索。某条反馈说操作失败后续客服回复却说明补齐配置后已完成报告就应呈现问题如何变化。只提取最初的负面句子会让已解决的使用问题看起来仍是持续故障只读取最后的成功回复又会掩盖用户此前遇到的障碍。建议与事实采用不同字段。事实写“材料中出现了哪些描述”原因推断写“可能与什么有关”建议写“下一步检查或调整什么”。每项建议关联来源编号并说明还缺哪些证据。入口位置难找可以提出检查导航与说明文案性能抱怨需要运行记录或复现材料不能凭反馈直接给出延迟结论。优先级也需要人的业务判断。模型可以整理问题类别、材料数量和影响描述但不能仅凭语气强烈就认定问题严重。团队可以结合受阻步骤、是否有替代路径和已核实的影响范围排序。没有完整材料的项保留为待核实不与已经复现的问题采用相同确定语气。在 ZGI 的 Workflow 中可以将事实摘录、问题归类和建议整理保存为独立产物再用运行步骤与输出检查哪一环引入了推断。这个流程需要自行定义字段和检查条件不能把结构化输出等同于内容已经真实。来源存在只能说明材料可追溯结论是否符合材料还要逐项复核。验收时选取一段多问题对话、一段缺少操作细节的反馈以及一段后续已解决的记录检查报告是否保留原话、是否重复计数、是否把推断标成事实。每条建议能找到对应材料并能说清下一步还需确认什么这份报告才具备进入产品讨论的基础。GitHubhttps://github.com/zgiai/zgiGiteehttps://gitee.com/zgiai/zgi