marketing-social-listening

前言（先运行）

_KS_REPO=""
_KS_REAL_SKILL="$(cd "$HOME/.claude/skills/marketing-social-listening" 2>/dev/null && pwd -P || true)"
for _candidate in \
  "${KAITO_SKILLS_DIR:-}" \
  "$( [ -n "$_KS_REAL_SKILL" ] && cd "$_KS_REAL_SKILL/../.." 2>/dev/null && pwd -P || true )" \
  "$HOME/kaito-skills" \
  "$HOME/.kaito-skills/repo"
do
  [ -n "$_candidate" ] || continue
  if [ -f "$_candidate/skills.json" ] && [ -x "$_candidate/bin/kaito-skills-update-check" ]; then
    _KS_REPO="$_candidate"
    break
  fi
done

if [ -n "$_KS_REPO" ]; then
  echo "KAITO_SKILLS_REPO $_KS_REPO"
  _UPD=$("$_KS_REPO/bin/kaito-skills-update-check" 2>/dev/null || true)
  [ -n "$_UPD" ] && echo "$_UPD" || true
fi

如果输出显示 KAITO_SKILLS_REPO <path>，请记住该路径为 KAITO_SKILLS_REPO。

如果输出显示 UPGRADE_AVAILABLE <old> <new>，请阅读 <KAITO_SKILLS_REPO>/docs/update-kaito-skills.md，并在继续之前按照“Inline upgrade flow”操作。如果用户选择稍后提醒或停用更新检查，请使用当前技能继续。

如果输出显示 JUST_UPGRADED <from> <to>，请告知用户 Running kaito-skills v{to} (just updated!)，然后继续。

社交舆情监听

使用此技能执行重新设计的热点社交舆情监听工作流。

输入

• token：项目名称、代币代码或已解析的 Kaito 代币值；仅当上游工作流已提供 unresolved_string 和已确认的 official_handle 时才可选
• official_handle：可选的预先提示；每当最终确定未解析模式时都必须提供
• unresolved_string：来自 shared-entity-resolution 的可选预构建关键词字符串；仅当它已附带已确认的 official_handle 时才使用
• duration：24h、48h、7d、30d、90d，或包含 start 和 end 的明确过去时间范围
• focus_mode：preset 或 custom（默认为 preset）
• preset_topics：可选的多选项。默认为所有当前预设主题：
  • Engagement opportunities
  • Risk watch
  • Key voices
  • Emerging narratives
  • Product discussion
  • Market discussion
  • Bugs & issues
  • Competitor comparisons
  • Questions & evaluation
  • Feature requests
• custom_topic_focus：仅在 focus_mode="custom" 时使用的可选自由文本
• excluded_handles：可选的排除集合；在规范官方账号和关联账号已知时，应将它们合并到该集合中。对于未索引回退模式，通常仅包含已确认的官方账号
• max_tweets：固定为 100

工作流

将工作流组织为四个阶段：Resolve Entity、Data Gathering、Analysis 和 Output。

1. 解析实体

在获取任何推文之前，先解析项目身份、排除集合和精确的分析时间窗口。

除非上游工作流已提供确认过的未解析身份包，否则首先使用 shared-entity-resolution。

• 如果已提供 unresolved_string 和确认过的 official_handle，则将这对值视为来自 shared-entity-resolution 的未解析身份包，不要重新构建。
• 否则，按照 ../shared-entity-resolution/SKILL.md 处理所有词元歧义、官方账号研究、账号确认和未解析关键词字符串构建。
• 沿用 shared-entity-resolution 返回的身份包：
  • 已解析模式：RESOLUTION_MODE = resolved、RESOLVED_TOKEN = <kaito token>，以及 kaito_twitter_official_account 提供的 OFFICIAL_HANDLE 和 AFFILIATE_HANDLES（如有）
  • 未索引模式：RESOLUTION_MODE = unresolved、OFFICIAL_HANDLE = <confirmed official handle>，以及 UNRESOLVED_STRING = <keyword string>
