速评：七月二十二号 dev.to 那篇 job-digest 复盘，开头四个数摆得很诚实——73 投，61 个没回音，8 封拒信，4 个进电话初筛。
然后两千多词写下来，这个 4 再没出现过一次。
我不觉得是笔误。这组数暴露的是整篇里最值钱的盲区。
技术选型那段我扫过去的——Python 3.11 加 asyncio，不用 Go；SQLite 不用 Postgres。理由都成立，也都见过一百遍。真正有意思的在成果清单。
他记了四笔账，全在投递发生之前：每天刷职位从 45 分钟压到 5 分钟，每周投递从 8 个提到 12 个，摘要里匹配自己技术栈的比例从 30% 涨到 85%，从职位发布到投递从三四天缩到 24 小时以内。四条，一条不落地全磨在漏斗上端。
唯一往下游走的是招聘者对话，每月 1 到 2 次变成 4 到 5 次。这条我认，是这几周里唯一能证明管道真在往下走的信号。但它有个取样问题作者一句没交代：1 到 2 变 4 到 5，统计窗口是多久——四周，还是从项目跑起来算起？没说。不是怀疑他编，是这种拿"使用前 vs 使用后"两组自报数字直接对照、又不开窗口的写法，说穿了就只是一句话。这剧本，眼熟。
全文我最想拿笔划出来的一句藏在很后面：有一次收到 18 个匹配职位，一个都没投出去，原因是选择太多、决策瘫痪。
他给的修法很干净，默认只推前三名，想看剩下的回 /more、回 /all。评论区有人说这才是整篇里最像产品决策的一个决定，我同意。但它暴露的东西比它修掉的多：18 个投不出去，3 个就投得出去？把选项砍到三，解决的是"挑不过来"，不是"不想投"。而 73 投 4 中背后的那层东西，沉在"不想投"下面再一层——每投一份，都是给自己记一笔等着被无视的账，投得越多，账本越厚。这不是排序算法能治的病。
还有个细节我一直记得：早期 SQLite 去重只按标题加公司做键，公司换个写法重发同一个岗，他就重复投了，招聘者当面跟他说"你上周申请过了"。这一句比任何一条技术选型都真实。被人当面点破重复投递，比 429 和 CAPTCHA 扎心多了——CAPTCHA 拦的是机器，那个招聘者拦的是你。
LLM 富化那段作者自己也交代了：盲信 gpt-4o-mini 一个星期，模型给他编出一个谷歌阿姆斯特丹的 K8s 平台岗，年薪 50 万欧，链接点进去 404。修法是每条抓到的链接发 HEAD 请求，非 200 的在富化之前就扔掉。
修法没错。但我想说的是 100 条 0.02 美元这个价——便宜到人根本懒得给它加校验层，直到你为一个不存在的谷歌岗位改了两天简历。便宜不是免费的近义词，它只是把账单往后推。这一单，最后是作者自己付的。
评论区有人提议干脆加自动投递。作者回得挺清醒：LinkedIn 这类站点会限流、会封。但真正拦住这件事的不是风控，是数学——手动 73 个出 4 个电话初筛，自动发出去 300 个，回复率不会自己往上爬，只会把 61 这个数等比放大。
这里立个 flag：这东西要真按他列的那条路线图走下去——加 ATS 后端、加薪资基准、加个 Streamlit 仪表盘——半年后最可能出现的结局是，他把大半精力花在了把"匹配"这个词往自己这边拽，而电话那头想听的，还是那 4 次初筛里他到底说了什么。
工具越顺手，越容易让人相信瓶颈在上游。
把一个 5% 的回复率乘以十，得到的不是 50%，是十倍的沉默。