微博公开信息检索

概述

四条通路已验证，覆盖关键词搜索、单帖正文、账号画像、历史微博

一、能力矩阵（实测）

二、参数要点

• 关键词必须 URL 编码（UTF-8）
• 翻页：追加 &page=N（返回体里 data.cardlistInfo.page 指示当前页）
• 返回结构：{"ok":1,"data":{"cards":[...]}}；正文在 cards[].mblog.text，作者 mblog.user.screen_name，时间 mblog.created_at
• ok:1 但 cards[0].card_type==4 且 itemid=="empty_result" = 无结果，不是失败
• 抓取频率控制在每分钟 5 次以内，避免触发风控；失败先降频重试，不要密集重试

三、解析建议

抓 JSON 接口时，直接在抽取指令里指定要用的字段（作者、时间、正文、互动数、地点），让模型结构化输出，不必落盘再二次解析。若需批量长期监测，改用 Python httpx 直连同一接口，落 JSON 后本地解析。

四、业务化用法示例：本地线下机会监测

许多线下执行机会（快闪、主题布置、品牌活动）最早出现在社交平台的粉丝/兴趣社群公告里，早于任何招商渠道。可固定监测词表（实时排序，每日一轮），把"公告"转成"线索"：

<城市>+<活动俗称> / <城市>+<品类词> / <城市>+<快闪>
+ <目标 IP 或品牌名> + <城市>

识别信号（把公告读成商机）：

• 公告中出现具体城市点位 → 本地落地需求，立即检索该场地与执行方
• 公告含"招募""各城市负责人""进群" → 存在可触达的组织者
• 已落地活动 → 记录场地名，反推该场地的品类接纳度

各地"哪些场地愿意接这类活动"应当自己边做边沉淀成清单，不要依赖现成名单 ——

场地接纳度随年份、招商负责人、经营状况变化，静态名单会过期。

五、可靠性纪律（必读）

社群公告里的场地、时间信息经常是错的。 实战实例：某后援会公告所报场地，经实地确认与实际举办地不符（实际在一家小型咖啡馆）。

因此：

• 公告中的场地／时间一律视为待核实项，交付文档里必须显式标注"需二次核实"，不得直接当事实引用
• 关键信息优先从长图读取（公告类帖子的实质内容大多在图里，正文往往只有宣传语）；图片 URL 取 original_pic 字段，下载后用多模态读图
• 同一条信息尽量双源交叉：官方账号＋本地参与者帖子＋场地方公开信息

术语陷阱：粉丝口语会泛用同一个词。 例如"整楼包装"与"店内一角布置"可能被同一个俗称指代，两者预算量级差 10—100 倍。做商业研判前必须先确认量级，不能凭俗称推断项目规模。

六、合规与边界

只读，不写；只公开，不私密。

• 非官方开放接口，属公开页面数据读取；仅用于公开信息检索
• 不做批量囤积、不采集个人隐私（不抓取手机号、住址、私信、粉丝列表等）
• 不执行任何需登录的操作（私信、关注、发帖、评论），此类动作须用户本人在浏览器中完成
• 不绕过登录墙、验证码、风控限制；遇到限制即停止并说明
• 抓取频率受限（≤5 次/分钟），避免对目标服务造成压力
• 结果仅供内部研判；引用需交叉验证（公告 ≠ 合同，场地与时间存在变更可能）
• 商业用途时请自行确认内容版权与平台条款，本技能不代为用户承担合规责任

这个技能不做什么

• 不抓评论、私信、关注关系等需登录的内容
• 不做账号登录态管理（无 Cookie / Token 方案）
• 不提供数据存储与去重服务（长期监测需自建落盘与比对）
• 不判断信息真伪 —— 它只提供通路与纪律，核实仍需实地或双源交叉