标准场景 知识问答 行业 · 油气与矿产资源

GE-02 · 井史复杂情况案例库检索

「这口井当年卡钻是谁处理的」不再靠老师傅还在不在

痛点 井队处理复杂情况靠老队长的记忆 · 这行最年轻的机长已经 48 岁,记性再好也带不走档案柜

① 场景引入

一、这件事现在是什么样

地质与钻探技术 · 真实业务触发

井队遇到复杂情况(井漏/卡钻/井斜超差/泥浆性能突变),技术员要在当班内给出处置参考,队长会问「咱们以前在附近遇到过没有」;答不上来就只能按通用规程硬闯,代价可能是几天的停钻处理。

二、痛点 · 每条都有来源

1井史的二次利用是行业公认该做、从未排进日程的事——中石油官网自己都说「如何利用已有井史数据库是信息化建设的关键环节」依据 · 中石油官网技术文章:井史数据是勘探开发的重要资料,「钻井班报表需要填写项目非常多,而且数据需要准确,是一项非常烦琐的工作」,并指出如何利用已有井史数据库是信息化建设的关键环节——井史的二次利用人人都说该做,从未有人排进日程2钻探行业严重断代,最年轻的机长 48 岁——复杂情况的处置经验存在人脑里,人走了经验就断了依据 · 今日头条报道:地质工程师用 DeepSeek 写勘探计划,「玄武岩标成沉积岩、二叠系错标寒武系、钻探点位设在滑坡高危区」;省地调院技术负责人证实「2018 年后的最新行业标准、特殊地域地层命名经常出错,AI 会自信编造地质参数」——客户被通用大模型背刺过,这是采购时最真实的顾虑3历史井史躺在档案室PDF 里,文件名是井号加年份,没有按特征索引——想找「同构造带、同深度、同类复杂」要一份份翻依据 · 某媒体:西南油气田员工自述「曾经我统计一口井的全生命周期数据,跑了几个部门,翻几十份纸质档案,耗时整整 3

天」——找数据两周、写报告三天,是这个行业报告工作的真实结构4开县井喷里录井记录明明写着 9 柱未灌泥浆的违章——记录在案但没人检索,与没记录一样依据 · 开县「12·23」井喷事故责任人认定(央视报道):被判刑的 6 名一线责任人中包括一名录井工——「录井记录已显示有 9 柱钻井液未灌注泥浆的严重违章行为,肖先素未及时发现;之后她发现了也未立即提出警告纠正」——一线记录岗位对记录异常的失职直接入刑

三、换个做法之后

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

✕ 现在的做法

  • 井史的二次利用是行业公认该做、从未排进日程的事——中石油官网自己都说「如何利用已有井史数据库是信息化建设的关键环节」钻探行业严重断代,最年轻的机长 48 岁——复杂情况的处置经验存在人脑里,人走了经验就断了历史井史躺在档案室 PDF 里,文件名是井号加年份,没有按特征索引——想找「同构造带、同深度、同类复杂」要一份份翻开县井喷里录井记录明明写着 9 柱未灌泥浆的违章——记录在案但没人检索,与没记录一样

✓ 交给 Agent 之后

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

四、场景闭环

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

  1. 案例结构化 · 把档案室里的纸变成可检索的行逐份完井报告提取:井号/构造带/深度段/复杂类型/处置措施/处理天数/损失
  2. 特征对齐 · 当次情况与历史案例匹配按构造带、深度段、复杂现象三重匹配排序,相似度逐项写明
  3. 处置链还原 · 当时是怎么办的从案例里抽出处置动作序列与代价(处理天数、材料消耗、报废进尺)第 4步差异标注 · 这次的条件哪里不一样钻机型号、泥浆体系、钻具组合的差异逐条列出——避免照抄十年前的办法第 5步留证 · 检索报告归档本次检索与最终处置结果回写案例库,下一次多一条真基准

