一个人，40 款应用、百万级用户，验证 MVP 这事，没那么复杂

Hassan El Mghari 应该是一名很成功的 AI 独立开发者了。

4 年时间，陆续开发了 40 多款 AI 应用，其中 roomGPT.io（290 万用户）、restorePhotos.io（110 万用户）等应用达到了百万级别的用户量。而这些应用，都是 Hassan 用一到两周时间，「快速冲刺」出来的。

快速开发、快速上线，而且还都是基于开源模型进行开发。

不做投放，开源，坚持 Build in public。

用最低成本验证 MVP，做的越多，对用户的需求理解得越精准，下一款应用成功的概率自然也就越大。

在 Al Engineer 近期的一场演讲中，Hassan 分享了他如何快速构建应用，从创意构思到产品落地的全流程经验，甚至还分享了他开发应用的详细流程和完整技术栈，很实在了。

其中，有很多有意思的观点：

• 应用开发者们常犯的一个典型错误就是应用发布的速度不够快，将问题过度复杂化。

• 用极快的速度将产品做到 90%的完成度，然后就推向市场，通过观察真实的市场反应再进行迭代优化。

• Hassan 构建的大多数应用都采用了极简架构，核心功能往往只需一到两次对 AI 模型的 API 调用即可完成。这种极简性至关重要，不仅能最大化地提升开发速度，更有助于快速、低成本地验证一个想法。将想法简化的越彻底，你的开发速度就越快。

• 构思阶段是整个应用开发流程中最关键的一环。Hassan 经常会记录灵感，同时用清单的形式列出来。Hassan 清单里记录了前五名创意，能够清楚地知道接下来要开发的五个应用是什么。

• Hassan 将大约 80%的时间都投入到了用户界面的打磨上。只要愿意投入时间让应用的界面看起来美观、易用且操作直观，就能够吸引到大量用户。

• Hassan 已经开发了 40 多款应用，但仍然不知道哪一个会获得成功。降低这种不确定性风险的唯一方法，就是简化项目，然后尽早发布。

• 有意识地在去设计产品的传播功能很重要。能让用户轻松分享自己创作内容的应用，表现往往要好得多。

01

今天开发者的最大问题

是发布速度太慢了

在分享一开始，Hassan El Mghari 就抛出了一个核心观点：我们正处在一个历史性的、最适合构建（Build）应用的黄金时代。

大量应用出现的背后，一方面是 Cursor、Windsurf、Bolt 等工具出现，让代码补全、应用原型构建和构思过程变得极其容易，降低了开发的门槛和效率。另一方面，则是几乎以周频率出现的突破性新模型，能够让开发者构建全新的应用。

构建新应用就像一场数字游戏，而开发者需要做的，就是不断地去尝试。

Hassan El Mghari 开发了 40 多款应用，且仍然在不断地尝试和迭代之中。他认为，应用开发者们常犯的一个典型错误就是应用发布的速度不够快，将问题过度复杂化。

Hassan 推崇极致的快速迭代。在任何一个项目上花费的时间，最多不会超过一到两周，然后立即发布。相比于一个五人团队耗时十个月精心打磨的应用，有时这些快速发布的应用反而能吸引数百万用户体验并获得极高评价。Hassan 将这个过程形容为一次历时一到两周的「快速冲刺」，在发布之后，加入评估机制，根据用户的意见和抱怨，逐步完成后续迭代。

「用极快的速度将产品做到 90%的完成度，然后就推向市场，通过抢先体验（Early Access）或 Beta 测试等形式，去观察真实的市场反应。」

Hassan 观察到的另一个现象是，当下值得构建的好项目层出不穷。「如果你是一名构建者（Builder），现在正是投身其中的最佳时机之一。」他在自己的 Notion 中维护着一个超过 70 个条目的创意清单，其中有 15 个项目是他正努力推进、希望在今年内全部完成并发布的。

「这是一个激动人心的时代，你可以用极少的资源成就极大的事业。」 Hassan 分享，他构建的许多应用非常简单，往往只依赖一到两次 API 调用，最多是由两三个调用构成的一个调用链（chain）。但是能用如此少的 API 调用和简洁的应用架构，构建出功能强大的产品，这一点令人十分着迷。

02

从社交媒体中寻找真实的产品需求

