← 返回
01 独立开发 · 需求到上线 · 2025
冷邮件客户唤醒
1,600 多条老询盘在库里躺了三年。做成一条自己会跑的投递流水线 —— 五个邮箱分时区滴灌、AI 分类回信、停止类分类自动叫停后续轮次。
PythonFastAPISQLite WALIMAP / SMTPKimi K2.5
1,602
沉睡客户入库
52
首阶段草稿
127
已发送
11%
回信率 · 3 个询价
交付与结果
127 封试运行投递，3 个有效询价
- 我的职责
- 从需求到上线独立开发，覆盖排期、发送状态、收信分类和运营后台。
- 数字的范围
- 1,600+ 是待跟进老询盘的名单规模；127 封、11% 回信率和 3 个有效询价来自项目试运行记录。公开材料未列具体统计起止日期，这些数字不代表持续更新的累计业绩。
- 公开材料
- 可查看使用虚构数据录制的后台演示，以及项目治理规范；演示中的数字不用于证明生产结果。
遇到异常，怎么处理
下面是系统设计中的处理路径，展示方案的边界与取舍。
- 投递进程中断
- 发送状态先落库再投递，优先避免重复发送；可能漏发的记录需要核对。
- 收到退订或明确拒绝
- 停止类判定触发后续轮次停止，回复内容由 AI 起草、人工确认。
要解决什么
老询盘有价值,但人工一条条跟根本跟不过来。
而群发工具的风险在另一头:一旦重发,或者发到已经说过"别再发了"的人手里,域名信誉就毁了 —— 那是不可逆的。
所以这套东西的第一需求不是"发得多",是"绝不发错"。
- 01 名单入库 去重、无效域名剔除、按 CASL 剔除加拿大地址
- 02 内容预生成 前一天生成次日全部正文,人工抽检后入队
- 03 阶梯排期 按收件人时区落到当地上午,分轮推进
- 04 发送 瞬态进程定时触发,状态先落库再投递
- 05 收信与分类 定时抓 IMAP,精确匹配回原邮件
- 06 停止判定 退订 / 不感兴趣 → 立即叫停后续轮次
- 1,602
- 沉睡客户入库
- 52
- 首阶段草稿
- 127
- 已发送
高亮的一步是整套系统的要害 —— 下面每一区都在讲它为什么这样定。
怎么搭的
每一层都是一次真实的取舍。图里高亮的那层,是整套系统的要害 —— 它错了,别的做得再好也没用。
- 名单入库:去重、无效域名剔除、按 CASL 剔除加拿大地址
- 内容预生成:前一天生成次日全部正文,人工抽检后入队
- 阶梯排期:按收件人时区落到当地上午,分轮推进
- 发送:瞬态进程定时触发,状态先落库再投递
- 收信与分类:定时抓 IMAP,精确匹配回原邮件
- 停止判定:退订 / 不感兴趣 → 立即叫停后续轮次
为什么这么选
并发控制用 WAL 还是应用层锁?
SQLite WAL
应用层锁一旦进程被杀就是死锁,而这是个定时触发的瞬态进程,被杀是常态。WAL 把并发交给数据库,进程怎么死都不会留下锁。
状态先落库还是先发信?
先落库
先发后记,崩在中间就会重发;先记后发,崩在中间只是漏发。重发砸的是域名信誉,漏发下一轮补得回来 —— 设计成「可能漏,绝不重」。
回信分类由 AI 判还是关键词判?
关键词兜底 + AI 起草
停止类判定关系到合规,不能交给可能出错的模型;而回复内容让 AI 起草、人工确认再发,省时间又不失控。
系统界面
本地演示实例 + 确定性演示数据,客户信息全部虚构
