mcpField
L
launch-monitor

launch-monitor

github.com/nimbleway营销与增长6140 次安装2 天前更新
代码仓库

关于 launch-monitor

launch-monitor 技能用于跟踪产品发布期间的媒体、社交平台、社区和竞争对手反应。它对信号分类，识别失实报道与情绪变化，并为发布团队建议响应行动。

主要功能

  1. 01监测媒体、社交平台和社区提及
  2. 02跟踪竞争对手回应
  3. 03标记不准确的产品说法
  4. 04分类紧急程度和响应行动
  5. 05跟踪情绪随时间的变化
  6. 06与既有报告去重

适用场景

  1. 01监测产品发布后的报道
  2. 02发现并纠正失实发布信息
  3. 03跟踪新出现的竞争对手反应
  4. 04发现发布期间的情绪变化

MCP 相关

该技能可在会话开始时选择 CLI 或 MCP 传输方式，并运行 Nimble 预检调用。输入未说明其提供的 MCP 服务端能力。

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/nimbleway/agent-skills --skill launch-monitor

安装后在 Claude Code 中输入/launch-monitor确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

references/
memory-and-distribution.md
nimble-playbook.md
profile-and-onboarding.md
sources.md
template.html

详细介绍

发布监测

从发布当天起监测媒体报道、社交媒体和社区论坛——追踪情绪、标记不实描述、发现竞争对手的回应，并推荐行动方案，助你快速响应。

引导消息

当此技能在某个会话中首次触发时，发送此消息。每个会话仅发送一次，并且必须在询问任何设置问题之前发送。即使用户在开场消息中已经提到产品，也不要跳过此消息——引导流程会说明此技能会收集哪些信息，以及如何运作。

👋 发布监测已就绪。

此技能会在产品发布前后监测媒体报道、社交媒体、开发者社区和竞争对手渠道——追踪情绪、标记不实描述、发现竞争对手的回应，并明确告诉你该回应什么以及如何回应。

如需开始，只需说： “监测 [产品名称] 的发布情况”

或者试试：

  • “追踪自我们昨天宣布 [产品] 以来的报道”
  • “大家对我们的 [产品] 发布反应如何？”
  • “标记我们关于 [产品] 的媒体报道中的不实描述”
  • “竞争对手对我们的 [产品] 发布有何回应？”

要我保存你的偏好，以便下次跳过这些问题吗？

预检

按照 references/nimble-playbook.md 中的传输方式选择和标准预检流程操作：在会话开始时选择 CLI 或 MCP，然后同时运行并行预检调用（日期、个人资料、记忆索引）。每次 Nimble CLI 调用都要添加标签：nimble --client-source nimble-agent-skills <subcommand>。

从个人资料（~/.nimble/business-profile.json）中加载产品和品牌背景信息，以及 last_runs.launch-monitor，用于确定日期范围。预先填写设置问题，让用户确认，而不是重新输入。如果个人资料不存在，请遵循 references/profile-and-onboarding.md 中的首次运行引导流程，并在首次运行后创建一个初始配置文件。

如何开始

在询问任何问题之前，先快速完成两项研究：

步骤 A — 自动确认其他名称： 搜索用户提到的产品，找出所有其他名称、代号、版本名称和相关搜索词。不要向用户询问。利用找到的信息，为步骤 1 构建全面的搜索词列表。

  • 搜索："[product name]" official name OR "also known as" OR codename OR version
  • 对于 Apple 产品，务必查找内部代号、型号和营销名称的不同写法
  • 对于软件：查找 GitHub 仓库名称、API 名称和 SDK 名称
  • 将所有已确认的变体悄悄加入搜索查询——用户无需知道这一步

步骤 B — 自动确认发布日期： 在询问用户之前，先搜索产品的发布时间。告知用户找到的信息，并请用户确认或更正。

  • 搜索："[product name]" launch date OR announced OR "available now" OR "shipping today"
  • 如果找到明确日期，请向用户提供该日期以供确认
  • 如果找到多个相互矛盾的日期（公告日期与正式发布日），请同时说明并询问应采用哪个时间范围

然后在一条消息中询问：