几年前我刚起步开发应用时，常常对开发方向感到迷茫。于是，我的策略是去 X（推特）上发掘灵感，观察人们正在讨论什么、需要什么。当时，我看到 Samina 发了一条推文：「谁能开发一个帮我挑选眼镜的应用？」 我的第一反应是：「没问题，这个需求我能实现。」 随即，我开发了这个小工具：它收集用户的具体需求，转化为查询参数，然后调用亚马逊的 API 来匹配相关产品，用户点击即可完成购买。

另一个应用的开发灵感，则源于我的朋友 Theo 的一条推文：「我想要一个能帮我撰写 Git Commit 信息的 AI 应用。」 当时，我们公司的 CTO 也认为这是个绝佳的主意，于是我开始着手开发。它的工作流程极其简单：当你执行 git add 命令后，它会自动获取代码的变更差异（diff），将其发送给一个 AI 模型，然后将生成的提交信息展示给你，供你选择是否接受。这是我早期开发的应用中相当成功的一个，累计获得了约四万次安装下载。并且由于是开源的，它吸引了大量社区贡献者，形成了一个非常健康的生态。

除此之外，我还构建了很多其他类型的应用，包括：

• 文本转应用类工具：这类工具很多，你可以输入你想要的应用描述，例如：「一个关于美国历史的问答应用」。它的工作原理是，将这个提示（Prompt）发送给一个 AI 模型生成项目规划，再由另一个模型依据规划编写出 React 代码并最终形成应用。这个应用已经处理了约 500 万次请求，生成了约 100 万个应用，累计用户也超过了 100 万。
• 实时图像生成应用：这个应用同样拥有超过 100 万用户，累计生成的图像数量达到了约 4800 万张。
• 草图转网页应用：它的功能是，你可以在一张餐巾纸上画一个简单的网页应用草图，拍照上传后，它就能为你生成相应的代码。这是我的另一个作品，拥有约 4 万名用户。
• 简历转个人网站应用：用户上传简历后，它能自动生成一个个人网站。
• 其他：还包括菜单可视化应用、AI 聊天辅导应用（你可以输入感兴趣的话题，比如「个人理财」，它会用小学生能理解的语言来解释），以及一些与光学字符识别（OCR）相关的应用。

03

开发框架要尽可能简单，

方便快速迭代

我所构建的大多数应用，底层都遵循着一个高度相似且极简的架构范式。

通常，工作流可以归结为四个步骤：

1. 接收用户输入： 包括文本、图像等形式的数据；
2. 调用 AI 模型： 将输入发送至 Together AI 上的某个模型进行处理。例如，在一个图像到图像的应用中，我将一张图片发送给 AI 模型，生成另一张图片；
3. 将图像或文本存储到数据库中： 在许多场景下，我会将生成的图像或文本存储到数据库中，以便向用户展示。
4. 向用户呈现结果。

这是一个极其简洁的架构，在绝大多数情况下，核心逻辑仅是一次 API 调用。用户执行操作，我调用一次 AI 模型的 API，获取响应后直接呈现给用户。我坚信，这种极简性至关重要。它不仅能最大化地提升开发速度，更有助于快速、低成本地验证一个想法。将想法简化的越彻底，你的开发速度就越快。

此外，使用 AI 开发应用的一个好处是，针对 AI 模型更新迭代极快的情况，可以快速且轻松地替换和升级底层的 AI 模型。在绝大多数情况下，在操作上，你只需要修改一行代码，来更新模型的名称，同时甚至能解锁全新的功能。我经常会回头去做这样的维护工作，甚至会用新的 AI 模型重新发布一个已有的应用，或者为它增添一个小功能。

我常用到的技术栈 （Tech Stack）包括：

• AI 模型： Together AI 提供的所有模型全栈框架： Next.js & TypeScript
• 数据库： Neon
• 身份验证： Clerk
• 数据库 ORM: Prisma （用于在 TypeScript 中进行数据库操作）
• 前端 UI: Shadcn/ui & Tailwind
• 对象存储： S3
• 网站分析： Plausible （能够追踪独立访客数、来源渠道、地理分布和设备类型等信息数据）

04

从构思到发布，

只需要七步

我经常被问到的一个问题是：「你的这些创意从哪来的？」 我认为，关键在于将一闪而过的灵感，转化为一个结构化的清单列出来。我们总会在不经意间迸发出好的想法，但大多数人不会记下来，而真正的关键在于将其捕捉和记录下来。

