复制仓库、改产品名、换 Logo、接着开发。

这是我准备做第二个 AI 产品时，脑子里最先出现的方案。原来的项目已经有登录、上传、积分、异步任务、模型调用、轮询、结果存储和历史记录，能省下的开发时间看起来非常多。

仓库复制完成后，项目也确实能正常启动。

但我很快发现：代码能跑，不等于它已经变成了第二个产品。

旧导航还在讲视频生成，旧页面还在回答上一批用户的问题，邮件、示例、SEO 文案和默认工作流也都带着原产品的假设。表面上是一个新仓库，实际上只是旧产品换了一个壳。

所以这次我没有立刻加新功能，而是先删掉了大半个网站。

我想复用的是能力，不是旧产品

原项目最值钱的部分，不是已经做好的几十个页面，而是藏在页面下面的运行能力。

比如一次生成请求，需要经过：

• 登录和权限判断；
• 文件上传；
• 模型和参数校验；
• 积分计算；
• 创建异步任务；
• 提交到不同 Provider；
• 轮询或接收状态；
• 保存生成结果；
• 失败处理和历史记录。

这些东西重新做一遍，不但费时间，还会重新踩一遍失败状态、重复扣费、刷新恢复、Provider 差异等坑。它们是真正值得复用的 “引擎”。

但引擎上面的产品层不一样。

路由、导航、首页结构、模型推荐、示例素材、SEO 页面、默认输入和文案，都在表达一个具体产品是谁。它们做得再完整，也不代表适合第二个产品。

我后来给自己定了一条简单规则：

用户看不见但必须稳定一致的，优先保留；用户能看见并据此理解产品的，重新判断。

真正困难的是删除已经完成的东西

删除一个没做完的实验很容易，删除一个已经写完文案、翻译、结构化数据、配图、测试和内链的页面就难多了。

因为它看起来是 “资产”。

但如果这个页面只属于旧产品，那么它对新产品来说就是带着维护成本的历史包袱。

这次我删掉了不少旧的顶层页面、视频模型页、效果页、工具页、相关数据、测试和素材，也移除了不属于新方向的音乐生成与 PPT 转视频链路。

我不是只删路由文件，而是按完整切片处理：

页面
├── 页面区块
├── 数据
├── 多语言文案
├── Metadata
├── 图片和视频
├── 测试
├── 导航入口
└── Sitemap / 发现入口

这样做有一个意外收获：删除会暴露代码的真实边界。

某个所谓的共享组件，如果删掉一个旧页面就无法编译，说明它可能偷偷依赖了页面专属数据。某个全局测试因为旧导航消失而失败，说明它验证的也许不是基础能力，而是旧产品的结构。

编译错误和测试失败没有只给我增加工作量，它们还告诉我：哪些依赖方向原来就是错的。

我没有把两个产品做成一个 “万能模板”

有两个同源产品之后，很容易产生一种冲动：是不是应该做成多品牌系统？

加一个品牌配置，再做一套路由注册、页面 Schema、组件 Variant 和部署矩阵，以后想做第三个产品时就能继续复制。

这个思路听起来很工程化，但我最后没有这么做。

原因很简单：现在只有两个产品，还没有足够证据证明它们必须长期同步。

它们的主任务、页面结构、SEO 方向、默认模型和发布节奏都可能越来越不同。为了一个还不存在的第三个产品，提前让每次修改都面对品牌分支，反而会把简单问题变复杂。

所以我保留了两个独立仓库，只让真正稳定的能力保持清晰边界。站点身份、导航、页面和内容属于各自产品；任务、积分、上传、Provider 和结果生命周期则尽量只有一套权威逻辑。

什么时候我会重新考虑多品牌框架？

至少要看到这些证据：

• 同一类修改需要反复在多个仓库同步；
• 产品共享部署、数据库和发布节奏；
• 已经出现三个以上的真实消费者；
• 分开维护的成本可以被明确衡量；
• 共同需求已经稳定，而不是看起来相似。

两个仓库长得像，不等于它们应该成为一个运行时。

先用三个入口确认产品方向

删完旧产品表层后，我没有急着补回一大堆页面，而是先保留三个公开入口：

