marketing-social-pulse

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Preamble (run first)

前置步骤（首先执行）

bash

_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

If output shows

KAITO_SKILLS_REPO <path>

, remember that path as

KAITO_SKILLS_REPO

If output shows

UPGRADE_AVAILABLE <old> <new>

, read

<KAITO_SKILLS_REPO>/docs/update-kaito-skills.md

and follow the "Inline upgrade flow" before continuing. If the user snoozes or disables update checks, continue with the current skill.

If output shows

JUST_UPGRADED <from> <to>

, tell the user

Running kaito-skills v{to} (just updated!)

and continue.

bash

_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 <路径>

，请将该路径记为

KAITO_SKILLS_REPO

。

如果输出显示

UPGRADE_AVAILABLE <旧版本> <新版本>

，请阅读

<KAITO_SKILLS_REPO>/docs/update-kaito-skills.md

并按照“内联升级流程”操作后再继续。如果用户选择暂缓或禁用更新检查，则继续使用当前版本的技能。

如果输出显示

JUST_UPGRADED <旧版本> <新版本>

，请告知用户

正在运行kaito-skills v{新版本}（刚刚完成更新！）

并继续操作。

Social Pulse

社交动态分析

Use this skill when the user asks about mindshare, sentiment, or broader social metrics for a particular entity, especially when the answer should include time-window anomalies, 12-month context, and drill-down explanation.

当用户询问特定实体的心智份额、情感倾向或更广泛的社交指标，且答案需要包含时间窗口异常、12个月背景信息及深度钻取解释时，可使用此技能。

Inputs

输入参数

```
token
```
: project name, ticker, or resolved Kaito token value; optional only when an upstream workflow already supplies
```
unresolved_string
```
plus a confirmed
```
official_handle
```
```
official_handle
```
: optional upfront hint passed into
```
shared-entity-resolution
```
when the token does not resolve cleanly; required whenever unresolved mode is finalized
```
unresolved_string
```
: optional prebuilt keyword string from
```
shared-entity-resolution
```
; use it only when it already comes with a confirmed
```
official_handle
```
```
affiliate_handles
```
: optional comma-separated handles that should be merged into the canonical exclusion set when already known
```
duration
```
:
```
7d
```
,
```
30d
```
,
```
90d
```
, or an explicit past window with
```
start
```
and
```
end
```
(default
```
30d
```
)

```
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
```
）

Workflow

工作流

Organize the workflow into four stages:

Resolve Entity

Data Gathering

Analysis

, and

Output

将工作流分为四个阶段：

实体解析

、

数据收集

、

分析

和

输出

。

1. Resolve Entity

1. 实体解析

Resolve the entity identity, exclusion set, and exact analysis window before pulling any metrics.

Use

shared-entity-resolution

first unless an upstream workflow already hands you a confirmed unresolved identity package.

If
```
unresolved_string
```
is already supplied together with a confirmed
```
official_handle
```
, treat that pair as the unresolved identity package from
```
shared-entity-resolution
```
and do not rebuild it.
Otherwise, follow
```
../shared-entity-resolution/SKILL.md
```
for token ambiguity handling, official-handle research, handle confirmation, and unresolved keyword-string construction.

Carry forward the identity package returned by

shared-entity-resolution

resolved mode:

RESOLUTION_MODE = resolved

RESOLVED_TOKEN = <kaito token>

, plus

OFFICIAL_HANDLE

and

AFFILIATE_HANDLES

when available from

kaito_twitter_official_account

unresolved mode:

RESOLUTION_MODE = unresolved

OFFICIAL_HANDLE = <confirmed official handle>

, and

UNRESOLVED_STRING = <keyword string>

Treat
```
OFFICIAL_HANDLE
```
as mandatory before continuing in unresolved mode.

Build a reusable entity search filter:

resolved mode:

ENTITY_SEARCH_FILTER = tokens=<RESOLVED_TOKEN>

unresolved mode:

ENTITY_SEARCH_FILTER = keyword=<UNRESOLVED_STRING>

In resolved mode,

mindshare

sentiment

mentions

engagement

, and

