09-05｜Failure Mode Database｜特殊氣體鋼瓶故障模式資料庫與案例知識管理

特殊氣體鋼瓶維修累積多年之後，

真正有價值的資料，

不只是：

「發生過多少事故。」

更重要的是：

What Failed?
（什麼失效？）

Where Did It Fail?
（在哪裡失效？）

How Was It Detected?
（如何被發現？）

What Evidence Was Available?
（有哪些證據？）

What Was the Cause Status?
（原因確認到什麼程度？）

Which Safety Barrier Failed?
（哪一道安全屏障失效？）

Which Barrier Caught It?
（哪一道屏障成功攔截？）

以及：

Has This Failure Happened Before?
（這種故障以前是否發生過？）

如果每一件案例：

各自寫一份報告，

卻沒有共同分類，

幾年之後就會形成：

Many Reports
（很多報告）

but

Little Structured Knowledge
（很少結構化知識）。

因此需要建立：

Failure Mode Database
（故障模式資料庫）。

它的目的不是取代：

Incident Report
（事故報告）

或：

Maintenance Record
（維修紀錄）。

而是把不同案例中：

Repeated Failure Patterns
（重複出現的故障模式）

整理成可以：

Search
（搜尋）

Compare
（比較）

Analyze
（分析）

Train
（教育）

以及：

Reuse
（重複利用）

的：

Maintenance Knowledge
（維修知識）。

一、什麼是 Failure Mode Database？

Failure Mode Database
（故障模式資料庫）

是一套依：

Failure Mode
（故障模式）

整理維修異常與案例的知識系統。

例如：

十支不同鋼瓶

可能在不同年份、

不同氣體服務、

不同瓶閥、

不同作業人員、

不同原因下，

都曾發生：

Neck Leak
（瓶頸洩漏）。

如果只按照：

Incident Date
（事故日期）

存檔，

這十件案例可能分散在：

十個不同資料夾。

但是如果建立：

FM-001
Neck Leak

就可以把相關案例：

Link
（連結）

到同一個：

Failure Mode。

未來就能快速回答：

「以前有沒有發生過 Neck Leak？」

「當時 Gauge 結果如何？」

「是否曾經 Gauge Pass 但仍發生 Leak？」

「常在哪個位置發現？」

「過去有哪些 Possible Cause？」

「哪些原因曾經真正 Confirmed？」

這就是：

Failure Mode Database

的價值。

二、Failure Mode Database ≠ Incident Database

Failure Mode Database

與：

Incident Database
（事故資料庫）

不能完全視為相同。

Incident Database

通常以：

Event
（事件）

為中心。

例如：

2026-XX-XX
某鋼瓶發生某事件。

Failure Mode Database

則以：

Failure Pattern
（故障模式）

為中心。

例如：

FM-001
Neck Leak。

因此：

One Incident
（一件事故）

可能包含：

Multiple Failure Modes
（多個故障模式）。

反過來：

One Failure Mode

也可能連結：

Many Incidents
（很多不同事件）。

三、Case ID 與 FM ID 必須分開

為了避免混亂，

建議未來資料庫使用兩種編號。

第一種：

Case ID
（案例編號）

代表：

某一次實際事件。

例如：

CASE-2026-001

第二種：

FM ID
（故障模式編號）

代表：

某一種 Failure Mode。

例如：

FM-001
Neck Leak。

所以：

CASE-2026-001

可能包含：

FM-001。

而：

FM-001

下面可能包含：

CASE-2023-004

CASE-2024-012

CASE-2025-008

CASE-2026-001。

這樣才能分清楚：

Event Identity
（事件身分）

與：

Failure Classification
（故障分類）。

四、目前 Failure Mode Database 的 13 個核心分類

CylinderTech 目前可以先建立：

13 個主要 Failure Mode。

FM-001

Neck Leak
（瓶頸洩漏）

FM-002

Cross Port Leak
（閥內串漏）

FM-003

Outlet Thread Damage
（出口螺紋損傷）

FM-004

Toroid Damage
（超環面／特定密封接觸面損傷）

FM-005

Cylinder Neck Thread Damage / Missing Thread
（鋼瓶瓶頸螺紋損傷／牙紋缺損）

FM-006

Valve Thread Material Adhesion / Foreign Material
（瓶閥螺紋材料沾黏／異物）

FM-007

PRD Loose / Position Abnormal
（PRD 鬆動／位置異常）

