> 版权所有 © 2026 广州行道昭元文化传播有限公司　保留所有权利。
> 本作品受《中华人民共和国著作权法》保护。禁止摘抄、改写后以任何形式再发布、转售，或用于商业培训、咨询交付等营利场景。

设备管理全生命周期TPM系统（付费版）

> 给一份设备清单，生成整套 TPM 保全文档：定期定量保全计划、保全作业要领书、派工单、故障报告书、备件与易损件台账、OEE 与 MTBF 分析。

计费：按次付费调用（Pay Skill）。分析引擎在服务端，9.90 元/次，价格与调用方式见下文第三节。

付费接入协议（支付宝 AI 按量付费 / 402 协议）

本 Skill 为 Pay Skill：分析引擎在服务端，源文件依赖后端服务，脱离后端无法独立使用。服务端已按支付宝「AI 按量付费」规范完成改造，完整实现下列六个环节：

调用时序（probe → pay → complete → ack）

agent                                        paid-service
  |  probe: POST /pay/device-management                          |
  | -------------------------------------------> |
  | <----------- 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 平台在对话内闭环完成。

源文件依赖后端服务，脱离后端无法独立使用。

一、你会拿到什么

1. 一整套设备保全文档包（Markdown）
2. 定期定量保全计划：设备×部位×作业内容×频度×标准×工具×实施月份
3. 含术语字典与「主数据固化」约束，保证故障部位↔定保部位可闭合追溯

本次实测规模：62,938 字 / 2,057 行（真实生成，非示意）

二、真实输出样例

> 下面是实际跑出来的成品节选（输入为演示数据，公司名做了替换）。目的是让你下单前就看到成品长什么样。

# C1 定期定量保全计划（核心）

- 企业：____________ ｜ 制定日期：2026-10-07

> 定位：设备定期定量保全的源头计划。按 设备×部位×作业内容×频度×作业标准×方法工具×实施月份 编制。
> **填写说明：下图为空白可填写表格，请客户按每台设备实际部位、实际作业填写；文末「参考样例」仅供填写参考，不是客户实数据。**
> **术语约束（关键）**：以下字段为标准必选项，只能从文末「C1 术语字典」中选择填写，**禁止自由发挥**——否则数据无法统计、无法横向比较：作业项目／频度／方法工具。其它字段可结合设备实际准确填写。
> **部位固化（同主数据）**：「部位」列只能从 `references/主数据固化术语表.md` 的部位标准名中选择，保证定保部位↔故障部位可闭合追溯。

### EQ-01 注塑机（HT-160，关键等级 A）

| 序号 | 作业类型 | 部位 | 作业内容 | 频度 | 作业标准（量化） | 方法工具 | 实施月份 |
|---|---|---|---|---|---|---|---|
| 1 |  |  |  |  |  |  |  |
| 2 |  |  |  |  |  |  |  |
| 3 |  |  |  |  |  |  |  |
| 4 |  |  |  |  |  |  |  |
| 5 |  |  |  |  |  |  |  |
| 6 |  |  |  |  |  |  |  |
| 7 |  |  |  |  |  |  |  |
| 8 |  |  |  |  |  |  |  |
| 9 |  |  |  |  |  |  |  |
| 10 |  |  |  |  |  |  |  |

### EQ-02 装配线（ZX-200，关键等级 A）

| 序号 | 作业类型 | 部位 | 作业内容 | 频度 | 作业标准（量化） | 方法工具 | 实施月份 |

三、怎么用（含支付流程）

端点

POST https://polyester-appease-bulldog.ngrok-free.dev/pay/device-management
Content-Type: application/json
X-Service-Id: API_2B5AB34A241F42BD

支付流程（三步）

整个流程只有三步，支付由 Agent 平台（支付宝）在对话里完成，你不用自己付款、不用注册、不用填卡号：

第 ① 步  发起请求（不带支付凭证）
          POST /pay/device-management  ← 你的 AI 助手代你发
                 ↓
第 ② 步  服务返回「账单」
          HTTP 402 + 账单信息（含订单号、9.90 元、商家签名）
          → 你的 Agent 会弹出支付宝付款，确认即可
                 ↓
第 ③ 步  带着支付凭证重发同一个请求
          POST /pay/device-management + 头 Payment-Proof
          → HTTP 200，返回成品

