376 条里只有 30 条勾了「支持中文」：这一栏记的不是你以为的那件事
为什么 ChatGPT 与 Claude 在这栏是 false、Gemini 是 true；为什么 30 条里有 29 条不是中国厂商；以及「界面有中文」「能用中文下指令」「中文输出好用」其实是三件事。
口径（2026-09-18，对 376 条已发布记录跑一次）：`chineseSupported`、`openSource`、`hasApi` 都是布尔字段，直接数 true；分类是 `primaryCategory`；厂商归属是 `region`。30 / 346 与「29 / 30 的 region 不是 cn」都由同一次统计得出，`npx tsx` 里 `import { tools } from "@/lib/tools"` 即可复算。字段口径本身在 `src/lib/tool-schema.ts` 的注释里（本轮写入），历史判断见 `docs/upgrade/05-free-tools-traffic.md:123`。「三家都能读写中文」这句不是站内数据，是我们对公开页面的读法，不构成质量结论。模型类数据基准日期：2026-09-15（数据集更新后此日期与正文数字一并复核）
先说结论：这一栏是「页面写明了」，不是「能用中文」
站内的 chineseSupported 只有 30 条为真，346 条为假（8%）。把这 30 条当成「能用的中文工具」清单，
是这一栏最容易被造成的误读——而且是我们自己造成的，所以这篇把它讲清楚。
一、30 条长什么样
- 按分类：对话 9、视频 6、平台 3、数据 3、Agent 2、写作 2，图像 / 音频 / 搜索 / 设计 / 销售 各 1。
- 按厂商归属：30 条里有 29 条的
region不是cn（站内 region 分布是 global 373、cn 2、both 1）。 所以「勾了支持中文」几乎不等于「中国厂商」，它是两件毫不相干的事。 - 打勾里
openSource为真 4 条、hasApi为真 8 条——没有「开源的都支持中文」这类规律，别去脑补。
最能说明问题的两个反例在同一个分类里：chatgpt 与 claude 是 false，gemini 是 true。
这三家都能读写中文，差别只在页面有没有把「中文」当成一项承诺写出来（Gemini 的中文说明写在功能里，
OpenAI 与 Anthropic 的公开页面当时没有把语言列表写成对消费者的承诺）。
二、这一栏的口径（本轮起写进了代码注释）
我们把口径定成一句可复核的话：只有在厂商自己的页面上读到「支持中文 / 语言列表含中文」这类明确表述，才置 true。
- 好处：任何人打开那个页面都能验，写歪了能被指出来。
- 代价：页面没写 ≠ 产品不行，于是出现上面那组反直觉结果； 而「我们都试过、确实好用」这种判断我们不写进去，因为它依赖某个人的语感，写进目录就等于让它失去可复核性。
- 这个口径以前只存在于编辑习惯里，2026-09-18 起写进
src/lib/tool-schema.ts的字段注释： 它记的是「页面写明」，不是「能不能用中文」，更不是「国内能不能访问」—— 最后这一层复用早就被否掉过（docs/upgrade/05-free-tools-traffic.md第 123 行：语义不成立，需另建数据集）。
三、真正的三件事
把「支持中文」拆开，你会发现自己关心的是第三件：
| 说法 | 谁负责 | 目录能不能记 |
|---|---|---|
| 界面有中文 | 前端做了 i18n | 能（我们没单独记） |
| 能用中文下指令 | tokenizer 与模型训练语料 | 勉强能，但没人写清 |
| 中文输出对你的领域好用 | 模型 + 你的提示词 | 不能，只能你测 |
第二件有个可量的影子：中文与英文在同一个 tokenizer 下不是一回事，同样一段需求，中文常常更贵。
用 /free-tools/token-counter 把两段同义指令各数一次就知道差多少，这个差价是你月度账单的一部分，
而它跟「界面有没有中文」毫无关系。
四、3 分钟自测（拿你自己的任务，别拿我们的字段）
- 同义指令对照：把你要它做的一件事分别用中文与英文写，各跑一次。看两件事：结果是否可用、token 数差多少。
- 塞一段真实材料：把你的中文需求文档、工单或合同片段放进去，用
/free-tools/context-window-visualizer看它占掉的上下文比例。中文材料吃上下文的速度，是你选长上下文还是选短上下文模型的真实依据。 - 要结构化输出就直接测：用
/free-tools/function-calling-generator生成一份 schema，让模型把中文文本填进去， 看键名与值里的中文有没有被改写成拼音或英文——这一项在生产里最常坏，而它不会出现在任何目录字段里。
三步做完大约三分钟，得到的结论比「某栏打了勾」可靠得多。
五、这套字段管不了什么（诚实边界）
- 这一栏不该被当排除条件用。如果你用筛选器勾掉 346 条，你会排掉大量中文完全可用的产品； 这是我们最不想造成的误用，所以口径写进代码注释、并且在这里说明。
- 我们不测中文输出质量，也不引用厂商自己的中文跑分当结论。
- 页面写了「支持 100+ 语言」的，我们记 true；这不表示它对中文做了任何专门优化。
一句话版本
「支持中文」这一栏回答的是「厂商有没有把这句话写出来」，不是「你用它写中文好不好用」。 前者我们能替你抄，后者只能你自己花三分钟测。
常见问题
- 既然会误导，为什么不干脆去掉这一栏？
- 因为另一批决定确实需要它：做中文语音转写、中文配音、中文合同审阅的人，会优先看那些把语言承诺写在页面上的产品——那一栏对这些条目是有信号的。删掉它会让「厂商自己写明了」这个信息一起消失。我们的处理是保留字段、把口径写进代码与文档，并明确它不能当排除条件用。
- 为什么不用「我们试过」来补齐那 346 条？
- 那样这条目录就从「可复核的抄写」变成「一个人的语感」。语感会变、也不解释它是怎么测的：什么提示词、什么领域、什么长度。我们要读者能重做验证，所以宁愿留 false 并说明 false 的含义是「页面没写」，而不是「不能用」。真要判断能不能用，第四节那三分钟比我们的勾可靠。
- 「支持 100+ 语言」这种写法你们怎么记？
- 如果语言列表里明确列了中文，记 true；只写「100+ 语言」而没有列表，记 false 并在描述里保留原文。理由同上：我们只抄可核对的那半句。「100+」这句话对中文使用者几乎不含信息量——它既可能包含简体中文，也可能只有繁体或经由翻译层，这几种情况在界面上长得一样，在成本与质量上不一样。
接着读
延伸阅读：这些条目可以直接开通
- DeepSeek R1 深度求索免费使用 / 按Token计费站内标了中文支持的对话类记录之一：定价串是「免费使用 / 按Token计费」。前往官网
Only 30 of our 376 records tick 'Chinese support' — the column does not mean what readers assume
Why ChatGPT and Claude read false while Gemini reads true, why 29 of the 30 ticked records are not Chinese vendors, and why UI localisation, Chinese prompting and good Chinese output are three separate claims.
Rules (2026-09-18, one pass over the 376 published records): `chineseSupported`, `openSource` and `hasApi` are booleans counted as true; category is `primaryCategory`, vendor origin is `region`. The 30 / 346 split and '29 of 30 are not region cn' both come from that single pass — reproduce it by importing `{ tools } from "@/lib/tools"` in `npx tsx`. The marking rule itself lives in the comment on `src/lib/tool-schema.ts` (added this pass); the earlier decision is recorded at `docs/upgrade/05-free-tools-traffic.md:123`. The sentence about all three vendors reading and writing Chinese is our reading of public pages, not site data, and it is not a quality verdict.
The short version first: this column records 'the vendor stated it', not 'Chinese works'
Only 30 of our records have chineseSupported = true; 346 are false — 8%. Treating those 30 as 'the list of tools
that work in Chinese' is the most common misreading of this field, and it is a misreading we enabled. This article
closes that gap.
1. What those 30 records look like
- By category: chatbots 9, video 6, platforms 3, data 3, agents 2, writing 2, and one each for image, audio, search, design and sales.
- By vendor origin: 29 of the 30 do not have
region = cn(site-wide the split is global 373, cn 2, both 1). So ticking 'Chinese support' almost never means 'Chinese vendor' — those are unrelated facts. - Within the ticked set, 4 are
openSourceand 8 havehasApi. There is no pattern like 'open source means it supports Chinese'; do not invent one.
The two best counter-examples sit in the same category: chatgpt and claude are false, gemini is true. All
three read and write Chinese. The difference is only whether the vendor's own page states it: Gemini lists Chinese
among its capabilities, while the OpenAI and Anthropic pages we checked did not present a language list as a
consumer-facing promise.
2. The rule we use (now written into the code)
The rule is one falsifiable sentence: we set it true only when we read an explicit statement — 'supports Chinese', or a language list containing Chinese — on the vendor's own page.
- What that buys: anyone can open that page and check us; if we got it wrong, it can be pointed out.
- What it costs: 'not stated' is not 'does not work', which is exactly the counter-intuitive pair above. We do not write 'we tried it and it was fine', because that depends on somebody's language intuition, and putting an intuition into a directory removes its checkability.
- Until now that rule lived only in editorial habit. On 2026-09-18 it was written into the field comment in
src/lib/tool-schema.ts: the column records 'the page says it', not 'can you use Chinese', and definitely not 'reachable from mainland China' — reusing the field for that was rejected earlier (docs/upgrade/05-free-tools-traffic.md, line 123: the semantics do not carry, a separate curated dataset is needed).
3. Three different claims that share one name
| Claim | Who owns it | Can a directory record it? |
|---|---|---|
| The UI is localised | their frontend i18n | yes (we do not track it separately) |
| You can prompt in Chinese | tokenizer plus training mix | barely, and nobody states it |
| Chinese output is good for your domain | the model plus your prompt | no — only you can test this |
The second row has a measurable shadow: Chinese and English are not equivalent under the same tokenizer, so the same
request written in the two languages costs different amounts. Count both with /free-tools/token-counter and you have
a number that belongs in your monthly bill — and has nothing to do with whether the UI is localised.
4. A three-minute self-check (use your task, not our field)
- Run the same request twice, once in Chinese, once in English. Judge two things: is the result usable, and how many tokens did each take?
- Feed it real material. Paste your Chinese requirements doc, ticket thread or contract clause, then use
/free-tools/context-window-visualizerto see how much of the context window it consumes. That ratio, not a marketing claim, decides whether you need a long-context model. - If you need structured output, test it directly. Generate a schema with
/free-tools/function-calling-generator, have the model fill it from Chinese text, and check whether keys or values get transliterated into pinyin or English. This breaks most often in production and appears in no directory field anywhere.
Three minutes, and the conclusion beats a ticked column.
5. What this field cannot do (stated plainly)
- It must not be used as an exclusion filter. Filtering out the 346 records drops a large number of perfectly usable products; that is the misuse we least want to cause, which is why the rule is now in the code comment and explained here.
- We do not benchmark Chinese output quality, and we do not quote a vendor's Chinese-language scores as conclusions.
- A page saying 'supports 100+ languages' gets a true. That says nothing about any specific optimisation for Chinese.
One-sentence summary
'Chinese support' answers 'did the vendor write that sentence down', not 'will it serve you well in Chinese'. The first half we can copy for you; the second takes three minutes at your own desk.
FAQ
- If it misleads, why not just delete the column?
- Because a different set of decisions genuinely needs it: someone doing Chinese speech transcription, dubbing or contract review will prioritise products that publish a language promise, and for those records the column carries signal. Deleting it would throw away 'the vendor stated this'. Our handling is to keep the field, write the rule into code and docs, and state plainly that it must not be used as an exclusion filter.
- Why not fill the other 346 with 'we tried it'?
- That would turn the directory from a checkable copy into one person's language intuition. Intuition drifts, and it never explains its own method: which prompt, which domain, which length. We want readers able to redo the verification, so we prefer leaving false and defining it as 'not stated on the page' rather than 'does not work'. For the real question, the three minutes in section four beat our tick.
- How do you treat 'supports 100+ languages'?
- If a language list explicitly includes Chinese, we set true; if it only claims '100+ languages' with no list, we set false and keep the original wording in the description. Same reasoning: we copy only the checkable half. For a Chinese reader '100+ languages' carries almost no information — it may mean Simplified Chinese, Traditional only, or a translation layer, and those look identical in the UI while differing in cost and quality.
Where to go from here
- DeepSeek R1Free / Pay-per-tokenOne of our ticked chat records; its price string reads '免费使用 / 按Token计费' (free to use, billed per token).Open the site