薯量营销大盘SKILL

概述

薯量营销大盘 Skill

通过薯量开放接口查询营销大盘页面的数据。五个接口：营销大盘周期汇总（main）、趋势（trend）、SPU 列表（spu-list）、店铺目录（catalog）、指标中文字典（metrics）。

先读：数据模型与口径（不读懂这节，报数必然出错）

1. main 返回的不是单日数据，是"计算周期窗口"的滚动累计。 薯量营销大盘每天计算一次"以某日为终点、往前 N 天"的窗口统计（N = 该品牌在「归因配置」里设置的营销大盘计算周期，可选 7/15/30/60/自定义）。窗口每天向前滚动一天。周期长度不要写死、不要假设——一律以响应里的 statPeriodStartDate/statPeriodEndDate 为准，回答时必须回显"统计周期 M/D~M/D"。

2. 两个容易混淆的"天数"，是两回事：

• 营销大盘计算周期（如 7 天）＝每个窗口的长度——核心看板和趋势图每个点都是这么长窗口的统计；
• 归因窗口期（如 30 天）＝趋势图横轴一共画多长（30 天 → 约 31 个点）。

页面趋势区写着"当前趋势数据按归因窗口期（30天）展示"——说的是横轴跨度，不是每个点是 30 天窗口。禁止把这两个概念混为一谈。

3. 数据为 T+1 口径、每日滚动：当天算的是截至昨日的数据；响应元信息里的 statDate 是"数据日"，窗口终点 = statDate − 1（例如 statDate=9/9，统计的是 9/2~9/8——按该品牌周期长度而定）。缺省查询返回最新就绪窗口；dataReadyStatus 非 READY 时按"面向用户的话术"处理。

4. 数据维度（dataType）官方定义：「笔记」统计笔记层面的种草数据；「计划」统计广告计划层面的种草数据（计划维度仅统计计划下的推广消耗与广告触达转化）。广告类型指标（信息流/全站智投/视频内流/搜索/品牌广告/其他）只在计划维度有数据，笔记维度下为 null 是"该维度不适用"，不是"没有投放"。

5. 统计口径（caliber）官方定义（抄自页面，向用户解释时按此表述）：

6. 回显四要素（硬规则）：每次回答数字时必须随口说明——统计周期（M/D~M/D）＋数据维度（笔记/计划）＋口径（窄/宽）＋店铺（带 SPU 过滤时再加 SPU 名）。缺一项都是不合格回答。示例："按统计周期 9/2~9/8、笔记维度、窄口径、xx 店铺查询，种草GMV ¥123,456.78。"

接入配置

• Base URL：https://sl-lh.enbrands.com
• 鉴权：从本 skill 同目录的 config.json 读取 api_key（运行时用绝对路径，见文末调用示例），放入请求头：

Authorization: Bearer <api_key>

• key 在薯量系统「薯量skill管理」页面创建，形如 sk-xxxx。未配置或填错会返回 401。
• 超时建议 60 秒（公网网关约 60 秒可能先切断连接，超时返回 504，见错误码表）。

接口一览（全部 POST JSON）

所有接口：Content-Type: application/json。身份与数据范围完全由 API Key 决定，body 里只有查询条件参数（日期、维度、店铺、SPU 等），没有任何身份类参数。

merchantId（店铺 ID）可选：缺省时服务端自动使用当前账号下唯一的店铺（绝大多数账号只有一个店铺）；账号下有多个店铺时，接口返回 400 并携带 candidates 候选清单（结构同 catalog 响应）——把候选店铺名给用户确认，带上选定的 merchantId 重试即可。merchantId 无效时同样返回 400 + candidates，照此流程自我纠正即可，不要当成"无权限"。不要凭空猜测 merchantId，也不要为了拿 id 而先调 catalog——直接发起查询，需要选择时服务端会告诉你（catalog 的正当使用场景见该接口一节）。

参数要点（服务端严格校验，非法参数返回 400 并说明合法值）。没提的参数一律不传——服务端会按页面默认口径注入，注入值与你显式传值等价生效：

