← 返回
01 独立开发 · 需求到上线 · 2025
1,600 多条老询盘在库里躺了三年。做成一条自己会跑的投递流水线 —— 五个邮箱分时区滴灌、AI 分类回信、停止类分类自动叫停后续轮次。
PythonFastAPISQLite WALIMAP / SMTPKimi K2.5
11%
回信率
127
试运行投递
3
有效询价
0
重复投递
Problem
要解决什么
老询盘有价值,但人工一条条跟根本跟不过来。
而群发工具的风险在另一头:一旦重发,或者发到已经说过"别再发了"的人手里,域名信誉就毁了 —— 那是不可逆的。
所以这套东西的第一需求不是"发得多",是"绝不发错"。
Architecture
怎么搭的
流程图按站点样式重画,不是 PDF 截图
Tradeoffs
为什么这么选
并发控制用 WAL 还是应用层锁?
SQLite WAL
应用层锁一旦进程被杀就是死锁,而这是个定时触发的瞬态进程,被杀是常态。WAL 把并发交给数据库,进程怎么死都不会留下锁。
状态先落库还是先发信?
先落库
先发后记,崩在中间就会重发;先记后发,崩在中间只是漏发。重发砸的是域名信誉,漏发下一轮补得回来 —— 设计成「可能漏,绝不重」。
回信分类由 AI 判还是关键词判?
关键词兜底 + AI 起草
停止类判定关系到合规,不能交给可能出错的模型;而回复内容让 AI 起草、人工确认再发,省时间又不失控。
Screens
系统界面
本地演示实例 + 确定性演示数据,客户信息全部虚构