要准备什么:历史井史档案(扫描件目录+复杂情况章节)完井报告里的复杂情况与处理记录,非结构化文本当次复杂情况描述(技术员口述或班表摘录)深度、现象、泥浆性能、当时参数构造带与地层对照表(地勘分公司提供)把井位映射到构造单元,跨井可比

为什么这个场景值得做

优先级评分:痛感 4 × AI 适配 4 ÷ 落地难度 3 = 5.9

最大差异点:不是通用的「AI 问答回忆」,是把本队档案室的井史按构造带、深度段、复杂类型、处置结果做成可检索结构——外部通用工具没有这些数据,这正是它够不着的地方。

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

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

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

五、会产出什么

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

  • 正式件本体:复杂情况处置检索报告.xlsx 正式件 · 案例对比+差异标注 · 含签批栏
  • 可派发清单:历史案例结构化清单.xlsx 可复用 · 按构造带/深度/类型索引
  • 可派发清单:本次处置回执单.xlsx 处置结果回写案例库的留证

这套东西不承诺什么:不替井队定处置方案。检索结果是历史案例与相似度排序,「当时怎么处理的、处理了多久、花了多少」如实呈现;用不用、怎么用,由队长和技术员定。

② Live Demo(演示逐步)

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」,用的是真实业务格式的脱敏构造数据, 不宣称已接入客户生产系统,也不承诺任何效率提升百分比。

案例设定:西岭矿业集团地勘工程分公司 2026-09-01 14:00, 40508 钻井队在 ZK-2608 井312-318 米段遇阻(钻时突快+全烃峰值 2.10% + 泥浆黏度 56→61),技术员高原接到机长报告后,先查井史案例库——同构造带 2019 年 ZK-1903 孔同深度段 11 天卡钻事故(损失 88 万)与 2021 年 ZK-2201 孔 4 小时气测异常提前处置成功两条历史,30 秒内被检索出来。本案演示 Agent 如何在遇阻发生 30 分钟内给技术员一个处置参考,而不是等老师傅回忆。

1 份复杂情况案例库结构化(15 口同构造带历史井)30 秒检索耗时(从打开库到给出相似度排序)2 次历史卡钻+1 次成功处置的对比列示0 项最终处置方案(队长定)

输入矿山与井队手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

  • 01_同构造带历史井复杂情况库.xlsx 40508 队档案室:同构造带(鹰山组)15 口历史井的复杂情况摘要档案室 PDF 扫描件目录,经地勘分公司录入
  • 02_ZK-2608当前工况数据.xlsx 当次遇阻的实时录井+班表:钻时/全烃/泥浆按时间序列录井房+班表拍照
  • 03_同深度段相似度排序.xlsx Agent 自动匹配:构造带+深度段+复杂类型 三维相似度Agent 现场生成
  • 04_两份案例处置链对比.xlsx ZK-1903 与 ZK-2201 处置链拆解到动作级Agent 基于案例库生成

注意标橙色那一份 —— 01_同构造带历史井复杂情况库.xlsx。它档案室 PDF 扫描件目录,经地勘分公司录入,平时压根不在核对范围里。这个场景的价值,很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

我们在 ZK-2608 孔 315 米遇阻,泥浆黏度上来了,先别急着定方案。 把咱们档案室打过的井里,同一构造带、类似深度遇阻的都翻出来: 当时是什么现象、怎么处理的、处理了几天。 跟这次条件不一样的地方单独说。方案我自己定。

客户念的只是意图,构造带映射、相似度规则、案例字段都在能力包里。

触发遇阻 30 分钟内要给出处置参考,不是答案

技术员不能等老机长回忆 7 年前那次卡钻,30 秒内 Agent 出检索报告

14:00 遇阻后 30 分钟内,机长问「咱们以前在附近遇到过没有」。Agent 30 秒从档案室 15 口井里找出 2 口强相关,1 口弱参考。技术员拿着这份报告去与机长定方案,不是替机长定方案。