• 如果 shared-entity-resolution 已将身份范围缩小到一个只需确认的账号候选对象，不要要求用户重新陈述整个项目。
• 在未索引模式下，必须先获取 OFFICIAL_HANDLE，才能继续。
• 在已解析模式下，如果可用，请识别项目的显示名称和官方 X 账号，以便报告标题和排除筛选器使用正确的账号身份。
• 在已解析模式下，如果沿用的身份包缺少 OFFICIAL_HANDLE 或 AFFILIATE_HANDLES，则在构建排除项之前，针对 RESOLVED_TOKEN 调用 kaito_twitter_official_account。
• 构建用于输出的 DISPLAY_PROJECT_NAME：
  • 优先使用已解析的项目显示名称
  • 否则回退为 @<OFFICIAL_HANDLE>
• 为后续步骤构建可复用的项目搜索筛选器：
  • 已解析模式：PROJECT_SEARCH_FILTER = tokens=<RESOLVED_TOKEN>
  • 未索引模式：PROJECT_SEARCH_FILTER = keyword=<UNRESOLVED_STRING>
• 在所需账号信息已知时，将 EXCLUDED_HANDLES 构建为可选的排除集合：
  • 已解析模式：包含规范的官方 X 账号和 kaito_twitter_official_account 返回的任何关联账号，然后合并其他已确认的 excluded_handles
  • 未索引模式：包含已确认的官方 X 账号，以及上游已确认的其他 excluded_handles（如有）
• 在未索引模式下，不要臆造关联账号。如果只确认了官方账号，则只排除该账号。
• 将任何相对时长转换为精确的 window_start 和 window_end 时间戳，并在整个工作流中使用这些精确边界。

2. 数据收集

2.1 先抓取排名前 100 的推文

在按主题筛选之前，始终先获取完整的广泛语料。

并行运行五次 kaito_advanced_search，参数如下：

• sources="Twitter"
• 使用 Resolve Entity 中的项目搜索过滤条件：已解析模式下为 tokens=<RESOLVED_TOKEN>，未索引模式下为 keyword=<UNRESOLVED_STRING>
• 若有 EXCLUDED_HANDLES，则使用 exclude_handles=<EXCLUDED_HANDLES>
• sort_by="smart_engagement"
• size=20
• from=0、20、40、60 和 80
• min_created_at=<window_start>
• max_created_at=<window_end>

搜索阶段规则：

• 不要预先按预设主题或自定义重点筛选。先获取相同的排名前 100 推文语料，然后在聚类和排序阶段应用关注重点。
• 排除由项目官方账号及任何已知关联账号发布的推文。此工作流用于分析外部讨论，而非自有媒体内容。
• 在未索引模式下，只排除已确认的官方账号。不要猜测或编造关联账号。
• 在未索引模式下，信任完整语料之前，先快速检查查询质量：
  • 检查第一页结果，确认内容确实与目标项目相关
  • 如果查询噪声较多，则收紧 UNRESOLVED_STRING，移除有歧义的名称，只保留歧义较小的别名和账号名
  • 如果优化后查询仍有较多噪声，则暂停，并在继续之前向用户确认账号名或项目的其他名称
• 只要已知相关账号，就必须将 EXCLUDED_HANDLES 作为必要的检索逻辑：
  • 在每次 Twitter 语料抓取中直接传入 exclude_handles=<EXCLUDED_HANDLES>
  • 如果相关账号仍未知，导致无法确定 EXCLUDED_HANDLES，则使用较小的已知排除集合继续，而不是编造账号
• 如果尚未确认官方账号，则停止操作，并在继续未索引模式之前先行确认。
• 翻页后按推文 ID 去重。
• 如果回复和引用推文排在语料前列，则予以保留；但如果其作者已知属于 EXCLUDED_HANDLES，仍须排除。
• 如果返回的推文少于 100 条，则使用现有结果继续，并在输出中说明。
• 如果项目未索引，则明确说明语料是基于关键词获取的，即使账号已确认，实体识别准确度仍可能低于基于已解析令牌的模式。

2.2 作者信息只补充一次并重复使用

从抓取的推文中整理出唯一作者列表，并按账号缓存每位作者的一份个人资料。