• statDate：main 恒返回最新就绪窗口，任何情况都不要传——早于昨天的历史日期会被服务端 400 拒绝（data-api 的 main 不支持历史日期查询，页面本身就没有日期选择器），今天/昨天会被服务端归一为最新就绪日。回答以响应里的 statDate/statPeriodStart~End 为准回显。查历史窗口（"8月10号""上周""上个月"）一律用 trend 单点法（见"周期与区间问题"节）。数据为 T+1 口径。
• dataType：NOTE（笔记）/ PLAN（计划），大小写均可。缺省不传时服务端按笔记维度（页面默认口径）查询，回答回显"笔记维度"。口语映射：种草/笔记/达人→NOTE；投流/计划→PLAN（用户没提就不传，不要把技术名词抛给用户选择）。"信息流/全站智投/视频内流/搜索/品牌广告"不是 dataType，它们对应广告类型指标组（feed_/smart_/video_/search_/brand_ 前缀指标），该组指标仅计划维度有数据：查它们必须传 dataType=PLAN（缺维度时服务端返回 400 并说明，补 PLAN 重试即可）。
• caliber：NARROW（窄口径）/ WIDE（宽口径），大小写均可。缺省不传时服务端按窄口径（页面默认）查询，回答回显"窄口径"。用户要求对比宽窄口径时：用 trend 分别传 WIDE、NARROW 各调一次，按返回的 dates 对齐后再对比。
• spuId：通常来自 spu-list；缺省不传＝全部 SPU（服务端按 "ALL" 处理，显式传 "ALL" 也合法）。用户直接给出 spuId 时可直接使用，跳过 spu-list。换店铺后要重新调 spu-list 获取，不要跨店铺复用——spuId 不属于当前店铺会返回 400，届时重新调 spu-list 即可。

1. POST /api/skill/open/dashboard/main

周期窗口汇总：一个请求返回该店铺一个"计算周期窗口"的全部指标（61 个业务指标 + 元信息字段）。statDate 是数据日（＝最新就绪日），窗口止于 statDate − 1（statDate 的前一天＝窗口最后一日），长度由品牌「归因配置」的计算周期决定，以响应 statPeriodStartDate/statPeriodEndDate 为准（不要写死天数），回答必须回显"统计周期 M/D~M/D"。main 恒返回最新就绪窗口（不支持历史日期，传早于昨天的 statDate 会被 400 拒绝）；历史窗口用 trend 单点法（见"周期与区间问题"节）。播报窗口值时如实回显周期，禁止换算成单日或除以天数。

响应：JSON 对象（camelCase 字段）；无数据时返回 null（不算错误，见错误码）。

• 元信息：statDate（数据日）、dataReadyStatus、lastDataTime、statPeriodStartDate/statPeriodEndDate（窗口起止，回显依据）。
• 业务指标：61 项（与 metrics 接口一一对应，字段名是指标名的驼峰形式），每项的中文含义、单位、值形态、官方定义见附录 A。
• briefing（若存在，优先引用）：服务端按页面同款句式组装好的标准答案——answerText（含统计周期起止＋维度＋口径＋核心卡数值，其中率类已是百分数形态如 9.40%，可直接引用）；coreCards（三张主卡的现成展示值）；caliber（本次生效的口径四要素）。引用 briefing 回答后仍要遵守回显规则。若响应未含 briefing（功能未启用），按原始字段＋本文件规则作答。
• 率类原始字段是 0~1 小数（clickRate=0.094 → 展示 9.40%）：引用原始字段时必须 ×100 加百分号；ROI 类是倍数（12.51）直接展示，禁止 ×100 或加百分号。briefing.answerText 里已是百分数，不要重复 ×100。
• 广告类型字段（feedXxx/smartXxx 等）在笔记维度下为 null 表示"该维度不适用"——禁止解读为"该广告类型没有投放"；查广告类型请改用 trend + dataType=PLAN。noteConsumePeriod/noteHeatConsume 仅笔记维度有值；ROI 类指标无单位，展示时不要自造单位。
• 响应可能含 dataReadyNotice 字段（dataReadyStatus≠READY 时服务端附加）：按其文案向用户说明就绪状态。

2. POST /api/skill/open/dashboard/trend

趋势数据。入参：merchantId?（同 main）、metrics[]（必填，下划线指标名数组，合法值见 metrics 接口/附录 A，传错会 400）；可选 spuId、dataType、lookbackDays（回看天数，1-365 的整数）、caliber。lookbackDays 缺省＝与页面同款的归因窗口天数（品牌配置）；响应无该元信息时，以 dates 实际跨度回显窗口范围，不要自行假设 30 天。

响应：{"dates": [...], "periodLabels": [...], "metrics": {"指标名": [数值数组]}, "trendNote?": {...}}；整段无数据时返回 null（见错误码）。

