> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 85 个 AI 做出来的应用：有受众月入 4 万美元，没受众 2 千 - URL: https://www.hubwiz.com/blog/ai-built-apps-revenue-audience-gap-85/ - Published: 2026-10-30T16:11:49.000Z - Updated: 2026-10-30T16:12:56.000Z - Description: 85 个 AI 应用的真实收入：有受众的中位数 4 万美元/月，没受众 2 千。而能从支付渠道核验的数字只有 26 份。 - Author: admin - Tags: AI 编程, 独立开发, 副业, Vibe Coding, 商业模式 过去几个月，Indie Hackers 上的作者 Kingringo 一直在做一件很笨的事：把用 AI 编程工具（Claude Code、Cursor、Codex、Lovable 等）做出来、并且**公开报过收入**的应用，一条一条收集起来，每条都附上出处。攒到 85 个之后，他把它们放进一个数据集，跑了跑数字。2026 年 10 月 27 日，他写了结果。 有几个发现出乎他自己的意料，其中最大的那个是：**决定这些应用收入的，不是做得好不好，而是上线前有没有受众。** 有受众的 9 个案例，月收入中位数是 **4 万美元**；受众小的 19 个案例，中位数是 **2,000 美元**。差 20 倍。 但这份数据里最该先记住的数字其实不是这个——**能核验的收入，中位数只有 2,280 美元。** ## 一、四个发现 ### 1\. 上线前的受众，比其他任何变量都更能对应收入 作者的原话：有大量关注者的创始人，月收入中位数是 **4 万美元**（9 个有美元月收入数字的案例）；关注者少的创始人，中位数是 **2,000 美元**（19 个案例）。 分母也要看清楚：**85 个案例里只有 4 个说自己完全是零受众起步。** 这 4 个里有 3 个给了月收入数字，中位数 1.7 万美元——但他自己补了一句：三个案例构不成规律，我不从中读任何结论。 ### 2\. 可核验的数字，比其余的少一个数量级 85 个里只有 **26 个**的收入是从支付服务商直接读出来的（通过 TrustMRR 这类公开档案）。 只看有美元月收入数字的案例，三种来源的中位数是这样： | 收入来源标签 | 案例数 | 月收入中位数 | | ------------------------------------------------- | --- | ------------- | | 可核验（第三方从 Stripe / RevenueCat 等读出，与创始人自述差在约 20% 内） | 18 | **2,280 美元** | | 创始人自述 | 16 | **16,000 美元** | | 后台截图 | 9 | **33,000 美元** | （表格按原文数字整理。） 而且：**18 个可核验的应用里有 11 个，月收入不到 1 万美元。** 作者给了一个诚实的解释：一部分差距来自"案例是怎么被找到的"——收入档案库里躺着大量小应用，而帖子、访谈和视频天然只讲大赢家。但他也说了一句更重要的：**我现在看那些没核验过的大数字，眼光不一样了。** ### 3\. 几乎没有人只靠一个渠道 在 82 个说明了获客方式（渠道来源）的案例里，**只有 10 个把所有功劳归给单一渠道**。中位数是 **3 个渠道**。被提到最多的是 X（29 个案例）、SEO（20 个）、build in public（19 个）。 ### 4\. Claude Code 是被点名最多的工具 85 个案例里 **36 个（42%）提到 Claude Code**，其次是 Cursor（30 个）和 Codex（15 个）。**38 个案例同时提到两个或以上的工具。** 报告里有按工具分的收入中位数，但作者明确说分组太小，不要据此选工具。 ## 二、他是怎么收的 方法部分值得单独抄下来，因为这类"收入盘点"最容易在口径上糊弄： - **每一个案例都必须是公开的帖子、访谈或视频**，创始人在其中报出收入，时间跨 2025 年 3 月到 2026 年 10 月；每条都链回原始出处。 - **每个数字有一个标签**：*Verified*（第三方档案从支付服务商读出，且与创始人自述相差在约 20% 以内）、*Screenshot*（创始人给了后台截图）、*Self-reported*（只有他自己的话）。 - **不做汇率换算，也不把 ARR 折算成月收入**。85 个案例里只有 43 个给了美元月收入，所以收入中位数只用这 43 个；其余 42 个仍计入工具与渠道统计。 - **用中位数而不是平均值**，原因是"几个大数字就会把平均值拉上去"。 ## 三、他自己列的四条"这不能告诉你什么" 这一段是全文最像样的部分，直接照译： - **幸存者偏差。** 这些都是赚到钱、并且公开说了的应用。没赚到钱的人很少发帖。**这不是"一个典型 AI 应用能赚多少"。** - **样本太小。** 受众那一组对比是 9 个对 19 个。当成提示，别当结论。 - **85 个数字里有 59 个是创始人自己的说法**（有没有截图都一样），没有人审计过。 - **这是相关性。** 有受众，可能只是"有经验"或"属于那种会公开报数的创始人"的替身变量。 最后他给了完整报告、方法、CSV，并以 CC BY 授权发布，注明出处即可使用。 ## 四、评论区把话说得更硬 这篇的评论区质量比正文还高，两个质疑值得单独拎出来。 **质疑一：分母根本不存在。**（Zane Berg） > 这个数据集里只有报过收入的应用，所以"零受众"那一组没有分母。一个有 5 万关注者的创始人发了自己的月收入，被看见、被收录；一个没有受众、月收入也很小的创始人，通常根本不发，或者发了也没人看见。**光这一条就足以造成"85 个里只有 4 个零受众"。** 如果可能，从 TrustMRR 这类目录里**按上线日期**而不是按"发过收入帖"抽样一批应用，看看受众差距还成不成立。 作者认了，而且说得更直白：**"这基本上是幸存者上面再叠一层幸存者。"** 他说按上线日期抽样是个好主意，可能会试。 **质疑二：差距到底在受众，还是在"核验"。**（PatchAndShip） > 可核验 2,280 对截图 33,000，是 **14 倍**的差距。所以只算核验过的数字时，受众差距可能也会缩小。能不能把发现 1 只用那 26 个核验过的重跑一遍？ 作者的回应很实在：核验过、且有美元月收入数字的只有 18 个，再按受众一拆就迅速变得极小，但他会试。 还有一条来自"零受众那一边"的实战补充（keithwyong）：他们最早的付费客户**不是靠发产品内容来的**，而是在买家本来就在的地方回答了一个具体的页面问题（比如"有浏览但没有收藏"这种帖子），之后才有人问"你们用什么做的"。他的建议是：把"有受众"拆成两件事——**你自己拥有的受众**，和**出现在已经被提问的地方**。 在独立游戏商店页这种细分里，**一场对味的讨论里的几百个人，胜过几千个不做游戏的泛粉。** ## 五、我们的整理：把这份数据变成能用的判据 **一、先看标签，再看数字** 很多人引用这类数据时会跳过来源标签。按这篇的口径，同一批应用能读出三个差着数量级的中位数： | 你看到的说法 | 实际含义 | 该打几折 | | ------------------- | ---------------- | -------------------- | | "月入 $30K" 附后台截图 | 只看得到他想截的那一段时间和口径 | 很大——可核验组中位数只有它的 1/14 | | "月入 $16K" 创始人自述 | 没有第三方读取，也没有审计 | 中 | | "月入 $2,280" 支付渠道可核验 | 第三方读出、与自述差 20% 内 | 最小 | 一句话判据：**看到收入数字，先问"谁读出来的"。** 这个问题能过滤掉大部分噪音。 **二、"分发 > 构建"这句话，这次有了数字形状** 评论区那句总结得很好：*每个 AI 工具都在同一年让"构建"变便宜，于是构建在同一年不再是稀缺的；分发本来就稀缺，现在它是全部。* 如果你的判断是"我做出更好的产品就能赢"，这份数据不支持你。但反过来也要小心——如 Zane 所说，这个结论被幸存者偏差放大了。**更稳的说法是：构建不再是壁垒，分发是；而不是"分发决定一切"。** **三、把"受众"拆成两问，比二选一有用** 评论里那个区分值得抄走。上线前问自己： 1. **我有没有自己的受众？**（关注者、邮件列表、社区身份） 2. **我能不能出现在"问题已经被提出"的地方？**（某个具体帖子、论坛、issue、reddit 帖子） 第二问是可执行的、不需要粉丝的。keithwyong 的说法是：对味的几百人 > 不对味的几千人。**这两问的组合，比"有受众 / 没受众"的二分更能指导动作。** **四、想自己做同类盘点，五步就够** 1. **只收公开、可链回出处的案例**，每条记下时间（这篇跨了 19 个月）。 2. **给数字打标签**（核验 / 截图 / 自述），不同标签分别算中位数，别混。 3. **不换算汇率、不把 ARR 当月收入**——口径一变，中位数就失真。 4. **用中位数**，并且**公布样本数**（9 个对 19 个这种事一定要写出来）。 5. **明确写出"这不能告诉你什么"**：幸存者偏差、样本量、未审计比例、相关性不等于因果。 **站内几条接得上的线** - [Agent 写完的代码没人读过：出事时你该潜多深](https://www.hubwiz.com/blog/agents-do-the-work-ownership-three-pillars/)——独立开发者的另一面：产品上线之后的"所有权"成本。 - [AI 编程的未来已经到来，只是分布得极不均匀](https://www.hubwiz.com/blog/ai-coding-velocity-feature-gap-essential-complexity/)——代码产出变多、上线的功能没变多，和"构建不再稀缺"是同一件事的两个尺度。 - [多 Agent 写代码：代码是最简单的部分，协议才是系统](https://www.hubwiz.com/blog/multi-agent-coding-workflow-identity-isolation-review/)——"做出东西"这一步被 agent 抹平之后，剩下的难点在哪。 **五条边界** - **这不是"AI 应用收入"的全景。** 它是"公开报过收入的 AI 应用"的集合，作者自己在文里说了三遍。**不能反推中位数以外的分布**，更不能反推成功率。 - **59/85 未审计。** 引用具体数字时，务必带上它是自述、截图还是核验。 - **两个对比组都很小**（9 对 19）。任何"受众值 20 倍"的说法都超出了数据能承载的强度。 - **作者有立场。** 他在持续维护这个数据库和报告（站点有 newsletter 与投稿入口），收集本身是他的项目——这一点按惯例要标出来，不影响数据可用性（CC BY，可复核）。 - **工具比较基本没有意义。** 原文自己说分组太小，"别据此选工具"，我们照抄这句。 **来源**：Kingringo,《I went through 85 AI-built apps that share revenue. Founders with an audience reported $40K/mo, without one $2K》, Indie Hackers, 2026-10-27。原文链接：[https://www.indiehackers.com/post/i-went-through-85-ai-built-apps-that-share-revenue-founders-with-an-audience-reported-40k-mo-without-one-2k-67d054025c](https://www.indiehackers.com/post/i-went-through-85-ai-built-apps-that-share-revenue-founders-with-an-audience-reported-40k-mo-without-one-2k-67d054025c?ref=hubwiz.com)。完整报告（含每个案例的出处、方法、CSV，CC BY 授权）：[https://shippedandpaid.com/reports/ai-built-app-revenue-2026/](https://shippedandpaid.com/reports/ai-built-app-revenue-2026/?ref=hubwiz.com)。四个发现、方法与四条局限为原文内容；评论区四则引语为原评论摘译；标签中位数表、"先看标签"表、"受众两问"、"五步盘点法"与五条边界为我们整理。原文封面是标题卡（未使用），本文封面为 Unsplash 图库照片。 本文由汇智网编译整理，转载请注明出处。 > **这是「AI 编程 / Vibe Coding」专题的一部分。**完整地图见：[AI 编程 / Vibe Coding 完全指南](https://www.hubwiz.com/blog/vibe-coding-stack/)