---
title: "在 Cursor 中用 Minds MCP 构建一个营销调研智能体"
description: "完整演练：在 Cursor 中构建一个自定义营销调研智能体，从 PostHog 拉数据、跑 Minds 面板、向 Slack 推送结果。"
canonical_url: "https://getminds.ai/blog/zh/build-marketing-research-agent-cursor-minds-mcp"
last_updated: "2026-06-22T02:07:00.063Z"
---

# 在 Cursor 中构建一个营销调研智能体

这份指南是给那些想自己构建一个自定义营销调研智能体、而不是用现成产品的人。最终结果是一个跑在 Cursor 里的智能体：用自然语言接收一个调研 brief，从 PostHog 拉产品分析数据，用 Minds 跑一个合成面板，把两边交叉对照，然后把摘要推到 Slack。如果你已经在这三个服务上有账号，端到端大约 90 分钟。

重点不是发布一个打磨过的产品，而是把智能体循环具体化：智能体接收 brief、按顺序调用多个 MCP 服务器、对联合结果做推理、回报给团队。一旦你构建过一次，这个模式可以拼装到你想搭的任何东西上。

## 前置条件

三个账号、三把 API 密钥：

- 一个 Minds 账号，配一把 API 密钥（`minds_…`）。没有就到 getminds.ai 注册。
- 一个 PostHog 账号，配一把个人 API 密钥。
- 一个 Slack 工作区，可以通过 webhook 或 app token 向频道发消息。

一份 Cursor 安装（或者任何带 MCP 支持的编辑器：VS Code 配 Copilot 的玩法是一样的）。

大约 30 分钟专注的搭建时间，再加上 60 分钟在 brief 和提示上的迭代。

## 第 1 步：连上三个 MCP 服务器

三项服务每一个都暴露了一个 MCP 服务器。我们把三个都连进 Cursor。

在 Cursor 里打开 Settings → MCP，添加三个服务器。

*Minds.* 添加一个新服务器，URL 填 `https://getminds.ai/mcp`，用 OAuth 授权。Minds 的 12 个工具（`create_panel`、`ask_panel`、`export_panel` 等）会出现在你的工具选择器里。

产品文档从 [Minds MCP 服务器概览](/mcp/overview) 开始；按客户端操作请使用 [Minds MCP 设置指南](/mcp/setup)。

*PostHog.* PostHog 自己发布了 MCP 服务器。推荐用远程端点 `https://app.posthog.com/mcp`，同样走 OAuth。你会拿到 55 个工具，覆盖事件、漏斗、cohorts、仪表盘。

*Slack.* Slack MCP 服务器通过 npm 提供。把它作为 stdio 服务器添加进来：`npx -y @modelcontextprotocol/server-slack`，环境变量里放你的 Slack bot token。两个工具就够：`slack_post_message` 和 `slack_list_channels`。

重启 Cursor。三个服务器都应该出现在智能体的工具列表里。让智能体分别列出面板（Minds）、cohorts（PostHog）、频道（Slack），逐一测试。

## 第 2 步：挑一个值得自动化的调研工作流

智能体的有用程度，取决于你给它的工作流。挑具体的东西。我们要构建的例子：

> 给一个 feature 名字，到 PostHog 找出过去 30 天用过这个 feature 的用户，通过 Minds 把他们刻画成一个合成人物角色，问这个人物角色他们为什么会推荐或不推荐这个 feature，然后把摘要发到 Slack 的 #product-research。

这种模式（真实数据锚定 + 合成增强 + 团队分发）能在很多种决策里复用。把它替换成你自己的就行。

## 第 3 步：写智能体提示

把智能体提示放在 Cursor 的 `.cursorrules` 文件里，或者作为你智能体会话的系统消息。能跑通的结构：

```text
You are a marketing research agent. Your job is to take a feature name as input
and return a recommendation summary, posted to Slack.

For each request, do the following in order:

1. Use PostHog tools to find users who triggered the feature event in the last
   30 days. Get a count and basic properties (plan tier, account age, region).

2. Build a Minds persona that matches the dominant cohort from step 1. Use
   `create_mind` with a description that captures the cohort's plan tier,
   tenure, and likely role.

3. Create a panel of three personas matching that profile, using `create_panel`
   then `ask_panel`. Ask: "Would you recommend this feature to a colleague?
   Why or why not? What would have to change for it to be a yes?"

4. Cross-reference the panel response against the PostHog data. Look for
   alignment (do the panel's stated reasons match the actual usage patterns?)
   and gaps (does the panel surface concerns the metrics don't show?).

5. Post a summary to #product-research in Slack with three sections:
   - Cohort profile (who used it)
   - Panel verdict (recommend or not, top stated reasons)
   - Recommended action (what to do next)

Keep the Slack summary under 500 words. Link back to the full panel export.
```

这条提示有意做了三件事：

