shield_lock
JinDaGe
← Back to skills
extension
Category: Content & MediaAPI key requirement unconfirmed

增长驱动因子因果诊断专家

贴上转化与投放的观测数据，先做数据画像与算法路由，再产出分层的因果结构图与驱动因子路径报告。

personAuthor: erzat1986hubOpenAPI
downloadDownload package

zvex 增长驱动因子因果诊断专家

投放、内容、促销、客服都在动，转化也在动——用户带着观测业务数据（CSV、截图、直接粘贴都行）来问：变量集里谁真正指向目标指标？哪条路径是间接传导？哪些只是同涨同落？先在对话里圈定变量、画像数据、确定方法路由，再交完成后整因果结构报告；结论先行、边型分层、每个数字可溯源。

文档分层：本文件是使用层（能力、示例节选、边界与 FAQ）；调用报文、参数表与报错对照在 references/api.md。

能力

| 能力 | 说明 | 产出方式 | |---|---|---| | 变量圈定 | 目标指标唯一明确（一张图回答一个问题）；派生比率（转化率、ROI）用原始分子分母替代，数学恒等式不进图；漏斗中间量（加购、下单）降为背景或剔除；与因果影响评估、渠道效果建模两条技能路线的分工说明 | 对话内完成 | | 数据画像 | 样本量与检验效力（七八个变量至少数百行）；近常数、严重截断、双重编码逐条退回；缺失模式甄别——零星缺失走缺失版检验逐检验剔除保最大效力，整列缺失或缺失带规律退回；线性与高斯形态判断；环境漂移诊断（大促混合、水位跳变） | 对话内完成 | | 方法路由 | 确定性规则：线性近似高斯→约束型发现（稳定模式+费希尔 z）或评分型搜索（GES+贝叶斯信息准则）；噪声非高斯→函数因果模型族（方向可识别）；离散→卡方/吉方检验；缺失→缺失版检验；隐藏混杂嫌疑→PAG 路线；环境漂移→拼时间指示列；大样本非线性→核检验并预告三次方耗时；先验注入原则（只收「逻辑上不可能」的强常识，逐条记录理由） | 对话内完成 | | 完整因果结构报告 | 带业务变量名的分层因果结构图（确定定向边、等价类内可能方向边、隐藏混杂双向边三种边型配图例）；驱动因子到目标指标的直接与间接路径清单（按证据强度排序）；方法与 v-结构定向规则声明；先验约束全量披露；局限性声明（观测数据无干预、相关性不等于因果） | 引擎产出（见调用） | | 预算重排方向与验证设计 | 按路径强度给资源重排方向；拟重仓关键边的最小成本验证设计（试点范围、观察周期、翻盘条件）；有基准真值场景先在基准上验证方法再上业务数据 | 引擎产出（见调用） |

使用示例与输出样例（合成数据，演示交付形态）

下例全部数字为合成示例，只为展示交付形态与口径；真实交付中每个数字必须来自用户自己的数据或引擎产出。

场景：虚拟订阅制电商，周度数据 104 周、7 个变量——周转化订单量（目标）、内容投放花费、搜索投放花费、自然流量、客服响应时长、促销标记、单均实收；零星缺失约 3%；目标出完整因果结构报告与预算重排方向。

  • 圈定 + 体检 + 路由（对话内）：目标锁定周转化订单量；「转化率」列已用原始两列替代；104 周对 7 变量效力充足；缺失 3% 零星走缺失版检验；近线性近似钟形 → 约束型发现（稳定模式），显著性阈值 0.01
  • 先验（对话内）：注入两条禁止边——「转化订单量→投放花费」「单均实收→投放花费」（花费是预算动作，不由当日结果反向决定）；报告先验段全量披露
  • 引擎调用：scenario="zvex-causal-discovery"，situation 放上述结论的浓缩（报文见 references/api.md）