FM-008

PRD Missing Component
（PRD 零件缺失）

FM-009

PRD Leak / Abnormal Release
（PRD 洩漏／異常釋放）

FM-010

Cylinder Body Weld Area Leak
（鋼瓶本體焊縫區域洩漏）

FM-011

Unexpected / Residual Cylinder Pressure
（非預期／殘留鋼瓶壓力）

FM-012

Status Label / Record Mismatch
（狀態標籤／紀錄不一致）

FM-013

PRD Fuse Metal Activation
（PRD Fuse Metal 動作）

這 13 個 FM ID

可以作為：

Initial Database
（初始資料庫）。

未來如果發現：

New Failure Pattern
（新的故障模式），

再新增：

FM-014

FM-015

FM-016……

而不是一開始建立大量沒有實際案例的分類。

五、FM ID 不應因為原因改變而改變

假設兩件：

Neck Leak。

第一件最後確認與：

Thread Damage

有關。

第二件最後確認與：

Assembly Alignment

有關。

它們的：

Root Cause

可能不同。

但是 Failure Mode

仍然都是：

FM-001
Neck Leak。

因此：

Different Cause
（不同原因）
≠
Different Failure Mode ID
（不同故障模式編號）

這樣才能比較：

Same Failure Mode, Different Causes
（相同故障模式、不同原因）。

六、同樣原因也可能產生不同 Failure Mode

反過來也可能發生。

例如：

Tool Interference
（工具干涉）

可能造成：

PRD Position Abnormality

也可能造成：

Component Damage

或其他異常。

因此：

Same Cause
（相同原因）
≠
Same Failure Mode
（相同故障模式）

這再次證明：

Failure Mode

與：

Root Cause

必須分開存放。

七、Failure Mode 名稱應描述失效，不要偷偷加入原因

例如：

好的 Failure Mode 名稱：

PRD Loose

較不理想：

PRD Loose Caused by Wrench

因為後者已經把：

Cause

寫入：

Failure Mode Name。

如果日後證據證明：

不是 Wrench，

整個分類就會失去一致性。

因此 FM 名稱應盡量：

Cause-neutral
（原因中立）。

例如：

Cylinder Body Weld Area Leak

比：

Manufacturing Weld Defect

更適合當 Failure Mode。

因為：

Weld Area Leak

是已觀察到的失效位置／模式。

而：

Original Manufacturing Defect

需要額外證據才能確認。

八、Failure Location 應獨立建立欄位

除了 Failure Mode，

還建議建立：

Failure Location
（故障位置）。

例如：

Cylinder Body
（鋼瓶本體）

Cylinder Neck
（瓶頸）

Cylinder Neck Thread
（瓶頸螺紋）

Valve Inlet Thread
（瓶閥入口螺紋）

Valve Outlet
（瓶閥出口）

Toroid / Sealing Surface
（超環面／密封面）

PRD

Weld Area
（焊縫區域）

Pressure Panel

Label / Record System。

如此未來可以分析：

「哪些位置最常出現異常？」

而不是只能靠：

Failure Mode Name

猜位置。

九、Observed Condition 必須保留原始描述

資料庫不能只有：

FM ID。

例如：

FM-007
PRD Loose / Position Abnormal

仍然需要保留：

Observed Condition。

例如：

「PRD Witness Mark 與原記錄位置不一致。」

或：

「PRD 外側部件位置與正常狀態比較出現偏移。」

這些：

Original Observation
（原始觀察）

不能被：

FM Classification
（故障分類）

取代。

因為未來重新分析時，

原始證據可能非常重要。

十、Evidence 應該成為正式欄位

每一筆案例建議建立：

Evidence
（證據）

欄位。

例如：

Photo
（照片）

Gauge Result
（量規結果）

Leak Test Result
（洩漏檢查結果）

Pressure Reading
（壓力讀值）

Work Record
（作業紀錄）

Label
（標籤）

Witness Mark
（見證標記）

Tool Mark
（工具痕跡）

Before / After Record
（作業前後紀錄）

Manufacturer Information
（製造商資料）

以及其他：

Physical Evidence
（實體證據）。

這樣可以區分：

What We Know
（已知）

與：

What We Think
（推測）。

十一、照片應連結案例，不要只有照片資料夾

照片如果只有：

IMG_9548.jpg

IMG_9549.jpg

幾年後很難知道：

它們代表什麼。

因此照片最好至少能連結：

