新帆线索池运营

新帆线索池运营技能：查看私海/公海线索列表与统计、查看线索详情， 认领/释放线索、更新跟进状态/备注/采纳优先级，并生成、定时推送私海线索日报。

新帆线索池 Agent Skill

新帆是公司内部的电商招商线索管理系统，本 skill 提供调用新帆线索池能力的 CLI。

通过本目录下的零依赖本地 CLI（bin/cli.js，仅用 Node 内置 fetch）调用新帆后台的线索管理接口。10 个接口一一对应 10 个独立子命令，每个子命令都自带 --schema（JSON Schema）和 --help（人类可读说明），字段/取值范围现查即可，不需要预读本文档。这份文档只写 CLI 自省拿不到的东西：认证怎么配、怎么发现命令、写操作的安全规则。

面向运营，不是面向工程师（重要）

本 skill 的使用者是运营人员，不是开发。对用户说话只讲业务结论，不讲实现细节：

• 不出现 CLI 命令、flag 名（如 --confirm、--dry-run）、HTTP method/path、原始请求体 JSON——这些是 agent 调用 CLI 的内部手段，运营看不懂也不需要看懂。要做什么改动，直接用大白话说清楚（"我会把这条线索的跟进状态改成'已建联'，确认吗？"），不要把请求体贴出来。
• 不出现接口/字段的英文名（如 lead_id、hasInnerShop、accept_level），一律换成运营在系统界面上看到的名字（线索名称、站内店、采纳优先级 P0/P1/P2……）。
• 不复述 agent 自己的调试/纠错过程（如"第一版判据全 0 是 bug，已修正""字段存的是字符串不是数字"）。这些是实现过程中的弯路，运营只关心最终结论对不对，不关心怎么算出来的。

首次使用：主动询问线索日报（重要）

本 skill 同时提供线索管理与私海线索日报。每次被用户实际触发时，agent 先检查当前用户是否已有名为 “新帆私海线索日报” 的定时任务：

1. 用定时任务列表检查该名称；已存在（包括暂停状态）则不询问、不重复创建。
2. 不存在时，在继续当前线索操作前只问一次：

   需要我在每个工作日 10:00，把你的私海线索日报推送给你吗？日报分三部分：你的转化数据战报（客开数、动销数、B3+/B4+线索数、增量DMGV，会跟同组均值对比）、建议优先跟进的优质线索（点名线索和推荐理由），以及即将到期需要及时跟进的线索提醒。

3. 用户同意后，使用系统的定时任务能力创建任务：
   • 名称：新帆私海线索日报
   • 时间：每周一至周五 10:00
   • 时区：Asia/Shanghai
   • 接收人：当前用户本人私聊
   • 执行内容：在本 skill 目录运行 node scripts/private-daily-report.js；若提示登录状态失效，先按「登录失效时的自愈规则」自己重试恢复，重试成功后再重新跑一次脚本，不要一遇到登录失效就直接跳过本次推送去通知用户——只有自愈重试后依然失效才允许跳过并通知用户。脚本正常输出后，按下面「日报占位符填充规则」把输出里的占位符填好、删掉参考事实区块后再发送；不要补充线索明细或”数据来源”。
4. 用户拒绝或说暂不需要时，不创建；本次会话后续不重复询问。
5. 创建前仍须获得用户明确同意。不得因为 skill 已安装就静默创建，也不得替用户选择群聊投递。
6. 若已有同名任务但时间或接收人不同，视为已配置，不自动覆盖；仅在用户要求修改时调整。

私海线索日报

运行：

bash

node <本 skill 目录>/scripts/private-daily-report.js

脚本分页读取当前登录运营本人的全部私海线索，在本地确定性计算后输出一份带占位符的日报骨架，分三部分：

