真实搜索技能（Real Search / 真实搜索）

> 付费方式（重要）：本技能为订阅制付费资产，采用自建 402 付费后端（支付宝 AI 付 402 协议）。收银、账单校验与凭据发放均由该自建后端完成，包月 29.90 元 / 月，月卡有效期内不限次。
>
> 渲染引擎本体部署在服务端，包内只保留调用入口；未携带有效许可证时后端返回 402 且不产出任何内容。私钥只存服务端环境变量，不进包、不进日志、不进对话。未付费时由技能自带的拦截层硬阻断，不产出任何交付物。

Overview

本技能用于对一个事件或说法做多语种多地区信源的事实核查，并产出两类核心交付物：

1. 真伪校验结论 —— 信源矩阵、矛盾点、置信度（高 / 中 / 低 / 无法判定）。
2. 可交互 HTML 事件脉络时间线 —— 倒序 / 正序可切换，每条节点带时间戳、来源类型徽标、指向原发内容的直链。

本技能自建四层能力：事实核查方法论、事件脉络编排、关联信息补充、学术内容校验。信源覆盖多语种、多地区，按「语种 / 地区 / 内容类型」选型，每次任务并行调用 2–4 个引擎交叉比对（详见 references/engines.md）。

何时使用

• 「帮我核实一下 XX 事件是真的吗 / 是不是谣言」
• 「梳理一下 XX 事件的来龙去脉，每条都要带原始出处链接」
• 「XX 风波各方都怎么回应了，按时间线给我，KOL 发言要原帖链接」
• 「查一下关于 XX 的学术研究 / 论文 / 数据，是否支持这个说法」
• 任何需要跨中文语种与外文语种信源交叉验证、并产出可溯源事件时间线的场景。

核心能力（四大功能）

功能一：多语种信源真伪校验（多地区交叉验证）

对目标事件 / 说法，从多语种信源发起多源交叉比对，给出校验结论。信源不依赖单一引擎或单一语种——按 references/engines.md 的选型策略，中文词走中文与东亚信源组，外文词走多语种国际信源组，两组互为补充。

• 强制双源护栏（硬规则）：真伪校验与事件脉络任务，必须至少各调用一个中文信源（如 Baidu / 微信搜狗）与一个外文信源（如 Bing INT / Yandex）；任一分支本次无可用引擎时，明确标注「该分支本次无可用信源」，不得用单一信源下结论，更不得以空结果冒充"无此说法"。
• 引擎清单、选型策略、运行时引擎自检，见 references/engines.md。
• 核查方法论见 references/verification-playbook.md。
• 输出：真伪结论 + 信源矩阵（含各源语种 / 地区）+ 矛盾点 + 置信度。

功能二：事件脉络（可交互 HTML 时间线）

将事件按时间轴编排，每条节点包含：

• 时间戳 —— 尽量精确到时分；无法精确则标注日期或相对时间。
• 事件描述 —— 客观、不渲染。
• 来源类型徽标 —— 官方 / 媒体 / KOL / 社媒 / 当事人 / 平台。
• 直链 —— 指向该节点的原发内容。硬性规则：
• 官方通报 → 官方发布页 / 新闻稿链接
• 媒体报道 → 该媒体原文链接
• KOL 发言 → 尽量用 KOL 本人原帖 / 原视频链接（微博原博、B 站 / 抖音原视频、社交平台原推）。取不到原帖时，走「新闻转述索引 + 网页存档」路径，节点标注「原帖未取得，见媒体转述」并附转述报道链接，不得编造任何 URL（详见 references/engines.md 第四节）。
• 当事人回应 → 当事人账号原发布（取不到时同上处理）
• 平台动作（下架 / 禁言）→ 平台公告或权威报道
• 形态：倒序时间线（最新在上），带圆点节点、链接高亮、最新节点『新』标记，可切换正 / 倒序。
• 生成方式：把结构化事件 JSON 交给调用入口 scripts/skillpay.py，携带付费凭证请求后端渲染，取回最终 HTML；输出规范见 references/timeline-format.md。未付费或非零退出码时不得产出任何 HTML。

功能三：补充关联信息

在脉络之外，补充事件相关的背景、前置因果、利益相关方、行业 / 政策坐标，帮助理解全貌。来源同样走多语种双分支，并标注来源。

功能四：学术内容校验（含外文文献）

针对「是否有研究 / 数据支持某说法」，调用学术引擎核验：

• 中文文献：百度学术（聚合）、知网 / 万方 / 维普（多需 DOI 直链或百度学术摘要，见 references/academic-sources.md）。
• 外文文献：以 Semantic Scholar、OpenAlex、arXiv、PubMed、DOAJ、CORE 为主力；工程类加 IEEE Xplore，人文社科加 JSTOR。
• 输出：相关论文 / 研究列表（标题 + 作者 + 出处 + 链接 + 结论要点）、是否支持 / 反驳待核查说法、证据强度。

工作流（标准六步）