Case ID

FM ID

Component

Photo Type。

例如：

FM007_CASE2026-003_PRD_Position_01.jpg

或由照片管理資料表建立：

Photo ID：

PHOTO-000231

Case ID：

CASE-2026-003

Failure Mode：

FM-007

Subject：

PRD Position

Photo Type：

Before Condition。

如此照片才會成為：

Searchable Evidence
（可搜尋證據）。

十二、Master Photo 與 Web Photo 必須分開

原始案例照片可能包含：

Cylinder Serial Number

Customer Name

Internal Label

Work Order

Employee Information

或其他敏感資料。

因此建議分成：

MASTER
（原始證據版本）

與：

WEB
（網站公開版本）。

MASTER：

保留原始內容，

不得為了網站美觀破壞證據。

WEB：

可以：

Crop
（裁切）

Redact
（遮蔽）

De-identify
（去識別化）

Add Watermark
（加入浮水印）。

因此：

MASTER Evidence
≠
WEB Publication Image

兩者應建立：

Reference Link
（關聯）

而不是互相取代。

十三、Gauge Result 要與 Visual Result 分開

延續 09-03：

Gauge Pass ≠ Cylinder Accepted。

資料庫不能只有：

Inspection Result = PASS。

應拆成：

Gauge Result
（量規結果）

Visual Result
（目視結果）

Leak / Functional Result
（洩漏／功能結果）

例如：

Gauge Result：

PASS

Visual Result：

Localized Thread Profile Abnormality
（局部牙型異常）

Leak Result：

Neck Leak Detected
（發現瓶頸洩漏）

這三個結果：

可以同時存在。

如果資料庫只有：

PASS

就會失去最重要的技術資訊。

十四、Cause 與 Cause Status 必須是兩個欄位

這是整個 Failure Mode Database

非常重要的設計。

不要只建立：

Cause：

Tool Interference

應該建立：

Cause：

Tool Interference
（工具干涉）

Cause Status：

POSSIBLE
（可能）

如此未來：

GasPro AI

才知道：

這不是：

Confirmed Fact
（已確認事實）。

因此：

Cause
＋
Cause Status

必須綁在一起。

十五、Cause Status 統一使用四級

目前 CylinderTech 建議使用：

CONFIRMED
（已確認）

PROBABLE
（較可能）

POSSIBLE
（可能）

UNCONFIRMED
（未確認）

例如：

Cause：

Tool Interference

Cause Status：

POSSIBLE

或者：

Cause：

Temperature Sensor Malfunction

Cause Status：

CONFIRMED。

這可以大幅降低：

Assumption Becomes Fact
（假設逐漸變成事實）

的問題。

十六、Cause Status 必須允許更新

新的證據出現後，

Cause Status

可能改變。

例如：

Version 1：

Tool Interference
POSSIBLE

後續找到：

Before / After Photo

Tool Contact Mark

Work Sequence Evidence。

可能更新成：

Version 2：

Tool Interference
PROBABLE。

如果再取得直接證據，

才可能變成：

CONFIRMED。

因此資料庫最好保留：

Revision History
（修訂歷程）。

而不是：

直接覆蓋舊結論，

讓人不知道：

判斷為什麼改變。

十七、Corrective Action 與 Preventive Action 必須分開

Corrective Action
（矯正措施）

主要處理：

Current Condition
（目前異常）。

Preventive Action
（預防措施）

則著重：

Prevent Recurrence
（避免再次發生）。

例如：

PRD Position Abnormality。

Corrective Action：

依核准程序處理目前異常。

Preventive Action：

Tool Control

Physical Guard

Clearance Check

Post-work Inspection

Training

或其他適用措施。

因此：

Problem Fixed
（問題處理完成）
≠
Recurrence Prevented
（已避免再次發生）。

十八、Corrective Action Success 不應自動更新 Cause Status

假設：

更換某個零件後，

Leak 消失。

資料庫不能自動把：

Cause Status

改成：

CONFIRMED。

因為：

Corrective Action Success
≠
Root Cause Proof

所以：

Cause Status

應由：

Evidence

決定，

不是由：

Repair Outcome
（維修結果）

自動決定。

十九、加入 Safety Barrier 欄位

延續 09-02，

資料庫可以加入：

Preventive Barrier
（預防屏障）

Detection Barrier
（偵測屏障）

Failed Barrier
（失效屏障）