• 今日战报：客开数、动销数、B3+/B4+ 线索数、增量DMGV，逐项跟同组均值对比。⚠️ 这五个指标当前全部是固定假数值（CONVERSION_MOCK 常量），包括动销数（private-stat 有真实接口）和 B3+/B4+（能从私海线索的站外店铺 GMV 分层本地算出真实数量）——这两个本来能查到真实数据，但故意先不用，因为"真实数字配虚构的同组均值"读起来会像一句可信的业务洞察、其实只有一半是真的，容易误导运营，所以在客开数/增量DMGV/全部同组均值都还没有真实来源之前，统一先用假数值，不真假混着展示。等所有指标都接上真实来源后，把 CONVERSION_MOCK 换成真实计算结果即可，不用动渲染逻辑。这一部分只有一个 <<SUMMARY>> 占位符。
• 优质线索，建议优先跟进：口径是私海线索的 extra_metric（10 个 0-100 行业百分位指标）里只要有一个 ≥80 就入选。⚠️ 这是后端刚上线的字段，底层数据表目前还没接写入管道，实际返回大概率是空的——脚本会诚实显示“暂无优质线索，建议保持现有跟进节奏”，不会为了有内容而降低口径或编数据。有命中时，每条线索一行，推荐理由 列是一个 <<REASON_n>> 占位符。
• 即将到期，请及时跟进：预计释放时间（认领后的保护期到期时间）剩余不超过 3 天的线索，按剩余时间从紧急到不紧急排列，两列表格（线索名称、剩余时间）。这部分脚本已经渲染成最终文字，不含占位符。

脚本输出的最后还有一段 <!-- AGENT-FACTS-START -->...<!-- AGENT-FACTS-END --> 区块，是只给 agent 看的参考事实，不是日报正文，发送前必须删掉（见下）。登录状态失效时，按「登录失效时的自愈规则」处理，不展示底层错误。

日报占位符填充规则（agent必读）

拿到脚本输出后，在发送之前必须做这几件事，缺一不可：

1. 找到所有 <<SUMMARY>>、<<REASON_1>>、<<REASON_2>>……占位符，参照紧跟在它们后面的 AGENT-FACTS 区块里对应的事实，把每个占位符替换成一句连贯的自然语言。
2. 除了占位符本身的文字，骨架里其余的每一个字符都不能改动——表头、表格竖线 |、行数、列数、已经算好的数字，一个都不能加、不能删、不能重新排版。
3. 写占位符文字时：
   • 不要用“｜”或逐字段罗列的方式堆砌信息，要写成一句读起来自然的话（参考风格：“淘天旗舰店年成交额810万，高端童车赛道供应链已验证；站内1.07万粉、篇均互动分96.5有内容基础”，而不是“年成交额:810万｜粉丝:1.07万”）。
   • 不要出现字段英文名（如 fans_dgmv_pct）或百分位数字本身（如“行业百分位92”）——百分位只是筛选依据，运营要看的是业务解读，不是技术分数。
   • 只能用 AGENT-FACTS 区块里给的事实，不要额外编造或引入区块之外的信息。
   • <<SUMMARY>> 写 24 句：先点 12 个最突出的对比结果，再给出鼓励（多数指标领先）或督促（多数指标落后）的语气；<<REASON_n>> 每条一句话，控制在约 60 字以内，挑 2~3 个最有代表性的事实融合表达，不需要把命中的所有事实都塞进去。日报里能进"优质线索"的都是行业百分位 ≥80 的线索（不会有 40-80 分位的），所以 <<REASON_n>> 可以放心用"行业领先/头部"这类肯定语气，不需要像列表视图的"亮点"行那样区分层级、放低语气。
4. 全部占位符替换完成后，删除整个 <!-- AGENT-FACTS-START --> 到 <!-- AGENT-FACTS-END --> 区块，只把剩下的正文发给用户——不要在正文前后加"以下是日报""日报生成完毕"之类的引导/结束语，也不要把中途运行脚本、重试、处理登录失效等过程写进去（见上「登录失效时的自愈规则」第 5 点）。发出去的消息应该从 ## 私海线索日报 开始，到「即将到期」表格结束。
5. 如果某一部分脚本本身就没有占位符（比如优质线索为空时的固定兜底句、即将到期这一整块），原样保留，不要额外补写内容。

环境准备

无需 npm install，零第三方依赖，Node >= 18 即可直接运行（会话通道用到全局 WebSocket，需 Node >= 22；DIBP/OpenClaw 环境已满足）：

bash

