# 国外有哪些中国市场还比较少见的工具？

URL: https://caijiao.org/posts/104
Source: docs/posts/104.md
Description: 差别不在汇率换算，而在 Homewyse 把报价拆成材料、人工、总价三行（月访问 42.885 万），以及 €69 买断的桌面发票软件这种形态。

这个问题最常见的答案是"单位换算、汇率换算、PDF 工具"。这个答案几乎站不住——这几类国内早在十年前就做烂了，做的人比国外还多。

真正差得远的是另一类：**把某个行业的已知参数做成公开参考值的工具。**

## Homewyse 那三行报价，国内几乎没人敢给

Homewyse 做的事听起来没什么技术含量：输入面积和城市，输出一个装修报价。2026 年 6 月的第三方访问估算约 42.885 万。

![Homewyse 官网首页截图](/images/2026-09/homewyse.com.png)

*Homewyse 首页写着 Custom, fully detailed estimates in minutes，把自己定位成独立公允的造价参考。*

它的关键不在算准，在于结果被**拆成了三行**：材料多少钱、人工多少钱、合计多少。对业主来说这三行意味着"我知道承包商的钱花在哪了"。

国内不是没有报价工具，但绝大多数是引流表单——填完面积留个手机号，然后等三家装修公司打电话。这两条路的产品逻辑完全相反：一个是让用户自己判断，一个是把用户变成线索。后者更赚钱，所以前者没人做。

Inch Calculator 是同一思路的另一个版本：只做尺寸和工程量估算，月访问 459 万。用户想知道的是"这块地砖要切几片、缝留多大"，工具给的是一个可以照着施工的数——而不是一个电话号码。

## 英制单位既是门槛，也是护城河

这类站能成立，很大程度依赖一个我们不熟悉的前提：**英制单位加上分区人工单价**。inch、pound、gallon 这些东西让中国开发者写起来极不舒服，但反过来，它也挡住了大量临时起意的复制者。

想把这套东西搬进来，本地化的工作量远比想象中大。税率算法、社保基数、材料损耗系数、地区工时单价——每一项都需要一个可引用的公开来源，并且要跟着政策更新。这不是翻译问题，是数据维护问题。

搬到代码层，有两个坑几乎必踩。一个是单位换算本身不能靠手写常量拼接，应该做成集中的换算表，否则改一处要动十处。另一个是金额和比率别直接用浮点——0.1 + 0.2 的误差在税率页面上会被用户当场算出来金额不对，[/decimaljs/](/decimaljs/) 里那套十进制高精度处理该用就用。

计算放哪一端也有讲究。参数型估算页面用 [JavaScript](/javascript/) 在浏览器里直接算是最合理的：用户改一个数字立刻看到结果，来回调参数的过程本身就是这类工具的价值。服务端只需要吐静态 HTML。

## Cakedesk 的 €69，是另一种差别

计费方式上的差异同样明显。Cakedesk 是德国开发者 Max Schmitt 一个人做的桌面端发票应用，Electron + React + Node.js，一次性付款 €69，没有订阅。2025 年卖了 239 份新授权，约 €16000 毛收入；同年他发了 12 个版本，44 个功能请求里完成了 13 个。

一个人、€69、没有账单系统、没有客服团队。国内同功能的工具几乎清一色是 SaaS 订阅，因为订阅才撑得起投放成本。这两种形态背后是完全不同的获客结构，跟哪个更先进没关系。

## Gusto 那台免费计算器，从来不是为了赚钱

还有一个差别容易被忽略：很多国外工具本来就不是独立生意，它是主产品的入口。

Gusto 的免费时薪工资计算器，wage calculator 月搜索量 17000、页面月访问约 17776。这个页面不产生一分钱收入，但进来的人全是正在算用工成本的小企业主——他们恰好就是 Gusto 薪资代发服务的目标客户。Shopify 在 /tools/ 下放的利润率计算器也是同一逻辑，峰值月访问超过 2 万，服务的是它的电商客户。

想明白这一点，很多看起来"不赚钱"的工具站就有解释了：人家赚的不是工具的钱。反过来也提醒一件事——如果你没有主产品可以承接，纯做工具就必须自己解决变现，而展示广告这条路的天花板，terrific.tools 那个约 300 美元的首个完整变现月已经给得很清楚了。

## 30 多种语言，是页面矩阵的乘法器

Omni Calculator 值得单独看：Semrush 给出的 2026 年 6 月访问估算约 1429 万，支持 30 多种语言。它的做法是把一个计算器抽象成一组配置，页面由模板生成——公式、单位、文案、示例都是配置项。

于是页面数变成"问题数 × 语言数"。规模上去了，但技术侧要保证的也就那几件事：模板可复用、每个 URL 唯一且稳定、多语言之间用 hreflang 标注对应关系、sitemap 能完整覆盖所有语言版本的 URL。多语言 sitemap 的具体写法，[/google-search-central/04-sitemaps-robots](/google-search-central/04-sitemaps-robots) 这一节可以直接照着实现。

## 判断要不要抄，先问参数从哪来

我现在只留一条硬性筛选：**页面里用到的行业参数，能不能找到一个公开且可持续维护的来源。**

Omni Calculator 依赖的是学术公式，Homewyse 依赖地区均价，Inch Calculator 依赖英制标准。参数源不存在、或者半年一变的品类，做出来就是一堆随时失效的页面。

至于这种"给业主看参考值"的工具在国内能不能成立，我拿不准。它取决于有人愿不愿意为"我知道大概值多少"这件事贡献注意力，而在一个长期习惯免费报价、而且报价电话会马上打过来的环境里，这件事还没被验证过。

---

*流量数据来自 Semrush 2026 年 6 月估算；Cakedesk 销售与迭代数据来自作者 Max Schmitt 2025 年公开复盘。*