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

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 是什么

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

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

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

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

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

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

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

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

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

看板要回答的三个问题

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

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

第一，对手最近的差评在抱怨什么。数据是 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 免费目录（2026 年 11 月 13 日 21:30 新加坡时间读取）。

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

平台页可以看每个平台的全部能力：App Store 爬虫、Google Play 爬虫、Trustpilot 爬虫、Reddit 爬虫。

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

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

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

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

Lovable 的博客写，他们每天拦下约 1,200 个被直接写进代码的私有 API Key（此前 Semafor 2025 年 5 月的报道提到过 170 个因数据库权限没配好而有漏洞的 Lovable 网站）。Cursor 这次在三处设了门。

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

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

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

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

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

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

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

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，只在服务端运行。

// 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 文档对它的说明是：遇到唯一约束冲突时不报错，改做指定的替代动作。这样同一条评论第二天又被拉到，表里也只有一行；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 通过环境变量传入，命令里只有变量名。

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、22:14、22:36（新加坡时间）。在看板的 7 次调用之外，对照组 Fintonic 三轮都调了 App Store，第二、三轮另调了 Google Play 和 Trustpilot。每次请求都记下 HTTP 状态、耗时、返回条数和 billing.charged_usd，原始返回逐个存档，下面的数字都能从存档重算。下表是 App Store 和 Reddit 三轮的对照，Google Play 和 Trustpilot 见后面「第三轮补上的两个来源」一节。

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 次调用也可以按来源并行发出，总时间就由最慢的一次决定。

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 定义 429 是「请求太多」，意思是你发得太快，等一等就好；RFC 9110 定义 503 是服务端暂时处理不了，可以带 Retry-After 告诉客户端多久以后再来。所以刷新路由的写法是：429 按 retry_after 等一次再试，503 也只重试一次，仍失败就跳过这个来源，保留昨天的数据，在这一栏标出上次成功的时间。前面配置示例里的 last_success_at 就是为这个准备的。

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

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 上留文字评论的人数，不代表下载量或收入。

这组数直接决定看板的参数。每天刷新一次时，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 管理中心的帮助页写明新评论一般延后约 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 个百分点，看板上应该显示条数，不只显示百分比。

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

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

第一，这份样本里 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 的开发者文档里，商家接口提供「发送邀请」。在这两家各 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 改掉，字段和去重规则都不用动。

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。

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

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

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

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

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

第二种是外部定时任务带 Cursor API key 进来。Apps 文档说，私有和团队应用在 Cursor 登录后面，自动化工具进不来；给它一把 Cursor API key，在每个请求的 x-cursor-app-token 请求头里带上，它就能像一个已登录的用户那样用应用。这个 key 只能放在请求头里，不能放在查询参数或 Cookie 里；用它发的请求会被标成自动化请求。团队 API key 只能打开分配给它的团队应用。我们把这个定时任务放在 GitHub Actions 的 schedule 触发器上，每天早上发一次 POST /api/refresh：

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

做不了或要注意的地方

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

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

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

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

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

• 2026 年 11 月 5 日，Cursor 上线 Build Live Apps。（更新日志）对读者：内部工具从「本机跑得通」到「团队能打开」少了托管、数据库、登录三步；数据要从外部取的看板，密钥放法是唯一要自己想清楚的地方。
• 2026 年 11 月 5 日，Anthropic 推出 Claude 的 Personal Finance 测试版。（Anthropic 原文、帮助中心、TechCrunch 报道）对读者：记账类应用多了一个通用助手做对手，看对手评论时要加一个「用户在拿谁比」的维度。
• 2026 年 11 月 4 日，苹果开放订阅退订挽留消息。（苹果开发者新闻）对读者：订阅类应用在用户点退订时多了一次说话的机会；对手评论里关于续费、退订的抱怨，是你们写挽留消息时最直接的素材。
• 2026 年 10 月 23 日，iPhone Duo 开始交付。（苹果新闻稿）对读者：我们拉到的两家对手的一星评论里各有 1 条提到没有适配 Duo。
• 2026 年 10 月 21 日，Monarch 重新开放 MCP 连接器。（Monarch 博客、帮助中心）对读者：对手已经把「能接 AI 工具」当卖点，评论里也出现了把 MCP 当成差异化的五星评价。
• 2026 年 10 月 20 日，Cursor 发布 Agent SDK；2026 年 10 月 13 日开放 Origin 应用市场。（Agent SDK、Origin App Marketplace）对读者：Agent SDK 的 channels 支持 cron 定时唤醒智能体，适合「每周让 agent 读看板写总结」；Origin 市场里有 Vercel、Cloudflare 等部署应用，看板以后也可以搬出 Cursor 托管。

上手

