daily-scout：五源每日发现 + 四维分诊 + 人工闸门

它解决的问题

robotworld-daily-cron v3.2.0 是站点的内容发动机：每天从五个信息源扫出新东西，打分入待确认队列，用户在后台点头之后由 agent 逐条深度采集直到发布。数字孪生里的执行者是 daily-scout，任务键形如 daily:2026-08-28，start/finish 配对幂等。

这条 skill 的核心不是「会爬」，而是一套不对称的节流：发现可以批量（脚本秒级扫公开 API），采集入库逐条串行，enrich 元数据逐条由 agent 生成，论文详情页逐篇精读。分诊阶段明令绝不下载媒体、绝不精读论文——深度采集留到用户确认之后。省 token 是次要收益，主要收益是不让机器替人做「值不值得收」的判断。

五个信息源

源	怎么扫	候选粒度
twitter	约 50 个机器人/具身 AI 领域追踪账号	账号级，还要浏览器巡逻主页找具体视频推文
github	关键词搜索，近 N 天创建、≥1 star，按 stars 排序	仓库级
hf	按最近更新排序 + 7 天内更新过滤	模型/空间级（新颖性铁律：超过 7 天算旧）
blog	官方博客 RSS，源列表在 BLOG_FEEDS	文章级（只收已验证可用的源）
paper	arXiv 最近 N 天，具身/世界模型/VLA/人形话题	论文级，含摘要

SERVER=root@43.162.123.152
ssh -p 2222 -F /dev/null -o BatchMode=yes $SERVER \
  "docker exec -w /app robotinfo-api python /app/scripts/daily_cron/discover_sources.py --days 7 > /tmp/candidates.json"

分诊：四维打分 + P0/P1/P2

triage_candidates.py 对每条候选算 0-10 的加权总分，四个维度各有明确信号：

• novelty 新颖度：头部机构、新发布、关键词命中数
• freshness 时效性：距最后更新/发布的天数，>7 天判老旧
• relevance 相关度：站点定位关键词命中
• impact 影响力：stars / likes / downloads / 有无开源代码 / 有无真机验证

分级 P0 重磅（当天必采）、P1 常规、P2 跳过。P0 与 P1 自动写进 content_queue_items（status=pending），同 URL 幂等去重，所以每天重复扫不会把队列灌爆。

状态机与人工闸门

队列状态是 pending → confirmed → done / rejected，管理页 /manage/queue。列表里能看到多维打分、一行摘要、原始信号和预览入口：已入库的走站内预览（管理员可看未发布条目），未入库的给原始 URL。发布权限规则是 2026-08-31 定的两条：

• 用户手动指定的 URL → ingest.py --publish 直接采集发布，不排队
• agent 自己发现的内容 → 只做轻量分诊入待确认队列，用户在后台点「确认采集」，再由用户唤起 agent 说「采集确认采集队列」才执行深度采集

这道闸门看起来慢，实际是让机器把「广撒网」的成本压到几乎为零，把「精读」的成本留给人决定。执行阶段串行处理，避免 SSH 并发断连；做完回填 status='done'、done_at 与 content_id（内容落点 id），这样队列本身就是可审计的采集台账。

「发布」的定义被改写过

2026-09-04 起，发布 = 采集完 + 社交物料齐。只入库不分发的内容，增长飞轮少一圈；OG 卡片晚补则社媒抓取器永久拿不到 og:image（它会记住 404 且不重试）。阶段 2.5 的顺序固定：先生成中英两张 1200x630 OG 卡（kind 按内容类型取 demo/paper/article/opensource），再逐条撰写社交重写稿并顺手渲 1080x1350 竖版知识卡，然后取六平台英文帖子包，最后目检。

这里有两条容易踩的：知识卡不能批量补，因为内容来自重写稿，没有稿子就 404；重写稿必须逐条写，钩子、事实条、数字都要来自真实采集到的内容，不许从标题+摘要编——这与论文详情页逐篇精读是同一条铁律。另外 api 容器里没有 curl/wget，社交接口要用本地 curl 带 X-API-Key 打公网域名。

阶段 2.6：存量才是最大的库存

当日采集分发完，再从存量里挑几条发。2026-09-04 实测生产库有 291 篇已发布精读论文（published=true 且 detail_html_en 超 3000 字），而 social_rewrites 只有 1 行，Umami 里 utm 回流仅 12 条且全来自 chatgpt.com——库存几乎全部未动用。待发稿队列是这条流程的唯一入口，不用翻 SOP 也不用猜今天发了什么：

curl -s "https://robotworld.top/api/social/rewrite?status=draft&limit=20&lang=en"

节奏是每天从存量挑 2-3 条写稿，优先近期发布、有封面图、实验数字硬的；写完进 draft，当天或次日投递并回写 published。角度错峰：同一条内容首次用 insight，之后换 number/howto/contrarian/timeline，避免同一句话在信息流里重复出现。连续几天零回流的角度和平台就少写，把额度挪给有回流的。

选题的第二个信号是站内分享点击：telemetry_events 里 kind='share' 的 payload 带 {platform, kind, id}，说明这条内容有真人主动转发的意愿。挑存量写稿时，有分享点击的条目优先级高于纯高浏览量——浏览量可能是搜索引擎扫过，点击分享是有人愿意为它背书。

诚实的边界

cron 只负责「发现」，采集与富化都需要 agent 在场；这条 skill 也不是一个可安装的开源包，它绑死本站的 content_queue_items 表、/manage/queue 后台、五源脚本和社交物料链。可迁移的是三个设计决定：发现与采集的成本分层（批量扫、串行采）、把人工确认做成状态机而不是口头约定、以及把「发布」的定义扩到包含分发物料。第三点尤其值钱——大多数内容站的库存不是不够，是采回来没人发。