← 返回项目目录
运营中 · 结果来自试运行记录
独立开发 · 需求到上线 · 2025
冷邮件客户唤醒
将 1,600 多条历史询盘接入分批投递与回信处理流程：五个邮箱按时区排期，停止类判定触发后续轮次停止，草稿和异常保留人工复核。
PythonFastAPISQLite WALIMAP / SMTPKimi K2.5
阶段记录，统计窗口未统一
- 1,602客户入库
- 52首阶段草稿
- 127已发送
- 11%回信率
- 3有效询价
交付与结果
127 封试运行投递，3 个有效询价
- 我的职责
- 从需求到上线独立开发，覆盖排期、发送状态、收信分类和运营后台。
- 数字的范围
- 1,602 是入库规模，52 是首阶段草稿记录；127 封、11% 回信率和 3 个有效询价来自试运行记录。公开材料未列统一统计起止日期，各阶段不能据此推算转化率，也不代表持续更新的累计业绩。
- 公开材料
- 可查看使用虚构数据录制的后台演示，以及项目治理规范；演示中的数字不用于证明生产结果。
遇到异常，怎么处理
下面是系统设计中的处理路径，展示方案的边界与取舍。
- 投递进程中断
- 发送状态先落库再投递，优先避免重复发送；可能漏发的记录需要核对。
- 收到退订或明确拒绝
- 停止类判定触发后续轮次停止，回复内容由 AI 起草、人工确认。
要解决什么
老询盘有价值,但人工一条条跟根本跟不过来。
重复投递、或继续发给已退订的人，会影响客户体验与发信域名信誉。
设计上优先降低重复发送风险，并让停止条件与异常记录可以复核。
工作流程
按内容资料整理的语义流程示意，不作为运行结果证明。
- 01 名单入库 去重、无效域名剔除、按 CASL 剔除加拿大地址
- 02 内容预生成 前一天生成次日全部正文,人工抽检后入队
- 03 阶梯排期 按收件人时区落到当地上午,分轮推进
- 04 发送 瞬态进程定时触发,状态先落库再投递
- 05 收信与分类 定时抓 IMAP,精确匹配回原邮件
- 06 停止判定 退订 / 不感兴趣 → 立即叫停后续轮次
为什么这么选
WAL 解决哪一部分并发问题?
SQLite WAL
WAL 允许读写并行，但同一时刻仍只有一个写事务，也可能遇到 SQLITE_BUSY。它改善的是数据库并发；领取发送任务、状态更新与防重仍要由事务和业务规则约束。
状态先落库还是先发信?
先落库
先发后记时，投递成功但记录失败可能引发重复发送。先记后发优先降低这类风险，但可能留下漏发或结果未知的记录，需要核对后处理；这个顺序本身不能保证任何故障下都不重复。
回信分类由 AI 判还是关键词判?
关键词兜底 + AI 起草
停止类判定关系到合规,不能交给可能出错的模型;而回复内容让 AI 起草、人工确认再发,省时间又不失控。
