如何在没有开发者的情况下做出 MVP,以及没人会先告诉你的事
构建不再是瓶颈了。几乎没人更新自己的计划来把这件事计入。
这是我被问到的问题,以及它底下的那个问题。
被问出的问题:我能不招开发者就把产品造出来吗?能。2026 年,一个单打独斗的创始人用 AI 工具,大约一周就能让一个能用的应用跑起来;而传统 MVP 的时间线是八到十六周——Altar.io 的数据把平均值放在接近四个月,其中三个月最常见。
底下的那个问题:那管用吗?而诚实的答案是:这取决于一些与构建毫无关系的事。
CB Insights 分析了 431 家失败的风险投资支持的公司,发现 43% 因产品与市场不匹配而失败。70% 是「资金耗尽」,而同一份分析把它当作症状而非原因。钱花光了,是在通往真正问题的路上会发生的事。
这些失败没有一个是由开发慢造成的。这意味着单独移除开发这个瓶颈,并不会让那个数字动。
究竟改变了什么,说准确点
不是「软件现在很简单」。而是某件更窄、更有用的事。
生产一个应用的成本崩塌了。决定这个应用该是什么的成本一点没动。
二十年来,开发瓶颈掩盖了第二项成本。当构建要花四个月和八万美元时,那四个月强加了某种纪律——你有时间在工程师干活的同时去和客户聊,而那笔开销让你在承诺之前先思考。
把那四个月拿掉,思考现在就成了可选项。这才是 2026 年真正的风险,而且它是新的。你能比以前快得多地造出错的东西,而它会在错的同时看起来令人印象深刻地完成了。
在给任何东西写提示词之前该做的四个决定
不是一套流程。四个问题,而且一个下午就能全部回答。
1. 这究竟是给谁的,他们今天用什么替代方案?
不是一个市场。是一个人,以及他当前的替代方案——一张表格、一个微信群、一家代理公司、周日的三个小时。如果你说不出那个替代方案,你还不知道这个问题是否真实存在,因为凡是真正会疼的问题,每个人都会有替代方案。
2. 它必须做的那一件事是什么?
那个能让某人的一天变好的单一动作。其他一切都是第二个版本。现在这件事比以前更重要,因为 AI 工具会乐意把你描述的全部九个功能都造出来,而九个功能正是通往「一个没人能解释的产品」的路。
3. 你产品里有哪些东西,它们之间如何关联?
这是创始人会跳过的那一个,也是决定第六个月能否活下来的那一个。用户、订单、项目、发票——不管你的名词是什么。谁属于谁。什么必须唯一。当其中一个被删除时会发生什么。
你不需要技术词汇。「一个客户可以有很多项目,一个项目恰好有一个所有者,两个客户不能共用同一个邮箱」——这就是一个数据模型。把它写下来要十五分钟,而这是整件事里杠杆最高的十五分钟。如果这些词汇不熟悉,技术术语词典在不假设你已经懂的前提下解释这些术语。
4. 你怎么知道它管用了?
在上线之前先选好那个数字,因为上线之后你会找到一个看起来令人鼓舞的数字。注册量通常是错的那个。有没有人第二次回来,通常是对的那个。
为什么第三个问题才是会咬人的那一个
因为跳过它之后会发生的事。
每一个你没有明确做出的决定,仍然会被做出。它由生成器在生成时做出,基于一个不包含你的业务的上下文。工具不会停下来问「两个客户能不能共用一个邮箱」。它挑一个看起来说得过去的,然后继续。
然后在第四个月,你需要加团队功能、或计费、或第二种用户类型——结果发现第一周被无声选定的那个答案,把这次改动变成了一次重建而不是一次增加。每次修复都弄坏别的东西。更多提示词让情况更糟。
开发者称之为 70% 问题:应用做到几乎完成,然后停止推进。阻塞点从来不是缺失的代码。是一个几百代生成之前被隐含做出的、再也无法便宜改动的决定。
这件事在行业层面是可测量的。DORA 的 2025 年研究发现,更高的 AI 采用率同时与软件交付吞吐量的上升以及不稳定性的上升相关联——更快也更脆,同时发生。GitClear 对 6.23 亿次代码变更的分析发现,相对 2023 年基线重复代码上升 81%,而重构活动从 2022 年占变更的 21% 降到 2026 年的 3.8%。
生成是廉价的。自洽不是,而且没有任何东西会偶然产出它。为解决这件事而建立的做法是规范驱动开发,而这个论点的架构版本在这里。
实际该做什么,按顺序
- 把四个答案写下来。 一页纸。在打开任何工具之前做这件事。如果你答不出第三个问题,你还不准备好构建——你准备好再去和两个客户聊聊。
- 按「第六个月会发生什么」挑工具,而不是按「今天下午会发生什么」。 这个赛道里的每一个选项今天都能产出令人印象深刻的东西。它们在「你之后还能不能扩展它」上差别巨大。这份格局,诚实对比过。
- 只造那一件事。 在有人用过第一个功能两次之前,抵抗第二个功能。当加功能几乎免费时,这比听起来难得多。
- 把它拿到五个真实的人面前,不是五十个。 五个有这个问题的人,会比五十个出于客气的人告诉你更多。看他们在哪里停下来,而不是问他们喜不喜欢。
- 决定你要拿那个数字怎么办。 如果没人回来,答案不是更多功能。答案是回到第一个问题。
你确实仍然需要开发者的地方
我宁愿在这件事上直说,而不是卖给你一个幻想。
任何「弄错代价很高」的地方。 超出标准结账的支付、健康数据、任何受监管的东西。不是因为工具做不出来,而是因为你无法评估它们做出来的东西是否安全,而在那些领域「看起来没问题」不是一个标准。
有负载时的迁移。 在有真实客户的情况下改动线上数据的形状,确实很难,而且出错时是无声的。
它开始管用的那一刻。 这是好问题。当使用量增长时,需要有一个理解这套系统的人来负责它。把那次招聘当作成功的里程碑来规划,而不是当作「本该避免的失败」。
你很可能不需要开发者的地方:走到「你知道有没有人想要这个」的那一步。以前这需要一个开发者。现在不需要了,而这是一个真实且值得利用的改变。
令人印象深刻的演示这个陷阱
一块能用的屏幕极具说服力——包括对你自己。
你会拿它给人看,而他们会鼓励你,因为「看着一个精致的界面」产生的反应,和「被要求改变自己的工作方式」是不一样的。鼓励不是证据。这个演示只有在有人在你不在场时用了它第二次,才值点什么。
我宁愿看到一个创始人有一个丑产品和四十个回访用户,而不是一个漂亮产品有四百个注册和零个第二次访问。后者容易得到得多,也难恢复得多,因为它感觉像进展。
那个没有变简单的部分
你现在能在一周内把东西造出来。这是真的,是真正新的东西,而任何告诉你不是的人,最近都没试过。
但那 431 家失败公司中 43% 死于产品与市场不匹配,而没有一家是因为构建花了太长时间而死的。瓶颈移动了。它移到了那个一直是最难、且以前被四个月的工程掩埋着的部分。
哪些决定,按什么顺序,为谁。那才是现在的工作。它一直都是工作。
只是构建曾经吵得足以把它盖住。
延伸阅读
具体关于架构决策:为非技术创始人写的 SaaS 应用开发。关于这些工具究竟会花你多少钱:token、额度还是投入量。
常见问题
2026 年真的能在没有开发者的情况下造出应用吗? 能。非技术创始人用 AI 应用构建器,大约一周就能让一个能用的应用上线,而传统 MVP 的时间线是八到十六周。约束不再是「你能不能造出来」——而是「你在开始之前有没有决定对那些事」。
做一个 MVP 要多久? 传统上八到十六周,数据把平均值放在接近四个月,三个月是最常见的时间线。用 AI 工具,单打独斗的创始人大约一周就能做到一个能用的产品,不过那份速度只有在底层决策是被刻意做出的情况下才有帮助。
在构建之前我该决定什么? 四件事:这是给谁的以及他们今天用什么替代、产品必须支持的那个单一动作、你产品里有哪些东西以及它们如何彼此关联,以及那个会告诉你「它是否管用」的数字。第三件是大多数创始人跳过的,也是之后造成最贵问题的那一件。
为什么 AI 搭建的 MVP 在几个月后就不行了? 因为没人明确做出的决定被生成器隐含地做出了,而那些决定限制了它们之后的一切。这就是 70% 问题:应用做到几乎完成然后停住,因为挡路的是一个架构选择,不是缺失的功能。
我需要懂数据库才能做 MVP 吗? 你不需要技术词汇,但你确实需要能说出你的产品里存在哪些东西以及它们如何关联。「一个客户可以有很多项目,一个项目有一个所有者,两个客户不能共用同一个邮箱」——这就是用平实语言表达的数据模型,而把它写下来是你能做的最有价值的事情之一。
我什么时候真的需要招开发者? 任何「弄错代价很高」的地方——受监管的数据、超出标准结账的支付——因为你无法评估产出是否安全。有负载时迁移线上数据。以及当产品开始管用、需要有人正式负责这套系统时。最后这一项请当作成功的里程碑。
在没有开发者的情况下做 MVP 要花多少钱? 工具从免费档到每月几百美元,取决于你迭代多少,而这比传统构建便宜得多。真正让创始人措手不及的成本是上线之后的那些——随使用量增长的托管费,以及如果早期架构撑不住下一个功能时的重建。