对于每位唯一作者：

1. 当 author_user_id 可用时，使用 kaito_get_twitter_user，以便获取：
   • 显示名称
   • 用户名
   • 个人资料图片 / 头像
   • 简介，以及有助于解读的分类信息
2. 对每位不同的作者使用 kaito_smart_followers 的 count 模式，以确保始终获取最新的标准化智能粉丝数
3. 当 kaito_twitter_account_type 可用时，对每个不同的作者账号使用它，以便获取：
   • 账号类型分类
   • 加密货币领域角色
4. 通过检查当前分析窗口之前是否有提及同一项目的历史记录，判断作者是 new 还是 existing：
   • 使用以下参数调用 kaito_advanced_search：
     • sources="Twitter"
     • usernames=<author_handle>
     • 使用 Resolve Entity 中的同一项目搜索过滤器：
       • 当代币已解析时使用 tokens=<RESOLVED_TOKEN>
       • 对于未索引项目，使用 keyword=<UNRESOLVED_STRING>
     • size=1
     • sort_by="relevance"
     • max_created_at=<window_start_minus_1s>
   • 使用当前窗口之前的所有可用历史记录，不包括当前窗口
   • 根据当前模式使用完整的项目实体表达式进行搜索，而不仅仅使用已解析代币路径
   • 如果找到至少一条匹配的历史推文，则设置 existing="existing"
   • 如果未找到匹配的历史推文，只有在项目搜索过滤器除账号外还包含至少一个足够独特的项目名称或别名时，才设置 existing="new"
   • 如果未找到匹配的历史推文，且未索引过滤器实际上仅包含账号，则设置 existing="unknown"，而不是 new，因为召回能力太弱
   • 如果无法完成历史查询或账号不可用，则设置 existing="unknown"

作者信息补充规则：

• 不要将搜索结果中的作者智能粉丝数作为主要数据来源。始终使用 kaito_smart_followers 刷新该数值，因为搜索负载可能已过时或返回 0。
• 只有在专用的 kaito_smart_followers 调用失败时，才将搜索结果中的智能粉丝数作为最后的备用数据。
• 当 kaito_twitter_account_type 调用成功时，将其作为 role 的主要数据来源。
• 始终根据下方的阈值，从刷新的智能粉丝数推导 tier。
• 最终输出中展示的每条推文都必须显示：头像、显示名称、账号、智能粉丝数、智能互动数、existing、role 和 tier。
• 如果头像或个人资料元数据不可用，请留空，不要编造。

作者状态字段：

• existing：new | existing | unknown
  • 通过检查作者是否在当前时间窗口之前提到过同一项目来进行分类
  • 使用 kaito_advanced_search，参数为 usernames=<author_handle>、max_created_at=<window_start_minus_1s>，以及来自 Resolve Entity 的相同项目搜索筛选条件
  • 如果至少有一条先前匹配结果，使用 existing
  • 如果没有先前匹配结果，且搜索筛选条件包含至少一个足够独特的项目名称或别名，使用 new
  • 如果没有先前匹配结果，但未建立索引的搜索筛选条件仅包含账号句柄，使用 unknown
  • 仅在无法可靠完成查询时使用 unknown
• role：research/trader | builder | kol | community member | unknown
  • 这是角色分类字段，不是布尔型研究员标记
  • 应依据 kaito_twitter_account_type 确定
  • 必要时将端点输出规范化为上述允许的 UI 值
  • 如果端点不可用，或未返回可信的角色，使用 unknown
  • 输出保持小写，并采用适合 UI 渲染的结构化格式
• tier：mega | large | medium | small | micro | unknown
  • 根据智能关注者数量推导出的便捷 UI 规模等级，供前端渲染使用
  • 定义：
    • 当 smart_followers > 2000 时为 mega
    • 当 1000 <= smart_followers <= 2000 时为 large
    • 当 300 <= smart_followers < 1000 时为 medium
    • 当 100 <= smart_followers < 300 时为 small
    • 当 smart_followers < 100 时为 micro
  • 如果无法获取智能关注者数据，使用 unknown
  • 输出保持小写，并采用适合 UI 渲染的结构化格式
  • 这是简化后的 UI 等级；仍需单独显示原始智能关注者数量