Successful Barrier
（成功屏障）。

例如：

FM-012
Status Label / Record Mismatch

Failed Barrier：

Status Label Control
（狀態標籤管理）

Successful Barrier：

Technician Record Verification
（技術人員紀錄確認）

如此可以分析：

「我們最常靠哪一道屏障發現問題？」

以及：

「哪一道屏障最常失效？」

二十、加入 Stop Work / Good Catch 資訊

資料庫也可以記錄：

Was Stop Work Initiated?
（是否停止作業？）

Yes / No

Was This a Good Catch?
（是否屬於 Good Catch？）

Yes / No

Was an Incident Prevented?
（是否在事故前成功攔截？）

如此 09-01 的概念

就可以真正進入資料庫。

未來可以分析：

Good Catch Rate

以及：

Where Good Catches Occur
（Good Catch 最常在哪一站發生）。

二十一、不要把「沒有事故」當成沒有 Failure Mode

例如：

維修人員發現：

Status Label / Record Mismatch

並立即停止。

沒有：

Gas Release

沒有：

Equipment Damage

沒有：

Injury。

但是：

FM-012

仍然存在。

因此：

No Incident
（沒有事故）
≠
No Failure Mode
（沒有故障模式）

Near Miss

Good Catch

Abnormal Finding

都應具有：

Knowledge Value
（知識價值）。

二十二、Severity 與 Failure Mode 應分開

同一 Failure Mode

可能有：

不同嚴重程度。

例如：

PRD Leak

可能只是：

早期檢查發現的微小異常，

也可能發展成：

Large Gas Release
（大量氣體釋放）。

因此：

Failure Mode ID

不應直接等於：

Severity
（嚴重度）。

如果未來需要，

可以另設：

Consequence
（後果）

或：

Severity Classification
（嚴重度分類）。

不要因為後果不同，

就建立：

FM-009A

FM-009B

FM-009C

除非真的存在不同：

Failure Mechanism
（失效機制）

需要分類。

二十三、Gas Service 應獨立記錄

對特殊氣體鋼瓶而言：

Gas Service
（氣體服務）

具有很高的分析價值。

例如：

SiH4

PH3

AsH3

BF3

DCS

CO

GeF4

H2 Mixture

C2H2

NH3。

但是：

Gas Service

不應直接寫入所有：

Failure Mode Name。

例如：

SiH4 Neck Leak

本質仍可以分類：

FM-001 Neck Leak。

另外記錄：

Gas Service = SiH4。

如此才能分析：

「FM-001 是否在某些 Gas Service 中較常出現？」

而不會建立大量：

SiH4 Neck Leak

PH3 Neck Leak

AsH3 Neck Leak

等重複 FM。

二十四、Cylinder 與 Valve 資訊也應結構化

每一案例若資料允許，

可以建立：

Cylinder Specification
（鋼瓶規格）

Cylinder Material
（鋼瓶材質）

Cylinder Capacity
（鋼瓶容積）

Valve Manufacturer
（瓶閥製造商）

Valve Model
（瓶閥型號）

Valve Material
（瓶閥材質）

PRD Type / Configuration
（PRD 類型／配置）

但是公開網站：

不一定需要全部公開。

尤其：

Full Cylinder Serial Number

Customer Information

Internal Part Number

Supplier-sensitive Information

應保留在：

Private Database
（私人資料庫）。

二十五、Public Database 與 Private Database 要分層

Failure Mode Database

最好建立：

Two-layer Structure
（雙層架構）。

第一層：

Public Knowledge
（公開知識）

可以包含：

FM ID

Failure Mode

Generic Component

Anonymized Case

General Evidence

Cause Status

Lessons Learned。

第二層：

Private Evidence
（私人證據）

可以包含：

Full Serial Number

Customer

Supplier

Work Order

Exact Internal Record

Original Photo

Employee Information

Internal Torque Data

Detailed Investigation

以及其他：

Confidential Information
（機密資訊）。

因此：

Public Knowledge Base
≠
Complete Internal Investigation Database

這樣比較適合：

CylinderTech Website

與：

GasPro AI

分別使用。

二十六、不要直接刪除「未確認案例」

資料庫很容易出現一個問題：

大家只想保存：

Solved Case
（已解決案例）。

但是：

Unconfirmed Case
（未確認案例）

同樣非常有價值。

例如：

五件 PRD Loose

其中：

一件 CONFIRMED

兩件 PROBABLE