• 首页：AI Image Editor，用提示词修改现有图片；
• /image：AI Image Generator，从文字或参考图生成图片；
• /video：AI Video Generator，从文字或图片生成视频。

这三个入口确定了一件事：图片编辑与图片生成是主线，视频是相邻能力，不再代表整个产品。

它们的界面可以不同，但底层结果必须一致。例如：页面显示的参数、积分预估和服务端真正收到的请求，不能分别来自三套数据；上传和任务恢复也不应该因为入口不同就出现不同协议。

我把这套新产品叫作 PicVane。现在首页以图片编辑为中心，同时保留图片生成与视频工作流。这个链接放在这里，是因为到这一步，产品的名字才真正有了对应的边界，而不只是换了一个 Logo。

图片链路也要有自己的后端边界

原来的项目里，视频侧已经有比较清晰的 Runner 和 Provider Adapter。图片侧如果继续让页面组件直接理解 Provider、模型参数和任务状态，后面每增加一个模型或图片工具，都可能再复制一遍积分与任务逻辑。

所以这次重建里，还有一部分工作完全不体现在首页视觉上：我把图片生成收口到独立 Runner 和 Adapter，让公开模型 ID、输入类型、比例、分辨率、张数和积分规则同时驱动界面与服务端请求。

我也没有为了 “统一” 把图片逻辑塞进视频工作台。图片和视频有不同输入与能力，应该保留清晰的 Controller 和类型；真正共享的是任务生命周期、上传、积分、历史与结果展示。

对我来说，这种统一才有价值：减少重复后果，而不是减少文件数量。

品牌应该最后换，而不是最先换

等旧身份真正从路由、邮件、资源名、默认工作流和公开文案里退出后，我才开始处理新域名、数据库身份、存储前缀、邮箱、Logo、图标和 Metadata。

这个顺序让我意识到，一款产品的身份并不在一个 siteName 配置里。

它散落在：

• 用户第一眼看到的入口；
• 导航优先级；
• 页面默认值；
• 示例告诉用户 “可以拿它做什么”；
• 邮件和账户消息；
• 搜索结果里的标题与描述；
• 失败时系统如何回应。

如果先换 Logo，最后很可能得到一个 “看起来是新产品、处处还在替旧产品做决定” 的网站。

这次重构还没有证明市场成立

这次拆分让我更快做出了第二个产品，也让代码边界比之前清楚。

但我要明确区分两件事：工程完成，不等于市场验证。

目前能确认的是，我完成了新的图片优先结构、独立图片生成链路、主要页面的多语言发布、每日签到积分，以及一些更聚焦的图片工具。

不能据此声称的，是它已经带来流量、转化、留存或收入增长。

接下来真正要回答的是：

• 访客是否理解图片优先的定位？
• 大家最常从哪个入口开始？
• 生成在哪一步中断？
• 图片编辑、图片生成和视频之间，哪个会带来重复使用？
• 用户愿不愿意为其中某个结果付费？

架构整理只能让我更容易观察和调整，不能替我回答这些问题。

如果你也准备从旧项目做第二个产品

我现在会建议先回答五个问题，再开始加功能：

1. 新产品最主要的用户任务是什么？
2. 哪些代码承载的是稳定能力，哪些只是旧产品的表达？
3. 如果删掉旧页面，哪些 “共享模块” 会暴露反向依赖？
4. 现在真的需要多品牌框架，还是只需要两个清晰的产品？
5. 你准备如何分别验证工程正确、真实运行和市场需求？

第二个产品确实可以比第一个做得更快。

但速度不一定来自复制更多，也可能来自终于知道哪些东西不该复制。

我这次保留下来的，主要是第一个产品里积累的运行经验；重新做的，则是第二个产品应该如何被用户理解。

这两者分开以后，新产品才真正开始成立。

也想请教 W2Solo 的朋友：你们从旧项目做新产品时，会倾向继续抽象成一套框架，还是允许两个产品尽早分开？什么证据会让你改变选择？

---

说明：本文记录真实项目开发过程。AI 协助整理了文章结构与文字，我核对了产品事实和最终内容。