3. 分析

3.1 为每条推文评定紧迫性和可执行性

为每条推文指定：

• urgency：not urgent、low urgency、moderate urgency 或 urgent
• urgency_reason：用一个简短句子说明原因
• suggested_action：用一个具体的回应，合并行动和目标，作为单一字段

紧迫性定义

• urgent：影响力高、应在当前监测周期内处理的内容。通常至少符合以下两项：
  • 作者具有较高影响力，例如智能关注者等级为 mega 或 large，或来自主流媒体、重要合作伙伴、主要投资者，或其他明显有影响力的外部声音
  • 智能互动量在语料中异常高
  • 内容具有时效性，例如漏洞、服务中断、错误信息、严重的竞争对手舆论定调、高质量评估帖，或仍可及时互动的知名人士背书
• moderate urgency：值得回复、放大传播、澄清或在下一响应周期内监测的有效信号，但尚未达到当前周期需要升级处理的程度
• low urgency：传播范围有限或可执行性较弱，但仍值得记录并进行轻度监测的内容
• not urgent：重复、过时、纯背景信息或不可执行的内容，可记录而无需近期跟进

urgency_reason 必须指出实际驱动因素，例如作者影响力、智能互动量、内容敏感度、新颖性或时机。

建议行动

将 suggested_action 作为单一输出字段。按以下格式书写：

• <action> + <objective>
• 示例：立即回复 + 放大产品角度

suggested_action 的 UI 简洁规则：

• 保持简短，适合紧凑型 UI 标签或单行字段。
• 目标为 2 到 6 个词，长度控制在约 60 个字符以内。
• 不要包含理由、证据、账号名称、指标、列表或多个分句。
• 不要在 Suggested Action: 后写一段说明。解释应放在 urgency_reason 或主题概览中，而不是行动字段里。

使用具体的传播或产品行动，而非交易建议。适用的行动动词包括：

• 立即回复
• 通过官方账号放大传播
• 立即澄清
• 转交支持团队
• 转交产品团队
• 私信／私下跟进
• 准备内部简报
• 仅监测

目标指导

每个 suggested_action 仍应承载一个明确目标。常见目标包括：

• Amplify product angle
• Convert evaluator into advocate
• Correct misinformation
• Contain reputational risk
• Support affected users
• Reinforce competitive differentiation
• Collect product feedback
• Build relationship with key voice
• Track signal without overreacting

建议的行动应与推文相符：

• 重要人物对产品的正面评论 -> Reply now to amplify product angle 或 Amplify from official account to extend third-party validation
• 可信的质疑 -> Reply now to convert evaluator into advocate
• Bug 报告或服务中断的说法 -> Route to support to help affected users 或 Clarify now to contain reputational risk
• 竞品比较 -> Reply now to reinforce competitive differentiation 或 Prepare internal brief to align the team on response
• 信号较弱的赞扬或过时评论 -> Monitor only to track signal without overreacting

3.2 将推文聚类为热门话题

根据推文内容、作者背景、有效互动数据和所选关注方向，将获取的推文聚类为连贯的热门话题。

热门话题规则：

• 围绕具体的讨论主题或叙事角度构建话题组，而不是按笼统的情绪类别划分。
• 每个热门话题应包含简短标题、精炼论点和按顺序排列的相关推文列表。
• 在每个话题内，优先按有效互动数据排序推文，其次考虑作者的重要性，最后考虑时效性。
• 话题应有选择性，而不是穷尽式拆分。合并明显重叠的聚类。

3.3 应用话题关注方向和标签

输出标签系统使用当前预设的话题分类和 Other：

• Engagement opportunities
• Risk watch
• Key voices
• Emerging narratives
• Product discussion
• Market discussion
• Bugs & issues
• Competitor comparisons
• Questions & evaluation
• Feature requests
• Other

标签规则：