node <本 skill 目录>/bin/cli.js <子命令> ...

以下示例统一用 xinfan-lead-cli 代指这行命令。

运行前提：agent 环境里有一个已登录新帆的浏览器页面（见下「建立会话通道」）。首次使用前 agent 需先建立这个通道。

建立会话通道（agent 首次使用前必读）

CLI 的每次请求，都通过「当前登录用户本人已登录新帆的浏览器页面」发出，用的永远是运营本人的身份和权限。agent 按下面步骤建立一次即可，之后会话有效期内无需重复：

1. 用 browser 工具打开新帆页面： https://newark.devops.xiaohongshu.com/seller/investClue
2. 等 3~5 秒让页面跑完公司 SSO(redpass) 登录流程。多数 DIBP 环境已带用户本人登录态，会直接进；若跳到 redpass 登录页，则由用户本人扫码/登录一次（agent 不代填账号密码）。
3. 确认已登录：截图看页面右上角是否显示当前用户本人姓名，或直接跑 xinfan-lead-cli auth status 看是否「会话通道: 就绪 ✓」。
4. 就绪后即可调用任意命令。CLI 会自动发现这个已登录页面并复用它。

随时自检通道状态：xinfan-lead-cli auth status

• 就绪 → 显示「会话通道: 就绪 ✓」及已登录页面 URL。
• 未就绪 → 显示原因，并给出上面的建立步骤。遇到命令返回退出码 2（鉴权失效）时，按「登录失效时的自愈规则」处理。

登录失效时的自愈规则（交互场景与定时任务通用，重要）

CLI 返回退出码 2、或私海日报脚本提示"登录状态失效"，都不是终态，不能一遇到就直接告诉用户"去重新登录"然后放弃这次操作。无论是用户正在对话中触发，还是定时任务无人值守触发，agent 都必须先自己走一遍：

1. 用 browser 工具重新打开 https://newark.devops.xiaohongshu.com/seller/investClue，等 3~5 秒。多数 DIBP 环境此时会自动带出用户本人的登录态而无需任何人操作。
2. 跑 xinfan-lead-cli auth status 确认是否已恢复「会话通道: 就绪 ✓」；恢复后立刻重新执行刚才失败的那一步（CLI 命令或日报脚本），不要把这次失败暴露给用户。
3. 只有重试后页面依然跳到 redpass 登录页、需要用户本人扫码时（agent 不能代填账号密码），才升级给用户：交互场景下用业务语言告诉用户"登录状态失效了，需要你本人登录一下"；定时无人值守场景（如私海线索日报）下私聊告知用户需要重新登录、本次跳过推送。
4. 不展示 HTTP 状态码、报错 JSON 原文等底层细节给用户。
5. 第 1~2 步的过程不能写成叙事讲给用户：重新打开页面、查通道状态、重试、排查接口报错（比如发现域名不对）这些都只通过工具调用完成，不要用文字描述"登录态失效，先...再重试""通道恢复了，重新跑脚本""域名不对，切换到 xxx 重试"这类过程记录——不管最终是成功还是失败都不要写，这不是讲给用户听的内容。定时无人值守场景下要求更严格：agent 当次任务最终可见的文本输出，就是原样发给用户的消息本身，只能是「按「日报占位符填充规则」处理完的最终日报正文」，或者第 3 步规定的那句失败通知，前后不能有任何过程叙述、致歉语、"以下是日报"之类的引导语。

这条规则适用于本文档所有提到"登录失效""鉴权失效"的地方，包括定时任务的执行内容——组装定时任务 prompt 时必须完整带上第 1~3 步的自愈重试逻辑，不能只写"提示用户重新登录"就把这一步省略掉；第 5 步的静默要求同样要带上。

配置项（一般无需改）

• XINFAN_LEAD_CDP_URL：浏览器调试端点，默认 http://127.0.0.1:18800。
• XINFAN_LEAD_DOMAIN：新帆域名，默认已指向生产域名 hawkeye.devops.xiaohongshu.com；如需临时指向其他环境用环境变量覆盖。
• auth set-token <token>：兜底路径，非主流程。仅当未来某环境确实签发了可手动注入的 cookie、或调试需要时才用；正常情况下不需要。

