> 版权所有 © 2026 广州行道昭元文化传播有限公司 保留所有权利。
> 本作品受《中华人民共和国著作权法》保护。禁止摘抄、改写后以任何形式再发布、转售，或用于商业培训、咨询交付等营利场景。
设备故障5Why真因分析（付费版）
> 把「设备又坏了」变成一份可执行的真因分析工作表：三层追因（物理现象 → 直接原因 → 管理机制）强制留证，8 类管理漏洞 × 4 层责任 = 32 格矩阵自动落格，对策锁死到责任层与责任人。
计费：按次付费调用（Pay Skill）。分析引擎在服务端，4.90 元/次，价格与调用方式见下文第三节。
付费接入协议（支付宝 AI 按量付费 / 402 协议）
本 Skill 为 Pay Skill：分析引擎在服务端，源文件依赖后端服务，脱离后端无法独立使用。服务端已按支付宝「AI 按量付费」规范完成改造，完整实现下列六个环节：
| # | 环节 | 实现 |
|---|---|---|
| 1 | 402 账单下发 | 无 Payment-Proof 请求头时返回 HTTP 402 + Payment-Needed 响应头（Base64URL 编码的订单 JSON，含 protocol / method 两层 + 商家 RSA2 签名） |
| 2 | 携带凭证重试 | 客户端完成付款后，携带 Payment-Proof 请求头重试同一 URL |
| 3 | 验付调用 | 服务端调用 alipay.aipay.agent.payment.verify 核验凭证（校验 active / trade_no / out_trade_no / amount / resource_id / pay_before 时效） |
| 4 | 履约确认 | 资源交付后调用 alipay.aipay.agent.fulfillment.confirm 发送履约回执，成功才返回 200 |
| 5 | 订单持久化与幂等 | 订单落库（out_trade_no 唯一约束）；同一 out_trade_no 重复请求只生成一次资源，复用缓存结果并标记 already_fulfilled=true，不重复计费 |
| 6 | 资源交付 | 返回 HTTP 200 + Payment-Validation 响应头 + 业务内容 |
调用时序（probe → pay → complete → ack）
agent paid-service
| probe: POST /pay/fault-5why |
| -------------------------------------------> |
| <----------- 402 + Payment-Needed 账单 ------ | ① 账单下发
| pay: 平台按账单完成扣款（对话内闭环） | ② 付款
| complete: 携 Payment-Proof 重试 |
| -------------------------------------------> |
| verify(验付) ------> 支付宝
| confirm(履约回执) --> 支付宝
| <---- 200 + Payment-Validation + 内容 ------- | ③ ack 交付
402 必需字段：protocol.{out_trade_no, amount, currency, resource_id, pay_before, seller_signature, seller_sign_type, seller_unique_id} ；method.{seller_name, seller_id, seller_app_id, goods_name, seller_unique_id_key, service_id}
支付依赖：服务端使用 alipay-sdk-python（模块 alipay.aop.api）+ pycryptodome（RSA2 签名）；客户端无需支付依赖，付款由 Agent 平台在对话内闭环完成。
源文件依赖后端服务，脱离后端无法独立使用。
一、你会拿到什么
- 一份完整 Markdown 追因工作表（可直接打印/归档）
- 三层追因表：每层必须留证，追到「人」不许停
- 管理漏洞 8×4 矩阵落格：自动给出该格的既定定义（不是自由发挥）
- 追因质量审核报告：未追到管理机制 / 未留证 / 未落格 / 归责于人 → 直接判不合格
- 对策表：每条对策对应真因 + 责任层 + 完成标准 + 期限
本次实测规模：1,873 字 / 50 行（真实生成，非示意）
二、真实输出样例
> 下面是实际跑出来的成品节选（输入为演示数据，公司名做了替换）。目的是让你下单前就看到成品长什么样。
# 设备故障 5Why 真因分析工作表
- 企业：**示例精密制造有限公司（脱敏）**
- 课题：**（未填写）**
- 判定：**✅ 合格**
---
| 项 | 内容 |
|---|---|
| What 什么故障 | 液压系统压力波动，成型时报警停机 |
| Where 哪台/哪工序 | 一车间 A 线 3 号机（HT-160） |
| When 何时/频率 | 2026-08~09 每月 4~5 次，多发生在连续生产 4 小时后 |
| Who 发现/涉及 | 操作工发现报警，保全班处理 |
| How 怎样发生 | 压力表指针抖动 → 系统报警 → 停机待修 |
| How much 停机时长/损失 | 月度非计划停机 6.5 小时；月产量损失约 1.8 万件 |
- 应有状态：HT-160 单机月度非计划停机 ≤ 1.0 小时（同类设备标杆值）
- 差距（量化）：**6.5 小时 vs 标准 1.0 小时 → 超出 5.5 小时（5.5 倍）**
## 二、三层追因（物理现象 → 直接原因 → 管理机制）
| 层级 | 内容 | 证据（须可现地现物复核） |
|---|---|---|
| 物理现象 | 液压油温升至 62℃（警戒值 55℃），油液黏度下降，压力建立不稳 → 报警 | 油温枪实测 62℃；报警记录 11 次（设备运行日志） |
| 直接原因 | 3 号机液压油连续使用 14 个月未更换；冷却器翅片积尘，散热能力下降 | 油品更换记录（上次 2025-07）；冷却器翅片目视积尘照片 |
三、怎么用（含支付流程）
端点
POST https://polyester-appease-bulldog.ngrok-free.dev/pay/fault-5why
Content-Type: application/json
X-Service-Id: API_6EC1113B41024EDA
支付流程（三步）
整个流程只有三步，支付由 Agent 平台（支付宝）在对话里完成，你不用自己付款、不用注册、不用填卡号：
第 ① 步 发起请求（不带支付凭证）
POST /pay/fault-5why ← 你的 AI 助手代你发
↓
第 ② 步 服务返回「账单」
HTTP 402 + 账单信息（含订单号、4.90 元、商家签名）
→ 你的 Agent 会弹出支付宝付款，确认即可
↓
第 ③ 步 带着支付凭证重发同一个请求
POST /pay/fault-5why + 头 Payment-Proof
→ HTTP 200，返回成品
关键点
- 同一份支付凭证可以重复重试，返回的是已缓存的结果，不会重复扣费
- 如果第 ② 步你没付，第 ③ 步就过不去 —— 这是正常的，不是故障
- 支付有效期写在账单的 pay_before 字段里，过期后重新发起第 ① 步即可
- 最常见的卡点：不是在终端里 curl 就完事，必须由支持支付宝 AI 按量付费的 Agent 来发，它才会弹出付款；手动 curl 只会一直拿到 402
最小可用请求
curl -X POST https://polyester-appease-bulldog.ngrok-free.dev/pay/fault-5why \
-H 'Content-Type: application/json' \
-d '{}'
- 业务参数可放 POST 的 JSON body，也可用
GET + ?payload=<urlencoded json> - 接口自述：
GET /help；健康检查：GET /healthz（返回服务版本号）
四、输入字段
| 字段 | 必填 | 说明 | 示例 |
|---|---|---|---|
problem |
必填 | 故障现象描述。写清「设备/部位 + 现象 + 量化影响」，建议 15 字以上 | 3号注塑机液压压力不稳，每月停机4~5次，月损失6.5小时 |
phenomenon |
可选 | 5W1H 结构化现象：what/where/when/who/how/how_much | {"what":"压力波动报警停机","where":"一车间A线3号机","how_much":"月停机6.5小时"} |
why_chain |
可选 | 追因链，每项含 层/内容/证据。层建议三段：物理现象 / 直接原因 / 管理机制 | [{"层":"物理现象","内容":"油温62℃","证据":"油温枪实测"}] |
matrix |
可选 | 管理漏洞落格，每项含 类别/层。类别为 8 类之一，层为 4 层之一 | [{"类别":"标准作业类","层":"公司管理"}] |
why_a / why_b / why_c |
可选 | 三层管理三问：标准本体 / 理解传导 / 遵守维持 | "标准本体有问题：周期按自然年设定，三班机被系统性漏保" |
countermeasures |
可选 | 对策表，每项含 对策/对应真因/责任层/责任人/完成标准/期限 | — |
evaluation |
可选 | 结果指标与管理过程指标（双轨验证） | — |
五、算法口径（结果怎么算出来的）
> 这一节回答「实际怎么算的，我能不能核对」。下面写的是引擎里真实使用的公式与判读阈值。
三层追因（引擎逐层校验，缺一层即判不合格）：
第 1 层 物理现象 —— 看得见/测得着的客观表现（如油温 62℃），必须带量化值与证据
第 2 层 直接原因 —— 为什么会出现该现象（如 14 个月未换油 + 冷却器积尘）
第 3 层 管理机制 —— 为什么这个原因能长期存在（如定保周期按自然年设定，三班机被系统性漏保）
追到「人」不许停：出现「操作工没做/没注意」时，必须继续追问三层管理三问——
Why-A 标准本体（标准是否可执行）→ Why-B 理解传导（TJI 指导是否到位）→ Why-C 遵守维持（有无遵守点检与纠偏）。
管理漏洞 8×4 矩阵（32 格穷举，引擎内置）：
| 类别 | 公司管理 | 中层（自） | 中层（它） | 班组管理 |
|---|---|---|---|---|
| 设计缺陷类 | 技术规范缺失 | 现场经验未利用 | 未遵守技术规范 | 之前未发生过而未重视 |
| 标准作业类 | 识别不充分 | 过去未发生过 | 以为不重要 | 不知道如何做 |
| 作业遵守类 | 新增设备未实施 | 未指派作业 | 未执行定期定量作业 | 理解错了 |
| 物品采购管理类 | 缺失采购流程 | 采购流程不合理 | 理解错了采购流程 | 不知道采购流程 |
| 快速反应类 | 快速处置规则缺失 | 快速处置规则不合理 | 未遵守快速处置规则 | 呼叫手段不良 |
| 人员技能类 | 技能教育内容缺失 | 教育训练不足 | 技能评价缺失 | 工作指导方法不良 |
| 图纸资料类 | 无图纸 | 图纸管理不良 | 软件未备份 | 图纸/程序修改管理不良 |
| 保养时间类 | 无错时出勤意识 | 无错时出勤机制 | 人员不足 | 行走距离远 |
责任层的性质（决定问题严重度）：公司管理 = 「缺失」类（体制问题，须上升公司级课题）；中层（自）= 「管理不到位」；中层（它）= 「协作失败」；班组管理 = 「能力/认知不足」。
体制级判据：同一漏洞类别在 ≥3 个责任层同时命中 → 不是单点问题，必须做体制改善（引擎自动标注）。
六、常见坑 / 不要做的事
❌ 停在「操作工不小心」 —— 最典型的失败，等于没分析；引擎会直接判不合格。
❌ 一层就结束 —— 5Why 至少要追到管理机制层，三层缺一层就不算完成。
❌ 把现象当原因 —— 「轴承温度高」是现象，不是原因；原因要回答「为什么会发生这个现象」。
❌ 管理漏洞勾笼统选项 —— 「定期定量计划 ❌」这种没法对应责任人与对策，必须落到 32 格中的具体格。
❌ 对策与真因不对应 —— 对策没打中真因，问题必然复发。
❌ 不做横展 —— 同类设备/部位不排查，等于只修了一台。
七、常见错误与处理
输入不合规时，服务返回 HTTP 400 + JSON，其中 code 是错误码、message 是中文原因、hint 是怎么改、example 是可照抄的正确写法。这种情况不会收费。
| code | 触发原因 | 怎么处理 |
|---|---|---|
MISSING_PROBLEM |
没传 problem | 补上 problem 字段（故障现象） |
PROBLEM_TOO_SHORT |
描述太短，做不了真因分析 | 写清设备/部位+现象+量化影响，建议 15 字以上 |
INVALID_PHENOMENON |
phenomenon 不是对象 | 改为 {what, where, when, who, how, how_much} 形式 |
INVALID_WHY_CHAIN |
why_chain 不是数组 | 改为 [{层,内容,证据}, ...] 形式 |
INVALID_MATRIX |
matrix 不是数组 | 改为 [{类别,层}, ...]；类别须为 8 类之一、层须为 4 层之一 |
Payment-Needed |
未付或支付凭证无效 | 按 402 账单完成支付后重试 |
ENGINE_INPUT_ERROR |
数据本身无法分析 | 按 message 修正后，用同一 Payment-Proof 重试，不重复计费 |
INTERNAL_ERROR |
服务内部异常 | 稍后重试；持续失败请联系我们（提供你的 curl 命令） |
八、服务不可用时怎么办
本 Skill 的分析引擎运行在服务端，必须联网才能出结果。遇到下面情况请这样处理：
| 现象 | 原因 | 处理 |
|---|---|---|
GET /healthz 不通或超时 |
服务暂时不可用 | 稍后重试；已支付的订单用同一 Payment-Proof 重试不会重复扣费 |
| 返回 402 但支付失败 | 支付宝侧网络/失败 | 在对话里重试支付；订单有 pay_before 时效，过期后重新发起即可 |
| 返回 422 | 是你的数据不满足分析条件（不是服务故障） | 按 hint 修正数据后重试 |
| 长时间无响应 | 引擎计算量大 | 超过 60 秒请重试；重试复用同一凭证不会重复计费 |
排查顺序：① GET /healthz 看服务是否活着 → ② 看返回 JSON 的 code → ③ 400/422 是数据问题、500/502 是服务问题。
九、FAQ
Q：只给一句故障现象行不行？
A：可以——引擎会输出完整工作表框架并标出「待填」处，但不留证的原因不予采信，审核会判不合格并列出缺什么。
Q：为什么我的分析被判「不合格」？
A：四种情况：① 没追到「管理机制」层（追到「人」就停）② 某一层没写证据 ③ 管理漏洞没落格 ④ 出现「操作工不注意」这类归责于人的表述。这正是本引擎的价值——把走流程的分析拦下来。
Q：32 格矩阵和一般检查表有什么不同？
A：8 类漏洞 × 4 层责任的每一格都有既定定义（如「标准作业类 × 公司管理 = 识别不充分」），必须落到具体格子，才能对应到具体责任人与对策；勾「定期定量计划 ❌」这种笼统选项不行。
Q：一遍不满意能重跑吗？
A：同一 Payment-Proof 重试返回缓存结果、不重复计费；换个故障重新提交则是新的一次调用。
Q：怎么确认自己没被重复扣费？
A：同一 Payment-Proof 的重复请求会返回缓存结果并带 already_fulfilled=true，不产生新订单。
Q：成品是什么格式？
A：JSON 响应里的 content 字段为 Markdown 文本，可直接保存、打印或贴进 Word/WPS。
十、适用边界
- ✅ 适合：制造业（汽车零部件 / 机械 / 电子 / 家电 / 食品 / 注塑等）现场管理场景
- ❌ 不适合：非制造业、纯财务/HR 分析
- 前置条件：需提供可计算的真实数据；引擎不会凭空编数据，样本不足时结论只作方向假设
十一、定价与许可
- 单价：4.90 元/次（支付宝「AI 按量付费」，serviceId
API_6EC1113B41024EDA） - 许可：Proprietary。可自用与对内交付；禁止再发布、转售或用于商业培训
- 卖家：广州行道昭元文化传播有限公司
生成内容为 AI 辅助分析初稿，所有归类与结论均为待确认假设，须以现地现物与更完整数据核实；不得直接作为考核依据。
