OM-03 · 历史工单知识库检索

① 场景引入

一、这件事现在是什么样

运维与质保工程师 · 真实业务触发

弘锐储能运维团队 14 人，三年累计 1,842 张工单。老师傅 2 人，每天要接 100 多通电话，人一走经验就断。2026 年团队扩到 14 人，其中 6 人入职不满 8 个月，同样的故障反复从头试错。运维总监想要一个「新人能自己查」的东西。

二、痛点 · 每条都有来源

1风电运维「老法师」困境：经验在少数人脑子里，每天要接 100 多通电话，人一走经验就断依据 · 风电运维「老法师」困境：经验在少数人脑子里，每天要接 100 多通电话，人一走经验就断2风电运维数字化的真实价值来自把老师傅的经验转成可检索的方案，而非预测 —— 内蒙古某公司对 1,500 个高发故障方案做本地化标注后，故障处理时长缩短40%依据 · 风电运维数字化案例：内蒙古某公司对 1500 个高发故障方案做本地化标注后，故障处理时长缩短 40% ——价值来自把老师傅的经验转成可检索的方案，而非预测3预测性维护的「试点炼狱」：预警发出后无人负责处置、无排期、无备件、无复盘，试点因此停在演示阶段依据 · 预测性维护「试点炼狱」：预警发出后无人负责处置、无排期、无备件、无复盘，试点因此停在演示阶段4预测性维护落地四大卡点：数据质量、预警后的责任归属、备件与排期配套、闭环复盘依据 · 预测性维护落地四大卡点：数据质量、预警后的责任归属、备件与排期配套、闭环复盘5西门子能源对 BESS 停机的归因是停机主因落在 HVAC、逆变器与 BOP 小件上，备件可得性直接决定停机时长 —— 而备件该不该备，凭的是历史失效规律，不是预测依据 · 西门子能源对 BESS 停机的归因：停机主因是 HVAC、逆变器与 BOP小件，备件可得性直接决定停机时长

三、换个做法之后

变化不在「快」，在「参与的角色」和「覆盖的范围」

✕ 现在的做法

• 风电运维「老法师」困境：经验在少数人脑子里，每天要接 100 多通电话，人一走经验就断风电运维数字化的真实价值来自把老师傅的经验转成可检索的方案，而非预测 —— 内蒙古某公司对 1,500 个高发故障方案做本地化标注后，故障处理时长缩短 40%预测性维护的「试点炼狱」：预警发出后无人负责处置、无排期、无备件、无复盘，试点因此停在演示阶段预测性维护落地四大卡点：数据质量、预警后的责任归属、备件与排期配套、闭环复盘

✓ 交给 Agent 之后

• 多来源文件一次读入，先做口径与完整性校验，再开始算
• 每条结论绑定来源文件、字段或条号，可以被审
• 产出是企业真会流转的正式件（带签批栏），不是一张展示用的表
• 该拦的地方给出「现在还不能提交」，并给不用干等的替代方案

四、场景闭环

5 步 · 每一步的产出都是下一步的输入

1. 工单分级 · 按处理结果栏的实质内容分三档有完整处置步骤的 / 只有结论的 / 只写「已处理」的，逐张归档第2 步方案抽取 · 从自由文本里抽出可复用的处置动作动作序列、所需工具与备件、涉及的安全边界，原文不改
2. 役龄统计 · 按部件类型与投运役龄统计故障次数只统计已发生的次数分布，不做任何外推
3. 备件缺口 · 高频失效部件的在库状态核对高频部件当前在库数量、采购周期、过去 12 个月的领用次数
4. 成稿与标注 · 生成检索库并标注覆盖率首页写明收录范围、覆盖率、不做预测的三条声明；运维负责人审核栏留空

要准备什么：工单系统全量导出（2023-08 至 2026-08，1,842 张）含故障类型、等级、处置时长、处理结果栏 —— 处理结果栏是自由文本，质量参差设备台账与投运日期（Excel）40 台液冷电池舱、40 台 PCS-2500、EMS 与消防系统，逐台投运日期备件库存与采购周期表（Excel）当前在库数量、采购周期、供应商新入职人员排障记录（近 8 个月，微信群导出）6 名新人的提问与答复，用来判断哪些方案最该先上架本司运维职责边界说明（Word，星标）★那份平时不在核对范围内的东西 —— 哪些故障不归运维团队处置须待电网侧确认，这条决定知识库该收什么、不该收什么

为什么这个场景值得做

优先级评分：痛感 4 × AI 适配 4 ÷ 落地难度 2 = 8.8

最大差异点：这是「接住客户第三问并转向」的场景。客户问「能不能做预测性维护」，答案是能做一半：把已经发生过的 1,842 次故障的处置方法变成可检索的，这一半是确定的、今天就能兑现的；而猜未来哪台会坏那一半，行业里的试点大多停在演示阶段 —— 不是算不准，是预警发出后没人负责处置、没排期、没备件、没复盘。把确定性的一半做实，比赌不确定的一半更有用。

评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」；

落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。

五、会产出什么

判断标准只有一个：这份东西能不能直接进企业的流程

