marketing-social-pulse

前置步骤（先运行）

_KS_REPO=""
_KS_REAL_SKILL="$(cd "$HOME/.claude/skills/marketing-social-pulse" 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!) 并继续。

社交热度

当用户询问某个特定实体的关注度、情绪或更广泛的社交指标时，使用此技能，尤其是答案需要包含特定时间窗口内的异常情况、12 个月背景信息以及深入分析说明时。

输入

• token：项目名称、股票代码或已解析的 Kaito token 值；仅当上游工作流已提供 unresolved_string 和已确认的 official_handle 时才可选
• official_handle：可选的前置提示，在 token 无法清晰解析时传递给 shared-entity-resolution；每当最终采用未解析模式时都必须提供
• unresolved_string：来自 shared-entity-resolution 的可选预构建关键词字符串；仅当该字符串已附带确认的 official_handle 时使用
• affiliate_handles：可选的逗号分隔账号列表，如果已知，应合并到规范排除集合中
• duration：7d、30d、90d，或指定包含 start 和 end 的过去时间窗口（默认为 30d）

工作流

将工作流分为四个阶段：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>
• 在未解析模式下，必须先有 OFFICIAL_HANDLE，然后才能继续。
• 构建可重复使用的实体搜索筛选条件：
  • 已解析模式：ENTITY_SEARCH_FILTER = tokens=<RESOLVED_TOKEN>
  • 未解析模式：ENTITY_SEARCH_FILTER = keyword=<UNRESOLVED_STRING>
• 在已解析模式下，可使用 mindshare、sentiment、mentions、engagement 和 kaito_mindshare_entity_by_account。
• 在未解析模式下，仅使用 mentions、engagement 和基于搜索的深入分析。mindshare、sentiment 和 kaito_mindshare_entity_by_account 不可用，必须在输出中明确说明。
• 在已解析模式下，如有 OFFICIAL_HANDLE，也要识别它，以便排除逻辑仍可生效。
• 在已解析模式下，如果沿用的身份包缺少 OFFICIAL_HANDLE 或 AFFILIATE_HANDLES，请在构建排除项前调用 kaito_twitter_official_account，并传入 RESOLVED_TOKEN。
• 根据规范官方账号句柄、kaito_twitter_official_account 返回的任何关联账号句柄，以及用户提供的额外经确认的 affiliate_handles，构建 EXCLUDED_HANDLES。
• 在未解析模式下，仅加入经确认的官方账号句柄，以及已确认的额外 affiliate_handles。不要猜测关联账号。
• 如果接口或用户输入中没有关联账号句柄，仍要排除官方账号句柄，并说明关联账号排除可能不完整。
• 将请求的时间段转换为精确的 window_start 和 window_end 时间戳。
• 另外，将 context_start 定义为以 window_end 为锚点向前追溯 12 个月的起始时间。
• 分析和输出中使用确切日期，不要只使用“上个月”等相对表述。

2. 数据收集

2.1 并行获取当前窗口和过去 12 个月的指标

运行与模式相对应的指标组合：

1. 已解析模式：
   • 获取所请求分析窗口的 kaito_mindshare_entity
   • 获取截至 window_end 的过去 12 个月的 kaito_mindshare_entity
   • 获取所请求分析窗口的 kaito_sentiment_entity
   • 获取截至 window_end 的过去 12 个月的 kaito_sentiment_entity
   • 获取所请求分析窗口的 kaito_mentions，并设置 sources="Twitter"
   • 获取截至 window_end 的过去 12 个月的 kaito_mentions，并设置 sources="Twitter"
   • 获取所请求分析窗口的 kaito_engagement
   • 获取截至 window_end 的过去 12 个月的 kaito_engagement
2. 未解析模式：
   • 使用未解析的实体表达式获取所请求分析窗口的 kaito_mentions，并设置 sources="Twitter"
   • 使用未解析的实体表达式获取截至 window_end 的过去 12 个月的 kaito_mentions，并设置 sources="Twitter"
   • 使用未解析的实体表达式获取所请求分析窗口的 kaito_engagement
   • 使用未解析的实体表达式获取截至 window_end 的过去 12 个月的 kaito_engagement

