# Cursor Build Live Apps 做竞品评论看板：每天不到 1 美分

> 用 Cursor 一句话发布的网页应用接 EveryInfra，每天拉竞品在应用商店、Trustpilot 和 Reddit 的评论，Key 只放服务端。

- Canonical page: https://everyinfra.com/blog/cursor-build-live-apps-competitor-review-board
- Published: 2026-11-13T23:47:00+08:00 · Fact-checked: 2026-11-13T22:40:00+08:00

Cursor 在 2026 年 11 月 5 日上线了 Build Live Apps：在云端 agent 里说一句「build an app」，它会把网页应用搭好，按需建 Postgres，配上 Cursor 登录，托管并给出一个链接。我们照着它的文档，给一个做预算应用的三人团队写了一块竞品评论看板：每天早上自动拉 YNAB 和 Monarch 在 App Store、Google Play、Trustpilot 上的最新评论，再加 Reddit 上把两家放在一起讨论的帖子；后端只调 EveryInfra 的 `POST /api/v1/social`，Key 存在 Cursor 的团队密钥里，代码只读环境变量名，浏览器和 agent 都看不到值。Cursor 一侧我们没有运行，提示词、刷新路由和定时触发都标为配置示例；数据一侧在 2026 年 11 月 13 日晚上 21:31、22:14、22:36（新加坡时间）三个时刻按看板的同一组调用各跑了一轮，另取西班牙区的记账应用 Fintonic 作对照，看同一套做法在非英语市场拿到什么。

第一，每天刷新一次要 7 次调用，按目录价 $0.009126，30 天约 $0.27，比一个 Premium 席位月费的 1% 还少。第二，App Store 三轮返回的 30 条评论一条没变，最新一条评论已经是 56.7 到 58.7 小时前的；评论在商店里本来就晚一两天公开，按小时刷新只会把账单放大 24 倍。第三，Google Play 和 Trustpilot 前两轮返回 503，没扣费，第三轮重试后成功；看板要按来源分开记录「上次成功时间」，一栏没刷新不拖累其余几栏。第三轮的数据里还有一条：YNAB 在 Trustpilot 上最新 20 条评价有 18 条是公司邀请来的，五星占 75%；Monarch 的最新 20 条全是用户自己来写的，一两星占 90%。

> **本文要点**
>
> - Cursor Build Live Apps 于 2026 年 11 月 5 日发布，只在云端 agent 里可用；Free（$0）和 Plus（$8）没有云端 agent，Premium（$30/月）起才能用，搭建时 agent 按所选模型计用量。
> - EveryInfra 的 Key 放进 Cursor 的团队密钥，变量名不能带 `NEXT_PUBLIC_`；发布前的四项检查会拦下写进文件的密钥、凭据文件、.env 和 source map，管理员也放行不了写死的密钥。
> - 一次刷新 = 两家各 1 次 `app_store/reviews`、`google_play/reviews`、`trustpilot/reviews`，加 1 次 `reddit/search`，目录价 $0.009126；每天一次，30 天约 $0.27。
> - 11 月 13 日三轮实测：App Store 三个应用的 30 条最新评论 3 轮完全相同，新增 0 条，最新一条在 57 小时以前；按小时刷新是 24 倍的钱换同样的数据。
> - Google Play 和 Trustpilot 前两轮返回 503，没扣费，第三轮重试后成功；刷新路由只重试一次，仍失败就保留昨天的数据并标出上次成功时间。
> - Trustpilot 的星级要连「是谁请来写的」一起看：YNAB 最新 20 条里 18 条来自公司邀请、五星 15 条；Monarch 最新 20 条全是自发评价、一两星 18 条。只有两家、各 20 条，说明不了因果。
> - 低星样本每家只有 10 到 11 条，一人标注：YNAB 有 4 条提到价格、3 条提到界面；Monarch 有 3 条提到隐私，同步和数据准确各 2 条。

## Cursor Build Live Apps 是什么

