第 15 天的早上最重要：vibe 项目的试用期结束与降级实战指南

先说清楚：以下示例人物、产品名和数据全部为虚构，是为讲清楚方法而编的例子，不是真实产品、不是真实用户案例。方法本身是通用的，数字是举例用的标尺，不是任何产品的实测结果。

试用期结束那一天，是很多 vibe 项目最容易丢人的时刻。不是因为产品不好，而是因为作者只想好了“怎么让人开始试用”，没想好“试用完了怎么办”。用户早上打开产品，发现昨天还能用的功能突然灰了，数据不知道还在不在，点升级又不知道会不会把旧数据弄丢——这种体验比一开始就不给试用更伤信任。我的判断是：试用期的设计重点根本不在前 14 天，而在第 15 天的早上。把那一天处理得体面，用户才愿意回来付钱；处理得粗暴，用户连导出数据的机会都不给你，就直接走了。

先定三件事，再写一行代码

动手之前，先在纸上定下三件事。第一，试用什么：是按时间算的 14 天，还是按用量算的 100 条记录？时间试用适合协作、报表这类“得用几天才有感觉”的产品；用量试用适合“一次就能判断好坏”的工具。千万别两者混着来——“14 天或 100 条，先到先停”听起来精明，用户算不清楚，客服也解释不清。第二，要不要先绑卡。先绑卡转化率高，但争议和退款也多；不绑卡转化率低一点，口碑却干净得多。一个人做的项目，我建议先不绑卡：你没有客服团队去处理“我忘了取消”的投诉，每一单争议都是你自己的时间。第三，降级后留什么。这是全文最关键的一条，必须在试用开始前就定好、写进产品里，而不是到期那天临时拍脑袋。

拿虚构的例子说：顾晓做的“雾岛清单”是一款团队任务工具，试用 14 天，不绑卡。试用开始时，产品里就有一句话写在显眼处：“试用结束后，你的任务和文件仍可查看和导出 30 天，只是不能新建高级项目。”这句话的价值不在文案，而在承诺：它把降级从“惩罚”变成了“早就说好的规则”。用户在试用期间敢往里放真实数据，因为他知道最坏的结果不是数据人质，而是降级。相反，那些试用页只写“免费试用 14 天”、到期规则藏在帮助文档第三层的产品，用户一律默认“到期就全锁”，于是只敢拿假数据随便点点，试用转化自然上不去。

到期时间轴：五次触达，一次都不能省

到期不是一个瞬间，而是一段需要打招呼的过程。我推荐的时间轴是这样的。试用开始当天，告诉用户到期日和降级后保留什么；第 7 天，告诉用户还剩几天、已经用了哪些高级功能；到期前 3 天，再提醒一次，并给出“一键导出”入口；到期前 1 天，最后提醒一次，重点不是催付费，而是告诉用户“明天之后你的数据还在，只是会变成只读”；到期当天，页面顶部出现一条平静的横幅，而不是弹窗挡住整个界面。每次提醒只讲一件事：还剩几天、到期后会怎样、现在能做什么。不要在同一封提醒里同时塞升级优惠、功能清单和客服联系方式，用户读不完，等于没提醒。

这里有两个细节最容易被 vibe 制作者忽略。一是时区和“当天”的定义：到期日到底是注册后第 14 天的 23:59，还是按用户本地时区算？必须在服务端用统一时间戳算，页面上显示用户本地时间，并且提前一天提醒时写明“北京时间 11 月 16 日 23:59 前”，不要只写“明天到期”。二是幂等：到期任务跑两次，不能把用户的数据状态改两次，更不能发两封“已到期”邮件。定时任务先查状态再改状态，改完再发通知，顺序反了就会出现“还没到期就收到到期邮件”的灵异事件。

降级矩阵：先画表，再写权限判断

降级最怕的是“想起一个锁一个”，最后锁得前后矛盾。动手前先画一张降级矩阵，行是功能，列是试用、免费、付费三档，每个格子只填三种状态之一：可用、只读、不可用。举个例子：查看任务是三档都可用；新建高级项目是试用和付费可用、免费不可用；导出数据是三档都可用——对，导出永远不要锁，这是底线；邀请新成员是付费可用、免费不可用；自动化规则是试用和付费可用、免费只读（能看不能改）。这张表一旦定下来，服务端所有权限判断都查这张表，不要在各个页面里各写一套 if 判断，否则迟早出现“列表页能点、详情页报错”这种半锁状态。

