上线前先自己吃狗粮：vibe 项目的内部试用手册

很多 vibe 项目上线第一天就翻车，翻的不是没想到的 bug，而是创始人自己从来没真正用过的功能：注册流程在自己手机上没走通过、付费按钮点下去不知道跳到哪里、旧数据导入后列表是空的。这些问题不需要用户来发现，只需要团队在上线前两周每天用自己的产品干活，就能发现一大半。这就叫吃狗粮：不是请人来测，而是在产品正式见人之前，先让它成为你们自己每天离不开的工具。

先划清界限，避免和站内已有的指南撞车。封闭内测讲的是“请外人来测”：怎么招募、怎么分组、怎么收集反馈；上线前一小时手册讲的是“发布当天的执行清单”；用户反馈分流讲的是“反馈来了怎么处理”。本文讲的是它们之前的一步：产品还没有外人，团队自己当第一批用户，每天真实使用、真实记录、真实修好。本文不讲招募，也不讲反馈分流，只讲内部试用这一段怎么做才有效。

吃狗粮不是“自己点一点”

最常见的假狗粮是：上线前夜，创始人把每个页面点一遍，没报错，就宣布“测过了”。这不叫试用，这叫浏览。真正的试用有三个硬标准，缺一个都不算。

第一，用真实任务。不是“点一下创建按钮看看能不能创建”，而是“今天团队的真实工作就用它做”：做笔记的产品就用它记今天的会议纪要；记账产品就用它记团队这周的真实开销；待办产品就用它排这周的真实任务。假数据测不出真问题：假数据不会手滑删错、不会有超长标题、不会在弱网下提交两次。

第二，用真实环境。主力机、日常网络、真实账号、真实数据量。只在开发机、千兆宽带、管理员账号、十条测试数据下跑过的功能，上线第一天就会在用户手里现形。特别是要覆盖：低端机、弱网、非管理员账号、已有三个月历史数据的老账号。

第三，用足够久。一次性的浏览只能发现“打不开”的问题，发现不了“第三天就不想用了”的问题。内部试用至少持续两周，每天都用——只有连续使用，才会撞上那些“第一天没感觉、第七天忍无可忍”的摩擦：比如每天都要重复的三次点击、每周都要手动清理一次的垃圾数据、每月结算时才发现的金额误差。

谁来吃：四类人，各吃各的部分

一个人吃狗粮是不够的，因为一个人会不自觉地绕开自己知道的坑。至少凑齐四类人，每类人负责不同的发现。

第一类，创始人自己。吃主流程，而且要吃“难用的部分”：注册、付费、导入、导出、找回密码——这些创始人最不想亲自走、用户却最先遇到的流程。创始人吃狗粮的目标不是找 bug，而是回答一个问题：“如果这是别人做的产品，我愿意为它付钱吗？”

第二类，团队成员和协作者。哪怕团队只有两个人，也要让另一个人用“普通用户账号”走全流程，不要用管理员账号。管理员账号绕过了权限、绕过了付费墙、绕过了新手引导，等于没测。协作者的任务是找“创始人已经习惯、所以看不见”的问题。

第三类，亲友用户。选三到五个真实目标用户画像的亲友：比如产品是给学生记账的，就找两个真学生。给他们真实任务，但不要手把手教：看着他们卡住的地方，就是产品要修的地方。亲友试用的规则只有一条：不许替他们操作，卡住了就记下来，修产品而不是教用户。

第四类，未来的自己。给两周后的自己留一份“试用日记”：每天花五分钟写下今天用产品时最不爽的一件事。这份日记是上线前复盘的原材料，比任何测试报告都诚实——因为写日记的人没有“证明产品没问题”的动机。

四类人里有一个要特别小心：太熟的人会“帮忙找补”。亲友看到 bug 会说“没事，我重新点一下就好了”，团队成员会说“这个我们下个版本再修”。内部试用的纪律就是：所有“重新点一下就好了”的瞬间，都要记下来——用户上线后可不会这么宽容。

三周内部试用计划

下面是一份可直接套用的三周计划，假设上线目标定在第四周。时间可以压缩，但顺序不能乱：先让产品能每天用，再让它被挑剔地用，最后才冻结改动。

