「1」是什么：四个里程碑与一张 100 天账本

「做完了」不是一个感觉，而是一条能被打断的判据：达不到，就退回上一段补证据。

一、一个没有终点的 0→1

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

一位开发者离职后开始做工具。第 3 个月，他说「核心功能快好了」；第 6 个月，他说「还差一个导出」；第 9 个月，他说「在改界面，改完就发」；第 12 个月，产品还在本地跑，没有一个外部用户。

他不是在拖延。他每天工作十小时，提交记录密密麻麻。真正的问题是：他从来没有定义过「1」是什么。 没有终点，任何进度都像差一点；差一点，就再改一点。

0→1 的失败很少是「做不出来」，多数是「做出来之后不知道该怎么算完成」。这一篇先把终点定义清楚，再算一遍时间和钱。

二、四个里程碑与两条证据轴

这些是内部实验判据，不是行业基准。指标分别保留，达成后一道也应检查前一道是否因改版失效。

问题投入证据与本方案成交状态是两条轴。02篇的A/B/C只分问题证据：A为可核实的既有金钱支出，B为具体行为/时间投入，C为陈述或待核实线索。为竞品付款能支持问题存在，不能计本方案M3。

本方案另记：无意向、明确报价后的预算/评估安排、预付待履约、已交付且未退款、退款/争议。预付款说明承担了履约和潜在退款义务，不直接当作已赚收入。

2.1 独立购买不等于渠道必须不同

排除自己下单、赠款、重复订单和仅为支持朋友的付款，记录共同预算、关联企业和介绍关系。同群用户可能确有独立需求；不同渠道也可能来自同一个采购主体。跨渠道取样用于挑战结论，不是判断成交真假的必要条件。

2.2 使用、续费与推荐分开

买断产品没有按期续费，但仍能测使用留存。例如本组固定从首次付费获得可用权益起算，第28–34天至少完成一次核心任务算第4周使用留存。此定义适用于本例高频工具；年度报税工具应按自然使用周期改窗口。

推荐了1人但第4周未使用：推荐数记1、该用户的使用留存记0。续费/复购另记发生时间、金额与退款。不能把三种行为相加后称作留存。

三、验证顺序可以调整，证据不能替代

可以先售后做，但必须说明交付日期、可交付范围与退出安排；这取得预付证据，不代表软件已经被使用。可以先免费观察，再收费，但免费队列和付费队列须分开报告。手工交付只验证结果需求及流程的一部分，技术可行性要另测。

每个阶段把已知、未知与下一步放在同一页：用户是谁、做了什么、为哪个方案付过钱、仍缺什么证据。不要用一个好看的注册数替代全部里程碑。

四、统一100天日历与两档工时

本组用14个完整周（第1–98天）工作，99–100天留作日历缓冲与复盘。每周前5天工作、后2天休息；20小时档每天4小时，40小时档每天8小时。这里的“第几天”是相对项目日，不是100个工作日。起始日变化时按自己的日历重排。

上限包含约人、检索、记录、等待期可做的其他任务、修复与支持；等待不会凭空产生额外工时。周10工作日在64–68天，第69–70天休息：第68天安排预热发送，第69–70天可用已设好的静态页面与定时内容，不要求加班。第71天发布，首周观察为第72–78天，第79–80天处理剩余事项。

05篇的120小时构建是需求估算，不是本阶段可用上限：全职档仍差8小时，应先砍范围或延期；20小时档只有56小时，需要采用更小架构或重新安排全系列，而非硬塞120小时。各篇局部预算均从本表扣，不重复计算已经完成的注册、支付和条款工作。

4.1 工时只限制范围，不保证产出

每周10小时共140小时也可能做成一个无账号、无云端的本地工具；已有代码与熟悉领域会改变工时。先估“输入、处理、结果、安全、分发与支持”的工作，再选手工验证、桌面工具或托管SaaS，不按140小时一刀切。

4.2 现金按净流出算

下表为100天约3.3个月的教学预算，实际付款按账单日，不按均摊金额假设到账。

全职无其他收入：预计总净流出上限49500+791=50291元，储备60000元余9709元。不能据此断言任一突发支出必然击穿预算，应另做设备/家庭支出压力情景。

在职工资已覆盖全部生活支出且不依赖项目回款时，项目增量现金需求上限是791元加实际其他成本，不再扣一次49500元。混合情形记录“生活+项目支出−可确定净收入”，预收款中的待履约/退款资金单列保留；没有固定收入时不把未来订单当已收现金。

五、留存受入组日约束

按本例首次付费获得可用权益起算，观察第28–34天，只有完整走过窗口的用户进入成熟分母：

最晚成熟入组日 = 截止日 − 34
第100天 − 34天 = 第66天

若只检查第28天当日，可最晚第72天入组，但不能把它与完整28–34天窗口混算。产品上线日只是允许入组的起点，不是所有用户的入组日。

默认到81–90天才首次收费时，第100天没有成熟付费队列，应报告“付费使用留存未验证”，下一轮保留观察；可以另报先前免费队列的使用，但不能充当付费留存。成熟用户失联且无可靠日志时记未知，另报可观测覆盖，不能悄悄从分母删除。

六、三个决策点

把预算、最长投入时间与触发条件预先写下。现金不足先减支或补可靠收入；停止开发也要履行已收款客户的交付、退款、数据与通知义务。教学阈值只用于本轮决定，不宣称达到即证明市场成立。

七、行动与复算验收

• 按自己的日历写出每阶段可用工时，合计不超过周投入×14。
• 分别记录问题投入和本方案成交；给付款、交付、退款加日期。
• 固定核心使用事件、入组日、观察窗口和截止日。
• 分开生活总支出、其他收入覆盖与项目增量支出。
• 预写阶段决定、停止条件及未完成客户义务的收尾安排。

复算：20小时档为70×4=280小时，40小时档为70×8=560小时。构建阶段14工作日分别56/112小时，不够120小时估算；每周10小时的140小时另按架构重排。现金791+49500=50291，60000−50291=9709。第90天入组在100天仅10天，成熟人数为0时留存写不可判，不写0%。

验收不是凑满某个数字，而是另一人能按记录复现：这些人为何属于目标群、证据来自哪个方案、现金如何变化、哪些用户已经走满观察期。

关键参考与核验范围

以下链接支持对应的规则；本组的里程碑、阈值与账本均为方法演示，不构成商业或投资建议。核验日期：2026-10-23。

• 中华人民共和国个人信息保护法 ：用户访谈、使用日志与回访记录涉及个人信息时，需按告知同意与最小必要原则收集和保存。
• 电子商务法 ：通过信息网络销售商品或提供服务时的经营者义务，收费上线前应先核对其适用范围。

系列导航

• 下一篇：第 1–10 天：选题与付费证据
• 回到目录：一个人的前 100 天：从想法到第一批付费用户
• 相关阅读：独立开发者生存指南 、一个人的服务生意