• dates 即实际覆盖区间；每个点的值＝以该日为数据日的计算周期窗口滚动值（窗口终点＝该日 − 1），不是单日值（窗口长度与品牌归因配置一致，以 periodLabels 为准——如点 09-09 对应 "09-02~09-08"）。页面趋势按"归因窗口期（N 天）"展示，指横轴跨度而非每点窗口长度。
• 硬规则：禁止跨点求和 / 求平均 / 跨点算环比（相邻窗口高度重叠，相加≈放大数倍）。❌"本月消耗＝Σ30 个点"；✅"区间/月度问题→用 main 的窗口值回答并回显周期起止"。
• 硬规则：单次取数不超过 10 个指标、lookbackDays 不超过 90；更大范围分多次取（❌ 61 指标×365 天，响应大到不可用）。
• 数组内单个 null＝该日缺数：展示时跳过并说明，禁止当 0 参与计算。
• trendNote（若存在）：服务端附带的窗口语义说明（窗口长度/禁求和/覆盖区间），与上列规则一致，向用户解释口径时可直接引用其文案。
• 用户要看"每天/走势"时用 trend；"一共/总共/累计"类问题不是 trend 求和问题，见"周期与区间问题"一节。

3. POST /api/skill/open/dashboard/spu-list

SPU 列表。入参：merchantId?（同 main）。响应：[{"spuId": "...", "spuName": "..."}]（该店铺全量 SPU）；无 SPU 时返回空数组。

SPU 较多时，不要把整份清单丢给用户——先按用户的描述（品名、品类关键词）在本地过滤出候选，再给用户确认。若 spuName 是不可读的乱码/哈希，直接向用户说明并按顺序编号让其指认。

4. POST /api/skill/open/dashboard/catalog

查询当前 key 可查询的店铺目录。无业务入参（body 传 {}）。日常查询不需要先调它；正当场景：用户问"我有几个店"、用户主动给出店铺名称需要匹配 merchantId、需要做多店铺汇总。

响应：

{
  "shops": [
    { "merchantId": "456", "merchantName": "..." }
  ]
}

5. POST /api/skill/open/dashboard/metrics

61 项业务指标的中文字典——trend 的 metrics 参数取值、main 响应字段的解读都查它（离线对照见附录 A，两者同源，运行时以接口返回为准）。无业务入参（body 传 {}）。

响应：{"metrics": [{"name","label","unit","category","valueFormat?","dimension?","formula?","desc?"}], "skillNotice?": {...}}。

• valueFormat 是硬规则：率类＝"原始值为0~1小数(如0.0235)，展示时×100加百分号(2.35%)"；ROI 类＝"倍数(如3.25)直接展示，禁止×100或加百分号"。
• dimension 标注该指标仅在某维度有值（如"仅计划(PLAN)维度有数据"）。
• formula 为唯一权威公式（与页面指标说明一致），回答"怎么算的"时照抄它，禁止按指标名自行推断公式；desc 为官方口径说明（含估算/去重等前提）。
• 每天首次查询前调一次、当天内复用（需要中文名→name 映射时同理）——这次调用同时完成"版本自检与自更新"一节的版本核对。
• skillNotice（若存在）：{"version": "...", "serverToday": "...", "notices": [...]}。notices 是服务端实时下发的口径规则，与本文件冲突时以 notices 为准；version 高于本文件头部的 version 时，按"版本自检与自更新"一节处理（提示更新，用户同意后可自动更新）。

典型用法

先分流：某时点/总量/单值问题（"最近咋样""这个月花了多少"）→ main；走势形态/按日展示（"最近每天的趋势"）→ trend。

