多产品经营：复制成功经验与长期资产管理

ClearCopy的流程跑顺后，你可能想再做一个“发布邮件检查器”。今天先不创建第二套产品，而是完成一份复制方案：哪些东西能带过去，哪些必须分开，以及你每周有没有时间维护它。

第二产品暂叫LaunchMail，仅是教学想法。它把发布邮件草稿与事实比较，沿用英文检查思路，但还没有真实客户和收入。你会得到一张完成的产品表与一次跨产品读取演练，不会在本课自动注册新域名或支付商品。

把“复制成功”拆成具体资产

先复制这张已填表，别只写“复用技术栈”：

资产	ClearCopy现有用途	LaunchMail可复用什么	必须另做什么
输入表单组件	功能事实+App描述	标签、校验、状态展示组件	邮件任务字段与示例
检查任务执行	生成并保存App文案报告	排队、重试、耗时与错误结构	邮件输出标准和质量样例
9美元10次包	App描述报告次数	收款与发放的通用处理模块	独立套餐代码、承诺与订单关联
支持文档	如何检查上架描述	帮助页布局	邮件场景的实际问题与答案
客户报告	用户私有App文案	不复制客户内容	第二产品自己的报告与授权

这里真正容易带走的是已经稳定的流程，不是把原产品的客户列表和报告直接拷一份。新任务的结果标准仍要重新做，不能把App描述里的“unsupported sync”换几个词就当成邮件检查完成。

可以共用同一套身份系统，但数据至少带产品归属，并且每次读取核对当前用户与产品。用下面两行合成报告做纸面演练：

[
  {"id":"demo-report-c1","product":"clearcopy","user":"demo-a"},
  {"id":"demo-report-m1","product":"launchmail","user":"demo-b"}
]

当demo-a从ClearCopy请求第一份，允许；请求第二份，拒绝。即使碰巧相同用户在两个产品都有账户，路由也应要求当前产品归属相符，再按你的明确产品规则决定是否支持跨产品查看，不靠传一个reportId就全部查出。

完成表已经给好：

在真正有第二个测试环境时，将这些变成读取检查，不用真实客户资料做演练。缓存键和存储路径也保留产品归属，不能只靠前端标签区分。

Stripe产品与价格说明区分具体销售选项与对应价格。假设两种产品卖的是不同报告，就让clearcopy-10-v1和launchmail-10-v1各自映射到适用商品与价格，不让一笔订单只写pro然后随页面猜发到哪里。

同一支付回调模块可以复用“验证→找订单→核对→唯一发放”的代码。订单里保存product、offerCode、userId、amount、currency、credits快照。一个产品退款，只处理那笔订单对应的权益；不能把用户另一个产品的剩余次数一起清零。

如果将来确实卖两产品通用包，应把它做成明确新套餐，用户付款前看得见适用范围。不要为了省一条配置，先把所有次数默默共享，再用文案补解释。

Google SRE减少重复劳动指出手工重复工作会随规模增长。本次用一张教学周计划检查自己能否开始：

每周工作	ClearCopy	LaunchMail初期	两者合计
支持与问题回复	2小时	2小时	4小时
故障与例行检查	1小时	1小时	2小时
内容与示例维护	1小时	2小时	3小时
合计	4小时	5小时	9小时

如果你每周只有8小时，单是维护假设已超过1小时，还没有新功能开发。先复用通知任务和帮助页，或缩小第二产品试验，而不是把两个产品都承诺全天人工支持。

费用也分两层：专属域名、模型、邮件和存储按产品记录；共享API与数据库费用按你选定的可解释方式分摊，并在表里说明。这是内部经营表，不把一个产品支撑另一个的费用藏起来，让每个都看似盈利。

GitHub仓库角色可以帮助你把只维护邮件模板的人与管理支付模块的人分开。配图中的权限矩阵用来观察具体能力，不能因为两个产品共用组织就给所有协作者相同管理员权限。

写下这样的归属记录：

ClearCopy负责人：自己；支持入口：实际可回复的地址
LaunchMail状态：想法验证；暂不收款
共享组件：输入状态、任务重试、邮件发送
独立资产：报告样例、订单产品归属、帮助内容
若暂停试验：关闭新任务入口；保留已售承诺与用户访问安排

Google SRE服务目标章节帮助将维护承诺具体化。对已售产品保留可以完成的服务目标，新试验不要借用原产品名声承诺未经运行的稳定性。

保存产品表、四行读取结果和9小时维护预算。如果现在不启动LaunchMail，你也已经完成了一项经营判断：确定可复用的资产，识别新增工作，并且没有牺牲ClearCopy现有用户来换取“产品数量加一”。