怎么用

bash

xinfan-lead-cli commands                    # 1. 看有哪些子命令（path/method/mutating/verified/summary）
xinfan-lead-cli <子命令> --help             # 2. 看这个命令怎么传参、有什么业务警示（人类可读）
xinfan-lead-cli <子命令> --schema           # 2'. 同上，机器可读版（标准 JSON Schema，响应含嵌套 $defs）
xinfan-lead-cli <子命令> [--flag value ...] # 3. 调用：flag 由 schema 的 snake_case 字段名转 kebab-case

• 数组字段用可重复 flag：list-private-leads --industries 美妆 --industries 3C
• 布尔字段传了 flag 本身就是 true（如 --plain-phone），不传视为 false/默认值
• 必填字段缺失、或值不在 enum 范围内，CLI 会在本地直接报错（退出码 1），不会真的发请求
• --dry-run：只打印会发出的 method/url/body（token 脱敏），不真正发请求
• --confirm：调用 5 个"写"命令（claim-lead/release-lead/update-follow-status/update-remark/update-accept-level）必须加，否则拒绝执行

高风险操作确认规则

5 个写命令会真实修改线索状态；其中 claim-lead 认领后可以用 release-lead 释放回公海撤销，其余接口没有对应的撤销接口。执行前必须用业务语言把要做的改动讲清楚（改哪条线索、改成什么），拿到用户明确同意后才能真正执行——确认内容只说"要做什么"，不要把 CLI 参数名（--confirm）或原始请求体 JSON 呈现给用户（那是讲给 agent 自己听的实现细节，见上「面向运营」一节）。生产环境公海线索 2 万+ 条，均为真实业务数据，应保持谨慎，不因为部分操作可撤销而降低确认标准。

退出码

退出码	含义	agent 应对方式
0	成功	正常处理返回的 JSON
1	用法错误（子命令/flag 不对、必填参数缺失、枚举值不合法、写命令缺 --confirm）	修正参数后重试，不需要找用户
2	鉴权失效（会话通道未就绪或会话已过期）	按「登录失效时的自愈规则」处理：先自己重新打开页面重试恢复，只有重试后仍需人工扫码才升级给用户，不要不重试就直接把失败甩给用户
3	上游业务错误（非鉴权类的 4xx/5xx 或业务报错）	把报错翻译成业务语言告诉用户（比如"这条线索已经被别人认领了"），而不是原样贴报错文本；再判断是参数问题还是业务本身拒绝
4	网络错误（DNS/连接失败/超时）	提示用户确认域名（XINFAN_LEAD_DOMAIN）是否有效、网络是否可达

已实测过的鉴权失效响应样本：HTTP 401 {"code":-100,"success":false,"msg":"无登录信息","data":{}}。

展示规范（agent 必读）

调用 CLI 拿到 JSON 后，不要把原始 JSON 贴给用户，也不要逐字段平铺。按下面的格式组织 Markdown 输出。目标是：运营在手机 Hi 上扫一眼就能抓住重点。

通用规则

• skill 自身不额外输出“数据来源”、接口名、查询时间等尾部卡片；若宿主渠道有统一溯源要求，遵循宿主要求。
• 金额按实际字段单位换算为「万」「亿」，通常保留两位小数；不要脱离接口口径自行猜测单位。
• 粉丝数 ≥10000 时用「万」表示。
• 缺失值、空字符串或未设置统一显示「无」；真实数值 0 显示 0，不要把 0 当作缺失值。
• 线索分级显示 S0/S1/S2，S0 加粗；GMV 分层显示 B0~B6。
• 跟进状态转中文：PENDING=待建联、CONTACTED=已建联、TALKING=沟通中、INTERESTED=有明确意向、NO_INTENT=无意向、PROPOSAL_SENT=已提供营销方案、PROTECTED=已客保、SETTLED=已入驻、CRM_BLOCKED=已被CRM挂接。
• 采纳优先级转中文：300=P0、200=P1、100=P2、-100=不采纳；未设置显示「无」。
• 线索状态转中文：0=未注册、1=已注册可客保、2=已开店可客保、3=未开店已客保、4=已开店已客保、5=已挂接(CRM)。
• 平台转中文：0=小红书、1=抖音、2=京东、3=得物、4=淘天（淘宝+天猫）。
• 毫秒时间戳转为 YYYY/MM/DD HH:MM。