1. 用户已说清的参数直接用；没提的一律不传（服务端注入页面默认：最新就绪日/笔记维度/窄口径/全部 SPU），不要逐项盘问，也不要自行传"昨天"。
2. 调接口：唯一店铺直接出数；多店铺或 merchantId 无效时按 candidates 流程请用户选择（见"接口一览"开头）。
3. 用户回复店名或店名片段（如"8801 那个店"）时，用 merchantName 模糊匹配 candidates：唯一命中就直接用（回答时回显店铺全名）；多个命中再列出请用户指认。会话内记住已选定的 merchantId，后续单店追问直接复用，用户说"换 xx 店"才切换（换店后旧 spuId 作废，按需重取）。例外：用户问"一共/所有店/各店"这类全账号问题时，要逐店查询再汇总或分列，不要只查已记住的店。
4. 回显四要素（硬规则）："按数据日期 8/11、统计周期 8/5~8/11、笔记维度、窄口径、xx 店铺查询"（带 SPU 过滤时再加 SPU 名）。
5. 模糊诉求的默认展开：默认用 main；"某品咋样"＝main＋spuId；"效果如何/卖得好不好"默认报核心指标组（种草GMV、种草ROI、订单获客成本、曝光量、点击量——前三项对齐页面三卡），先报这几项再问要不要看更多。
6. 展示精度（硬规则）：金额 2 位小数（可千分位），ROI 与百分比 2 位小数。
7. 数字加工一律按本文件约定执行（元规则）：率类×100 加 %、ROI 倍数禁×100、禁止跨点求和/求平均、禁止换算单日、null 不当 0、展示精度等约定不得自行变通或另作理解；约定存疑时以 metrics 接口 valueFormat/formula 字段为准，不按自己的理解发挥——随意理解是数据口径不一致的主要来源。
8. 凡对数字做算术加工必须用程序计算：差值、环比百分比、均值、单位换算等一律用程序（如 python3）算出结果再播报，禁止心算——心算易错且错了不自知（trend 两点对比环比时尤其如此）。

用户口语对照

• 消耗＝总消耗（推广消费金额＋周期内笔记合作金额＋内容加热金额），不是仅广告投放花费。
• GMV＝估算付款金额（不含购物金、未剔除退款、含邮费；预售付尾款当天计入）——报数时主动声明"估算口径"。"赚了多少钱/收入"：大盘只有 GMV（成交流水）口径，没有利润。
• "获客成本/CPA"有两个指标：cpa_per_order（订单获客成本，默认，页面头条卡同款）与 cpa_per_user（人均获客成本）——默认报订单口径并回显，用户说"人均"才切换。
• 指标计算公式一律以 metrics 接口 formula 字段（＝附录 A）为准；附录 A 未给公式的指标，回答"口径以薯量系统指标说明为准"，禁止推断后笃定播报。
• ROI 解读前提（用户问"ROI 好不好/为什么掉了"时先说清）：种草转化存在长尾回流（归因窗口期内陆续兑现，单期低 ROI 不代表终局）；转化指标为估算值；窄口径仅统计当期触达当期成交、宽口径含长尾回流，两套数字差异大，先确认口径再评价。

周期与区间问题（"上周/本月/上月/这个月一共"怎么答）

大盘没有"自然周/自然月累计"口径——所有数据都是 N 天滚动窗口。处理规则：

• "这个月花了多少/一共"：❌ 禁止把 trend 的点加总（窗口重叠，相加放大数倍）。✅ 用 main 当前窗口值回答＋回显周期，并说明："大盘按您设置的计算周期滚动统计（当前窗口 9/2~9/8），没有自然月累计口径（页面同样不提供）；当前窗口总消耗 ¥X。精确自然月合计可用薯量页面『趋势分析-导出』。"
• "上周怎么样"：trend 单点法（main 不支持历史日期，传 statDate 会被 400 拒绝）——调 trend（lookbackDays 取 14~21 保证覆盖到上周），在响应 periodLabels 里找恰为上周自然周（周一~周日）的那个点，取该单点的值回答（每个点＝该窗口的完整值，与 main 同源同口径，禁止跨点加总）。品牌计算周期恰为 7 天时该点窗口＝上周自然周，直接答；找不到恰好的标签（周期设了 15/30/60/自定义）时如实说明："您的计算周期是 N 天，大盘没有自然周口径；我能给出的是以 X 日（上周日）为终点的 N 天窗口值"，取终点最接近上周日的那个点并回显实际周期。
• "和上月比/环比"：trend 两点法——一次 trend（lookbackDays 覆盖两个窗口，单次指标 ≤10），在 periodLabels 里定位两个等长窗口的点（最新窗口点 与 终点＝上月同日的窗口点），分别回显两个窗口起止后再对比；禁止不等长对比（自然月 31/30 天 vs 滚动窗口），禁止跨点求和或求平均。差值/百分比用程序算，禁止心算。
• "本周/上周"指自然周（周一起始）；拿不准今天星期几时以 skillNotice.serverToday（或系统时间，北京时间）为准换算成具体日期。
• 周期配置问答：
  • "我的计算周期是多久？"→ 查一次 main，由 statPeriodStartDate/statPeriodEndDate 推导回答（如 9/2~9/8 即 7 天），不要写死 7 天。
  • "在哪改/能不能改？"→ 引导：薯量系统「营销大盘 → 归因配置」。该菜单含四项配置：营销大盘计算周期（7/15/30/60/自定义）、归因窗口期、归因模型（末次/首次触点等）、归因口径（点击/曝光等）；一个自然月仅可修改一次。
  • 子账号看不到「归因配置」菜单 → 提示联系主账号负责人查看/操作。
  • 禁止臆测"修改周期后历史数据会不会重算"——未定义，引导用户咨询薯量支持。