兩件 UNCONFIRMED。

這樣的資料：

比只留下那一件 CONFIRMED

更接近真實世界。

因為它可以顯示：

Evidence Quality
（證據品質）

以及：

Investigation Limitation
（調查限制）。

二十七、資料庫不能把「未知」自動補成「正常」

如果某案例：

Valve Material

沒有紀錄。

應該寫：

UNKNOWN

或留作：

Not Recorded
（未記錄）。

不能因為：

「通常都是 Stainless Steel」

就自動填入：

Stainless Steel。

同樣：

PRD Type Unknown

不能由 AI

根據照片名稱或相似案例

自行補成：

Burst Disc。

因此：

Missing Data
（缺少資料）
≠
Normal / Typical Value
（正常／常見值）

這對 GasPro AI

尤其重要。

二十八、資料庫的基本欄位建議

CylinderTech 的 Failure Mode Database

可以先建立以下核心欄位：

Case ID
（案例編號）

FM ID
（故障模式編號）

Date
（日期）

Process Step
（作業階段）

Gas Service
（氣體服務）

Cylinder Type / Specification
（鋼瓶類型／規格）

Cylinder Material
（鋼瓶材質）

Valve Manufacturer / Model
（瓶閥製造商／型號）

Failure Location
（故障位置）

Observed Condition
（觀察狀態）

Failure Mode
（故障模式）

Gauge Result
（量規結果）

Visual Result
（目視結果）

Leak / Functional Result
（洩漏／功能結果）

Evidence
（證據）

Photo ID
（照片編號）

Direct Cause
（直接原因）

Contributing Factor
（促成因素）

Root Cause
（根本原因）

Cause Status
（原因確認狀態）

Corrective Action
（矯正措施）

Preventive Action
（預防措施）

Failed Barrier
（失效屏障）

Successful Barrier
（成功屏障）

Stop Work
（停止作業）

Good Catch
（良好攔截）

Disposition
（處置結果）

Lesson Learned
（經驗教訓）

Revision
（修訂版本）。

不需要一開始每個欄位都有資料。

Unknown

本身也是有效資訊。

二十九、FM-001～FM-013 初始索引

目前可以先建立以下：

Failure Mode Index
（故障模式索引）。

FM-001｜Neck Leak
瓶頸洩漏

FM-002｜Cross Port Leak
閥內串漏

FM-003｜Outlet Thread Damage
出口螺紋損傷

FM-004｜Toroid Damage
超環面／特定密封接觸面損傷

FM-005｜Cylinder Neck Thread Damage / Missing Thread
鋼瓶瓶頸螺紋損傷／牙紋缺損

FM-006｜Valve Thread Material Adhesion / Foreign Material
瓶閥螺紋材料沾黏／異物

FM-007｜PRD Loose / Position Abnormal
PRD 鬆動／位置異常

FM-008｜PRD Missing Component
PRD 零件缺失

FM-009｜PRD Leak / Abnormal Release
PRD 洩漏／異常釋放

FM-010｜Cylinder Body Weld Area Leak
鋼瓶本體焊縫區域洩漏

FM-011｜Unexpected / Residual Cylinder Pressure
非預期／殘留鋼瓶壓力

FM-012｜Status Label / Record Mismatch
狀態標籤／紀錄不一致

FM-013｜PRD Fuse Metal Activation
PRD Fuse Metal 動作

三十、FM-001 範例資料結構

以：

FM-001 Neck Leak

為例。

FM ID：

FM-001

Failure Mode：

Neck Leak

Failure Location：

Cylinder Neck / Valve Connection

Possible Observed Conditions：

Leak detected near neck connection

Thread profile abnormality

Material adhesion

Visible thread damage

Possible Evidence：

Leak test result

Plug Gauge result

Ring Gauge result

Visual inspection

Thread photo

Before / After photo

Maintenance record

Possible Cause：

Thread damage

Alignment issue

Foreign material

Assembly-related condition

Other factors

Cause Status：

依個別 Case 分別記錄。

注意：

上面列出的 Possible Cause

只是：

Investigation Direction
（調查方向）

不是：

FM-001 的固定 Root Cause。

三十一、FM-007 範例資料結構

FM ID：

FM-007

Failure Mode：

PRD Loose / Position Abnormal

Failure Location：

PRD

Possible Evidence：

Witness Mark

Before / After Photo

Tool Mark

Contact Mark