• 正式件本体：故障处置方案检索库.xlsx 正式件 · 1,229 条 · 含运维负责人审核栏与三条声明
• 可派发清单：高频故障 TOP20卡.xlsx 可派发 · 每类含动作序列 · 所需工具与备件 · 安全边界
• 可派发清单：备件常备建议与役龄统计表.xlsx 逐部件 ·役龄区间故障次数 · 在库状态 · 采购周期

这套东西不承诺什么：不做故障预测、不做设备健康度评分、不输出「下周哪台会坏」；役龄失效窗口是历史统计事实（这类部件在这个役龄区间的故障次数显著高于其他区间），不是对任何单台设备的预测 —— 这个区别必须写在知识库首页；工单原文的处置描述一个字不改，不做润色、不做归并。

② Live Demo（演示逐步）

本场景的演示数据正在制作中

下面展示的是这个场景的执行骨架与四类看点。完整的逐步演示（含真实表格与拦停结论）见同一角色下已完成的场景。

流程5 步执行骨架

1工单分级 · 按处理结果栏的实质内容分三档有完整处置步骤的 / 只有结论的 / 只写「已处理」的，逐张归档

2方案抽取 · 从自由文本里抽出可复用的处置动作动作序列、所需工具与备件、涉及的安全边界，原文不改

第 3 步 · 役龄统计 · 按部件类型与投运役龄统计故障次数只统计已发生的次数分布，不做任何外推

4备件缺口 · 高频失效部件的在库状态核对高频部件当前在库数量、采购周期、过去 12 个月的领用次数

③ 能力沉淀（Skill / 提示词 / 预期输出 / 人工边界）

1能力沉淀 · 待补充

评审确认后制作可直接导入 WorkBuddy 的能力包

2. 原始素材

这些就是储能集成商手上真实能拿到的东西 —— 格式不统一是常态，不是问题

📁OM-03 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 5 份

本场景素材正在制作中。输入清单见下方「要准备什么」。

怎么用

• 把素材全部拖进 WorkBuddy 对话框（不需要整理格式、不需要改文件名）
• 粘贴下方提示词发送
• 拿到正式件初稿 —— 签批栏留空，推荐意见留空，由你填

3. 提示词卡片

把这三年的工单整理成一个新人能自己查的东西。 处理结果栏写了具体怎么修的，抽出来做成能搜的方案； 没写或者只写「已处理」的，单列一张待补清单，别混进去充数。 另外按部件类型和投运多久统计一下故障次数，看看哪些备件该常备。 不要预测哪台会坏，也不要给设备打分。 工单原文一个字都别改，首页要写清楚收录了多少、覆盖率多少。

为什么这么短就够了：短是因为工单字段映射、故障分类体系、役龄统计口径与不做预测的三条声明都写在能力包里。你只需要说清哪段时间的工单、要不要含电网侧。

换成你自己的业务：把素材换成你手上的真实文件即可。导入 Skill 之后，

该走几步、什么口径、什么情况必须拦住，Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

• 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说：什么事、什么文件、什么要求。不用讲究格式。
• 调用 Skill 补齐专业规则 —— 导入本页 Skill 后，流程、口径、硬规则 Agent 自己知道。
• 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮，把随口说的话补成更完整的表述。

分工：自然语言负责「这是什么事」，Skill 负责「该怎么做」，增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 3 份

本场景预期输出正在制作中。

能力包将固化什么（待补充）从 2025 年那张工单里，翻出了 37 个字里藏着的方法该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单：工单系统全量导出（2023-08 至 2026-08，1,842 张）含故障类型、等级、处置时长、处理结果栏 —— 处理结果栏是自由文本，质量参差设备台账与投运日期（Excel）40 台液冷电池舱、40 台 PCS-2500、EMS 与消防系统，逐台投运日期备件库存与采购周期表（Excel）当前在库数量、采购周期、供应商新入职人员排障记录（近 8 个月，微信群导出）6 名新人的提问与答复，用来判断哪些方案最该先上架本司运维职责边界说明（Word，星标）★那份平时不在核对范围内的东西 —— 哪些故障不归运维团队处置须待电网侧确认，这条决定知识库该收什么、不该收什么

人工边界：不做故障预测、不做设备健康度评分、不输出「下周哪台会坏」；役龄失效窗口是历史统计事实（这类部件在这个役龄区间的故障次数显著高于其他区间），不是对任何单台设备的预测 —— 这个区别必须写在知识库首页；工单原文的处置描述一个字不改，不做润色、不做归并。

升为客户真实案例还缺什么：客户当前真实输入文件（不要整理过的）岗位现行 SOP 与审批链（金额分档、谁签字）至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径（多少天算临期、多少金额算大额）

5. 同一角色下的其他场景

运维与质保工程师 · 产出即下一步输入

OM-01 · 运维月报与故障工单成稿 — 月报里那个 99.2% 没人会去核对 · 直到业主按合同口径算了一遍，才发现两个数差了 1.8 个百分点 查看 →OM-02 · 质保索赔证据包 — 索赔谈判桌上最贵的不是那 450 万 · 是对方翻出你数据缺了四个月时，你解释不清的那三分钟 查看 →

上下游串起来就是完整链路。每一步的产出都是下一步的输入，不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理，演示中的企业、人物与数据均为虚构，不代表任何客户的实际成效；痛点引用的公开来源已做脱敏处理。网页版由原资料转换，部分演示表格以原文形式展示。