列表视图（list-private-leads / list-public-leads）

列表数据的核心是让运营快速对比线索质量。每条线索一个紧凑表格，不要用一个超宽大表。默认每页查询并展示不超过 10 条。

私海列表格式：

markdown

---
**S2** 奢姿大码女装 ｜ 已开店可客保 ｜ 女装

- **亮点**：站内粉丝购买力和内容互动均处于行业领先水平，且供应链稳定性已通过站外近1年GMV验证
- **跟进**：采纳 无 ｜ 跟进状态 待建联 ｜ 备注 无
- **到期**：预计释放时间 2026/08/20 21:17（还剩约 6 天）

公海列表格式相同，但不展示“跟进”“到期”两行（公海线索未被认领，没有这两个概念）：

markdown

---
**S0** source with u ｜ 已开店可客保 ｜ 女装

- **亮点**：站内粉丝规模和内容互动均处于行业领先水平

规则：

1. 每条线索用 --- 分隔。
2. 第一行展示分级、线索名称、线索状态和行业。
3. 每个信息行都用 - **标签**： 起头，行内多个字段用全角 ｜ 分隔。
4. 不要逐字段罗列站内/站外的原始指标（粉丝数、笔记数、CES、GMV、客单价……）。列表视图只保留“亮点”“跟进”“到期”——运营要看某条线索的完整指标明细时，用 get-lead-detail 查详情，那里才展示逐账号/逐店铺的完整数据表。
5. “亮点”行：读每条线索的 quality_highlight 字段（CLI 本地算出来的，不是后端字段）决定要不要写、怎么写：
   • tier === "none"（facts 为空）时不展示这一行，不编“暂无亮点”这种话——没有亮点不需要额外强调。
   • tier === "outstanding"：可以用“行业领先/头部”一类肯定表述。
   • tier === "fallback"：语气要克制，用“处于同行业中等偏上水平”一类措辞，不要用“领先/头部”这种夸大词——40-80 分位不等于突出。
   • 只能用 facts 里给的事实，挑 1~3 个融合成一句自然语言，跟私海日报的“推荐理由”一样：禁止用“｜”分隔罗列字段，禁止出现字段英文名（如 fans_dgmv_pct）或百分位数字本身。
6. 私海列表必须展示“跟进”行，字段固定为：
   • 采纳：取采纳优先级；无值显示「无」。
   • 跟进状态：取跟进状态中文值；无值显示「无」。
   • 备注：取备注原文；空字符串或无值显示「无」。
7. 私海列表若返回了预计释放时间，展示“到期”行：认领时间、预计释放时间都转 YYYY/MM/DD HH:MM；剩余天数按私海线索日报同样的口径算（Math.floor，已到期显示“已到期，可能随时被释放”，不到 1 天显示“不到1天”）。公海列表不展示这一行。
8. 公海列表不展示“跟进”“到期”两行。
9. 列表开头说明总数、页码和用户明确使用的筛选条件。

智能推荐（仅公海列表）

当用户说类似“给我推荐些线索”“帮我推荐一下”“挑几条合适的线索给我”这样的话（不是明确要看某个筛选条件下的全部列表）时，查询公海列表要额外触发智能推荐排序：

• 只有公海列表支持，私海列表没有这个能力，用户对私海提这个要求时如实说明私海暂不支持、可以看公海。
• 跟用户表达时用“为你优先挑选的几条线索”之类朴素说法即可，不要说成“AI 智能推荐/语义匹配”等夸大表述，避免设定过高预期。
• 用户如果只是说“看看公海线索”“查一下公海”没有表达推荐/挑选意图，仍按默认方式查询，不触发这个排序，保持原有列表顺序语义不变。

详情视图（get-lead-detail）

详情按「线索概览 → 跟进 → 站内账号 → 站外店铺」展示，恢复紧凑横向基本信息布局：

markdown