输出样例（节选，合成数字）：

  • 分层因果图：确定定向——内容投放→自然流量、促销→转化订单量、自然流量→转化订单量；等价类内可能方向——客服响应时长与转化订单量；双向边——无
  • 路径清单（示例读法）：「内容投放有两条路：直接到订单的路径弱，经自然流量再到订单的间接路径强——内容投放的杠杆在拉动自然流量，砍内容预算伤的是流量盘而不只是当期单量。」
  • 局限性声明（示例）：「客服响应时长与订单的先后分不出；品牌心智、竞品动作未记录在数据里，若有未观测共同原因，个别方向可能翻转。」
  • 验证设计（示例）：「对『内容投放→自然流量』这条拟重仓的关键边，先做 4 周小规模加投试点：内容预算上调约 15%，其余渠道冻结，周度盯自然流量——若 4 周内自然流量抬升不足 5%，该路径不成立，预算维持原状。」

能力边界与限制

  • 结构发现不是因果铁证：观测数据无干预实验，输出是等价类分层下的假设图；线性高斯数据分不出等价类内的方向；双向边是隐藏混杂信号不是定向结论；不承诺任何提升结果
  • 只吃记录齐全的观测数据：需要目标指标与候选驱动的原始记录；样本量撑不起检验、整列缺失、变量近常数退回并给补数路径；随机实验数据（A/B 分组）不需要本技能——直接比较组间差异即可
  • 隐藏混杂只能检测不能消除：未记录的共同原因（品牌心智、竞品、季节）只能靠双向边提示与先验约束兜底；「保证没有混杂」做不到，如实说明
  • 引擎返回通用分析骨架：因果结构专属板块（分层因果图、路径清单、等价类解读、验证设计）由宿主转译层按场景交付形态组装，实际数字必须来自用户数据与引擎产出，两边都没有的数字不写（见 references/api.md §4）
  • 不做：操作投放后台、代跑数据导出、实时拉数（只审用户提供的表格）——干预实验怎么做由业务方拍板
  • 隐私红线：经营数据先脱敏概括再进调用参数；个人信息禁止写进任何参数

常见问题与反模式（FAQ）

高频问答：

  • 为什么我拿到的是通用营销分析包，不是 因果结构深度报告？ 八成是漏传 scenario="zvex-causal-discovery"（与技能身份绑定，漏传拿到通用包）；若报「场景未就绪(scenario pack 缺失)」是服务端部署态问题——禁止改传 general，如实告知稍后同参数重试（详见 references/api.md 错误表）。
  • 同一个问题重复问，会重复下单吗？ 不会——判重按问题身份（situation+goal+mode+scenario）：同键重复查询复用已存结果；补 known_facts/goal_detail 不出新订单；任一键改变 = 新问题 = 新订单，所以提交后禁止换参数重试。不确定订单状态传 action=check_order 查单。
  • 「好了」之后多久拿到完整报告？ 支付核销有短暂延迟：等 1 分钟左右回「好了」，系统自动查单交付，无需任何凭证；不要把延迟当失败反复刷单，也不要引导用户找/粘贴支付凭证。
  • goal 传什么值？ 以 consult_info 探针实时返回的列表为准（含其固定中文别名）；传列表外的值（自由中文、自造目标名）报参数错误——先调探针取当前枚举，修正后重调即可。
  • situation 该放什么、不放什么？ 放路由段结论浓缩（变量圈定、体检结论、路由依据、先验清单、方向性发现，≤2000 字符）；不放原始导出整段粘贴，不放未脱敏经营数据与个人信息。
  • 转化率、ROI 能直接放进图里吗？ 不能——它们是别的变量相除得出的派生量，放进去算法找出的是数学恒等式；用原始分子分母（订单、访客、花费）替代。
  • 样本多少行才够？ 与变量个数相关：七八个变量至少要数百行才谈得上效力；不足时先扩窗或精简变量集，只给方向性观察并说明补数路径。
  • 图上 A 和 B 之间是双向箭头，怎么回事？ 双向边是隐藏混杂信号：数据里没记录的共同原因同时推动了两者；如实转述，不要硬定向——这是方法在如实报告局限。
  • 两次跑结果不一样？ 检查是否用了稳定模式与固定随机种子——同数据同参数重跑结论应一致；仍不一致说明参数变了，判重按新问题处理。
  • 和 A/B 实验复盘什么区别？ A/B 复答回答「这一次动作带来多少增量」，走对照或反事实路线；本技能回答「观测数据里谁驱动谁」的结构问题；重大预算动作前两条路线互补——先用结构发现圈出关键边，再用小实验验证。

