让 AI 新闻自己“出刊”：AI风暴眼自动制播与 B站发布实战

布衣云水客大约 19 分钟

让 AI 新闻自己“出刊”：AI风暴眼自动制播与 B站发布实战

想象一下，你给一间小小的新闻编辑部留了一张值班表。

它每两小时看看世界：实验室有没有发布重要成果？模型的能力、价格或安全边界有没有真的改变？一篇论文、一条公开原帖，是否值得让普通观众停下来听一分钟？

遇到大消息，编辑查证、写稿，主播开口，剪辑师排镜头，封面设计师点亮风暴中的那束电光。最后，发行员把视频送到 B站——还会回头确认：观众真的能看了吗？它进合集了吗？

这就是《AI风暴眼》想做的事。不过，这间编辑部最重要的本领，恰恰是知道什么时候不出刊。

本文依据 /home/isp/wsps/daily 的配置、生产脚本与实际回执整理，规则截点为 2026 年 9 月 30 日，北京时间。它是一份现有项目的实战导览，不是一条复制后就能零配置运营频道的“万能命令”。教程本身也不会启动视频任务。

一、先认清玩法：巡查有时钟，出片看新闻

早期流程里曾有日更、每周固定出片，以及 08:00、12:20 等公开时间。9 月 30 日的新规范覆盖了这些旧安排：

北京时间每两小时巡查一次。
默认关注近 12 小时发生的实质新增事实；旧事件有重大新进展时，只讲新增部分。
一条足够重要的消息就能单独成片，不强求六个候选或三条新闻。
视频目标 60～120 秒，硬上限是严格短于 180 秒。
来源、权利、成片和草稿全部过关后，在既有授权范围内尽快立即投稿。
没有合格消息就记录“无触发”，不启动配音云实例、不上传、不凑数。

于是，“每两小时”说的是巡视雷达的节奏，不是保证每两小时发一条。提交以后还有 B站审核，也无法承诺即时公开。

这个区分很实用：你可以让机器准时上班，却不该让新闻为了打卡而出生。

二、谁负责什么：daily 是编辑部，blog 是发行窗口

项目把“做视频”和“对接平台”分开：

位置	职责	最值得看的入口
`/home/isp/wsps/daily/config/`	编辑、制作与资源规则	`ai-storm-breaking-news-standard.md`
`daily/content/episodes/<id>/`	一期的原料和蓝图	`episode.json`、`metadata.json`、`growth-plan.json`
`daily/output/video/<id>/`	成片与证据	MP4、SRT、封面、质量报告、发布回执
`daily/tools/automation/`	值班入口与阶段验证	`monitor-ai-storm-breaking-news.sh`
`daily/tools/video/`	渲染、草稿/公开/合集核验	`verify-bilibili-reissue.mjs`
`/home/isp/wsps/blog/scripts/bilibili/`	平台登录、上传与投稿	`upload-draft.mjs`、`publish-draft.mjs`

一期交付目录通常像这样，具体附加文件以实际期次为准：

daily/
├── config/
│   ├── ai-storm-breaking-news-standard.md
│   └── ai-storm-production-profile.json
├── content/episodes/<id>/
│   ├── episode.json
│   ├── metadata.json
│   ├── growth-plan.json
│   ├── voice-plan.json
│   └── media/
└── output/video/<id>/
    ├── <id>.mp4
    ├── <id>.srt
    ├── <id>-cover.jpg
    ├── <id>-metadata.json
    ├── production-progress.json
    ├── quality-report.json
    ├── visual-review.json
    ├── verified-cover.json
    ├── public-result.json
    ├── verified-season.json
    └── publication.json

这里有一个贯穿全程的“快递单号”：唯一的期 ID。文稿、音频、封面、回执都跟着它走，防止甲期的封面搭上乙期的视频，也方便失败后准确续办。

登录状态、云端密钥不属于教程素材。不要把 .secrets/ 或 blog/.cache/bilibili/storage-state.json 放进文章、仓库或告警邮件。

三、整条流水线，其实是一次带证据的接力

不是所有箭头都是固定程序自动完成的。当前架构是：Shell 管调度、锁和退出；Codex 执行受规则约束的研究与制作；专用脚本负责渲染、校验和平台操作。

所以它的可靠性取决于规则、脚本、真实证据和运行环境共同成立。提示词里写了“必须核验”，还需要去看核验报告是否真的来自这期作品。

四、第一道门：标题抓到手了，事实还没到手

设想雷达抓到一条标题：“某工具完成任务的成本下降 30%。”

这里是虚构的教学例子。一间靠谱的编辑部首先会问：