"开始前——我想确认几件事：

  1. 发布日期： 我查到 [product] 于 [DATE YOU FOUND] 发布——这是我开始监测时应采用的日期吗？还是其他日期？
  2. 时间范围： 从该日期往前追溯多久？（默认：从发布日到现在）
  3. 深度： 快速扫描（更快）还是深度检索（更全面、来源更多）？（默认：深度检索）
  4. 竞争对手： 我会默认监测竞争对手的回应——有没有要优先关注或排除的特定竞争对手？"

输出始终是在 Claude 中直接呈现的 Response War Room。 不要询问格式或输出选项。

例外情况——完全跳过询问：

  • 用户在初始消息中已提供以上所有信息
  • 用户在本次会话中之前运行过此技能（使用先前的配置）

用户说“直接运行”时使用以下默认值：

  • 时间范围：从发布日到现在
  • 深度：深度检索
  • 竞争对手：开启（根据上下文分析自动识别）

消除歧义： 如果研究后产品名称仍有歧义，请先确认再继续：

"确认一下——你说的 [product] 是指 [Option A] 还是 [Option B]？"

步骤 0 — 上下文分析（在任何搜索前执行）

搜索前，分析产品特征，以调整所有查询：

  1. 这是什么类别？（开发者工具、消费级应用、企业 SaaS、硬件、API 等）
  2. 它属于哪个生态系统？（例如 Claude/Anthropic、AWS、Salesforce、开源）
  3. 目标受众是谁？（开发者、PM、企业买家、消费者）
  4. 发布时提出了哪些关键主张？（从用户描述或快速搜索公告中提取）
  5. 怎样的描述会构成误述？（类别错误、定价错误、能力错误、比较对象错误）

利用此分析：

  • 定位合适的社群和媒体
  • 构建精准的搜索查询，以找到真实报道而非噪声
  • 确定准确的产品定位，以便准确标记误述
  • 了解竞争对手的回应可能是什么样

步骤 1 — 信号扫描

并行运行以下所有查询。发现阶段使用 --search-depth lite。仅在提取完整文章或讨论串内容时切换到 --search-depth deep。为每次调用添加标签：nimble --client-source nimble-agent-skills search ...

媒体与评论文章
  • "[product name]" site:techcrunch.com
  • "[product name]" site:theverge.com
  • "[product name]" site:wired.com
  • "[product name]" site:arstechnica.com
  • "[product name]" site:venturebeat.com
  • "[product name]" site:siliconangle.com
  • "[product name]" site:theregister.com
  • "[product name]" site:zdnet.com
  • "[product name]" "[company name]" announcement OR launch OR release
  • 特定类别的媒体（例如，开发者工具：InfoQ、SDTimes；AI：The Information、Import AI）
社交媒体与社区

运行以下所有查询——社交媒体上的消息传播速度比新闻媒体快。使用 Nimble 的 focus:"social" 扩大平台覆盖范围。各平台的完整查询模式，请参阅 references/sources.md Tier 2b。

Reddit（针对多个子版块分别查询，而不只是使用宽泛查询）：

  • "[product name]" site:reddit.com — 宽泛查询
  • "[product name]" site:reddit.com/r/[category] — 类别子版块
  • "[product name]" site:reddit.com/r/[company] — 品牌子版块
  • "[product name]" site:reddit.com/r/technology 和其他相关子版块
  • Nimble 社交媒体焦点：使用 focus:"social" 查询 "[product name]" reddit

X / Twitter：

  • "[product name]" site:x.com
  • "[product name]" wrong OR broken OR disappointed site:x.com — 搜寻投诉
  • "[product name]" "actually" OR correcting site:x.com — 搜寻纠正信息的讨论串
  • 查看官方发布推文的引用推文

LinkedIn：

  • "[product name]" site:linkedin.com
  • "[product name]" launched OR "my take" site:linkedin.com

Instagram：

  • Nimble 社交媒体焦点：使用 focus:"social" 查询 "[product name]" instagram
  • 关注信号：网红帖子、品牌账号互动、消费者反馈

TikTok：

  • Nimble 社交媒体焦点：使用 focus:"social" 查询 "[product name]" tiktok review OR reaction
  • 关注信号：48 小时内走红的反应视频；评论情绪

YouTube：

  • "[product name]" review OR reaction OR "first impressions" site:youtube.com
  • "[product name]" problems OR issues site:youtube.com

