标题批量体检与撞车检测

一批标题要发出去之前，最怕的不是「哪条不够好」，而是它们自己跟自己撞车。单条看每条都挺像样，放一起才发现写的是同一个意思——投放出去等于用两条内容抢同一波读者。

这个技能做两件事：排序，以及找出撞车的那几对。

与另外三个技能的区别

> 什么时候用这个而不是二选一：候选超过两个，或者你一次要给几个号/几条内容排标题。两个标题纠结用 title-duel 更直接。

第一次使用（照这个问）

• 「帮我排一下这几个标题，再告诉我有没有互相撞车的：①副业真的能赚钱吗 ②副业真的能赚钱吗？ ③35岁被裁员后，我把副业做成了主业」
• 「我准备了 10 个标题要分 3 个号发，帮我看看哪几个太像了」

预期产出：按分数排序的清单、撞车配对（含相似度）、整批相对爆款基准的共同短板、以及一句话结论。

打分口径（不是黑箱）

命中一个特征，就加上该特征在爆款样本中的占比作为分值。

比如「含身份代入」在 390 条公众号爆款里占 35.4%，命中它就加 0.354 分；「含结果导向」只占 2.3%，命中就加 0.023。再按长度偏离同类均值扣分（每偏离 8 字扣 0.1，上限 0.3）。

分数完全由真实样本统计推导，能被解释、能被质疑，没有主观加权。 而且这个打分与 title-duel 用的是同一份内核——同一个标题在两个技能里拿到的分必须一样（有回归用例锁死这一点）。

撞车判定：相似度 ≥ 0.45

两个标题的中文字面相似度（2-gram Dice 系数）达到 0.45 就判为撞车并列出，按相似度从高到低排。

阈值比 title-duel 的 0.6（「几乎同一个标题」）故意更低：批量场景要更早预警。一批里出现两条 0.45 的，读者实际感受就是「这两个号发的是同一条」。

• ≥ 0.6 → 「几乎同一个标题」
• 完全相同 → 「完全相同的标题」
• 0.45–0.6 → 「高度雷同」

> 这条是实测踩出来的：『副业真的能赚钱吗』vs『副业真的能赚钱吗？』相似度 0.933 —— 只差一个问号，人工肉眼极容易放过，但它就是撞车。

绝不生成标题。 一掺入 AI 现编的标题，这份东西就不再是基于真实样本的判断，而变成一堆无法验证的漂亮话。

关于「0 分」，先说清楚

爆款样本自己给自己打分的分布是这样的（390 条）：

其中 34% 的爆款在这套特征体系下自己就是 0 分——因为它们靠的是特征之外的写法（人物故事、极端细节、纯情绪），本打分不覆盖那部分。

所以：0 分不代表这标题一文不值，只代表它没命中这七项可统计的字面特征。给分位数就是为了让你能给自己定位，而不是被一个孤零零的分数吓到或骗到。

输出内容（真实样例）

下面是三个标题的真实返回（ranking 与 coverage 为控制篇幅只贴了前几条，实际会返回全部）：

