@yixinkj/priority-buyer-alert-cli 0.1.45 → 0.1.47

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yixinkj/priority-buyer-alert-cli",
-  "version": "0.1.45",
+  "version": "0.1.47",
   "description": "重点买家未回复预警独立启动器，只读扫描询盘并提醒，不发送任何消息。",
   "type": "module",
   "bin": {

package/skill/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: 哨兵预警-0812
 description: 重点买家未回复预警。只读扫描阿里国际站询盘列表，挑出重点买家（金品店铺为 L2 及以上真实档；出口通店铺只有 L1+ 一个值，它是 L1–L4 的合集，必然包含 L1），判断买家最后一句是否超过 SLA 仍没有真人业务员回复，并输出中文预警清单；机器人自动接待不算人工回复。Use when 用户要求检查重点买家有没有超时未回复、查询盘超时提醒、看 L3/L4 有没有快凉的，或要求运行重点买家预警。
-version: "0.1.45"
+version: "0.1.47"
 ---
 
 # 重点买家预警
@@ -133,20 +133,33 @@ npx -y @yixinkj/priority-buyer-alert-cli@beta \
 那时它已经不是「第一次回复」的场景了，交给首响 Skill 时它会看到 `alreadyDrafted` 为真。
 
 因此清单里没有某条询盘，可能是「今天没有新询盘」，也可能是「都推过了」。摘要里的
-`first_response_suppressed` 分开记着这两种情况，不要只看清单条数就下结论。
+`first_response_listed`（本轮清单条数）和 `first_response_suppressed`（已推过、本轮不再进清单）
+分开记着这两种情况，不要只看清单条数就下结论。
 
 「只推一次」是靠 `--mark` 推进水位实现的：**不带 `--mark` 就只是预演**，不写水位，可以反复拉取
 看结果，但也意味着去重不起作用。所以心跳一定要带，人工查看一定不要带。
 
-### 会话阶段：开场白该不该写，看这个
+### 会话热度：两个原始数字，不分桶
 
-每条记录带 `thread_stage`，回答的是「这段对话到了哪个阶段」：
+每条记录带 `thread_message_count`（整条会话的消息条数）和 `last_gap_ms`（买家最后一句距上一条的间隔）。
 
-- `opening` 还在开场——消息不多，**或者久未联系后重新来问**（间隔超过 30 天）。两种都适合写开场白。
-- `ongoing` 已经聊起来了，该写的是跟进。
-- `unknown` 没取到详情，判不出来。
+**这两个数不用来决定写不写开场白，只用来定语气。**写不写由清单本身决定：进了清单就是今天的、
+而且没推过。
 
-**这才是转给开场白 Skill 的判据，不要用 `first_response_pending`。** 后者只说明「我方有没有发过真人消息」：全是 AI 自动接待、来回二十条的会话它是 `yes`，那显然不该写开场白；买家几个月前问过、今天又来问的它是 `no`，那恰恰该写——中间隔了这么久，上一轮说过什么都不作数了。
+- `last_gap_ms` 很大 = 久未联系后又回来问。中间可能换了采购周期甚至换了对接人，
+  上一轮说过什么都不作数，按重新开场写。
+- `thread_message_count` 很大 = 已经有些来回了。照写，但别用「感谢您的询盘」开头。
+  注意这个数**包含系统消息、卡片和自动接待**，今天刚进来的询盘也常常有七八条，
+  它不等于「双方真的聊了这么多句」。
+- 两个都是 `null` = 没取到详情。照写，按第一次回复的语气。
+
+这里原来是一个分好桶的 `thread_stage`（`opening` / `ongoing`），阈值是 6 条。真机验收
+把它证伪了：今天的 2 条、放宽到 7 天的 42 条，**全部**被判成 `ongoing`。阈值从没被真实
+数据校准过，拿它当判据等于把开场白关掉，而且失败时毫无声响——看起来只像「今天没有合适样本」。
+现在把原始数字交出去，由模型判。
+
+`first_response_pending` 同样不作判据。它只说明「我方有没有发过真人消息」：全是 AI 自动接待、
+来回二十条的会话它是 `yes`；买家几个月前问过、今天又来问的它是 `no`。
 
 每条记录的 `first_response_pending` 是三态：
 
@@ -161,6 +174,20 @@ npx -y @yixinkj/priority-buyer-alert-cli@beta \
 看到 `yes` 可以转去新询盘首响 Skill 起草第一次回复；`no` 暂不处理。本 Skill 只输出只读元
 数据，不调用其他 Skill。
 
+#### 摘要里哪个数才是清单条数
+
+- `summary.first_response_listed`：**本轮实际写进 `artifacts.first_response` 的条数**，
+  也就是清单本身有多长。要判断「本轮到底推没推东西」，只看这个数。
+- `summary.first_response_pending_count`：上面 `yes` 那一档的条数，**不是清单条数**。
+
+两者统计的不是同一组对象。进清单的条件只有「今天新建」和「本轮没推过」，跟我方回没回过无关：
+`first_response_pending` 为 `no` 的会话照样进清单、照样要推给开场白；反过来被水位压住、本轮
+没进清单的候选仍然计进 pending。真机上出现过 `first_response_pending_count: 0` 而清单文件里
+实实在在有 2 条——**把 pending 当清单条数看，就会把「推了 2 条」误读成「本轮什么都没推」**。
+
+中文清单（`artifacts.digest`）把这两件事分成了两行：「本轮清单：N 条」是清单条数，
+「判定分布」那行才是 `yes` / `no` / `unknown` 的分布，且包含未进清单的候选。
+
 ### 买家最后一句是卡片时
 
 消息摘要会归一成固定标签：`[图片]` `[视频]` `[文件]` `[表情]` `[产品卡片]` `[订单卡片]`

package/skills.json

@@ -1,5 +1,5 @@
 {
-  "runtimeVersion": "0.1.35",
+  "runtimeVersion": "0.1.37",
   "platforms": {
     "darwin-arm64": {
       "id": "mac-arm64",
@@ -24,7 +24,7 @@
   "skill": {
     "name": "哨兵预警-0812",
     "id": "priority-buyer-alert",
-    "version": "0.1.45",
+    "version": "0.1.47",
     "bin": "priority-buyer-alert-cli"
   }
 }