**线索详情：奢姿大码女装**
分级 **S2** ｜ 行业 女装 ｜ 状态 已开店可客保 ｜ 线索ID dfc41d7c...

**亮点**：站内粉丝购买力和内容互动均处于行业领先水平，且供应链稳定性已通过站外近1年GMV验证

**跟进**
采纳 无 ｜ 跟进状态 待建联 ｜ 备注 无

---

### 小红书账号：奢姿大码女装

**基本信息**
所在地 广东东莞 ｜ 用户资产分 8568 ｜ 专业号 已开通 ｜ 站内店 已开通 ｜ 广告账户 已开通

**内容能力**
| 指标 | 值 |
|---|---:|
| 粉丝数 | 2.48万 |
| 笔记数 | 0 |
| 笔记CES | 0 |
| 站内粉丝DGMV | 671.76万 |
| 交易粉丝人均DGMV | 686 |
| 近30天下单用户数 | 9792 |
| R4+粉丝占比 | 24.9% |

**粉丝画像**
性别：女性 98.3%，男性 1.7%
年龄：按接口返回的年龄层级或明确年龄段展示
R等级：R1 26.1%、R2 29.3%、R3 19.8%、R4 11.5%、R5 9.8%、R6 3.6%

**热门笔记**（有数据时展示，最多 5 条）
| 标题 | 点赞 | 收藏 | 评论 |
|---|---:|---:|---:|
| 笔记标题 | 1.2万 | 3000 | 500 |

---

### 淘天店铺：奢姿大码女装

**基本信息**
主营类目 女装/女士精品 ｜ GMV分层 B6 ｜ 店铺类型 企业店 ｜ 所在地 广东东莞
店铺主体 东莞市优盛服饰有限公司 ｜ 平台状态 未注册

**经营数据**
| 指标 | 值 |
|---|---:|
| 近一个月GMV | 850.11万 |
| 近一年GMV | 3160.38万 |
| 客单价 | ¥256.21 |

**热销商品**（最多 5 条）
| 商品 | 价格 | 月销 |
|---|---:|---:|
| 清新优雅提花收腰连衣裙 | ¥312 | 1174件 |

详情规则：

1. 顶部线索基本信息使用原来的紧凑横向布局。
2. “亮点”行：跟列表视图规则一致——读 data.lead.quality_highlight（CLI 本地算出来的，不是后端字段），tier === "none" 时不展示这一行；outstanding 可以用“行业领先/头部”一类肯定表述，fallback 语气要克制（如“处于同行业中等偏上水平”）；只用 facts 里的事实挑 1~3 个融合成一句话，禁止逐字段罗列、禁止出现字段英文名或百分位数字本身。跟列表视图不同，详情视图下面的表格照常展示完整数据，“亮点”只是加在概览区的一句快速摘要，不替代下面的表格。
3. 跟进区块固定展示采纳、跟进状态、备注；无值显示「无」。
4. 每个站内账号单独一个区块；多个账号按粉丝数从高到低编号展示。
5. 解析 gender_dist、age_dist、fan_r_level_dist、carrier_dgmv_dist 后转成中文摘要；没有明确年龄枚举映射时写“年龄层级N”，不要猜成具体年龄段。
6. 每个站外店铺单独一个区块，保留平台、店铺名、主营类目、GMV、分层、客单价、所在地、店铺类型和热销商品。
7. 商品与笔记标题过长时截断到约 15 个汉字，保留可点击链接（若接口返回 URL）。
8. 未读取明文联系方式时，不展示联系方式区块；只有用户明确要求并确认可能触发跟进状态变化后，才查询明文联系方式。

统计视图（private-stat / public-stat）

统计数据使用原来的紧凑布局：

markdown

**私海概览**
共 56 条线索 ｜ 跟进中 12 ｜ 已客保 8 ｜ 已入驻 3
转化累计 GMV 1280.50万 ｜ 公海可领 2100 条

写操作确认格式

执行写操作前，用自然语言确认，例如：

text

确认把「奢姿大码女装」的跟进状态改为「沟通中」？

不要展示请求参数、原始 JSON 或接口路径。执行后只说明业务结果。