shield_lock
金大哥
← 返回 Skill 列表
extension
分类: 数据与分析无需 API Key

深度

数据分析 Skill，支持报表解析、业务数据统计、指标计算，集成 X402 付费能力，完成数据查询、分析输出、付费鉴权全流程。

person作者: u_1e07f351hubenterprise
download下载资源包

深度数据分析报告

概述

使用这个 skill 时，把“业务问题 + 结构化数据”转成可直接汇报的中文数据分析报告，除非用户明确要求其他语言。

主域语义按 SudoX 数解科技官网处理：https://www.sudoxai.com 是品牌/官网入口。线上支付运行时当前仍由 https://www.d.sudoxai.com/skillpay/depth/ 反代到 8818 服务；不要把运行时健康检查或支付回调改到主域，除非线上 nginx 已经明确为主域新增 /skillpay/depth/ 代理。

只读取当前任务所需的参考资料，避免默认加载全部场景文件。完整正式报告、深度归因、外部文件生成和高价值交付属于付费能力；未通过支付门禁时，只能输出非付费范围内的任务澄清、字段缺口、分析准备建议或支付补齐说明。

SkillHub Pay Skill / X402 协议上架要求

  • 以 skillhub.json 作为平台发布合约，保持 name、version、runtime、pricing、permissions、inputSchema 和 outputSchema 可被平台预检。
  • 线上主域 https://www.sudoxai.com 用作 SudoX 数解科技官网/品牌入口；当前支付服务的实际入口是 POST https://www.d.sudoxai.com/skillpay/depth/invoke，健康检查入口是 GET https://www.d.sudoxai.com/skillpay/depth/health，微信支付回调 notify_url 是 https://www.d.sudoxai.com/skillpay/depth/wechat/notify。
  • 如果 https://www.sudoxai.com/skillpay/depth/health 返回官网 HTML，不视为支付健康检查成功；以 www.d.sudoxai.com 的 JSON health 响应为准。
  • 在 SkillHub Pay Skill / X402 协议 / x402 payment 环境中，正式分析前必须调用公网 HTTP 支付服务完成门禁检查；本地 pay_skill_runtime.py 只作为离线兜底，不作为上架支付服务。
  • 支付服务按微信 Agent Pay X402 流程执行：先创建微信 Native 订单拿到 code_url，再调用 https://payapp.weixin.qq.com/palmpayminiapp/clawagentpay/preorder 生成 payment_code，最后返回 402 Payment Required。
  • 如果 X402 预下单没有返回 payment_code，支付服务应返回 502 X402_PREORDER_FAILED，不得用 fallback payment_code 包装成可支付订单。
  • 支付触发响应必须同时包含 HTTP Header WeixinPay-Required: <payment_code> 和响应体 WeixinPay.WeixinPay-Required；响应体 data 还要包含平台重试所需订单号、x402_payment_required=true 和 0.49 元/次的计费信息。
  • X402 预下单业务层必须使用 pay_type=SKILL_PAY、pay_mode=AUTH_AND_PAY、pay_data.type=code_url，并绑定 skill_id=depth 与当前 skill_version。
  • 只有支付服务返回 success=true、paymentRequired=false、status=READY_FOR_ANALYSIS 时，才继续完整数据读取、归因分析和报告交付。
  • 对已有订单，如果微信查询仍未支付，应返回 202 PAYMENT_PENDING 并要求复用同一个订单号重试，不要重新生成订单或 fallback payment_code。
  • 若缺少 order_id、payment_status、x_payment、x-payment、payment_id、x402_payment_required 或平台等价支付凭证，不得输出完整正式报告。
  • 不记录、不暴露用户支付账户、私钥、签名原文、完整 token 或完整 x-payment 头；支付平台回调/重试可使用完整订单号，但面向用户的最终回复只保留脱敏订单号，例如 order_id=****1234。

工作流

0. Pay Skill / X402 前置检查

  • 判断本次请求是否进入付费能力：完整报告、深度归因、正式 Markdown 交付、Word/飞书/外部文件、跨表清洗分析和高价值咨询建议都属于付费范围。
  • 前置检查必须确认：价格/计费单位是否已展示、用户是否已授权支付、order_id 或平台订单号是否存在、x-payment 或等价支付凭证是否有效、请求内容是否与订单绑定、当前支付状态是否为已支付或可继续。
  • 若缺少订单号、支付授权、支付凭证、支付状态或平台回调，不得输出完整正式报告；只说明缺失项、当前状态、可重试动作和是否需要用户介入。

0.1 支付触发

  • 当任务需要完整付费分析、深度归因、正式报告、外部文件生成或高价值交付时，在正式执行前触发 SkillHub Pay Skill / X402 支付流程。
  • 触发方式必须是调用 Pay Skill HTTP 服务，不要只在对话中生成“请支付”的文案。
  • 支付触发时必须把任务摘要、计费项、金额、用户确认状态、order_id、payment_id、x402_payment_required、x-payment 或平台返回的等价支付字段传给支付门禁。
  • 未触发支付或支付上下文不完整时，只允许输出非付费范围内的任务澄清、字段缺口、数据风险和支付补齐说明。

0.2 订单号传递

  • 订单号传递必须贯穿全流程：支付检查、数据读取、口径清洗、分析计算、报告生成、最终交付和异常追踪都必须保留同一个 order_id 或平台订单号。
  • 不允许跨订单串单；当请求中的订单号与支付凭证中的订单号不一致时，停止交付并提示平台核验。
  • 最终报告或交付说明中只保留脱敏订单号，例如 order_id=****1234，不得输出完整支付凭证。