第一周：让产品“能活着”。目标是团队每天的工作真的搬进来。第一天：所有人装上内部版本（见下节的内部渠道），建真实账号，导入真实数据。第二到三天：每天下班前每人提交一条试用记录（格式见下节），哪怕只写“今天没发现问题，但导入花了十分钟”。第四到五天：修掉所有“导致无法继续用”的问题——打不开、丢数据、付不了款，其他问题先记下来不动。周末复盘：列出本周发现的问题清单，按“阻断使用 / 严重摩擦 / 小毛病”分三档。

第二周：让产品“被挑剔”。这周引入亲友用户，每人给一个真实任务包：比如“用它记三天开销、月底导出一次账单”。同时加两条压力测试：一次弱网测试（用地铁、电梯、地下车库的真实弱网，不是浏览器节流模拟）；一次“脏数据”测试（导入一份带超长标题、特殊字符、重复项的真实旧数据）。这周修的重点是严重摩擦：每天都要重复的操作、容易误触的按钮、看不懂的报错文案。修不完没关系，记下来排进上线后的第一批迭代，但阻断类问题必须清零。

第三周：冻结与验收。周一开始只修阻断类和严重摩擦类问题，不再加新功能——这是内部试用最容易破的纪律：试用中冒出来的“好主意”一律记进下一版本，不进上线版本。周三做一次“从零开始”验收：找一个没用过产品的人（可以是新亲友），从注册到完成一次核心任务全程不指导，计时并记录卡点。周五开上线评审会，对照毕业标准（见下节）逐项打勾，不过关就推迟上线——推迟一周，远好过带着已知阻断问题上线。

内部渠道与反馈格式：别让反馈死在群聊里

内部试用最常见的死法是：反馈散落在五个群聊、三个私聊和口头里，上线前谁也凑不齐。立两条规矩就能避免。

第一条，内部版本走固定渠道。移动端用 TestFlight 或内部测试轨道、网页端用一个带密码的预览域名、桌面端用固定下载链接，版本号每天递增。不要用“我刚部署的那个链接”这种口头渠道——反馈里写“最新版”三个字时，没人知道他指的是哪一版。每个内部版本贴一张变更便条：今天改了什么、已知有什么问题还没修，让试用者不用重复报已知问题。

第二条，反馈只用一种格式。不管在群里还是 issue 里，反馈都按这个模板写，缺一项就请对方补齐：

内部版 0.9.3（日期）
手机型号 / 浏览器 / 网络
我当时想做什么
发生了什么（截图或录屏）
我以为会发生什么
每次都出现 / 偶尔出现 / 只出现一次
导致我无法继续用 / 很烦但能绕过 / 只是不好看

模板里最关键的是“影响”这一项：它直接决定了修复优先级。没有影响分级的反馈清单，上线前夜必然陷入“先修哪个”的争吵。维护者每天花十分钟把新反馈归档到一张表里：编号、影响、状态、负责人——这张表就是上线评审会的议程。

还有一条容易被忽略的规矩：内部试用期间，试用者的数据要和生产数据隔离，但又要是“真实的”。做法是：内部版本连独立的数据库或独立的工作区，试用者可以在里面随便折腾、删了重来，但数据必须是他们自己的真实内容。拿假数据试用，等于没试用；拿生产数据试用，等于埋雷。

五个偏见陷阱：为什么团队自己测也会漏

内部试用最大的敌人不是 bug，而是团队的偏见。下面五个陷阱，每个都真实发生过，对照着自查。

陷阱一，绕坑本能。团队成员知道哪个按钮有问题，会下意识绕开它。解法是给亲友用户布置任务时不透露任何“正确路径”，并且要求团队成员试用时也用普通账号、按直觉操作，不许用“内部知识”走捷径。

陷阱二，假数据幻觉。用“测试用户、测试金额、测试标题”测出来的流程全是顺的。解法见上：第二周必须导入真实旧数据，标题要长、金额要杂、记录要多。

陷阱三，设备幻觉。全团队都用最新款手机和千兆宽带，就会漏掉低端机卡顿和弱网失败。解法是试用设备清单里强制包含一台三年前的旧手机和一次真实弱网场景，这两项不做完不算试用完成。

陷阱四，付费幻觉。内部测试常常跳过真实付费：用测试卡、用管理员账号、用“上线后再接支付”。结果上线第一天真实支付就翻车。解法是：上线前至少完整走通一次真实小额支付（哪怕只有一元），并且走通一次退款流程——退款流程没人走过，等于没有退款功能。

