贯穿案例：一个知识客服如何工作

01先定义一个有限的服务范围

教学场景：一个课程服务提供方希望回答课程安排、资料位置和已公布的服务规则。它可以查询公开通知和授权知识，但不自动作出退款决定，也不向无权限的人展示其他学员的信息。这个场景用于解释产品链路，不是某家公司已上线系统的案例或实测结果。

用户输入可能含糊，例如“我上次的资料在哪里”。系统需要判断“上次”对应什么；缺少身份或课程信息时，先澄清比编造链接更有价值。

02从提问到处理完成

系统先判断问题属于知识查询还是需要操作。知识查询走检索并附来源；涉及个人进度的请求需要适当身份与数据访问；需要修改记录的任务应按业务规则确认；无法回答的问题转给人工，并保留必要上下文。

03用具体失败说明协作

如果引用旧通知，运营需要检查知识更新；如果新通知已经在库但没检索到，算法和开发需要检查检索；如果接口返回失败而页面说成功，开发与产品需要检查状态表达；如果人工仍需从头问一遍，产品可以检查交接信息是否足够。

这些问题不一定需要训练新模型。改文档、改流程、改工具说明和改检索都可能影响结果。先定位环节，再决定处理方式，能避免用技术名称替代问题分析。

04这个系统应该怎样被评价

知识问答看答案是否被当前材料支持；操作任务看动作是否在允许范围内完成；人工交接看上下文是否有效传递。还需考虑用户等待时间和单次服务成本。回答更长、模型更大或节点更多，都不能单独证明服务更好。

一个实习岗位可能只负责这条链路的一段。读 JD 时，把“维护知识库”“设计评测集”“开发 Agent”放回这里，就更容易理解具体日常，而不是把它们都理解成从零搭建整个系统。