当一个产品变成两个：如何把你的 AI 应用干净地拆开，而不用从头再来

你从一个想法开始。你把它描述给你的 AI 应用构建器，看着它生成各个界面，把粗糙的边角修一修，然后发出了一个真实的东西。人们开始用它。然后，起初慢慢地，反馈里冒出了一个规律：你一半的用户想要一样东西，另一半想要别的。他们不是在争同一个功能。他们是在要两个不同的产品。

这就是很多创客会慌、然后从零开始另起一个项目的时刻。他们不该这么做。当你的一个产品原来其实是两个时，有一种更干净的办法可以拆分 AI 应用——而且它通常能保留你已经做好的大部分东西。本文要讲的，就是如何识别出这个拆分、什么时候去做，以及这个拆分往往会呈现的三种形态。

你是怎么发现自己有两个产品的

那个信号几乎从来不像一个功能需求。它看起来像是摩擦。

我见过一个生产力应用经历过这件事，它的故事很清晰。它最初是作为一个”个人计划工具”来卖的。用户开始分成两种口味出现。一群人用它来安排自己的一周，把它当成一个私人笔记本。另一群人带着小团队，想把事情指派给别人。两群人都用得还算开心，愿意继续用同一个产品，但每一次更新都讨好一群、惹恼另一群。团队以为他们有一个功能优先级排序的问题。其实他们有的是一个品牌问题。他们有一个个人应用和一个团队应用，共用着一套代码、一个主页、一个定价页。

当下面这些里有一条开始成真时，你就知道自己越过了那条线：

你的落地页不得不把它真正的卖点藏在含糊的措辞背后，因为两类受众不会相信同样的话。
每一个新功能都带着一句”但对另一类用户来说，它该用不同的方式运作”的附加说明。
你的客服回复开始分叉：“如果你是自己用的话……”对比”如果你是在管理一个团队的话……”。
有数量可观的一批用户，各自留着两个独立的账号，好把两种模式分开。

如果你看到了其中两条或更多，那你有的就不是一个功能问题了。你有的是一个等着发生的产品拆分。

拆分的三种形态

你不必在第一天就选定一种形态。你通常可以先试最轻的那种，再往上升级。但在你开始把它描述给你的 AI 构建器之前，知道这份菜单是有用的，因为你用的措辞会塑造出被生成的东西。

形态一：一个应用，两扇门

最轻的版本。你保留一套代码。你在首次启动时加一个问题——“你是为自己来的，还是为一个团队来的？“——然后用答案来展示一套不同的页面和一套不同的导航。同一个数据存储。同一个登录。同一套计费。只是一个不同的表层。

如果你把它描述成一个”双模式应用”，大多数 AI 应用构建器都能处理得很好。要当心的是，这两种模式不应该到处共用那种带着条件显隐的界面。那最后会变成一个混乱的应用假装自己是两个。告诉构建器，这两扇门是分开的——不同的主页、不同的设置页、不同的空状态界面。少数几个确实重叠的界面（账户设置、计费）可以共用。

什么时候这管用：当两类受众想要不同的呈现框架、但底层对象相同时。计划工具对比团队那个例子就属于这一类。你在安排的东西仍然是一个任务；变的只是围绕指派、共享和通知的规则。

什么时候这不管用：当两类受众期待的是完全不同的对象时。一个”客户门户”和一个”内部管理工具”几乎毫无重叠，哪怕它们看起来是关于同一门生意。

形态二：两个应用，一个后端

中间形态。你把产品的前端拆成两个独立的应用——两个网址、两个落地页、两套引导流程、两张定价表——但它们底下都从同一个数据库读取。一个客户可以在两个应用上都有账号。一个管理员可以看到两边的数据。

这正是运营这个博客的公司最近做的事。我们有一个应用想服务两类受众：评估我们 agent 平台的工程师，以及使用我们 AI 应用构建器的创客。同一个后端、同一套认证、同一个数据库——但前端长出了两个脑袋，传达的信息混乱不堪。我们把它拆成两个前端应用，各服务一类受众。后端则原封不动。

这种形态在以下情况是对的答案：