Tool Clearance

Fixture Position

Work Record

Possible Cause：

Tool interference

Machine / fixture contact

Previous abnormal condition

Assembly-related condition

Cause Status：

依案例證據決定。

不能建立：

FM-007

Tool Interference

因為：

Failure Mode
≠
Cause。

三十二、FM-012 範例資料結構

FM ID：

FM-012

Failure Mode：

Status Label / Record Mismatch

Failure Location：

Information / Process System

Observed Condition：

Label status inconsistent with completion/work record

Possible Failed Barrier：

Status Control

Possible Successful Barrier：

Technician Verification

Record Cross-check

Possible Event Type：

Good Catch

Near Miss

這個案例非常重要，

因為它證明：

Failure Mode Database

不應只記錄：

Mechanical Failure
（機械故障）。

Process / Information Failure
（製程／資訊失效）

同樣可能直接影響：

Cylinder Maintenance Safety
（鋼瓶維修安全）。

三十三、FM-013 範例資料結構

FM ID：

FM-013

Failure Mode：

PRD Fuse Metal Activation

Observed Condition：

Fuse Metal activated following abnormal thermal exposure

Known Case：

NH3 Drum overheating event

Confirmed Cause in That Specific Case：

Temperature Sensor Malfunction

Cause Status：

CONFIRMED

但是這不代表：

所有 FM-013

都必須具有相同 Root Cause。

未來另一件 Fuse Metal Activation

可能具有：

Different Cause。

因此：

Case-specific Root Cause
（個案根本原因）

不能變成：

Failure Mode-wide Root Cause
（整個故障模式的固定根本原因）。

三十四、資料庫最重要的是「可以比較」

建立資料庫之後，

未來可以開始回答：

Which Failure Mode Occurs Most Often?
（哪種故障模式最常出現？）

Which Process Detects It?
（在哪個流程最常被發現？）

Which Barrier Catches It?
（哪一道屏障最常攔截？）

Which Cause Is Actually Confirmed?
（哪些原因真正被確認？）

Which Cause Is Only Assumed?
（哪些原因只是推測？）

Which Gas Service Is Involved?
（涉及哪些氣體服務？）

Which Valve / Cylinder Combination Appears Repeatedly?
（哪些瓶閥／鋼瓶組合重複出現？）

How Often Does Gauge Pass Despite Visual Abnormality?
（量規通過但目視異常的情況有多少？）

這些問題：

單靠個別 Incident Report

很難回答。

Failure Mode Database

就是把：

Experience
（經驗）

轉換成：

Data
（資料）

再轉換成：

Knowledge
（知識）。

三十五、不要過早做統計結論

資料庫剛開始建立時，

案例數可能很少。

例如：

FM-001 有 8 件，

FM-007 有 2 件。

不能直接說：

「Neck Leak 的風險是 PRD Loose 的四倍。」

因為還需要考慮：

Exposure
（暴露量）

Number of Cylinders Processed
（處理鋼瓶數）

Inspection Frequency
（檢查頻率）

Detection Method
（偵測方式）

Gas Service

Valve Population

以及：

Reporting Bias
（通報偏差）。

因此：

Case Count
（案例數）
≠
Risk Rate
（風險率）

這點未來如果開始做：

Failure Trend Analysis
（故障趨勢分析）

尤其重要。

三十六、資料庫的目的不是找「最常犯錯的人」

Failure Mode Database

如果最後變成：

Operator Ranking
（作業人員排名）

很容易破壞：

Good Catch

與：

Stop Work

文化。

資料庫真正應該尋找的是：

Repeated Pattern
（重複模式）

Weak Barrier
（薄弱屏障）

Common Failure Location
（常見故障位置）

Recurring Cause
（重複原因）

以及：

Improvement Opportunity
（改善機會）。

因此：

Analyze the System
（分析系統）

比：

Rank the People
（排列人員）

更有技術價值。

三十七、GasPro AI 如何使用 Failure Mode Database

未來 GasPro AI

收到問題：

「Neck Leak 有哪些可能原因？」

不應直接回答：

「Neck Leak 是過扭力造成。」

正確的知識結構應該讓 AI 找到：

FM-001
Neck Leak

然後分開讀取：

Known Cases
（已知案例）

Confirmed Causes
（已確認原因）

Probable Causes
（較可能原因）

Possible Causes
（可能原因）

Unconfirmed Cases
（未確認案例）

最後回答：