Facebook / Threads：

  • Nimble 社交媒体焦点：使用 focus:"social" 查询 "[product name]" facebook OR threads

Hacker News：

  • "[product name]" site:news.ycombinator.com
  • 也可搜索：hn.algolia.com/?q=[product+name]&dateRange=last24h

开发者社区：

  • "[product name]" site:dev.to
  • "[product name]" site:medium.com
开发者社区（如适用）
  • "[product name]" site:stackoverflow.com
  • "[product name]" site:github.com — 问题、讨论和反馈
  • "[product name]" site:discord.com OR discord community
  • "[product name]" site:hashnode.com
竞争对手监测（如已启用）
  • [competitor A] "[product name]" OR "[category]" — 对方如何回应？
  • [competitor A] announcement OR response OR "compared to" — 是否发布了反制公告？
  • 查看竞争对手的社交账号和博客，了解其定位策略
  • 搜索自发布之日起发布的 "[competitor] vs [product name]" 内容
错误描述排查

运行有针对性的查询，以找出错误信息：

  • "[product name]" "[wrong claim to watch for]"
  • "[product name]" pricing OR price — 检查价格信息是否准确
  • "[product name]" vs "[wrong comparison]" — 是否与错误对象进行比较？
  • "[product name]" "[capability it doesn't have]" — 检查能力描述是否被夸大或弱化

步骤 2 — 信号分类

为发现的每条信号指定：

紧急程度：

  • 🔴 立即行动 — 错误描述正在病毒式传播、大范围负面报道、竞争对手发布反制公告、危机信号
  • 🟡 持续关注 — 新出现的负面主题、中等传播范围的不实报道、竞争对手定位内容
  • 🟢 良好信号 — 准确的正面报道、自发热情、开发者采用信号
  • ⬜ 噪声 — 无关提及、名称相似但无关的产品、垃圾信息

行动标签：

  • RESPOND — 需要直接公开回应（推文、评论、媒体联络）
  • CORRECT — 需要更正或澄清（私信、评论、媒体说明）
  • AMPLIFY — 值得分享、转发或借势扩展
  • ESCALATE — 需要上报给公关、法务或领导层
  • WATCH — 暂无行动，但需持续跟踪，以便升级处理
  • IGNORE — 已过滤的噪声

信号类型：

  • 媒体报道 · 社区讨论 · 社交媒体提及 · 竞争对手动向 · 错误描述 · 流失信号 · 影响者观点 · 开发者反应 · 分析师评论

来源 URL — 每条信号都必须提供： 每条信号都必须包含 Nimble 为相应文章、讨论串或帖子返回的确切 URL。此 URL 会生成每张卡片上可点击的 ↗ 来源链接。首页 URL 对用户毫无用处。

正确 — 确切的文章／讨论串／帖子 URL：

  • https://techcrunch.com/2026/06/11/nimble-mcp-connector-launch
  • https://news.ycombinator.com/item?id=12345678
  • https://reddit.com/r/MachineLearning/comments/abc123/is_nimble_just_another_scraper
  • https://x.com/[username]/status/[POST_ID]

错误 — 绝不可使用以下 URL：

  • https://techcrunch.com
  • https://news.ycombinator.com
  • https://reddit.com
  • https://x.com

使用 Nimble 在搜索结果中返回的原样 URL。不得编造 URL。

步骤 3 — 错误描述分析

对于每条存在错误的报道，提取：

  1. 说法 — 原文具体说了什么
  2. 来源 — 媒体、作者、预计传播范围、日期
  3. 错误之处 — 具体的不准确之处
  4. 准确信息 — 正确的表述是什么
  5. 传播风险 — 是否有其他来源跟进？（搜索引用错误说法的二次报道）
  6. 建议回应 — Claude 建议的一句话更正

步骤 4 — 情绪变化速度

跟踪发布以来情绪随时间的变化趋势：

  • 将时间窗口划分为多个区间（例如，前 24 小时按小时统计，此后按天统计）
  • 对每个区间统计正面、负面和中性信号
  • 找出转折点 — 情绪何时达到峰值？何时发生转变？
  • 标记任何变化速度激增 — 提及量突然增加（正面或负面）

记忆去重（过滤已知信号）

生成输出前，根据 references/memory-and-distribution.md 中的去重流程，对照 ~/.nimble/memory/reports/ 中以往的发布监测报告进行去重。

