二开信源管道跑了半个月，聊聊用 pgvector 语义降噪和防重推送踩的几个深坑

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

平时转型做独立开发与出海调研，最大的痛点就是每天被垃圾信息淹没：刷推特、Product Hunt 和各大社区，充斥着大量套壳工具互吹与营销号焦虑小作文。想找点真正有落地参考价值的技术选型、开源轮子，每天在信息堆里淘金太累。

半个月前基于开源底座二开了一套垂直情报过滤管道，单机部署跑在吃灰的 Linux VPS 上。跑顺了之后每天只推 2~3 条高信噪比卡片，省心很多。但回顾这半个月的二开踩坑，有几个工程层面的细节值得复盘：

1. 语义向量去重的边界与阈值陷阱

最开始想用 pgvector 解决「不同媒体在 48 小时内反复报道同一件事」的冗余。直接用文本做 embedding ，发现余弦相似度阈值如果设在 0.85 ，很多同赛道但不同技术方案的独立项目会被误杀；如果放宽到 0.92 ，换个标题的通稿又漏了进来。最终的解法：先做实体与依赖层提取（ GitHub Repo 归一化、顶级域名折叠），实体命中直接折叠；实体不命中才走 5 轴语义打分（落地可行性、商业闭环、代码成熟度），把纯公关稿在打分层直接干掉。

2. Prepared Statement 的异步双写灾难

这是最隐蔽的一个线上坑。异步队列消费时，外部消息（如推到频道）成功发送，但数据库记账由于连续拼接了两段 SQL 语句撞了底层 Prepared Statement 解析报错。结果事务回滚，队列引擎误判该任务未完成，进入指数退避重试，直接引发同一条消息向外部端点死循环狂推。教训就是：跨外部网络调用的 side-effect 必须与本地数据库状态做原子防重设计，外部调用前显式插入 pending 占位锁。