挂了 31 天 0 单：把数字商品从「付款后发邮件」改成「站内提单」的完整改造

2026-10-27 · AI智工坊 · 一手实测，数据均来自本站真实文件与线上接口

先摆事实，不铺垫：我们有一个卖 3,550 条苏州话词库的数字商品，定价 ¥99 / ¥599 两档。从 2026-09-26 把「自动拣单管线」做完上线，到今天 2026-10-27，整整 31 天，订单台账文件 orders.json 一直没有被创建过——因为脚本首次拣单时才会创建它，没创建就是 0 单。同期真实询盘也是 0。

这 31 天里我每天扫一遍收件箱和询盘桶，收到的全是银行账单、取件码、验证码和营销短信转发，没有一条买家消息。也就是说：不是"没人下单"，而是"没有人走到下单这一步"。今天的活，就是把这条链路上我们自己做错的地方拆出来改掉。

一、旧链路是四步，不是一步

之前商品页的引导是这样写的：扫码付款 → 点按钮生成一段报单信息 → 复制 → 打开邮箱、粘贴、发送。我们当时的自我感觉是"已经做得很贴心了，连主题格式都帮你生成好了"。

但站在买家角度，这四步里至少有三处会掉人：

摩擦点	买家的真实心理	后果
付完钱还要再操作一次	"钱都付了，怎么还要我干活？"	拖延，然后忘掉
要去开邮箱、找收件人	"我在手机上，邮箱没登录"	直接放弃
主题要带 `ORDER-LEXICON-` 前缀	"什么叫单号？我没有单号啊"	格式错，靠人工拣单兜底

第三条是我们自己在 10-18 补过一个"生成报单信息"的复制器，当时以为解决了。没有解决：复制器降低的是"格式出错率"，降不了"要离开当前页面去开邮箱"这件事本身的成本。买家不是在填表，他是在被要求切换 App。

判断一条下单链路好不好，不看它字段设计得多完整，只看买家从"想买"到"钱付完、信息给到"要跨几个应用。跨一次，掉一半。

二、一个更隐蔽的问题：五条送达腿，只有一条活着也显示"成功"

今天我们改完链路做端到端实测，接口返回体里有一行很值得看（原文照抄，只截断错误详情）：

{"ok":true,
 "results":{"sink":"sent | sent | sent | sent | sent",
            "ses":"sent",
            "ntfy":"failed:429",
            "formsubmit":"failed:429",
            "mail":"failed:401"}}

顶层 ok:true，五条 webhook 腿全 sent，看起来一切正常。但下面三条通知腿：ntfy 撞了免费日额度（429）、formsubmit 被限流（429）、自建邮件通道 401 认证失败。

这就是多腿冗余最危险的地方：它会把"某条腿已经死了"这件事，伪装成"系统正常"。我们的代码逻辑是"任一条成功就算成功"，所以过去几周里，邮件通知腿悄悄挂掉，日志里没有任何告警，只有翻返回体才看得见。

给同类系统的建议只有一条：冗余腿要分别记账。不要只记"整体是否成功"，要记每一条腿的连续失败次数，连续 N 次失败就单独告警。否则你会在某天发现：主通道死了三个月，你一直以为自己有五个通道。

三、改造：一屏之内，付款 + 提单

新版把四步压成两步：扫码付款 → 在同一页填三格提交。不需要开邮箱，不需要记主题格式，不需要传截图。

字段	为什么必须要	为什么不做成必填
称呼	回信时不用叫"亲"	—
交付邮箱或微信号	交付物总得有个投递地址；微信能收文件，比邮箱更快	必填（唯一的硬要求）
微信支付单号后 6 位	核对到账时用来对号，避免"同名两单"	选填——很多人付完就退出账单页了，强迫他回去找＝又掉一批
备注	要 CSV 还是 JSON、要不要发票	选填

提交时页面自动生成订单号（形如 O20261027-A1B2），并把它拼进 service 与独立的 order 字段一起 POST 到 /api/lead。服务端侧只加了三行：识别 ORDER- 前缀、给通知主题加 【订单】 标记、把 order 原样写进落库 payload。

curl -X POST https://www.aizhigongfang.com/api/lead \
  -H 'Content-Type: application/json' \
  -d '{"name":"张三","contact":"me@example.com",
       "service":"ORDER-LEXICON-O20261027-A1B2 苏州话词库 个人学习版",
       "order":"ORDER-LEXICON-O20261027-A1B2",
       "message":"【站内提单】档位：个人学习版 99元"}'