本技能专属规则：

  • 指纹： {url, signal_type, published_date} — 规范化 URL（去除查询参数和末尾斜杠）。
  • 再次出现的信号，紧急程度已变化： 保留在信息流中，并标记 ↩ returning · urgency changed 徽标。
  • 已知且无变化： 从“立即行动”／“持续关注”部分中隐藏；仅在用户要求查看完整历史记录时才列入附录。
  • 摘要行： 在作战室顶部显示：X net-new · Y returning (urgency changed) · Z suppressed。
  • 持久化： 本次运行后，将信号指纹保存到 ~/.nimble/memory/reports/launch-monitor-{YYYY-MM-DD}.md，并根据 references/memory-and-distribution.md 在 log.md 中追加一条记录。

输出模板（必需）

生成 HTML 输出时，Claude 必须严格遵循 references/template.html。加载模板，将占位符替换为实际研究数据，并保持所有 CSS、JS 和交互模式完全一致。

必需的响应结构

每次发布监测响应都必须按以下顺序组织：

  1. ## TL;DR——始终作为第一个部分。用两到三句话概述整体情绪判断（正面 / 混合 / 负面 / 趋势变化）、需要立即采取行动的事项数量，以及最紧急的信号或错误表述。示例：“最初 48 小时的情绪喜忧参半、偏负面，有 5 项需要立即采取行动。主要风险是‘Gemini 换皮’的说法正在 HN 和媒体中扩散。目前有 3 项错误表述，其中 2 项正在传播。”
  2. 内嵌的 Response War Room 小组件——按照下方顺序，紧接 TL;DR 呈现。
  3. ## What This Means——始终作为最后一个部分。用两到三句话综合说明信号模式对发布走势的意义，以及团队此刻最应采取的行动。
呈现方式——始终优先内嵌（生成输出前请先阅读）

Response War Room 是一个必须在聊天中内嵌呈现的交互式小组件。可下载文件只是次要产物，绝不能作为主要交付内容。每次运行都必须严格遵循以下顺序：

  1. 首先在聊天中内嵌呈现 war room。 使用 Write 工具将完整填充内容的 launch-monitor-{YYYY-MM-DD}.html 写入 ~/.nimble/，然后在对话中直接输出 HTML 内容，让用户立即看到交互式小组件。这份内嵌输出是主要交付内容，必须先于其他任何内容提供。
  2. 然后才能提供下载。 内嵌小组件显示后，确认 ~/.nimble/launch-monitor-{YYYY-MM-DD}.html 和 ~/.nimble/launch-monitor-{YYYY-MM-DD}.md 已保存，并向用户提供下载或分享选项。

硬性规则：

  • 绝不能只回复下载链接或只提供文件。如果用户看到了文件，却没有看到内嵌的 war room，本次运行就没有完成首要任务。
  • 不要询问用户想要内嵌呈现还是文件，也不要询问格式——默认始终内嵌呈现，并且始终同时提供文件。
  • 内嵌小组件与可下载的 HTML 是同一份产物——必须呈现完全相同的模板，不得提供精简版的内嵌内容。

如果确实无法内嵌输出：

  1. 用一行简短说明原因——例如：“这次无法在聊天中内嵌呈现 war room，因此改为提供文件。”
  2. 确认文件已保存到 ~/.nimble/launch-monitor-{YYYY-MM-DD}.html，作为备用方案。

如果无法内嵌呈现，绝不要默默改为只提供下载——必须明确说明失败，以便用户知道这是环境限制，而非预期行为。

输出模板规范（launch-monitor-{YYYY-MM-DD}.html）

Response War Room 具有区别于其他所有技能的独特视觉风格：

  • 浅色背景，使用 CSS 变量——继承宿主主题，同时兼容浅色和深色模式
  • 等宽字体点缀用于信号元数据——营造实战操作感，而非报告感
  • **颜色系统：**紧急程度使用红色 #A32D2D / 琥珀色 #854F0B / 绿色 #3B6D11——与 CSS 变量调色板相匹配
  • 紧凑、密集的布局——营造作战室氛围，而非仪表板氛围
  • 来源链接：<a href="[EXACT_NIMBLE_URL]" class="src-link">↗ source</a>——颜色为 #185FA5，无边框、无背景；点击监听器绑定在 sc-top（而非 sc）上，以便链接能够正常打开

