让人随便点、又绝不搞坏：vibe 项目的演示模式实战

以下示例产品与人物均为虚构，仅用于说明做法。假设你做了一个叫“桔子工坊”的小应用：帮手作陶艺工作室管理课程预约、卖材料包、收学员作品照片。产品上线三个月后，创始人阿桔遇到一个尴尬：每次给潜在客户或投资人演示，都要先花半小时造数据——注册一个假账号、编几节课、上传几张作品图，演示完还得小心别把假数据留在真实数据库里。有一次她忘了清理，演示用的“测试学员张三”出现在了真实的结课名单里，客服还给“张三”发了结课短信。这篇指南要解决的就是这个问题：给你的 vibe 项目做一个像样的演示模式，让任何人一键进入一个看起来真实、用起来完整、但绝对不会污染真实数据的沙箱。

先把概念划清楚。演示模式不是测试数据，也不是演示脚本。测试数据是你开发时用的种子内容，服务于你自己；演示脚本是你给人讲产品时准备的台词和操作顺序，服务于某一次讲解；演示模式是产品里的一个正式功能，服务于每一个第一次打开产品的人——潜在客户、投资人、应用商店审核员、甚至你自己的新员工。它有三个硬标准：第一，看起来真实，数据要像真的业务跑出来的样子；第二，用起来完整，核心流程能从头走到尾，而不是点两下就弹“演示版不支持”；第三，绝对隔离，演示里做的任何事都不能写进真实数据库、发不出真实通知、花不掉真实的钱。

演示模式有五种常见形态，你不需要全做，选一种与你的产品阶段匹配的就行。第一种是公开演示站：单独部署一个只读或可重置的站点，网址可以大方贴在官网和社交媒体上，任何人不用注册就能看。它的好处是传播成本最低，坏处是你要多维护一套部署，而且必须保证演示站的数据不会被恶意用户灌满垃圾。第二种是一键试用账号：登录页上放一个“不用注册，先试试看”按钮，点一下就以演示身份进入，数据是预置好的，退出即焚或者定时清理。第三种是沙箱租户：在正式产品里，每个演示用户拥有一个独立的租户空间，数据结构和正式租户一模一样，只是打上了演示标记、定期回收。第四种是录播引导：把一次精心准备的操作录成可交互的引导流程，用户点下一步、页面跟着动，但背后没有真实业务逻辑，适合只想展示界面的早期产品。第五种是只读镜像：把真实产品的脱敏快照定时同步到演示环境，用户能看、能点、不能改，适合数据本身就是卖点的产品，比如数据看板类应用。

对绝大多数一人项目，我推荐从第二种起步：一键试用账号。它的实现成本最低——一个演示身份、一条预置数据、一个退出清理逻辑——却能覆盖最常见的演示场景：发给朋友看、贴到 Product Hunt、给投资人发链接。而且它有一个公开演示站没有的好处：演示用户走的是正式产品的同一套代码路径，你改了功能，演示立刻跟着变，不用维护两套界面。等你开始接到批量演示需求、或者演示流量大到影响正式服务时，再升级到沙箱租户或独立演示站。

演示数据要像真的，但不能是真的

演示模式成败的第一关是数据。太假的数据会立刻穿帮：三个学员、两节课、全部是“测试”开头的名字，观众一眼就知道这是个空壳；太真的数据又会惹麻烦：用真实客户的名字和照片做演示，等于把别人的信息拿出来展览。合格的演示数据要满足四条：数量上像真的，一个陶艺工作室就该有几十个学员、十几节课、横跨几个月的预约记录；关系上像真的，学员要报过课、课要有老师、有时间、有价格、有上下限人数；时间上像真的，今天往前有已完成的课、今天有进行中的课、往后有可预约的课，时间线不能断在某一天；细节上像真的，作品照片要是真实的陶艺照片风格，评语要像人话，不能全是“很好”“不错”这种 AI 味的套话。

具体怎么做？先给你的演示数据定一个“种子版本”。把演示数据写成一份带版本号的种子文件，比如 demo-seed-v1，里面包含完整的业务对象和它们之间的关系。版本号的作用是：以后产品改了数据结构，你就升一个版本，而不是偷偷改几行数据让演示悄悄变味。种子数据里的人名、地名、作品名，全部用虚构但合理的名字：学员叫“林小满”“陈默”这种像真名的名字，而不是“测试用户 1 号”；课程叫“周六上午拉坯入门”，而不是“测试课程 A”。照片可以用你自己拍的产品实物图，或者明确标注可商用的图库照片，千万别从网上随手抓客户的真实作品图。