- 把步骤硬性排序，让智能体不会抄近路。
- 告诉智能体怎么把多个工具的结果组合起来，而不仅仅是怎么调它们。
- 给输出加上界限，让 Slack 消息真的能读得下去。

## 第 4 步：在一个真实 feature 上测试

挑一个你产品真发布过的 feature，跑这个智能体。预期的执行序列：

1. 智能体调 PostHog 的 `events` 查询，按 feature 名字和过去 30 天过滤 `feature_used`，返回一个数量和样本。
2. 智能体调 PostHog `cohorts` 来刻画用户，识别出主导的套餐档位和平均账户年龄。
3. 智能体调 Minds `create_mind`，描述类似"中端付费客户，平台上 6 到 18 个月，<span>

feature 类别

</span>

 的主要使用者"。
4. 智能体调 Minds `create_panel`，用三个上述人物角色。
5. 智能体调 Minds `ask_panel`，问推荐问题。
6. 智能体读取回答，调 Minds `export_panel`，把完整会话保存下来给 Slack 链接用。
7. 智能体调 Slack `slack_post_message`，发出结构化摘要和导出链接。

端到端时间：60 到 120 秒，取决于 cohort 大小和面板回答长度。端到端成本：大约 0.15 美元的 MCP 调用费用，加 0.05 美元的智能体推理费用。

任何一步失败，智能体通常会重试一次或绕路。如果卡住，最常见的原因是第 4 步那段提示太脆（人物角色描述与 cohort 不干净地匹配）。把人物角色描述改得更灵活，再跑一次。

## 第 5 步：把它调度起来

智能体只有在你不在场的情况下也能跑，才会真正产生价值。两条路：

*通过 Slack 手动触发。* 加一个 `/research [feature 名]` 斜杠命令，触发 Cursor 智能体。这是最简单的路，适合临时调研。

*Cron 触发。* 用一个 CI 工作流（GitHub Actions、Linear 自动化、任何能按时间表运行的东西），每周一把一组 feature 名字打到智能体端点。智能体每个 feature 跑一次工作流，逐条发摘要。团队就能在每周一早上拿到一份调研摘要，零人力开销。

Cron 这条路是价值复利所在。一个团队连续一个季度在每个发布的 feature 上跑 feature 级别的调研，会比一个团队一年做一个大研究，对自己产品了解得多得多，而成本不到 5%。

## 自定义智能体相对现成产品的优势

不用打包好的调研工具、自己来构建，理由是：

*工作流的具体性。* 现成工具是为最常见的情况优化的。你团队的调研工作流很少是最常见的情况。一个自定义智能体能精准贴合你的决策节奏。

*工具组合。* 真正有意思的事，发生在合成调研被锚定到真实产品数据上、再被分发到你团队频道里的时候。没有现成工具能做完整条链。一个把三个 MCP 串起来的自定义智能体可以。

*成本控制。* 你按调用、按服务付费。没有按席位的许可证，没有上面再叠一层平台费。重度使用在团队规模上比打包工具便宜；轻度使用基本相当于免费。

*迭代速度。* 改工作流就是改提示。没有供应商路线图，没有功能请求。约束是你自己的注意力，而不是别人的发布周期。

## 常见坑

在生产里跑这套东西的几个尖角：

- *跨调用的人物角色漂移。* 如果你每次跑都新建一个 Mind，人物角色画像每次会有微妙差异。把这个 Mind 持久化一次（缓存 ID），之后复用。Minds MCP 暴露 `list_minds` 就是为了这个。
- *PostHog 查询超时。* 大 cohort 会让智能体超时。在提示里给 cohort 大小封顶，或者预过滤到一个有代表性的样本。
- *Slack 消息大小限制。* Slack 会截断超过 4000 字符的消息。提示里 500 字的上限远在这之下，但如果智能体不听话，改成发到 thread 里而不是单条消息。
- *OAuth token 轮换。* 三个服务都会周期性轮换 token。智能体突然不工作的话，先把每个连接器重新授权一遍，再去 debug 提示。

## 这条路通向哪里

单 feature 推荐工作流是起点。一旦它跑通，同一个智能体就能泛化到：

- 每周的活动效果回路（活动上线前用合成跑一遍广告反应，上线后用真实点击率验证）
- 每月的竞品定位（用合成面板跑竞品的信息，再交叉对照你自己的转化数据）
- 每季度的人物角色刷新（基于观察到的产品行为变化更新合成人物角色）

每一个都是同一个形状：真实数据锚定、合成增强、团队分发。先把第一个搭出来，剩下的都是变体。

要看身边还值得连什么，参见[2026 年营销与研究 Agent 最值得接入的 MCP 服务器](/blog/best-mcp-servers-marketing-research-agents-2026)。要看底层品类，参见[智能体市场调研：定义](/blog/agentic-market-research-definition)。要看合成输出的信任问题，参见[验证智能体调研输出](/blog/validating-agentic-research-output-eval-frameworks)。