kaito_mindshare_entity_by_account

are available.

In unresolved mode, continue with
```
mentions
```
,
```
engagement
```
, and search-based drill-down only.
```
mindshare
```
,
```
sentiment
```
, and
```
kaito_mindshare_entity_by_account
```
are unavailable and must be called out explicitly in the output.
Identify
```
OFFICIAL_HANDLE
```
when available in resolved mode as well so exclusion logic can still work.
In resolved mode, if the carried identity package is missing
```
OFFICIAL_HANDLE
```
or
```
AFFILIATE_HANDLES
```
, call
```
kaito_twitter_official_account
```
for
```
RESOLVED_TOKEN
```
before building exclusions.
Build
```
EXCLUDED_HANDLES
```
from the canonical official handle, any affiliate handles returned by
```
kaito_twitter_official_account
```
, and any extra confirmed
```
affiliate_handles
```
supplied by the user.
In unresolved mode, include only the confirmed official handle plus any extra
```
affiliate_handles
```
that are already confirmed. Do not guess affiliates.
If affiliate handles are not available from the endpoint or user input, still exclude the official handle and state that affiliate exclusion may be incomplete.
Convert the requested period into exact
```
window_start
```
and
```
window_end
```
timestamps.
Also define
```
context_start
```
as the trailing 12-month start anchored to
```
window_end
```
.
Use exact dates in the analysis and output, not only relative phrases such as
```
last month
```
.

在获取任何指标之前，先解析实体身份、排除集合及精确分析窗口。

除非上游工作流已提供已确认的未解析身份包，否则先使用

shared-entity-resolution

。

如果已提供
```
unresolved_string
```
及已确认的
```
official_handle
```
，则将该组合视为来自
```
shared-entity-resolution
```
的未解析身份包，无需重新构建。
否则，请遵循
```
../shared-entity-resolution/SKILL.md
```
中的token歧义处理、官方句柄调研、句柄确认及未解析关键字字符串构建流程。

传递

shared-entity-resolution

返回的身份包：

已解析模式：

RESOLUTION_MODE = resolved

，

RESOLVED_TOKEN = <kaito token>

，加上来自

kaito_twitter_official_account

的

OFFICIAL_HANDLE

和

AFFILIATE_HANDLES

（若可用）

未解析模式：

RESOLUTION_MODE = unresolved

，

OFFICIAL_HANDLE = <已确认的官方句柄>

，以及

UNRESOLVED_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
```
，则在构建排除集合前，需针对
```
RESOLVED_TOKEN
```
调用
```
kaito_twitter_official_account
```
。
从标准官方句柄、
```
kaito_twitter_official_account
```
返回的关联句柄，以及用户提供的额外已确认
```
affiliate_handles
```
中构建
```
EXCLUDED_HANDLES
```
。
在未解析模式下，仅包含已确认的官方句柄及任何已确认的额外
```
affiliate_handles
```
。请勿猜测关联句柄。
如果无法从端点或用户输入获取关联句柄，仍需排除官方句柄，并说明关联句柄的排除可能不完整。
将请求的时间段转换为精确的
```
window_start
```
和
```
window_end
```
时间戳。
同时定义
```
context_start
```
为以
```
window_end
```
为锚点的过去12个月起始时间。
在分析和输出中使用精确日期，而非仅使用“上个月”这类相对表述。

2. Data Gathering

2. 数据收集

2.1 Pull current-window and trailing-12-month metrics in parallel

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

Run the mode-appropriate bundle:

resolved mode:
- ```
kaito_mindshare_entity
```
  for the requested analysis window
- ```
kaito_mindshare_entity
```
  for the trailing 12 months ending at
```
window_end
```
- ```
kaito_sentiment_entity
```
  for the requested analysis window
- ```
kaito_sentiment_entity
```
  for the trailing 12 months ending at
```
window_end
```
- ```
kaito_mentions
```
  for the requested analysis window with
```
sources="Twitter"
```
- ```
kaito_mentions
```
  for the trailing 12 months ending at
```
window_end
```
  with
```
sources="Twitter"
```
- ```
kaito_engagement
```
  for the requested analysis window
- ```
kaito_engagement
```
  for the trailing 12 months ending at
```
window_end
```
unresolved mode:
- ```
kaito_mentions
```
  for the requested analysis window with
```
sources="Twitter"
```
  using the unresolved entity expression
- ```
kaito_mentions
```
  for the trailing 12 months ending at
```
window_end
```
  with
```
sources="Twitter"
```
  using the unresolved entity expression
- ```
kaito_engagement
```
  for the requested analysis window using the unresolved entity expression
- ```
kaito_engagement
```
  for the trailing 12 months ending at
```
window_end
```
  using the unresolved entity expression

In resolved mode, treat

mindshare

and

sentiment

as the primary analytical axes. Use

mentions

and

engagement

as secondary corroborating signals that help explain changes in perception rather than replace the main read.

Preserve the full returned time series for every metric that actually ran so you can compare:

the anomaly pattern inside the requested window
the window-level trend versus the entity's longer 12-month regime

For

kaito_mentions

, include only

Twitter

. Exclude every other source type from the mentions analysis because non-Twitter sources are not relevant for explaining changes in Twitter-driven social metrics.

运行与模式匹配的指标组合：

已解析模式：
- 针对请求的分析窗口调用
```
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
```
未解析模式：
- 使用未解析实体表达式，针对请求的分析窗口调用
```
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. Analysis

