用途：在产品发布公开后到报道热度消退（通常两到四周）期间，持续监测媒体、社交和开发者社区的声音，产出分诊式“作战室”报告，让团队知道该回应、纠正、放大还是上报什么，并按此优先级处理。
主要能力：先静默解析产品的代号、旧名、版本名、API/SDK/仓库名和模型标识等别名，并从证据确认发布日期；随后对产品做画像（品类、生态、受众、发布主张、可能被误读的点）。每轮并行搜索媒体、社区、社交、竞品四个方向，并持续运行“误读猎取”查询。每个信号打上紧急程度（act now / monitor / good signal / noise）、行动标签（RESPOND、CORRECT、AMPLIFY、ESCALATE、WATCH、IGNORE）、信号类型和精确 URL。对错误报道提取六字段误读记录，并做二次搜索判断传播状态（SPREADING / CONTAINED / CORRECTED）。还统计情感速度，按小时或按天分区间计数，识别拐点与突增。
使用方式：启用前需替换 {{ALERTS_CHANNEL}}（act-now 项上报渠道）和 {{COMMS_OWNER}}（上报接收人）。首次扫描前先做别名解析与发布日期确认，再一次性确认发布日期、回溯窗口（默认发布至今）、深度（默认 deep）和竞品范围。报告固定格式：先 TL;DR，再按固定章节写作战室正文，最后“What this means”。重跑节奏为发布后前 6 小时每 1–2 小时一次，到 24 小时每 3–4 小时一次，之后每天一两次。每次运行前加载该发布的运行文件去重，指纹为 {url, signal_type, published_date}，URL 需规范化。
适用场景：产品发布后的舆情与社区监测、错误信息纠正、竞品对比跟踪、情感走势判断。
限制：所有建议回应和更正都只是草稿，未经人工明确批准不得公开发布或发送；每个信号必须带搜索返回的精确文章/帖子 URL，不得用首页或编造 URL；无证据不得声称传播或给出触达数字；不得把准确的中性报道当作问题；不得把通讯社转载计为多个信号。具体来源清单、分诊细则和报告格式规范在 references/sources.md、references/triage.md、references/report-format.md 中，资料未提供其内容。