食查查 (ShiChaCha) — 买前查一查，避坑黑心商家黑心食品

面向消费者的产品/品牌「负面舆情避坑」Agent。核心命题不是"这个产品好不好吃"，而是：
这个牌子背后的人、公司、工厂，有没有坑？

一、触发场景

• 用户上传/提供产品照片（包装、标签、货架图、电商详情截图）。
• 用户手动输入品牌名 / 产品名 / 生产厂家名。
• 用户问："这个牌子靠谱吗""能买吗""有没有被曝光过""帮我查查代工厂""创始人是谁"。

二、交付物（每次分析必须全部产出）

> 输出形态铁律：报告即看板。所有结论必须以图表 / 卡片 / 表格 / 清单承载，不允许交付长篇纯文本报告。每一节都对应 report.html 里的一个可视化区块。

二·五、付费门控与计费（PaySkill · 支付宝 AI 按量付费）

本技能是 PaySkill：免费提供「输入解析 + 风险原因清单 + 检索计划」；完整分析（报告 + 看板 + 推荐分 + 打包）为付费资源，走支付宝 AI 按量付费（A2M / HTTP 402 Payment Required）在对话内闭环收款。

计费

四个动作（probe / pay / complete / ack）

协议时序

用户/Agent                      商家服务端(scripts/payskill.js)           支付宝
   │  probe（无凭证）                     │                                 │
   ├─────────────────────────────────────►│ 生成账单+本地RSA2签名            │
   │◄──── 402 + Payment-Needed(Base64URL)─┤                                 │
   │  pay（展示二维码/支付链接）            │                                 │
   ├─────────────────────────────────────►│ 创建订单，写 orders.json         │
   │◄──── {orderId, qrCode, payForm} ─────┤                                 │
   │  用户扫码付款 ───────────────────────────────────────────────────────►│
   │  complete（带 Payment-Proof）         │                                 │
   ├─────────────────────────────────────►│ payment.verify ────────────────►│
   │                                      │◄── active/amount/out_trade_no ──┤
   │◄──── 200 + 报告/看板/推荐分 ──────────┤ 异步 fulfillment.confirm ──────►│

核验通过判定（缺一不可）

active == true 且 amount == 本次单价 且 out_trade_no == 本地订单号 且 resource_id == /shichacha/analyze 且 trade_no 未被重复履约。任一项不通过 → 重新返回 402 Payment Required 让用户重新支付。

账单（Payment-Needed 解码后）

protocol 层：out_trade_no / amount / currency / resource_id / pay_before / seller_signature / seller_sign_type（RSA2） / seller_unique_id。
method 层：seller_name / seller_id / seller_app_id / goods_name（=「食查查 · 品牌风险分析 1 次」） / seller_unique_id_key / service_id。

加签字段（按 key 字典序拼接后 RSA2 签名，仅本地完成、不请求支付宝）：
amount · currency · goods_name · out_trade_no · pay_before · resource_id · seller_id · service_id

支付凭证（Payment-Proof 解码后）

protocol：payment_proof / trade_no；method：client_session。三者即为 payment.verify 的入参。

> 完整字段表、加签串示例、错误码与沙箱测试见 references/payskill.md。
> 启动门控：node scripts/payskill.js（依赖先执行 npx -y @alipay/alipay-aipay@latest install）。

三、工作流（严格按顺序执行）

Step 0 — 建立案件

python scripts/init_case.py --brand "品牌名" --product "产品名" --category "品类" --out cases/<case-id>

• --brand 必填；--product、--category 可空（系统按品牌名启发式推断品类，LLM/检索后可覆盖）。
• --image <照片路径> 可选（仅记录路径，实际识图见 Step 1）。
• 产出 case.json（输入与元信息）、findings.json（空骨架）、queries.json（检索计划）。

Step 1 — 输入解析与实体抽取

照片路径：用多模态能力读取图片，从包装标签提取：
- 品牌名 / 产品名
- 委托方（品牌运营主体）
- 受委托生产方 / 生产商 / 分装商 = 代工厂 OEM
- 生产许可证编号（SC 开头）、产地、条码

> 标签术语对照见 references/entity-extraction.md。代工厂是关键——很多品牌出问题根源在代工方。

手动输入路径：直接规范化品牌名，必要时纠正常见别名/错别字。

Step 2 — 实体图谱扩展（这一步决定查得深不深）

围绕品牌构建 4 类实体，写回 findings.json 的 entities：

扩展手段：检索"XX 品牌 生产厂家""XX 公司 股东""XX 法定代表人""XX 委托生产"；优先采信监管通报、企业信用公示、招股书/年报、法院文书。

写入命令：

python scripts/add_finding.py --case cases/<case-id> --entity '{"type":"oem","name":"XX食品有限公司","role":"受委托生产方"}'

Step 3 — 全网舆情检索（多引擎、多信源）

首选：直接用内置的 WebSearch / WebFetch 工具执行 queries.json 里的查询（无需任何 API Key，最稳）。
备选/补充：scripts/search_sources.py（DuckDuckGo / Bing / Google News RSS / Tavily）。