还有一类数据最容易被忽略：脏数据。真实业务从来不是干干净净的：有取消过的预约、有请过假的学员、有缺货的材料包、有写错又改过的价格。演示数据里故意留一两处这样的“毛边”，反而更可信——观众看到一条“已取消”的预约记录，会觉得这个系统真的在处理真实业务。但毛边要适度，一两处是真实感，满屏都是就是产品有 bug 的错觉。我的经验是：演示数据里 90% 是顺畅的 happy path，10% 是已妥善处理过的异常状态，并且每处异常旁边都能看到处理结果，而不是悬在半空的报错。

时间感是另一个关键。演示数据如果全是今天的数据，观众会觉得这个产品昨天才上线；如果全是去年的数据，又会觉得产品已经没人维护。正确的做法是让演示数据的时间轴“以今天为锚点”动态生成：种子文件里存的是相对时间（比如“开课前 3 天”“结课后 2 天”），每次进入演示模式时按当天日期算出绝对时间。这样无论观众哪天打开，看到的都是“昨天刚结了一节课、明天还有三节课可约”的鲜活状态。实现上不难：种子生成函数里用今天减几天、加几天，别把 2026 年某月某日写死在数据里。

写隔离是演示模式的生死线

演示模式最危险的地方，永远不是“看起来假”，而是“写进了真地方”。阿桔那次事故的根源，就是演示和正式共用一个数据库、只靠“记得清理”来兜底。正确的做法是把隔离做进架构里，而不是做进口头约定。最干净的方案是租户级隔离：演示用户的数据行全部带上一个演示租户标识，所有查询默认只查本租户，演示租户的数据可以整租户删除。退一步的方案是数据库级隔离：演示走单独的数据库或单独的 schema，连接串在入口处就分流。最不推荐、但很多一人项目实际在用的方案是标记位隔离：每张业务表加一个 is_demo 字段，所有查询都带上条件——这条路能走，但你必须保证每个查询都不漏条件，漏一个就是一次事故。

除了数据库，还有四条外发通道必须堵死。第一是通知：演示里触发的短信、邮件、公众号消息，必须全部拦截，改成写演示日志或者只显示在页面上，绝对不能真的发出去。实现上可以在通知服务入口处加一道判断：演示租户的通知请求直接记日志返回成功，不要走到真实的短信网关。第二是支付：演示里走到付款步骤时，要么用支付平台的沙箱环境，要么直接显示模拟的支付成功页，绝不能接真实的收款通道。第三是第三方同步：演示数据不能同步到你的 CRM、数据分析平台或广告归因系统，否则假数据会污染真实的经营报表。第四是文件存储：演示用户上传的图片要进单独的演示目录，并且定期清理，避免有人用你的演示模式当免费图床。

页面上也要让演示身份一目了然。演示模式下，页面顶部应当有一条常驻的横幅，写清楚“你正在查看演示数据，这里的操作不会影响真实业务”，并附一个显眼的“退出演示”按钮。这条横幅不是装饰，它同时保护三方：观众不会误以为自己在操作真实业务，演示者不会被误认为是真实用户，而你也不会在事后被质问“为什么演示里能看到我的数据”。另外，演示账号的头像和名字要一眼可辨，比如统一用“演示访客”加一个明显的演示角标，不要伪装成真实用户。

一键重置：演示模式的自我修复能力

演示模式上线后很快会遇到一个新问题：观众会在里面乱点。有人把课程价格改成 0 元，有人把所有学员删掉，有人上传一张奇怪的图片——下一个观众进来，看到的就是一个被玩坏的产品。所以演示模式必须有自我修复能力，核心就是一键重置。重置按钮应当放在演示横幅旁边，点一下就把当前演示租户的数据恢复到种子版本的状态。重置的粒度可以分两档：软重置只恢复业务数据（课程、预约、订单），保留观众的浏览痕迹；硬重置连同演示账号本身一起重建，回到最初的种子状态。