还要单独处理三类边缘情况。第一是协作数据：用户 A 降级了，但他参与的团队项目是别人付费的，怎么办？原则是“按资源归属算权限，不按个人身份一刀切”：团队项目跟着团队的订阅走，个人项目才跟着个人走。第二是公开链接和分享：已经发出去的分享链接，到期后是继续可读、还是立刻失效？我的建议是继续可读、停止可写，突然断链会伤到链接另一端的人，那是你得罪不起的第二批用户。第三是超额数据：试用期间建了 50 个项目，免费档只允许 5 个，降级后多出来的 45 个怎么办？不要自动删，也不要随机锁。做法是：全部保留为只读，让用户自己选哪 5 个恢复可编辑——把选择权还给用户，争议立刻少一半。

文案：把“锁”说成“留”，把“付费”说成“恢复”

降级页的文案，决定了用户是觉得“被赶走”还是“被留住”。反面例子：“您的试用已结束，请立即升级，否则功能将受限。”这句话全是威胁，没有信息。正面的写法是：“试用已结束。你的 128 条任务和 36 个文件都在，30 天内随时可以查看和导出。升级后，高级项目和自动化会立刻恢复，不用重新设置。”你看，后一句没有一句废话：数据在、期限清、出口有、恢复零成本。升级按钮的文案也别写“立即购买”，写“恢复高级功能”更贴切——用户买的不是一个新东西，而是把自己已经用顺手的东西拿回来。

同样，千万不要在降级当天玩“限时优惠倒计时”那一套。一个人的项目玩饥饿营销，只会让用户觉得你急了。真想给优惠，就给一个不带倒计时的“回来价”，比如降级后 30 天内升级享首月优惠，写清楚起止日期，到期自动恢复原价，不用弹窗催。信任比一单转化值钱，尤其对还在攒口碑的 vibe 项目。

到期和欠费是两件事，别用同一套流程

很多人把“试用到期”和“付费失败”混成一套流程，这是大错。试用到期是预期内的事，用户没做错任何事，流程应该平静、有出口、有期限；付费失败是意外，用户可能只是卡过期了，流程应该是提醒、重试、宽限，而不是立刻降级。付费失败后，先给 3 到 7 天宽限期，期间功能不变，只提醒更新支付方式；宽限期过了再降级，降级规则和试用降级用同一张矩阵，但文案要区分：“支付失败”不是“试用结束”，别让用户收到一封文不对题的邮件。把这两条流程画成两张图贴在墙上，写代码时就不会顺手复用错分支。

再升级：恢复必须是“一键”，不能是“重做”

降级做得再好，如果升级后还要用户重新配置一遍，前面全白费。升级那一刻，系统应该做三件事：按矩阵把权限改回去；把降级期间用户选定的“保留项目”自动恢复为可编辑；把降级期间只读的数据原样解锁，不丢一条、不改顺序。测试的时候，专门走一遍“试用—降级—只读 10 天—升级”全流程，检查自动化规则、成员权限、分享链接是不是都回来了。还有一个容易漏的点：降级期间用户导出了数据、升级后又导入了一份，会不会出现重复？导入时按唯一标识去重，或者明确提示“检测到重复，将跳过”，不要静默复制两份。

个人试用和团队试用，降级规则不能共用一套

个人试用和团队试用看起来只差在人数，降级时的麻烦程度却完全不同。个人试用降级，影响的只有一个人，规则可以简单：只读加导出加自选恢复就够了。团队试用降级，影响的是一群人，外加他们之间的权限关系：如果管理员降级了，普通成员还能不能看？如果某个成员先升级了个人版，团队数据归谁？我的建议是：团队试用的降级规则单独写一张表，核心只有一条——“数据跟着空间走，不跟着人走”。团队空间降级，空间里所有成员一起变成只读；任何一个成员单独升级，都只恢复他自己的个人空间，不自动恢复团队空间；团队空间要恢复，必须由管理员升级团队版。这样规则虽然听起来绕，但执行起来没有歧义，客服也不用逐单解释“为什么他能看我不能看”。