在已解析模式中，将 mindshare 和 sentiment 视为主要分析维度。将 mentions 和 engagement 用作辅助佐证信号，帮助解释认知变化，而非取代主要分析结论。

保留每项实际运行指标返回的完整时间序列，以便比较：

• 所请求窗口内的异常模式
• 窗口级趋势与该实体过去 12 个月的长期趋势

对于 kaito_mentions，仅纳入 Twitter。从提及分析中排除所有其他来源类型，因为非 Twitter 来源与解释由 Twitter 驱动的社交指标变化无关。

3. 分析

3.1 检测异常，并将窗口置于过去 12 个月的趋势中

仅使用当前解析模式下可用的指标，综合分析当前窗口和 12 个月的时间序列。

找出：

• 所请求窗口内每项可用指标的异常峰值或跌幅
• 可用指标走向不一致的分歧点
• 所请求窗口高于、低于还是接近该实体过去 12 个月的基线
• 与长期趋势相比，该窗口呈现加速、减速、反转还是趋于正常

特定模式的解读方式：

• 已解析模式：首先关注 mindshare 和 sentiment，然后将 mentions 和 engagement 用作辅助背景信息和佐证
• 未解析模式：结合分析 mentions 和 engagement，并明确标注 mindshare 和 sentiment 为不可用的结构化指标

异常选择规则：

• 如果数据支持，保留多个异常窗口。
• 将紧邻的异常数据桶视为同一个调查窗口。
• 根据实际运行指标的综合幅度、持续性和相关性对异常排序。
• 如果没有明显异常，应说明该时期由趋势驱动而非事件驱动，并跳过异常深入分析步骤。

3.2 收集异常细查证据

对每个异常时间窗口，执行以下步骤。

1. kaito_advanced_search
   • 使用 Resolve Entity 中的实体搜索筛选条件：
     • 已解析模式：tokens=<RESOLVED_TOKEN>
     • 未解析模式：keyword=<UNRESOLVED_STRING>
   • sources="Twitter"
   • sort_by="smart_engagement"
   • size=100
   • min_created_at=<anomaly_start>
   • max_created_at=<anomaly_end>
   • 如果有 EXCLUDED_HANDLES，则使用 exclude_handles=<EXCLUDED_HANDLES>
   • 目标：检索该实体在异常时间窗口内互动表现最高的 100 条外部推文
2. 贡献者归因
   • 已解析模式：
     • 如果端点支持时间窗口边界，则对异常时间窗口内的 RESOLVED_TOKEN 运行 kaito_mindshare_entity_by_account
     • 如果端点只支持接近该时间窗口的预设范围，则使用最接近的可用范围并说明这一点
     • 使用该端点，从定量角度识别贡献 mindshare 最多的账号
   • 未解析模式：
     • 跳过 kaito_mindshare_entity_by_account
     • 直接从异常时间窗口内的 Twitter 内容中识别最相关的外部声音，依据重复出现、智能互动量以及在异常讨论中的影响力等信号
   • 对任一模式中最相关的贡献者账号，在可用时调用 kaito_twitter_account_type，以判断异常是由 KOL、研究人员或交易者、构建者，还是社区账号推动的
3. 账号后续搜索
   • 对上述贡献者归因步骤中最相关的贡献者账号运行 kaito_advanced_search
   • 使用 Resolve Entity 中相同的实体搜索筛选条件
   • 添加 usernames=<top contributor handles>
   • 使用相同的异常时间边界
   • 在可行时进行分页，以收集这些账号在异常时间窗口内的所有匹配内容
   • 目标：准确查看主要异常推动账号发布了什么内容

为账号后续搜索选择贡献者账号时，检查能够解释异常的最小集合，通常为排名前 5 到 10 的贡献者，或明显主导该时间窗口的账号集合。

3.3 为 Summary and Conclusions 中的叙述确定规范名称

撰写 Summary and Conclusions 之前，进行一次简要的叙述核查。