先在 EveryInfra 注册，建一把专给看板用的 Key，在 App Store 评论和 Reddit 搜索的试用台里各调一次，确认参数和字段；用量和单价在价格页查。想先在编辑器里试，可以把 EveryInfra 的远程 MCP 装进 Cursor（MCP 接入说明、在 Cursor 里调用 TikTok、Instagram、Amazon 数据：插件实测），在对话里试出要哪些能力、参数怎么填，再把确定下来的调用写进看板的刷新路由。每天让 agent 读一遍自家差评、开 issue 的做法，见 VS Code Copilot cloud automations：每天给应用商店差评分类。

常见问题

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

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

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

（问题来自 Google 搜索联想词「cursor build live apps not working」，2026 年 11 月 13 日读取。）按文档逐项排查：一是有没有用云端 agent，Apps 文档写明本地 agent 不支持；二是套餐，Cloud Agents 文档写明 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 文档列了七种发起方式：iOS 应用、网页版、桌面版、Slack、GitHub 或 Bitbucket 评论、Linear、API。Mac、Windows、Linux 上的桌面版都行，手机上也行。

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

（来自联想词「cursor live apps free」。）不能。按 Cursor 定价页（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」里的提问。）功能上很像：都是描述一句话、生成并托管一个 Web 应用。The New Stack 的报道把它和 Lovable、Replit 放在一起比，认为 Cursor 这次更偏向公司内部工具。对评论看板来说，区别主要在两处：Cursor 的应用默认放在 Cursor 登录后面，适合只给团队看；发布前的密钥检查是强制的，管理员也放行不了写死的密钥。

参考资料

1. Build live apps, Cursor changelog, 2026-11-05, https://cursor.com/changelog/build-live-apps
2. Apps, Cursor Docs, https://cursor.com/docs/cloud-agent/apps
3. Cloud Agents, Cursor Docs, https://cursor.com/docs/cloud-agent
4. Cloud Agents security, Cursor Docs, https://cursor.com/docs/cloud-agent/security
5. Secrets & Network, Cursor Docs, https://cursor.com/docs/cloud-agent/security-network
6. Automations, Cursor Docs, https://cursor.com/docs/cloud-agent/automations
7. Pricing, Cursor, https://cursor.com/pricing
8. Start from scratch, Cursor changelog, 2026-08-27, https://cursor.com/changelog/start-from-scratch
9. Agent SDK, Cursor changelog, 2026-10-20, https://cursor.com/changelog/agent-sdk
10. Origin App Marketplace, Cursor changelog, 2026-10-13, https://cursor.com/changelog/origin-app-marketplace
11. Model Context Protocol (MCP), Cursor Docs, https://cursor.com/docs/mcp
12. 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/
13. Vercel for Platforms, Vercel, https://vercel.com/for/platforms
14. 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/
15. 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
16. Customer Reviews, Apple Developer Documentation, App Store Connect API, https://developer.apple.com/documentation/appstoreconnectapi/customer-reviews
17. Ratings, reviews, and responses, Apple Developer, https://developer.apple.com/app-store/ratings-and-reviews/
18. Retention messages now available, Apple Developer News, 2026-11-04, https://developer.apple.com/news/?id=fk9ps3gv
19. New age rating content descriptors, Apple Developer News, 2026-11-02, https://developer.apple.com/news/?id=yxkh08us
20. 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/
21. Reply to Reviews API, Google for Developers, https://developers.google.com/android-publisher/reply-to-reviews
22. View and analyze your app's ratings and reviews, Google Play Console Help, https://support.google.com/googleplay/android-developer/answer/138230
23. Trustpilot API documentation, Trustpilot Developers, https://developers.trustpilot.com/
24. Data API Terms, Reddit, Inc., 2026-07-20, https://redditinc.com/policies/data-api-terms
25. Environment variables, Next.js Docs, https://nextjs.org/docs/app/guides/environment-variables
26. Events that trigger workflows: schedule, GitHub Docs, https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule
27. About secret scanning, GitHub Docs, https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning
28. INSERT, PostgreSQL Documentation, https://www.postgresql.org/docs/current/sql-insert.html
29. RFC 9110: HTTP Semantics, IETF, 2022-06, https://www.rfc-editor.org/rfc/rfc9110
30. RFC 6585: Additional HTTP Status Codes, IETF, 2012-04, https://www.rfc-editor.org/rfc/rfc6585
31. Secrets Management Cheat Sheet, OWASP, https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
32. 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
33. Lovable: Secure Vibe Coding, Lovable blog, https://lovable.dev/blog/secure-vibe-coding
34. Introducing Personal Finance in Claude, Anthropic, 2026-11-05, https://claude.com/resources/articles/introducing-personal-finance-in-claude
35. Use Personal Finance in Claude, Claude Help Center, 2026-11, https://support.claude.com/en/articles/18185620-use-personal-finance-in-claude
36. 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/
37. Monarch MCP, Monarch blog, 2026-10-21, https://www.monarch.com/blog/monarch-mcp
38. Monarch MCP Connector, Monarch Help Center, https://help.monarch.com/hc/en-us/articles/50207234679956-Monarch-MCP-Connector
39. Pricing, Monarch, https://www.monarch.com/pricing
40. Pricing, YNAB, https://www.ynab.com/pricing