金大哥 - 企业微信客户画像分析 Skill 详情

环境前提（销售首次使用）

安装 WorkBuddy 桌面端。
在 WorkBuddy 中接入英科AI中台 connector（左侧连接器入口添加并授权）。

若某销售看不到任何客户群聊数据，先确认：① 英科AI中台 connector 是否已授权；② 该销售是否确为该客户的负责人。

关键坑（务必先看）

Read 工具对超长单行会截断到约 2000 字符，且按"行"做 offset，单行紧凑 JSON 根本无法分块读取。 若把 connector 返回的聊天流直接 json.dumps 成单行紧凑 JSON，子代理用 limit 350 读取时只能看到前 1~2 条消息，产出的评分/结论完全不可信。

唯一可靠做法：转 NDJSON——第 1 行写元数据 {"customer":..,"key":..,"total":N}，其后每行一条消息 {"t":..,"sender":..,"role":"employee|customer","content":..}。这样每行 = 一条消息，子代理可 limit=300, offset 逐段通读到末尾，覆盖每一行。

connector 的 datawarehouse_query 返回的 messages 是嵌套数组 [[时间,发件人,类型,正文,动作,序号,消息ID], ...]（非对象）。解析时按 tuple 位置提取：[0]=时间、[1]=发件人、[2]=类型、[3]=正文、[4]=动作、[5]=序号、[6]=消息ID。

流程

1. 取数

在 WorkBuddy 内调用英科AI中台 connector 的 datawarehouse_query (a) 先取到销售想要做画像分析的客户群清单（轻量，不含群消息）： (b) 再逐群取全量消息，落盘为 raw/ 将完整返回 JSON用 Write 工具写入 raw/export.json。 取数过大处理：单群消息量可能达数千条（如 TOP1 群近万条），整行 messages 数组可能很大。若单次查询返回受限/超时，改用 arraySlice 分片取，每片存为独立文件（raw/roomid_p1.json、_p2.json …），转换时按 room_id 合并：

SELECT room_id, customer_name, arraySlice(messages, 1, 2000) AS messages
FROM ADS_YL.ads_mrp_wechat_msg_by_room WHERE room_id='<room_id>';
-- 第二片
SELECT room_id, customer_name, arraySlice(messages, 2001, 4000) AS messages
FROM ADS_YL.ads_mrp_wechat_msg_by_room WHERE room_id='<room_id>';

也可按 first_msg_time/last_msg_time 划时间窗配合 arraySlice 控制单批体量。

2. 转 NDJSON

用 Bash 运行一段 Python：读取 raw/export.json（connector 返回的完整 JSON，按实际 envelope 解析出每个 room 的 room_id/customer_name/messages），对 messages 嵌套数组按 tuple 位置提取，做角色判定与时间升序排序，写入 raw_ndjson/NN_客户名.ndjson（第 1 行元数据，其后续行每条消息）。