必需部分及其顺序：

0. 发布页眉栏 全宽栏，显示：产品名称 · 发布日期 · 距发布已过时间 · 找到的信号总数 · 上次更新时间

1. 情绪变化速度图表 小型折线图（非柱状图），显示自发布以来各时间段的信号量，分别以正面（绿色线）和负面（红色线）表示。X 轴 = 时间间隔。Y 轴 = 信号数量。鼠标悬停在数据点上时显示数量及该时段的热门信号。点击数据点可将信号动态列表筛选为对应的时间段。 2. 信号动态 — 战情室 主面板。信号卡片以响应式网格排列，可按可用宽度显示 2–3 张卡片（自动填充列数，而不是强制固定数量，因此动态信息流始终紧凑，不会折叠成单列长列表）。卡片按紧急程度排序（先 🔴，再 🟡，最后 🟢）。每张卡片显示：

  • 顶行：紧急程度圆点 + 操作徽标 + 类型标签 + 展开箭头（都位于 .sc-header 中的同一行）
  • 标题（字号 12px，字重 500）
  • 单行背景信息（字号 11px，弱化显示）
  • 底行：元数据 + ↗ 来源链接 — 使用 margin-top:auto 和顶部边框固定在卡片底部，使同一行的所有卡片在视觉上对齐
  • 展开后显示建议操作 — 点击卡片展开（点击监听器位于 .sc-top，而不是 .sc，因此点击来源链接时不会触发展开）

网格布局 CSS： .feed { display:grid; grid-template-columns:repeat(auto-fill,minmax(215px,1fr)); gap:8px } — auto-fill 会尽可能排列约 215px 宽的列（在常见渲染宽度下每行排列 2–3 列），让动态信息流保持精简。不要改回固定的 repeat(2,...)，否则在窄屏宽度下可能折叠成单列。 .no-sigs 跨越两列： grid-column:1/-1

动态信息流上方的筛选栏：

  • 主要筛选：视图标签 — 全部 / 🔴 立即行动 / 🟡 监控 / 🟢 良好 / 误传。 — 与可点击的统计卡片同步
  • 次要筛选：折叠的“细化”按钮 → 展开包含操作类型 + 信号类型选项的面板
  • 活跃筛选条件显示为可关闭的标签，并提供“全部清除”

所有筛选条件会叠加生效。信号数量实时更新。“无匹配信号”空状态横跨全宽。

3. 误传追踪器 专用面板 — 仅在发现误传时显示。采用两列布局：

左列：声明（说了什么、来源、传播范围） 右列：更正（准确信息 + 建议回复文本）

每行都有一个 COPIED 按钮，可将建议更正内容复制到剪贴板。状态徽标：SPREADING（正在被转发时）/ CONTAINED（仅来自单一来源时）/ CORRECTED（已处理时）。

4. 竞争对手响应面板 仅在启用竞争对手监控时显示。每个竞争对手显示一张卡片，包含：

  • 竞争对手名称
  • 对方采取的行动（发布内容、发推文、发布反制公告、保持沉默）
  • 紧急程度评估
  • 建议的应对措施

5. 覆盖情况摘要 精简统计行：信号总数 · 媒体提及 · 社区帖子 · 社交媒体提及 · 误传 · 竞争对手行动 · 平均情绪分数

交互要求（JS 点击处理器 — 绝不使用 CSS 悬停）：

  • 信号卡片：点击展开/折叠建议操作文本
  • 传播速度图表：点击数据点，将动态信息流筛选为对应时间段
  • 筛选按钮：三行筛选条件彼此独立，叠加生效
  • 误传复制按钮：将更正文本复制到剪贴板
  • 所有筛选条件都会实时显示匹配信号数量

样式：

  • 背景：var(--color-background-primary) — 外层透明，继承宿主样式
  • 卡片背景：var(--color-background-primary)，边框为 0.5px solid var(--color-border-tertiary)
  • 区块背景：var(--color-background-secondary)
  • 文本：var(--color-text-primary) / var(--color-text-secondary) — 不要使用硬编码颜色
  • 等宽字体：元数据字段使用 'SF Mono', 'Fira Code', monospace
  • 紧急程度颜色：红色 #A32D2D · 琥珀色 #854F0B · 绿色 #3B6D11
  • 操作徽标颜色：RESPOND/ESCALATE 使用红色调 · CORRECT 使用琥珀色调 · AMPLIFY 使用绿色调 · WATCH 使用灰色调
  • 来源链接：color: #185FA5 — 使用内联 <a href> 标签，不加边框或背景
  • 任何地方都不要使用硬编码的深色背景
