> 版权所有 © 2026 广州行道昭元文化传播有限公司 保留所有权利。
> 本作品受《中华人民共和国著作权法》保护。禁止摘抄、改写后以任何形式再发布、转售，或用于商业培训、咨询交付等营利场景。
TBP问题解决教练（付费版）
> 把一句模糊的「出问题了」，变成一份可执行的八步问题解决工作表：现象量化 → 分解定位 → 目标 → 5Why 真因 → 管理漏洞 8×4 矩阵 → 对策 → 实施跟踪。
计费：按次付费调用（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/tbp-problem-solving |
| -------------------------------------------> |
| <----------- 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 工作表（可直接打印/归档）
- Step1–8 全流程表格（含 5Why 三层追因与管理层漏洞定位）
- 对策表：每条对策对应真因 + 责任层级 + 完成标准
- 全过程「禁止归责于人」自检铁律
本次实测规模：5,004 字 / 180 行（真实生成，非示意）
二、真实输出样例
> 下面是实际跑出来的成品节选（输入为演示数据，公司名做了替换）。目的是让你下单前就看到成品长什么样。
# TBP 问题解决分析工作表
- 生成日期：2026-10-07 ｜ 场景：**设备**
- 问题陈述：3号注塑机近一个月频繁停机，每次约40分钟，影响交付
- 数据/事实：月停机6次，累计停机4小时
- 目标：月停机≤1次
> **教练声明**：本表为 AI 辅助生成的分析初稿，所有归类均为**待现场确认的假设**，必须以现地现物核实后修改；禁止把本表当作结论直接上报。
## 〇、四大铁律（全程自检）
- [ ] 现地现物：到现场、看实物
- [ ] 事实证据：用数据说话，不靠印象
- [ ] 因果可逆：A 变了 B 一定变，否则不是真因
- [ ] 禁止归责于人：追到「人」不能终止，必须继续追管理机制
## Step 1 明确问题（现象 → 可量化的问题）
| 项目 | 内容 | 待确认 |
|---|---|---|
| What（发生了什么） | 3号注塑机近一个月频繁停机，每次约40分钟，影响交付 | ☐ |
| When（何时开始/频度） | | ☐ |
| Where（哪台设备/哪道工序） | | ☐ |
| Who（谁发现/谁受影响） | | ☐ |
| How much（不良率/停机时长/损失） | 月停机6次，累计停机4小时 | ☐ |
| 与标准的差距 | 月停机≤1次 | ☐ |
> 检查：**现象 ≠ 问题**。把「设备坏了」变成「X 设备在 Y 工序每月停机 Z 小时」。
三、怎么用（含支付流程）
端点
POST https://polyester-appease-bulldog.ngrok-free.dev/pay/tbp-problem-solving
Content-Type: application/json
X-Service-Id: API_A1D28E85CE804B49
支付流程（三步）
整个流程只有三步，支付由 Agent 平台（支付宝）在对话里完成，你不用自己付款、不用注册、不用填卡号：
第 ① 步 发起请求（不带支付凭证）
POST /pay/tbp-problem-solving ← 你的 AI 助手代你发
↓
第 ② 步 服务返回「账单」
HTTP 402 + 账单信息（含订单号、9.90 元、商家签名）
→ 你的 Agent 会弹出支付宝付款，确认即可
↓
第 ③ 步 带着支付凭证重发同一个请求
POST /pay/tbp-problem-solving + 头 Payment-Proof
→ HTTP 200，返回成品
关键点
- 同一份支付凭证可以重复重试，返回的是已缓存的结果，不会重复扣费
- 如果第 ② 步你没付，第 ③ 步就过不去 —— 这是正常的，不是故障
- 支付有效期写在账单的 pay_before 字段里，过期后重新发起第 ① 步即可
- 最常见的卡点：不是在终端里 curl 就完事，必须由支持支付宝 AI 按量付费的 Agent 来发，它才会弹出付款；手动 curl 只会一直拿到 402
最小可用请求
curl -X POST https://polyester-appease-bulldog.ngrok-free.dev/pay/tbp-problem-solving \
-H 'Content-Type: application/json' \
-d '{}'
- 业务参数可放 POST 的 JSON body，也可用
GET + ?payload=<urlencoded json> - 接口自述：
GET /help；健康检查：GET /healthz（返回服务版本号）
四、输入字段
| 字段 | 必填 | 说明 | 示例 |
|---|---|---|---|
problem |
必填 | 问题描述。写清「对象 + 现象 + 量化数据」，建议 15 字以上 | 3号注塑机近一个月频繁停机，每次约40分钟 |
data |
可选 | 已掌握的量化事实（频率、时长、损失、不良率…） | 月停机6次，累计停机4小时 |
target |
可选 | 目标状态（SMART） | 月停机≤1次 |
scene |
可选 | 场景，便于套用对应判读：device/quality/delivery/cost/safety | device |
五、算法口径（结果怎么算出来的）
> 这一节回答「实际怎么算的，我能不能核对」。下面写的是引擎里真实使用的公式与判读阈值。
八步结构（工作表固定按此八步展开，每步都有独立表格）：
| 步 | 产出 | 引擎怎么填 |
|---|---|---|
| Step 1 明确问题 | 5W1H + 与标准的差距表 | 从 problem 抽关键词填入 What/Where，未给的部分留「待确认」 |
| Step 2 分解问题 | 分类定位表 | 按设备/工序/时间/批次等维度架好空表待填 |
| Step 3 设定目标 | SMART 目标行 | 直接采用 target；未给则留空 |
| Step 4 分析真因 | 5Why 三层追因 | 每层强制追到「管理机制」，不允许停在「人」 |
| Step 5 管理漏洞定位 | 8 类 × 4 责任层 = 32 格矩阵 | 按场景预置候选项，逐格打勾 |
| Step 6 制定对策 | 对策表 | 每条对策必须对应 Step 4 的真因 + Step 5 的责任层 |
| Step 7 实施对策 | 现地现物跟踪表 | 留实施/验证/日期位 |
| Step 8 固化 | 标准更新清单 | — |
四条强制铁律（工作表顶部自检清单，全程适用）：
1. 现地现物 —— 到现场、看实物，不看二手报表
2. 事实证据 —— 用数据说话，不靠印象
3. 因果可逆 —— A 变了 B 一定变，否则不是真因
4. 禁止归责于人 —— 追到「人」不能终止，必须继续追到管理机制
三步核查逻辑：标准本体（有没有标准）→ 理解传导（员工知不知道）→ 作业遵守（有没有照做）。任一环节「不完整/缺失」即进入 Step 4 真因分析；三层全「有」则问题在遵守层、不是标准层。
六、常见坑 / 不要做的事
❌ 别把「设备坏了」当问题 —— 现象 ≠ 问题。要变成「X 设备在 Y 工序每月停机 Z 小时」。
❌ 别跳过 Step 2 直接 5Why —— 没有分解定位，5Why 会追到错误的方向。
❌ 5Why 追到「员工不认真」就停 —— 这是最典型的失败。引擎会强制继续追到管理机制。
❌ 别把对策写成「加强管理」「提高意识」 —— 对策必须对应真因 + 具体责任层 + 可验证的完成标准。
❌ 别拿初稿直接上报 —— 工作表里所有归类都是待现场确认的假设。
七、常见错误与处理
输入不合规时，服务返回 HTTP 400 + JSON，其中 code 是错误码、message 是中文原因、hint 是怎么改、example 是可照抄的正确写法。这种情况不会收费。
| code | 触发原因 | 怎么处理 |
|---|---|---|
MISSING_PROBLEM |
没传 problem | 补上 problem 字段 |
PROBLEM_TOO_SHORT |
描述太短，做不了 5Why | 写清对象+现象+量化数据，建议 15 字以上 |
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：可以，但 data/target 空着时工作表里会留下「待确认」空格，需要你补。给数据才能真正做 5Why。
Q：结果是最终结论吗？
A：不是。这是一份分析初稿，所有归类都是待现场确认的假设，必须现地现物核实后修改。
Q：一遍不满意能重跑吗？
A：同一 Payment-Proof 重试返回缓存结果、不重复计费；换个问题重新提交则是新的一次调用。
Q：怎么确认自己没被重复扣费？
A：同一 Payment-Proof 的重复请求会返回缓存结果并带 already_fulfilled=true，不产生新订单。
Q：成品是什么格式？
A：JSON 响应里的 content 字段为 Markdown 文本，可直接保存、打印或贴进 Word/WPS。
十、适用边界
- ✅ 适合：制造业（汽车零部件 / 机械 / 电子 / 家电 / 食品 / 注塑等）现场管理场景
- ❌ 不适合：非制造业、纯财务/HR 分析
- 前置条件：需提供可计算的真实数据；引擎不会凭空编数据，样本不足时结论只作方向假设
十一、定价与许可
- 单价：9.90 元/次（支付宝「AI 按量付费」，serviceId
API_A1D28E85CE804B49） - 许可：Proprietary。可自用与对内交付；禁止再发布、转售或用于商业培训
- 卖家：广州行道昭元文化传播有限公司
生成内容为 AI 辅助分析初稿，所有归类与结论均为待确认假设，须以现地现物与更完整数据核实；不得直接作为考核依据。
