apify-trend-analysis – AI 趋势数据分析 Skill

3周前更新 8 0 0 0

apify-trend-analysis 是帮助 AI Agent 抓取并分析 Google 搜索、网页及社交媒体趋势数据的 Skill，适合市场调研、内容选题和竞品动态追踪场景。

查看调研报告 在来源平台打开

Skill 安装

多 Agent 安装 
npx skills add https://github.com/apify/awesome-skills --skill apify-trend-analysis

使用 npx skills 快速安装，支持将 Skill 添加到多个兼容的 AI Agent。

Skill 调研报告

Skill 详细介绍

apify/awesome-skills#apify-trend-analysis 是 Apify 官方 awesome-skills 仓库中的一个 Skill，用于借助 Apify 平台上的数据采集能力，对指定主题、关键词、品牌或市场进行趋势分析。它的核心价值不是“预测未来”，而是把分散在各平台上的公开数据（搜索结果、社交讨论、热度信号等）采集下来，整理成可读的趋势判断依据。

安装后，Agent 增加的能力大致包括：

  • 根据主题或关键词规划一次趋势分析任务；
  • 通过 Apify 上的相关 Actor 采集公开数据；
  • 对采集结果做归纳，输出趋势方向、热度变化、话题聚类等结论；
  • 把结果整理成适合汇报、调研或内容选题使用的结构化摘要。

需要分清两件事：

  • Skill 本身主要提供的是“趋势分析的流程与指令”，它告诉 Agent 该采集什么、怎么组织、怎么归纳；
  • Apify 平台提供真正执行采集的运行时和 Actor 能力，实际的数据抓取发生在 Apify 侧，而不是本地 Agent 内。

它本质上是一个面向 Agent 的分析工作流型 Skill，不是独立运行的软件，也不是一个本地爬虫程序。典型任务包括：某关键词近期热度变化、某品牌在社媒上的讨论趋势、某话题的内容走势、某市场细分方向的热度对比。适合做市场调研、内容选题、竞品观察、舆情初步判断的用户。不适合需要严格统计学意义、需要长期高频监控或需要付费数据源授权才能拿到的深度商业数据。

Skill 安全评估

总体判断：这是一个来源可信度较高、风险主要来自第三方平台与凭证管理的 Skill。它本身不包含可疑的本地执行逻辑，但它会引导 Agent 调用 Apify 采集能力，因此安全性重点在 Apify 账号凭证和采集行为合规上。

需要关注的点：

  • 来源可信度：Skill 来自 Apify 官方组织的 awesome-skills 仓库，属于官方一手来源，不是第三方镜像或同名重发版本。
  • 第三方 API 依赖：实际采集依赖 Apify 平台。这意味着需要 Apify 账号和 API Token，数据会经过 Apify 服务端。
  • API Token 敏感：Apify Token 一旦泄露，可能被他人消耗你的账户额度。不要把 Token 写进公开仓库、聊天记录或截图。
  • 网络访问：Skill 工作需要联网访问 Apify 平台和目标数据源，这是其正常用途的一部分，不代表危险。
  • 采集合规：趋势分析通常针对公开数据，但采集目标平台的服务条款、robots 约定、当地法律（含数据保护法规）需要用户自行判断，Skill 不会替你承担合规责任。
  • 费用：Apify 上很多 Actor 按用量计费，大规模或高频采集会产生实际费用，建议先小规模测试。
  • Prompt Injection 风险：采集回来的网页/帖子内容可能包含恶意指令文本。交给 Agent 归纳时建议把它当作待分析的数据，而不是可执行指令。

降低风险的做法：

  • 使用独立、权限最小化的 Apify Token，避免用主账号全权限 Token；
  • 先在 Apify 控制台手动跑一次目标 Actor，确认行为与花费再交给 Skill 自动化；
  • 对敏感主题的趋势分析，避免把内部业务数据作为查询关键词上传到第三方平台。

Skill 使用要求

一、Agent / 客户端

