Xiyang・Liu
返回上一页

Journey

日货决策链的心路历程

日货决策链

以下是 2026 年 7 月写的，那时候三个工具还各自为战。原文保留，没有改动。

做日本中古商品这门小生意，链条上有三个反复出现的问题：

  • 线上哪里有便宜货？
  • 站在店里，这件东西最多可以出多少钱？
  • 卖出去之后，账应该怎么记？

于是有了三个工具，一个问题一个。

它们都不是商业产品，而是为自己的实际使用做出的生产工具。每一个工具分别负责发现、判断与记录，串在一起便组成了一条从线上行情到最终入账的完整链路。

链路总览

  1. 日货雷达

    发现低于行情的商品

  2. 店铺决策

    计算店内最高出价

  3. 销售记录

    记录买卖与最终利润

日货雷达

发现低于行情的商品

是什么

跑在 Mac 上的桌面端“雷达合集”。

目前搭载的第一个雷达是日拍雷达：监控 Yahoo!オークション 上相机与镜头、手办与模型、腕表三个垂直类别的行情。

当系统发现明显低于近期行情的商品时，会将警报直接推送到手机。

使用方法

  1. 自动积累行情

    每晚固定时间采集当天成交行情并写入本地数据库，逐渐形成“某件商品通常值多少钱”的价格基线。

  2. 白天扫描在售商品

    每天分多轮扫描在售商品。当即决价格明显低于近期成交行情时，将候选商品进一步过滤，再推送到手机。

  3. 命中后即时通知

    通过 Ntfy，实现人在外面也可以实时接到通知，随时可以打开推送的商品链接，判断是否出手。

  4. 本地总览面板

    需要查看整体情况时，可以打开本地网页面板，一屏查看行情分位、监控词表和低价候选。

运作结构

核心特点：电脑在家运行，人在外面接收。

  1. 采集层

    Python 脚本限速采集公开页面，并遵守 robots 规范。成交数据与在售数据分别存入 SQLite 数据库，互相作为判断依据。

  2. 调度层

    使用 macOS 的 launchd 定时执行任务，不依赖云服务器。成交行情每晚运行一次，在售警报每天分多轮运行，Mac 本身就是服务器。

  3. 判定层

    以近半年经过净化的成交价格低分位作为基线。候选商品必须同时通过降幅比例与绝对金额两层条件。

    成色未确认的商品只记录、不推送。通过第一轮判断后，再读取商品详情，加入成色与卖家风险的第二阶段判断。

  4. 推送层

    警报通过 ntfy 推送。手机安装 ntfy App 并订阅后即可接收，不需要自建中转服务器或申请开发者账号。

店铺决策

计算店内最高出价

是什么

手机优先的网页工具。

站在日本的中古店里，输入型号后，立刻得到“这件东西最高可以出多少日元”。

它将闲鱼行情、汇率、成本与目标毛利的换算，压缩成掏出手机后几秒钟内可以完成的判断。

使用方法

  1. 店铺计算器

    在首页搜索框输入型号后筛选商品。

    选中商品后，以大字显示最高收购价，同时列出该型号的检品要点。

    价格根据以下信息实时计算：

    • 闲鱼中位价
    • 渠道费用
    • 目标毛利
    • 带回成本
    • 当日汇率

    结果向下取整。

    店内标价高于这个数字，就可以直接放下。

  2. 收购台账

    收货时当场录入，自动计算预计毛利，之后可以复盘每一批收购的质量。

  3. 店铺库与路线

    按扫店路线分组维护店铺列表。

    每家店可以一键标记“本周已去”，并于每周一重置，以配合店铺周初补货的节奏。

    也可以直接打开苹果地图或 Google Maps 导航。

  4. 附近扫店雷达

    人在外面临时起意时，授权定位后，可以搜索附近几公里内的二手店和目标连锁门店。

运作结构

核心特点：人在店里只有手机流量，也必须随时能够使用。

  1. 部署

    应用运行在香港云服务器上，使用 Flask、SQLite、nginx 反向代理和 systemd 守护，通过 HTTPS 域名访问。

    手机只需要打开网页。

    服务器位于香港，以兼顾日本与中国大陆的访问。

  2. 体验

    首次使用访问令牌鉴权并写入 Cookie，之后可以直接进入。

    通过 Safari“添加到主屏幕”后，可以全屏运行，接近原生 App 的使用体验，同时省去应用上架、签名和审核。

  3. 数据

    汇率每日从公开 API 缓存。

    超过 48 小时没有更新时，页面发出提示，避免使用旧汇率判断出价。

    附近店铺数据使用 OpenStreetMap Overpass API，并提供苹果地图与 Google Maps 搜索作为补充。

  4. 同步

    数据保存在服务器端。

    店内使用手机录入的数据，回家后在电脑浏览器打开相同网址即可继续查看，实现自然的多端同步。

销售记录

记录买卖与最终利润

是什么

本地运行的多商品、多渠道销售记录与分析工具。

它将商品档案、每一笔买卖、不同成本和销售路径集中在同一个地方，从单品、品类到整体生意，随时看清营收、利润和利润率。