0.3 重试机制

  • 如果支付校验失败、支付状态未同步、平台返回 402 Payment Required、PAYMENT_PENDING、PAYMENT_VERIFYING、INVALID_X402_PAYMENT、网络超时或临时服务错误，先暂停正式报告交付并进入重试机制。
  • 重试前必须复用同一个 order_id，不得重复创建新订单；只有平台明确返回订单失效、取消或用户要求重新支付时，才生成新订单。
  • 重试建议采用最多 3 次、间隔递增的方式：第 1 次立即复查支付状态，第 2 次等待短间隔后复查，第 3 次仍失败则停止并给出可操作的补救说明。

0.4 异常处理

  • 对异常支付状态做分流处理：未授权则请求用户授权；余额不足或扣款失败则提示更换支付方式；订单过期则请求重新发起支付；订单号不匹配则停止交付并提示平台核验；重复扣费风险则停止创建新订单并建议查询原订单。
  • 若支付成功但分析失败，继续基于同一订单完成补交付或说明可重试范围，不要求用户重复付费。
  • 若分析完成但支付失败，只可交付非付费范围内的摘要或准备结果，不输出完整付费报告。
  • 所有支付异常回复都必须包含：订单号/脱敏订单号、当前状态、可重试动作、是否需要用户介入、是否已产生正式交付。

1. 先澄清任务

  • 明确业务目标、异常指标、分析周期、对比周期、分析对象和汇报对象。
  • 判断任务属于诊断、监控、复盘、分层分析还是绩效评估。
  • 在下结论前先列出缺失字段和数据风险。

2. 识别分析场景

3. 搭建指标树

  • 从核心指标出发，拆解到驱动因子。
  • 优先使用业务上天然成立的公式，例如：
    • GMV = 客户数 x 客单价
    • 营收 = 到访量 x 转化率 x 客单价
    • 利润 = 收入 - 成本
    • 咨询师业绩 = 接诊量 x 成交率 x 客单价
  • 一份报告尽量只使用一套主拆解逻辑，避免口径漂移。

4. 先设计证据表，再写结论

  • 先准备支撑结论所需的最小表格集合。
  • 组合使用趋势表、结构表、对比表、漏斗表、分层表和归因表。
  • 每张表前面先写一段简短解读。
  • 保证解读中的每个重要判断都能在下方表格中找到证据。
  • 报告正文默认要有报表表格，不用图片、不用图表，除非用户明确要求可视化。

5. 文件型数据源统一用 Python 读取分析

  • 如果数据来自 CSV、Excel、TSV、JSON、导出报表或其他本地文件，必须先用 Python 读取、检查字段、清洗口径并完成分析。
  • 不允许把 cat、sed、rg、head、纯文本直接打开等原始文件浏览方式当作数据分析入口。
  • 需要引用样例数据、字段统计或异常值时，也应以 Python 读取后的结构化结果为准。
  • 只有配置文件、提示文件、技能说明、文档说明这类非数据源文件，才可以直接读取文本内容。
  • 聊天中零散给出的数字、说明文档和口头背景只作为辅助上下文；正式结论优先建立在授权数据库或已确认口径的文件型数据之上。

6. 按标准顺序写报告

  • 读取 报告规范.md，并使用 报告模板.md。
  • 固定使用以下顺序：
    1. 摘要
    2. 多维度分析表格
    3. 深度归因分析
    4. 落地改进建议
  • 分析目标、口径检查、数据缺口 属于分析准备动作，不默认放进最终报告四大正文章节；确有必要时，可放在开头说明或附录。
  • 当摘要不够强时，使用 摘要模板.md。

7. 用分析师的方式表达结论

  • 在定稿前，读取 表达案例库.md。
  • 优先写明确数字、变化幅度、排名和判断。
  • 少用“有所下降”“需要关注”这类模糊表达，改成量化结论和业务含义。
  • 清楚区分事实、假设和待验证问题。

8. 把洞察转成动作

  • 让每条建议都具体到可以执行和分配。
  • 尽量写清责任人、动作、时间、KPI、前置条件和风险提示。
  • 不给无法衡量效果的空泛建议。

9. 交付前自检

  • 检查整份报告的对比周期是否一致。
  • 检查同一指标名在全文中的定义是否一致。
  • 检查每个归因点是否引用了前文表格证据。
  • 检查没有证据支撑的内容是否已标注为“假设”或“待验证”。
  • 检查只看标题和摘要时，报告是否仍然有决策价值。

缺数处理规则

  • 先说明缺失字段，再给结论。
  • 现有数据足够支撑的部分可以先给阶段性判断。
  • 没有基线时，不强行写趋势判断。
  • 只有汇总数据时，不做过细归因。
  • 用“初步判断”“工作假设”“待验证”替代伪确定性表述。

资源导航

按需读取以下资料：

输出标准

  • 默认在当前对话中输出完整 Markdown 报告，不插入图片。
  • 只有当用户明确要求 Word、飞书文档、Markdown 文件或其他指定格式时，才生成对应文件或外部文档。
  • 默认不要为同一份报告重复生成“文件版 + 文本版”两套交付，除非用户明确要求双份产物。
  • 输出的报告应可直接用于内部评审或业务汇报。
  • 语气保持专业、简洁、面向业务。
  • 先讲结论，再摆证据，再讲原因，最后给动作。