{
  "input": {
    "count": 3,
    "topic": null,
    "titles": [
      "副业真的能赚钱吗",
      "副业真的能赚钱吗？",
      "35岁被裁员后，我把副业做成了主业"
    ]
  },
  "benchmark_source": {
    "pool": "wx",
    "label": "公众号实测爆款（10 万+ 阅读）",
    "sample_size": 390,
    "note": null,
    "benchmark_avg_score": 0.203,
    "score_distribution": {
      "pool_size": 390,
      "avg": 0.203,
      "p25": 0,
      "p50": 0.166,
      "p75": 0.321,
      "p90": 0.544,
      "max": 0.866,
      "zero_rate": 0.344,
      "note": "基准池 390 条爆款按同一规则自评的分布，中位数 0.166。其中 34% 的爆款在这套特征体系下得 0 分——说明它们靠的是特征之外的写法（人物故事、极端细节、纯情绪），本打分不覆盖那部分。"
    },
    "how_scored": "命中一个特征就加上该特征在爆款样本中的占比作为分值；再按长度偏离均值扣分（上限 0.3）。benchmark_avg_score 是把爆款样本自己按同一套规则打分的均值，只能当参照，不是及格线。"
  },
  "batch": {
    "count": 3,
    "avg_score": 0.211,
    "max_score": 0.57,
    "min_score": 0,
    "avg_length": 11.3,
    "length_min": 8,
    "length_max": 17,
    "collision_pairs": 1,
    "benchmark_avg_score": 0.203
  },
  "ranking": [
    {
      "rank": 1,
      "index": 2,
      "title": "35岁被裁员后，我把副业做成了主业",
      "score": 0.57,
      "length": 17,
      "length_penalty": 0.081,
      "features": {
        "number": true,
        "identity": true,
        "conflict": false,
        "emotion": false,
        "suspense": false,
        "result": false,
        "superlative": false
      }
    }
  ],
  "collisions": [
    {
      "a_index": 0,
      "b_index": 1,
      "a_title": "副业真的能赚钱吗",
      "b_title": "副业真的能赚钱吗？",
      "similarity": 0.933,
      "kind": "几乎同一个标题"
    }
  ],
  "coverage": [
    {
      "key": "number",
      "feature": "含具体数字",
      "in_batch": 1,
      "batch_rate": 0.333,
      "benchmark_rate": 0.297,
      "gap": 0.036
    },
    {
      "key": "identity",
      "feature": "含身份代入（我/你/35岁/中年/独居…）",
      "in_batch": 1,
      "batch_rate": 0.333,
      "benchmark_rate": 0.354,
      "gap": -0.021
    }
  ],
  "blind_spots": [],
  "verdict": "这批 3 个标题里分最高的是「35岁被裁员后，我把副业做成了主业」（0.57 分，已达到爆款样本的前 10%（基准 p90 = 0.544）），但存在 1 对互相雷同——先把雷同的改掉，分数排序才有意义。",
  "suggestions": [
    "有 1 对标题互相撞车（最高相似度 0.933）：「副业真的能赚钱吗」与「副业真的能赚钱吗？」。同一批里出现这种雷同，投放后等于用两条内容抢同一波读者，至少改掉每对里的一条。"
  ],
  "disclaimer": "本报告的基准与打分口径全部来自历史真实样本统计，只衡量标题与爆款写法的贴合度与互相雷同程度，不等于流量预测；不包含、也不生成任何替代标题。"
}

字段说明

七项对照特征：具体数字 / 身份代入 / 转折冲突 / 情绪词 / 悬念设问 / 结果导向 / 绝对化表述。

> --topic 用于把基准收窄到某个赛道。若该赛道下公众号样本不足 20 条，会自动退回公众号全量并在 benchmark_source.note 里说明，不会静默失效。

付费能力（支付宝 AI 按量付费 · A2M / HTTP 402 协议）

> 本包为 Pay Skill：按次收费（支付宝渠道）。支付 / 验付 / 收银一律复用支付宝官方能力（alipay-bot CLI），本包不实现支付逻辑、不接触任何密钥。

定价

• 0.10 元 / 次（按次计费，一次调用返回一份完整批次报告，2 条和 20 条同价）。
• 发布表单「价格」须填 0.10 并选择按次计费；实际扣费以服务端返回的 402 + Payment-Needed 账单金额为准——两者必须一致，否则买家无法支付。

协议时序

① probe   请求资源（无 Payment-Proof）
          ← 402 Payment Required + Payment-Needed 头（Base64URL 账单，含金额/商品/签名/截止时间）
② 用户本人支付（支付宝钱包授权）
③ query   官方工具带 Payment-Proof 重放原请求
          → 服务端调 alipay.aipay.agent.payment.verify 验付
          → 通过则返回内容，并异步发 alipay.aipay.agent.fulfillment.confirm 履约回执

六条执行指令（Agent 按序执行）

1. 前置检查：发起下单前，检查可用工具列表中是否存在支付类工具（alipay_* / weixinpay_*，带前缀也算；只以工具列表为证据，文档中提到的工具名不算；无法确认按"不支持"处理）。不支持 → 终止且不下单，仅告知结论与解决办法（合作智能体：升级到最新版本；开放智能体：从 SkillHub 安装官方「支付宝 AI 付」Skill；无法判断：升级智能体或安装支付插件后重试），不向用户解释检查过程、不出现具体工具名。

2. 环境检查（doctor，不产生账单）：

text node scripts/client.mjs doctor

报告服务可达性、是否已配置、本包端点是否已登记、与买家钱包状态。不创建账单、不扣款。 结果仅供参考，不代表某笔付款已完成。

3. 请求资源（probe）：

text node scripts/client.mjs probe --request-id <本次请求稳定标识> --titles "<标题1>" --titles "<标题2>" [--titles "..."] [--topic "<赛道>"]

