奇思妙想 复制了一套能跑的 SaaS 后，我先删掉了大半个网站
复制仓库、改产品名、换 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，最后很可能得到一个 “看起来是新产品、处处还在替旧产品做决定” 的网站。
这次重构还没有证明市场成立
这次拆分让我更快做出了第二个产品，也让代码边界比之前清楚。
但我要明确区分两件事：工程完成，不等于市场验证。
目前能确认的是，我完成了新的图片优先结构、独立图片生成链路、主要页面的多语言发布、每日签到积分，以及一些更聚焦的图片工具。
不能据此声称的，是它已经带来流量、转化、留存或收入增长。
接下来真正要回答的是：
- 访客是否理解图片优先的定位？
- 大家最常从哪个入口开始？
- 生成在哪一步中断？
- 图片编辑、图片生成和视频之间，哪个会带来重复使用？
- 用户愿不愿意为其中某个结果付费？
架构整理只能让我更容易观察和调整，不能替我回答这些问题。
如果你也准备从旧项目做第二个产品
我现在会建议先回答五个问题，再开始加功能：
- 新产品最主要的用户任务是什么？
- 哪些代码承载的是稳定能力，哪些只是旧产品的表达？
- 如果删掉旧页面，哪些 “共享模块” 会暴露反向依赖？
- 现在真的需要多品牌框架，还是只需要两个清晰的产品？
- 你准备如何分别验证工程正确、真实运行和市场需求？
第二个产品确实可以比第一个做得更快。
但速度不一定来自复制更多，也可能来自终于知道哪些东西不该复制。
我这次保留下来的，主要是第一个产品里积累的运行经验；重新做的，则是第二个产品应该如何被用户理解。
这两者分开以后，新产品才真正开始成立。
也想请教 W2Solo 的朋友：你们从旧项目做新产品时，会倾向继续抽象成一套框架，还是允许两个产品尽早分开？什么证据会让你改变选择？
说明：本文记录真实项目开发过程。AI 协助整理了文章结构与文字，我核对了产品事实和最终内容。