• 调用 kaito_narratives，获取 Kaito 的规范叙述集。
• 检查 Summary and Conclusions 是否提及该集合中的任何叙述。
• 如果提及的叙述与 Kaito 的某条规范叙述相符，则使用返回的 narrative 值，按原样呈现结构化叙述标记；但要将其自然地嵌入已经阐述该观点的句子中。
• 如果 Summary and Conclusions 中的主题与规范叙述集不符，则仅用平实语言提及，不要臆造结构化叙述标记。

4. 输出

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

严格按照以下顺序输出四个部分：

• Summary and Conclusions
  • 先直接回应用户的请求，再概述指定时间范围内的整体社交舆情，并给出主要结论
• Key Observations
  • 本节以描述性内容和数据为主，同时仍需结合用户的请求
  • 聚焦于舆情：在已解析模式下，先说明关注度变化路径和情绪变化路径，再用提及量和互动量作为辅助背景；在未解析模式下，聚焦于实际可用的指标
• Key Insights
  • 结合用户的请求，解释异常出现的原因
  • 使用热门推文的深入分析、当前模式下最佳可用的贡献者归因方法，以及这些账号实际表达的内容作为依据
• Suggested Actions
  • 根据用户的请求和观察到的舆情变化，提出具体的后续行动
  • 聚焦于团队应针对观察到的舆情变化和已识别的驱动因素采取哪些行动

除非用户明确要求，否则不要添加额外的评分卡或基准分析部分。

Summary and Conclusions 的结构化呈现规则：

• 本节应保持高层次且简洁。不要在此重述完整的异常分析、冗长的推文示例或各时间窗口的详细指标。
• 如果在 Summary and Conclusions 中提及账号句柄，应写成 @handle。开头的 @ 是供前端识别账号的标记。
• 如果在 Summary and Conclusions 中提及已解析的叙事，应写成 [[narrative:<narrative>]]，其中 <narrative> 必须是 kaito_narratives 返回的 narrative 字段原文。
• 不要添加独立标签或结尾的标记列表，例如：Matched narratives: [[narrative:AI]], [[narrative:L2]]。
• 尽量采用自然的表达，例如“讨论集中在 [[narrative:AI]]”，而不要仅为显示标记而拆分句子。
• 结构化叙事标记仅在 Summary and Conclusions 中使用，除非用户明确要求在其他位置采用相同格式。

规则

• 始终结合此前 12 个月的背景分析用户指定的时间窗口。
• 始终围绕用户的实际请求组织答案。四个输出部分只是回答格式，不能取代对用户提示词的直接回应。
• 在已解析模式下，构建核心叙事时优先考虑 mindshare 和 sentiment，而不是 mentions 和 engagement。
• 在异常根因分析中，将官方和关联账号的帖子视为自有媒体噪声，并在可行时排除。
• Key Observations 应采用量化、描述性的表述，不要在其中混入因果推测。
• 在已解析模式下，将 mentions 和 engagement 视为辅助证据，用于解释或验证 mindshare 和 sentiment 的变化，而不是同等优先级的核心指标。
• 在 Key Insights 中进行因果解读，并结合推文证据以及适用于当前模式的最佳账号级归因方法。
• 如果可以进行贡献者分类，应利用分类结果解释驱动因素的构成，而不只是列出账号名。不要臆造账号角色或缺乏依据的影响力标签。
• 如果任何端点对排除、分页或时间窗口的支持不完整，应明确说明限制，不要隐瞒。
• 如果实体仍未解析，应明确指出缺少哪些结构化指标，不要凭猜测补齐。
• 如果实体仍未解析，应明确说明，深入分析和趋势分析是基于关键词的，在实体精度方面可能不如已解析代币模式。
• 如果未发现异常，应明确说明，并将报告重点放在长期趋势背景上。
• 始终使用 smart accounts，绝不要使用 smart money。

待办事项

相应的 MCP 端点推出后，添加以下计划中的指标扩展：

1. 滚动唯一 smart accounts 数量
   • 添加专用 MCP 端点，用于统计随时间变化的滚动唯一 smart accounts 参与情况
   • 将其作为感知质量信号，与 mindshare、sentiment、mentions 和 engagement 一并使用
2. sentiment 构成
   • 添加专用 MCP 端点，用于分析随时间变化的 sentiment 构成
   • 使用该端点丰富 sentiment 解读，而不只是依赖单一汇总 sentiment 序列