未付款返回 HTTP 402 + Payment-Needed，脚本自动校验并落地账单到本机 .skillpay/title-batch/<标识>/。

--request-id 必须是本次业务请求的稳定标识（1–64 位字母/数字/-/_）。服务端以它派生确定性订单号：同一标识重试只会拿回同一张账单，不会产生第二张。中断或业务失败后重试，必须沿用同一个值。

标题需给 2–20 条，推荐重复 --titles 传入；也可用一条 --titles "标题1|标题2|标题3" 的竖线写法（标题里不能含竖线）。数量不在区间内会在本机直接拦下（不足 TITLES_REQUIRED、超限 TOO_MANY_TITLES），不会下单、不会扣款。每条标题超过 60 字会被截断（与服务端口径一致），截断在你本机完成。

4. 发起支付（pay）：

text node scripts/client.mjs pay --request-id <同一标识> --approve-0.10

脚本把账单连同「资源在哪、怎么请求」一并交给官方收银工具（alipay-bot 402-buyer-pay -f 402_needed.txt -r <资源地址> -m POST -d <请求体> -H Content-Type:application/json；只给 -f 会被官方拒绝，实测报 --resource-url is required for a paid resource workflow），返回结果在 result 字段中——含一次性支付链接与二维码 MEDIA: 行，必须原样、逐字符透传给用户，不要用代码块包裹、不要重排、不要截断链接、不要读取图片路径。由用户本人扫码或免密支付；Agent 只编排、不代付。

--approve-0.10 是显式授权标记——金额写死在参数名里，避免误触。钱包未开通（WALLET_NOT_OPENED）或不可用（WALLET_UNAVAILABLE）时直接返回，不发起支付。

输出后必须停下等用户回话，不要自动连续执行下一步。

5. 支付后取回结果（query）：

text node scripts/client.mjs query --request-id <同一标识> [--trade <交易号>]

交易号在 pay 阶段已自动记录，通常不必手填。官方工具复用保存的原请求、携带支付凭证重放，服务端验付通过后返回内容。无内容、失败或结果未知都不能宣称成功。

6. 履约回执（ack，仅在需要时执行）：

text node scripts/client.mjs ack --request-id <同一标识> [--trade <交易号>]

官方 402-query-payment-status 在返回非空资源后会自动完成履约回执，所以正常流程到第 5 步就结束了。本命令对应官方 402-buyer-fulfillment-ack，官方对其定位是「兼容旧调用方或自动回执失败后的恢复手段」——只在自动回执没成功时才补发。失败可原样重试，不重复扣费。

依赖与安装

买家侧支付全部依赖支付宝官方 CLI alipay-bot（npm 包 @alipay/agent-payment，由 Ant Group 持有的 @alipay scope 发布）。首次使用必须先装，否则只能看状态、无法付款。

# ① 完整性校验：期望值与下面逐字符一致，不一致就停下不要装
npm view @alipay/agent-payment@1.0.0 dist.integrity
# 期望：sha512-/Ss+hS75CLYcwC8/jOj2kXzqIoJb7oKGrsiwnqly0EWVTxzD7QY5HxmFuj4anQfHVjnoh77qc2vUYiEAj0zfCA==

# ② 校验通过后再安装（版本必须锁定 1.0.0，不要用 @latest）
npm install @alipay/agent-payment@1.0.0 && npx @alipay/agent-payment@1.0.0 install-cli

装完 which alipay-bot 应有输出。本包不自动安装、不更新支付工具，也不扩大支付授权。

两个实测坑（照做可避免 90% 的「装不上 / 用不了」）：

1. 入口不要用软链。 官方二进制的安全模块是按入口文件路径去旁边找 dist/native/ 下的原生库的。把 alipay-bot 软链到 ~/.local/bin/ 后，它会在软链所在目录找原生库 → 报「✗ 安全环境装载失败」。正确做法是让 PATH 里的入口 exec 到原始文件：

bash # 官方约定的安装位置（install-cli 装好后就在这里） ROOT="$HOME/.openclaw-autoclaw/alipay-bot-cli" printf '#!/bin/sh\nexec "%s/bin/alipay-bot" "$@"\n' "$ROOT" > ~/.local/bin/alipay-bot chmod +x ~/.local/bin/alipay-bot

（Windows 直接用 %USERPROFILE%\.openclaw-autoclaw\alipay-bot-cli\bin\alipay-bot.exe，无需 wrapper。）