「過去案例曾出現哪些相關因素，以及各因素的 Cause Status。」

這比：

單純把所有維修經驗寫成文章

更適合：

AI Retrieval
（AI 檢索）。

三十八、GasPro AI 必須遵守的資料庫規則

未來可以建立以下基本規則：

Rule 1：

Failure Mode ≠ Root Cause

Rule 2：

Possible ≠ Confirmed

Rule 3：

Unknown ≠ Normal

Rule 4：

Missing Data ≠ Typical Value

Rule 5：

Corrective Action Success ≠ Root Cause Proof

Rule 6：

Gauge Pass ≠ Cylinder Accepted

Rule 7：

One Case ≠ Universal Rule

Rule 8：

Company Practice ≠ DOT Requirement

Rule 9：

Case-specific Cause ≠ Failure Mode-wide Cause

Rule 10：

Original Evidence Has Priority Over AI Inference
（原始證據優先於 AI 推論）

這十條規則，

可以成為：

GasPro AI

最重要的：

Knowledge Guardrail
（知識護欄）。

三十九、本篇的重要判斷觀念

Failure Mode
（故障模式）
≠
Incident
（事故）

Case ID
（案例編號）
≠
FM ID
（故障模式編號）

Failure Mode
≠
Root Cause

Different Cause
≠
Different Failure Mode

Same Cause
≠
Same Failure Mode

Failure Mode Name
≠
Cause Conclusion

Observed Condition
≠
Cause

Photo
≠
Root Cause

Gauge Result
≠
Visual Result

Cause
≠
Cause Status

Corrective Action
≠
Preventive Action

Corrective Action Success
≠
Root Cause Proof

No Incident
≠
No Failure Mode

Case Count
≠
Risk Rate

Missing Data
≠
Normal

UNKNOWN
≠
SAFE

One Case
≠
Universal Rule

Case-specific Root Cause
≠
Failure Mode-wide Root Cause

Public Knowledge
≠
Complete Internal Evidence

真正的 Failure Mode Database 應建立：

Case
（案例）
↓
Observed Condition
（觀察狀態）
↓
Failure Mode
（故障模式）
↓
Evidence
（證據）
↓
Cause
（原因）
＋
Cause Status
（原因確認狀態）
↓
Safety Barrier
（安全屏障）
↓
Corrective / Preventive Action
（矯正／預防措施）
↓
Lesson Learned
（經驗教訓）
↓
Knowledge Base
（知識庫）

四十、相關文章

・05-04｜Neck Leak 故障診斷

・05-05｜Cross Port Leak

・05-06｜Outlet Thread Damage

・05-07｜Toroid Damage

・05-08｜SiH4 Neck Leak 與 Thread Profile

・06-01～06-08｜實際事故與 Good Catch 案例

・09-01｜Stop Work 與 Good Catch

・09-02｜Multiple Safety Barriers

・09-03｜Gauge Pass ≠ Cylinder Accepted

・09-04｜Observed Condition、Direct Cause 與 Root Cause

・09-06｜新人異常判斷與技術知識傳承

注意事項

本文所建立之 FM-001～FM-013、Cause Status（原因確認狀態）、Safety Barrier（安全屏障）及 Failure Mode Database（故障模式資料庫）架構，主要用於 CylinderTech / GasPro AI 的內部技術知識管理。

FM ID 並非 DOT、PHMSA、CGA 或瓶閥／鋼瓶製造商的官方故障分類編號。

CONFIRMED、PROBABLE、POSSIBLE、UNCONFIRMED 亦為本知識庫使用的原因確認分類，不代表主管機關的統一事故調查分類。

Failure Mode Database 應保存 Observed Condition（觀察狀態）與 Evidence（證據），不得因後續推測而覆蓋原始事實。

公開 CylinderTech 網站使用案例資料時，應移除或遮蔽 Customer Information（客戶資訊）、完整 Cylinder Serial Number（鋼瓶序號）、Employee Information（人員資訊）、Internal Work Order（內部工單）及其他不適合公開的資訊。

資料庫中的 Possible Cause（可能原因）僅作為調查方向，不得直接轉換為 Confirmed Root Cause（已確認根本原因）。

本文為故障資料管理與技術知識架構，不提供特殊氣體鋼瓶洩壓、排放、充填、PRD 拆裝、瓶閥拆卸、螺紋重新加工或其他危險操作程序。

最後更新：2026-09-30