3. 分析

3.1 Detect anomalies and place the window inside the 12-month trend

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

Analyze the current-window and 12-month series together using only the metrics available in the active resolution mode.

Find:

unusual spikes or drops in every available metric inside the requested window
divergence points where the available metrics move in different directions
whether the requested window sits above, below, or near the entity's trailing 12-month baseline
whether the window shows acceleration, deceleration, reversal, or normalization versus the longer trend

Mode-specific interpretation:

resolved mode: focus first on mindshare and sentiment, then use mentions and engagement as secondary context and confirmation
unresolved mode: analyze mentions and engagement together, and explicitly mark mindshare and sentiment as unavailable structured metrics

Anomaly-selection rules:

Keep multiple anomaly windows when the data supports them.
Treat immediately adjacent abnormal buckets as one investigation window.
Rank anomalies by combined magnitude, persistence, and relevance across the metrics that actually ran.
If no clear anomaly exists, say the period was trend-driven rather than event-driven and skip the anomaly drill-down step.

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

找出：

请求窗口内各可用指标的异常峰值或谷值
各可用指标走势出现分歧的节点
请求窗口的指标水平相对于实体过去12个月基线的位置（高于、低于或接近）
与长期趋势相比，窗口内指标呈现加速、减速、反转或回归常态的趋势

模式特定解读：

已解析模式：优先关注心智份额和情感倾向，再将提及量和互动量作为辅助背景和验证依据
未解析模式：结合分析提及量和互动量，并明确标记心智份额和情感倾向为不可用的结构化指标

异常选择规则：

当数据支持时，保留多个异常窗口
将紧邻的异常时间段视为一个调查窗口
根据实际运行指标的综合幅度、持续性和相关性对异常进行排序
如果未发现明确异常，则说明该时间段由趋势驱动而非事件驱动，并跳过异常钻取步骤

3.2 Gather anomaly drill-down evidence

3.2 收集异常钻取证据

For each anomaly window, run these steps.

kaito_advanced_search

use the entity search filter from

Resolve Entity

resolved mode:
```
tokens=<RESOLVED_TOKEN>
```
unresolved mode:
```
keyword=<UNRESOLVED_STRING>
```

```
sources="Twitter"
```
```
sort_by="smart_engagement"
```
```
size=100
```
```
min_created_at=<anomaly_start>
```
```
max_created_at=<anomaly_end>
```

exclude_handles=<EXCLUDED_HANDLES>

whenever

EXCLUDED_HANDLES

is available

goal: retrieve the top 100 external tweets for the entity during the anomaly window

contributor attribution
- resolved mode:
  - run
```
kaito_mindshare_entity_by_account
```
    for
