标题二选一裁决

两个标题改来改去拿不定主意？别再靠感觉抛硬币。用真实爆款样本给它们同基准打分，看差在哪一项。

与另外两个技能的区别

第一次使用（照这个问）

• 「这两个标题哪个好：A『35岁被裁员，我在家躺了三个月』B『35岁职场危机，我是怎么走出来的』」
• 「帮我选一个：『我用 AI 写公众号，一个月赚了 3 万』还是『AI 写公众号的心得分享』」

预期产出：双方得分、裁决结论、各自独有的特征、长度对比、以及可执行的建议。

打分口径（不是黑箱）

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

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

也就是说：分数完全由真实样本统计推导，能被解释、能被质疑，没有主观加权。

会如实说「差不多」

两种情况会直接判平局，而不是硬选一个：

1. 分差小于 0.05 —— 两者与基准的贴合度几乎相同，选哪个差别不大。
2. 两个标题字面相似度高于 0.6 —— 差异主要来自标点或个别字词，样本统计上分不出优劣。

> 这条是实测踩出来的：『副业真的能赚钱吗』vs『副业真的能赚钱吗？』相似度 0.933，照常裁决会得出「取胜关键：含悬念或设问」——等于告诉你加个问号就更好。那是虚假的确定性，所以这种情况一律判平局，并建议你重写其中一个做出真正的差异。

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

输出内容（真实样例）

{
  "input": {
    "title_a": "我用 AI 写公众号，一个月赚了 3 万",
    "title_b": "AI 写公众号的心得分享",
    "topic": null
  },
  "benchmark_source": {
    "pool": "wx",
    "label": "公众号实测爆款（10 万+ 阅读）",
    "sample_size": 390,
    "note": null,
    "how_scored": "命中一个特征，就加上该特征在爆款样本中的占比作为分值；再按长度偏离均值扣分（上限 0.3）。"
  },
  "scores": { "a": 0.58, "b": 0 },
  "winner": "a",
  "margin": 0.58,
  "similarity_between": 0.4,
  "detail": {
    "a": {
      "title": "我用 AI 写公众号，一个月赚了 3 万",
      "features": {
        "number": true, "identity": true, "conflict": false,
        "emotion": false, "suspense": false, "result": true, "superlative": false
      },
      "length": 16,
      "length_gap": 7.5,
      "length_penalty": 0.094,
      "contributions": [
        { "feature": "含具体数字", "weight": 0.297 },
        { "feature": "含身份代入（我/你/35岁/中年/独居…）", "weight": 0.354 },
        { "feature": "含结果导向（赚/省/涨/摆脱…）", "weight": 0.023 }
      ]
    },
    "b": {
      "title": "AI 写公众号的心得分享",
      "features": { "number": false, "identity": false, "conflict": false, "emotion": false, "suspense": false, "result": false, "superlative": false },
      "length": 11,
      "length_gap": 12.5,
      "length_penalty": 0.156,
      "contributions": []
    }
  },
  "only_in": {
    "a": ["含具体数字", "含身份代入（我/你/35岁/中年/独居…）", "含结果导向（赚/省/涨/摆脱…）"],
    "b": []
  },
  "benchmark_avg_length": 23.5,
  "verdict": "「我用 AI 写公众号，一个月赚了 3 万」更接近同类爆款基准（0.58 vs 0）。",
  "suggestions": [
    "取胜关键：含具体数字、含身份代入（我/你/35岁/中年/独居…）、含结果导向（赚/省/涨/摆脱…）——这正是落选那个缺的",
    "落选那个的长度偏离同类均值更多，移动端展示吃亏"
  ],
  "disclaimer": "本裁决的权重全部来自历史真实样本统计，只衡量与爆款写法的贴合度，不等于流量预测；不包含、也不生成任何替代标题。"
}

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

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

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

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

定价

• 0.10 元 / 次（按次计费，一次调用返回一份完整裁决）。
• 发布表单「价格」须填 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 <本次请求稳定标识> --title-a "<标题A>" --title-b "<标题B>" [--topic "<赛道>"]

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

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

两个标题都必须给——少给一个会在本机直接拦下（TWO_TITLES_REQUIRED），不会下单、不会扣款。各自的标题超过 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/duel；可用环境变量 TITLE_DUEL_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-duel/<标识>/（目录权限 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
• [ ] 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 个公开榜单，未参与打分。

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