该 Skill 以 Agent Skill 的形式提供，适合支持 Skill / 自定义指令加载机制的 AI Agent 使用。官方没有公布完整的第三方 Agent 兼容列表。从 Skill 的工作方式看，Claude Code 这类原生支持 Skills 的环境可以优先尝试；Codex、Cursor、Trae、OpenClaw、WorkBuddy 等是否可直接加载，取决于对应 Agent 当前版本的 Skill 支持情况，具体以各 Agent 官方说明为准。

二、运行环境 / 依赖

项目 要求
Agent 支持 Skill / 自定义指令的 Agent
网络 需要，用于访问 Apify 平台及目标数据源
Apify 账号 需要，用于执行采集
Apify API Token 需要，用于授权采集

Skill 本身是否需要额外的本地运行时（如特定 Node.js 或 Python 版本），当前官方资料未明确说明，以该 Skill 当前官方说明为准。

三、权限

  • 网络访问：必需（访问 Apify 及数据源）
  • Apify 账号 / API Token：必需（授权采集）
  • 文件读写：可选，取决于是否让 Agent 保存分析结果
  • Shell：通常非必需，除非你的 Agent 需要命令行调用 Apify CLI，是否开启由你决定

四、账号 / API Key

Skill 本身需要 Apify 账号与 API Token 才能实际采集数据。这一点要和“分析结果落地的项目”区分开：项目侧若还需要其他凭证，属于项目自身需求，不是这个 Skill 的硬性要求。

最小使用条件

  • 一个支持 Skill 的 Agent；
  • 可联网；
  • 一个 Apify 账号及 API Token。

Skill 安装、使用与卸载教程

一、安装

本页面已经提供 apify/awesome-skills#apify-trend-analysis 的 Skill 安装指令，直接复制并粘贴到你的 Agent 或终端执行即可。

如果你不确定当前 Agent 该怎么装，可以直接问它：

如何安装 apify/awesome-skills#apify-trend-analysis？

如何在 Claude Code 中安装 apify/awesome-skills#apify-trend-analysis？

如何在 Cursor 中安装 apify/awesome-skills#apify-trend-analysis？

让 Agent 根据自己的 Skill 加载机制指导你完成安装。该 Skill 依赖 Apify 平台，安装后通常还需要在 Apify 侧完成账号与 Token 配置，具体以官方说明为准。

二、安装后如何使用

安装后，当你提出趋势、热度、话题走势、市场方向类需求时，可以显式点名该 Skill 触发它。适合交给它的任务：关键词趋势、品牌讨论走势、话题热度对比、内容选题方向判断。

使用 apify-trend-analysis，帮我分析“家用咖啡机”最近一个月的搜索和讨论趋势。

使用 apify-trend-analysis，对比一下“AI 笔记”和“AI 会议纪要”两个话题近期的热度差异。

使用 apify-trend-analysis，看看某品牌在社媒上的讨论趋势是上升还是下降，并给出依据。

三、卸载

不同 Agent 的 Skill 安装位置与管理方式不同。最简单的做法是使用对应 Agent 或 Skill 管理器提供的删除方式移除该 Skill，或者直接问当前 Agent：

如何卸载 apify/awesome-skills#apify-trend-analysis？

如果没有统一卸载命令，直接让 Agent 按它的管理机制移除通常更稳妥。当前官方未明确提供统一卸载命令，不建议照搬来源不明的删除脚本。

常见问题

1. 这个 Skill 可以离线用吗？

基本不行。它的采集依赖 Apify 平台，需要联网。离线环境最多只能做提示词层面的讨论，无法真正采集与分析。

2. 中国大陆网络环境使用是否受限？

Apify 属于境外平台，中国大陆网络访问其服务可能需要自行解决网络可达性问题。这是网络环境问题，不是 Skill 本身的功能限制。

3. 不使用 Apify 账号能用吗？

不能完成实际采集。Skill 的分析流程围绕 Apify 采集结果展开，没有账号和 Token 就没有真实数据源，输出的趋势判断会失去依据。

4. 用这个 Skill 会产生费用吗？

很可能。Apify 上部分 Actor 按用量计费，数据量大或频率高时费用会上升。建议先小规模试跑，确认单价和消耗后再扩大。

5. 为什么安装后 Agent 没识别到 Skill？

