> 版权所有 © 2026 广州行道昭元文化传播有限公司 保留所有权利。
> 本作品受《中华人民共和国著作权法》保护。禁止摘抄、改写后以任何形式再发布、转售，或用于商业培训、咨询交付等营利场景。
活力组织诊断与建设方案（付费版）
> 基于丰田 4P 模型，融合日系全员改善（人間性尊重 / 小集団活動 / 自主研 / 守破離 / カイゼン）与德国专精型工匠体系（Meister / 双通道 / 工艺知识库 / 职工委员会），输出活力组织诊断 + 三阶段建设路线图。
计费：按次付费调用（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/vital-organization |
| -------------------------------------------> |
| <----------- 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）
- 活力四要素诊断（信任 / 希望 / 价值感 / 挑战）与综合得分评级
- 认知层次定位 + 三阶段建设路线图
- 岗位专属行动（责任到人）+ 落地追踪指标 + 避坑清单 + 评审检查清单
本次实测规模：6,010 字 / 265 行（真实生成，非示意）
二、真实输出样例
> 下面是实际跑出来的成品节选（输入为演示数据，公司名做了替换）。目的是让你下单前就看到成品长什么样。
# 活力组织诊断与建设方案
**对象**：某机械制造公司 | **行业**：汽车零部件 | **规模**：约 320 人
**生成日期**：2026-10-08 | **引擎版本**：v1.0.0
> 本方案基于丰田 4P 模型（People + Problem Solving），融合日系全员改善体系
> （人間性尊重 / 小集団活動 / 自主研 / 守破離 / カイゼン）与德国专精型工匠体系
> （Meister / 双通道 / 工艺知识库 / 职工委员会），并合中国古典匠学（轮扁斫轮）。
---
## 一、核心结论
**活力综合得分：2.50 / 5.00 —— 评级【弱】**
> 组织普遍被动应付。**不要先上工具、不要先讲文化**——先立「问题无罪、隐瞒有责」与现地现物机制，把安全感地基打好。
**首要改善方向：希望（2.0/5）**
**企业自述痛点**：一线不愿提改善
**建设目标**：建立双通道与师徒制
## 二、活力四要素诊断
> 来源：按离职原因数据倒推各要素相对重要性，再**归一为 100%**（信任 12% + 希望 21% + 价值 30% + 挑战 37% = 100%）
三、怎么用（含支付流程）
端点
POST https://polyester-appease-bulldog.ngrok-free.dev/pay/vital-organization
Content-Type: application/json
X-Service-Id: API_F40A07E17D6C45CB
支付流程（三步）
整个流程只有三步，支付由 Agent 平台（支付宝）在对话里完成，你不用自己付款、不用注册、不用填卡号：
第 ① 步 发起请求（不带支付凭证）
POST /pay/vital-organization ← 你的 AI 助手代你发
↓
第 ② 步 服务返回「账单」
HTTP 402 + 账单信息（含订单号、4.90 元、商家签名）
→ 你的 Agent 会弹出支付宝付款，确认即可
↓
第 ③ 步 带着支付凭证重发同一个请求
POST /pay/vital-organization + 头 Payment-Proof
→ HTTP 200，返回成品
关键点
- 同一份支付凭证可以重复重试，返回的是已缓存的结果，不会重复扣费
- 如果第 ② 步你没付，第 ③ 步就过不去 —— 这是正常的，不是故障
- 支付有效期写在账单的 pay_before 字段里，过期后重新发起第 ① 步即可
- 最常见的卡点：不是在终端里 curl 就完事，必须由支持支付宝 AI 按量付费的 Agent 来发，它才会弹出付款；手动 curl 只会一直拿到 402
最小可用请求
curl -X POST https://polyester-appease-bulldog.ngrok-free.dev/pay/vital-organization \
-H 'Content-Type: application/json' \
-d '{}'
- 业务参数可放 POST 的 JSON body，也可用
GET + ?payload=<urlencoded json> - 接口自述：
GET /help；健康检查：GET /healthz（返回服务版本号）
四、输入字段
| 字段 | 必填 | 说明 | 示例 |
|---|---|---|---|
company / industry / headcount |
可选 | 企业名 / 行业 / 员工人数 | 某机械制造公司 / 汽车零部件 / 320 |
trust / hope / value / challenge |
可选 | 活力四要素现存分数，0–5 分（未填按行业基准估） | {"trust":3,"hope":2,"value":3,"challenge":2} |
pain / goal |
可选 | 企业自述痛点 / 建设目标 | "一线不愿提改善" / "建立双通道与师徒制" |
五、算法口径（结果怎么算出来的）
> 这一节回答「实际怎么算的，我能不能核对」。下面写的是引擎里真实使用的公式与判读阈值。
活力四要素与权重（按离职原因数据倒推相对重要性后归一为 100%；未填的项按行业基准估，不改变权重总和）：
| 要素 | 权重 | 含义 |
|---|---:|---|
| 挑战 challenge | 37% | 是否有机会尝试新事物、体会成长 |
| 价值感 value | 30% | 员工是否觉得自己的工作有价值、被看见 |
| 希望 hope | 21% | 是否相信「做改善会有结果」 |
| 信任 trust | 12% | 是否敢暴露问题、不怕被追责 |
| 合计 | 100% | 权重口径固定：四要素之和恒为 100% |
算法：
综合得分 = Σ(要素得分 × 权重) ÷ Σ(已填要素权重) ← 未填项暂时剔除权重后再归一，避免缺项拉低总分
痛点权重 = 该要素权重 × (5 − 现状分) ← 用来排「先改哪个」
> 注意：挑战（37%）和价值感（30%）权重最高 —— 这两项弱，员工动力就起不来；信任（12%）权重最低，但它是地基，地基塌了上面全白做。
三阶段路线图由引擎按综合得分评级决定展开重点：得分越低，第一阶段越侧重「立安全感与机制」（而不是上工具、讲文化）。
六、常见坑 / 不要做的事
❌ 别先上工具、别先讲文化 —— 得分弱时第一件事是立「问题无罪、隐瞒有责」与现地现物机制。
❌ 别把改善活动全占用下班时间 —— 日系实践反复证明：员工会强烈抵触，活动沦为负担。
❌ 别给「改善」只挂经济指标 —— 没落地的好点子也要有反馈，否则没人再提。
❌ 别只有「当官」一条路 —— 技术能手没有技术晋升通道，就会放弃深耕去抢管理岗。
❌ 别追求一次性大变革 —— 组织文化转变一般要 2–4 年周期，别搞「一阵风」。
七、常见错误与处理
输入不合规时，服务返回 HTTP 400 + JSON，其中 code 是错误码、message 是中文原因、hint 是怎么改、example 是可照抄的正确写法。这种情况不会收费。
| code | 触发原因 | 怎么处理 |
|---|---|---|
SCORE_OUT_OF_RANGE |
评分越界或非数字 | 四要素按 1–5 分打分；可只填部分 |
INVALID_HEADCOUNT |
headcount 非数字 | 填人数或省略 |
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：和免费版有什么区别？
A：免费版给方法论；本付费版由后端引擎一次性生成针对你企业数据的成品方案。
Q：怎么确认自己没被重复扣费？
A：同一 Payment-Proof 的重复请求会返回缓存结果并带 already_fulfilled=true，不产生新订单。
Q：成品是什么格式？
A：JSON 响应里的 content 字段为 Markdown 文本，可直接保存、打印或贴进 Word/WPS。
十、适用边界
- ✅ 适合：制造业（汽车零部件 / 机械 / 电子 / 家电 / 食品 / 注塑等）现场管理场景
- ❌ 不适合：非制造业、纯财务/HR 分析
- 前置条件：需提供可计算的真实数据；引擎不会凭空编数据，样本不足时结论只作方向假设
十一、定价与许可
- 单价：4.90 元/次（支付宝「AI 按量付费」，serviceId
API_F40A07E17D6C45CB） - 许可：Proprietary。可自用与对内交付；禁止再发布、转售或用于商业培训
- 卖家：广州行道昭元文化传播有限公司
生成内容为 AI 辅助分析初稿，所有归类与结论均为待确认假设，须以现地现物与更完整数据核实；不得直接作为考核依据。