关键点
- 同一份支付凭证可以重复重试，返回的是已缓存的结果，不会重复扣费
- 如果第 ② 步你没付，第 ③ 步就过不去 —— 这是正常的，不是故障
- 支付有效期写在账单的 pay_before 字段里，过期后重新发起第 ① 步即可
- 最常见的卡点：不是在终端里 curl 就完事，必须由支持支付宝 AI 按量付费的 Agent 来发，它才会弹出付款；手动 curl 只会一直拿到 402

最小可用请求

curl -X POST https://polyester-appease-bulldog.ngrok-free.dev/pay/device-management \
  -H 'Content-Type: application/json' \
  -d '{}'

• 业务参数可放 POST 的 JSON body，也可用 GET + ?payload=<urlencoded json>
• 接口自述：GET /help；健康检查：GET /healthz（返回服务版本号）

四、输入字段

五、算法口径（结果怎么算出来的）

> 这一节回答「实际怎么算的，我能不能核对」。下面写的是引擎里真实使用的公式与判读阈值。

定期定量保全计划的编制维度（引擎按此七维生成表格，一行一个作业项）：

设备 × 部位 × 作业内容 × 频度 × 作业标准 × 方法工具 × 实施月份

两条数据约束（这是 TPM 数据能用的前提）：
1. 术语字典 —— 「作业项目 / 频度 / 方法工具」只能从文末术语字典里选，禁止自由发挥；否则数据无法统计、无法横向比较。
2. 主数据固化 —— 「部位」列只能从标准部位名里选，目的是让定保部位 ↔ 故障部位可闭合追溯（哪台设备哪个部位老坏，一眼能连起来）。

按设备变更量生成：devices 有几台就生成几台的行；report=EQ-01 会额外生成该设备的故障报告书，workorder=本周 会额外生成派工单。

配套的分析口径（OEE / MTBF 等，与「制造业深度数据分析」同源）：OEE = 时间开动率 × 性能开动率 × 良品率；MTBF = 相邻故障间隔均值；MTTR = 平均修复时长。

六、常见坑 / 不要做的事

❌ 别只给设备名 —— 每台必须有 id 和 name，id 是台账追溯的钥匙。
❌ 别自己编「部位」和「频度」的叫法 —— 一定要用术语字典里的标准词，否则数据废掉。
❌ 别把计划表当摆设 —— 生成的是空白可填写表格，附的「参考样例」只是示范，不是你的实数据。
❌ 别一次传几百台 —— 单次上限 300 台，超了会被拦下（400）。
❌ 别只做定期更换 —— 威布尔 β≈1（随机故障）时定期更换无效，要转状态监测。

七、常见错误与处理

输入不合规时，服务返回 HTTP 400 + JSON，其中 code 是错误码、message 是中文原因、hint 是怎么改、example 是可照抄的正确写法。这种情况不会收费。

八、服务不可用时怎么办

本 Skill 的分析引擎运行在服务端，必须联网才能出结果。遇到下面情况请这样处理：

排查顺序：① GET /healthz 看服务是否活着 → ② 看返回 JSON 的 code → ③ 400/422 是数据问题、500/502 是服务问题。

九、FAQ

Q：只要设备名可以吗？

A：id 和 name 是必填（id 用于台账追溯），model/area/year/critical 可选但填了分析更准。

Q：设备很多怎么办？

A：单次上限 300 台，超过请分批提交。

Q：能生成空白表单自己填吗？

A：可以。生成的计划/要领书含空白可填写表格，另附「参考样例」仅供参考。

Q：「术语字典」是干什么的？

A：约束关键字段只能从标准选项里选，保证数据可统计、可横向比较。

Q：怎么确认自己没被重复扣费？

A：同一 Payment-Proof 的重复请求会返回缓存结果并带 already_fulfilled=true，不产生新订单。

Q：成品是什么格式？

A：JSON 响应里的 content 字段为 Markdown 文本，可直接保存、打印或贴进 Word/WPS。

十、适用边界

• ✅ 适合：制造业（汽车零部件 / 机械 / 电子 / 家电 / 食品 / 注塑等）现场管理场景
• ❌ 不适合：非制造业、纯财务/HR 分析
• 前置条件：需提供可计算的真实数据；引擎不会凭空编数据，样本不足时结论只作方向假设

十一、定价与许可

• 单价：9.90 元/次（支付宝「AI 按量付费」，serviceId API_2B5AB34A241F42BD）
• 许可：Proprietary。可自用与对内交付；禁止再发布、转售或用于商业培训
• 卖家：广州行道昭元文化传播有限公司

生成内容为 AI 辅助分析初稿，所有归类与结论均为待确认假设，须以现地现物与更完整数据核实；不得直接作为考核依据。