```
RESOLVED_TOKEN
```
    on the anomaly window whenever the endpoint supports window bounds
  - if the endpoint only supports a nearby preset range, use the closest available range and say so
  - use it to identify which accounts contributed the most mindshare quantitatively
- unresolved mode:
  - skip
```
kaito_mindshare_entity_by_account
```
  - identify the most relevant external voices directly from the anomaly-window Twitter corpus, using signal such as repeated presence, smart engagement, and prominence in the anomaly discussion
- for the most relevant contributor handles from either mode, call
```
kaito_twitter_account_type
```
  when available so you can characterize whether the anomaly was driven by KOLs, researchers or traders, builders, or community accounts
account follow-up search
- run
```
kaito_advanced_search
```
  for the most relevant contributor handles from the contributor-attribution step above
- use the same entity search filter from
```
Resolve Entity
```
- add
```
usernames=<top contributor handles>
```
- use the same anomaly time bounds
- paginate when practical so you capture all matching content from those accounts in the anomaly window
- goal: inspect exactly what the main anomaly-driving accounts said

When choosing contributor handles for the account follow-up search, inspect the smallest set that explains the anomaly, usually the top 5 to 10 contributors or the set that clearly dominates the window.

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

kaito_advanced_search

使用“实体解析”阶段生成的实体搜索过滤器：
- 已解析模式：
```
tokens=<RESOLVED_TOKEN>
```
- 未解析模式：
```
keyword=<UNRESOLVED_STRING>
```
设置
```
sources="Twitter"
```
设置
```
sort_by="smart_engagement"
```
设置
```
size=100
```
设置
```
min_created_at=<异常起始时间>
```
设置
```
max_created_at=<异常结束时间>
```

当

EXCLUDED_HANDLES

可用时，设置

exclude_handles=<EXCLUDED_HANDLES>

目标：获取异常窗口内该实体的前100条外部推文

贡献者归因
- 已解析模式：
  - 当端点支持窗口范围时，针对
```
RESOLVED_TOKEN
```
    在异常窗口内调用
```
kaito_mindshare_entity_by_account
```
  - 如果端点仅支持附近的预设范围，则使用最接近的可用范围并说明情况
  - 用此方法定量识别贡献心智份额最多的账号
- 未解析模式：
  - 跳过
```
kaito_mindshare_entity_by_account
```
  - 直接从异常窗口的Twitter语料库中识别最相关的外部声音，依据包括重复出现、智能互动量以及在异常讨论中的突出性
- 对于从任一模式中识别出的最相关贡献者句柄，若可用则调用
```
kaito_twitter_account_type
```
  ，以便判断异常是由KOL、研究者或交易者、开发者还是社区账号驱动
账号跟进搜索
- 针对贡献者归因步骤中识别出的最相关贡献者句柄，调用
```
kaito_advanced_search
```
- 使用“实体解析”阶段生成的相同实体搜索过滤器
- 添加
```
usernames=<顶级贡献者句柄>
```
- 使用相同的异常时间范围
- 尽可能分页，以捕获这些账号在异常窗口内的所有匹配内容
- 目标：查看主要异常驱动账号的具体发言内容

选择用于账号跟进搜索的贡献者句柄时，选择能解释异常的最小集合，通常为前5到10个贡献者，或明显主导该窗口的账号集合。

3.3 Resolve narratives for

Summary and Conclusions

3.3 为“总结与结论”梳理叙事

Before writing

Summary and Conclusions

, do one lightweight narrative check.

Call
```
kaito_narratives
```
to get the canonical Kaito narrative set.
Check whether
```
Summary and Conclusions
```
mentions any narrative from that set.
If a mentioned narrative matches a canonical Kaito narrative, render it with the structured narrative token using the returned
```
narrative
```
value exactly as shown, but keep it embedded naturally inside the sentence that is already making the point.
If a theme in
```
Summary and Conclusions
```
does not match the canonical narrative set, mention it in plain language only and do not invent a structured narrative token.

在撰写“总结与结论”之前，进行一次轻量级叙事检查。

