第 31–50 天：主路径 MVP 的范围

用户不关心你有多少功能，只关心自己那件事有没有从头到尾走通一次。

一、MVP 不是「功能少的版本」

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

一位开发者用两个月做了 14 个功能：标签、搜索、模板、主题、快捷键、导入导出、团队邀请。上线当天，他请五位朋友试用，四个人停在注册页——验证邮件进了垃圾箱，第五个人注册成功，却不知道下一步该点哪里。

他的问题不是做得太多，而是把功能当成了路径。功能是并列的，路径是串联的；用户卡在任意一环，后面的功能一个也用不上。功能少的版本如果仍然断在第二步，它只是更便宜的失败。

这一篇只做一件事：把第 21–30 天手工跑通的那次交付，收窄成一条可以上线的软件主路径，并把「这轮不做」写成一份可以拿出来对照的清单。

二、主路径的三段定义

把主路径写成三段，每段只回答一个问题。三段之间用同一组名词，避免「上传」「导入」「添加」混着用，让用户在三个页面看到三种说法。

三段都通过，才算主路径成立。任何一段需要你在旁边口头补充，都不算。

三、范围三分类

下表是保存用户结果并在线收费的托管SaaS示例，不是所有产品的必做列表。范围按法律/安全前置、交易路径及本轮价值来裁剪。每一行都要写理由，理由要能被第 51–60 天的观察推翻。

「可以后置」和「这轮不做」的区别在于：前者已经知道怎么做，只是排期靠后；后者是当前不打算投入，除非证据变化。两栏不要混写，否则复盘时分不清是「没来得及」还是「主动放弃」。

四、不做清单为什么要写下来

防止临时加。 构建中途突然想到「顺便做个分享按钮」，如果没有清单，这个念头会直接进代码；有清单时，你至少要把它写进「可以后置」并标上日期，多一步就能拦住大部分冲动。

便于复盘。 第 100 天回看时，「当时为什么不做导入」比「做了哪些功能」更有信息量。它能告诉你当时的判断错在哪，而不是只留下一个功能列表。

对用户有话可说。 用户问「能不能支持某某」，你可以回答「这轮不做，原因是……，如果你需要，我先记下来」。含糊的「以后会做」会消耗信任，具体的边界反而让人放心。

五、20 天排期与 120 小时预算

下面是120小时的需求估算：20个6小时时段，不代表第31–50天连续每天工作。按01篇日历，本阶段14工作日，40小时档只有112小时、20小时档56小时。必须裁剪、复用或延期，不能把不足工时藏进休息日。

20 个任务时段 × 6 小时 = 120 小时估算
基础设施 45 + 主路径 50 + 缓冲 25 = 120
占比：45 ÷ 120 = 37.5%，50 ÷ 120 ≈ 41.7%，25 ÷ 120 ≈ 20.8%

缓冲不是「提前做完就休息」，而是给未知留的额度。一个人做产品，部署、支付审核、邮件送达这些环节的等待时间经常超出预期，25小时是工作量额度，不等于能压缩支付审核等日历等待。全职档可将主路径从50减至42小时（砍8小时非核心格式），总量45+42+25=112；20小时档可另选基础18+主路径26+缓冲12=56的本地架构，不能声称与原SaaS能力相同。

5.1 多做一个后置项会怎样

假设每个「可以后置」项平均 8 小时：

3 个后置项 = 3 × 8 = 24 小时
缓冲剩余 = 25 − 24 = 1 小时
4 个后置项 = 4 × 8 = 32 小时 > 25 小时，超支 7 小时

也就是说，加 3 个后置项就吃掉了 96% 的缓冲，第 4 个开始直接超支。这不是「挤一挤」能解决的：超支7小时须通过减范围、增预算或延期解决，不从睡眠里强扣，而每减少一段投入都要重新检查验收范围。

所以排期的正确用法不是「先排满再看」，而是先把 25 小时锁住，任何人（包括你自己）想加功能，都要先从这 25 小时里扣，扣完就停。

六、范围蔓延的三个早期信号

开始讨论「顺便」。 「反正登录都做了，顺便加个第三方登录」「导出都写了，顺便支持批量」。顺便的成本从来不是那一行代码，而是测试、文案、边界与之后的维护。

