Chefshot — 自有产品
在联系餐厅之前就完成诊断的外呼引擎
挑战
Chefshot 让商业美食摄影不再需要影棚，产品本身是成立的。问题在于：餐厅老板不会一觉醒来就想要更好的摄影，他们想要的是更多订单。在他们眼里，菜单上的照片「还行」。现有照片与真正能改变转化率的照片之间的差距，对他们而言是不可见的，而任何投放都无法填平一个看不见的差距。手工做诊断同样不可行：认真判断一家餐厅的摄影质量需要一到两分钟的真实注意力，再写出一条具体的观察又要好几分钟——每个线索五分钟，换来的却是不到两位数的回复率。
技术栈
- n8n
- Dify
- Apify
- Apollo.io
- Twenty CRM
- PostgreSQL
- Vercel AI Gateway
合作形式: 自有产品：架构与工程由我独立完成，持续迭代。
阅读完整架构，以及它在十万级为什么会崩架构方案
- 在管线最前端用代码构建搜索矩阵——城市 × 品类 × 限定词——让「猎谁」这个决策被版本化、可复核，而不是散落在爬虫配置里
- 分批抓取，每次只跑一个矩阵组合，让单次查询永远不需要硬扛超时
- 在任何付费 API 被调用之前，用稳定的 Place ID 逐个比对 CRM 去重——这是让整套经济模型成立的成本控制环节
- 一个被反转的选图步骤：让快速视觉模型从候选池里挑出**最差**的那张菜品图，因为一家餐厅最差的主打菜照片，正是让它在损失订单的那张
- 通过带检索知识库的 Dify 智能体做诊断——知识库里放着摄影标准与改造前后的真实案例库，于是点评引用的是规则，而不是意见
- 并行的富化分支（企业基本面与决策人联系方式），并按 Company → Person → Diagnosis 的顺序写入 CRM，确保没有孤立记录
影响
- 整条管线由一个人运行：唯一真正需要专家判断的诊断环节以机器速度完成，而下游的一切仍然可复核
- 外呼带着对收件人自己那张照片的、具体且可核对的点评——这正是它与一次群发投放的区别
- 在任何付费调用之前完成去重，让单位成本与「真正的新线索」成正比，而不是与抓取量成正比
- 这套设计有一个算出来的、而不是拍脑袋的上限：约 300 家/小时，所以一万家大约需要一天半，而十万家需要连续运行两周——到那时该换的是编排方式（换成消息队列 + 无状态 Worker 集群），而不是调参