VC 失败了，他用 AI 产品组合自举做到月入 $20K

原文来源：Bootstrapping a $20k/mo AI portfolio after his VC-backed company failed — Indie Hackers 对 Alex Van Le 的深度访谈

Alex Van Le 的故事，可能是 2026 年独立开发者最想听到的那种叙事：VC 公司失败了，自举却成功了。

他持有计算机科学和金融双学位，之前与人联合创立了一家 VC 支持的金融科技公司。四个联合创始人、拿到了种子轮意向、零收入、糟糕的 GTM 策略——最后公司死掉了。

然后他从零开始，用两款 AI 产品 —— AI Flow Chat（可视化 AI 工作空间）和 Starpop（AI 视频生成）—— 在一年内把月收入做到了 $20K MRR。

没有 VC，没有团队，完全自举。

VC 给他上了哪些课？

「我们在讨论条款、战略、讲故事、做幻灯片上花了太多时间，而在营销和了解客户上花了太少时间。」

这是 Alex 对第一家公司的总结。四个创始人、一个不错的 idea、有投资人感兴趣。听起来不错，对吧？问题是，投资人感兴趣不等于客户需要。

他对 VC 陷阱的反思非常犀利：

VC 的评估逻辑是「叙事-市场匹配」，不是「产品-市场匹配」。投资人买的是你的故事能否融入他们的投资组合逻辑，不是你能否做出有人付钱的产品。很多创始人把投资人的热情误认为是市场需求。
资本应该用于放大已验证的产品，而不是推迟验证。如果你的产品还没人付钱，拿更多钱只会让你在错误的路上跑得更远。
四名创始人却没人真正负责获客——架构太豪华，反而模糊了最核心的问题：产品卖给谁？

—— 广告 ——

营销优先：顺序不能错

从失败的灰烬中走出来后，Alex 建立了一套完全相反的方法论。核心是营销优先，而且顺序是铁律：

印象 → 转化 → 留存

大多数人做产品时把顺序搞反了：先花大量精力建留存体系，然后发现根本没人来用。Alex 的做法是——在还没用户的时候，别管留存。

他的决策原则更狠：

「任何一个功能，节奏是：想出来 → 写代码 → 推广。如果你不知道怎么推广一个功能，就别花时间做它。因为做出来也带不来一分钱收入。」

这在独立开发者圈子里是个有争议的观点。很多人信奉「做好产品自然有人用」。Alex 的经历证明：在不缺好产品的世界里，这行不通。

具体是怎么引流的？

1. 创始人-渠道匹配（Founder-Distribution Fit）

这不是一个标准化的 checklist。你要找到那个你的个人信用、你的背景故事、你的语境能创造不公平竞争优势的分发渠道。

对 Alex 来说，这个渠道是 X（Twitter）。他在 X 上分享自己 VC 失败的经历和自举过程，一下子火了。他的故事本身就是一个病毒式传播的内容。

可复制的逻辑：不是每个人都有失败的 VC 故事可讲，但每个独立开发者都有自己「为什么做这个产品」的真实叙事。找到那个能打动人的角度，你的个人经历就是最好的分发引擎。

2. 社区渗透（高转化，但慢）

在 Reddit、Discord、Indie Hackers 上发布真正有用的内容（不带推广链接）。当有人通过私信主动联系你时，信任已经建立好了。

Alex 报告的一个数据非常惊人：社区渠道来的用户，私信转化率高达 50%。

但代价是时间——需要连续几周到几个月地在社区里产出有价值的内容，才能开始看到转化。这是一个复利效应：一篇 6 个月前发的教程至今还在带来流量。

3. 冷私信（仅限已建立信任后）

不是批量群发，而是只回复那些已经跟你内容互动过的人。

产品思路：快速迭代 + 共享代码

MVP 两周内搞定

AI Flow Chat 的初始版本是一个黑客松原型，用了两周。范围极小——核心 UI 和基本后端能跑就行。

「我几乎是故意留了几个 bug 在那里。零用户的时候，bug 根本不重要。反正技术假设会随着用户反馈改变。」

这是一个极其务实的做法。很多开发者（包括曾经的我自己）在第一个版本上追求完美，结果等写完了才发现没人需要这个产品。Alex 的做法恰恰相反——先扔出去，再看谁捡起来、怎么用的。

代码重写了好几次

大部分原始代码都扔掉了。快速上线的真正好处不是代码质量，而是你学到了用户真正需要什么。

共享代码架构

两款产品（AI Flow Chat 和 Starpop）共用同样的文件结构和库。一个项目修了个 bug 或加了功能，另一个自动受益。切换项目的上下文成本几乎为零。

「感觉就像我知道两个代码库里每个东西在哪。」

为什么做多产品组合？

Alex 选择同时维护两款产品，而不是把所有精力放在一个上，是出于对 AI 行业特殊性的判断：

模型迭代太快，一个产品可能因为某个模型更新而被商品化
两个产品互相备份——如果一个不行了，另一个还在产生收入
共享代码架构让维护成本远低于独立的两套代码

如何判断什么时候放弃什么功能？

Alex 的决策标准是数据加直觉：

如果一个功能做出来没人用、也不会去推广它——那从一开始就不该做
如果一个产品的增长曲线连续几个月是平的——可能需要调整方向

他的个人原则也很有意思：

「如果我感觉像是在『牺牲』什么，通常意味着有些事情我在个人层面并不享受。现在我先把『玩得开心、保持动力』放在『公司』前面。」

给独立开发者的四条经验

不要沉迷于融资叙事。VC 的认可不等于市场验证。先让真实用户掏钱，再考虑要不要拿钱。
营销是产品的一部分。在写代码之前，先想清楚这个东西怎么让别人知道。不知道怎么推广的功能，不值得做。
先快速上线，再迭代品质。故意留几个 bug 也没关系——零用户时的完美主义只是拖延你了解真实需求的借口。
AI 时代可以考虑产品组合策略。单款产品可能被模型更新冲垮，但多款产品的组合可以分摊风险。前提是能共享代码基础设施，否则维护成本会吃掉所有收益。

Alex 的故事最打动人的地方在于：他不是那种卖课的「导师」，也不是天才型创始人。他就是一个普普通通的开发者，犯过大多数创业者都会犯的错误，然后从错误中总结出一套更具操作性、更适合独立开发者的方法。这套方法不一定对每个人都适用，但至少证明了：VC 想要的不是你需要的东西——而这可能反而是个好消息。