Cursor 在 [2026 年 11 月 5 日的更新日志](https://cursor.com/changelog/build-live-apps)里写了一句很直白的话：智能体让写代码变便宜了，但用户做出来的大多数应用和工具从没离开过本机。这次的功能就是把「离开本机」这一步也交给 Cursor：你描述想要什么，Cursor 搭应用、建数据库、配登录、部署上线，最后给你一个链接。功能的正式名字就叫 Build Live Apps，文档里归在 Cloud Agents 下面的 [Apps 一页](https://cursor.com/docs/cloud-agent/apps)。

这个功能只在云端 agent 里能用。文档原话是「记得用 cloud agent，这个功能本地不支持」。云端 agent 是跑在 Cursor 云上独立虚拟机里的编程智能体，带完整的开发环境（[Cloud Agents 文档](https://cursor.com/docs/cloud-agent)），从桌面版、网页版、iOS 应用、Slack、GitHub 评论都能发起。所以一个人在手机上给 agent 留一句话，agent 在云上把应用搭好、预览、发布，这条路在 11 月 5 日之后是通的。

和 8 月的版本比，这次多了托管。2026 年 8 月 27 日 Cursor 发过一版 [Start from scratch](https://cursor.com/changelog/start-from-scratch)，那时也能发布到一个线上地址，但原文写明「发布功能需要一个 Vercel 账号」，要用户自己去接。11 月这版不用了：文档说 Cursor 会为每个团队（个人套餐就是为个人）单独建一个托管账户，彼此隔离。[The New Stack 11 月 5 日的报道](https://thenewstack.io/cursor-ai-app-deployment/)转述了 Vercel 在 X 上的回应，说这次的托管跑在 [Vercel for Platforms](https://vercel.com/for/platforms) 上；Cursor 自己的文档没有点名托管方，我们按文档的说法写「Cursor 托管」。

文档里和竞品评论看板直接相关的条文如下：

| 文档写的 | 原文出处 | 对评论看板意味着什么 |
| --- | --- | --- |
| 只能在云端 agent 里建应用，本地 agent 不支持 | [Apps 文档 Getting started](https://cursor.com/docs/cloud-agent/apps#getting-started) | 要有带云端 agent 的套餐，Free 和 Plus 不行 |
| 需要数据库时自动建一个 Postgres | [Apps 文档 How it works](https://cursor.com/docs/cloud-agent/apps#how-it-works) | 每天拉到的评论可以存下来，按评论 id 去重，做出「近 30 天」这种视图 |
| 私有和团队应用放在 Cursor 登录后面；个人套餐可以公开 | [Apps 文档 Sharing](https://cursor.com/docs/cloud-agent/apps#sharing) | 竞品看板一般只给团队看，正好用 Team 可见 |
| 要连你自己的系统时，Cursor 会向你要密钥，agent 看不到值 | [Apps 文档 How it works](https://cursor.com/docs/cloud-agent/apps#how-it-works) | EveryInfra 的 Key 作为密钥交给 Cursor，代码里只写变量名 |
| 发布前四项检查一直开着：文件里写死的密钥、凭据文件、.env、source map | [Apps 文档 Security and controls](https://cursor.com/docs/cloud-agent/apps#security-and-controls) | 把 Key 写进代码会直接挡住发布 |
| 自动化工具用 `x-cursor-app-token` 请求头带 Cursor API key 进入应用 | [Apps 文档 API keys](https://cursor.com/docs/cloud-agent/apps#api-keys-for-grok-bot-and-scripts) | 每天定时刷新的脚本可以这样进到团队应用里 |
| 可以从 Cursor Origin 或 GitHub 的仓库部署，GitLab 还不支持 | [更新日志](https://cursor.com/changelog/build-live-apps) | 代码放 GitLab 的团队要先换地方 |

文档里没写的几样我们也列出来，免得读者以为有：没有写托管的地区，没有写 Postgres 的容量上限和备份周期，没有写应用自带定时任务。应用没有自带定时任务，要自己接触发器，做法见「刷新怎么触发」一节。

## 谁能用、要付多少：带云端 agent 的套餐起步

[Cursor 定价页](https://cursor.com/pricing)（2026 年 11 月 13 日读取）列了五档：Free $0、Plus $8/月、$30/月的一档、Super $100/月、Ultra $200/月。$30 那档在定价页上没有显示名字，Super 档的说明写的是「Premium 的全部，外加……」，所以它叫 Premium。云端 agent（Cloud agents & automations）从 $30 这档才出现在功能列表里；[Cloud Agents 文档的排错一节](https://cursor.com/docs/cloud-agent#troubleshooting)写得更明确：需要包含云端 agent 的套餐，Premium 及以上、Teams、Enterprise 或旧版付费套餐，Free 和 Plus 不包含。更新日志里那句「所有开启了云端 agent 的付费套餐都能用」，按这个读法，就是 Premium 起步。

套餐费之外，云端 agent 按模型用量计费。[Cloud Agents 文档的计费一节](https://cursor.com/docs/cloud-agent#billing)说，云端 agent 和其他 agent 工作一样消耗套餐用量，按所选模型的价格算；第一次用时会要求你设一个花费上限。定价页底部另有一句：第三方模型的用量不含在月费里，要单独购买。所以建这个看板的模型费，取决于你让 agent 改了几轮、用了哪个模型，我们没有在 Cursor 里实际跑，没法给出一个数。能确定的是：看板发布以后，每天刷新数据只是一段普通的服务端代码在调接口，不经过模型，不再花模型费。

| 档位 | 月费（定价页，11 月 13 日读取） | 能不能用 Build Live Apps | 能不能公开分享 |
| --- | --- | --- | --- |
| Free | $0 | 不能（没有云端 agent） | — |
| Plus | $8 | 不能（只含 Grok 模型，没有云端 agent） | — |
| Premium | $30 | 能 | 个人套餐可以公开 |
| Super | $100 | 能 | 个人套餐可以公开 |
| Ultra | $200 | 能 | 个人套餐可以公开 |
| Teams / Enterprise | 定价页未列 | 能（管理员要开启 Apps） | 默认关，管理员可开 |

对一个三五个人的小团队，一个人订 Premium 就够建和发布；看板要给团队里其他人看，就要么用 Teams 让大家在 Cursor 登录后打开，要么用个人套餐公开分享。竞品看板里的评论都是公开内容，公开分享在技术上可以，但看板上通常还有你们自己的判断和备注，我们建议仍然放在登录后面。

## 看板要回答的三个问题

举一个具体的团队：三个人在做一款记账预算类应用，直接对手是 YNAB 和 Monarch。最近一个月这个市场接连有大动作：Monarch 在 [2026 年 10 月 21 日重新开放了 MCP 连接器](https://www.monarch.com/blog/monarch-mcp)，用户可以把账目接到 Claude、ChatGPT、Cursor 里提问；Anthropic 在 [11 月 5 日推出 Claude 的 Personal Finance](https://claude.com/resources/articles/introducing-personal-finance-in-claude)，美国的 Pro、Max、Ultra 用户可以通过 Plaid 把银行账户接进 Claude，只读；苹果在 [11 月 4 日给订阅类应用开放了退订挽留消息](https://developer.apple.com/news/?id=fk9ps3gv)。对手的用户怎么评价这些变化，每天看一眼比每月做一次调研更有用。

我们给这块看板定了三个问题，每个问题对应一组数据：

第一，对手最近的差评在抱怨什么。数据是 App Store 和 Google Play 的最新评论，按星级和主题归类，每天看新增的一两星评论。第二，同一个对手在不同平台上的口碑是不是一样。应用商店的评论多来自手机端用户，Trustpilot 上多是付费、退款、客服相关的长评，两边放在一起看，能看出问题出在产品还是出在账单。第三，社区在讨论谁换到谁。Reddit 上「从 YNAB 换到 Monarch」「求 YNAB 替代品」这类帖子，比星级更早反映用户流向。

这三个问题决定了看板只需要四项能力，也决定了刷新频率：评论和帖子都不是分钟级变化的东西，一天刷新一次足够。

另外我们加了一个对照：西班牙的记账应用 Fintonic（App Store ID 672220319，Google Play 包名 `com.fintonic`，Trustpilot 域名 `fintonic.com`）。它不进看板，只在实测时和 YNAB、Monarch 用同样的参数调用，用来看两件事：`country: es` 的 App Store 评论和西语的 Google Play 评论拿回来是什么样，评论速度和低星主题和美区对手差多少。后文凡是出现 Fintonic 的数字，都来自这组对照调用。

## 选哪几项能力：四个入口，一张表

四项能力都在 EveryInfra 的统一接口 `POST /api/v1/social` 下，请求体只差 `platform`、`action` 和 `params`。下表的参数、单价、上限和字段都取自 [EveryInfra 免费目录](https://api.everyinfra.com/api/v1/social/catalog)（2026 年 11 月 13 日 21:30 新加坡时间读取）。

| 能力 | 必填参数 | 本文用的可选参数 | 目录单价 | 默认 / 上限条数 | 看板用到的字段 |
| --- | --- | --- | --- | --- | --- |
| [`app_store/reviews`](/app-store-api/reviews) | `app_id`（数字 ID） | `sort: newest`、`country` | $0.001389 / 次 | 30 / 500 | `id`、`rating`、`title`、`text`、`app_version`、`posted_at` |
| [`google_play/reviews`](/google-play-api/reviews) | `app_id`（包名） | `sort: newest`、`language` | $0.001389 / 次 | 40 / 200 | `id`、`score`、`text`、`app_version`、`thumbs_up`、`reply_text`、`posted_at` |
| [`trustpilot/reviews`](/trustpilot-api/reviews) | `company`（官网域名） | `sort: newest`、`date`、`stars` | $0.001389 / 次 | 20 / 200 | `id`、`rating`、`title`、`text`、`is_verified`、`reply_text`、`posted_at` |
| [`reddit/search`](/reddit-api/search) | `keyword` | `sort: newest` | $0.000792 / 次 | 10 / 25 | `id`、`title`、`community`、`like_count`、`comment_count`、`posted_at` |

几条参数上的细节，目录里都写了，建看板时容易踩：App Store 的 `app_id` 要数字 ID（应用链接里 id 后面那串数字），不是 `com.xxx` 形式的包名；Google Play 正好反过来，要包名，而且不能把整条商店链接塞进去。Google Play 的评论只随 `language` 变，同一语言下换 `country` 拿到的评论相同，目录里注明了这一点。Trustpilot 的 `company` 要官网域名，`date` 只接受 `last7days`、`last30days` 这类固定值。Reddit 搜索的时间范围固定是最近一个月，只返回标题或正文里对得上关键词的帖子，一条都没有时按空结果退款。

平台页可以看每个平台的全部能力：[App Store 爬虫](/app-store-api)、[Google Play 爬虫](/google-play-api)、[Trustpilot 爬虫](/trustpilot-api)、[Reddit 爬虫](/reddit-api)。

![截图：EveryInfra 中文站 App Store 评价 API 页面首屏，深色背景。标题「App Store 评价 API」，下面是 POST /api/v1/social 和「在线调试」按钮；中间「接口健康状态」面板显示 24 小时和 30 天的格子都是绿色，24h 健康值「正常」；底部一段写着默认 30 条、单次最多 500 条，单价 $1.39 / 千次（每次 $0.001389），失败和空结果都不收费。](https://everyinfra.com/articles/cursor-build-live-apps-competitor-review-board/img-shot-app-store-page-zh.webp)

App Store 评价能力页首屏：参数、单价和接口健康状态都能在这里先核对 [EveryInfra App Store 评价 API 页面截图](https://everyinfra.com/app-store-api/reviews)

## 整体流程：浏览器只碰自己的应用，Key 只在服务端

先看一遍数据怎么走。看板发布后，团队成员在浏览器里打开的是 Cursor 托管的那个应用，先过 Cursor 登录；页面只向应用自己的后端要数据，后端从 Postgres 读出已经存好的评论。每天一次的刷新由一个定时请求触发：它带着 Cursor API key 进入应用的刷新路由，刷新路由在服务端读出 EveryInfra 的 Key，逐个调用四项能力，把新评论写进 Postgres，按评论 id 去重。整条路上，EveryInfra 的 Key 只出现在服务端的环境变量里，浏览器拿不到，Cursor 的 agent 也看不到它的值。

![流程动画，从左到右五个方框：团队成员的浏览器（先过 Cursor 登录）、Cursor 托管的看板应用（页面和服务端路由）、Postgres（按评论 id 去重存储）、EveryInfra 接口（POST /api/v1/social，四项能力）、每天一次的定时请求（带 x-cursor-app-token 请求头）。动画里一颗灰点从定时请求走到刷新路由，再走到 EveryInfra，一个灰色方块带着评论回到 Postgres；另一颗青绿小点从浏览器走到应用、从 Postgres 取数后回到浏览器。下方一行写着：Key 只在服务端环境变量里，浏览器和 agent 都看不到。](https://everyinfra.com/articles/cursor-build-live-apps-competitor-review-board/fig-01-board-flow.zh.light.svg)

这样分开有两个好处。一是打开看板不花钱：团队里五个人一天打开二十次，都只读 Postgres，不调接口。二是接口出问题时看板照样能看：哪个平台这次没刷新成功，就继续显示上一次的数据，标上「上次成功刷新」的时间。

## Key 放在哪：Cursor 的密钥、Next.js 的 NEXT_PUBLIC_ 和发布检查

[Lovable 的博客](https://lovable.dev/blog/secure-vibe-coding)写，他们每天拦下约 1,200 个被直接写进代码的私有 API Key（此前 [Semafor 2025 年 5 月的报道](https://www.semafor.com/article/05/29/2025/the-hottest-new-vibe-coding-startup-lovable-is-a-sitting-duck-for-hackers)提到过 170 个因数据库权限没配好而有漏洞的 Lovable 网站）。Cursor 这次在三处设了门。

第一处是密钥本身。[Apps 文档](https://cursor.com/docs/cloud-agent/apps#how-it-works)写，当应用要用你自己的资源或连别的系统时，Cursor 会提示你提供需要的密钥，agent 永远看不到值；多数情况下由团队管理员在 Apps 后台建团队密钥，有权限的人也可以建个人密钥。对我们的看板，这一步就是在 Apps 后台建一个名为 `EVERYINFRA_API_KEY` 的密钥，代码里只读 `process.env.EVERYINFRA_API_KEY`。

云端 agent 本身跑在各自独立的虚拟机里，[Cloud Agents 安全说明](https://cursor.com/docs/cloud-agent/security)写明一个 agent 看不到另一个 agent 的代码和环境，Cursor 员工也不能访问虚拟机里的代码。这个开发环境另有一套密钥类型，[Secrets & Network 文档](https://cursor.com/docs/cloud-agent/security-network#secret-protection)分了三种：Environment Variable（agent 能看到，只放不敏感的配置）、Runtime Secret（仍以环境变量加载，但值会从 agent 的工具输出、对话记录、提交和提交信息里抹掉，显示成 `[REDACTED]`）、Build Secret（只给 Docker 构建用）。如果你想让 agent 在开发阶段用真 Key 试调一次接口，要选 Runtime Secret，不能选 Environment Variable。文档也提醒，Runtime Secret 对通过终端进入 agent 环境的人仍然可见。

第二处是框架。Cursor 文档没有规定应用用什么框架，我们的配置示例按 Next.js 写。[Next.js 的环境变量文档](https://nextjs.org/docs/app/guides/environment-variables)写明：不带 `NEXT_PUBLIC_` 前缀的变量只在 Node.js 环境里可用，浏览器拿不到；带了这个前缀，值会在构建时被直接写进发给浏览器的 JavaScript。所以 Key 的变量名不能带 `NEXT_PUBLIC_`，调接口的代码只能放在 Route Handler 或 Server Action 里。让 agent 写代码时把这条明确写进提示，比事后检查省事。

第三处是发布检查。[Apps 文档的安全一节](https://cursor.com/docs/cloud-agent/apps#security-and-controls)列了每次发布前都会跑的四项检查，安全审查关掉时也照跑：文件里写了 API Key 或访问令牌就挡住；包含私钥、服务账号密钥或带令牌的文件就挡住；`.env` 文件不发布；source map 不发布。四项之外还有一轮 AI 安全审查，团队管理员可以往审查提示里加规则，但不能删掉内置检查；管理员也能放行被审查挡住的发布，例外是恶意代码、写死的密钥和暴露的凭据，这三类管理员也放不了。

![示意插图：左边是一间亮着的前台，玻璃窗后面摆着一块钉满评论卡的看板，几个人在窗外看；右边隔一道墙是一间小后屋，桌上一只上锁的小铁盒，一根细线从铁盒穿过墙连到前台看板背后；窗外的人看不到后屋。](https://everyinfra.com/articles/cursor-build-live-apps-competitor-review-board/img-explain.webp)

Key 放在后屋的锁盒里：浏览器只看前台的看板，接口调用都在服务端发出。

这三道门能挡住「写死在文件里」和「打进前端包」这两类错误，挡不住第三类：Key 本身被别人拿去用。EveryInfra 的 Key 是按调用扣钱的，建议给看板单独建一把 Key，和你们其他系统用的分开；万一要换，只换这一把，在 Apps 后台改一次密钥值就行。[OWASP 的密钥管理速查表](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)把「每个服务用各自的密钥、能快速轮换」列为基本做法；如果仓库放在 GitHub，[GitHub 的密钥扫描](https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning)还会扫全部提交历史里的硬编码凭据，私有仓库要开 Secret Protection 才有。

## 配置示例：给 cloud agent 的那段话

下面是我们给 cloud agent 写的提示词。Cursor 一侧没有实际运行，这一节和下一节都是配置示例；EveryInfra 一侧的参数和字段都和目录逐个对过。提示词要明确说「build an app」，[Apps 文档](https://cursor.com/docs/cloud-agent/apps#getting-started)要求这样写才会进入建应用的流程。

```text
Build an app: a competitor review board for our budgeting app team.

Data: call EveryInfra from the server only.
- POST https://api.everyinfra.com/api/v1/social
- Header: Authorization: Bearer ${EVERYINFRA_API_KEY}  (team secret; never NEXT_PUBLIC_)
- Sources (one call each per refresh):
  app_store/reviews   {"app_id": "1010865877", "sort": "newest", "limit": 30}   # YNAB
  app_store/reviews   {"app_id": "1459319842", "sort": "newest", "limit": 30}   # Monarch
  google_play/reviews {"app_id": "com.youneedabudget.evergreen.app", "sort": "newest", "limit": 40}
  google_play/reviews {"app_id": "com.monarchmoney.mobile", "sort": "newest", "limit": 40}
  trustpilot/reviews  {"company": "ynab.com", "sort": "newest", "limit": 20}
  trustpilot/reviews  {"company": "monarchmoney.com", "sort": "newest", "limit": 20}
  reddit/search       {"keyword": "YNAB Monarch", "sort": "newest", "limit": 25}
Storage: Postgres table reviews(source, competitor, review_id, rating, title, text, posted_at, fetched_at),
  unique (source, review_id); upsert with ON CONFLICT DO NOTHING.
Refresh: POST /api/refresh, allowed only for requests that come with a Cursor API key.
  On HTTP 429 or 503 read error.retry_after, retry once, then keep yesterday's data and
  record last_success_at per source.
Pages: (1) new 1-2 star reviews since last refresh, (2) rating mix per competitor per source,
  (3) Reddit posts list. Share with: our team only.
```

提示里每一项都对应前面的一条事实：密钥名和「不要 `NEXT_PUBLIC_`」对应 Next.js 文档；`unique (source, review_id)` 对应「同一条评论会在几次刷新里重复出现」；429 和 503 的处理对应接口返回里标明可以重试的两种错误；`limit` 按竞品的评论速度定，依据见「30 条能盖住几天」一节。

## 配置示例：刷新路由和表结构

agent 生成的代码每次不一样，下面是我们认为刷新路由至少要有的样子，可以拿来对照 agent 写出来的东西。它是一个 Next.js 的 Route Handler，只在服务端运行。

```text
// app/api/refresh/route.ts — config example, server only
import { sql } from "@/lib/db";

const SOURCES = [
  { source: "app_store", competitor: "ynab", body: { platform: "app_store", action: "reviews", params: { app_id: "1010865877", sort: "newest", limit: 30 } } },
  { source: "app_store", competitor: "monarch", body: { platform: "app_store", action: "reviews", params: { app_id: "1459319842", sort: "newest", limit: 30 } } },
  { source: "reddit", competitor: "both", body: { platform: "reddit", action: "search", params: { keyword: "YNAB Monarch", sort: "newest", limit: 25 } } },
  // google_play/reviews and trustpilot/reviews follow the same shape
];

async function callOnce(body: object) {
  const res = await fetch("https://api.everyinfra.com/api/v1/social", {
    method: "POST",
    headers: { Authorization: `Bearer ${process.env.EVERYINFRA_API_KEY}`, "Content-Type": "application/json" },
    body: JSON.stringify(body),
  });
  const json = await res.json();
  return { status: res.status, json };
}

export async function POST() {
  const report = [];
  for (const s of SOURCES) {
    let r = await callOnce(s.body);
    if (r.status === 429 || r.status === 503) {
      const wait = Math.min((r.json?.error?.retry_after ?? 30) * 1000, 120_000);
      await new Promise((ok) => setTimeout(ok, wait));
      r = await callOnce(s.body);
    }
    if (r.status !== 200) { report.push({ ...s, ok: false, status: r.status }); continue; }
    for (const row of r.json.results ?? []) {
      await sql`INSERT INTO reviews (source, competitor, review_id, rating, title, text, posted_at, fetched_at)
                VALUES (${s.source}, ${s.competitor}, ${row.id}, ${row.rating ?? row.score ?? null},
                        ${row.title ?? null}, ${row.text ?? null}, ${row.posted_at}, now())
                ON CONFLICT (source, review_id) DO NOTHING`;
    }
    await sql`UPDATE sources SET last_success_at = now() WHERE source = ${s.source} AND competitor = ${s.competitor}`;
    report.push({ ...s, ok: true, rows: r.json.results?.length ?? 0, charged_usd: r.json.billing?.charged_usd });
  }
  return Response.json(report);
}
```

去重用的是 Postgres 的 `INSERT … ON CONFLICT DO NOTHING`，[PostgreSQL 文档](https://www.postgresql.org/docs/current/sql-insert.html)对它的说明是：遇到唯一约束冲突时不报错，改做指定的替代动作。这样同一条评论第二天又被拉到，表里也只有一行；`fetched_at` 记的是第一次拉到的时间，「新评论」按它筛，不按 `posted_at` 筛，原因在实测一节。

三个字段名要按平台分开取：App Store 和 Trustpilot 的星级字段叫 `rating`，Google Play 叫 `score`；Reddit 帖子没有星级，只有 `like_count` 和 `comment_count`。这些都能在目录的 `response_fields` 里核对，不必猜。

## 一次真实往返：请求、返回、扣费

下面是我们 2026 年 11 月 13 日 21:31:02（新加坡时间）发出的一次真实请求，取 YNAB 在 App Store 美区的最新 30 条评论。Key 通过环境变量传入，命令里只有变量名。

```bash
curl -s https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer $EVERYINFRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"platform":"app_store","action":"reviews","params":{"app_id":"1010865877","sort":"newest","limit":30}}'
```

返回是 HTTP 200，`count` 为 30，`billing.charged_usd` 为 0.001389，和目录单价一致；整段 JSON 约 19.6 KB。每条评论的字段和目录的 `response_fields` 一一对得上：`id`、`title`、`text`、`rating`、`rating_scale`、`author`、`app_version`、`helpful_count`、`posted_at`、`app_id`、`app_name`、`platform`。看板只需要其中 7 个，`author` 是普通用户的昵称，我们建议入库前就丢掉，看板上不显示，这也是本文的截图和表格里一律不出现评论者名字的原因。

![截图：终端风格的真实请求和返回。第一行是 2026-11-13 21:31:02 新加坡时间发出的 POST 请求，请求体是 app_store/reviews，app_id 1010865877，sort newest，limit 30；下面是 HTTP 200 的返回节选：count 30，第一条评论 rating 2、app_version 26.42、posted_at 2026-11-10T20:52:31-07:00，作者一栏已打码；青绿框标出 billing 里 charged_usd 0.001389 一行和 count 30 一行。](https://everyinfra.com/articles/cursor-build-live-apps-competitor-review-board/img-shot-ei-response.webp)

一次 app_store/reviews 的真实返回节选：30 条，扣 $0.001389；评论者昵称已打码 [EveryInfra 接口真实返回](https://api.everyinfra.com/api/v1/social)

## 实测：三个时刻、四项能力，各拿到了什么

看板一侧是配置示例，数据一侧我们真调了。2026 年 11 月 13 日晚上，我们按看板每次刷新的那一组调用，在三个时刻各跑了一轮：21:31、22:14、22:36（新加坡时间）。在看板的 7 次调用之外，对照组 Fintonic 三轮都调了 App Store，第二、三轮另调了 Google Play 和 Trustpilot。每次请求都记下 HTTP 状态、耗时、返回条数和 `billing.charged_usd`，原始返回逐个存档，下面的数字都能从存档重算。下表是 App Store 和 Reddit 三轮的对照，Google Play 和 Trustpilot 见后面「第三轮补上的两个来源」一节。

| 轮次 | App Store · YNAB | App Store · Monarch | App Store · Fintonic（西班牙区，对照） | Reddit「YNAB Monarch」 |
| --- | --- | --- | --- | --- |
| 第 1 轮 | 21:31 · 30 条，最新一条 57.6 小时前 | 21:31 · 30 条，最新一条 56.7 小时前 | 21:54 · 30 条，最新一条 66.5 小时前 | 21:31 · 本次返回 9 帖 |
| 第 2 轮 | 22:14 · 30 条，新 0 条，最新一条 58.4 小时前 | 22:14 · 30 条，新 0 条，最新一条 57.4 小时前 | 22:14 · 30 条，新 0 条，最新一条 66.8 小时前 | 22:14 · 本次返回 9 帖，新发 0 帖 |
| 第 3 轮 | 22:36 · 30 条，新 0 条，最新一条 58.7 小时前 | 22:36 · 30 条，新 0 条，最新一条 57.7 小时前 | 22:37 · 30 条，新 0 条，最新一条 67.2 小时前 | 22:36 · 本次返回 23 帖，新发 0 帖 |

App Store 的最新评论三轮没有变。YNAB、Monarch 和 Fintonic 三个应用，后两轮返回的 30 条评论和第 1 轮完全相同，评论 id 和顺序都一样，新增 0 条；最新一条评论距请求的时间跟着时钟往上涨，YNAB 从 57.6 小时涨到 58.7 小时，Monarch 从 56.7 小时涨到 57.7 小时。也就是说，这一个多小时里商店没有公开任何新评论。

Reddit 那一栏也没有新帖。前两轮返回的 9 个帖子相同，变的只有点赞数，例如 11 月 9 日那篇讨论帖从 280 赞涨到 283 赞，第三轮是 284 赞。第三轮的 23 帖发帖时间都早于第一轮请求。同一个帖子会在几次刷新里反复出现，看板要按帖子链接去重；「新帖」按 `posted_at` 判断，不按「这次第一次拉到」判断。

评论在商店里本来就要等一两天才公开，每小时刷新一次，24 次里有 23 次拿到的是同一批评论，接口费却是每天一次的 24 倍。每天一次足够；想更及时，最多每 6 小时一次。

各来源的速度差得很远：成功的 App Store 调用每次 0.42 到 0.74 秒，Google Play 7.0 到 9.3 秒，「YNAB Monarch」这个 Reddit 搜索 8.86 和 10.54 秒，Trustpilot 26.37 到 53.35 秒（最慢的 53.35 秒是对照组 Fintonic）。第三轮按看板的 7 次调用串行跑完一共约 84 秒，其中两次 Trustpilot 就占了 54 秒。刷新路由要给每次调用留够超时，Trustpilot 至少留一分钟；7 次调用也可以按来源并行发出，总时间就由最慢的一次决定。

![分组横向柱状图，纵轴是三轮的请求时刻（21:31、22:14、22:36，新加坡时间），每轮三根柱子分别是 YNAB、Monarch（美区）和 Fintonic（西班牙区）最新一条 App Store 评论距请求的小时数：YNAB 从 57.6 到 58.7，Monarch 从 56.7 到 57.7，Fintonic 从 66.5 到 67.2。标题写着三轮的 30 条评论没有变化，新增 0 条。](https://everyinfra.com/articles/cursor-build-live-apps-competitor-review-board/fig-09-newest-review-age-bar.zh.light.svg)

![横向柱状图，列出 2026 年 11 月 13 日 22:36 到 22:39（新加坡时间）第三轮每次调用的耗时：App Store · YNAB 0.53 秒、App Store · Monarch 0.42 秒、App Store · Fintonic（对照）0.45 秒、Reddit · YNAB Monarch 10.54 秒、Google Play · YNAB 9.3 秒、Google Play · Monarch 8.4 秒、Google Play · Fintonic（对照）7 秒、Trustpilot · YNAB 28.09 秒、Trustpilot · Monarch 26.37 秒、Trustpilot · Fintonic（对照）53.35 秒。看板的两根 Trustpilot 柱为青绿色，对照组的柱子颜色较浅。标题写着看板的 7 次调用串行共 83.7 秒，两次 Trustpilot 占 54.5 秒。](https://everyinfra.com/articles/cursor-build-live-apps-competitor-review-board/fig-11-call-latency-bar.zh.light.svg)

### 503 和 429：看板该怎么接

前两轮里 Google Play 和 Trustpilot 返回 503，没扣费，第三轮重试后成功，各自按目录价扣费。以其中一次 503 为例（22:14:53 新加坡时间，`google_play/reviews`，YNAB）：返回的 `error.code` 是 `unavailable`，`error.retryable` 是 true，`billing.charged` 是 false、`charged_usd` 是 0，`refund.status` 是 succeeded。

两种错误在 HTTP 里的含义不同，看板的处理也该不同。[RFC 6585](https://www.rfc-editor.org/rfc/rfc6585) 定义 429 是「请求太多」，意思是你发得太快，等一等就好；[RFC 9110](https://www.rfc-editor.org/rfc/rfc9110) 定义 503 是服务端暂时处理不了，可以带 `Retry-After` 告诉客户端多久以后再来。所以刷新路由的写法是：429 按 `retry_after` 等一次再试，503 也只重试一次，仍失败就跳过这个来源，保留昨天的数据，在这一栏标出上次成功的时间。前面配置示例里的 `last_success_at` 就是为这个准备的。

| 返回 | 含义 | 扣费 | 刷新路由怎么做 |
| --- | --- | --- | --- |
| 200，有结果 | 成功 | 按目录价扣一次 | 按评论 id 去重写库，更新 `last_success_at` |
| 返回 0 条 | 没有匹配的内容 | 不扣费，自动退回 | 不写库，照常更新 `last_success_at` |
| 429 `rate_limited` | 这把 Key 每分钟超过上限 | 不扣费 | 等 `retry_after` 秒后重试一次 |
| 503 `unavailable` | 这项能力暂时不可用 | 不扣费 | 重试一次；仍失败就跳过，保留昨天的数据 |
| 401 | Key 缺失或无效 | 不扣费 | 停止整次刷新，提醒管理员检查团队密钥 |

刷新路由不要循环重试到成功：死等一个来源，其余来源的结果也迟迟写不进库。按来源分开记状态，一个来源没刷新成功只影响一栏，看板其余几栏照常更新；这也是把四个来源写成四次独立调用的原因，合成一个批量请求时，一处失败会拖累全部。界面上，每一栏显示上次成功刷新的时间。

## 30 条评论能盖住几天：先量竞品的评论速度，再定 limit

`limit` 定多少，取决于竞品每天来多少条评论。拿第 1 轮的两份 App Store 返回来量：YNAB 最新 30 条从 2026 年 10 月 12 日排到 11 月 10 日，横跨 29.1 天，平均每天约 1.03 条；Monarch 最新 30 条从 11 月 2 日排到 11 月 10 日，只横跨 8.6 天，平均每天约 3.48 条。同样 30 条，Monarch 的评论速度是 YNAB 的 3.4 倍左右（3.48 ÷ 1.03），这个倍数只说明美区 App Store 上留文字评论的人数，不代表下载量或收入。

![横向柱状图，比较同样 30 条最新评论覆盖的天数：YNAB 美区 App Store 29.1 天（每天约 1.03 条），Monarch 美区 App Store 8.6 天（每天约 3.48 条），Fintonic 西班牙区 App Store 40.4 天（每天约 0.74 条）。Monarch 一行用青绿色突出。](https://everyinfra.com/articles/cursor-build-live-apps-competitor-review-board/fig-03-review-window-bar.zh.light.svg)

这组数直接决定看板的参数。每天刷新一次时，Monarch 一天新增 3 到 4 条，`limit: 30` 够用 8 天以上；就算刷新连续断了一周，补拉一次也不会漏。YNAB 一天约 1 条，30 条够一个月。所以我们没有把 `limit` 调到上限 500：多拉的几百条是早就入库的旧评论，按次计费时不多花钱，但每次返回会从约 20 KB 变成几百 KB，写库和去重都变慢。只有第一次建库时，才值得用大一点的 `limit` 把历史补齐，例如 YNAB 拉 200 条大约能回溯半年。

另一个数要写进界面：发出请求时，最新那条评论距现在有多久。第 1 轮 21:31（新加坡时间）请求时，YNAB 最新一条发表于 11 月 10 日 20:52（美国太平洋时间，换成新加坡时间是 11 月 11 日 11:52），已经过去 57.6 小时；Monarch 最新一条也过去了 56.7 小时。[Google Play 管理中心的帮助页](https://support.google.com/googleplay/android-developer/answer/138230)写明新评论一般延后约 24 小时才公开，App Store 这两份样本也是两天多以前的评论排在最前面。看板上「今日新增」只能按 `fetched_at` 算，意思是「今天第一次看到」，不能理解成「今天写的」。

## 星级分布和低星主题：两家各自在哪里丢分

两份样本里低星比例差不多：YNAB 30 条里 1 星 6 条、2 星 4 条，合计 33.3%；Monarch 1 星 8 条、2 星 3 条，合计 36.7%。两家都有一半左右是 5 星（YNAB 16 条，Monarch 14 条），中间的 3 星、4 星很少。样本只有 30 条，相差 1 条就是 3.3 个百分点，看板上应该显示条数，不只显示百分比。

![分组柱状图，横轴是 1 星到 5 星，每组两根柱子分别是 YNAB 和 Monarch 美区 App Store 最新 30 条评论的条数。YNAB 依次为 6、4、3、1、16 条；Monarch 依次为 8、3、1、4、14 条。Monarch 用青绿色，YNAB 用灰色。](https://everyinfra.com/articles/cursor-build-live-apps-competitor-review-board/fig-04-rating-dist-bar.zh.light.svg)

21 条低星评论的主题分布如下。标注规则：两家共 21 条 1 星、2 星评论由一个人（本文作者）逐条读完，每条只归一个主题，主题以评论第一句抱怨的事为准，没有第二人复核。每家只有 10 到 11 条，表里的条数只说明这份样本，看板上线后可以交给模型或规则做同样的事。

| 主题 | YNAB（10 条低星） | Monarch（11 条低星） | 评论里的典型说法（转述） |
| --- | --- | --- | --- |
| 价格和订阅 | 4 | 1 | 不用银行同步的人没有便宜一档；涨价；年费约 100 美元 |
| 界面和功能 | 3 | 0 | 手机上看不到余额；功能请求没人理 |
| 账户同步 | 2 | 2 | 银行连接断开、余额对不上 |
| 隐私 | 0 | 3 | 认为隐私政策允许向第三方提供数据 |
| 数据准确 | 0 | 2 | 分类和金额算错 |
| iPhone Duo 适配 | 1 | 1 | 大屏上仍被强制用手机版界面；为什么还没有 Duo 更新 |
| 强制更新 | 0 | 1 | 不升级就不让用 |
| 稳定性 | 0 | 1 | 闪退 |

![分组横向柱状图，列出 8 个低星主题在两家的条数：价格和订阅 YNAB 4、Monarch 1；界面和功能 3、0；账户同步 2、2；隐私 0、3；数据准确 0、2；iPhone Duo 适配 1、1；强制更新 0、1；稳定性 0、1。标题写着样本里 YNAB 有 4 条低星提到价格，Monarch 有 3 条提到隐私。数据来自 11 月 13 日第 1 轮真调的 21 条 1 星、2 星评论。](https://everyinfra.com/articles/cursor-build-live-apps-competitor-review-board/fig-07-low-star-themes-bar.zh.light.svg)

样本里 YNAB 有 4 条低星提到价格（[YNAB 定价页](https://www.ynab.com/pricing)写的是年付 $109、月付 $14.99，2026 年 11 月 13 日读取），其中有人提到不用银行同步的人没有便宜一档；Monarch 有 3 条提到隐私、2 条提到数据准确。条数太少，不能推到两家的整个用户群，看板的作用是每天把新的低星攒下来，攒够几十条再看分布。要提醒的是，隐私那 3 条是用户的看法，评论本身证明不了 Monarch 的政策怎么写，团队要看原文时去读对方的隐私政策；[Monarch 定价页](https://www.monarch.com/pricing)上写的是从不出售用户的财务数据。看板上只记「有 3 条评论这样说」。

两家同时出现的一个主题是 iPhone Duo。iPhone Duo 在 10 月 23 日开始交付，Apple 当天发了新闻稿介绍开发者为它做的新界面。我们的样本里，YNAB 有 1 条 1 星评论抱怨大屏上仍被强制用手机版界面，Monarch 有 1 条 1 星直接问「为什么还没有 Duo 更新」，还有 1 条 4 星说只差 Duo 支持。样本里有 2 条低星提到 iPhone Duo（两家各 1 条），看板上可以给这类评论单独一个标签，看后面几周的条数怎么变。

AI 相关的评论只有 1 条：Monarch 的一条 5 星评论说 MCP 连接器「明显是一个差异点」，这条发表于 11 月 2 日，距离 Monarch 10 月 21 日重开 MCP 连接器不到两周。YNAB 的 30 条里没有提到 AI。样本小，不能说明用户普遍在意，只说明已经有用户把 MCP 写成了打分理由。

## 第三轮补上的两个来源：同一家对手，三个平台三种口碑

22:37（新加坡时间）第三轮里 Google Play 和 Trustpilot 重试成功，我们第一次拿到同一家竞品在三个平台上的最新评论。App Store 用第 1 轮的数据（三轮本来就一样），Google Play 和 Trustpilot 用第三轮的数据：

| 竞品 | 平台 | 条数 | 覆盖天数 | 1–2 星 | 5 星 | 有官方回复 |
| --- | --- | --- | --- | --- | --- | --- |
| YNAB | App Store（美区） | 30 | 29.1 | 10（33%） | 16 | 返回里没有回复字段 |
| YNAB | Google Play | 40 | 46.4 | 17（43%） | 17 | 26 |
| YNAB | Trustpilot | 20 | 20.8 | 1（5%） | 15 | 5 |
| Monarch | App Store（美区） | 30 | 8.6 | 11（37%） | 14 | 返回里没有回复字段 |
| Monarch | Google Play | 40 | 18.9 | 18（45%） | 15 | 28 |
| Monarch | Trustpilot | 20 | 322.9 | 18（90%） | 1 | 0 |

![分组横向柱状图，三组是 YNAB、Monarch 和西班牙区的 Fintonic，每组三根柱子分别是 App Store、Google Play 和 Trustpilot 最新评论里一两星的占比。YNAB 是 10/30、17/40、1/20；Monarch 是 11/30、18/40、18/20；Fintonic 是 21/30、34/40、4/8。Trustpilot 柱为青绿色，Monarch 那根接近 90%，YNAB 那根只有 5%。](https://everyinfra.com/articles/cursor-build-live-apps-competitor-review-board/fig-10-platform-low-star-bar.zh.light.svg)

第一，这份样本里 Google Play 的低星比例更高。两家在 Google Play 的低星比例都比 App Store 高出 8 到 10 个百分点：YNAB 43% 对 33%，Monarch 45% 对 37%。评论速度的排序没有变：Google Play 上 Monarch 40 条盖 18.9 天，约每天 2.1 条；YNAB 40 条盖 46.4 天，约每天 0.86 条。Monarch 仍然是 YNAB 的两倍多，和 App Store 得出的结论一致，这说明前面「按评论速度定 `limit`」的做法换到 Google Play 也成立。

第二，Trustpilot 上两家像两个世界：YNAB 20 条里只有 1 条低星，五星 15 条；Monarch 20 条里 18 条是一两星，只有 1 条五星。YNAB 的 20 条里有 18 条 `source` 是 `InvitationApi`、`verification_level` 是 `verified`，也就是公司通过 Trustpilot 的邀请接口请用户来写的，这 18 条全是三星以上；另外 2 条是用户自己来写的（`source: Organic`），一条一星，一条五星。Monarch 的 20 条全部是 `Organic`，最新一条是 2026 年 9 月 21 日的，20 条跨了 323 天。[Trustpilot 的开发者文档](https://developers.trustpilot.com/)里，商家接口提供「发送邀请」。在这两家各 20 条的样本里，用邀请接口的一家五星多，没用的一家低星多；只有两家，不能说明因果，但足以说明 Trustpilot 的星级不能脱离 `source` 直接比。

所以看板的 Trustpilot 一栏要按 `source` 分两行：邀请来的一行，自发的一行。比较两家时只比自发评价才公平，这时 YNAB 只有 2 条，样本太小，不下结论。另一个信号是官方回复。Google Play 上 YNAB 回复了 40 条里的 26 条，Monarch 回复了 28 条；Trustpilot 上 YNAB 回复了 5 条，Monarch 0 条。用 `reply_text` 是否为空就能算出回复率，对一个三人团队来说，回复得快本身就是可以拿来比的地方。

对照组 Fintonic 的三个平台也在第三轮里拿齐了。它在 Google Play（西语）最新 40 条里有 34 条一两星，占 85%，比 App Store 的 70% 还高，而且 40 条全部有官方回复；Trustpilot 上一共只拿到 8 条，跨了 501 天，其中 5 条是邀请来的（`verification_level: invited`）。这说明 Fintonic 在 Trustpilot 上几乎没有新评价，西班牙用户的声音主要在两家应用商店里。

Fintonic 在 App Store 西班牙区的 21 条一两星评论，我们按同样的规则逐条标了主题：抱怨更新和改版的 7 条，抱怨应用在推销贷款、保险等金融产品的 5 条，银行连接 4 条，数据丢失 3 条，其他 2 条。按版本号看，10.0.7 版本下的 7 条评论全是一两星，其中 3 条说在推销产品、2 条说改版；最新的 10.0.10 版本下 12 条里有 6 条一两星。对一个西班牙的同类团队，这组数说明的是「改版后变成卖产品的应用」这件事在评论里集中出现过，和 YNAB、Monarch 的价格、隐私抱怨是两回事。这也说明同一套看板换个国家、换个对手直接能用：只要把 `country` 和 `language` 改掉，字段和去重规则都不用动。

![横向柱状图，列出 Fintonic 西班牙区 App Store 最新 30 条里 21 条 1 星、2 星评论的主题条数：更新和改版 7 条、推销金融产品 5 条、银行连接 4 条、数据丢失 3 条、其他 2 条，前两项用青绿色突出。标题写着改版和推销金融产品占一半以上。数据来自 2026 年 11 月 13 日 21:54（新加坡时间）的真调。](https://everyinfra.com/articles/cursor-build-live-apps-competitor-review-board/fig-08-fintonic-themes-bar.zh.light.svg)

## Reddit 上的迁移帖：用户在两家之间怎么走

同一时刻我们用 `reddit/search` 搜「YNAB Monarch」，按最新排序，拿到 9 个帖子，时间从 10 月 25 日到 11 月 10 日，评论合计 515 条。按标题分：3 个是迁移帖，r/personalfinance 的「YNAB Alternatives? I've outgrown it」（72 赞、104 条评论），r/ynab 的「Spent the past month on Monarch」（55 赞、75 条评论），r/MonarchMoney 的「Convince me to come over from YNAB?」（11 条评论）。5 个是新产品的宣传帖，其中一个标题相同的帖子分别发在两个加拿大创业社区；剩下 1 个是下面这篇讨论帖。

热度最高的一个帖子和迁移无关：2026 年 11 月 9 日 r/MonarchMoney 一篇讨论用户对 AI 预算功能态度的帖子，280 赞、179 条评论，发在 Claude 推出个人财务功能 4 天之后。5 个宣传帖里也有 1 个直接拿 Claude 的个人财务功能和 Monarch 比较。对看板来说，这一栏的价值在标题和评论数，帖子正文是长讨论，适合人点进去读，不适合在看板上全文展示。

Reddit 这一栏我们只搜两家的名字放在一起的组合。这样搜到的帖子少，但几乎都和「两家怎么选」直接相关。分别搜「YNAB」和「Monarch」能拿到更多帖子，但会混进两家各自用户的使用求助，这一点我们没有实测条数。`reddit/search` 一次 $0.000792，多搜两个词每天也只多约 0.16 美分，团队可以先观察一周，再决定要不要加。

## 每天刷新一次的接口费

账按目录 `price_usd` 算，和真调扣费核对过：成功的调用 `charged_usd` 都等于目录单价，失败的调用全部是 0；第三轮看板的 7 次调用全部成功，实扣合计正好 $0.009126。看板每天刷新一次，要调这几次：两家各一次 `app_store/reviews`、一次 `google_play/reviews`、一次 `trustpilot/reviews`，再加一次 `reddit/search`。

| 每次刷新的调用 | 次数 | 单价（目录，11 月 13 日） | 小计 |
| --- | --- | --- | --- |
| `app_store/reviews` | 2 | $0.001389 | $0.002778 |
| `google_play/reviews` | 2 | $0.001389 | $0.002778 |
| `trustpilot/reviews` | 2 | $0.001389 | $0.002778 |
| `reddit/search` | 1 | $0.000792 | $0.000792 |
| 合计 | 7 | — | $0.009126 |

每天一次是 $0.009126，不到 1 美分；30 天约 $0.27，一年约 $3.33。改成每小时刷新，30 天是 $6.57，是每天一次的 24 倍；实测一节会说明，这多出来的 23 次几乎拿不到新评论。失败和返回 0 条的调用不扣费。

![横向柱状图，比较不同刷新频率的 30 天接口费：每天一次、7 次调用全部成功 0.274 美元；每 6 小时一次 1.095 美元；每小时一次 6.571 美元。每天一次、四个来源都成功的一行用青绿色突出。](https://everyinfra.com/articles/cursor-build-live-apps-competitor-review-board/fig-06-refresh-cost-bar.zh.light.svg)

Cursor 一侧，一个 Premium 席位每月 $30，搭建时云端 agent 另按所选模型计用量（我们没有实测这部分）；看板上线以后每月的接口费约 $0.27，约为 Premium 月费的 0.9%。

## 刷新怎么触发：三种做法和各自的花费

Apps 文档没有提到应用自带定时任务，所以「每天刷新一次」要自己接一个触发器。我们比较了三种做法，都只用到文档里写明的功能。

第一种是打开时刷新。页面加载时检查每个来源的 `last_success_at`，超过 24 小时就在服务端触发一次刷新，其余时候只读 Postgres。好处是什么都不用额外配；缺点是如果那天没人打开看板，就没有数据，第二天打开的人要多等一轮接口调用（我们第三轮实测这 7 次调用串行合计约 84 秒，Trustpilot 一次就要 26 秒以上；可以先显示上次的数据，刷新在后台跑完再换）。小团队每天都有人看，这种做法够用。

第二种是外部定时任务带 Cursor API key 进来。[Apps 文档](https://cursor.com/docs/cloud-agent/apps#api-keys-for-grok-bot-and-scripts)说，私有和团队应用在 Cursor 登录后面，自动化工具进不来；给它一把 Cursor API key，在每个请求的 `x-cursor-app-token` 请求头里带上，它就能像一个已登录的用户那样用应用。这个 key 只能放在请求头里，不能放在查询参数或 Cookie 里；用它发的请求会被标成自动化请求。团队 API key 只能打开分配给它的团队应用。我们把这个定时任务放在 [GitHub Actions 的 `schedule` 触发器](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule)上，每天早上发一次 `POST /api/refresh`：

```text
# .github/workflows/refresh-board.yml — config example
on:
  schedule:
    - cron: "0 1 * * *"   # 01:00 UTC = 09:00 Singapore time
  workflow_dispatch: {}
jobs:
  refresh:
    runs-on: ubuntu-latest
    steps:
      - run: |
          curl -sf -X POST "https://<your-app-domain>/api/refresh" \
            -H "x-cursor-app-token: ${{ secrets.CURSOR_APP_TOKEN }}"
```

注意这里有两把钥匙，存在两个地方：GitHub 仓库的 Secrets 里只放 Cursor API key，它只能打开这一个应用；EveryInfra 的 Key 仍然只在 Cursor 的 Apps 密钥里，GitHub 那边看不到。

第三种是 Cursor 自己的 Automations。[Automations 文档](https://cursor.com/docs/cloud-agent/automations)写明可以用定时触发器（预设选项或 cron 表达式）在后台跑云端 agent，「可能会延迟，但不会早于设定时间」；计费方式是按云端 agent 的用量算。也就是说，每天让一个 agent 起来调一次刷新，每天都要花一份模型费，而刷新这件事本身不需要模型做判断。Cursor 论坛 2026 年 9 月的[一个帖子](https://forum.cursor.com/t/cron-mcp-only-automations-repo-warning-no-output-surface-broken-add-flow/172146)还提到，定时自动化的结果默认只写在运行历史里，要另外接「发到 Slack」之类的工具才看得到。我们的结论是：刷新用第一种或第二种；Automations 适合每周让 agent 读一遍看板、写一段文字总结，那一步才用得上模型。

| 触发方式 | 要配什么 | 每天的额外花费 | 适合 |
| --- | --- | --- | --- |
| 打开时刷新 | 无 | 无 | 每天都有人看的小团队 |
| GitHub Actions + `x-cursor-app-token` | 一把 Cursor API key、一个工作流文件 | GitHub 公共仓库免费；私有仓库计 Actions 分钟 | 要求每天固定时间更新 |
| Cursor Automations 定时 | 一个定时自动化 | 每次运行按云端 agent 用量计费 | 要模型写周报，不适合只做刷新 |

## 做不了或要注意的地方

先说 Cursor 一侧。Build Live Apps 只在云端 agent 里能用，Free 和 Plus 没有；Teams 和 Enterprise 的管理员可以整体关掉 Apps，也可以禁止 API key 打开应用，那样第二种刷新方式就用不了。代码仓库只支持 Cursor Origin 和 GitHub，GitLab 写的是「即将支持」。[Apps 文档的 Availability 一节](https://cursor.com/docs/cloud-agent/apps#availability)写明托管和 Cursor 的服务是分开的，按「现状」提供；子域名和应用可能因违反条款或业务原因被撤下。重要的看板，代码要在自己的仓库里留一份。

再说数据一侧。我们用的四项能力都只读公开内容：公开的应用评论、公开的 Trustpilot 评价、公开的 Reddit 帖子。苹果和谷歌的官方接口只给开发者看自己应用的评论：[App Store Connect API 的 Customer Reviews](https://developer.apple.com/documentation/appstoreconnectapi/customer-reviews) 是「获取你的应用的用户评论」，[Google Play 的 Reply to Reviews API](https://developers.google.com/android-publisher/reply-to-reviews) 只覆盖自家应用的正式版，只返回带文字的评论，读取有每小时 200 次的配额。看对手的评论，这两个接口用不上。另外两个来源也一样：[Trustpilot 的开发者文档](https://developers.trustpilot.com/)给商家的接口是发评价邀请、展示和回复自己的评价，读整个评价库要另外走它的 Data Solutions 商务渠道；想自己直接接 Reddit 官方接口，先要读 Reddit 的 [Data API Terms](https://redditinc.com/policies/data-api-terms)（最近一次修订是 2026 年 7 月 20 日）。

评论本身也有时间差。[Google Play 管理中心的帮助页](https://support.google.com/googleplay/android-developer/answer/138230)写明，新评分和评论一般会延后约 24 小时才公开，发现可疑活动时还会整体暂停公开。苹果的[评分与评论说明](https://developer.apple.com/app-store/ratings-and-reviews/)提到，开发者可以在新版本发布时重置汇总评分，但已写的评论不会被清掉。看板上的「今天新增」实际是「今天第一次拉到」，可能是一两天前写的评论，界面上要这样标。

最后是人的问题。评论者的昵称属于普通用户，看板不需要它，入库前就丢掉；需要引用原话时只引内容，不引名字。评论内容能说明对手的产品问题，不能拿来证明对手违法或不诚信，Monarch 那几条关于隐私的一星评论就是例子：它们说明有用户这样认为，不说明事实如此。看板里写给团队的备注，也要按这个分寸写。

## 行业动向：2026 年 10 月到 11 月

- **2026 年 11 月 5 日，Cursor 上线 Build Live Apps。**（[更新日志](https://cursor.com/changelog/build-live-apps)）对读者：内部工具从「本机跑得通」到「团队能打开」少了托管、数据库、登录三步；数据要从外部取的看板，密钥放法是唯一要自己想清楚的地方。
- **2026 年 11 月 5 日，Anthropic 推出 Claude 的 Personal Finance 测试版。**（[Anthropic 原文](https://claude.com/resources/articles/introducing-personal-finance-in-claude)、[帮助中心](https://support.claude.com/en/articles/18185620-use-personal-finance-in-claude)、[TechCrunch 报道](https://techcrunch.com/2026/11/05/claude-can-now-analyze-your-spending-with-its-new-personal-finance-tool/)）对读者：记账类应用多了一个通用助手做对手，看对手评论时要加一个「用户在拿谁比」的维度。
- **2026 年 11 月 4 日，苹果开放订阅退订挽留消息。**（[苹果开发者新闻](https://developer.apple.com/news/?id=fk9ps3gv)）对读者：订阅类应用在用户点退订时多了一次说话的机会；对手评论里关于续费、退订的抱怨，是你们写挽留消息时最直接的素材。
- **2026 年 10 月 23 日，iPhone Duo 开始交付。**（[苹果新闻稿](https://www.apple.com/newsroom/2026/10/developers-bring-incredible-new-app-experiences-to-iphone-duo/)）对读者：我们拉到的两家对手的一星评论里各有 1 条提到没有适配 Duo。
- **2026 年 10 月 21 日，Monarch 重新开放 MCP 连接器。**（[Monarch 博客](https://www.monarch.com/blog/monarch-mcp)、[帮助中心](https://help.monarch.com/hc/en-us/articles/50207234679956-Monarch-MCP-Connector)）对读者：对手已经把「能接 AI 工具」当卖点，评论里也出现了把 MCP 当成差异化的五星评价。
- **2026 年 10 月 20 日，Cursor 发布 Agent SDK；2026 年 10 月 13 日开放 Origin 应用市场。**（[Agent SDK](https://cursor.com/changelog/agent-sdk)、[Origin App Marketplace](https://cursor.com/changelog/origin-app-marketplace)）对读者：Agent SDK 的 channels 支持 cron 定时唤醒智能体，适合「每周让 agent 读看板写总结」；Origin 市场里有 Vercel、Cloudflare 等部署应用，看板以后也可以搬出 Cursor 托管。

## 上手

先在 [EveryInfra](/docs#quickstart) 注册，建一把专给看板用的 Key，在 [App Store 评论](/app-store-api/reviews)和 [Reddit 搜索](/reddit-api/search)的试用台里各调一次，确认参数和字段；用量和单价在[价格页](/pricing)查。想先在编辑器里试，可以把 EveryInfra 的远程 MCP 装进 Cursor（[MCP 接入说明](/mcp-server)、[在 Cursor 里调用 TikTok、Instagram、Amazon 数据：插件实测](/build/cursor-mcp-tiktok-instagram-amazon-data)），在对话里试出要哪些能力、参数怎么填，再把确定下来的调用写进看板的刷新路由。每天让 agent 读一遍自家差评、开 issue 的做法，见 [VS Code Copilot cloud automations：每天给应用商店差评分类](/blog/vs-code-copilot-cloud-automations-app-review-triage)。

## 常见问题

**cursor build live app builder：它算不算一个 app builder，能做什么样的应用？**

（问题来自搜索联想词「cursor build live apps app builder」，2026 年 11 月 13 日读取。）算。描述一个应用，Cursor 搭好、托管、给你一个链接，这就是 app builder 做的事。[Apps 文档](https://cursor.com/docs/cloud-agent/apps#how-it-works)写的是 Web 应用，按需带 Postgres 和 Cursor 登录，没有提原生手机应用。因为应用默认放在 Cursor 登录后面，它最适合公司内部工具，一块只给团队看的竞品评论看板正好是这一类。

**cursor build live apps not working：为什么我的 Cursor 里没有建应用的入口？**

（问题来自 Google 搜索联想词「cursor build live apps not working」，2026 年 11 月 13 日读取。）按文档逐项排查：一是有没有用云端 agent，[Apps 文档](https://cursor.com/docs/cloud-agent/apps#getting-started)写明本地 agent 不支持；二是套餐，[Cloud Agents 文档](https://cursor.com/docs/cloud-agent#troubleshooting)写明 Free 和 Plus 不含云端 agent；三是团队设置，管理员可以在 Apps 后台把 Apps 整体关掉；四是提示词，要明确说「build an app」。另外，新加的密钥只在 agent 启动时注入，已经在跑的 agent 拿不到，加完密钥要新开一个 agent。

**cursor build live apps react：Cursor 建的应用用什么框架？能指定 React 吗？**

（来自联想词「cursor build live apps react」。）Apps 文档没有规定框架，只说 Cursor 会搭好 Web 应用、按需建 Postgres、配 Cursor 登录和托管。你可以在提示词里写明框架，本文的配置示例按 Next.js（React）写，原因是它的服务端路由和 `NEXT_PUBLIC_` 规则让「Key 只在服务端」这件事有明确的写法。框架选什么，不影响调用 EveryInfra 的方式，都是一个服务端发出的 HTTPS POST。

**cursor live apps for mac / windows：要在本机装什么吗？**

（来自联想词「cursor live apps for mac」「cursor live apps windows」。）不用。应用是云端 agent 在 Cursor 的云上搭和部署的，本机只是发起的地方。[Cloud Agents 文档](https://cursor.com/docs/cloud-agent#how-to-access)列了七种发起方式：iOS 应用、网页版、桌面版、Slack、GitHub 或 Bitbucket 评论、Linear、API。Mac、Windows、Linux 上的桌面版都行，手机上也行。

**cursor live apps free：免费版能用吗？**

（来自联想词「cursor live apps free」。）不能。按 [Cursor 定价页](https://cursor.com/pricing)（11 月 13 日读取）和 Cloud Agents 文档，Free 和 Plus 不含云端 agent，Premium（$30/月）起才有。发布以后的托管费文档没有单列。EveryInfra 这一侧按调用计费，没有月费，看板每天刷新一次的接口费见上面的算账一节。

**competitor review monitoring free：有没有免费的竞品评论监控做法？**

（来自联想词「competitor review monitoring free」。）完全免费的做法是每天手动打开对手的商店页面看。苹果和谷歌的官方评论接口都只给开发者读自己应用的评论（见上文「做不了」一节），读不到对手的。本文的做法每天的接口费按实测在一美分左右，Cursor 一侧要 Premium 套餐；如果你已经有服务器，也可以把同一段刷新代码放在自己的定时任务里，不用 Cursor。

**这是不是就是新版的 v0？和 Lovable、Replit 有什么区别？**

（来自 Reddit r/cursor 讨论帖「[Cursor can now build + deploy internal apps](https://www.reddit.com/r/cursor/comments/1xoxyh5/cursor_can_now_build_deploy_internal_apps_hosting/)」里的提问。）功能上很像：都是描述一句话、生成并托管一个 Web 应用。[The New Stack 的报道](https://thenewstack.io/cursor-ai-app-deployment/)把它和 Lovable、Replit 放在一起比，认为 Cursor 这次更偏向公司内部工具。对评论看板来说，区别主要在两处：Cursor 的应用默认放在 Cursor 登录后面，适合只给团队看；发布前的密钥检查是强制的，管理员也放行不了写死的密钥。

## 参考资料

1. Build live apps, Cursor changelog, 2026-11-05, https://cursor.com/changelog/build-live-apps
1. Apps, Cursor Docs, https://cursor.com/docs/cloud-agent/apps
1. Cloud Agents, Cursor Docs, https://cursor.com/docs/cloud-agent
1. Cloud Agents security, Cursor Docs, https://cursor.com/docs/cloud-agent/security
1. Secrets & Network, Cursor Docs, https://cursor.com/docs/cloud-agent/security-network
1. Automations, Cursor Docs, https://cursor.com/docs/cloud-agent/automations
1. Pricing, Cursor, https://cursor.com/pricing
1. Start from scratch, Cursor changelog, 2026-08-27, https://cursor.com/changelog/start-from-scratch
1. Agent SDK, Cursor changelog, 2026-10-20, https://cursor.com/changelog/agent-sdk
1. Origin App Marketplace, Cursor changelog, 2026-10-13, https://cursor.com/changelog/origin-app-marketplace
1. Model Context Protocol (MCP), Cursor Docs, https://cursor.com/docs/mcp
1. Most apps never make it off localhost: Cursor takes on Lovable and Replit with fully managed app deployment, The New Stack, 2026-11-05, https://thenewstack.io/cursor-ai-app-deployment/
1. Vercel for Platforms, Vercel, https://vercel.com/for/platforms
1. Cursor can now build + deploy internal apps, Reddit r/cursor, 2026-11, https://www.reddit.com/r/cursor/comments/1xoxyh5/cursor_can_now_build_deploy_internal_apps_hosting/
1. Cron/MCP-only automations: repo warning, no output surface, Cursor Forum, 2026-09, https://forum.cursor.com/t/cron-mcp-only-automations-repo-warning-no-output-surface-broken-add-flow/172146
1. Customer Reviews, Apple Developer Documentation, App Store Connect API, https://developer.apple.com/documentation/appstoreconnectapi/customer-reviews
1. Ratings, reviews, and responses, Apple Developer, https://developer.apple.com/app-store/ratings-and-reviews/
1. Retention messages now available, Apple Developer News, 2026-11-04, https://developer.apple.com/news/?id=fk9ps3gv
1. New age rating content descriptors, Apple Developer News, 2026-11-02, https://developer.apple.com/news/?id=yxkh08us
1. Developers bring incredible new app experiences to iPhone Duo, Apple Newsroom, 2026-10-23, https://www.apple.com/newsroom/2026/10/developers-bring-incredible-new-app-experiences-to-iphone-duo/
1. Reply to Reviews API, Google for Developers, https://developers.google.com/android-publisher/reply-to-reviews
1. View and analyze your app's ratings and reviews, Google Play Console Help, https://support.google.com/googleplay/android-developer/answer/138230
1. Trustpilot API documentation, Trustpilot Developers, https://developers.trustpilot.com/
1. Data API Terms, Reddit, Inc., 2026-07-20, https://redditinc.com/policies/data-api-terms
1. Environment variables, Next.js Docs, https://nextjs.org/docs/app/guides/environment-variables
1. Events that trigger workflows: schedule, GitHub Docs, https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule
1. About secret scanning, GitHub Docs, https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning
1. INSERT, PostgreSQL Documentation, https://www.postgresql.org/docs/current/sql-insert.html
1. RFC 9110: HTTP Semantics, IETF, 2022-06, https://www.rfc-editor.org/rfc/rfc9110
1. RFC 6585: Additional HTTP Status Codes, IETF, 2012-04, https://www.rfc-editor.org/rfc/rfc6585
1. Secrets Management Cheat Sheet, OWASP, https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
1. The hottest new vibe coding startup Lovable is a sitting duck for hackers, Semafor, 2025-05-29, https://www.semafor.com/article/05/29/2025/the-hottest-new-vibe-coding-startup-lovable-is-a-sitting-duck-for-hackers
1. Lovable: Secure Vibe Coding, Lovable blog, https://lovable.dev/blog/secure-vibe-coding
1. Introducing Personal Finance in Claude, Anthropic, 2026-11-05, https://claude.com/resources/articles/introducing-personal-finance-in-claude
1. Use Personal Finance in Claude, Claude Help Center, 2026-11, https://support.claude.com/en/articles/18185620-use-personal-finance-in-claude
1. Claude can now analyze your spending with its new personal finance tool, TechCrunch, 2026-11-05, https://techcrunch.com/2026/11/05/claude-can-now-analyze-your-spending-with-its-new-personal-finance-tool/
1. Monarch MCP, Monarch blog, 2026-10-21, https://www.monarch.com/blog/monarch-mcp
1. Monarch MCP Connector, Monarch Help Center, https://help.monarch.com/hc/en-us/articles/50207234679956-Monarch-MCP-Connector
1. Pricing, Monarch, https://www.monarch.com/pricing
1. Pricing, YNAB, https://www.ynab.com/pricing