调用
```
kaito_narratives
```
获取标准Kaito叙事集合。
检查“总结与结论”中是否提及该集合中的任何叙事。
如果提及的叙事与标准Kaito叙事匹配，则使用返回的
```
narrative
```
值，以结构化叙事令牌
```
[[narrative:<narrative>]]
```
的形式呈现，但需自然嵌入到已表达该观点的句子中。
如果“总结与结论”中的主题与标准叙事集合不匹配，则仅用普通语言提及，不要创建结构化叙事令牌。

4. Output

4. 输出

Prefer the four-section structure below. If the user asks a specific question, answer it more directly within that structure, especially in

Summary and Conclusions

. If the user does not ask a specific question, use the same structure as the default summary or report.

Render exactly four sections in this order:

```
Summary and Conclusions
```
- lead with the most direct response to the user's request, then summarize the overall social pulse in the requested window and the main conclusion
```
Key Observations
```
- keep this section descriptive and data-first, but still tie the observations back to the user's request
- focus on perception: in resolved mode, lead with the mindshare path and sentiment path, then use mentions and engagement as supporting context; in unresolved mode, focus on the metrics that are actually available
```
Key Insights
```
- explain why the anomalies happened in the context of the user's request
- use the drill-down evidence from top tweets, the best available contributor attribution method for the active mode, and what those accounts actually said
```
Suggested Actions
```
- give concrete next actions that follow from the user's request and the observed perception shifts
- focus on what the team should do because of the observed perception shifts and identified drivers

Do not add extra scorecard or benchmark sections unless the user explicitly asks for them.

Summary and Conclusions

structured rendering rules:

Keep this section high-level and compact. Do not restate full anomaly breakdowns, long tweet examples, or per-window metric detail there.
If you mention an account handle in
```
Summary and Conclusions
```
, render it as
```
@handle
```
. The leading
```
@
```
is the parsing signal for frontend account rendering.
If you mention a resolved narrative in
```
Summary and Conclusions
```
, render it as
```
[[narrative:<narrative>]]
```
, where
```
<narrative>
```
is the exact
```
narrative
```
field returned by
```
kaito_narratives
```
.
Do not add standalone labels or trailing token lists such as
```
Matched narratives: [[narrative:AI]], [[narrative:L2]]
```
.
Prefer natural phrasing such as
```
discussion concentrated around [[narrative:AI]]
```
instead of breaking the sentence just to surface the token.
Keep the structured narrative token in
```
Summary and Conclusions
```
only unless the user explicitly asks for the same rendering elsewhere.

优先采用以下四部分结构。如果用户提出特定问题，请在该结构内更直接地回答，尤其是在“总结与结论”部分。如果用户未提出特定问题，则使用默认摘要或报告的相同结构。

严格按照以下顺序呈现四个部分：

```
总结与结论
```
- 首先直接回应用户的请求，然后总结请求窗口内的整体社交动态及主要结论
```
关键观察
```
- 本部分以描述性和数据优先为主，但仍需将观察结果与用户请求关联
- 聚焦认知层面：在已解析模式下，先呈现心智份额和情感倾向的变化路径，再将提及量和互动量作为支持背景；在未解析模式下，聚焦实际可用的指标
```
关键洞察
```
- 结合用户请求，解释异常发生的原因
- 使用来自顶级推文的钻取证据、当前模式下最佳的账号级归因方法，以及这些账号的具体发言内容
```
建议行动
```
- 根据用户请求及观察到的认知变化，给出具体的后续行动建议
- 聚焦团队应针对观察到的认知变化及已识别的驱动因素采取的措施

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

总结与结论

结构化呈现规则：

本部分需保持高度概括和简洁。不要在此重述完整的异常细分、长推文示例或每个窗口的指标细节。
如果在“总结与结论”中提及账号句柄，请以
```
@句柄
```
的形式呈现。前置的
```
@
```
是前端账号渲染的解析标识。
如果在“总结与结论”中提及已解析的叙事，请以
```
[[narrative:<narrative>]]
```
的形式呈现，其中
```
<narrative>
```
是
```
kaito_narratives
```
返回的精确
```
narrative
```
字段值。
不要添加独立标签或末尾令牌列表，如
```
匹配叙事：[[narrative:AI]], [[narrative:L2]]
```
。
优先采用自然表述，如
```
讨论集中在[[narrative:AI]]相关话题
```
，而非为了展示令牌而拆分句子。
仅在“总结与结论”中使用结构化叙事令牌，除非用户明确要求在其他部分采用相同呈现方式。