面向用户的话术

• 只陈述数据，不做平台归因：数据只反映该店铺本计算周期的投放表现，不足以支撑渠道/平台层面的结论——❌ 对平台效果做任何定性评价（无论好坏）。
• 数据不理想时的措辞：数字必须照实播报（委婉管的是"怎么说"，不是"报多少"），表述保持中性、委婉、有建设性：先给事实与口径，再给可行动的下一步（如"可以拆分 SPU／换维度看结构变化""对比更早的已就绪窗口"）；❌ "效果很差""表现糟糕""投放失败"等负面定性措辞。
• 不做预算决策建议：用户问"要不要停投／减预算／加投放"时，只呈现相关数据与结构事实，预算决策留给用户或其投放团队（或咨询薯量支持）；❌ "建议停投""建议减少预算"。
• 返回 200 但为 null："这个条件下没有查询到投放数据——可能当天没有投放，或数据还没同步。可以换个日期、去掉 SPU 过滤、或换个店铺再试。"（先自查：是否带了 SPU/日期过滤；笔记维度下广告类型字段为 null 属维度不适用——均排除后才可能是无投放或未就绪）
• 连续多日 null 时：用 trend 拉大 lookbackDays（如 30）看 dates 是否整体为空，区分"当天没投"和"账号整体无数据"；历史很久的日期查不到可能是超出数据保留范围。
• 用户问"今天"："大盘是 T+1 口径，每天计算的是截至昨日的滚动窗口数据——最新窗口就是当前最完整的视图。"（缺省查询拿到的就是它，直接报数＋回显周期）
• dataReadyStatus 三态：CALCULATING→"这一天的数据仍在计算中，数字可能偏小，建议明天再看，或先看更早的已就绪窗口"；FAILED→"该日期数据计算失败，不会自动恢复，建议查询更早日期或联系薯量技术支持"（禁止对 FAILED 说"明天再看"）。响应含 dataReadyNotice 时按其文案说。
• 500/502：对用户说"服务暂时异常，请稍后重试"，不要原文转述服务端错误信息；但若 message 明确提示"请联系薯量技术支持"，请如实转告用户并停止重试（这类是服务端部署问题，重试无效）。

能力边界（用户问到时这样引导）

• 导出：正式 Excel 导出请到薯量系统（趋势分析-导出，导出后浏览器会直接下载文件）；你可以先把数据整理成表格（或 CSV 文件，如果你有文件能力）交付给用户。
• 定时推送 / 预警：本 skill 不支持持续盯盘和定时发送，引导用户到薯量系统使用对应功能；你可以先把当前数据列给用户。
• 归因（"为什么 ROI 掉了"）：可以先拉 conversion_roi 及分广告类型 ROI 的 trend（dataType=PLAN），指出"主要掉在哪类投放"这个方向；更细的笔记/计划级归因请用户到薯量系统查看。
• 排行（"哪个品效果好/最赚钱"）：拒绝全量逐 SPU 查询（调用次数多、耗时长、易超限）；用户坚持时抽查不超过 10 个 SPU 并声明是抽查。排序指标默认："最赚钱/效果好"→种草GMV（total_pay_amt）；"投产比"→种草ROI（conversion_roi），先向用户回显排序口径。

错误码

带 candidates 的 400 不是失败，是"需要用户选定一个店铺"——询问用户后带参重试。401/403 不要重试（先让用户检查 key 与权限）；400 按 message 修正参数后重试；500/502/504 可稍后重试一次（message 提示联系技术支持的除外，转告用户即可）。

调用示例

# 用绝对路径读 config.json——skill 执行时工作目录不是 skill 目录；
# 下面是 Claude Code 的安装路径，Codex 用户请把 ~/.claude 换成 ~/.codex
API_KEY=$(python3 -c "import json,os;print(json.load(open(os.path.expanduser('~/.claude/skills/shuliang/config.json')))['api_key'])")