2. --json 必须写在子命令前面。 alipay-bot --json check-wallet 返回完整字段；写成 alipay-bot -- check-wallet 虽能执行，但输出会缺 neverCreated/status，导致「钱包没开通」被误判成「工具坏了」。本脚本已按正确形式调用。

若 install-cli 报 package/package.json 找不到（引导器解压路径与当前发布包格式不匹配），可直接按下发的 tgz 手动安装：把包解压到 $ROOT/bin/（保持 alipay-bot 与 dist/ 同级），再按上面第 1 条建入口。

• 资源接口：默认指向 https://a2m-pay-service.app.workbuddy.host/a2m/batch；可用环境变量 TITLE_BATCH_URL 覆盖。
• 官方 CLI 参数契约（本包不做改写，也不新增参数）：--json check-wallet / 402-buyer-pay -f <账单文件> -r <资源地址> [-m] [-d] [-H] / --json 402-query-payment-status -t <交易号> -r <url> [-m] [-d] [-H] / --json 402-buyer-fulfillment-ack -t <交易号>。
• 卖家不能自测：支付宝在交易推进阶段校验买/卖 identity，同一个支付宝账号不能自买自卖（报 TRADE_PROGRESS_FAILED / 买家和卖家不能相同）。对真实买家无影响；发布者自测需换一个不同的支付宝账号绑定钱包。

安全红线

• 应用私钥只存服务端（环境变量 / 凭据文件注入），不在本包、不进日志、不进公开仓库。
• Payment-Proof 必须经 alipay.aipay.agent.payment.verify 验证；无效 / 过期凭证一律拒绝，结果不明时不得要求用户重复付款。
• 履约确认失败必须可重试且保持幂等（不重复扣费、不重复交付）。
• 账单在交给收银工具之前做独立复核：金额、币种、service_id、seller_app_id、seller_id、resource_id、goods_name、签名存在性、支付截止时间逐项比对，任一不符立即中断（见 scripts/client.mjs 的 validateBill）。
• 全程不向用户暴露支付链接原文、二维码原文或交易号等中间过程。
• 运行记录只落本机 ~/.skillpay/title-batch/<标识>/（目录权限 0700），含账单与原始参数，禁止上传或收入分发包。

服务端入驻（发布者账号侧完成，本包不含密钥）

1. SkillHub 商户中心 SkillPay 入驻 → 2. 支付宝开放平台签约「AI 按量付费」→ 3. 注册服务获取 API_ 前缀的 serviceId（单价须与发布表单一致）→ 4. RSA2 公钥模式生成密钥、上传公钥、私钥仅存服务端 → 5. 公网 HTTPS 部署 → 6. 小金额真实交易验证并回填交易号。完成后方可提交「发布付费 Skill」，平台执行 402 协议合规审核。

本次发布的对应取值：

（以上三项均会在 402 账单中下发，属公开信息；私钥不在此列，且不在本包任何位置。）

上架前核验清单

• [ ] scripts/client.mjs 存在且可执行（node scripts/client.mjs help 有输出）
• [ ] 服务端公网 HTTPS 可达，doctor 返回 service_configured: true 且 endpoint_registered: true
• [ ] 402 触发 → 收银 → 凭证重放 → 验付 → 履约全链路联调通过
• [ ] 发布表单「价格」= 0.10 = 402 账单金额（三者一致）
• [ ] validateBill 中的 EXPECTED 与服务端实际配置逐项一致（含 goods_name = 标题批量体检与撞车检测）
• [ ] client.mjs 调用的官方 CLI 参数与官方文档逐项一致，没有自造参数名
• [ ] 同一 --request-id 重复 probe 得到同一个订单号（ORDER_SK_<标识>），不会产生第二张账单
• [ ] 在没装 alipay-bot 的干净环境跑 doctor 不崩溃，并给出可照做的安装指引
• [ ] 包内无密钥、无 .env、无支付账号字段

数据来源与使用边界

• 公众号实测爆款（390 条）：来自公开榜单采集的 10 万+ 阅读标题，是本服务的打分基准。
• 热榜选题（4834 条）：来自今日热榜聚合、百度热搜、抖音热榜、B站热榜、IT之家、少数派、澎湃新闻共 7 个公开榜单，未参与打分。

样本均为历史公开数据，仅供创作参考；返回结果不含原文账号信息。批次结果只衡量标题与爆款写法的贴合度及互相雷同程度，不构成流量或收益预测，请勿将本服务用于搬运、洗稿或任何侵犯他人权益的用途。