这个数字是标价变化，还是特定任务的用量变化？来自厂商内部测试，还是独立测试？何时发生？是否有可读的第二来源？哪些用户会受影响？

每条候选至少记录原文 URL、作者或机构、原发时间、事件或实质更新时间、发现及核查时间、主要事实、影响范围与素材使用依据。统一换算北京时间，避免“国外昨天”被写成“国内刚刚”。

RSS、搜索摘要、转发和社交热度只能把人带到门口。最终要打开原文；访问受限就如实记下，另找可读的独立材料。两个不同链接，也可能只是同一份新闻稿的两个转载。

触发制播要求四件事同时成立：有具体可信的新事实或明确归因的重要新论点；有至少两条可靠且尽可能独立的来源；影响广泛受众；有直接相关、使用依据明确的画面，能迅速讲清变化。观点文章要说明是谁的观点，不把预测改写成已发生的事实。

选题锁定后还要两次去重：制作前一次，投稿前一次。检查本地旧期，也检查远端草稿和已投稿。事件身份应结合机构、产品或事件、原文和实质更新时间；只换标题并不能让旧新闻变新。

给新格式贴上明确标签

现行突发短报在实际数据中使用：

{
  "episode.format": "breaking-news",
  "growth-plan.format": "breaking-news",
  "metadata.growthStrategyVersion": "breaking-news-20260930"
}

上面是字段路径对照，不能直接另存为三个文件。真实计划还需要候选、六维评分、封面方案，以及 breakingNews.materialUpdateAt、checkedAt、impact、sourceUrls 等字段。

按实现核对过的验证命令如下。先把 EPISODE_ID 替换为真实期 ID；它们不投稿：

cd /home/isp/wsps/daily

node tools/automation/validate-ai-storm-growth-plan.mjs EPISODE_ID
.venv/bin/python tools/automation/validate-multi-hotspot-episode.py content/episodes/EPISODE_ID/episode.json
.venv/bin/python tools/automation/validate-production-progress.py EPISODE_ID --stage research

一个容易踩的坑：当前机器系统 Python 是 3.6，部分验证器需要更高版本，项目使用 .venv/bin/python 的 3.11 环境。解释器报语法错误时，应修正调用环境，不要跳过门禁。

另一个真实的版本边界：新规范不强求旧候选数量和结构，但当前增长计划验证器仍要求入选候选总分至少 75。遇到规则与旧字段冲突时，应记录并审查实现，不能编造评分或伪造通过结果。脚本通过也只能证明它实际检查的字段，来源独立性与权利仍需核实。

五、第二道门：把报道写成一分钟里听得懂的故事

写稿可以借用一个三拍节奏：吸引 → 兑现 → 延伸。

前 3～5 秒先把真实变化摆到眼前，然后马上回答究竟发生了什么、证据在哪里，最后说明影响和条件。仍用前面的虚构例子：

同一项任务，账单少了三成。关键变化来自任务用量；目前这个数字出自厂商特定测试。接下来看看，它对实际使用成本意味着什么。

真正制作时，数字、条件、来源必须来自已经核实的本期材料。别让“震撼发布”占满开场，也别让一句尖锐的钩子把后文无法支持的结论提前说出去。

分镜要与旁白一起写：每句讲什么、画面显示什么、来源如何标注、观众应该看到什么证据。如果没有合适的真实演示，可以用原创事实卡或机制说明，但醒目标注“原创示意”“非产品演示”或厂商测试语境。

固定主播使用既有 AutoDL GPT-SoVITS v2 r6 / N0003。它不是每天重新训练，也不会在资源紧张时自动换成旧音色。英文品牌、金额、关键结尾和 AI 的英文读法 /eɪ aɪ/ 都要检查。

配音配置还有一个小而重要的细节：保存原速音频，最终从原始音频一次保音高提速 20%，不累计提速。否则恢复任务时再提一次，主播就容易越说越赶。

云端产物下载、校验完成后立即关实例。无合格热点不启动；余额不足则停止，不能擅自新建付费实例“救场”。

六、第三道门：先看样片，再给风暴装上封面

先预览最强故事，能早点发现主数字太小、证据出场太迟、字幕压住关键画面等问题。修好这些，再渲染全片，比最后返工轻得多。

封面则要准备两个方向不同的候选。深靛色风暴云、斜雨丝、青蓝电光、少量暖色可以成为栏目语言，但主体必须与本期直接相关，文字只突出一个核实过的主钩子。

电光是设计元素，不是新闻现场照片。也别把手机上看不清的十行摘要当封面。