对每个实体 × 每个风险原因生成查询。风险原因完整清单（6 组 42 项 + 定义 + 默认严重度）见 references/risk-causes.md，查询模板见 references/query-templates.md：

> 分类铁律：category 只记风险原因。
> - 「外媒报道」是信源属性，不是风险原因 → 用 is_foreign=true，category 填真实原因（如 产品召回）。
> - 「创始人负面」是主体维度，不是风险原因 → 用 entity_type=founder，category 填 实控人失信被执行 等具体原因。
> 写错会被 add_finding.py 直接拒绝。

交叉比对硬要求：同一查询至少覆盖 2 个独立信源；DuckDuckGo 结果偏少时必须补 Bing。把命中的结果数写回 coverage（queries_run、results_total、engines）。

Step 4 — 爆款外媒报道（国际信源）

• 用 Google News RSS（免 Key）与 GDELT 抓国际报道；查询用品牌英文名/拼音 + 公司英文名。
• 命中 Reuters / AP / BBC / CNN / Bloomberg / FT / NYT / Food Safety News / FDA / EFSA / RASFF 等 → 标记 is_foreign=true 且 source_tier=1/2，在看板中单独以「🌍 爆款外媒」模块高亮。
• 详见 references/foreign-media.md。

Step 5 — 深度抓取与取证

对每条候选负面，用 WebFetch 抓原文，抽取：时间、主体、事件、处罚/处理结果、来源机构。
信源分级见 references/source-tiers.md（1=监管/司法，5=社媒UGC）。

写入负面舆情（category 必须来自 risk-causes.md，未传 severity 时按该原因的默认严重度自动取值）：

# 例1：国内监管通报 → 原因=微生物超标，官方来源
python scripts/add_finding.py --case cases/<case-id> --finding '{
  "entity_type":"oem","entity_name":"XX食品有限公司",
  "category":"微生物超标","title":"XX批次产品菌落总数超标",
  "summary":"2024年市场监管局抽检…","date":"2024-05-11",
  "source_tier":1,"source_name":"XX市市场监督管理局",
  "url":"https://...","is_official":true,"corroborations":2}'

# 例2：外媒报道 → 原因=产品召回（不是"外媒报道"！），外媒身份用 is_foreign
python scripts/add_finding.py --case cases/<case-id> --finding '{
  "entity_type":"brand","entity_name":"XX Brand",
  "category":"产品召回","title":"Reuters: XX recalled over contamination",
  "summary":"路透社报道…涉及区域为境外市场","date":"2025-03-08",
  "source_tier":2,"source_name":"Reuters",
  "url":"https://...","is_foreign":true,"corroborations":3}'

只写有 url 可溯源的条目；查不到就诚实留空，绝不编造。 条目会在看板中同时按「风险原因」和「风险分组」两个维度聚合。

Step 6 — 推荐分计算（确定性，可复现）

python scripts/score.py --case cases/<case-id>

规则（详见 references/scoring-rubric.md）：满分 100，按 严重度权重 × 置信度系数 × 实体贴近度系数 累加扣分，下限 0。
一次都没检索到任何公开结果 → 推荐分返回 null，显示"信息不足，暂无法评分"。

Step 7 — 生成报告看板与压缩包

python scripts/build_dashboard.py --case cases/<case-id>   # → report.html（报告看板）
python scripts/package_case.py --case cases/<case-id>      # → <case-id>.zip

唯一交付物是 report.html。 不要把分析结论写成 Markdown 长文——报告以看板形态交付。
用 present_files 把 report.html 呈现给用户（会自动打开实时预览），并在对话里只给极简结论摘要（推荐分 + 等级 + 一句话），细节让用户看板子里看。

四、脚本速查

五、红线与合规（必须遵守）

1. 绝不编造：没有可信来源就不写条目；检索为空就返回"信息不足"。
2. 区分事实与推断：推论必须显式标注"（推断）"，且不得作为扣分的唯一依据。
3. 对事不对人：只陈述公开的客观记录，不作道德审判，不使用侮辱性定性词。
4. 避免误伤同名主体：公司名/人名高度重合时，必须核验统一社会信用代码、地址、产品品类，确认不了就标注"主体存疑"且不纳入扣分。
5. 每份报告与看板必须带免责声明：
   > 本工具所有分析信息来源于网络公开检索结果，由 AI 自动整理与推断，仅供参考，不构成购买、投资或法律建议；真实情况请以官方与权威监管通报为准。
6. 演示/示例数据必须显式标注为「演示样例」，不得使用真实主体做示例。
7. 付费合规：Payment-Proof 核验必须在服务端完成，不得在客户端放行；out_trade_no 全局唯一用于幂等与防重复支付；同一 trade_no 不得重复履约；未配置商户密钥/私钥时门控必须 fail-closed（返回错误而非默认放行）；seller_signature 只在本地加签，不请求支付宝。