除了手动重置，还要配自动回收。两个策略可以叠加用：闲置回收——演示租户超过 24 小时没有活动就自动重置；定时回收——每天凌晨把所有演示租户统一重置回种子版本。定时回收的好处是，你每天早上都知道演示环境是干净的，不用在重要演示前临时检查。实现时注意，重置操作本身要幂等：同一个重置请求重复执行两次，结果应当和执行一次一样，避免并发重置把数据搞成半截状态。还有，重置前不要弹“确定要重置吗”这种二次确认——演示数据本来就是一次性的，确认框只会打断演示节奏；但重置按钮绝对不能出现在正式模式里，演示与正式的入口必须分开。

种子数据的版本化在这里再次发挥作用。当你给产品加了新功能，演示数据也要跟着升级：新功能没有对应的演示数据，观众点进去就是空页面。我的做法是把“演示数据升级”写进发版检查清单：每次发版前，问自己一句“新功能在演示模式里看得到吗”。如果答案是否定的，要么补种子数据，要么在演示模式里把新功能入口暂时隐藏——空页面比缺功能更伤演示效果，因为它看起来像 bug。

退出路径：演示的终点应该是注册，而不是关闭

演示模式很容易犯的一个错误，是只管进、不管出。观众试完了，关掉页面就走了，你连他是谁都不知道。好的演示模式要把退出设计成转化漏斗的一部分。第一步是显眼的转化入口：在演示横幅和关键流程的终点（比如完成一次模拟预约后），放一个“用真实账号再来一次”按钮，点一下进入注册流程。第二步是数据带走：如果观众在演示里搭了点东西（比如排了一张课程表），注册后要允许他把演示里的配置一键导入正式账号——注意是“配置”而不是“演示数据”本身，演示的假学员、假订单不能跟着过去。

第三步是收集反馈，但要轻。演示结束时可以弹一个最多三个问题的反馈框：哪个功能最吸引你、哪个地方让你困惑、愿不愿意留下联系方式。问题超过三个，完成率会断崖式下跌；联系方式必须是选填，强制留邮箱会把本来有兴趣的人吓跑。反馈数据要单独存，不要和正式用户的反馈混在一起，否则你分析用户反馈时会被演示观众的意见带偏。

最后是一份上线检查表，发布演示模式前逐项打勾。数据：种子数据有版本号、时间轴以今天为锚点、有少量已处理的异常状态、无真实客户信息。隔离：演示租户与正式租户在数据库层面或租户标识层面分开、通知支付同步存储四条外发通道全部拦截、页面有常驻演示横幅与退出按钮。重置：手动一键重置可用、闲置与定时自动回收已配置、重置操作幂等。转化：注册入口可见、演示配置可导入正式账号、反馈框不超过三个问题。监控：演示模式的访问量、重置次数、转化率有单独的统计口径，不与正式数据混算。十项里缺任何一项，演示模式都不要急着公开链接——演示模式出事故的代价，比没有演示模式大得多。

还有一个上线后才会被想起的问题：演示模式也会被滥用。公开的演示链接一旦被爬虫或羊毛党发现，有人会批量注册演示账号灌垃圾数据，有人会拿演示站的上传入口当免费图床，还有人会用演示表单批量发测试请求。防滥用不需要做得很重，但三道底线要有：演示账号的创建要限速，同一 IP 短时间内只能建少量演示租户；演示数据的总量要设上限，单个租户的课程、订单、图片数量超过阈值就拒绝写入并提示重置；演示环境的写接口要和正式环境分开限流，演示流量暴涨时先掐演示、保正式。这三道底线配上前面的定时回收，演示模式才能长期公开挂着而不被玩坏。

反模式收尾，写给赶时间的你。不要用真实客户数据做演示，哪怕“只给投资人看一下”也不行；不要把演示账号的密码写成 123456 就公开链接，演示模式同样会被扫描器找到并灌垃圾数据；不要在演示模式里留一个能发真实通知的口子，“演示里一般不会触发”是最常见的事故前兆；不要为了省事把演示和正式做成同一套数据加一个“演示中”的标记位，除非你能保证每条查询都不漏条件。演示模式的本质是一句承诺：观众可以放心乱点，因为这里的一切都不会成真。守住这句承诺，演示模式就是你最便宜的获客渠道；守不住，它就是你最贵的事故来源。