Rules

规则

Always analyze the requested window together with trailing 12-month context.
Always anchor the answer to the user's actual request. The four output sections are a response format, not a substitute for addressing the user's prompt directly.
In resolved mode, prioritize
```
mindshare
```
and
```
sentiment
```
over
```
mentions
```
and
```
engagement
```
when framing the main story.
Treat official and affiliate posts as owned-media noise for anomaly root-cause analysis and exclude them whenever practical.
Keep
```
Key Observations
```
quantitative and descriptive. Do not mix in causal speculation there.
Treat
```
mentions
```
and
```
engagement
```
as secondary evidence that helps explain or validate shifts in
```
mindshare
```
and
```
sentiment
```
, not as equal-priority headline metrics in resolved mode.
Put causal interpretation in
```
Key Insights
```
, and tie it to tweet evidence plus the best available account-level attribution method for the active mode.
When contributor classification is available, use it to explain the driver mix instead of only listing handles. Do not invent account roles or unsupported influence labels.
If exclusion, pagination, or time-window support is incomplete for any endpoint, state the limitation clearly instead of hiding it.
If the entity stayed unresolved, make the missing structured metrics explicit instead of filling the gaps with guesswork.
If the entity stayed unresolved, say clearly that drill-down and trend analysis are keyword-based and entity precision may be weaker than in resolved-token mode.
If no anomaly is found, say so explicitly and focus the report on long-cycle trend context.
Say
```
smart accounts
```
, never
```
smart money
```

始终结合过去12个月的背景信息分析请求窗口。
始终紧扣用户的实际请求。四个输出部分是响应格式，不能替代直接回应用户的提示。
在已解析模式下，构建核心结论时优先考虑
```
mindshare
```
和
```
sentiment
```
，而非
```
mentions
```
和
```
engagement
```
。
在异常根因分析中，将官方和关联账号的帖子视为自有媒体噪音，尽可能排除。
```
关键观察
```
部分需保持量化和描述性。不要在此加入因果推测。
在已解析模式下，将
```
mentions
```
和
```
engagement
```
视为辅助证据，用于解释或验证
```
mindshare
```
和
```
sentiment
```
的变化，而非同等优先级的核心指标。
将因果解释放在
```
关键洞察
```
部分，并结合推文证据及当前模式下最佳的账号级归因方法。
当贡献者分类可用时，用它来解释驱动者构成，而非仅列出句柄。不要编造账号角色或无依据的影响力标签。
如果任何端点的排除、分页或时间窗口支持不完整，请明确说明限制，而非隐藏。
如果实体未被解析，请明确说明缺失的结构化指标，而非用猜测填补空白。
如果实体未被解析，请明确说明钻取和趋势分析基于关键字，实体精度可能低于已解析token模式。
如果未发现异常，请明确说明，并将报告重点放在长期趋势背景上。
使用“smart accounts”（智能账号），绝对不要使用“smart money”（聪明资金）

TODO

待办事项

Add these planned metric extensions once the corresponding MCP endpoints exist:

rolling unique smart accounts
- add a dedicated MCP endpoint for rolling unique smart-account participation over time
- use it as an additional perception-quality signal alongside mindshare, sentiment, mentions, and engagement
sentiment mix
- add a dedicated MCP endpoint for sentiment-mix breakdown over time
- use it to enrich the sentiment read beyond a single aggregate sentiment series

当对应的MCP端点可用后，添加以下计划中的指标扩展：

滚动唯一智能账号
- 添加专门的MCP端点，用于追踪随时间变化的滚动唯一智能账号参与情况
- 将其作为心智份额、情感倾向、提及量和互动量之外的额外认知质量信号
情感倾向细分
- 添加专门的MCP端点，用于追踪随时间变化的情感倾向细分情况
- 用它丰富情感倾向分析，超越单一的聚合情感时间序列