常见原因有：安装路径不被当前 Agent 扫描、Agent 版本不支持该 Skill 形式、需要重启会话或重新加载。先确认安装成功，再让 Agent 自检是否加载到了该 Skill。

6. 趋势分析结果可靠吗？

它反映的是所采集公开数据的信号，不等于严谨的统计预测。适合用作方向参考和选题判断，不建议直接作为投资或重大商业决策的唯一依据。

7. 可以同时装到多个 Agent 吗？

通常可以，前提是各 Agent 都支持 Skill 加载且安装方式互相独立。不同 Agent 的目录和管理机制不同，分别按各自方式安装即可。

Skill 更新日志

版本列表
无版本号
chore: 重新生成 marketplace.json、AGENTS.md 和 README [bot]
无版本号
添加 apify-orchestrator-actor-development 技能 (#72) * 添加 apify-orchestrator-actor-development 技能 构建 TypeScript Apify 编排器 Actor —— 使用 apify-orchestrator 库协调一系列子 Actor（可选带有一个 LLM 步骤）。交互式脚手架流程， 包含 Apify MCP schema 发现、通过 maxTotalChargeUsd 实现的每步成本预算， 以及 OpenRouter LLM 步骤。 Co-Authored-By: Claude Opus 4.7 * fix(apify-orchestrator-actor-development): 修正成本跟踪、子任务状态检查和 MCP 字段名 对照实时 Apify 平台和 Apify MCP 服务器进行测量；以下每项更改 都有一次运行或一次调用作为依据，而非仅凭审查。 成本跟踪（返回的 Run 报告 $0）： - `run.usageTotalUsd` 在 `.call()` 返回的对象上为 0，而且它不会随后 完整到达 —— 按事件付费的子任务在达到 SUCCEEDED 后数秒内仍会按每个 计费事件收费。实测：一个两项子任务在约 3 秒时读取为 $0.0020，最终 结算为 $0.0040，而一个同级任务在 8 秒时仍读取为 $0。采用返回值会 使整个工作流的 `spent` 保持为 0，因此累计总额从未变动。 - 将每个子 Run 记录在账本中，并等待其费用稳定下来，而不仅仅是变为 非零；在每次预算决策前和退出时重新读取已记录的 Run，这样延迟的 费用仍能计入总额。 - 修正关于累计总额可防止失控支出的说法。在均分且子任务遵守其上限的 情况下，该保护无法在最后一步之前触发；它是对未设上限步骤的兜底， 且仅当超支已及时累积完成时才有效。实测：一个未设上限的步骤在总额 $0.0030 的情况下收费 $0.0040，而下一步仍然启动了。 子任务状态（失败的步骤看起来像空步骤）： - FAILED、ABORTED 或 TIMED-OUT 的子任务返回一个带有 dataset id 的 Run 对象，读取该 dataset 会得到 [] 而非错误 —— 在一个 TIMED-OUT 子任务 上实测。模板直接调用 listItems()，因此失败的步骤被当作空步骤处理， 工作流报告成功但无数据。添加了 requireSucceeded() 以及一个描述该 失败模式的注意事项。 Apify MCP 字段名（在 apify-mcp-server 0.16.0、7 个 Actor 上实测）： - `fetch-actor-details` 参数是 `actor`，不是 `actorId`；`actorId` 会失败 并报 "must have required property 'actor'"。 - 定价位于 `actorInfo.pricing`，不是 `pricingInfo`。对于按事件付费的 Actor，它会逐项列出费用，这正是设定上限所需的信息。 - 描述上没有 REQUIRED 前缀（7 个 Actor 中 0 个）；必填字段通过标准的 `inputSchema.required` 数组传递。两条指示 agent 高亮 REQUIRED 前缀 字段的说明指向了空处。 - 枚举列表不会截断到 200 字符：google-search-scraper 返回了全部 240 个 countryCode 值（480 字符）。 - 所有 7 个 Actor 都缺少 `outputSchema`，包括本技能自己的示例。 同时添加必需的 `metadata` 块（keywords、category: actor-development）； 没有它 scripts/generate_agents.py 会无法通过目录 lint。 Co-Authored-By: Claude Opus 5 * chore: 从技能 PR 中移除生成的目录文件 marketplace.json、agents/AGENTS.md 和 README 技能表由 SKILL.md frontmatter 生成，并在合并后由 bot 重新生成；技能 PR 必须只触及 skills/apify-/（validate-pr 范围检查）。 Co-Authored-By: Claude Opus 5 --------- Co-authored-by: Claude Opus 4.7 Co-authored-by: pavel242242
无版本号
chore: 重新生成 marketplace.json、AGENTS.md 和 README [bot]
无版本号
添加 apify-blocked-scrape-triage 技能 (#84) * 添加 apify-blocked-scrape-triage 技能 针对返回空结果的抓取进行分诊：在花费任何成本之前，区分硬封锁与 托管挑战、死路径和渲染问题，然后按成本顺序升级，浏览器放在最后。 * 纳入关于分诊技能的审查反馈 - 在使用某 CDN 厂商的挑战标记之前先确认厂商名称，并让正文覆盖 缺失的响应头 - 解释为什么解除盲化的修复是一个 hook：Actor 输入不包含任何 Crawlee 的 session-pool 选项，这是对照构建 schema 实测的 - 将住宅代理探测设为需先询问，并优先选择免费的第二个观测点而非 付费运行 * 将目录元数据移入 SKILL.md frontmatter 目录现在由 frontmatter 生成，因此 keywords 和 category 位于 SKILL.md 中，手写的 marketplace.json 条目已移除。 * fix(apify-blocked-scrape-triage): 修正实测结论、保护 pageFunction、设置 category 于 2026-09-21 对照实时平台验证；详情如下。 代码修复： - 两个示例 pageFunction 都未加保护地调用了 context.$。在响应没有 HTML 正文时 —— 例如空正文的 403，或 text/plain，即本技能所诊断的情形 —— context.$ 不是函数，pageFunction 会抛出异常。该项随后带有 #error， 与没有该 hook 的运行无法区分，因此 hook 的效果在下一行就被抵消。 实测：一次运行中 6 次失败。现已加保护；当没有 HTML 时，依赖 $ 的 字段返回 null。已针对 403（可读状态，无抛出）和 HTML 页面（title、 scripts、mountPoints、offHostLinks 不变）重新测量。 修正的结论： - 该 hook 的标题数字将 "items carrying fields" 列引用为 "classified refusals"。根据本技能自己的表格，classified 计数从 0 -> 2，而 3 -> 6 是 items carrying fields。 - `gotOptions.throwHttpErrors = false` 表格行并未测量某个设置： gotOptions 不在该 Actor 的 30 个输入字段中，且该 Actor 接受包含它的 输入而不会产生验证错误，并会静默丢弃它。该行已移除，发现已在原处 说明。 - application/json 和 application/xml 属于 cheerio-scraper 的默认 MIME 类型，因此 JSON 端点根本不需要 additionalMimeTypes。该 Actor 在其 跳过错误中列出了自己允许的列表。（该 Actor 发布的 schema 描述在 这一点上已过时。） - 完整账户审批并非仅限浏览器：cheerio-scraper 和 web-scraper 也需要它， 因此这不是偏好其中一个的理由。已添加到 Prerequisites，其失败模式在 那里很重要：stdout 且退出码为 0。 新增： - proxyConfiguration 通过 MCP 是必需的，但通过 CLI 不是。 - CLI 接受 additionalMimeTypes，而 MCP 在任何编码下都拒绝它。 元数据： - category: data-extraction -> actor-development Co-Authored-By: Claude Opus 5 --------- Co-authored-by: pavel242242 Co-authored-by: Claude Opus 5
无版本号
chore: 重新生成 marketplace.json、AGENTS.md 和 README [bot]
无版本号
添加 apify-jobs-data 技能 (#40) 添加 apify-jobs-data 技能：通过 agentx/all-jobs-scraper 跨 20+ 个招聘 网站提取职位发布，具备跨网站去重、启发式幽灵职位和转载标记、规范化 字段，以及在其之上的分析 / 导出 / 简历匹配模式。 在维护者对贡献者分支进行一轮审查后合并：验证了实时 Actor schema 和 定价，按 Actor 修正了上限字段名，删除了 Google Jobs 承诺（不在聚合器 枚举中），重建了简历匹配示例以去除捏造的证据，围绕抓取的职位描述添加 了提示注入边界，并解决了路由矛盾，使一个返回区域内无结果的具名网站 获得一次有上限的回退运行，而不是被直接放弃。 通过对照 Actor 自身文档的配对评估验证（9 月 16 日和 21 日）： 0 个捏造值，每个统计量都可从记录重新计算，且 7 次 Actor 运行中无策略 偏差。 Co-authored-by: oleg martinez Co-Authored-By: Claude Opus 5
无版本号
chore: 重新生成 marketplace.json、AGENTS.md 和 README [bot]
无版本号
添加 apify-app-store-intelligence 技能 (#89) 两个提交：技能由 @donnywin85 提供，以及一个维护者提交，纳入了来自 #41 和 #54 的 Google Play 工作。 取代： - #41 由 @Freshactors 提供 —— freshactors/google-play-scraper mode=details， 带有 1–5★ 的 ratingHistogram、按模式的成本模型，以及跨商店标识符速查表 - #54 由 @0xsline 提供 —— neatrat recentDays 用于硬性日期窗口，以及 sortBy "newest" / appVersion 作为真实输入字段
无版本号
feat(apify-app-store-intelligence): 纳入 #41 和 #54，对照实时 API 修正路由事实 - 来自 #41 的 Google Play 模块（@Freshactors）：freshactors/google-play-scraper mode=details， 带有 $0.002/应用 的 ratingHistogram、按模式的成本模型和跨商店标识符速查表 - 来自 #54 的 Google Play 窗口事实（@0xsline）：neatrat recentDays，以及 sortBy "newest" / appVersion 是真实输入字段，尽管该 Actor README 记录的是其他字段 - 路由表现在为每个被路由的 Actor 都带有上限和价格（价格读取自实时 Actor 定价 2026-09-18），包括此前留作 "see schema" 的故障开放默认值 - Apple 确实发布 1-5 星直方图：sourabhbgp/apple-app-store-scraper mode=app-details 返回的 ratingsHistogram 总和等于 userRatingCount；includeVersionHistory 不额外收费 （2026-09-19 实测：有无均为 $0.004） - changesOnly 按其实际行为记录：该模式下的首次运行会输出每个应用并作为 基线，快照在整个 Apify 账户间共享，评分以 5 位小数精度进行差异比较， 且源被边缘缓存约 24 小时，因此同日的版本更新可能被遗漏 - apify actors info 接受 --input 而无需 --json（CLI 1.10.0 否则会隐藏 schema） - brilliant_gum 版本可以是字面量 "VARY"；评论文本标记为不可信内容 - 目录产物（marketplace.json、README 表格、agents/AGENTS.md）已还原为 main； bot 会在合并后从 SKILL.md frontmatter 重新生成它们 Co-Authored-By: Claude Opus 5
无版本号
chore: 为 apify-app-store-intelligence 重新生成目录 该技能在 d32f471 中添加时未重新生成生成的目录，因此 marketplace.json、 agents/AGENTS.md 和 README 技能表未列出它。PR 工作流会重新生成目录并 进行比较；fork PR 的 token 无法将结果推送回去，因此该任务会失败而非 自愈。 由 scripts/generate_agents.py 生成，无手动编辑： 写入 14 个插件。纯新增 —— 26 处插入，0 处删除。 Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01MQCHGvdKdAa9fZroPjrXte
无版本号
fix(apify-osint-threat-intel): 替换已弃用的租赁 Reddit Actor，强制时效性，设置新闻时间范围 (#125) * fix(apify-osint-threat-intel): 将已弃用的 trudax/reddit-scraper 替换为 harshmaur/reddit-scraper trudax/reddit-scraper 在商店中已弃用（租赁，$45/月）。将三个 Reddit 步骤路由到 harshmaur/reddit-scraper，它已是此处的回退方案，也是 apify-easy-competitive-intelligence 中 main 分支的回退方案，其输入已 通过实时运行验证：withinCommunity 恰好接受一个 subreddit（"A OR B" 值会静默丢弃过滤器并搜索整个 Reddit），postedAfter 强制窗口 （searchTime 不会 —— 该 Actor 会用多年前的帖子填充上限）， maxPostsCount 是按搜索词计的，没有 proxy 字段。故障排除现在指向 RUN-SUMMARY（inputWarnings、emptyReason）以及 fatihtahta/reddit-scraper-search-fast 作为按项付费的回退方案。 Co-Authored-By: Claude Opus 5 * fix(apify-osint-threat-intel): 在 google-news-scraper-fast 示例中设置 timeframe 该 Actor 的 `timeframe` 默认为 `1h`，因此 "recent activity" (2c) 和 "landscape" (2d) 新闻调用几乎返回不了任何内容，除非模型猜到了该字段。 为威胁行为者活动设置 `30d`，为每周态势设置 `7d`，与评估运行 （E3、E4、E8、E9）不得不手动添加的内容一致。 Co-Authored-By: Claude Opus 5 --------- Co-authored-by: Claude Opus 5
无版本号
chore: 重新生成 marketplace.json、AGENTS.md 和 README [bot]
无版本号
添加 apify-reddit-scraper 技能 (#114) * feat: 添加 apify-reddit-scraper 技能 * fix(apify-reddit-scraper): 按词成本公式、相对时间段的 postedAfter、实时 schema 事实 在作者设计之上的维护者文本修正（无结构性更改）： - maxPostsCount 是按搜索词计的；成本公式 = 词数 × maxPostsCount × (1 + maxCommentsPerPost)，附来自实时运行的示例计算 - "last month" → postedAfter（强制 sort=new），并明确说明与 searchTime 的权衡 - 运行前显示可见的运行部分（词数、估算）；运行后检查估算 ≥ 结算值 - dataType user → user_profile；帖子上的 searchTerm 为 null，评论上缺少 postTitle；removed_by 为 snake_case - 错误行与实时 README 一致（错误日期 = 故障开放，无目标 = 0 项） - aiAnalysis 在 Free 上计费；UGC 防护语句；--user-agent 仅在可接受处使用 在三次隔离的评估运行中测量（R4/R4b/R4c，0 个捏造值）。 Co-Authored-By: Claude Opus 5 --------- Co-authored-by: Harsh Maur Co-authored-by: Pavel Chocholous Co-authored-by: Claude Opus 5
无版本号
chore: 重新生成 marketplace.json、AGENTS.md 和 README [bot]
无版本号
还原手动目录重新生成 目录文件由合并后重新生成工作流负责。此操作还原 e1245ea，以便修复后的 GITHUB_TOKEN 任务能够证明完整流程。
无版本号
Merge pull request #124 from apify/codex/use-github-token-catalog-regen 使用 GITHUB_TOKEN 修复目录重新生成
无版本号
fix: 使用 GitHub token 重新生成目录
无版本号
为 apify-plan-travel 重新生成目录
无版本号
Merge pull request #123 from apify/codex/consolidate-apify-travel-skills 添加整合后的 Apify 旅行规划技能
无版本号
添加整合后的 Apify 旅行规划技能
无版本号
Merge pull request #69 from johnisanerd/add-apify-yandex-search-api 添加 apify-yandex-search-api 技能
无版本号
将 Yandex Images 合并到 main 后重新生成目录
无版本号
Merge pull request #70 from johnisanerd/add-apify-yandex-image-search-api 添加 apify-yandex-image-search-api 技能
无版本号
合并 main 并应用已审查的 Yandex 图片技能修正
无版本号
合并 main 并应用已审查的 Yandex 网页技能修正
无版本号
Merge pull request #106 from johnisanerd/add-apify-company-data-api 添加 apify-company-data-api 技能
无版本号
Merge pull request #107 from johnisanerd/add-apify-marketing-agency-database 添加 apify-marketing-agency-database 技能
无版本号
应用已审查的 Clutch 技能修复并重新生成目录 (#106)
无版本号
应用已审查的 Clutch 技能修复并重新生成目录 (#107)
无版本号
Merge pull request #93 from luispintoapify/add-apify-product-data-setup 添加 apify-product-data-setup 技能

暂无评论

none
暂无评论...