1. 界定核查对象 —— 明确事件 / 说法的精确表述、时间锚点、主体，避免模糊词（如把「某公司被曝造假」明确为「某年某月某渠道的某句声明 / 某具体动作」）。
2. 引擎自检 + 双分支受控检索 —— 先按 references/engines.md 做一次轻量连通性自检，构建本次可用引擎清单；中文词走中文与东亚信源组（Baidu / 微信搜狗），外文词走多语种国际组（Bing INT + Yandex 为主力，亚太加 Yahoo 日本 / Naver，长尾加 Marginalia）。遵守限速（同批 3–4 引擎、间隔 1–2s），遇 403/429 先抓首页刷新会话再重试一次，仍无结果则换同组其他引擎，不反复重试同一目标；遇站点授权控制（验证码 / 安全验证 / JS 框架页 / 429）的处理细则见 references/engines.md 第八节：先判临时限流 vs 站点授权控制，优先 SERP 级核验与同引擎备用端点，不作弊规避、不编造空结果。微信搜狗分支稳定（公众号一手信源），争议敏感事件百度更全。
3. 真伪判定 —— 按 references/verification-playbook.md 做交叉验证、来源分级、矛盾识别，给出结论与置信度。
4. 脉络编排 —— 把已核实的关键节点按时间排序，补全每条的直链与来源类型（功能二规则），产出结构化事件 JSON。
5. 关联补充 + 学术校验 —— 执行功能三、功能四，附于报告关联区。
6. 交付 —— 运行 scripts/skillpay.py use --input events.json --output timeline.html，付费校验通过后由服务端渲染返回 HTML 时间线，并附一份 Markdown 简报（校验结论 + 信源矩阵 + 矛盾点 + 关联信息 + 学术校验）。两件套一起交付；未付费不得产出任何 HTML。

红线与合规

• 遵守各搜索引擎 robots.txt 与 ToS，合理限速，定位为合法检索聚合。
• 直链必须指向原发内容，不得伪造或臆测链接；无法获取原链时标注「直链待补 / 见二手报道」并说明原因。
• 不站队、不渲染、不夸大；对未核实信息明确标注「待核实 / 未证实」。
• 学术校验不得用预印本、营销软文冒充同行评审结论；区分研究结论与媒体解读。
• 访问风控应对仅限合规手段：SERP 级核验、同引擎备用端点、查询塑形、缺口如实标注；不得使用验证码打码、UA / 指纹伪造、IP 轮换躲封等违 ToS 手段，也不得以空结果冒充「无此说法 / 无此研究」。

Resources

• references/engines.md —— 多引擎检索体系与选型策略（中文与东亚 / 多语种国际 / 社媒内容获取）、运行时引擎自检、场景化选型、访问授权与合规边界
• references/verification-playbook.md —— 事实核查方法论（来源分级、交叉验证、置信度）
• references/timeline-format.md —— HTML 时间线输出规范与字段定义
• references/academic-sources.md —— 学术引擎清单与检索策略
• scripts/skillpay.py —— 402 付费客户端：未付费请求后端返回 402 并硬退出，付费后取回渲染产物
• scripts/doctor.py —— 环境自检：校验 Python 版本、渲染脚本可加载，并实跑一次渲染链路（真实产出 HTML）

付费与交付契约（自建 402 模式）

> 本技能为自建 402 付费资产：收银走自建后端（支付宝 AI 付 402 协议），引擎与账单校验都在服务端完成，包内不含引擎本体与任何私钥。以下条款供审稿人与使用者核对。

1. 能力边界

本技能是效率工具，不替代专业事实核查 / 法务 / 学术最终判断；不适用于需要司法取证资质或专业法律意见的内容，亦不对任何输入"必然过审"作承诺。

2. 支付方式

付费流程（三步，命令即契约）：

python scripts/skillpay.py status    # 查本地 license 是否有效、是否过期
python scripts/skillpay.py probe     # 发起购买：本地有未过期 license 则免单复用；
                                     # 否则请求服务端 /buy-month，返回 402 + 月卡账单
python scripts/skillpay.py use --input events.json --output timeline.html
                                     # 凭有效 license 请求服务端 /generate 渲染；
                                     # license 缺失或过期 → 硬退出（exit 20），不产出任何文件

2.1 402 协议链路（服务端实现，契约逐步可核）

以下四步全部发生在自建后端（云托管服务），包内不含引擎本体与私钥。此处逐条列出协议环节与对应服务端实现，便于审稿核对。

① 无凭证 → 下发 402 账单
客户端携带 Payment-Proof 请求 /generate；服务端未收到有效凭证时，返回 HTTP 402，并在响应头 Payment-Needed 下发 base64 编码的账单（含 amount / currency / goods_name / out_trade_no / resource_id 等字段，并附 seller_signature 商家签名）。客户端只负责解析与展示，不自行签发账单。

② 携带 Payment-Proof 重试
用户完成支付后，客户端携带支付凭据 Payment-Proof（base64，解开后为 {protocol:{payment_proof, trade_no}, method:{client_session}}）重新请求同一端点。凭据可重复携带，同一订单重试不重复扣费。