Markdown 输出规范 (launch-monitor-{YYYY-MM-DD}.md)
# Launch Monitor — [Product Name]
**Launch date:** [DATE]
**Monitored window:** [DATE RANGE]
**Generated:** [TIMESTAMP]
**Total signals:** [N]

## TL;DR
[2-3 sentences: overall sentiment read, count of act-now items, single most urgent signal or mischaracterization]

## Summary
- Act now: [N] | Monitor: [N] | Good signals: [N] | Noise: [N]
- Mischaracterizations found: [N]
- Competitor moves: [N]
- Overall sentiment: [Positive / Mixed / Negative / Trending negative]

## Signal Feed

### 🔴 Act Now
- **[RESPOND/CORRECT/ESCALATE]** | [Signal type] | [Headline]
  Context: [One sentence]
  Source: [outlet] · Reach: [estimate] · [Time since launch]
  Action: [Suggested action]

### 🟡 Monitor
...

### 🟢 Good Signals
...

## Mischaracterizations
| Claim | Source | Reach | Correct version | Status |
|---|---|---|---|---|
| [What was said] | [Source] | [Reach] | [Accurate version] | SPREADING/CONTAINED |

## Competitor Moves
- **[Competitor]:** [What they did] — [Suggested counter-move]

## Source Index
- [URL] | [Source] | [Date] | [Urgency] | [Action]

## What This Means
[2-3 sentences: what the signal pattern implies for launch trajectory; the single most important action for the team to take right now]

已保存的偏好

完成引导后，询问一次：

“是否要保存你的偏好设置，以便下次跳过这些问题？你随时可以说 ‘更改设置’ 来更新任何内容。”

存储：产品名称、主要竞争对手、发布窗口偏好、详细程度设置。

分发

内联呈现输出并保存文件后，按照 references/memory-and-distribution.md 提供分享选项（连接器检测、AskUserQuestion 流程、Notion/Slack 选项）。

此技能的路由规则：将 launch-monitor-{YYYY-MM-DD}.md 推送到 Notion（完整报告）；仅将「立即行动」信号发布到 Slack。若 ~/.nimble/business-profile.json 中的 integrations 已设置，则使用其中的目标位置；否则询问用户并保存，以便下次使用。

重新运行行为

计算日期窗口时，遵循 references/nimble-playbook.md 中的 Smart Date Windowing 模式——使用配置文件中的 last_runs.launch-monitor。

如果用户要求重新运行或刷新监测：

“我会从[上次运行时间戳]开始扫描新信号，并更新作战室。观察名单上还有什么要新增的吗？”

仅呈现上次运行后出现的新信号。保留尚未解决的错误描述和待处理事项。

相关技能——后续步骤

交付作战室报告后，在 ## 这意味着什么 部分建议相关的后续步骤：

  • 持续品牌监测： 活跃发布窗口结束后（通常为发布后 2–4 周），建议将任务移交给 brand-mention-monitor，持续追踪品牌健康状况——它针对稳定阶段的监测进行了优化，而非发布期间的流量高峰。
  • 竞争对手跟进： 如果竞争对手在发布窗口期间采取了重大行动，建议使用 competitor-intel，开展更深入、持续的竞争情报分析——它会追踪信息传达、定位变化以及随时间推移形成的反叙事。
  • 消费者情绪： 如果产品面向消费者，且早期使用数据正在累积，建议使用 consumer-sentiment-monitor，追踪真实用户对产品的体验，超越发布期的媒体报道。

重要性门槛

跳过以下信号：

  • 明显涉及同名的其他产品（通过上下文分析过滤）
  • 自动化机器人或垃圾账号
  • 没有新信息的重复报道（通讯社稿件转载）
  • 传播潜力有限、触达量仅为个位数的内容

标记但不优先处理：

  • 准确描述产品的中性报道
  • 无需采取行动的正面信号

评论

支持 Markdown