制造业售后场景很适合引入智能体，但它也很容易在需求阶段被做复杂。
一个客户可能同时提出：
员工查询设备说明书；
售后工程师检索故障案例；
管理者查看维修数据；
AI 自动判断故障风险；
自动创建工单；
自动分配工程师；
修改维修状态。
这些目标分别对应知识库、数据服务、流程编排和业务系统写入，不能用一个提示词解决。
这次演示选择的不是“设备维修万能助手”，而是先搭建一个客户项目交付分诊助手，在 Haoee 上验证交付伙伴如何处理制造业 AI 项目。
- 场景拆解
假设客户是一家设备制造企业，已有设备说明书和部分维修记录，希望构建售后 AI。
交付伙伴需要先确认：
目标用户是普通操作员还是维修工程师；
资料是否包含设备型号和版本；
故障记录是否可以直接使用；
是否需要查询订单或工单；
是否涉及业务数据写入；
什么结果必须由专业人员确认。
如果不先确认这些内容，直接接入工单系统，后续很容易出现权限和责任边界问题。 - 当前搭建结构
实际演示采用两节点编排：
用户输入项目需求
需求拆解与交付建议↓
第一节点负责接收自然语言需求，第二节点输出：
需求类型：
目标用户：
资料准备：
建议搭建对象：
第一阶段范围：
人工确认事项：
这种结构的好处是输出稳定，便于交付伙伴把回答直接转换成项目清单。 - 知识库设计
当前知识库名为《客户项目交付分诊助手 FAQ》，内容定位是项目交付控制层，而不是设备专业知识库。
其中包括：
知识问答项目的资料要求；
设备类项目的常见拆分方式；
系统接入前的确认项目；
高风险操作的人工确认边界；
第一阶段 MVP 的划分方法；
测试问题编写规则。
如果进入第二阶段，需要新建或追加设备业务知识库，内容包括设备手册、故障代码、保养规范、维修案例和安全要求。
项目交付知识与设备业务知识分层，有利于后续客户隔离、版本管理和知识维护。 - 模型选择
当前使用 deepseek-v4-flash，任务重点是：
识别需求；
提取实体；
生成清单；
按格式输出；
识别缺失信息。
因此，不需要把所有任务都交给最强模型。模型选择应当与任务复杂度、响应稳定性和成本控制一起评估。 - 评估规则
当前节点开启评估，最多两次。评估关注四件事：
是否把知识问答、故障分析和系统集成分开；
是否明确资料准备要求；
是否限定第一阶段范围；
是否对工单写入、派工和状态修改保留人工确认。
对企业项目来说，评估不是为了给回答打一个漂亮分数，而是为了发现交付遗漏。 - 测试
测试输入：
客户希望员工查询设备手册，工程师根据故障现象获得排查建议。
智能体应建议：
先导入设备说明书和操作规范；
按设备型号整理资料；
对不同用户设置访问边界；
使用历史故障问题制作测试集；
排查建议由工程师确认。
测试输入：
客户希望 AI 自动判断维修风险、创建工单并派工。
智能体应拆分为：
信息读取；
辅助分析；
工单创建；
派工；
状态修改。
其中写入系统的动作不能直接当成普通文本生成，需要进一步确认系统接口、权限、日志和人工审批。
- 当前版本边界
本次演示已经跑通：
项目需求输入；
FAQ 知识参考；
需求结构化拆解；
第一阶段建议；
越界需求提醒；
人工确认边界。
尚未完成：
真实设备资料导入；
真实工单接入；
生产环境运行；
自动派工；
自动修改维修状态；
真实效果指标验证。
所以，这个案例更准确的说法是“制造业设备售后 AI 项目前置分诊演示”。 - 对交付伙伴的价值
交付伙伴真正需要的不是每次从零开始搭建，而是一套可以复制的工程流程：
先复制交付模板；
创建客户独立项目；
导入客户资料；
配置模型和智能体；
准备测试问题；
完成人工验收；
发布到客户使用入口；
根据反馈继续维护。
公网 B 端平台面向智能体交付、客户沉淀和持续运营。它不是普通模型 API 封装层，也不是只解决一次性 Demo 的工具。
对制造业场景而言，比较稳妥的路径是先从设备知识问答开始，再逐步增加数据查询、只读系统能力和人工复核流程，最后再评估业务写入。
