> 版权所有 © 2026 广州行道昭元文化传播有限公司 保留所有权利。
> 本作品受《中华人民共和国著作权法》保护。禁止摘抄、改写后以任何形式再发布、转售，或用于商业培训、咨询交付等营利场景。
中基层管理者育成·梯队健康度诊断（付费版）
> 给一份「现任管理者 + 后备池」台账，直接出一份梯队健康度诊断报告：算出后备覆盖率、代理试岗率、五项晋升资格要件达成度、退出健康度，并检出五类致命问题——梯队断层（0.67 个后备顶 1 个岗）、跳过试岗直接任命、资格未闭环却要提拔、GL 被产线束缚（监督时间被侵占）、该限期改善/该退出的人还在管理岗上。
计费：按次付费调用（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/manager-dev |
| -------------------------------------------> |
| <----------- 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，含 A/B/C 级总评与整改优先级）
- 核心结论 3 条（结论前置，可直接对上汇报）
- 后备池逐人资格审查表：五项资格要件逐条打勾 + 缺口清单（缺课程 / 缺课题 / 缺试岗）
- 现任管理者预警表：限期改善 / 不胜任退出 / 监督时间被侵占
- 整改优先级（按「先补哪一环」排序，不是罗列问题）
- 规范化台账 CSV（可直接进 HR 系统）
本次实测规模：2,452 字 / 93 行（真实生成，非示意）
二、真实输出样例
> 下面是实际跑出来的成品节选（输入为演示数据，公司名做了替换）。目的是让你下单前就看到成品长什么样。
# 中基层管理者育成 · 梯队健康度诊断报告
**企业**：示例制造企业（脱敏） ｜ **管理岗位数**：6 ｜ **在池后备**：4 ｜ **现任管理者**：6
## 一、总评：**B 级**（64.2 / 100）—— 基本可用（有断点）
### 核心结论（3 条）
- **① 梯队断层**：后备覆盖率仅 **0.67**（< 1.0）——6 个管理岗位只有 4 名后备，出现离任将无人在池可补。
- **② 试岗机制在跑**：代理试岗率 **75%**。
- **③ 资格未闭环**：资格要件总达成度 **75%**——有 2 名后备**尚不可纳入晋升候选人池**，不可"先任命后补课"。
## 二、关键指标
| 指标 | 实绩 | 阈值判读 | 状态 |
|---|---|---|---|
| 后备覆盖率 | 0.67 | <1.0 断层 / ≥1.5 充分 | ⚠️ |
| 代理试岗率 | 75% | <50% 风险 | ✅ |
| 资格达成度 | 75% | 100% 才可晋升 | ⚠️ |
| 退出健康度（限期改善按 0.5 计） | 75% | 越低说明选拔机制越失效 | ⚠️ |
| GL 监督时间被侵占 | 1 人 | 0 人最佳 | ⚠️ |
## 三、后备人才池逐人资格审查
### 王五（目标：GL）—— ✅ 可纳入晋升候选人池（5/5）
| 资格要件 | 实际 | 达成 |
三、怎么用（含支付流程）
端点
POST https://polyester-appease-bulldog.ngrok-free.dev/pay/manager-dev
Content-Type: application/json
X-Service-Id: API_4CA75636BEF54653
支付流程（三步）
整个流程只有三步，支付由 Agent 平台（支付宝）在对话里完成，你不用自己付款、不用注册、不用填卡号：
第 ① 步 发起请求（不带支付凭证）
POST /pay/manager-dev ← 你的 AI 助手代你发
↓
第 ② 步 服务返回「账单」
HTTP 402 + 账单信息（含订单号、9.90 元、商家签名）
→ 你的 Agent 会弹出支付宝付款，确认即可
↓
第 ③ 步 带着支付凭证重发同一个请求
POST /pay/manager-dev + 头 Payment-Proof
→ HTTP 200，返回成品
关键点
- 同一份支付凭证可以重复重试，返回的是已缓存的结果，不会重复扣费
- 如果第 ② 步你没付，第 ③ 步就过不去 —— 这是正常的，不是故障
- 支付有效期写在账单的 pay_before 字段里，过期后重新发起第 ① 步即可
- 最常见的卡点：不是在终端里 curl 就完事，必须由支持支付宝 AI 按量付费的 Agent 来发，它才会弹出付款；手动 curl 只会一直拿到 402
最小可用请求
curl -X POST https://polyester-appease-bulldog.ngrok-free.dev/pay/manager-dev \
-H 'Content-Type: application/json' \
-d '{}'
- 业务参数可放 POST 的 JSON body，也可用
GET + ?payload=<urlencoded json> - 接口自述：
GET /help；健康检查：GET /healthz（返回服务版本号）
四、输入字段
| 字段 | 必填 | 说明 | 示例 |
|---|---|---|---|
positions |
必填 | 现管理岗位数（用于算后备覆盖率） | 6 |
managers |
二选一 | 现任管理者数组 | [{"id":"M01","name":"张GL","level":"GL","eval_result":82,"eval_prev":78,"supervision_ratio":0.62}] |
managers[].eval_result |
必填 | 年度综合评价（0–100） | 82 |
managers[].eval_prev |
必填 | 上年综合评价（0–100）——与本年比照判是否连续不达标 | 78 |
managers[].supervision_ratio |
建议 | 监督业务时间占比 0–1（低于 0.5 判「GL 被产线束缚」） | 0.62 |
candidates |
二选一 | 后备池数组 | [{"id":"C01","name":"王五","target_level":"GL","months_in_pool":9,"courses_done":["TWI-JI","TWI-JM","TBP/A3","安全管理","基础管理"],"kaizen_themes":3,"acting_months":4,"acting_score":81,"experience_years":7}] |
candidates[].target_level |
必填 | 目标层级（GL / TL / CL / 课长） | "GL" |
candidates[].months_in_pool |
必填 | 后备池历练月数 | 9 |
candidates[].courses_done |
必填 | 已完成必修课程数组（数量需达标） | ["TWI-JI","TWI-JM","TBP/A3","安全管理","基础管理"] |
candidates[].kaizen_themes |
必填 | 实战改善课题件数 | 3 |
candidates[].acting_months |
必填 | 代理试岗月数 | 4 |
candidates[].acting_score |
必填 | 代理期评价（0–100） | 81 |
candidates[].experience_years |
必填 | 现场实操履历年限 | 7 |
requirements |
可选 | 阈值覆盖（本次系统一不用填）：backup_months / courses_min / kaizen_themes / acting_months / acting_score / experience_years / eval_pass / supervision_min | {} |
五、算法口径（结果怎么算出来的）
> 这一节回答「实际怎么算的，我能不能核对」。下面写的是引擎里真实使用的公式与判读阈值。
① 后备覆盖率 = 后备人数 ÷ 现管理岗位数。< 1.0 判「梯队断层」；1.0–1.5「基本安全」；≥ 1.5「储备充分」。
② 代理试岗率 = 已完成/在代理期的后备 ÷ 后备总数。< 50% 判「跳过试岗直接任命，风险高」。
③ 资格达成度 = Σ(五项要件达成项) ÷ (5 × 后备人数)。每名后备需 5/5 才可晋升。
④ 退出健康度 = 1 −（0.5 × 限期改善人数 + 不胜任退出人数）÷ 现任管理者数。限期改善者仍在岗、处于 6 个月改进期内，按 0.5 权重单列。
⑤ GL 监督时间被侵占：supervision_ratio < 0.5 即预警（生产稼动维持挤占了监督业务）。
⑥ 梯队健康度总评 = 后备覆盖率 30% + 代理试岗率 20% + 资格达成度 30% + 退出健康度 20% → A ≥ 80 / B 60–79 / C < 60。
> 各阈值均为建议值，可在 requirements 中覆盖，按企业规模校准。
六、常见坑 / 不要做的事
❌ 只提 managers 不提 candidates —— 那就只能诊断现任，缺了「后备覆盖率」这一项最关键的指标。
❌ 把「完成课程」当作唯一资格 —— 五项要件里只有一项是课程，其余是历练、课题、试岗、实操履历。先训后升 ≠ 训完就升。
❌ acting_months 填 0 却想晋升 —— 未试岗即不可纳入候选人池。这是日-德-台三地一致的最强共识。
❌ supervision_ratio 一律填 1.0 —— 那等于放弃了「GL 被产线束缚」这一项诊断；填真实观测值才有用。
❌ eval_result 与 eval_prev 填成一样 —— 那就算不出「连续两年不达标」，退出预警会失灵。
七、常见错误与处理
输入不合规时，服务返回 HTTP 400 + JSON，其中 code 是错误码、message 是中文原因、hint 是怎么改、example 是可照抄的正确写法。这种情况不会收费。
| code | 触发原因 | 怎么处理 |
|---|---|---|
MISSING_INPUT |
既没 candidates 也没 managers | 两者至少提供一个数组 |
CANDIDATE_NOT_OBJECT |
某名后备不是对象 | 每条应为 JSON 对象 |
MISSING_TARGET_LEVEL |
某名后备缺 target_level | 填 GL / TL / CL / 课长 |
INVALID_ACTING_SCORE |
代理期评价不是 0–100 | 填 0–100 的数 |
INVALID_EVAL |
年度/上年评价不是 0–100 | 填 0–100 的数 |
INVALID_SUPERVISION_RATIO |
监督占比不在 0–1 | 填 0–1 的小数，如 0.62 |
INVALID_POSITIONS |
positions 不是正整数 | 填现管理岗位数 |
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：后备覆盖率 0.67 是什么意思？
A：6 个管理岗位只有 4 名后备。低于 1.0 即判「梯队断层」——任何一名管理者离任都会造成岗位真空。≥1.5 才算储备充分。
Q：五项资格要件是哪五项？
A：① 后备池历练月数 ② 必修课程 ③ 实战改善课题件数 ④ 代理试岗（月数+评价）⑤ 现场实操履历。五项全达成才可纳入晋升候选人池；任一项未达成即不可。「资格 ≠ 晋升」，最终还要看实绩与价值观行为。
Q：「GL 被产线束缚」是怎么判的？
A：看你填的 supervision_ratio（监督业务时间占比）。低于 0.5 即预警——丰田七大任务的人事领域把「GL 监督时间」直接列为活动指标，因为 GL 一旦长期顶岗，就没有人观察作业者是否安全地、按手顺作业。
Q：「不胜任退出」和「限期改善」有什么区别？
A：年度评价 < 阈值 → 限期改善（6 个月，上级重点辅导，到期复评）；连续两年 < 阈值 → 直接判不胜任退出（退回原技术岗 → 返后备池重新历练）。管理岗位不是终身制。
Q：同一 Payment-Proof 重发会重复收费吗？
A：不会。同一凭证重试返回缓存结果；改台账重新提交则是新的一次调用。
Q：怎么确认自己没被重复扣费？
A：同一 Payment-Proof 的重复请求会返回缓存结果并带 already_fulfilled=true，不产生新订单。
Q：成品是什么格式？
A：JSON 响应里的 content 字段为 Markdown 文本，可直接保存、打印或贴进 Word/WPS。
十、适用边界
- ✅ 适合：制造业（汽车零部件 / 机械 / 电子 / 家电 / 食品 / 注塑等）现场管理场景
- ❌ 不适合：非制造业、纯财务/HR 分析
- 前置条件：需提供可计算的真实数据；引擎不会凭空编数据，样本不足时结论只作方向假设
十一、定价与许可
- 单价：9.90 元/次（支付宝「AI 按量付费」，serviceId
API_4CA75636BEF54653） - 许可：Proprietary。可自用与对内交付；禁止再发布、转售或用于商业培训
- 卖家：广州行道昭元文化传播有限公司
生成内容为 AI 辅助分析初稿，所有归类与结论均为待确认假设，须以现地现物与更完整数据核实；不得直接作为考核依据。