两类受众出于不同的理由购买。
他们会被另一类受众的营销文案搞糊涂或劝退。
他们在乎的数据形状大体相同，只是呈现框架不同。
你不想维护两个数据库或两套计费。

告诉你的 AI 构建器，你想要一个”共用现有 API 的第二个前端应用”。大多数现代 AI 构建器都能搭起一个同级项目，并把它指向你现有的后端。要避开的陷阱是：把第一个应用的组件原封不动地复制粘贴过去，然后永远地维护两份副本。让构建器把共用的部分（认证界面、通用表单控件）抽取到一个两个应用都用的小型库里。这能帮你省下日后几个月的重复修复工作。

形态三：两个应用，两个后端

最重的拆分。你确实有两个产品了。它们不共享数据，不共享用户，也不该共享一条路线图。正确的做法是把它们彻底分开：分开的代码、分开的数据库、分开的域名。

这种做法正确的时候，比人们以为的要少。它很诱人，因为它感觉干净。现实是，两个完全独立的应用意味着每样东西都有两份要去维持运转——两条部署流水线、两套值班轮换、两套计费集成、两套帮助文档。除非这两个产品真的毫无重叠，否则别去碰这种形态。一个好的检验方法：如果产品 A 的用户绝不可能成为产品 B 的用户，那你大概真的需要形态三。如果你大多数用户都有可能同时想要两者，那你几乎肯定想要的是形态二。

当你用 AI 构建器做这件事时，最省事的做法是把你现有的项目复制一份，作为第二个项目的起点，然后让构建器去掉不属于它的功能、加上属于它的功能。别从一张白纸开始第二个项目。你做第一个的时候已经学到了很多，而如果你愿意，AI 构建器会把那份上下文接过去。

在拆分任何东西之前要做的事

在你把这个拆分描述给你的 AI 构建器之前，先做三件小事。它们的价值比听起来要大。

第一，为每一边写一个新的主页。 各两段。卖点、受众、你想让他们做的那一件事。如果你写不出两个不同的主页，那你其实还没有两个产品——你只是有一个产品的两个细分群，而你该用信息传达去解决它，而不是用架构。

第二，列出哪些界面是共用的、哪些不是。 老实点。“登录是共用的。引导流程不同。仪表盘不同。设置大体共用。计费共用。“这张清单会变成你交给 AI 构建器的需求说明。它能省下大量来回沟通。

第三，决定底层有哪些是相同的。 同样的用户？同样的数据？同样的支付？每一个”是”都把你推向形态一或二。每一个”否”都把你推向形态三。没有正确答案——只有那个契合你产品实际运作方式的答案。

拆分之后会有什么变化

有两件事变容易，有一件事变难。

营销变容易了。每个应用都有了它自己清晰的卖点。每个落地页都可以对着一类受众说话，而不必含糊其辞。你至少有一边、有时是两边的转化率通常都会上去。

引导流程变容易了。一个初次使用的用户，落在一个关于他自己的页面上，而不是一个想兼顾所有人的页面上。

变难的是让共用的部分保持同步。如果你修了登录流程里的一个 bug，你会希望它在两个应用里都被修好。如果你改了计费界面的样子，你会希望两个应用都跟着变。你需要的那份自律——无论你是用 AI 构建器搞 vibe coding，还是带着一队人类开发者来做，这一点都成立——就是让共用的部分真正地共用。别重复。别分叉。要么把共用的界面抽取到一个两个应用都用的小型库里，要么接受你有两个真正独立的应用、并承担起这件事。

结尾留一个小问题

如果你把你当前应用的卖点说给五个陌生人听，而他们各自的描述都不一样——但分成了两个清晰的桶——那你很可能已经在和这个拆分共存了。唯一的问题是：你是继续付着”一个混乱的产品”的税，还是去做那份功课，诚实地面对自己其实是两个。

你不必今天就决定。但下一次你的 AI 应用构建器问”接下来我该做什么？“时，不妨想想：最有用的答案也许不是一个新功能。它也许是一扇新的前门。

如果这篇文章引起了你的共鸣，你可能也会喜欢我们早先那篇关于为你的团队而做 vs 为客户而做的文章——同一种味道的决定，只是处在你产品生命里更早的一步。