第 1 步 · 案例结构化 · 15 口井 4 字段

档案室 PDF 扫描件目录自动结构化(井号/年份/深度/复杂/处置/天数/损失)

演示数据(表格原文)档案室 15 口同构造带井的结构化:字段覆盖数据完整度—井号15/15100%—年份15/15100%—深度段15/15100%—复杂情况15/15100%—处置动作15/15100%—处理天数15/15100%—直接损失(万元)15/15100%—15/15 全字段———15 口井 7 字段全字段 100% 完整——档案室 PDF 目录经地勘分公司录入时结构化(否则要 Agent 从扫描件里读,会有一两字段识别失败)。从历史里想起档案室 15 口井的结构化录入是 2023 年地勘分公司借集团数字化项目做的——这条不靠当年的档案员还在不在,字段在 Excel 里,Agent 调出来比对即可。

第 2 步 · 特征匹配 · 构造带+深度+类型三维

三维相似度匹配,不只看深度段

当前工况 ZK-2608 孔 312-318m 钻时突快+全烃峰值 2.10% 的三维匹配:井号构造带深度段类型相似度ZK-1903鹰山组

  • ✓ 308-318
  • ✓ 卡钻同型92%ZK-2201鹰山组
  • ✓ 310-320
  • ✓ 气测异常同型88%ZK-2401鹰山组
  • ✓ 305-315(差 5m)钻时突快近型70%ZK-2001鹰山组
  • ✓ 280-310(差 20m)气测异常近型55%其他 11 口——不匹配< 50%2 口强参考1 口次参考———三维匹配下,2019 年 ZK-1903 与 2021 年 ZK-2201 是最相关的 2 口——前者是失败案例(卡钻 11 天),后者是成功案例(提前调泥浆无复发)。两份案例并排给技术员——失败与成功并列,处置方向自然显现。把技术动作翻译成钱(再次)两份案例并排的处理天数对比:11 天 vs 0 天,损失对比:88 万 vs 0.3 万药剂。技术员在 30 秒看到这两组数字后,今夜调泥浆(成本 2 千元药剂)vs 11 天停钻(损失 88 万)的对比,不需要讨论——2 千 vs 88 万。

第 3 步 · 处置链还原 · 当时是怎么办的

从案例里抽出处置动作序列与代价

演示数据(表格原文)ZK-1903 与 ZK-2201 的处置链并排:环节ZK-1903(失败)ZK-2201(成功)—发现时钻时突快后 3 天才卡钻钻时突快后 4h 监测—第一动作继续钻进立即停钻循环观察—第二动作卡钻后反复活动钻具调泥浆密度 1.20→1.32 + 加 200kg 润滑剂—第三动作套铣解卡循环观察 4h 全烃下降—处理天数11 天0 天—直接损失88 万0.3 万(药剂)—处置链对比11 天 vs 0 天——两份案例的处置链并排:失败案例是「继续钻进 → 卡钻 → 套铣解卡」(3 步被动),成功案例是「立即循环 → 调泥浆→ 监测下降」(3 步主动)。主动 vs 被动的对比在 3 个动作里完全展开。排除性结论本次遇阻可以直接排除「钻头磨损因素」——该钻头入井仅 54 小时、上一趟起出时 IADC 编码 1-2-WT(轻度磨损),钻头磨损需要累计100+ 小时才会显著影响钻速。排查范围缩小到「地质+泥浆」两端,无需起钻。

第 4 步 · 差异标注 · 这次的条件哪里不一样

照抄十年前的办法可能出问题,差异逐条列示