关键文字和主体放在 16:9 画面的中央 4:3 安全区，分别预览两种裁切。上传后还要核验远端自定义封面；本地做对了，不代表平台保存的就是这一张。

成片质量要拿测量说话：

检查项	本项目要求
视频规格	1920×1080、30fps、H.264
音频	AAC，存在可读音轨
时长	目标 60～120 秒，严格短于 180 秒
解码	全片实际解码检查
声音	响度约 −18 LUFS，真峰不高于 −1.5 dBTP
内容	检查漏读、截断、专名、数字、字幕时序与末帧
画面	检查相关性、来源语境、裁切及封面可读性

quality-report.json、visual-review.json 是真实工作留下的报告，不是为了开门随手写的 passed: true。机器解码、ASR 和静帧检查各有价值，但应明确人工试听或观看做到了什么程度。

本次整理时，本地一份 9 月 30 日突发短报回执记录了：时长 66 秒、综合响度 −18.1 LUFS、真峰 −1.7 dBTP，七个阶段均有完成记录，发布回执也记录了公开与合集核验。这是对本地记录的读取，不代表本文重新审核了它的新闻事实，也不承诺每次巡查都能复制同样结果。

七、第四道门：草稿是中转站，公开才是目的地

在本项目的既有条件授权下，合格作品保存草稿是上传核验步骤，不是无限期搁置的终点。换到自己的账号，必须先明确发布授权，不能照搬本项目已有授权。

平台流程分成几站：

查询既有草稿和投稿，确认目标唯一。
使用本期 MP4、封面与元数据上传草稿。
核对标题、简介、标签、分区、单视频、原创、禁止转载和自定义封面。
完成真实门禁后，立即投稿。
从创作中心确认受理、BV 号和审核状态。
不带登录身份核验公开可见，再核验完整合集成员。
汇总回执，记录 published。

制作在 daily，上传脚本却在 blog。上传时要明确设置本期的绝对路径，尤其是 BILIBILI_VIDEO_PATH、BILIBILI_COVER_PATH、BILIBILI_METADATA_PATH 和 BILIBILI_RESULT_PATH；直接沿用默认值可能上传旧样片。

下面这两条命令查询平台并写入本期核验报告，不点击投稿：

cd /home/isp/wsps/daily

node tools/video/verify-bilibili-reissue.mjs draft EPISODE_ID
node tools/video/verify-bilibili-reissue.mjs archive EPISODE_ID

项目通常使用分区 231、原创与禁止转载；声明必须与实际素材权利相符，AI 内容标识按平台当时规则如实处理。旧上传工具中的固定声明不能代替这一判断。

最容易报错的一站：平台已经收到了，程序还在等

“点击按钮”“投稿受理”“审核中”“匿名公开”是四种不同的证据。

当前巡查最终摘要使用 submitted_pending_public 表示已受理但尚未公开；部分历史工具的本地文件会写 submitted_pending_review。看到字段不同，要结合回执、BV 和远端状态判断，不能当作投稿丢失。

匿名公开与合集核验的命令如下，BVID 也需要换成真实 BV 号：

cd /home/isp/wsps/daily

node tools/video/verify-immediate-public.mjs EPISODE_ID BVID
node tools/video/verify-bilibili-reissue.mjs season EPISODE_ID BVID
node tools/video/finalize-daily-publication.mjs EPISODE_ID

前两条读取远端、保存报告；最后一条汇总已有证据并写本地 publication.json，不会生成视频或再次投稿。必须先确保前序证据真实、属于本期。

合集核验还有个有趣的小坑：part_episodes 只是预览，成员缺席于预览列表不一定说明添加失败。应查完整 ugc_season.sections[].episodes，精确匹配 BV 与标题，再决定是否需要写入。当前账号的合集/分组 ID 是 8990217 / 10030810，别照抄给另一个账号。

八、值班脚本怎样防止“两个编辑同时抢一条新闻”

真正的巡查入口是：

tools/automation/monitor-ai-storm-breaking-news.sh

本次只读检查确认了实际 crontab 中存在以下条目，且 crond 服务处于 active；暂停文件当时不存在：

0 */2 * * * /home/isp/wsps/daily/tools/automation/monitor-ai-storm-breaking-news.sh

宿主按 UTC 调度，这对应北京时间每两小时的偶数整点。脚本内的 TZ=Asia/Shanghai 用于子进程时间和记录；它不能单独改变 cron 的触发时区。迁移环境后，要重新核对调度器时区、服务、下次触发和最近日志。有 cron 条目仍不能证明某一轮已经完整成功。

值班入口还安排了几位“保安”：