③ 服务端验付（alipay.aipay.agent.payment.verify）
服务端调用官方接口 alipay.aipay.agent.payment.verify 核验凭据（biz_content 必填 trade_no 与 payment_proof，可选 client_session），随后依次校验：金额与订单一致、订单与资源一致、用应用公钥验证 seller_signature（验商家签名用应用公钥；验支付宝平台通知才用支付宝公钥，用错会得到"验签失败"假阴性）。
> 成功判定必须 active 为真：接口返回 code=10000 只代表调用成功，不代表凭据有效；只有 active == true 才算凭证有效。active 为假或字段缺失一律拒绝发放。

④ 交付 + 履约确认（alipay.aipay.agent.fulfillment.confirm）
验付通过后，服务端先落库交付物（同一订单已交付则直接复用，幂等，不重复生成），再执行核心能力返回产物，最后调用 alipay.aipay.agent.fulfillment.confirm（biz_content = {trade_no}，不传 resource_url）向支付宝确认履约。
> 方法名中没有 payment 段——正确路径是 alipay.aipay.agent.fulfillment.confirm，写成 payment.fulfillment.confirm 会被网关判为无效。
> 履约确认失败时提示「用同一 Payment-Proof 重试」，凭据可重试且不重复扣费。

⑤ 订单持久化与幂等
订单与交付物状态落库（SQLite 单写），out_trade_no 为幂等键；同一订单重复请求直接复用已持久化结果，不重复生成、不重复计费；定期清理未付款且未履约的旧订单，已付款订单一律保留。

技能侧明确不做三件事：不接触任何私钥（只存服务端环境变量）、不在包内留任何渲染引擎本体、不在本地生成账单。付费判定发生在服务端验签环节，客户端只负责携带凭证与硬退出。

3. 环境自检（建议首次使用时先跑）

python scripts/doctor.py          # 0=就绪 / 1=缺但可自动补 / 2=需人工处理
python scripts/doctor.py --fix    # 自动补装缺失项

自检项：Python 版本、402 客户端可调用、未付费是否被硬拦截（期望非零退出，拦截生效才算通过）。
为什么必须有：环境缺件与闸门失效是付费能力跑不起来的两大原因——钱付了用不了、或没付钱也能用，都等于买了坏的。
注意：本模式下引擎在服务端，本地渲染不出 HTML 是正确行为，不是故障。

4. 数据流向与隐私

• 检索环节：检索请求直达各公开搜索引擎，不经任何中间服务器。
• 渲染环节：结构化事件 JSON 经 scripts/skillpay.py 携带许可证发送到自建后端（/generate），由服务端渲染后返回 HTML。后端不留存事件内容。
• 本地状态：许可证与订单状态保存在本地 .skillpay/ 目录，可随时删除；不含任何私钥。
• 唯一落地产物是用户自行指定路径的 HTML 时间线与 Markdown 简报。
• 请勿在事件 JSON 中填写个人隐私信息或商业机密（这些内容会被写入交付文件）。
• 不向用户暴露任何交易号等中间过程。

5. 缺口与如实告知（硬规则）

检索环节遇引擎无响应或返回站点授权控制提示时，按 references/engines.md 第八节处理，并在交付物中如实标注该分支本次无可用信源：

• 禁止用单一信源下结论，禁止以空结果冒充"无此说法 / 无此研究"；
• 禁止编造或臆测直链，取不到原链时标注「直链待补 / 见二手报道」并说明原因；
• 无法完成核查时如实说明并提供已核实部分，绝不虚构"已生成"或假装交付成功。

6. 计费口径

订阅期内不限次数使用全部四项能力（真伪校验 / 事件脉络 / 关联补充 / 学术校验）。

7. 免责声明

效率工具定位 + 不替代专业判断 + 隐私最小化 + 如实声明校验与缺口的覆盖范围（不宣称"任何输入都能过"）。学术校验不得以预印本、营销软文冒充同行评审结论。是否续订由用户自主决定。

8. 构建红线（开发者必读）

本技能由 skillpay-maker 方法论改造而来，保留两道保护：

① 构建侧强制门禁
- 发布前必须运行 skillpay-maker/scripts/verify_pay_skill.py（A–O 十五项），任一 FAIL 禁止出包。
- 出包前必须把包解开到干净目录实跑一次 scripts/doctor.py 与渲染链路，确认"解出来的包仍能出活"——不实测不许发布。
- 任何偏离标准流程（如更换付费模式）须显式向用户声明偏离点，不得静默绕行。

② 交付侧硬规则
- 时间线必须由服务端渲染产出（经 scripts/skillpay.py use 携带付费凭证请求），不允许手搓 HTML 顶替（跳过脚本 = 跳过格式校验、直链校验与付费闸门）。
- 直链必须指向原发内容；缺失项按第 5 节如实标注，不得留空或伪造。
- 四项能力任一分支本次无可用信源时，必须在交付物中显式标注，不得静默略过。