开始重构基础。 构建中途觉得数据模型不够优雅，想推倒重来。重构的收益在上线后体现，成本却立刻发生；除非当前模型会阻断主路径，否则记进清单，上线后再动。

开始比较竞品功能。 打开竞品的功能页，逐条对照自己缺什么。竞品的功能对应的是它的用户与它的阶段，不是你的主路径。比较可以用来找方向，不能用来定范围。

三个信号出现时，动作都一样：打开不做清单，写一行，标注日期，然后回到当天排期。

七、技术选型的三条最小原则

可替换。 三个月后能换掉。支付、邮件、存储、鉴权这些外部依赖，尽量通过一层薄封装调用；不追求抽象优雅，只要求换供应商时改一处。判断方法：如果换掉它需要改十个文件，说明耦合太深。

可观测。 出错能看见。至少要有结构化日志、一个错误上报入口、一条能按用户查到请求的线索。没有可观测性，封测时用户说「不行」，你只能猜。

可部署。 一个人能发布和回滚，且不需要在凌晨操作。发布脚本、环境变量、数据库迁移顺序要写下来；回滚要演练过一次，而不是假设它能用。

八、按架构裁剪，并验证安全边界

本例用新普通账号走输入、处理、保存、导出；同时执行以下负向验收，不能只检查未登录被拒：

• A账号替换对象ID，不能读取、导出、修改或删除B的结果；公开分享链接有范围、有效期与撤销边界。
• 密钥不进入前端包、导出及日志；服务端验证输入大小、类型与权限，不只靠隐藏按钮。
• 支付回调验签并按事件/订单幂等处理；重放不会重复发权益、创建费用或重复记账，异常状态可对账。
• 日志可追踪必要操作但不记录明文密钥或无关材料；备份在隔离环境恢复并核对结果与订单。
• 版本发布、回滚及数据库变化可演练；未修复的数据、资金或安全风险按损害阻塞上线。

连续10次主路径成功是本例回归观察，不证明所有边界安全；找不到阻断也不能免做上述检查。P1等编号只是内部约定，是否放行看影响和法律/合同条件，不按名字自动后置。

九、常见错误

十、行动清单

• 用一句话写出主路径的输入、处理、可见结果。
• 为三段各写一个验收问题，找一个人按问题走一遍。
• 把当前所有想做的功能列出来，按三分类打标并写理由。
• 把「这轮不做」单独存成文件，标注日期。
• 对照120小时需求估算，明确砍范围或延期，另保留缓冲。
• 把任务估算排到实际工作日，标明本阶段112/56小时上限。
• 演练一次发布与回滚，记录各用了多少分钟。
• 用新账号完整走一遍主路径，记录卡点位置。

使用边界与实操验收

120小时及45/50/25是本例估算，不是统一标准。全职阶段上限112小时，按45/42/25裁剪；半职阶段56小时采用18/26/12的较小架构，分别重新写验收，不能只把任务时间减半。

若改为延长日历，重新排封测、审核、预热及留存截止；等待期间能并行的任务也须计入周预算。原估算加3个各8小时后置项消耗24/25=96%的缓冲，是风险说明，不是建议主动花完缓冲。

验收：主路径可用、适用法律/安全条件满足、用户间权限与支付重放检查有证据、预算与不做清单可追踪。缓冲实际用于修故障后可以为0，不要求为了“剩余缓冲”而延后已经合格的交付。

关键参考与核验范围

以下链接支持对应的规则；本文的工时分配、功能分类与判据均为方法演示，不构成商业或法律意见。核验日期：2026-10-23。

• 中华人民共和国个人信息保护法 ：注册登录、结果保存与导出涉及个人信息时，收集范围、保存期限与删除机制要在上线前确定，不能等封测再补。
• 电子商务法 ：通过信息网络提供服务并收费时，经营者需履行告知与履约义务；支付与退款入口属于这条路径的一部分。

系列导航

• 上一篇：第 21–30 天：手工跑通一次交付
• 下一篇：第 51–60 天：十人封闭测试
• 回到目录：一个人的前 100 天：从想法到第一批付费用户
• 相关阅读：独立开发者的平台寄生 、独立游戏 MVP 验证