反模式（命中即返工）：

  • 漏传 scenario；goal 拍脑袋传探针列表外的值；situation 整段粘贴原始导出
  • 出订单后换参数重试；把核销延迟当失败反复刷单；引导用户找/粘贴支付凭证
  • 派生比率直接进图；整列缺失静默删行；等价类内方向讲成确定结论；双向边硬定向
  • 报告贴邻接矩阵不转译；套模板——换一份不同主题、不同变量集的数据结论不变

护栏

  • 边型分层是底线：确定定向、可能方向、双向边三种边型分开呈现，等价类内的方向不下确定结论，双向边译成隐藏混杂提示
  • 路由依据必须交代：选了哪个方法族、为什么——算法与数据假设错配是整体作废级错误
  • 先验全量披露：注入了哪些禁止/必选边、各自的业务理由；先验是收敛工具不是结论来源
  • 数据不达标如实退回，不硬凑结论；每个数字可溯源到用户数据，缺数据先明说

调用

完整因果结构报告与预算重排方向走 zvex 类目引擎·营销增长 MCP（Streamable HTTP 三步会话流：initialize 拿 mcp-session-id → notifications/initialized → tools/call）：

  1. 首次调用（payment_proof 留空）：

    {"jsonrpc":"2.0","id":2,"method":"tools/call","params":{
  "name":"analyze_consult",
  "arguments":{"scenario":"zvex-causal-discovery","situation":"<路由段结论浓缩：变量圈定+体检结论+路由依据+先验清单+方向性发现>","goal":"<以 consult_info 探针返回的当前列表为准>","mode":"standard","known_facts":"<诊断段确认的口径、样本量、先验约束>","goal_detail":"","payment_proof":""}}}

    必须传 scenario="zvex-causal-discovery"（技能身份绑定，漏传拿到的是通用营销分析包）；goal 以 consult_info 探针返回的当前列表为准（接受列表中的取值及其固定中文别名，列表外的值报参数错误）。

  2. 返回账单：结果内 code=Payment-Needed，含 out_trade_no、amount、pay_url（收银台直链）与结果概要。把 pay_url 原样发给用户，点开可选支付宝（手机自动拉起）或微信扫码支付；完成后引导用户等 1 分钟左右回一句「好了」。

  3. 支付后交付：用户回复「好了」后系统自动查单交完成后整结果，无需任何凭证；确需改参数先征得用户同意再重新发起。积分用户如已持有 zvex_api_key 凭证，调用时传 zvex_api_key 直接扣积分（积分直扣，以实际扣减为准），免逐单支付。

完整会话流、参数表、宿主转译目标、幂等语义与错误处置对照见 references/api.md。

输出纪律

  • 成品交付：结果中的框架/样例若含 {占位}，由你（对话助手）结合用户的真实信息补全为可直接使用的成品；上下文没有的事实最多追问 1 次；禁止编造数据与事实；
  • 不虚构：结果未覆盖的信息如实说明「需补充什么」，不假装已知；引用外部信息注明来源。

交付与计费纪律

  • 交付状态机：首次调用返回账单（HTTP 200，结果内 code=Payment-Needed，内含 pay_url 收银台直链，支付宝/微信均可付——不要按 HTTP 错误码分支处理）→ 用户完成后回复「好了」→ 系统自动查单交完成后整结果，无需任何凭证，不会重复扣费；
  • 判重语义：同一问题重复查询不重复扣费——判重按问题身份（相同情境+目标+模式）；补充已知信息或修改目标说明不会产生新账单，交付始终使用最新提供的信息；
  • 查单：不确定订单状态时，用相同参数调用并传 action=check_order（不产生账单）即可查询，不要靠更换参数试探；
  • 换参数=新问题=新账单：出账单后不要更换参数重试。

证据呈现纪律

  • 证据是论据不是附录：每条证据 = 一句结论挂钩诊断 + 标题 + 来源域名，热度转述为「高赞/讨论量级」；
  • 来源只用中性表述（中文社区讨论/公开网页），不得提及证据服务商名称；不罗列裸链接；
  • 证据不可用时如实说明，不编造行业案例。