演示数据(表格原文)本井与两份参考案例的工况差异:维度ZK-1903(2019)ZK-2201(2021)本井 ZK-2608(2026)—钻机型号ZJ-40ZJ-40ZJ-40(同)—钻头型号PDC(同)PDC(同)PDC(同)—泥浆体系水基聚合物水基聚合物水基聚合物(同)—泥浆密度1.201.201.26(↑0.06)不同润滑剂无200kg100kg(本班已加)不同钻头入井78h42h54h(中)—3 项同 / 3 项不同————本井与两份案例 3 项相同(钻机/钻头/泥浆体系)、3 项不同(本井泥浆密度 1.26 已高于 2019 的 1.20、润滑剂 100kg 已加但少于 2021 的 200kg)。——本井的处置不是 2021 的简单复刻,需要在 1.32 密度+200kg 润滑剂之上再评估。这正是把两份案例并排的意义——避免简单复制。从历史里想起(再次)+ 该拦的地方拦住了差异里 1.20 vs 1.26 的密度差异是好事(本井密度高0.06),但 100kg vs 200kg 的润滑剂差异是坏事(本井少 100kg)。技术员拿着这份对比,会知道「不能照搬 2021 经验」——本井需追加 100kg 润滑剂而非全照搬。

第 5 步 · 留证 · 检索报告归档 + 处置回执

本次检索与最终处置结果回写案例库,下一次多一条真基准

演示数据(表格原文)处置回执:环节Agent 给的机长/技术员的处置回写案例库检索2 口强参考 30 秒出报告技术员拿着报告 14:25 去找机长—第一动作建议立即停钻循环观察14:30 停钻循环本井处置动作:停钻循环第二动作建议调泥浆密度 1.26→1.32 + 润滑剂100→200kg15:00 调泥浆+追加润滑剂本井处置动作:调泥浆第三动作建议监测 4h15:30 全烃峰值 2.10% → 16:00 降至 1.85→ 18:00 降至 0.71本井监测时长 4h,全烃下降 66%本次回写——本井入库:处置成功,处理 4h,损失 0.3 万(润滑剂)本次入库下一份参考——本次处置成功(全烃 4h 下降 66%,无卡钻),回写案例库作为下一口同构造带井的参考——下次技术员30 秒检索时,本井的 0.3 万 + 4h 成功案例就是他的「2021 风格」。从历史里想起(再次)+ 把技术动作翻译成钱(再次)案例库每一次成功/失败处置的回写,都是 Agent 的「持续可用的本队资产」。这条不靠 2021 年技术员还在不在,回写到 2026 年案例库,7 年后(2033)的技术员检索时还能用。本井成本 0.3 万保住 11 天 88 万敞口——案例库就是把每一次成功都沉淀下来。这份 9-1 井史复杂情况处置检索报告现在还不能交检索报告里的「处置建议」是 Agent 基于 2019/2021 两次历史给的,但2026 年本井工况有 3 项与历史不同(密度 1.26、润滑剂 100kg、钻头 54h),机长与技术员是否采纳,采纳的话是否追加100kg 润滑剂而不是 200kg,都是本井自己的决定。不用干等:方案一(机长处置决定录入后发完整版,推荐):机长14:30 看完报告,15:00 决定调泥浆+追加润滑剂(本井工况决定润滑剂 100→200kg),15:30 全烃峰值 2.10%,16:00 降至1.85,18:00 降至 0.71——4h 监测成功。检索报告由 14:00 初稿 → 16:00 机长处置后补「处置决定」 → 18:00 监测成功补「处置结果」,18:30 发回写案例库,完整版定稿。方案二(先发初稿,带「待补处置」):检索报告 14:30 先发机长,标注「Agent 建议,机长/技术员处置决定待补」——但机长拿到后口述处置,Agent 补「处置决定」——可信度低一档,但 14:30立即可发(若当时有 6 口邻井技术员等检索报告)。若按 2019 轨迹重演卡钻 11 天 88 万,只因检索报告没及时回写案例库——案例库的价值就是「不让前人栽过的树后人再栽」。之后这一次跑完,公司多了什么

不讲省了多久 · 讲少了几个隐患、沉淀了什么

