标题体检与诊断

标题写完了，别靠感觉判断行不行。把它拿去跟真实爆过的标题逐项对照，看差距在哪。

与「爆款标题检索」的区别

先检索找方向、写完之后再体检，是两个动作，不要混用。

第一次使用（照这个问）

• 「帮我看看这个标题行不行：『我用 AI 写公众号，一个月赚了 3 万』」
• 「35岁被裁员后我做了什么 —— 这个标题差在哪？」

预期产出：一份诊断报告（主基准 + 全库对照 + 命中项 + 缺失项 + 长度对比 + 最相似真实样本 + 改动方向）。

能力边界

能做：对照真实样本统计，指出你的标题命中/缺失了哪些爆款常见特征；给出长度偏差；找出最相似的 5 条真实样本；给出改动方向。

不能做：不生成替代标题；不做语义理解（只做可验证的字面特征统计）；不预测阅读量；不保证改了就一定爆。

> 「不生成替代标题」是刻意的设计。一经掺入 AI 现编的标题，它就不再是「你跟真实样本的差距报告」，而变成一堆无法验证的漂亮话——那不是你花钱要买的东西。

关于基准：为什么不用全库均值

全库 5224 条里 4834 条是热榜新闻标题，只有 390 条是公众号实测爆款。两类写法根本不是一回事：

拿新闻标题的均值去衡量一个公众号标题，等于用短跑成绩要求马拉松选手，得出的「你缺什么」全是噪声。所以主基准默认取同类的公众号爆款样本，全库数据作为对照一并给出，你自己能看清差距来源。

输出内容（真实样例）

{
  "input": { "title": "我用 AI 写公众号，一个月赚了 3 万", "topic": null },
  "scope": { "used": "all", "sample_size": 5224, "note": null },
  "benchmark_source": {
    "pool": "wx",
    "label": "公众号实测爆款（10 万+ 阅读）",
    "sample_size": 390,
    "note": null,
    "why": "体检对象多为自媒体标题，故基准取同类样本而非被新闻标题稀释的全库均值。"
  },
  "benchmark": {
    "sample_size": 390,
    "avg_length": 23.5,
    "feature_rates": {
      "number": 0.297, "identity": 0.354, "conflict": 0.074,
      "emotion": 0.028, "suspense": 0.221, "result": 0.023, "superlative": 0.085
    }
  },
  "reference_benchmark": {
    "pool": "all",
    "label": "全库对照（含新闻热榜）",
    "sample_size": 5224,
    "avg_length": 19.9,
    "feature_rates": {
      "number": 0.251, "identity": 0.169, "conflict": 0.04,
      "emotion": 0.008, "suspense": 0.204, "result": 0.018, "superlative": 0.043
    }
  },
  "your_features": {
    "number": true, "identity": true, "conflict": false,
    "emotion": false, "suspense": false, "result": true, "superlative": false
  },
  "length_note": "长度 16 字，比同类爆款均值 23.5 字短 8 字，信息量可能不足",
  "nearest": [
    { "title": "我们尝试用AI造了一个时空", "similarity": 0.222, "source": "热榜选题", "topic": "技术与人性", "score": 30.4 },
    { "title": "教别人用AI，我赚翻了", "similarity": 0.16, "source": "热榜选题", "topic": "技术与人性", "score": 38.9 },
    { "title": "AI写稿越来越顺溜，综合科长这个岗位还有必要吗？", "similarity": 0.105, "source": "公众号实测爆款", "topic": null, "score": null }
  ],
  "gaps": [],
  "strengths": [
    "含具体数字（爆款样本中 30% 具备）",
    "含身份代入（我/你/35岁/中年/独居…）（爆款样本中 35% 具备）"
  ],
  "suggestions": [
    "比同类爆款明显偏短，可补一个具体对象或结果（谁、多少钱、多少天），把信息量顶上去"
  ],
  "disclaimer": "本报告的基准全部来自历史真实样本统计（主基准为同类公众号爆款样本，另附全库对照），仅作创作参考；不包含、也不生成任何替代标题。不构成流量或收益预测。"
}

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

> ⚠️ --topic 用于把比对范围收窄到某个赛道。若该赛道下公众号样本不足 20 条，会自动退回公众号全量并在 benchmark_source.note 里说明——不会静默失效。传入不存在的赛道名时，scope.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 "<待体检标题>" [--topic "<赛道>"]

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

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

标题超过 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/check；可用环境变量 TITLE_CHECK_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-check/<标识>/（目录权限 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 个公开榜单，作为全库对照与题材参照。

样本均为历史公开数据，仅供创作参考；返回结果不含原文账号信息。体检报告不构成流量或收益预测，请勿将本服务用于搬运、洗稿或任何侵犯他人权益的用途。