第 61–70 天：上线前的十五件事

上线既要接通交易路径，也要满足适用法律与安全条件；成功收款不能代替后两项验收。

一、上线不是「代码写完」

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

一位开发者第 68 天判断「功能齐了」，把链接发进两个群。当天来了 12 个访客，4 个走到定价页，0 个完成支付。他以为是定价太高，改了文案，第二天又发了三个群，还是 0 单。第三天他用自己的账号点了一次「购买」，页面转了两秒，报「商户配置错误」——支付通道只填了沙箱密钥，从未切到生产。

问题不在功能，也不在定价。他的链路上有一个断点，而他没有走过一次完整链路。 更麻烦的是，第一批访客可能不再回来：那 12 个人里，有 5 个后来再没打开过链接。

发布可分批重试，但每批触达都有成本，链路验证有助于减少无效尝试。

二、判断标准：一条链，不是一个功能

把用户从「第一次听说」到「完成付费」画成一条链：

听说 → 打开 → 看懂 → 注册 → 到达激活动作 → 付费 → 收到凭证 →（出问题时）找到人

这条链的性质是串联：任何一环断掉，后面的环节都不发生，后续转化可能无法发生；此前需求证据仍可保留。所以上线前的判断标准不是「功能做完了吗」，而是：

• 每一环是否有一个陌生人能在不问你的情况下走通？
• 断掉时，告警能否及时到达并有人处理？

一个可操作的检验：把每一环写成一句「用户在这里要完成什么」，再让一个没参与开发的人复述。复述不出来，需要进一步观察理解障碍，与功能多少无关。

第 06 篇的十人封测解决的是「看懂」和「激活」两环；这一篇补齐剩下的六环，它们大多不是功能，而是配置、文案和流程。

三、十五件事总表

按「缺了会断哪一环」排序，不按开发工作量排序。第五列是查细节的地方，不是必读材料。

先分类再安排：

• 适用法律与安全硬门槛：主体/许可和商品服务信息披露、必要条款、合法数据处理与告知、权利响应、用户隔离、资金与结果安全。是否适用按业务、地区、数据和合同核对，缺失即不放行。
• 本架构交易必需：价格与权益一致、支付/订单/退款状态、相关邮件和支持路径；本地买断或人工服务按实际架构裁剪。
• 可后置体验：额外帮助文章、非必要外观、更新日志等，只有不影响前两类时才后置。

不能只问能否收钱。已知越权或缺适用告知时，即使支付成功也不发布。导出可人工仅在已有承诺和使用场景允许时成立；若05篇本例验收承诺自助导出，就不能在上线时悄悄降为人工。

四、依赖顺序

不是十五件事都能并行。下面这些有硬前置，顺序错了会返工。

本例技术依赖可按10→11→12及3→4准备，法律与安全条件并行核对。采购服务或模板可以帮助完成，仍须验证与实际处理一致，不能只因套模板而放行。

一个经验上限：同时推进不超过三项。本例多项需要进后台操作，切换成本比看起来高；一次只开两个后台，做完再换。

五、上线前48小时：按环境验收

先查实际通道的测试/上线文档，不把真实银行卡与沙箱卡视为替换选项。Stripe禁止用真实支付资料在live模式做测试；在测试环境使用测试密钥和官方模拟数据。生产核对密钥环境、商户资格、域名、回调、权限及通道允许的上线流程，不自行制造被禁止的测试交易。

48小时是本例准备窗口，非银行到账保证。沙箱退款只证明模拟状态；真实合法业务发生后的退款按通道状态跟踪到账，超期追查并告知用户，不把未到账标完成。Stripe官方说明退款通常需5–10个工作日显示在客户账户，实际可能更久；该例不能套所有钱包与银行。

先判断失败是否触及法律、安全或交易硬门槛；收件箱到达速度、文字理解等按目标人群和实际证据修复，不能用“12项有截图”代替真实条件。

六、可以后置的十项

后置不是不做，是明确写下代价，等有付费用户之后再补。

后置前先确认不影响适用法律、安全及已有合同，再检查本次价值与交易路径。审计追踪按风险保留；企业SSO能否后置与安全日志分开判断。

七、常见错误表

八、行动清单

• 把十五项抄成一张表，逐项标「已具备 / 有替代 / 缺失」。
• 画出自己的依赖顺序，标出关键路径。
• 先核法律和安全硬门槛，再按本产品依赖排交易路径与体验项。
• 准备一个从未注册过的邮箱和一台干净设备。
• 按 12 个检查点走一遍，逐项记录时间与截图。
• 在允许的测试环境模拟失败（官方测试卡、断网），确认报错可读。
• 确认退款申请与商户处理可追踪，通道到账期限按实际披露。
• 写下十项后置项的代价，以及补上的触发条件。

使用边界与逐项工时预算

下表是已有主路径后的核对/补齐工时，不是把05篇做过的登录、部署再算一次完整建设。未建设的项必须另估，不能认为2小时一定做完。

若3和11各从2增到5小时，总量36；文档三篇减一篇省4、把非必需公告/日志制作后置省2，得到30。法定公示或必要用户通知不属于可省公告。若其他14项都各需2小时，则基线34、延迟后40、同样节省6后仍34，不能混用两个情景。

按01日历本阶段半职24小时、全职48小时。30小时基线在半职仍差6小时，应提前在前阶段明确预留、再减非必需范围或延期，并联动发布日；不得把未计工时塞到休息日。全职余18小时包含预热、故障修复和审核沟通，不是随意加功能的额度。

验收：按环境保存状态证据，硬门槛均满足，有未完成事项时明确责任人与下一检查点；沙箱截图不充当真实到账凭证。

关键参考与核验范围

以下链接支持对应的规则；十五项清单、工时预算与检查点均为方法演示，不构成法律或商业建议。核验日期：2026-10-23。

• 中华人民共和国个人信息保护法 ：按第13、17、45、47、50、51条分别核处理基础、告知、权利响应和安全；不把按钮存在等同履行全部要求。

• 电子商务法 ：通过信息网络销售商品或提供服务时的经营者义务，涉及条款、退款与消费者权益的披露要求。

• Stripe测试规则 ：测试环境、模拟资料与live测试限制。

• Stripe退款状态 ：通常到账范围及延迟可能，不能当固定保证。

系列导航

• 上一篇：第 51–60 天：十人封闭测试
• 下一篇：第 71–80 天：发布与第一周
• 回到目录：一个人的前 100 天：从想法到第一批付费用户
• 相关阅读：独立开发者的资产韧性 、一个人的公司：主体、税务与合规