角色判定（以 ID 格式为准，勿盲信子代理"自纠"）：发件人昵称含"英科医疗"/"英科"/yingke，或工号格式 字母+5位以上数字+( → employee；纯乱码企微 ID（无昵称）→ customer。纯哈希、无昵称、非 M000xxxxx 工号格式的发送者即客户侧 ID（与真实买家同格式）；英科员工必为 M000xxxxx(姓名) 或名中含"英科医疗"。启发式标签与子代理的角色"自纠"都可能错——改判前先看 ID 格式、再读原文发言；切勿因怀疑某人是 staff 就排除其本属客户的消息。
输出每行：{"t":<[0]>,"sender":<[1]>,"role":<employee|customer>,"content":<[3]>}，按消息时间 [0] 升序。

3. 写/读分析 Brief

本 skill 内置 AGENT_BRIEF.md（自包含方法论：5 个聊天层维度定义+0-5 评分细则、7 业务阶段、近期=末 1/4 时间窗、judge JSON 结构、第 6/7 维度由 Buddy 核算的边界说明）。子代理不共享主上下文，必须读它。

4. 子代理全量分析（每个客户一个，判 1–5 维 + 阶段 + 品类 + 近期 + 小结）

读 AGENT_BRIEF.md → 用 Read limit=300 offset=2 逐段通读 raw_ndjson/NN_客户名.ndjson 到最后 → 写 judge/NN_客户名_judge.json。

后台并行跑；若遇运行时 499 canceled（资源争用，非逻辑错），直接重跑该客户即可。
子代理只判 5 个聊天层维度（price/compliance/logistics/newproduct/quality）、业务阶段、品类、近期动作/建议、画像小结；scale/stability 在产出中保留占位（score 0、reason 注明"由 Buddy 核算"），不得基于聊天臆判（见步骤 5）。
judge JSON 结构见下方 schema。

5. 核算采购规模 / 采购稳定性（Buddy 基于发货数据，写回 judge）

第 6 维 scale、第 7 维 stability 由 Buddy 用发货历史记录核算，不依赖聊天（群聊推断与真实量级系统性偏差，且销售本地仅可见自身客户发货数据）。

数据源：ODS_YL.mrp_SgHistoryRecord（内销口径 IsDeleted=0 AND IsValid=1），窗口统一近 12 个月，按合并主体组聚合。
算法与固定阈值档位以《客户画像维度体系与评分标准.md》第 6/7 章为权威。
Buddy 查数 → 按细则算法算分 → 覆盖写回对应客户 judge/*.json 的 dimensions.scale / dimensions.stability（score、reason、evidence[可选]）。
若销售环境暂未接入发货表：在 judge 中保留占位并 reason 标注"待核算（未接入发货数据）"，报告该维度显示待核算；接入后重跑本步即可。
注：发货表每日约 10:27–10:37 重灌，关键判断前先查 max(load_timestamp) 确认数据稳定。

6. 产出前自检清单

构建报告前，逐项核对每个 judge/*.json：

[ ] 每个聊天层维度 evidence、近期动作、近期建议非空（无信号维度须为"无观测信号"而非假设无视瑕疵，score=0 + 规范 reason）。
[ ] stage.reason 与 summary 未写入研判规则说明（如"取最高成熟阶段、复购不回退规则"）；只写客户事实与客观阶段依据。
[ ] summary_struct 四块（positioning/features/relationship/signal）皆非空；features 为提炼式 prose，无「维度名（N分）」逐维度罗列。
[ ] 近期建议 recent_advice / 近期动作 recent_actions 全量未截断。
[ ] 文件名严格为 *_judge.json，避免补丁/临时 JSON 被误读为客户。
[ ] display_top_advice.json 存在且覆盖全部客户的 rank（构建脚本已强制校验，缺失或漏客户会直接报错）。
[ ] summary_bold.json 存在且覆盖全部客户的 rank，每条短语须命中 summary_struct 同名块原文（构建脚本已强制校验）。

7. 生成三段式近期建议与小结加粗配置（必选）

(a) 三段式近期建议：为使报告"近期建议"以「标题 / 背景 / 建议」三段式卡片呈现，基于 judge/*.json 的 recent_advice 全量证据，为每个客户产出 2-3 条三段式，写入 display_top_advice.json（结构 {rank:[{title,background,suggestion}]}）。 (b) 小结加粗短语：为每个客户从 judge/*.json 的 summary_struct 各块原文中挑取需要重点突出的短语（每客户至少一块、每块 1-2 条），写入 summary_bold.json（结构 {rank:{"features":[..],"relationship":[..],"signal":[..],"positioning":[..]}}，rank 键支持零填充 "01" 或 "1"；定位块未配置短语时回退"是/为"后置加粗）。 本步骤两项均为必选：构建脚本会校验两文件存在、覆盖全部客户 rank，且加粗短语命中 summary_struct 同名块原文，任一不满足即报错阻断；新增/补做客户后须同步补两文件对应 rank 条目。

8. 构建报告

python scripts/build_profiles.py

生成自包含 HTML customer_profiles.html（无需联网）。保留：画像小结、主要采购品类；含：7 段业务阶段横向进度条（顶部）、近期建议（仅末 1/4 窗口真实动作、具体可落地）、左文右图（左=小结/品类/近期建议，右=7 维度雷达 SVG）。维度明细+聊天证据、阶段判定+聊天证据改为悬停触发（鼠标悬停雷达对应维度或进度条当前阶段显示，点击可固定便于截图）。左列画像小结为四块标签式：定位/核心特征/合作关系/关键信号。

关键约定（勿违反）

近期建议 recent_advice 与近期业务动作 recent_actions 一律保持全量，不得截断为 3 条或任意条数。 "该几条就几条"＝judge JSON 里原本生成了几条就展示几条。如需"只看最近 N 条"之类的展示约束，只在渲染层做，绝不回写截断后的数据到 judge 源。
构建脚本读取 judge 目录时务必用 *_judge.json 通配，避免把补丁/临时 JSON 当客户读入。
stage.reason 与 summary 不得写入研判规则说明（如"取最高成熟阶段、复购不回退规则，current=N"）。只写客户事实与客观阶段依据；必要的"注：…"事实补注可留。
画像小结采用「定位 / 核心特征 / 合作关系 / 关键信号」四块标签式：渲染层优先读 summary_struct（四键皆非空），缺失则回退 clean_summary(summary)。四块内容仅对原 summary 做归位、打标签、剥离建议，不新增任何事实；原 summary 字段保留不动作源与兜底。
画像小结「核心特征」一律提炼式，禁止维度分数枚举：7 维度雷达图就在小结旁、已呈现各维度名称与分数，故 summary_struct.features 不得出现「维度名（N分）」式逐维度罗列，应改写为凝练 prose，用实质行为/事件承载信息。维度无信号需特别说明时（如"质量认可度维度观测期内无表达信号（待核）"）可点名，但不得以罗列分数方式呈现。
画像小结重点加粗由渲染层完成（不改 judge 数据）：build_profiles.py 对每个客户按 rank 在 summary_bold.json 取该客户短语做首处加粗，再用 _GEN（通用规则：稳定复购阶段 / 零流失 / 连续X个月 / 特定规模量）兜底叠加。summary_bold.json 为必选配置——构建脚本强制校验其存在、覆盖全部客户 rank、且每条短语命中 judge summary_struct 同名块文本的精确子串（含全角引号须逐字复制），任一不满足即报错阻断；按 {rank:{"features":[..],"relationship":[..],"signal":[..],"positioning":[..]}} 格式填写（rank 键支持零填充 "01" 或 "1"；定位块未配置短语时回退"是/为"后置加粗）。
7 维统一正向规则（勿违反）：所有维度须满足"得分越高＝雷达越外凸＝客户该维度特征越正向/越突出"。价格/质量/物流三维度为翻转构念（价格接受度 / 质量认可度 / 交付配合度），评分方向已反转、新分＝5−旧分；质量维度旧分 0（无观测信号）保留为 0「待核」，严禁翻成认可。judge JSON 中这三维度的 score 与 reason 一律用正向构念表述，禁用「敏感度 / 议价力度 / 品控要求 / 物流时效」等旧名；渲染层雷达说明统一为"评分越高＝该客户在此维度特征越正向、越突出"，灰色顶点仅用于质量认可度 0 分（待核），价格/物流 0 分用浅蓝（极低）。维度命名与方向口径以 客户画像维度体系与评分标准.md 第 1/3/5 章为权威。
第 6/7 维度（规模/稳定性）由 Buddy 基于发货数据核算（见步骤 5），子代理不判；chat 层判定仅覆盖 1–5 维。

judge JSON 结构（schema）

{
  "customer":.., "key":.., "total_messages":N,
  "date_range":{"start":..,"end":..}, "recent_window":{"start":..,"end":..},
  "dimensions":{
    "price":{"score":0-5,"reason":..,"evidence":[{"date":..,"sender":..,"quote":..}]},
    "compliance":{...},"logistics":{...},"newproduct":{...},"quality":{...},
    "scale":{"score":0-5,"reason":"由 Buddy 依据发货数据核算后填回","evidence":[]},
    "stability":{"score":0-5,"reason":"由 Buddy 依据发货数据核算后填回","evidence":[]}
  },
  "stage":{"current":1-7,"reason":..,"stage_name":..,"evidence":[{"date":..,"quote":..}]},
  "category":{"main":..,"single":true/false,"note":..},
  "recent_actions":[{"date":..,"action":..,"quote":..}],
  "recent_advice":["具体可落地动作1",..],
  "summary":"画像小结（源/兜底，保留不动作）",
  "summary_struct":{"positioning":..,"features":..,"relationship":..,"signal":..}
}

7 维度（统一正向规则：得分越高＝雷达越外凸＝客户在该维度特征越正向/越突出）：价格接受度 / 合规关注度 / 交付配合度 / 新产品接纳度 / 质量认可度 / 采购规模 / 采购稳定性。其中「价格接受度」「质量认可度」「交付配合度」为原「价格敏感度」「质量敏感度」「物流时效」的翻转构念（带教要求"负向指标转正"）：评分方向已反转，新分＝5−旧分（质量维度旧 0"无信号"保留为 0"待核"、不臆造认可）；高分＝客户好成交/认可质量/易配合。合规关注度维持正向（医疗器械行业高分＝正规低风险客户）；新产品接纳度/采购规模/采购稳定性本就正向。采购规模、采购稳定性两维由发货数据核算（步骤 5），不属聊天层判定。

7 阶段：1建联触达→2需求与询价→3合规资质对接→4试样验证→5首单转化→6批量放量→7稳定复购。阶段取"已到达最成熟阶段"，允许跳跃、跨阶段并存。

目录结构与文件职责

企业微信客户画像分析/
├─ SKILL.md                          # 本文件（流程与约定）
├─ AGENT_BRIEF.md                    # 子代理方法论（自包含，含 6/7 维度边界）
├─ 客户画像维度体系与评分标准.md      # 口径权威文档（人类参考）
├─ examples/
│  └─ example_judge.json             # 一份真实客户 judge 示例（few-shot 参考）
├─ scripts/
│  └─ build_profiles.py              # judge → 自包含 HTML 报告（Buddy 调用）
├─ raw/            (运行时) connector 导出落盘
├─ raw_ndjson/     (运行时) 防截断转换产物
├─ judge/          (运行时) 子代理分析产物
├─ display_top_advice.json   (运行时·必选) 三段式近期建议
├─ summary_bold.json       (运行时·必选) 小结加粗短语配置
└─ customer_profiles.html  (运行时·产出) 最终画像报告