• 允许使用多个标签。有依据时，每个话题最多分配 3 个标签。
• 仅当当前所有预设标签均不适用时，才使用 Other。
• 如果 focus_mode="preset"，默认选择所有当前预设话题。如果用户缩小了预设多选范围，则优先保留与所选预设标签匹配的话题。
• 如果 focus_mode="custom"，使用 custom_topic_focus 更改聚类和优先级逻辑，但不要创建新的输出标签。最终话题仍必须使用当前输出分类打标签。

标签定义：

• Engagement opportunities：有明确机会进行回复、引用、致谢或建立关系
• Risk watch：负面说法、争议、错误信息或涉及声誉风险的讨论
• Key voices：由重要账号或值得关注的新参与者主导的聚类
• Emerging narratives：新出现或正在升温的叙事
• Product discussion：功能、发布、集成、使用、演示或用户体验
• Market discussion：价格、估值、资金流、上市或交易相关讨论
• Bugs & issues：可靠性问题、漏洞、服务中断、流程故障或支持方面的痛点
• Competitor comparisons：直接比较、品类基准或替代方案论据
• Questions & evaluation：尽职调查讨论串、质疑或评估性讨论
• Feature requests：明确要求增加或改进功能
• Other：相关讨论，但不属于预设分类

3.4 计算主题级汇总数据

对于每个热点主题，计算：

• tweet_count：该主题中的推文总数
• total_smart_engagement：该主题中所有推文的智能互动总量
• urgency：该主题中所有推文的最高紧急程度
• key_accounts：该聚类中最重要或出现频率最高的作者

主题排序规则：

• 按主题紧急程度从高到低排序：urgent > moderate urgency > low urgency > not urgent，然后依次按智能互动总量和推文数量排序。
• 主题沿用其推文中的最高紧急程度，使用相同的严重程度顺序：urgent > moderate urgency > low urgency > not urgent。
• 在主题摘要卡片和详细章节中都使用汇总指标。

3.5 为摘要确定叙事

撰写 Summary 之前，进行一次轻量级的叙事核查。

• 调用 kaito_narratives 获取 Kaito 的规范叙事集。
• 检查 Summary 是否提及其中的任何叙事。
• 如果提及的叙事与 Kaito 的某个规范叙事相匹配，请使用返回的 narrative 值（须与显示内容完全一致）以结构化叙事标记呈现，但要将其自然地嵌入原本表达该观点的句子中。
• 如果 Summary 中的某个主题与规范叙事集不匹配，只用普通语言提及，不要臆造结构化叙事标记。

4. 输出

优先采用以下输出结构。如果用户提出了具体问题，应在该结构中更直接地回答，尤其是在 Summary 中。如果用户没有提出具体问题，则使用相同结构作为默认摘要或报告。

以 Summary 部分开头，恰好包含三个简短段落：

1. 对用户请求的最直接回应，以及所选项目和时间范围的总体结论
2. 最重要的热点主题、推动这些主题的关键账号，以及最重要的已确定叙事
3. 最重要的建议行动及其中包含的目标

仅限摘要的结构化呈现规则：

• 不要在 Summary 前添加独立的报告标题。界面可以单独显示项目名称和时间范围。
• 当界面或周边工作流需要项目标签时，使用 DISPLAY_PROJECT_NAME。
• 每个摘要段落都要简洁：每段不超过 2 句话。
• 保持 Summary 内容概括。不要在其中重复完整的主题卡片、较长的推文示例或各主题指标明细。
• 只提及最重要的 1 至 2 个主题，以及最重要的行动要点。
• 如果在 Summary 中提及账号句柄，请按 @handle 的形式呈现。开头的 @ 是前端渲染账号的解析信号。
• 如果在 Summary 中提及已确定的叙事，请按 [[narrative:<narrative>]] 的形式呈现，其中 <narrative> 必须与 kaito_narratives 返回的 narrative 字段完全一致，例如 AI 或 L2。[[narrative:...]] 包装标记是前端渲染叙事的解析信号，但必须自然地嵌入正文。
• 不要添加独立标签或末尾标记列表，例如 Matched narratives: [[narrative:AI]], [[narrative:L2]]。
• 优先使用类似 讨论主要集中在 [[narrative:AI]] 和 [[narrative:L2]] 的表述，而不要拆分句子机械地枚举匹配项。
• 仅在 Summary 中使用这种结构化叙事标记。Hot Topics 部分无需使用这种特殊呈现方式。