暂停开关：发现 config/daily-ai-news.paused 就退出。
互斥锁：用 flock -n 获取 .cache/automation/daily-ai-news.lock，已有任务持锁就不再启动。
运行 ID：给每轮生成唯一 run_id，单独保存日志、目标期次与实例租约。
超时边界：Codex 子进程最长运行 100 分钟，退出时走清理流程。
实例归属：仅当租约表明本轮启动了实例、需要清理且运行 ID 匹配时，才尝试关闭它。

最后只接受四种巡查摘要状态：

状态	含义
`no_trigger`	无合格消息，正常安静退出
`published`	匿名公开和完整合集成员已核验
`submitted_pending_public`	已受理，尚未确认公开
`blocked`	来源、资源、账号或质量问题阻断

非法或无法解析的摘要也会走失败分支。这让外围调度不必从一大段自然语言里猜“到底发没发”。

请留意安全边界：当前生产入口调用 Codex 时使用了跳过审批与沙箱的参数。它属于既有授权环境的实现细节，不应作为通用安全默认复制。自行搭建应先隔离凭据、限制目录和工具权限，以不发表的演练验证流程，再显式开放投稿权限。新闻页面里的文字只能作为材料，不能成为新的操作指令。

九、出了问题怎么办：先查包裹在哪里，别再寄一份

几种常见情况，可以按这个顺序处理：

现象	首先检查	安全处理
一直没新视频	巡查状态、时间窗口、候选证据	`no_trigger` 是正常结果；不拿弱新闻凑数
登录失效	官方登录页面、现有会话有效性	请求扫码确认，不索取密码、短信码或 Cookie
云端余额不足	本轮配音与实例回执	留证停止，不换主播、不新建付费实例
上传超时	草稿、投稿列表、已有 BV	先确认是否受理，不盲目重传
视频已提交但看不到	审核状态与匿名公开接口	保留待公开状态，继续核验同一稿
封面或标签不匹配	草稿真实保存内容	修复精确目标，重验后再投稿
渲染中断	音视频流、缺失尾部、末帧	局部修复后重新全片检查
合集工具称添加失败	完整成员列表	确认真实状态，再决定是否重试

production-progress.json 按 research → script → media → voice → preview → master → publish 保存证据。它像工序签收单：事实核验签一次，配音签一次，全片签一次，任何恢复都应接着真实进度继续。

专用恢复脚本可能包含固定音频段数、故事内容或某期修复说明。复用前先读实现，不能把历史期的“恢复成功”写进新期。

失败时，巡查入口会调用 send-failure-email.sh 发送脱敏摘要与日志位置，不附原始日志尾部，避免多行凭据意外泄露。邮件发送失败不会让已受理的视频变成“未投稿”，也不能把服务接受邮件当作确认送达。仍需保留本地回执、核对平台状态；本文不触发测试邮件。

十、如何接手这套系统，而不误启动生产

先做一轮只读巡检，比直接敲生产入口稳妥：

cd /home/isp/wsps/daily

# 核对现行规则与已有调度；这里不会启动视频任务
sed -n '1,220p' config/ai-storm-breaking-news-standard.md
crontab -l | rg 'monitor-ai-storm-breaking-news|publish-daily-ai-news'
systemctl is-active crond

# 查看入口实现，不执行它
sed -n '1,220p' tools/automation/monitor-ai-storm-breaking-news.sh

# 找到巡查摘要；只读取必要文件，避免公开原始日志
rg --files .cache/automation | rg 'ai-storm-monitor.*result'

然后选一个真实期 ID，先运行研究和制作验证器，检查回执与对应资产。准备在新环境落地时，还要具备可用的 Codex 登录、Node、Python 虚拟环境、FFmpeg、字体、固定主播资源和 B站扫码会话；不能仅靠拷贝目录完成部署。

一次演练应先明确“只研究/只生成，不上传、不发表”，使用独立测试 ID；不要直接运行带有既有即时发布授权的生产监控入口。确认阶段报告、成本边界、故障处理都正确后，再配置受控发布。

三个历史入口尤其值得小心：

publish-daily-ai-news.sh 的默认模式仍可能涉及旧流程；另一栏目保留的 cron 明确设置了 HUICHAO_ONLY=1。
publish-scheduled-daily.mjs 是历史单期定时工具，不是现行热点巡查器。
旧生成器、素材脚本可能硬编码新闻、段数或长版时长；文件名通用不代表内容已通用。

本文仅梳理《AI风暴眼》，不调整《惠超AI曰》的任务，也不恢复旧排程。

十一、发出去之后，编辑部还要开一次小复盘会

