14天推了148条，翻来覆去只有61件货

每天早上，一个自建的折扣机器人把当天的促销清单推到 Discord：只挑常买的店、自己的尺码、有货的款。它确实在干活。直到有人把推送记录数了一遍。

14 天，148 条推送，去重后只有 61 件商品。一件棕色拉链连帽衫在四周里出现了 23 次，一双运动鞋连推 13 天。机器人已经不是在找折扣，是在反复念叨同一批货。

这是三个失败里的第一个。它们最终变成了 ClothingLab——一个免费工具，专门把最枯燥的那部分做对：只推你选的店、你的尺码、确实有货的促销品，而且同一件东西不给你看第二遍。

失败一：同一件连帽衫反复出现

每日推送分成几个板块：精选、潮流、搭配、你尺码的新品。每个板块都从同一个池子里挑货。精选板块只记得最近三天看过什么，等所有商品都被看过一遍，它就退回去把整张清单重新推一遍。潮流板块则完全不检查看过什么。

修法是让所有板块共用一本账。任何给你看过的商品，14 天内不再出现。只有值得再提一次时才回来：比上次看到时至少便宜 5%，或者你的尺码断货后又补上了。同一款的不同配色算同一件商品，黑色连帽衫和藏青连帽衫不能轮流上场。同一条推送里，任何商品不得出现两次。

失败二：欧码鞋码被悄悄丢掉

欧洲店铺的鞋类折扣从来没出现过，也没有任何报错。这些店把尺码写成裸数字，45 或 45.5，有时还把颜色粘在后面：46 2/3 / Cream White / Blue。原来的尺码检查只认前面带字母的“EU 46”，一个裸写的 45.5 被当成英国码读取，自然对不上，商品就以“尺码不符”被丢弃。这是每一轮里最大的丢弃原因。

解决办法靠数字本身就能证明：没有成年人的英国码或美国码鞋码会到 39 及以上，所以光看数字就能判断这家店列的是欧码。英国码和美国码没法这样区分，只能按店铺单独设置。ClothingLab 会从你的英国码换算出欧码并标在结果上，你看到“EU 44”就知道该订哪个号。

失败三：库存就在那儿，读错了地方

有些店对每一双运动鞋都显示“无尺码信息”。原以为是店家藏起来了，其实不是。页面上可见的尺码选择器没有库存标记，但每个尺码的确切库存就嵌在页面的数据里。有一家店，在改读数据而不是读按钮的那天，可用的鞋类折扣从 0 条变成 9 条。

另一面更难接受。一些大型商业街连锁店根本不把分尺码库存写进页面，而是之后用 JavaScript 加载。对这类店，机器人在你的尺码下找到零件商品。ClothingLab 的规则是：没有分尺码库存的商品，永远不会被标成“有你的尺码”。结果更少，但没有一条是假的。

ClothingLab 是什么

引擎从原来的机器人重建，不再硬编码成只服务一个人：

• 一段简短问答生成你的档案：尺码（上衣、腰围和裤长、英国鞋码）、喜欢的版型和绝不穿的款式、颜色、品牌、预算。全程不问身高体重。
• 两个通用店铺读取器：任意 Shopify 店铺（公开的 products.json 里有每个变体的尺码和 available 标记），以及任何有站点地图、页面带规范商品数据的店铺。会检查 robots.txt，请求之间有延迟，运行前必须设置一个说明你是谁的用户代理。
• 预算档位 低 / 中 / 高，按每件衣服的英镑价格线划分、可自行调整，每档给出一套由上衣、下装和鞋组成的搭配，尺码对得上，你列出的已有单品也会被用上。某一档当天凑不出完整搭配，它会直接说明。
• 降价关注列表、每日摘要（文件、邮件或 Discord），以及一个 MCP 服务器，可以从 Claude、Cursor 或任何 MCP 客户端完成引导，并直接问“有 50 镑以下的藏青连帽衫吗？”

两张图都是真实输出，来自测试用的虚构店铺和一位叫 Sam 的虚构用户。作者本人的尺码不在仓库里。

没有放进去的东西

原来的机器人还读一份英国店铺清单，里面摸清了各家店的怪癖：藏起来的库存数据、奇怪的尺码格式、哪些店会拦机器人。这份清单留在作者自己手里。免费版附带四个示例 Shopify 店铺，添加自己的店铺是三行代码的事。它也不读你的邮箱；想让搭配用上你已有的衣服，得自己列出来。

安装与运行：

1. pipx install git+https://github.com/casareanderson/clothinglab
2. clothinglab init && clothinglab onboard
3. clothinglab refresh && clothinglab digest

项目免费，采用 AGPL 协议，地址是 github.com/casareanderson/clothinglab。安装指南每周由 GitHub 在一台全新机器上跑一遍，所以它说能走通的步骤，就是能走通。

你穿多大码？在找到一件真正有你的尺码的“折扣”之前，你要划过多少条推送？