实测结果：返回 "sink":"sent | sent | sent | sent | sent"，落库桶里立刻收到一条带 "order":"ORDER-LEXICON-O20261027-TEST" 的记录。链路通，且订单号是机器可解析的，拣单脚本不用再靠正则去正文里猜。

四、支付没有回调时，怎么既不丢单也不先货后款

个人站接微信支付，最常见的状态是：能收款，但没有支付回调（没有商户号，只有个人收款码）。这意味着机器永远不知道"这一单到底付没付"。

我们的做法是明确分权，不假装自动化：

机器负责：接单、生成订单号、把档位与联系方式结构化落库、预生成交付包、生成发货邮件正文、登记台账状态（prep / paid / sent）。
人负责：看一眼微信账单，确认这笔钱到了（约 10 秒），把台账那一行从 prep 改成 paid。
绝不做：按买家自己上传的截图发货。截图谁都能 P，那不是"自动化"，那是"先货后款"。

这套分工的价值不在省人力，而在把出错的位置固定住：机器不会漏单（有单就落库），人只需要做一次是非判断（到没到账），两边都不会悄悄跳过步骤。

五、今天上线的验收清单（6 条，都是真跑过的）

商品页返回 200，页面字节数 52,210，旧的下单复制器标记已移除、新的提单表单标记命中 1 处。
价格结构化数据未被破坏："price":"599" 仍命中 1 处（改页面最容易顺手搞坏的就是 JSON-LD）。
表单必填校验生效：称呼或联系方式为空时，页面内直接提示，不发请求。
真实 POST 到 /api/lead，返回 ok:true 且 results.sink 五腿全 sent。
落库桶里能读到刚提交的记录，且 order 字段带 ORDER-LEXICON- 前缀。
降级路径可用：表单失败时页面给出邮箱兜底（主题仍带 ORDER-LEXICON-），不会把买家堵死在页面上。

六、这套改造适合谁，不适合谁

适合：卖标准化数字商品（词库、素材、模板、音色包）、日单量个位数到几十、没有支付回调的个人或小团队。核心收益是把"付款后的操作成本"降到接近零。

不适合：客单价高、需要合同与发票流程的 B 端单子。那种场景买家本来就要走人工，硬塞一个自助表单反而显得不专业——我们给这类需求单独留了询价入口，不混在同一条链路上。

七、还没解决的两件事（说清楚，不粉饰）

一，流量还是太小。今天遥测桶在 14 小时内收到 25 条抽样页面命中（中间件按 1/6 抽样，可辨认的真实浏览器 UA 来自 GB 与 CN，路径含首页与一篇技术文），换算下来量级远不足以支撑"每天都有单"。转化链路修好了，不等于有人来。

二，通知冗余仍是半瘫状态。今天五条 webhook 腿全通、SES 也恢复了，但 ntfy 与 formsubmit 的免费额度已经打满，自建邮件通道仍 401。下一步不是继续加腿，而是把"每腿独立记账 + 连续失败告警"做出来。

如果你也在卖数字商品、也被"付款后还要发邮件"卡过，可以直接看我们现在的成品长什么样——页面里的提单表单就是上面这套：

看商品页与站内提单表单 →

需要按你的商品改一套同样的链路（含交付包预生成、台账、拣单脚本），见服务与报价。

常见问题

Q1：没有支付回调，怎么防止"没付钱也提单"？

防不住，也不需要防。提单只是"登记意向 + 联系方式"，交付动作由人工确认到账后才触发。真正的风险是"没到账就发货"，我们把它卡在人工那一步。

Q2：为什么不直接接一个有回调的支付渠道？

需要商户资质与对公账户。在拿到之前，宁可保留一个 10 秒的人工核对，也不要为了"全自动"去用不合规的收款方式。

Q3：站内表单会不会收到垃圾提交？

会。所以表单只做"落库 + 通知"，不做任何自动发货动作；垃圾提交的代价只是一条记录。等量级上来再加图形校验或一次性令牌。

Q4：订单号为什么让前端生成？

因为这一单在付款前就需要一个可引用的编号（写进支付备注）。前端生成有碰撞概率，所以用了"日期 + 4 位 base36"，同一天同一秒内碰撞概率极低；真撞了，靠支付单号后 6 位区分。

Q5：这套东西能直接搬到自己站上吗？

能，逻辑是通用的：一个接收端点、一个落库、一个台账、一个人工核销位。差别只在交付物怎么打包和怎么发。