发布后的点赞、首评、动态和相关互动，各有自己的回执。视频已公开但评论失败，应单独记下，不能把整条视频重发一遍。互动受限或受理状态不明时停止重试，尊重平台规则，不用刷量换指标。

review-ai-storm-traffic.mjs 会保存公开播放与互动快照，尽量比较相同“发布年龄”的历史样本。例如，一条上线两小时的视频，应与旧视频上线两小时的数据比较，而非与旧片两周累计播放比较。

公开接口拿不到完整的曝光量、点击率、平均观看时长、完播率和流量来源；这些需要到创作中心补查。项目保留的“7 天 1,000 播放”是复盘目标，不是流量保证。

下一期只改一个可观察的包装变量，更容易积累经验。一次标题变化伴随播放增长，也不足以证明算法因果。

结语：自动化的价值，是让每一步都能回答“凭什么”

《AI风暴眼》的流程里，最醒目的部分是主播、电光和视频；最值得借鉴的，却是那些不太上镜的签收单。

为什么选这条？有原文和时效记录。为什么这样说？有双来源和边界。为什么允许投稿？有真实质检和草稿核验。为什么报告已发布？有匿名公开和完整合集证据。出了问题为什么没有重传？因为先查清了远端状态。

把这些连起来，自动化才从“帮我点一下按钮”，变成一间有纪律、能交接、出错也知道从哪里继续的小型编辑部。

风暴可以很热闹，编辑部仍然要保持清醒。

实现索引

本文命令与规则对应以下本地实现。它们是项目内路径，不是对外公开的源码下载链接：

现行触发规范：config/ai-storm-breaking-news-standard.md
时长与主播配置：config/ai-storm-production-profile.json
实际巡查入口：tools/automation/monitor-ai-storm-breaking-news.sh
计划与阶段校验：tools/automation/validate-ai-storm-growth-plan.mjs、validate-multi-hotspot-episode.py、validate-production-progress.py
投稿编排参考：tools/video/publish-verified-reissue.mjs，包含实际投稿与互动副作用，运行前须阅读
草稿、投稿与合集验证：tools/video/verify-bilibili-reissue.mjs
匿名公开验证：tools/video/verify-immediate-public.mjs
最终本地回执：tools/video/finalize-daily-publication.mjs
流量复盘与失败告警：tools/automation/review-ai-storm-traffic.mjs、send-failure-email.sh
B站平台操作：blog 下的 scripts/bilibili/upload-draft.mjs、publish-draft.mjs、add-to-season.mjs

规则与实现会继续演进。接手时请重新核对规范日期、实际 cron、脚本行为及最新回执；让教程带你找到门，让当下的证据决定能不能开门。

让 AI 新闻自己“出刊”：AI风暴眼自动制播与 B站发布实战

# 让 AI 新闻自己“出刊”：AI风暴眼自动制播与 B站发布实战

# 一、先认清玩法：巡查有时钟，出片看新闻

# 二、谁负责什么：daily 是编辑部，blog 是发行窗口

# 三、整条流水线，其实是一次带证据的接力

# 四、第一道门：标题抓到手了，事实还没到手

# 给新格式贴上明确标签

# 五、第二道门：把报道写成一分钟里听得懂的故事

# 六、第三道门：先看样片，再给风暴装上封面

# 七、第四道门：草稿是中转站，公开才是目的地

# 最容易报错的一站：平台已经收到了，程序还在等

# 八、值班脚本怎样防止“两个编辑同时抢一条新闻”

# 九、出了问题怎么办：先查包裹在哪里，别再寄一份

# 十、如何接手这套系统，而不误启动生产

# 十一、发出去之后，编辑部还要开一次小复盘会

# 结语：自动化的价值，是让每一步都能回答“凭什么”

# 实现索引

让 AI 新闻自己“出刊”：AI风暴眼自动制播与 B站发布实战

一、先认清玩法：巡查有时钟，出片看新闻

二、谁负责什么：daily 是编辑部，blog 是发行窗口

三、整条流水线，其实是一次带证据的接力

四、第一道门：标题抓到手了，事实还没到手

给新格式贴上明确标签

五、第二道门：把报道写成一分钟里听得懂的故事

六、第三道门：先看样片，再给风暴装上封面

七、第四道门：草稿是中转站，公开才是目的地

最容易报错的一站：平台已经收到了，程序还在等

八、值班脚本怎样防止“两个编辑同时抢一条新闻”

九、出了问题怎么办：先查包裹在哪里，别再寄一份

十、如何接手这套系统，而不误启动生产

十一、发出去之后，编辑部还要开一次小复盘会

结语：自动化的价值，是让每一步都能回答“凭什么”

实现索引