# 查大盘主数据：不需要任何 id，什么都不传就是页面默认口径
curl -s -X POST "https://sl-lh.enbrands.com/api/skill/open/dashboard/main" 
  -H "Authorization: Bearer $API_KEY" -H "Content-Type: application/json" 
  -d '{}' --max-time 60

版本自检与自更新

薯量会持续修正口径规则，修正版通过接口下发。每天第一次查询前先完成一次版本核对（就是上面 metrics 的"每天首查"，当天内不必重复）：

• skillNotice.version 与本文件头部的 version 相同，或响应无 skillNotice → 正常继续。
• skillNotice.version 更高 → 有更新，走下面的流程。

更新流程：

1. 告诉用户："薯量 skill 有口径修正更新（当前 vX.X.X → 最新 vX.X.X），建议现在更新，大约一分钟。"
2. 用户同意后请求：GET https://sl-lh.enbrands.com/api/skill/open/package/latest（Header 带 Authorization: Bearer <api_key>），响应 {"version": "...", "sha256": "...", "downloadUrl": "..."}；下载 downloadUrl 指向的包文件，校验 sha256 与响应一致。
3. 解包后把包内文件原位替换到本 skill 目录（SKILL.md 等全部文件）——绝对禁止改动、覆盖或删除 config.json（api_key 在里面，弄丢用户就要重新配置）。
4. 完成后告诉用户"更新完成，重新开启一个会话即可生效"；本次会话按现有规则继续作答（若 notices 已随本次响应下发，直接按 notices 执行）。

失败兜底：下载失败 / sha256 对不上 / 没有写权限时，不要反复重试，引导用户到薯量系统「薯量skill管理」页面手动下载重装。

用户主动问"有没有新版本 / 怎么更新"→ 同样先调 metrics 核对版本，再按上述流程处理。

附录 A：61 项指标官方字典

与 metrics 接口同源；官方定义抄自薯量营销大盘页面指标说明（含页面"问号"提示原文）。维度列：两维度＝笔记/计划都有；仅计划＝必须 dataType=PLAN；仅笔记＝仅 NOTE 有值。形态列：率(0~1)＝原始值 0~1 小数，展示 ×100 加 %；倍数＝直接展示禁 ×100。

A1 转化业绩（3 项）

A2 本品与关联转化（6 项）

本品：订单商品中关联了笔记绑定的小红书SPU的是本品，未关联的是非本品。关联转化：用户被内容触达后产生的跨品类购买。小红书SPU-商品关联关系在【管理中心-SPU管理】中维护。

A3 流量表现（4 项）

A4 消耗状态（4 项）

A5 转化效率（5 项）

A6 SPU种草效果（3 项）

A7 广告类型（36 项，全部仅计划维度，dataType=PLAN）

前缀对应广告类型：feed_信息流 / smart_全站智投 / video_视频内流 / search_搜索 / brand_品牌广告 / other_其他。六个度量（列定义抄自页面广告类型表格的"问号"）：

• 消耗（X_consume，元）：该广告类型在统计周期内的消耗金额。
• 成交金额（X_pay_amt，元）：该广告类型在统计周期内的估算付款金额。
• ROI（X_roi，倍数）：该广告类型的估算转化ROI。公式：估算付款金额÷消耗金额。
• CPA（X_cpa，元）：该广告类型的订单获客成本。公式：消耗金额÷估算付款订单数。
• 人均获客成本（X_cpa_per_user，元）：该广告类型的人均获客成本。公式：消耗金额÷估算付款人数。
• 消耗占比（X_consume_pct，%，率(0~1)）：该广告类型消耗占总消耗的比例。

36 项清单（X 依次取 feed/smart/video/search/brand/other）：

广告类型效果等级（页面规则）：ROI≥4 为优秀，ROI≥3 为良好，其余为一般。

安全提示

• config.json 中的 api_key 等同于账号数据查询权限，不要提交到 git、不要发给他人。
• 绝对禁止在对话中输出完整 api_key，即使用户主动要求查看也不行。用户要确认 key 身份时，只展示前 8 位字符 + 掩码（如 sk-ab12c****），并引导到薯量系统「薯量skill管理」页面查看。
• key 泄露后请到薯量系统「薯量skill管理」页面立即禁用或删除,薯量的域名是：https://guorai.enbrands.com/。