演示数据(表格原文)✓案例库多了一条:本次复杂情况与最终处置回写入库,案例从 43 条变 44 条✓一条沉睡资产被激活:档案室井史第一次按特征可检索✓两次历史教训被真正用上:卡钻处置的时差与成本差成了可引用的基准✓岗位角色变了:从「问老机长」变成「先查库、再带着结果去问」追问现场可能被问到的答不上来的问题,比答得漂亮的问题更能决定这场演示的结果老档案是扫描的 PDF 你也能读?能读,识别不确定的字段会标出来让人核——宁可慢一点也不猜,这行的记录是要经得起追责的。给出的历史处理办法能直接用吗?不能直接用。每条都标了与本次工况的差异,照抄十年前的办法出过事,最终方案队长定。案例库要维护吗?会不会变成又一个没人填的台账?不用专门填——每次检索后回写一条,用的是本来就要发生的复杂情况处理记录,不加新台账。

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

1. Skill 能力包

导入之后,同类任务会自动按这套规则走 —— 提示词才能写得那么短

井史复杂情况案例库检索 —— 「这口井当年卡钻是谁处理的」不再靠老师傅还在不在 · Skill

SKILL.md 主本 + references(输出骨架 / 判据 / 渲染脚本)· 符合 WorkBuddy Skill 规范

版本 v1.0

well-history-cases.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

  • SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
  • references/output_template.md 输出骨架(sheet 名 / 分区顺序 / 列头)+ 可直接运行的渲染脚本
  • references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细,不会拖慢每次对话。

2. 原始素材

这些就是矿山与井队手上真实能拿到的东西 —— 格式不统一是常态,不是问题

📁GE-02 · 演示素材

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

共 4 份

XLS01_同构造带历史井复杂情况库.xlsx40508 队档案室:同构造带(鹰山组)15 口历史井的复杂情况摘要下载

  • ↓XLS02_ZK-2608当前工况数据.xlsx 当次遇阻的实时录井+班表:钻时/全烃/泥浆按时间序列
  • 03_同深度段相似度排序.xlsx Agent 自动匹配:构造带+深度段+复杂类型 三维相似度
  • 04_两份案例处置链对比.xlsx ZK-1903与 ZK-2201 处置链拆解到动作级

怎么用

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

3. 提示词卡片

我们在 ZK-2608 孔 315 米遇阻,泥浆黏度上来了,先别急着定方案。 把咱们档案室打过的井里,同一构造带、类似深度遇阻的都翻出来: 当时是什么现象、怎么处理的、处理了几天。 跟这次条件不一样的地方单独说。方案我自己定。

为什么这么短就够了:客户念的只是意图,构造带映射、相似度规则、案例字段都在能力包里。

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

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

自己组织输入的三步法

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

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

4. 预期输出

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

📋正式交付物

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

共 3 份

  • GE-02_复杂情况处置检索报告.xlsx 正式件 · 案例对比+差异标注 · 含签批栏
  • GE-02_历史案例结构化清单.xlsx 可复用 · 按构造带/深度/类型索引
  • GE-02_本次处置回执单.xlsx 处置结果回写案例库的留证

Skill 里固化了什么:从历史里想起了公司踩过的坑该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单:历史井史档案(扫描件目录+复杂情况章节)完井报告里的复杂情况与处理记录,非结构化文本当次复杂情况描述(技术员口述或班表摘录)深度、现象、泥浆性能、当时参数构造带与地层对照表(地勘分公司提供)把井位映射到构造单元,跨井可比

人工边界:不替井队定处置方案。检索结果是历史案例与相似度排序,「当时怎么处理的、处理了多久、花了多少」如实呈现;用不用、怎么用,由队长和技术员定。

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

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

地质与钻探技术 · 产出即下一步输入

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

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

想把这个场景在你们企业跑通?

顾问会先看你们的数据和流程够不够,再决定从哪一步开始。