还有一个团队场景容易漏：试用期间邀请进来的外部协作者。降级后，这些协作者是继续可读、还是直接失去访问权？直接踢人是最伤人的做法，等于替用户得罪了他的合作方。稳妥的做法是：协作者保留只读访问 30 天，和数据保留期对齐，到期前给管理员发一次提醒，让管理员决定是升级、导出还是正式移除。把“踢人”这个动作从系统自动行为变成管理员主动选择，争议就从“你们产品乱踢人”变成了“我们团队自己没处理”，性质完全不同。一个人做的项目尤其要记住：你没有客服团队去灭火，所以凡是会影响到第三方的动作，一律不要自动执行，要留给用户决定。

保留期过了之后：删除也要讲体面

30 天保留期结束，数据怎么办？很多作者到这里就含糊了，产品里既不删也不说，用户只能猜。正确的做法是提前说清楚、到期按约执行。保留期结束前 3 天，再发一次提醒，标题不要写“最后通牒”，写“你的数据保留期将于 3 天后结束，现在仍可导出”。保留期结束当天，系统先把数据标记为“待删除”，再给 7 天冷静期——这 7 天里用户升级仍可恢复，客服申诉仍可找回；冷静期过后，再真正删除，并且删除动作要可审计：删了什么、何时删的、谁触发的，留一条日志。不要为了省存储空间，在保留期没过就悄悄删；也不要为了“万一用户回来”而永久留着不删，那既是存储成本，也是隐私负债。

删除范围也要讲清楚：删的是用户在免费档下的数据，还是连同账号一起删？我的建议是分开处理：降级后不升级，删的是超出免费档的数据和试用期产生的临时数据，账号本身和基础数据保留，用户随时能用免费版回来；只有用户主动点“注销账号”，才走账号注销流程——那是另一篇指南的主题，不要在这里顺手合并。把“降级”“保留期结束”“注销”写成三段独立的说明，贴在降级页底部，用户读起来不费劲，你执行起来也不容易串流程。体面不是一句口号，它体现在每一次“系统要动用户东西”之前，有没有提前说、有没有留出口、有没有办法挽回。

降级当天的客服话术：三句话，不要辩论

降级当天一定会有人来问，而且问法都差不多：“我的数据是不是没了？”“为什么昨天能用今天不能用？”“我现在升级能不能马上恢复？”一个人做的项目，没有时间跟每个用户长篇解释，所以要提前准备三句话，复制粘贴就能用。第一句讲数据：“您的数据都在，试用结束后 30 天内可以查看和导出，升级后立刻恢复。”第二句讲原因：“试用期是 14 天，到期后高级功能会变为只读，这是试用开始时就说明过的规则。”第三句讲出路：“现在升级不需要重新设置，之前的项目、成员和自动化都会原样回来；如果暂时不想升级，也可以先把数据导出来。”三句话覆盖了用户最关心的三件事：数据、原因、出路。不要在回复里辩论“你当初应该看清楚规则”，也不要为了留人而临时承诺“这次帮你延长一周”——临时延长一旦开了口，下一个用户也会要，而你根本没有规则去兜底。

如果用户说“我根本没收到提醒”，先别急着反驳。查两件事：提醒是不是真的发出去了、发到了哪个邮箱。很多“没收到”其实是提醒进了垃圾箱，或者注册邮箱根本不是常用邮箱。查完之后再回复，话术同样是三句：“我们查到提醒已于某月某日发到某邮箱，可能进了垃圾箱，抱歉给您带来不便；您的数据仍在保留期内，可以先导出；需要的话，我可以帮您确认导出是否成功。”把事实、歉意、出路放在同一条回复里，用户即使还是不升级，也大概率不会带着怨气走。降级日的客服质量，就是产品口碑的最后一道防线，别把它交给临时发挥。

上线前检查表

最后给一份可以直接照着测的清单。到期日按服务端时间戳算、页面显示本地时间；到期提醒至少发三次，内容只讲期限、后果和出口；降级矩阵覆盖全部功能，没有页面级散落判断；导出在任何档位都不锁；超额数据只读不删、由用户自选恢复；分享链接降级后可读不可写；协作项目按资源归属算权限；付费失败有独立宽限流程；升级后一键恢复、配置不丢；到期任务幂等，重跑不重复发通知；降级页文案不含威胁、不含倒计时恐吓。十条全过，试用期才算真正做完。记住一句话：试用期的终点不是“用户付不付钱”，而是“用户走的时候，愿不愿意再回来”。把第 15 天早上做好，前面 14 天的努力才不会白费。