然后添加 Hot Topics。

对于每个热点主题，展示：

• 主题标题
• 当前输出分类体系中的主题标签（如适用，最多 3 个）
• 概述，说明主题内容及其在此时间范围内的重要性
• Tweets: N
• Smart Engagement: N
• Urgency: not urgent | low urgency | moderate urgency | urgent
• 关键账号

热点主题格式规则：

• 话题卡片仅用于汇总。卡片只能包含上述话题级字段和下面的推文列表，不得包含其他内容。
• 使用分类体系中的确切标签。不要更改大小写或措辞。
• Urgency 必须是以下确切的小写值之一：not urgent、low urgency、moderate urgency 或 urgent。
• Smart Engagement 必须是数值汇总，不能使用 High 或 Medium 等定性文字。
• key accounts 应为简短的逗号分隔列表，最好只包含账号句柄。
• 不要添加话题级别的 Suggested Action 段落，也不要添加 Source Credibility 等额外区块。
• 话题的 overview 可以由 2 到 3 个简短句子组成。第一句最重要，应作为精简的卡片摘要；完整的 2 到 3 个句子可用于详情视图。
• 不要在单一的 overview 字段之外添加单独的话题级说明部分，例如 Why it matters、Recommended response、Takeaway 或 Source notes。
• 话题正文应简洁，便于 UI 扫读。每个话题最多展示 5 条推文，并按智能互动度和作者重要性排序。

然后列出该话题中的推文。每条推文都必须包含：

• 头像
• 显示名称
• 账号句柄
• 智能粉丝数
• 智能互动度
• existing
• role
• tier
• 推文文本或简洁、客观的摘要
• 推文 URL
• Urgency: <level> - <reason>
• Suggested Action: <action + objective>

推文条目格式规则：

• 只有推文条目中可以出现 Suggested Action。
• 不要将推文排成 Markdown 表格。每条推文使用一个精简条目，以便 UI 清晰映射各字段。
• 使用真实的推文 URL，绝不要使用 link 等占位符。
• 推文文本应为原文，或仅包含简洁、客观的摘要。
• 不要添加 Source Credibility、自由格式的情绪列，或推文条目之后的冗长说明等不受支持的字段。
• Suggested Action 必须保持为简短的单行内容，不得写成迷你建议段落。
• existing、role 和 tier 必须保持结构化且简洁。不要用说明性文字替代它们。

规则

• 此工作流以内容和话题为先，而非以 KPI 为先。
• 始终围绕用户的实际请求作答。输出结构是响应格式，不可替代对用户提示的直接回应。
• 在应用聚焦逻辑前，始终先获取已解析股票代码对应的前 100 条推文，或已确认的基于关键词的项目查询对应的前 100 条推文。
• 前 100 条推文的数据集应仅反映外部讨论；若已知项目自身账号和任何关联账号，则应排除这些账号。
• 摘要和话题部分必须使用确切选定的时间范围，不得使用模糊的滚动时间描述。
• 不要臆造作者身份、头像或账号角色。只能使用真实的个人资料数据。
• suggested_action 应结合具体推文、作者背景和内含目标。
• 行动建议应切实可行，适用于传播、社区、支持或产品团队。
• 不要提供交易建议或市场判断，例如 buy signal、sell signal 或目标价格相关表述。
• 不要将项目自有或关联账号纳入外部对话话题数据集或话题推文列表。处于未索引模式时，仅排除你实际知晓的账号句柄。
• 如果项目未索引或仅基于关键词进行查询，应明确说明，并指出实体识别精度、existing 语气召回、关联账号排除以及依赖结构化代币数据的覆盖范围方面的限制。
• 如果数据集稀疏，应直接说明，不要夸大可信度。
• 使用 smart accounts，绝不要使用 smart money。