> 版权所有 © 2026 广州行道昭元文化传播有限公司 保留所有权利。
> 本作品受《中华人民共和国著作权法》保护。禁止摘抄、改写后以任何形式再发布、转售，或用于商业培训、咨询交付等营利场景。
企业安全管理应有状态（付费版）
> 给一份现场发生源清单，直接出一份重点灾害发生源审核报告：自动归入重点灾害 R1~R7 归类（机械卷入 / 重物接触 / 厂内车辆 / 高处坠落 / 触电 / 高温物），按「严重度 × 频度」判 A/B/C 风险等级，给出点检周期与责任人，并检出违反「硬件优先」原则的发生源——有致命可能却只靠管理/个人防护的，一律强制 A 级。
计费：按次付费调用（Pay Skill）。分析引擎在服务端，9.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/safety |
| -------------------------------------------> |
| <----------- 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，可直接打印/汇报）
- 重点灾害 R1~R7 归类分布（先锁 TOP，资源不摊平）
- A 级发生源清单：必须硬件对策 + 停机规则明确
- 「硬件优先」违规检出：指出哪些致命风险只靠管理/教育/防护用品在硬撑
- 横展检查清单（同类别 → 同类设备/同类作业）
- 台账字段缺口清单（缺责任人的台账等于没台账）
- 规范化台账 CSV（16 列，可直接进 EHS / CMMS 系统）
本次实测规模：1,983 字 / 58 行（真实生成，非示意）
二、真实输出样例
> 下面是实际跑出来的成品节选（输入为演示数据，公司名做了替换）。目的是让你下单前就看到成品长什么样。
# 重点灾害发生源审核报告
企业：示例精密制造有限公司（脱敏）｜车间/区域：机加 / 装配 / 物流｜台账日期：2026-10-08
## 一、总体
发生源共 **12** 处：**A 级 6 · B 级 3 · C 级 3**；硬件优先原则未达标 **3** 处；台账字段缺项 **0** 处。
> 口径：风险等级 = 严重度 × 频度；**有致命可能却没有设备（本质安全）对策的，一律强制 A 级**。
## 二、重点灾害分布（先锁 TOP，资源别摊平）
| 类别 | 名称 | 处数 | 其中 A 级 |
|---|---|---|---|
| R1 | 机械夹伤·卷入 | 1 | 1 |
| R2 | 重物接触（≥100kg） | 1 | 1 |
| R3 | 厂内车辆碰撞 | 2 | 1 |
| R4 | 高处坠落（≥2m） | 1 | 1 |
| R5 | 触电 | 1 | 1 |
| R6 | 高温物接触 | 1 | 0 |
| R7 | 其他（本企业特有重点） | 5 | 1 |
## 三、A 级发生源（必须硬件对策 + 停机规则明确）
| 编号 | 类别 | 设备 | 发生源位置 | 隐患机理 | 现行防护 | 点检周期 | 责任人 |
|---|---|---|---|---|---|---|---|
三、怎么用（含支付流程）
端点
POST https://polyester-appease-bulldog.ngrok-free.dev/pay/safety
Content-Type: application/json
X-Service-Id: API_39117C86EB734699
支付流程（三步）
整个流程只有三步，支付由 Agent 平台（支付宝）在对话里完成，你不用自己付款、不用注册、不用填卡号：
第 ① 步 发起请求（不带支付凭证）
POST /pay/safety ← 你的 AI 助手代你发
↓
第 ② 步 服务返回「账单」
HTTP 402 + 账单信息（含订单号、9.90 元、商家签名）
→ 你的 Agent 会弹出支付宝付款，确认即可
↓
第 ③ 步 带着支付凭证重发同一个请求
POST /pay/safety + 头 Payment-Proof
→ HTTP 200，返回成品
关键点
- 同一份支付凭证可以重复重试，返回的是已缓存的结果，不会重复扣费
- 如果第 ② 步你没付，第 ③ 步就过不去 —— 这是正常的，不是故障
- 支付有效期写在账单的 pay_before 字段里，过期后重新发起第 ① 步即可
- 最常见的卡点：不是在终端里 curl 就完事，必须由支持支付宝 AI 按量付费的 Agent 来发，它才会弹出付款；手动 curl 只会一直拿到 402
最小可用请求
curl -X POST https://polyester-appease-bulldog.ngrok-free.dev/pay/safety \
-H 'Content-Type: application/json' \
-d '{}'
- 业务参数可放 POST 的 JSON body，也可用
GET + ?payload=<urlencoded json> - 接口自述：
GET /help；健康检查：GET /healthz（返回服务版本号）
四、输入字段
| 字段 | 必填 | 说明 | 示例 |
|---|---|---|---|
sources |
必填 | 发生源清单数组，至少 1 条（上限 300 条） | [{"equipment":"CNC-07","source":"主轴皮带轮防护罩","phenomenon":"防护罩螺栓缺失1颗，手可触及旋转皮带轮","severity":"致命","frequency":"偶尔"}] |
sources[].equipment |
建议 | 设备编号（与设备台账一致，便于联动保全计划） | "CNC-07" |
sources[].source |
建议 | 发生源具体位置（写「主轴皮带轮防护罩」，不写「机床」） | "主轴皮带轮防护罩" |
sources[].phenomenon |
必填其一 | 隐患机理——为什么危险（与 source 至少给一个，否则无法归类） | "罩体可掀开，手可触及旋转皮带轮" |
sources[].protection |
建议 | 现行防护方式（写清有无、是否有效） | "固定式防护罩（螺栓缺失、无联锁）" |
sources[].severity |
建议 | 严重度：致命 / 重伤 / 轻伤 / 无伤害（默认轻伤） | "致命" |
sources[].frequency |
建议 | 频度：经常 / 偶尔 / 极少（默认偶尔） | "偶尔" |
sources[].countermeasures |
建议 | 对策数组，写清类型：设备对策 / 管理对策 / 个人防护——引擎据此判「硬件优先」 | ["个人防护：手套"] |
sources[].owner |
建议 | 点检责任人（缺了会被记入字段缺口） | "保全班 王" |
sources[].is_safety_device |
可选 | 是否涉及安全装置（防护罩/联锁/接地/安全阀）——true 则点检周期加严 | true |
sources[].history |
可选 | 该处或同类处的历史事故 | "同类设备3年前发生夹伤" |
五、算法口径（结果怎么算出来的）
> 这一节回答「实际怎么算的，我能不能核对」。下面写的是引擎里真实使用的公式与判读阈值。
① 重点灾害归类：按发生源的位置/机理文字匹配 R1–R6 的关键词库（含滚筒/卷入/输送带/运转等）；匹配不到归入 R7「其他（本企业特有重点）」。
| 类别 | 名称 | 典型发生源 |
|---|---|---|
| R1 | 机械夹伤·卷入 | 传动辊、齿轮、链条、皮带、冲压、剪板、注塑、机械手 |
| R2 | 重物接触（≥100kg） | 重型工装/铸件/模具倾倒坠落、吊具失效、吊点偏移 |
| R3 | 厂内车辆碰撞 | 叉车/牵引车倒车盲区、人车混行、拐角、充电区 |
| R4 | 高处坠落（≥2m） | 平台开口、临边、脚手架、梯具、检修作业 |
| R5 | 触电 | 电缆破损、控制柜、临时接线、接地失效、潮湿 |
| R6 | 高温物接触 | 熔融金属、热处理炉、高温管道、蒸汽、焊接飞溅 |
② 风险分级：风险值 = 严重度系数 × 频度系数（致命 4 / 重伤 3 / 轻伤 2 / 无伤害 1；经常 3 / 偶尔 2 / 极少 1），据此定 A/B/C。
③ 硬性升 A 规则：严重度 = 致命 且对策中无「设备对策」 → 强制升为 A 级。
④ 点检周期：A=1天 / B=7天 / C=30天；涉及安全装置 → A=1 / B=3 / C=14 天。
⑤ 横展与缺口：按类别生成横展清单；检出缺少设备编号/位置/机理/防护/责任人的条目。
六、常见坑 / 不要做的事
❌ 把「人的违章」当发生源写进去 —— 发生源识别的对象是设备、设施、布局、物料。人的违章往往只是结果。
❌ 只写「管理对策」就以为闭环了 —— 有致命风险却只靠制度/教育/手套，是最典型的自欺。硬件优先：设备 → 管理 → 个人防护。
❌ 部位写得太粗（「机床」「车间」） —— 无法定位、无法横展、无法点检。
❌ 不写责任人 —— 没有责任人的点检，等于没有点检（引擎会把它列进字段缺口）。
❌ 台账建完就存档 —— 新增设备、工艺变更后必须重新识别；否则新设备的风险完全在管控之外。
❌ 点检发现防护失效还继续生产 —— 必须停机锁定，维修复位并功能确认后才允许复工。
❌ 按自然年定周期 —— 三班机（24h/日）与两班机（16h/日）损耗完全不同，按自然年定会系统性漏保。
七、常见错误与处理
输入不合规时，服务返回 HTTP 400 + JSON，其中 code 是错误码、message 是中文原因、hint 是怎么改、example 是可照抄的正确写法。这种情况不会收费。
| code | 触发原因 | 怎么处理 |
|---|---|---|
MISSING_SOURCES |
没传 sources 或不是数组 | 传发生源数组，至少 1 条 |
SOURCE_NOT_OBJECT |
某条不是 JSON 对象 | 每条应为对象 |
MISSING_PHENOMENON |
某条缺 phenomenon 和 source | 两者至少给一个，否则无法归类到重点灾害类别 |
INVALID_SEVERITY |
severity 不在允许值内 | 致命 / 重伤 / 轻伤 / 无伤害 |
INVALID_FREQUENCY |
frequency 不在允许值内 | 经常 / 偶尔 / 极少 |
TOO_MANY_SOURCES |
超过 300 条 | 按车间/区域分批提交 |
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：不行。发生源要写到具体部位 + 隐患机理——比如「主轴皮带轮防护罩：螺栓缺失1颗、罩体可掀开、手可触及旋转皮带轮」。写得越具体，归类越准、对策越明确；写成「设备危险」这种话，引擎只能归入「其他」。
Q：「硬件优先违规」是怎么判的？
A：看你给的对策类型：有致命可能的（severity=致命）如果对策里没有「设备对策」（只写了管理对策/个人防护），一律触发告警并强制判 A 级。这是丰田「设备对策 > 管理对策 > 个人防护」原则的硬性落地。
Q：为什么点检周期有的 1 天、有的 14 天？
A：按风险等级给基准：A 每日 / B 每周 / C 每月；若该处涉及安全装置（防护罩、联锁、接地、安全阀），周期全面加严为 A 每日 / B 每 3 天 / C 每 14 天——因为安全装置一旦失效，防护等于没有。
Q：台账 CSV 能直接用吗？
A：是。16 列规范化字段（编号/类别/等级/设备/位置/机理/防护/严重度/频度/周期/责任人/三类对策/历史/备注），以 UTF-8-BOM 输出，Excel 双击不乱码、也可直接导入 EHS/CMMS。
Q：同一 Payment-Proof 重发会重复收费吗？
A：不会。同一凭证重试返回缓存结果；改台账重新提交则是新的一次调用。
Q：怎么确认自己没被重复扣费？
A：同一 Payment-Proof 的重复请求会返回缓存结果并带 already_fulfilled=true，不产生新订单。
Q：成品是什么格式？
A：JSON 响应里的 content 字段为 Markdown 文本，可直接保存、打印或贴进 Word/WPS。
十、适用边界
- ✅ 适合：制造业（汽车零部件 / 机械 / 电子 / 家电 / 食品 / 注塑等）现场管理场景
- ❌ 不适合：非制造业、纯财务/HR 分析
- 前置条件：需提供可计算的真实数据；引擎不会凭空编数据，样本不足时结论只作方向假设
十一、定价与许可
- 单价：9.90 元/次（支付宝「AI 按量付费」，serviceId
API_39117C86EB734699） - 许可：Proprietary。可自用与对内交付；禁止再发布、转售或用于商业培训
- 卖家：广州行道昭元文化传播有限公司
生成内容为 AI 辅助分析初稿，所有归类与结论均为待确认假设，须以现地现物与更完整数据核实；不得直接作为考核依据。
