haoee接到一个制造业售后智能体，为什么要先做需求分诊？

制造业客户经常会提出这样的需求：

“我们想做一个设备售后 AI，员工能查手册，工程师能看故障，管理者能看维修数据，最好还能自动派工单。”

这类需求并不是一个功能，而是一条完整业务链。

它至少包括知识问答、故障分析、数据查询、工单创建、派工和状态修改。如果直接从系统集成开始，项目很容易陷入反复确认和持续加需求。

这次演示中，我选择先搭建一个“客户项目交付分诊助手”，让交付伙伴先完成需求识别，再决定后续是否搭建设备知识助手。

实际架构

当前编排只有两个节点：

开始节点 -> 需求拆解与交付建议节点

开始节点接收客户原始描述，第二个节点负责输出六部分内容：

• 需求类型；
• 目标用户；
• 资料清单；
• 建议搭建对象；
• 第一阶段范围；
• 人工确认事项。

例如客户说：

希望员工能够查询设备操作规范，售后工程师能够根据故障描述得到排查建议。

智能体不会直接说“可以完成设备维修”，而是先识别：

• 员工侧是设备知识问答；
• 工程师侧是维修辅助分析；
• 需要准备设备说明书、操作规范、故障代码和历史案例；
• 第一阶段可以先做基于资料的问答和排查建议；
• 涉及停机、维修和安全判断时，需要工程师复核。

知识库的作用

当前绑定的是《客户项目交付分诊助手 FAQ》，它不是设备手册，而是用来规范项目交付判断。

知识库主要记录：

• 哪些需求适合知识库问答；
• 哪些需求需要独立智能体；
• 系统接入前要确认哪些信息；
• 哪些操作需要人工审核；
• 如何划分第一阶段和后续阶段。

如果继续建设设备售后助手，还要再导入设备说明书、操作规范、故障案例等专业资料。项目交付知识和行业业务知识应该分开管理，避免后续维护混乱。

模型与评估

当前模型使用deepseek-v4-flash。原因是当前任务以需求分类和结构化输出为主，不需要复杂推理。

节点开启了评估，最多评估两次，主要检查：

• 是否漏掉客户资料要求；
• 是否将知识问答和系统集成混为一谈；
• 是否给出清晰的第一阶段范围；
• 是否对工单写入保留人工确认；
• 是否把演示能力写成生产能力。

测试结果

测试问题一：

客户已经有设备手册和故障记录，希望员工能查询，工程师能获得排查建议。

智能体可以将其拆成知识问答和辅助分析，并建议先整理资料、划分用户权限、准备测试问题。

测试问题二：

客户希望 AI 自动读取订单、创建工单、派给工程师并修改维修状态。

智能体应将其拆分为查询、风险提示、工单创建和状态修改几个阶段，不能把所有动作一次性承诺。

测试问题三：

客户想做制造业售后 AI，帮助员工提高效率。

智能体会提示需要补充用户角色、设备类型、资料情况、现有系统和人工审核要求。

交付伙伴为什么需要这样的底座

对于交付伙伴来说，真正耗时的工作往往不是第一次做 Demo，而是：

• 每个客户都重新搭建环境；
• 每次都重新整理知识库；
• 不同客户资料容易混淆；
• 交付后无法快速定位问题；
• 项目无法复制到下一个客户。

公网 B 端平台的价值，在于帮助交付伙伴管理客户项目、复用智能体模板、沉淀知识与能力资产，并支持项目从搭建、测试到发布后的持续运营。

不过，当前演示只完成了需求分诊和交付建议，尚未接入真实设备系统，也没有真实生产数据。后续如果涉及工单创建、状态修改等动作，仍需要权限、日志和人工审核。

对制造业 AI 项目来说，第一步不是做一个什么都能做的助手，而是先把客户最明确、最容易验证的一个问题跑通。