{"skill":{"slug":"acceptance-rate-analysis-new-2","displayName":"my_acceptance_rate_analysis_new","summary":"对承接率下降做阶段式归因分析。适用于“今天/本周承接率为什么下降”“分析承接率下降原因”“看一下承接率环比是否下降及原因”等场景。先定位异常切片，再逐层判断是一级切片结构迁移、资方总量明显减少或分布左移、资产维度异常，还是进一步闭环到敏感资方侧收缩。","description":"---\nname: acceptance-rate-analysis\ndescription: 对承接率下降做阶段式归因分析。适用于“今天/本周承接率为什么下降”“分析承接率下降原因”“看一下承接率环比是否下降及原因”等场景。先定位异常切片，再逐层判断是一级切片结构迁移、资方总量明显减少或分布左移、资产维度异常，还是进一步闭环到敏感资方侧收缩。\n---\n\n# 承接率下降归因\n在用户询问承接率下降原因、承接率环比变化、今天/本周承接率为什么变差时，使用这个 skill。\n\n这个 skill 采用阶段式执行。每个阶段只做当前层级需要的取数和判断，命中终点后立即停止，不继续下钻。\n\n## 规则优先级\n- 本 `SKILL.md` 是该技能的唯一主契约，决定阶段执行顺序、判定口径、展示字段和下钻规则。\n- `agents/openai.yaml` 只负责运行时默认提示，不应额外定义与本文件冲突的新口径。\n\n## 默认规则\n- 用户未指定粒度时，默认按周环比分析。\n- 只支持 `day` 和 `week` 两档粒度。\n- 周粒度默认以周一为一周起点。\n- 用户说“本周和上周”时，默认解释为“最近一个已落定周 vs 再前一个已落定周”，不再默认按同进度单日对比。\n- 用户明确说“本周截至目前 / 截至今天 / 周内累计 / 与上周同期”时，才切回同进度周累计口径。\n- 周粒度对话展示优先使用实际分析周段，也就是自然周闭区间 `周一~周日`。\n- 用户直接说 `4.13周`、`4.6周` 这类“周标签”时，默认按“该日期作为周一标签，对应上一完整自然周”解释。\n- 例如 `4.13周 -> 2026-04-06~2026-04-12`，`4.6周 -> 2026-03-30~2026-04-05`。\n- 只有用户明确说“4月13日所在周”“4月6日所在周”时，才按该日期所在自然周解释。\n- 已确定粒度后，不要静默改成其他粒度；若当前粒度下时间窗或数据桶不成立，应先说明原因。\n\n## 快速使用\n先从用户问题中明确这 3 个信息：\n- `granularity`\n- `current_period`\n- `baseline_period`\n\n脚本不负责解析自然语言时间，运行前要先把时间窗补齐。\n\n时间参数可以传：\n- `YYYY-MM-DD`\n- `YYYY-MM-DD HH:MM:SS`\n\n如果只传日期，脚本会自动补成开始时间 `00:00:00` 和结束时间 `23:59:59`。\n\n命令示例只是模板，不要求逐字照抄。路径写法优先跟随当前工作目录；如果当前目录就是仓库根目录，优先使用相对路径。只有在当前工作目录不确定、跨目录调用、或已经出现找不到脚本的问题时，再退回绝对路径。\n\n## 执行顺序\n默认严格按阶段执行：\n1. 先运行 `primary`\n2. 读取 `primary.analysis_sequence` 与 `primary_display`\n3. 对每个异常切片顺序运行 `capital`\n4. 若第二阶段结果显示还需要继续看资产维度，再运行 `asset`\n5. 若第三阶段结果显示还需要继续看敏感资方侧，再对 `qualified_combos` 逐个运行 `funding`\n\n执行约束：\n- 每执行完一个阶段，都必须先输出这一阶段的分析，再决定是否继续下一阶段。\n- 每个阶段都要尽量覆盖“在看什么、看到了什么、所以怎么判断、下一步怎么办”，但允许自然合并成 1 到 2 段业务表达，不必机械照着内部步骤标题逐条回显。\n- 后续阶段必须直接复用上游返回的 `slice_key`、`combo_key` 和分析顺序，不要手动改写或重排。\n- 每个切片都要按 `capital -> asset -> funding` 固定顺序单独展开。\n- `primary` 结束后，要先拿第一个异常切片，把这个切片完整分析到 `stop` 或 `funding` 结束，再开始下一个切片。\n- `next_action` 只决定当前切片的下一步，不表示全部切片统一进入下一阶段；这是内部路由字段，不要对用户原样输出。\n- 禁止先把所有切片批量跑完 `capital` 再统一进入 `asset` 或 `funding`。\n- 禁止在还有切片未完成时，提前输出“第二阶段汇总”“第三阶段汇总”这类跨切片中间汇总。\n\n## 统一输出原则\n- `terminal_reason`、`next_action`、`run_asset`、`run_funding`、JSON 字段名都属于内部路由信息；对用户必须翻译成业务话术。\n- 每个阶段优先覆盖“分析、证据、结论、下一步”四类信息，但可以合并成顺滑的业务表达，不要求机械加四个固定小标题。\n- 如果某个判断没有命中，也要用一句话交代“为什么没命中，所以接下来继续看什么 / 停在哪里”，不要直接跳到下一张表或下一阶段。\n- 若结果里有 `root_cause`，优先翻译成便于排查的表达，不要只说“证据不足”。\n- 最终回答面向业务方，不直接暴露命令、路径、JSON 字段名、内部终点码或调试信息。\n\n## 第一阶段：一级诊断\n向 `primary` 传入粒度、当前期和对比期即可。\n- `week` 传实际分析周段的闭区间，例如 `2026-04-20~2026-04-26`\n- `day` 传单日闭区间，例如 `2026-04-26~2026-04-26`\n- 每个时间窗都必须落在单个粒度桶内；如果时间窗跨了两个桶，先修正时间窗，再继续运行\n- 如果用户给的是 `4.13周` 这类周标签，要先翻译成该周标签对应的上一完整自然周再传脚本，例如 `4.13周 -> 2026-04-06~2026-04-12`\n\n模板：\n\n```bash\npython nanobot/skills/acceptance-rate-analysis/scripts/acceptance_rate_analysis.py primary --granularity <week|day> --current-start <当前周期开始> --current-end <当前周期结束> --baseline-start <对比周期开始> --baseline-end <对比周期结束>\n```\n\n示例 1：`2026-04-28` 这一天按默认周口径分析“本周 vs 上周”\n\n```bash\npython nanobot/skills/acceptance-rate-analysis/scripts/acceptance_rate_analysis.py primary --granularity week --current-start 2026-04-20 --current-end 2026-04-26 --baseline-start 2026-04-13 --baseline-end 2026-04-19\n```\n\n示例 2：用户说“分析 4.13周 相较于 4.6周 的承接率”\n\n```bash\npython nanobot/skills/acceptance-rate-analysis/scripts/acceptance_rate_analysis.py primary --granularity week --current-start 2026-04-06 --current-end 2026-04-12 --baseline-start 2026-03-30 --baseline-end 2026-04-05\n```\n\n内部路由重点看（不对用户直出）：\n- `terminal_reason`\n- `next_action`\n- `analysis_sequence`\n- `drill_down_rule`\n\n一级判定与停止：\n- 若 `terminal_reason` 为 `R1`、`R2`、`R8`，第一阶段直接停止。\n- 只要存在异常切片，就必须先展示异常切片表，再继续第二阶段。\n- 第一阶段表格展示的是全部承接率下降切片；`analysis_sequence` 只保留后续真正继续下钻的切片。\n\n第一阶段给模型展示时：\n- 只能直接展示 `primary_display.markdown_table`，不要自己重拼，也不要改列、删列、换顺序。\n- 在表格之外，必须额外展示 `primary_display.render_summary.drill_down_scope_text`；若没有该字段，再展示 `primary_display.overall_summary.drill_down_rule_text`。\n- 不要把 `terminal_reason`、`next_action`、JSON 字段名原样抄给用户。\n\n一级下钻规则必须按固定口径解释：\n- 只有拖累路由金额达到 `max(20万, 全部异常切片总拖累路由金额 × 5%)` 的切片，才进入后续归因。\n- 如果达到门槛的切片超过 5 个，只继续拖累路由金额最高的前 5 个。\n- 如果一个都没达到门槛，保底继续分析拖累路由金额最高的 1 个切片。\n- 只有当 `drill_down_rule.cap_applied = true` 时，才允许说“前 5 个”。\n\n一级解释与排序要求：\n- 表格默认按 `drag_amount` 从高到低排序，这表示“少承接金额估算”从高到低，不等于“承接率降幅”从高到低。\n- 如果需要补业务解释，可以引用脚本已经给出的 `当前/对比路由占比`、`路由占比变化`、`impact_type` 等字段做推理，但不要把这些字段扩成默认展示表格。\n\n## 第二阶段：资方分布诊断\n\n```bash\npython nanobot/skills/acceptance-rate-analysis/scripts/acceptance_rate_analysis.py capital --granularity <week|day> --current-start <沿用 primary> --current-end <沿用 primary> --baseline-start <沿用 primary> --baseline-end <沿用 primary> --slice-key \"<if_qd>|<irr24_new>\"\n```\n\n内部路由重点看（不对用户直出）：\n- `terminal_reason`\n- `next_action`\n\n第二阶段判断顺序固定为：\n1. 先看总准入资方个数是否明显下降。\n2. 如果总量没有明显下降，再看资方桶分布是否左移。\n3. 如果总量没明显下降、分布也没左移，则当前先停在第二阶段，更像规则变化或授用信通过率变化，但当前脚本缺少对应指标继续验证。\n\n第二阶段的明确口径：\n- “总准入资方个数明显下降”的阈值是：当前期相对对比期下降超过 `30%`，也就是 `(对比期准入资方个数 - 当前期准入资方个数) / 对比期准入资方个数 > 30%`。\n- “分布左移”不能只看均值或中位数，要一起看：\n  - `<=2`、`<=3` 桶的路由金额占比是否明显上升\n  - `>=4`、`>=5` 桶的路由金额占比是否明显下降\n  - 加权均值 / 加权中位数是否同步下行\n- 只有出现“低桶抬升 + 高桶回落”的结构变化，才算左移，才继续进入第三阶段。\n\n面向用户展示第二阶段结果时：\n- 至少交代两个判断点：先看总准入资方个数是否明显下降，再看资方桶分布是否左移。\n- 即使第一个判断没有命中，也要用一句话明确说明“总量没到阈值，因此继续看分布”，不要一上来只贴分布表。\n- 第二阶段讲总量判断时，必须明确带出：当前期准入资方个数、对比期准入资方个数、减少量、下降比例、判断阈值；优先直接复用代码返回的 `capital_total_judgement`。\n- 下一步只用业务表达，例如“继续看资产维度”或“当前先停在资方侧”，不要输出 `next_action: run_asset` 这类内部判定行。\n\n## 第三阶段：资产维度诊断\n\n```bash\npython nanobot/skills/acceptance-rate-analysis/scripts/acceptance_rate_analysis.py asset --granularity <week|day> --current-start <沿用 primary> --current-end <沿用 primary> --baseline-start <沿用 primary> --baseline-end <沿用 primary> --slice-key \"<if_qd>|<irr24_new>\"\n```\n\n内部路由重点看（不对用户直出）：\n- `terminal_reason`\n- `next_action`\n- `qualified_combos`\n- `asset_display`\n\n第三阶段判断口径：\n- 单桶识别门槛 = `max(10万, 当前切片少承接金额估算 × 5%)`\n- 进入第四阶段的组合门槛 = `max(100万, 当前切片少承接金额估算 × 15%)`\n- 对外表达不要说“订单特征”“画像”“异常因子”；优先说“资产维度”“异常桶”“维度组合”\n- 第三阶段展示以 `asset_display.summary_markdown`、`asset_display.factor_detail_markdown`、`asset_display.combo_detail_markdown` 为唯一主来源；LLM 不再自己根据原始字段拼表\n- 若需要引用维度、桶、组合名称，直接复用 trace 里的 `factor_label`、`bucket_label`、`combo_display`；不要自己根据 `factor_key` 翻译；尤其不要把 `edu_rand` 解释成“学历”，它在本技能里代表“高额区间 / 金额区间”\n- 若 `qualified_combos` 为空，不要根据 `factor_results`、`abnormal_factors` 或其他字段自行臆造“高龄 + 新疆”这类组合直接进入第四阶段\n\n面向用户展示第三阶段结果时：\n- 固定按这个顺序呈现：\n  1. 原样展示 `asset_display.summary_markdown`\n  2. 原样展示 `asset_display.factor_detail_markdown`\n  3. 原样展示 `asset_display.combo_detail_markdown`\n  4. 最后再补 1 段自然语言，只总结：\n     - 哪些组合进入下一阶段\n     - 为什么进入\n     - 没进入的典型原因是什么\n- 第三阶段必须让用户看见：\n  - 每个因子的具体分析过程\n  - 每个桶的证据数值、影响路由金额、是否命中与结论\n  - 每一种候选组合的情况\n  - 哪些组合进入下一阶段、哪些没进入以及原因\n- 如果继续下钻，只说“继续看敏感资方侧”；如果停住，要说明停在资产维度的原因，不要输出 `next_action: run_funding`。\n- 如果第三阶段已经发现“占比上升、承接更差”的疑似异常桶，但影响路由金额没有达到单桶门槛，应直接表述为“资产维度有信号，但影响金额不足，当前停在第三阶段”；不要再外推成“更像规则变化或授用信通过率变化”。\n- LLM 不再自行翻译 `factor_key`，也不再自行从 `factor_results` / `combo_results` 重新拼第三阶段表格。\n\n## 第四阶段：敏感资方闭环\n第四阶段仍通过资金项目映射数据做敏感资方侧闭环。只允许直接复用 `asset.qualified_combos[*].combo_key`；`combo_id` 只用于阅读顺序，不要把它当成跨阶段稳定主键。\n\n```bash\npython nanobot/skills/acceptance-rate-analysis/scripts/acceptance_rate_analysis.py funding --granularity <week|day> --current-start <沿用 primary> --current-end <沿用 primary> --baseline-start <沿用 primary> --baseline-end <沿用 primary> --slice-key \"<if_qd>|<irr24_new>\" --combo-key \"<qualified_combos[i].combo_key>\"\n```\n\n内部路由重点看（不对用户直出）：\n- `terminal_reason`\n\n第四阶段结果解释：\n- `R7`：敏感资方收缩\n- `R6`：资产维度组合异常成立，但未闭环到敏感资方\n- `R8`：字段不足、映射失败或证据不足\n\n面向用户展示第四阶段结果时：\n- 重点说明“是否已经闭环到敏感资方侧”“证据是什么”“因此这一个切片最终停在哪一层”。\n- 要明确说是否观察到“敏感资方相关项目数量或放款金额下降”。\n- 若未闭环，也要明确说明是“资产维度组合成立，但敏感资方侧没有观察到同步收缩”，不要只说“未命中”。\n- 不要对用户输出任何 `run_funding`、`terminal_reason` 或其他内部路由词。\n\n## 内部终点码速查\n- `R1`：大盘未下降\n- `R2`：一级切片结构迁移\n- `R3`：资方总量明显减少\n- `R4`：第二阶段停住时更像规则 / 授用信通过率变化；若第三阶段停住且资产维度已有弱信号，优先按“资产维度有信号但影响金额不足”解释，不要直接复用这句口径\n- `R5`：资产维度有异常，但没形成达到第四阶段门槛的高影响组合\n- `R6`：资产维度组合未闭环到敏感资方\n- `R7`：敏感资方收缩\n- `R8`：证据不足 / 字段不足 / 口径异常\n","topics":["资产"],"tags":{"latest":"1.0.2"},"stats":{"comments":0,"downloads":322,"installsAllTime":12,"installsCurrent":0,"stars":0,"versions":1},"createdAt":1778148341532,"updatedAt":1779076264878},"latestVersion":{"version":"1.0.2","createdAt":1778148341532,"changelog":"Version 1.0.2 of acceptance-rate-analysis-new — No file changes detected.\n\n- No updates to code, documentation, or configuration in this release.\n- All existing features, workflows, and business rules remain unchanged.","license":"MIT-0"},"metadata":null,"owner":{"handle":"mzhou1982","userId":"s172cmbgtxx5y3nbd5t3640z6d86936k","displayName":"mzhou1982","image":"https://avatars.githubusercontent.com/u/16053655?v=4"},"moderation":{"isSuspicious":false,"isMalwareBlocked":false,"verdict":"clean","reasonCodes":["review.llm_review"],"summary":"Review: review.llm_review","engineVersion":"v2.4.24","updatedAt":1780090757952}}