你宣布要做一款应用，搭个落地页，收集邮箱，告诉大家：令人期待的东西就要来了。
与此同时，另一个人看到同样的机会，打开编程智能体，开始动手。
等你发出“快准备好了”的邮件，潜在客户可能已经在用别的产品。
这就是在智能体开发时代，我对创业公司候补名单的疑问。从一个想法到可用版本，所需时间已经改变。我不太确定，关于产品发布的建议是否跟上了变化。
如果今天就能提供有用的东西，为什么还要让人以后再来？
旧方法有它的理由
过去开发产品需要数月工程投入，候补名单让创始人能够接住早期兴趣：测试文案、招募测试用户，在软件逐渐成形的同时聚集受众。
Linear 和 Superhuman 是熟悉的例子。Linear 从名单中挑选早期用户，通过小批次测试改进产品。Superhuman 大量投入一对一上手指导。两种方式都帮助团队有针对性地了解客户。
但这些策略诞生于今天的编程智能体出现之前。它们解释了旧方法的来历，却不能证明其中的取舍如今仍然合理。
当交付一个能运行的实验版本变得便宜，只收集兴趣表达就更难得到充分辩护。
邮箱地址说明有人足够喜欢你的承诺，愿意填写表单。真正使用应用的人，才能指出承诺在哪里落空。
你也给了竞争者时间
公开的候补名单，会在你未必已经赢得客户之前，就公布一个机会。
当产品的核心功能相对容易复现时，这一点尤其重要。公告描述问题，演示勾勒方案，报名数量展示需求。
竞争者不必复制你的整张路线图。只要先解决客户问题中的足够一部分，就能比你更早变得有用。
这是竞争风险，不是已经证实的定律。我没有找到研究证明候补名单经常导致创业公司丢掉市场。同样，先发布也不保证胜利。
尽管如此，故意拉长“我想要”和“我能用”之间的距离，仍然值得审视。
客户的问题正在发生。发布日程是你的安排。
新一些的例子告诉我们什么？
Lovable 在自己的回顾中描述了 2024 年两次不成功的发布、从名单中逐步接纳用户，以及仍然频繁卡住的 AI。公司将最终突破归因于产品改进、品牌重塑和更好的沟通。名单早就存在，但不足以带来突破。
Manus 让“限制访问的发布方式已经过时”这个断言变得复杂。它在 2025 年 3 月开始邀请制测试，之后宣布年度经常性收入达到 1 亿美元。这说明限制式发布之后可以取得商业成功，却不能说明限制本身导致了成功，也不能说明更早开放会更差。
我们应当在两个方向上采用同样的标准。成功公司用过候补名单，不证明名单有效。失败公司用过名单，也不证明名单就是问题。
邀请别人进入产品，是另一回事
为一个想法收集兴趣，与控制人们已经在使用的产品的访问权限，有重要区别。
Instinct 展示了邀请模式：其公开首页有“邀请朋友”的链接。这本身不能解释公司为何限制访问，但指向一种不同的互动：现有用户可以把另一个人带进产品体验。
当邀请通向真正能用的产品时，我觉得它更可信。
合理的限制确实存在。你可能每周只能支持少量新客户。运行智能体可能很贵。你可能需要先观察故障，再接纳更多人。
邀请同样可以制造稀缺感。形式不能回答问题，限制的原因才能。
最有力的辩护：寻找客户仍然需要投入
开发更快，并不会自动带来获客渠道。
一个近期的创始人自述说明了这一点。Hado SEO 的创始人称，自己收集了 80 个邮箱，在发布周将其中五人转化为付费客户。发布前，他花时间在社区帮助潜在客户，打磨产品主张。这些数据来自本人，未经独立核实，但描述的是付费转化，而不只是漂亮的报名总数。
这是为短期发布准备辩护的合理理由。你可以了解客户聚在哪里、怎样描述问题，以及你能否触达他们。
但仍有一个问题：如果给同样的人一个小而能用的产品，你是否能学到更多？
开发越快，这个替代方案就越现实。
让等待有充分理由
我怀疑那些主要为了让未发布应用显得抢手的候补名单。
有用的名单应该对应具体限制：容量上限、客户实验、外部依赖，或者正在解决的产品问题。应该有等待的理由，也有获得访问资格的条件。
“制造热度”是弱得多的回答。
在加上邮箱表单之前，先想想能给这些人交付什么。一个工作流程。一项有用的能力。一个范围有限、却能做好一件事的版本。
然后，你就能衡量他们是否使用、是否回来，以及是否在意产品改进。
如果别人在你制造完期待之前，就能发布你这个想法的可用版本，那么你究竟在等什么？