【交叉评测】知客业务报告闭环已跑通，但 API 失败反馈、结果可验证性与 KPI 确认流程仍需补强 #5
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
1. 项目理解
我了解到知客 ZhiKe AI 是一个面向业务员的目标驱动型业务处理 Agent。项目把微信聊天记录、客户备注、电话纪要或会议记录转化为客户档案、需求分析、机会判断、跟进计划、沟通话术和业务日报，并通过业务员确认反馈更新当前会话内 KPI。
页面将能力概括为“客户理解 → 业务判断 → 行动生成 → KPI 反馈”，同时明确最终发送和业务决策由人工确认，KPI 只统计业务员确认后的反馈。
2. 项目优点
2.1 业务流程清楚
Demo 拆分信息输入、客户档案、需求分析、机会判断、跟进建议、沟通话术和业务日报七个阶段，符合业务员实际工作过程。
2.2 输入门槛低
支持直接粘贴微信聊天记录、客户备注、电话纪要、会议记录和聊天摘要；信息不完整时仍可生成，并将缺失内容标记为“未知/待确认”。
2.3 提供可复现案例
页面提供企业培训客户、课程顾问客户和企业服务客户三个案例，可自动填充输入框，降低首次体验成本。
2.4 目标和 KPI 配置完整
支持目标周期、周期总工作日、剩余工作日、新增合格客户、有效沟通、方案沟通/演示和重点客户推进，并提供保存目标操作。
2.5 报告生成流程成功
本轮通过 Chrome DevTools 打开 Demo，点击“案例 1 · 企业培训客户”，再点击“生成业务报告”。页面显示“业务报告已完成 / Report ready”，并显示 API Skills 7、本地 Mock Skills 0、安全回退 0。报告包含客户档案、客户需求分析、业务机会判断、跟进建议和沟通话术，核心需求被提取为“了解 AI 员工如何帮助销售团队做客户跟进”。
2.6 数据边界说明明确
页面显示 MiniMax API 已配置/Connected、会话内 KPI、No Database、Session only / Not persisted，并说明无数据库、登录、CRM 或微信接入，不保存客户数据，最终发送和业务决策由人工确认。
3. 当前问题
3.1 页面存在 404 资源错误
Chrome DevTools 控制台捕获：
虽然主页面和报告生成仍可运行，但 Demo 存在资源加载失败。建议通过 Network 面板定位具体 URL，在 CI/CD 中加入部署后静态资源完整性检查，并为关键资源失败提供用户可见提示。
3.2 报告生成过程缺少清晰 loading 状态
点击生成后需要等待 API/Agent 处理，但按钮状态和阶段反馈不够明显。建议显示提取客户信息、分析需求、判断机会、生成建议、生成话术、汇总日报等阶段；生成期间禁用重复点击，失败时保留原始输入并支持重试。
3.3 API 失败和安全回退路径缺少可验证演示
页面显示 API Skills 7、本地 Mock Skills 0、安全回退 0，但尚不清楚 API 超时、空内容、限流、格式错误、单个 Skill 失败和全部 API 不可用时如何处理，也不清楚回退结果是否会被误认为真实模型结果。
建议增加故障演示或测试开关，展示当前运行源、回退状态、失败原因和结果来源。回退结果必须明确标记“回退生成”。
3.4 “Connected” 状态定义不清
Connected 可能代表 API Key 存在、最近请求成功、当前会话请求成功、服务端配置完成、网络可达或模型返回有效结果。
建议拆分配置状态、连通状态、最近请求、响应时间和当前报告来源，不要用单一 Connected 覆盖多个含义。
3.5 报告字段缺少事实、推断、确认状态区分
页面说明缺失内容会标记为“未知/待确认”，但各字段没有充分区分原始材料直接提供、模型推断、业务员确认和缺失内容。业务员可能把模型推断误认为客户明确表达。
建议为每个字段标记来源和状态，例如“来源：客户原话”“来源：模型推断”“状态：待业务员确认”。
3.6 机会判断缺少依据和人工修改入口
机会判断会影响后续行动，但用户需要看到使用的客户信号、缺失字段、未确认假设、判断置信度和替代解释。
建议允许业务员修改预算状态、购买时间、决策人身份、需求紧迫度、机会阶段和下一步动作。修改后重新生成跟进建议和话术，并保留模型原始判断与人工修正结果。
3.7 跟进建议和话术需防止未经确认直接发送
页面说明最终发送由人工确认，方向正确。建议界面使用“复制话术”而非直接发送，增加人工确认、发送前二次检查、敏感内容提示、客户称谓/价格/时间校验、发送对象确认和业务员编辑记录。
3.8 KPI 会话内反馈闭环不够可见
页面说明 KPI 仅根据业务员确认反馈更新，但本轮主要验证报告生成，未清楚看到反馈确认入口、KPI 数字变化、业务日报变化、撤销能力、刷新后的数据状态和会话结束后的销毁行为。
建议增加可复现流程：生成报告 → 选择跟进结果 → 业务员确认 → KPI 变化 → 业务日报更新 → 显示仅当前会话保存。若尚未实现，应明确标注报告生成已实现，反馈/KPI 闭环为演示或待实现。
3.9 “无数据库、不保存客户数据”需要更可验证
页面文字无法证明客户文本是否发送给 MiniMax API、第三方是否保存请求、Streamlit session 是否保存输入、日志/错误追踪是否包含客户信息、浏览器是否缓存输入。
建议补充哪些内容会发往第三方模型 API、第三方保留政策、应避免输入的真实敏感信息、Session 销毁时机、日志脱敏策略，以及关闭外部 API、强制 Mock 模式的方式。
3.10 中英文混排影响业务使用
页面包含 W3 AGENT DEMO、Goal Period、Customer Input、Report ready、API Skills、Session only、No Database 等术语。建议中文作为主界面，英文放入 tooltip 或辅助说明，并统一“会话内保存”“仅当前会话有效”“不持久化”等中文术语。
4. 建议优先级
P0：结果可信度和隐私
P1：异常流程
P2：业务闭环
5. 综合评价
知客 Demo 方向清楚，输入、客户理解、业务判断、行动生成和 KPI 反馈形成较好的业务闭环。本轮实测报告生成成功，能从客户沟通记录提取核心需求并生成客户档案、需求分析、机会判断、跟进建议和沟通话术。
当前重点不是功能入口缺失，而是结果可解释性、异常路径和数据边界。API 状态定义、模型推断与事实区分、KPI 人工确认闭环，以及客户数据发送给第三方模型 API 后的隐私边界，应作为下一轮重点。