因此，我会将想到的点子全部列出，当我看到有趣的想法或产品时，会思考：「或许我可以用类似的方法论来构建一些别的东西。」 构思阶段非常重要。我的清单里通常会记录前五名的创意，这会让我清楚地知道接下来要开发的五个应用是什么。当然，如果中途有新的、更令人兴奋的想法出现，我也会灵活调整。比如，下周如果有重磅的开源图像模型发布，我很可能会立即投身于利用它开发一款新应用。

这是我开发应用的完整流程：

1. 构思与列表化： 将所有想法记录下来，构思阶段是整个流程的关键。
2. 命名与域名： 构思一个简短、易记的名称。可以借助像 Domains GPT 这样的 AI 工具来寻找灵感，并同步确认对应的域名是否可用。
3. 设计工作流程： 规划应用的核心交互路径。例如，设计一个着陆页，用户点击进入后上传内容，然后看到生成结果。你可以在纸上绘制草图，也可以使用 Figma 等原型设计工具来将其梳理清晰。
4. 开发最小可行版本 （MVP）： 致力于打造一个特定应用的最简化可行版本，其核心功能通常只需要一个 API 端点。
5. 集成身份验证与使用限制： 当拥有一个可运行的原型后，考虑身份验证和使用限制等问题。你需要评估应用的成本、为每位用户设定的每日使用配额、以及是否允许用户使用自己的 API 密钥等，这些决策取决于应用本身和所使用的 AI 模型。
6. 发布准备：包括精心制作 Open Graph Image、购买域名、集成分析工具、撰写详尽的 README 文件。由于我所用到的都是开源的，因此要保证代码易于使用和克隆。
7. 发布与推广： 我通常会在领英或 X 上发布我的产品，然后密切关注大家的反应。

05

给开发者的建议：

高频实践、低成本、开源

接下来是我给各位开发者的一些建议：

构思一个既让你感兴趣又非常简单的想法。这种简单，应该达到能用五个词向任何人清晰描述的程度。比如「Blink Shot——实时生成图像」，或者「Llama Coder——文本转应用」。许多开发者常犯的错误，是构想过于宏大的蓝图，然后投入漫长的时间去开发，最终却发现想法不可行、难以实现或无人问津。因此，关键在于一个让你本人感到兴奋且极其简单的想法。

确保用户界面是美观的。 在我展示的这些 AI 应用中，我将大约 80%的时间都投入到了用户界面的打磨上。我早期开发过几个界面难看的应用，无一例外地没人用。后来我意识到，即便是最简单的想法，只要你愿意投入时间让界面看起来美观、易用且操作直观，它就能够吸引到大量用户。

保持应用的简洁性。我在前边反复强调过这一点，我的大多数成功应用，核心都只依赖一到两次 API 调用。

尝试使用最新的 AI 模型。 我展示的许多应用都得益于对最新 AI 模型的第一时间采用。例如，实时图像生成应用 Blink Shot，是在 Flux 模型发布仅两天后推出的。成为第一批利用这项新技术的应用之一，能够极大地提升产品的传播度。

尽早发布、持续迭代。 即使我已经开发了 40 个应用，但仍然不知道哪一个会获得成功。降低这种不确定性风险的唯一方法，就是简化你的项目，并尽早发布。如果它没有获得太多关注或使用，你至少只投入了一周而不是六个月的时间，这样可以继续去探索其他想法。

坚持免费与开源。这种策略能让人们从你的代码中学习，更重要的是，人们更有动力去分享你的作品。

将分享机制融入到产品设计中。能让用户轻松分享自己创作内容的应用，表现往往要好得多。所以我会有意识地在去设计产品的传播功能。比如当用户生成一张满意的图片，我会让分享动作极其简单，确保分享出去的链接预览图足够精美、吸引人。最终要达成的目标，就是创造一个「创造-分享-吸引」的自发传播循环，让每一个用户都成为你产品最有效的推广者。

多做、持续做！我的许多 AI 应用表现并不好，说明它是一场数字游戏，你必须不断地开发。开发的越多，就越发现哪些想法能真正引起用户的共鸣，你的开发速度会越来越快，你选择应用想法的眼光也会越来越精准。所以，这在很大程度上取决于你投入的时间和实践的数量，构建大量的应用，然后观察结果。

文章来自公众号“Founder Park”