09-04｜Observed Condition、Direct Cause 與 Root Cause｜異常現象、故障模式與根本原因判斷
特殊氣體鋼瓶維修中，
最常見的診斷錯誤之一，
不是：
「沒有看到異常。」
而是：
「看到異常後，太快決定原因。」
例如：
發現 Neck Leak
（瓶頸洩漏）
就寫：
「安裝扭力過大。」
發現 PRD Loose
（PRD 鬆動）
就寫：
「工具碰到了 PRD。」
發現 Toroid Damage
（超環面損傷）
就寫：
「Gasket 鎖太緊。」
發現 Outlet Thread Damage
（出口螺紋損傷）
就寫：
「接頭沒有對準。」
這些原因：
可能是對的，
也可能只是：
Hypothesis
（假設）。
因此真正的故障分析，
第一步不是：
Guess the Cause
（猜原因）。
而是先分清楚：
What Did We Observe?
（我們看到什麼？）
What Failed?
（什麼失效？）
What Directly Produced the Failure?
（什麼直接造成失效？）
Why Was That Condition Allowed to Occur?
（為什麼這個狀況會發生？）
以及：
How Strong Is the Evidence?
（證據有多充分？）
本篇建立的核心原則是：
Observed Condition
（觀察狀態）
≠
Failure Mode
（故障模式）
≠
Direct Cause
（直接原因）
≠
Root Cause
（根本原因）
而且：
Possible
（可能）
≠
Confirmed
（已確認）
一、Observed Condition 是「實際看到什麼」
Observed Condition
（觀察狀態）
應該是：
Evidence-based Description
（以證據為基礎的描述）。
例如：
「PRD 六角部位位置與原 Witness Mark 不一致。」
「Cylinder Neck Area 發現洩漏。」
「Outlet Thread 局部牙紋變形。」
「Burst Disc 不存在於應有的 Assembly 中。」
「Pressure Panel 顯示非預期壓力。」
「Status Label 與 Work Record 不一致。」
這些描述的共同特點是：
不需要先知道原因，
也可以成立。
因此：
Observed Condition
應盡可能描述：
What Is Present
（存在什麼）
而不是：
Why It Happened
（為什麼發生）。
二、好的異常描述不要偷偷放入原因
例如：
「因為工具碰撞造成 PRD 鬆動。」
這一句同時混合了：
Observed Condition
＋
Cause Conclusion。
如果目前只有：
PRD Position Abnormality
以及：
附近存在 Tool Mark，
比較精確的寫法應該是：
Observed Condition：
PRD Position Abnormality
（PRD 位置異常）
Evidence：
Tool / Contact Mark Observed Near PRD
（PRD 附近發現工具／接觸痕跡）
Cause Status：
Tool Interference Possible
（工具干涉：可能）
如此可以避免：
Evidence
（證據）
被：
Conclusion
（結論）
取代。
三、Failure Mode 是「以什麼方式失效」
Failure Mode
（故障模式）
回答的不是：
Why?
（為什麼？）
而是：
How Did the Item Fail?
（這個項目以什麼形式失效？）
例如：
Neck Leak
Cross Port Leak
Outlet Thread Damage
Toroid Damage
PRD Loose
PRD Missing Component
PRD Leak
Cylinder Body Weld Area Leak
Unexpected Cylinder Pressure
Status Label / Record Mismatch
PRD Fuse Metal Activation。
這些都可以建立：
Failure Mode ID
（故障模式編號）。
但是：
Failure Mode
≠
Root Cause
這是整個故障資料庫最重要的原則之一。
四、Neck Leak 是 Failure Mode，不是 Root Cause
例如：
FM-001
Neck Leak
（瓶頸洩漏）。
它告訴我們：
Failure Location / Failure Behavior
（故障位置／失效表現）
發生在：
Cylinder Neck / Valve Connection Area
（鋼瓶瓶頸／瓶閥連接區域）。
但是 Neck Leak 本身沒有回答：
Why?
可能需要進一步調查：
Cylinder Neck Thread Condition
（瓶頸螺紋狀態）
Valve Thread Condition
（瓶閥螺紋狀態）
Thread Profile
（牙型）
Foreign Material
（異物）
Material Adhesion
（材料沾黏）
Assembly Alignment
（組裝對準）
Sealing Material
（密封材料）
Component Compatibility
（零件相容性）
以及其他可能因素。
所以：
Neck Leak
≠
Over-torque
Neck Leak
≠
Cross Thread
Neck Leak
≠
Damaged Cylinder Thread
除非：
Evidence Supports the Conclusion
（證據支持該結論）。
五、Direct Cause 是什麼？
Direct Cause
（直接原因）
可以理解為：
直接導致 Failure Mode
發生的條件或事件。
例如：
Outlet Thread Damage
如果有充分證據顯示：
Connector
（接頭）
在未正確對準的狀態下被強制咬合，
則：
Misalignment During Engagement
（咬合時未正確對準）
可能成為：
Direct Cause。
但是 Direct Cause
仍然不一定是：
Root Cause。
因為下一個問題是：
Why Was Misalignment Allowed to Continue?
（為什麼未對準的狀態仍然繼續？）
六、Root Cause 是更深一層的問題
Root Cause
（根本原因）
通常需要回答：
為什麼系統允許：
Direct Cause
發生並一路發展成：
Failure Mode。
例如：
Connector Misalignment
（接頭未對準）
可能是 Direct Cause。
但更深層可能需要調查：
Tool / Fixture Design
（工具／治具設計）
Work Method
（作業方法）
Training
（教育訓練）
Inspection Barrier
（檢查屏障）
Component Identification
（零件識別）
Work-space Limitation
（作業空間限制）
或：
Process Control
（製程控制）。
因此：
Operator Action
（作業人員動作）
也不應自動被當成：
Root Cause。
七、「人員操作錯誤」通常不是分析的終點
如果事件報告最後只有：
Root Cause：
Operator Error
（人員操作錯誤）
那麼通常還可以繼續問：
Why Was the Error Possible?
（為什麼這個錯誤可以發生？）
Was the Tool Appropriate?
（工具是否適合？）
Was the Component Easy to Misidentify?
（零件是否容易誤認？）
Was There a Physical Guard?
（是否有實體防護？）
Was There Independent Verification?
（是否有獨立確認？）
Was the Procedure Clear?
（程序是否清楚？）
Was the Work Condition Different from Normal?
（作業條件是否不同？）
也就是：
Human Error
（人為錯誤）
往往是：
Starting Point for Deeper Analysis
（深入分析的起點）
而不是：
Automatic Root Cause
（自動等於根本原因）。
八、Cause Status｜原因確認狀態
CylinderTech 後續案例建議統一使用：
Cause Status
（原因確認狀態）。
可以分成：
CONFIRMED
（已確認）
PROBABLE
（較可能）
POSSIBLE
（可能）
UNCONFIRMED
（未確認）。
這套分類主要用於：
Internal Knowledge Management
（內部知識管理）
與：
Failure Analysis
（故障分析），
不是 DOT / PHMSA 的官方事故分類。
九、CONFIRMED｜已確認
CONFIRMED
代表：
目前存在足夠證據，
可以支持該原因判斷。
例如 06-08：
NH3 Drum Overheating
（NH3 Drum 過熱）
案例。
已確認：
Temperature Sensor
（溫度偵測器）
回傳的溫度資訊
與實際狀態不符，
造成控制系統：
Continued Heating
（持續加熱）。
事件鏈可以建立為：
Temperature Sensor Malfunction
（溫度偵測器異常）
↓
Incorrect Temperature Feedback
（錯誤溫度回饋）
↓
Heating Continues
（持續加熱）
↓
Drum Overheating
（Drum 過熱）
↓
PRD Fuse Metal Reaches Activation Condition
（PRD Fuse Metal 達到動作條件）
↓
Fuse Metal Activation
（Fuse Metal 動作）
↓
NH3 Gas Release
（NH3 氣體釋放）
在這個案例中：
Temperature Sensor Malfunction
具有已確認的證據支持。
因此：
Cause Status = CONFIRMED。
十、PRD Fuse Metal Activation 不是 Root Cause
同一個 NH3 Drum 案例，
如果只看到：
Fuse Metal Melted
（Fuse Metal 熔化）
就寫：
Root Cause = PRD Failure
會把：
Safety Device Response
（安全裝置反應）
誤認成：
Cause
（原因）。
實際上：
Fuse Metal Activation
是事件鏈後段的：
Observed / Functional Response
（觀察到的／功能性反應）。
因此：
PRD Activation
≠
Root Cause
Fuse Metal Melted
≠
PRD Defect
Replace PRD
≠
Root Cause Corrected
這是一個非常典型的：
Failure Mode / Cause Confusion
（故障模式與原因混淆）。
十一、PROBABLE｜較可能
PROBABLE
代表：
目前證據較支持某個原因，
但是：
Critical Evidence
（關鍵證據）
仍不足以將它提升為：
CONFIRMED。
例如：
某個 PRD Position Abnormality
同時存在：
Tool Mark
工作位置吻合
時間順序吻合
且其他可能原因較少。
這時：
Tool Interference
可能被評估為：
PROBABLE。
但是如果：
沒有直接觀察
沒有 Before / After Photo
沒有明確接觸證據，
仍不應寫成：
CONFIRMED。
十二、POSSIBLE｜可能
POSSIBLE
代表：
這個原因在技術上：
Can Explain the Failure
（可以解釋故障）
但目前證據不足以表示：
它比其他原因更有可能。
例如：
PRD Loose
可能與：
Tool Interference
Machine Interference
Fixture Contact
Previous Condition
Assembly Condition
等因素有關。
如果只有：
「這個工具曾經在附近使用。」
那麼：
Tool Interference
最多可能只是：
POSSIBLE。
因此：
Tool Used Nearby
（工具在附近使用）
≠
Tool Contact Confirmed
（工具接觸已確認）
十三、UNCONFIRMED｜未確認
有些案例經過調查後，
仍然無法確認：
Why It Happened。
這並不代表：
調查失敗。
正確做法可能就是：
Cause Status = UNCONFIRMED。
例如：
已確認：
Neck Leak。
也確認：
某區域存在：
Thread Profile Abnormality。
但是如果沒有足夠資料判斷：
這個牙型異常是在：
Manufacturing
Previous Service
Valve Installation
Previous Maintenance
或其他階段形成，
就不應自行補上一個：
Root Cause。
因此：
Unknown
（未知）
是可以接受的技術結論。
Invented Certainty
（虛構的確定性）
才是更大的問題。
十四、Possible ≠ Confirmed
這一句值得在整個網站反覆使用：
Possible
（可能）
≠
Confirmed
（已確認）
例如：
Over-torque Can Cause Damage
（過扭力可能造成損傷）
是一個：
Technical Possibility
（技術可能性）。
但：
Damage Observed
（發現損傷）
≠
Over-torque Confirmed
（已確認過扭力）
除非具有：
Torque Record
（扭力紀錄）
Physical Evidence
（實體證據）
Process Evidence
（製程證據）
或其他：
Supporting Evidence
（支持證據）。
十五、案例：Toroid Damage
FM-004：
Toroid Damage
（超環面損傷）。
現場可能看到：
Sealing Surface Damage
（密封面損傷）
以及：
Damaged Gasket
（墊片損傷）。
但是：
Damaged Gasket
≠
Gasket Caused the Damage
同樣：
Toroid Damage
≠
Over-torque Confirmed
需要進一步確認：
Gasket Condition
Gasket Material
Surface Condition
Foreign Material
Assembly History
Alignment
Applied Load
Tool / Fixture
以及其他證據。
因此在原因沒有確認前，
文章應寫：
Possible Contributing Factor
（可能影響因素）
而不是：
Confirmed Root Cause。
十六、案例：PRD Loose
FM-007：
PRD Loose / Position Abnormal
（PRD 鬆動／位置異常）。
已觀察到：
PRD Position Changed
（PRD 位置改變）
這是：
Observed Condition。
Failure Mode：
PRD Loose / Position Abnormal。
但是：
Tool Interference
仍需要證據。
因此：
Position Change
≠
Tool Contact Confirmed
Tool Mark
≠
Root Cause Confirmed
Tool Used Near PRD
≠
Tool Caused PRD Movement
Retightened Successfully
≠
Root Cause Confirmed
這個案例非常適合訓練：
Evidence vs Assumption
（證據與假設）
的區別。
十七、案例：Burst Disc Missing
FM-008：
PRD Missing Component
（PRD 零件缺失）。
如果已確認：
Burst Disc
在 Assembly 中缺失，
那麼：
Missing Burst Disc
就是：
Observed Condition / Failure Mode。
但是如果直接寫：
Root Cause = Operator Forgot
（根本原因＝作業員忘記）
仍然太快。
還需要問：
Was the Correct Part Available?
（正確零件是否可取得？）
Was Component Verification Required?
（是否要求零件確認？）
Was Assembly Completeness Checked?
（是否確認組裝完整性？）
Was There an Independent Check?
（是否有獨立確認？）
Could Exterior Inspection Detect It?
（外觀檢查能否發現？）
Was the Work Instruction Adequate?
（作業文件是否足夠？）
因此：
Missing Component
≠
Operator Forgot
即使最後證明：
Operator Omission
（人員遺漏）
確實是 Direct Cause，
仍可能存在更深層：
System Cause
（系統原因）。
十八、Corrective Action ≠ Cause
這是另一個很常見的錯誤。
例如：
發現洩漏後：
Replace Gasket
（更換墊片）
結果：
Leak Stops
（洩漏停止）。
不能因此直接推論：
Root Cause = Bad Gasket。
因為：
Corrective Action
可能同時改變了：
Contact Condition
Alignment
Surface Cleanliness
Assembly Condition
以及其他因素。
因此：
Corrective Action Success
（矯正措施成功）
≠
Root Cause Proof
（根本原因證明）
十九、Replace Part ≠ Root Cause Corrected
如果每次發生問題都：
Replace the Part
（更換零件）
事件可能暫時消失。
但是如果真正 Root Cause 是：
Tool Interference
Wrong Assembly Method
Incorrect Part Identification
Process Control Weakness
Temperature Sensor Failure
或：
Missing Verification Barrier，
只換零件並沒有真正解決問題。
因此：
Part Replaced
（零件已更換）
≠
System Cause Removed
（系統原因已消除）
二十、Evidence 應該先於 Conclusion
故障分析最好建立：
Evidence First
（證據優先）
的順序。
例如：
Evidence 1：
PRD Witness Mark Position Changed
Evidence 2：
Tool Mark Observed
Evidence 3：
Work Record Shows Valve Installation Performed
Evidence 4：
No Before-work Photo Available
然後才進行：
Cause Evaluation
（原因評估）。
而不是：
先決定：
「一定是工具碰到。」
再去找：
Supporting Evidence。
後者容易形成：
Confirmation Bias
（確認偏誤）。
二十一、Before / After Evidence 非常重要
很多維修案例最大的問題是：
只有：
After Condition
（事後狀態）。
沒有：
Before Condition
（事前狀態）。
例如：
作業後發現 PRD Position Abnormal。
但是如果沒有：
Before-work Photo
Before-work Witness Mark Record
Before-work Inspection Record，
就很難回答：
Was It Already Like This?
（原本是否已經如此？）
因此對：
Critical Component
（關鍵零件）
建立適當的：
Before / After Evidence
可以大幅提高：
Cause Analysis Quality
（原因分析品質）。
二十二、照片不是 Root Cause，但可以是 Evidence
照片可以證明：
At This Time, This Condition Existed
（在這個時間點存在這個狀態）。
例如照片可以顯示：
Missing Component
Thread Damage
Tool Mark
PRD Position
Label
Weld Leak Location。
但是照片本身通常不能直接證明：
Why It Happened。
因此：
Photo Evidence
（照片證據）
≠
Root Cause
但：
Photo Evidence
＋
Process Record
＋
Before / After Comparison
＋
Physical Evidence
可以共同建立更強的：
Causal Evidence
（因果證據）。
二十三、時間順序也是重要證據
Cause
必須在：
Failure
之前存在或發生。
因此：
Timeline
（時間線）
非常重要。
例如：
Before Valve Installation：
PRD Position Normal
After Valve Installation：
PRD Position Changed
這比只有：
After Photo
具有更高的分析價值。
但是：
Temporal Sequence
（時間先後）
≠
Causation Confirmed
（因果關係已確認）
也就是：
A Happened Before B
≠
A Definitely Caused B
仍然需要其他證據。
二十四、Correlation ≠ Causation
如果十次 Neck Leak
有八次都發生在某個：
Valve Model
不能直接說：
Valve Model Is the Root Cause。
這只能表示：
Correlation
（相關性）
值得進一步研究。
還需要排除：
Usage Frequency
（使用頻率）
Gas Service
Cylinder Type
Installation Method
Maintenance History
Operator
Tool
Batch
Age
以及其他：
Confounding Factors
（混雜因素）。
因此：
Correlation
（相關）
≠
Causation
（因果）
Failure Mode Database
累積資料之後，
這一點會越來越重要。
二十五、Root Cause 可以不只一個
實際事故不一定只有：
One Root Cause。
例如一件 Missing Component Event
可能同時存在：
Work Instruction Weakness
No Independent Verification
Poor Component Identification
以及：
Training Gap。
因此不要強迫所有事件：
一定只能填一個：
Root Cause。
更適合的方式可能是區分：
Direct Cause
（直接原因）
Contributing Factor
（促成因素）
System Cause
（系統原因）
以及：
Root Cause
（根本原因）。
二十六、Contributing Factor 不是 Root Cause
Contributing Factor
（促成因素）
代表：
它增加事件發生的可能性或嚴重程度，
但不一定是主要根本原因。
例如：
Limited Tool Clearance
（工具操作空間有限）
可能增加：
Tool Interference
的可能性。
但是：
Limited Clearance
不一定單獨足以造成：
PRD Movement。
因此它可能更適合標示：
Contributing Factor。
這比硬把所有因素都叫：
Root Cause
更精確。
二十七、建立標準 Failure Analysis Record
CylinderTech / GasPro AI
未來可以統一使用：
Failure Analysis Record
（故障分析紀錄）。
建議欄位：
Case ID
（案例編號）
Failure Mode ID
（故障模式編號）
Observed Condition
（觀察狀態）
Failure Location
（故障位置）
Evidence
（證據）
Before Condition
（事前狀態）
After Condition
（事後狀態）
Direct Cause
（直接原因）
Contributing Factor
（促成因素）
Root Cause
（根本原因）
Cause Status
（原因確認狀態）
Corrective Action
（矯正措施）
Preventive Action
（預防措施）
Failed Barrier
（失效屏障）
Successful Barrier
（成功屏障）
Lesson Learned
（經驗教訓）
如此每一件案例
都可以用同一套：
Diagnostic Language
（診斷語言）
記錄。
二十八、不要讓 AI 把 Possible 自動改成 Confirmed
未來 GasPro AI
整理案例時，
這是一條非常重要的規則。
原始紀錄如果寫：
「疑似工具干涉」
AI 不應潤飾成：
「工具干涉造成 PRD 鬆動。」
原始紀錄如果寫：
「可能為過扭力」
AI 不應整理成：
「原因為過扭力。」
因此 AI Knowledge Base
應保留：
Cause Status。
例如：
Cause:
Tool Interference
Cause Status:
POSSIBLE
而不是只存：
Cause:
Tool Interference。
這樣可以避免：
AI-generated Certainty
（AI 產生不存在的確定性）。
二十九、網站文章也應保留不確定性
公開技術文章中，
不需要為了讓文章看起來：
「比較專業」
就把所有原因寫得非常肯定。
真正專業的寫法反而是：
Confirmed Evidence
（已確認證據）
Possible Cause
（可能原因）
Unconfirmed Factor
（未確認因素）
分開。
例如：
「本案例已確認 PRD 發生位置異常；工具干涉屬可能原因，但現有資料不足以確認其為唯一根本原因。」
這比：
「作業人員使用工具撞到 PRD，導致 PRD 鬆動。」
更符合：
Evidence-based Failure Analysis
（證據導向故障分析）。
三十、UNKNOWN 是可以接受的答案
故障分析最重要的紀律之一是：
Do Not Invent the Missing Evidence
（不要替不存在的證據補答案）。
如果：
Evidence Insufficient
（證據不足），
最正確的結果可能就是：
Root Cause：
UNCONFIRMED。
但是仍然可以做：
Risk Reduction
（風險降低）。
例如：
雖然無法確認某次 PRD Loose
一定由 Adjustable Wrench
造成，
但過去案例已顯示：
Tool Interference
具有實際風險。
因此公司仍然可以：
Restrict Tool Selection
（限制工具）
增加：
Physical Guard
Post-work Inspection
或：
Tool Clearance Control。
也就是：
Root Cause Unconfirmed
（根本原因未確認）
≠
No Preventive Action Possible
（無法採取預防措施）
三十一、Cause Status 可以隨新證據更新
Cause Status
不是永久固定。
例如最初：
Tool Interference = POSSIBLE
之後取得：
Before / After Photo
Tool Contact Mark
Witness Statement
Fixture Position Evidence
以及其他一致證據。
可能提升為：
PROBABLE
甚至：
CONFIRMED。
反過來，
如果新的證據否定原假設，
也應：
Downgrade / Reject the Hypothesis
（降低或排除原假設）。
因此：
Knowledge Base
應保留：
Evidence History
（證據歷程）
而不是只保留：
Final Sentence
（最後一句結論）。
三十二、建立「五層故障分析模型」
CylinderTech 後續可以統一使用：
Five-level Failure Analysis Model
（五層故障分析模型）。
Level 1：
Observed Condition
（觀察狀態）
我們看到什麼？
↓
Level 2：
Failure Mode
（故障模式）
什麼以什麼方式失效？
↓
Level 3：
Direct Cause
（直接原因）
什麼直接造成失效？
↓
Level 4：
Contributing / System Factors
（促成／系統因素）
哪些條件讓失效更容易發生或沒有被攔截？
↓
Level 5：
Root Cause
（根本原因）
為什麼系統允許這個事件發生？
然後所有 Cause
再附上：
Cause Status
（原因確認狀態）：
CONFIRMED
PROBABLE
POSSIBLE
UNCONFIRMED。
三十三、本篇的重要判斷觀念
Observed Condition
（觀察狀態）
≠
Root Cause
（根本原因）
Failure Mode
（故障模式）
≠
Root Cause
Direct Cause
（直接原因）
≠
Automatically Root Cause
Human Error
（人為錯誤）
≠
Automatic Root Cause
Neck Leak
≠
Over-torque Confirmed
Toroid Damage
≠
Over-torque Confirmed
PRD Loose
≠
Tool Interference Confirmed
Tool Mark
≠
Root Cause Confirmed
Tool Used Nearby
≠
Tool Contact Confirmed
Missing Component
≠
Operator Forgot
Fuse Metal Activation
≠
PRD Defect
PRD Activation
≠
Root Cause
Corrective Action Success
≠
Root Cause Proof
Part Replaced
≠
Root Cause Corrected
Photo Evidence
≠
Root Cause
A Happened Before B
≠
A Caused B
Correlation
≠
Causation
Possible
≠
Confirmed
UNKNOWN
≠
Failure of Analysis
Root Cause Unconfirmed
≠
No Preventive Action Possible
真正完整的分析流程是：
Observe
（觀察）
↓
Describe
（描述）
↓
Classify Failure Mode
（分類故障模式）
↓
Collect Evidence
（收集證據）
↓
Build Timeline
（建立時間線）
↓
Develop Hypotheses
（建立原因假設）
↓
Test Against Evidence
（以證據驗證）
↓
Assign Cause Status
（設定原因確認狀態）
↓
Determine Corrective / Preventive Action
（決定矯正／預防措施）
↓
Update 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-02｜PRD Burst Disc 遺漏事故
・06-07｜瓶閥安裝後 PRD 鬆動案例
・06-08｜NH3 Drum 過熱與 PRD Fuse Metal 動作事故
・09-01｜Stop Work 與 Good Catch
・09-02｜Multiple Safety Barriers
・09-03｜Gauge Pass ≠ Cylinder Accepted
・09-05｜Failure Mode Database
・09-06｜新人異常判斷與技術知識傳承
注意事項
本文所使用的 Observed Condition（觀察狀態）、Failure Mode（故障模式）、Direct Cause（直接原因）、Contributing Factor（促成因素）、Root Cause（根本原因）及 Cause Status（原因確認狀態），主要用於 CylinderTech / GasPro AI 的故障分析與知識管理架構。
CONFIRMED、PROBABLE、POSSIBLE、UNCONFIRMED 為本知識庫的內部原因確認分類，不代表 DOT、PHMSA 或其他主管機關的統一官方事故分類。
故障原因應以 Evidence（證據）為基礎。若現有資料不足以支持特定原因，應保留 Possible 或 Unconfirmed 狀態，不應為了完成報告而將假設描述成已確認事實。
Corrective Action（矯正措施）成功不能單獨證明 Root Cause；同樣，更換零件、重新調整或檢查結果恢復正常，也不能單獨證明原始故障原因。
涉及特殊氣體、承壓鋼瓶、PRD、Cylinder Body、Thread Damage 或其他安全關鍵異常時，實際處置仍應依公司核准程序、製造商資料、適用法規及相關專業資格要求進行。
本文重點為 Failure Analysis（故障分析）與 Evidence Management（證據管理），不提供特殊氣體鋼瓶洩壓、排放、PRD 拆裝、瓶閥拆卸、重新攻牙或其他危險操作程序。
最後更新：2026-09-30
發佈留言
很抱歉，必須登入網站才能發佈留言。