使用方法

  1. 商品档案

    可以自行建立球鞋、登山用品、桌面收纳等商品大类，并为每件商品设置独立商品编码。

    每个商品可以保存：

    • 实物图片
    • 销售用图片
    • 中文商品名称
    • 日文商品名称
    • 英文商品名称
    • 商品介绍
    • 营销文案

    同一商品需要在多个平台上架时，可以直接复用已有资料。

  2. 逐笔记录买卖

    同一商品可以连续记录多笔不同交易。

    每笔记录可以输入：

    • 售价
    • 数量
    • 进货成本
    • 其他成本
    • 销售平台
    • 销售路径

    系统根据录入数据自动计算每笔交易的收入和最终利润。

    不要将“一件商品”限制成只有一个固定售价或一条销售记录。

  3. 分层分析

    数据可以从三个层级查看：

    • 单品层面：查看某一商品实际卖了多少、赚了多少。
    • 品类层面：比较哪些商品大类销售表现更好。
    • 整体层面：查看总营收、总利润、利润率和不同渠道的表现。
  4. 搜索与复盘

    可以通过首页搜索商品编码或名称，快速找回商品档案。

    结合历史交易记录，可以复盘下一次的定价、补货和销售渠道选择。

运作结构

  1. 本地使用

    这是为本人日常买卖管理制作的自用软件，核心目标是随时记录和复盘实际销售，而不是面向外部用户提供服务。

  2. 商品与交易分离

    商品档案负责保存长期不变或可复用的信息；销售记录负责保存每一次真实交易。

    同一商品可以对应多条销售记录。

  3. 自动统计

    营收、成本、利润与利润率均从实际交易记录自动汇总，不需要再次手工输入统计结果。

  4. 素材与多语言资料

    商品图片、三语名称和销售文案与商品编码绑定，方便在不同销售平台之间重复使用。

三个工具串起来，就是一条完整的日货决策链：

  1. 日货雷达发现机会
  2. 店铺决策判断最高出价
  3. 销售记录完成买卖入账

数据在链条中逐步积累，每一环都让下一次判断更准确一点。

从三个工具到一条链

上面这三个工具，不是一起做的，也不是为同一件事做的。

日货雷达最早只是不想每天手动刷雅虎；店铺决策是因为有次在店里对着一台相机想了十几分钟，最后没敢下手，回家一查才发现那个价其实很划算；销售记录做得更早，本来是拿来记球鞋的。

三件事各有各的来由，写的时候谁也没想着谁。真正让我意识到它们是一条链的，是用起来之后——

在雅虎上看到一个价，我得开第二个工具去查这个型号该出多少；东西买回来，再开第三个记一笔账。想知道"这台我以前是不是收过、上次卖了多少"，就得在三个界面之间来回翻。同一件东西，在三个地方各留了一份不完整的记录，谁也不认识谁。

站在店里、手上拿着一台相机的时候，这个来回是最要命的。

发现、判断、入账——它们本来就首尾相接，只是被我拆成了三段在过。

后来的事写在下面。

2.0 开发故事

  1. 最难的不是写界面，是先把数据讲清楚

    三个工具用了三套写法，数据格式互不相认。但真正卡住的不是格式，是口径。

    雷达算价格基线的时候，中间有一整条过滤链：去掉配件、去掉不相干的型号、去掉状态说不清的。我一开始图省事，直接查原始数据表看分布，得出的结论跟系统实际在用的那一份完全对不上——我以为它被配件污染了，实际上根本没有。

    从那之后立了条规矩：任何一个数字，先确认它是不是系统真正在用的那一份，再下结论。 这条规矩后来救了很多次。

  2. 一个藏了很久的错

    手表那一类原本设了个五万日元的价格上限，超过的成交不计入基线。那是很早随手加的，本意是挡掉离谱数据。

    去掉它之后，有一个型号的中位价从 8650 円跳到 89000 円——十倍。也就是说这个型号的基线一直是错的，而且错得离谱：它绝大多数成交本来就在五万以上，帽子把上半截全砍了，剩下的只是零头。

    更麻烦的是它不显眼。中位数对裁剪天生不敏感，看上去一切正常；被拖偏的恰恰是用来判断出价的那两个分位数——也就是我真正在看的那两个。

    改法最后定成：每个型号按它自己的价格带，两头各去掉 5%。不设固定金额，市场涨了它跟着涨。全部型号照新口径重算了一遍。

    现在打开任何一个型号的行情区，往下拉能看到"历史基线"那一栏，里面留着旧口径那一行，注明"含 5 万上限"。留着它不是为了纪念，是为了随时能对照——一个数字改过之后，得知道它以前是什么样。

  3. 数据不搬家

    面板要同时读三份数据，最省事的做法是复制一份到自己这边。没这么做。

    复制的代价比看上去大：两份数据一定会不同步，而到那一天，你分不清哪份是对的。所以面板一行数据都没复制，每一次读都从原处转发——慢一点，但永远只有一个真相。

    销售记录那个库还有个额外的麻烦：它是纯本机自用的，从来没做过鉴权。面板要用它，就必须保证它那个端口一步不出本机——所有请求都经面板的后端转一手，外面永远碰不到它。这一条后来每改一次都要重新验一遍，因为漏掉一个口子，那些商品照片就直接裸在公网上了。

  4. 店里那三十秒

    面板是给店里用的。这句话决定了很多看起来无关的细节：

    界面上不出现术语，分位数就叫"低中高"，判据用白话写在旁边；数据一次全下发，筛选在手机本地做，点下去没有等待；门用自己写的口令加半年 Cookie，而不是更规范的企业级登录——后者每次过期要等邮箱验证码。站在店里，手上拿着一台相机，店员在旁边看着，那半分钟等不起。

  5. 改了十七批

    面板不是一次做完的，是一批一批磨出来的：先把数据接通，再把功能一块块搬过来，最后拿原来那三个工具的界面逐条对照，看还差什么。

    最后那次对照查出十一处缺失，七处集中在同一个地方——交易记录。原因也很实在：那部分我用得最多，所以最先做，做的时候还不知道整个东西后来会长成什么样。

  6. 结尾

    现在这条链能从头走到尾了。

    它没有让我赚到更多钱——它只是让我在店里掏钱之前，比以前多知道一点。