工作原理
这是做什么用的工具、为什么不能靠自己去查、以及每天早上会以什么形式送到手上。关于内部机制的说明，放在这之后。
「从网上取数据」听起来简单。难的不是取到，而是取到的数字能被信任。
一句话
每天早上，告诉您这件商品现在由哪家公司在卖、卖多少钱，并附上证据。
不是"大约 12 万日元"，而是：A 公司 ¥118,000、B 公司 ¥134,800、C 公司 ¥109,500，页面在这里，今早 6 点读取，使用的汇率是这个。
为什么"大约"不够用
经常有人来问价格。而绝大多数答案返回的是行情均价。
均价是正确的数字。只是据此无法做任何决定。
- 与供应商谈判时，需要知道是谁、多少钱
- 是否下调自家售价，取决于是否真的存在一个正在抢走生意的对手
- 是否出海销售，取决于当地实际卖多少钱
"大约 12 万日元"，这三件事一件也没回答。
为什么不能自己去查
能查。查一次的话。
有两个障碍。
① 100 件商品 × 5 个网站，每天早上查一遍，这不是人干的活
打开 500 个页面、抄下价格、和昨天比对。一天做不完。而且不是每天做就没有意义——昨天多少钱，没记下来就永远拿不回来了。
② 站在自己的国家，只能看到自己国家的价格
这一点最难说清楚，所以慢慢讲。
同一个网址，从哪里打开，返回的内容就不一样。 价格不同、货币不同、有货无货不同，排序、运费、促销也都不同。
这不是什么把戏，而是再普通不过的事——给日本来的访客显示日本的价格，商店本来就是这么做的。
也就是说：坐在东京的电脑前，您永远看不到竞争对手给德国客户显示的价格。
我们经由您指定国家的服务器打开页面，可以同时从多个国家读取同一个页面并并排呈现。
"问 ChatGPT 不就行了吗"
这个问题常被问到。我们实测过，结果如下。
| 询问对话式 AI | "两个市场水平大致相当" |
| 同日同商品实测 | 美国市场比日本高 17% |
有意思的是后面。AI 给出的两个数字，都是真实且正确的值。 一个是回收价，另一个是市场指数。
它把性质完全不同的两个量并列相减，而回答中任何地方都没有说明这个区别。 仅这一点差异，就会让差价的正负号反过来。
这不是模型好坏的问题。下面五点，换个问法都填不上。
- 返回的是"行情"，不是"卖家"——是正确的答案，但不是能据以行动的答案
- 只能从它所在的位置看——不存在"请从圣保罗的角度看"这样的提示词
- 不说数字从哪来——所以您无从发现错误
- 它没有"昨天"——没人保存过，事后也买不到
- 每次问，答案都不同——上周的材料和这周的材料无法比较
这是在说明 AI 是用来做什么的，而不是在批评它。 读取特定页面、从特定国家、在特定时刻，并留下记录——那是另一件工作。
每天早上收到的东西
每一行都附带以下全部内容。
| 销售方 | 页面上显示的卖家原文 |
| 价格（不含税） | ¥118,000 |
| 与上次之差 | −¥4,200 |
| 与自家比 | +8.6% |
| 读取国家 | 经由了哪个国家的服务器 |
| 页面网址 | 实际读取的页面 |
| 取得时刻 | 2026-08-22T02:20:04.756Z |
| 汇率 | 采用的汇率，以及该汇率本身的公布日 |
这些字段不可拆分。 不是选配、不是高价套餐，一定全部附带。
理由只有一个——没有出处的价格，在会议上守不住。 汇报"竞争对手是 10 万"，被追问"哪来的？""什么时候的？""含税还是不含税？"，答不上来，那份材料就再也不会被使用。
送达方式有四种：画面（今早的表格）、CSV、每日早间邮件、Webhook。
最不起眼、却最要紧的地方
假设每天都去读取竞争对手的网站。某天早上对方改版了，读取失败。 返回的数据是"0 条"。
如果做得粗糙，就会这样汇报："竞争对手一夜之间全部售罄。"
在数据上，"取得失败"和"全部售罄"的形状完全一样。 而且这是会让人真的采取行动的数字。
我们的做法：
- 先确认该信息源今天是否正常应答。 未应答的信息源，其在架商品不纳入下架判定
- 只消失一次不判定为成交。 仅仅是排序变化导致消失，是日常现象
- 拒绝就记录为拒绝。 不把"请求过于频繁"变成"内容为空的成功"
并且读取失败的信息源会被指名 ——画面上、CSV 里、邮件中都会出现。默默丢掉的话，比上周更短的清单会被读成"市场萎缩了"。
以下是机制的说明
1. 从哪里看
页面会因为「谁在看」而改变样貌。
同一个商品页，从日本看是日元、有货；从美国看是美元、缺货。搜索排序不同，同意横幅不同，AI 提到的公司名也不同。
所以请求必须从那个国家的地址发出。 每个请求都可以指定国家，我们就从那里读取。
2. 怎么读 —— 从便宜的层开始
| 层 | 做什么 | 费用 |
|---|---|---|
css | 读取你提供的选择器 | 无 |
structured_data | 读取站点已经公布的 JSON-LD / OpenGraph | 无 |
llm | 把页面描述给模型 | token |
后面的层只填补前面留空的部分，而只要你不要求 llm，模型就不会被调用。 大多数商品页靠前两层就够了。
这既是成本问题，也是可复现性问题：选择器和结构化数据，对同一个页面返回同样的结果。
列表按行返回
我们不按列返回数组。一张卡片缺了价格，那一个数组就短一位，之后所有配对全部错位，而且不会报错 —— 你会得到一张由真实商品名和真实价格组成、却分属不同商品的表。下游无法检测。
按行返回时，缺失的字段是该条记录内的 null，前后各行依然对齐。
3. 一起返回什么
只有数据，在会议上守不住。每一行都带有：
seller | 页面上公布的卖家原样 |
url | 读取的页面 |
retrieved_at | 读取时刻 |
fx_rate / fx_published_on | 所用汇率，以及该汇率本身的公布日期 |
price_ex_tax_jpy | 统一为不含税的价格 |
level / attempts | 产出该值的层，以及尝试过的所有层 |
税制换算在采集时一次性完成，比较只读那一列。 把含税的日本价格与不含税的香港价格相减，曾产出「香港便宜 12.9%」的报告。真实差距是 4.3%，而且有些商品在对方市场反而更贵 —— 错的不只是幅度，是正负号。
4. 在发布之前停下
上述错误不会抛出异常。它们会生成看起来合理的数字。 所以我们放弃了「人会发现」这个前提，把每一个都变成可执行的检查。
报告生成前要通过 31 项检查，任何一项失败就不生成。 当检查在正确的数据上失败时，我们修检查，而不是放宽它。
我们拒绝做的
不伪装指纹。不绕过验证码。不绕过登录。不超过对方声明的限制。不从所读取的页面采集个人信息。
除了原则，还有生意上的理由：一旦被某个来源拒绝，就再也读不回来了，而损失落在每一位需要它的客户身上。
最后更新 2026-08-21
最后更新