陷阱五，沉默幻觉。试用者觉得“这点小事不值得说”，于是小摩擦一个都没报，上线后用户却因为同一个小摩擦流失。解法是每天下班前强制一条记录，哪怕写“今天没问题”；并且明确告诉试用者：报小问题不是挑刺，是帮产品省下上线后的流失。

毕业标准：什么时候可以结束内部试用

内部试用不能凭感觉结束，要凭标准。下面六条全部满足，才算毕业，可以进入封闭内测或公开发布；任何一条不满足，就推迟一周再测。

• 阻断类问题清零：没有“导致无法继续用”的已知问题。
• 主流程全覆盖：注册、核心任务、付费、导入、导出、找回密码，六条流程都有人用真实账号完整走通过，且有记录。
• 真实支付走通过：至少一次真实小额支付和一次退款流程完整完成。
• 弱网与旧设备覆盖：至少一次真实弱网场景、至少一台三年前的旧设备完成主流程。
• 连续使用满两周：核心试用者每天都在用，不是上线前夜集中点的。
• 从零验收通过：一个没用过产品的人，在不指导的情况下完成一次核心任务。

毕业标准里没有“没有 bug”这一条——那是不可能的。标准要的是“没有会拦住用户的 bug”，以及“团队已经连续两周真实地活在这个产品里”。达到这个状态再上线，上线第一天的问题会少一个数量级；达不到就硬上，等于把内部试用外包给了第一批用户，而第一批用户是没有义务替你试用的。

走一遍：一个虚构例子的内部试用

假设产品是一个给自由职业者记账的小工具：记一笔收入或支出、按月汇总、月底导出账单。创始人定在四周后上线，内部试用按三周计划走。第一周，团队把真实开销搬进来，第二天就发现：导入旧账单时，带中文括号的分类名会乱码——这是假数据永远测不出来的问题，因为测试数据里没有中文括号。第三天，创始人用自己的主力机（三年前的旧安卓）记账，发现列表滚动卡顿——开发机上完全不卡。

第二周引入三位亲友：两位自由职业者、一位学生。布置的任务是“记三天真实开销，周末导出一次账单”。其中一位在地铁上弱网提交，账单重复记了两次——团队这才补上“提交中禁用按钮 + 幂等处理”。另一位导出账单后发现金额合计差一分钱——小数四舍五入的 bug，只在真实数据量下才冒头。第三周冻结期，有人提议“上线前加个图表功能”，被记进下一版本，没有进上线版本。周三从零验收：一位没用过的朋友在不指导的情况下，六分钟完成注册、记三笔账、导出账单，只卡在一个地方：导出按钮藏得太深。按钮位置当天调整，周五评审六条标准全部打勾，准时上线。

这个例子的要点不在 bug 本身，而在发现它们的手段：真实数据、旧设备、弱网、亲友的不指导操作、冻结期的纪律。每一项都是低成本、可复制的，没有一项需要请专业测试团队。内部试用不是“更认真的测试”，而是“更真实的使用”——把这两件事分清楚，狗粮才算吃对了。

试用日记怎么写：每天五分钟的模板

试用日记不需要文采，只需要固定格式，否则坚持三天就断了。每天下班前写三行：今天用产品做了哪件真实任务；过程中最不爽的一件事是什么；如果只能修一件事，你希望修哪件。第三行最重要：它逼试用者排序，而不是罗列。维护者每周把所有人的第三行收集起来，出现两次以上的问题自动升为严重摩擦，优先修。日记写在共享文档或固定 issue 里，不要写在私聊里——私聊里的日记等于没写，上线评审时谁也翻不出来。

上线前最后一夜：只做三件事

内部试用毕业后、上线前夜，只做三件事，多一件都是风险。第一，确认内部试用表里阻断类和严重摩擦类问题全部关闭，有记录可查。第二，确认生产环境用全新账号从零走一遍主流程——内部版本测得再好，也不能代替生产环境的一次真实行走。第三，把试用期间记下的“下一版本清单”原样保留，不要在上线前夜顺手塞进发布里。上线前夜加的功能，是上线第一天 bug 的主要来源。

吃狗粮的本质，是把“用户第一次使用的尴尬”提前到自己身上发生。尴尬发生在自己身上，修起来不丢人；发生在第一批用户身上，丢的是用户。花三周时间每天用自己的产品，换上线第一天少一堆公开翻车——这是 vibe 项目最便宜的质量投资。