为什么我们拒绝编数据
本文首发于 RoboParts 机器人零件兼容性判定层。文中的规模数字取自
onboarding_block.facts()现算，不做美化。
如果你去看任何一个零件数据库，会发现它们有一个共同点：字段是满的。
每一款电机都有功率、每一款传感器都有量程、每一款夹爪都有行程——看起来完整得让人放心。但你有没有想过：那些空着的、厂商官网都查不到的字段，它们是怎么变满的？
答案是：靠推断填的。同系列小一号的型号是 50mm 法兰，那大一号的也按 50mm 填；同厂商上一代是 CAN 总线，这一代也按 CAN 填。填的人不觉得有问题，因为「看起来合理」。直到你按这个数据买了一批货，发现装不上。
RoboParts 做了一个反方向的选择：我们公开登记答不出来的部分。
一、三态，不是二态
大多数兼容性判断只有两个答案：兼容 / 不兼容。这是一个二态系统，它假设「所有问题都能回答」。
但真实世界不是。拿我们的机械接口数据举例：在 868 个实体里，大量零件的机械接口是厂商从未公开的。这时只有三种诚实答案：
| 状态 | 含义 | 我们的处置 |
|---|---|---|
| 是 | 有出处证明可装 | 判 compatible |
| 否 | 有出处证明不可装（如电压区间不重叠） | 判 incompatible |
| 不知道 | 厂商未声明，或我方词表不认识 | 判 null（无法判定），不猜 |
关键在于第三态。一个二态系统必须把「不知道」压成「是」或「否」其中之一，两种压法都会害人：
- 压成是 → 假绿。用户以为能装，买回来装不上。
- 压成否 → 假红。用户以为装不上，排除掉一个本来可用的选项。
我们选择第三种：null，并告诉你为什么是 null。
这不是技术做不到，是立场选择。
二、我们为此付出的代价
诚实是有成本的，而且成本很直观：
- 我们的机械接口声明率很低——大量条目显示
not_declared。 - 我们的兼容性矩阵大量格子是空的（unknown），看起来远不如竞品"完整"。
- 我们的 BOM 检查器经常输出「无法判定」，而不是干脆的「兼容 / 不兼容」。
任何一个做增长的人看到这个数据都会皱眉：用户要的是答案，不是「我不知道」。
但我们的判断是：一个敢说「我不知道」的数据源，比一个把所有格子填满的数据源更可信。 因为后者填满的格子里，有相当一部分是猜的——而你无法分辨哪些是猜的。
三、三个可验证的事实（不是口号）
我们不是靠"态度好"来自证的，下面三条都可以被外部复核：
- 跨厂商可直接横向比较的 A 级条目为 0 条。 行业普遍不声明测试条件，我们公开登记这一事实，而不是假装参数可比。
- 每个实体都带
source_tier（A/B/C）与confidence。 Tier A = 可点开复核的一手来源；Tier C = 无溯源，confidence 上限被硬性压低。 not_declared是显式缺口，不是字段缺失。 它能被 API 查询、被 Agent 读到——下游可以据此判断"这条结论有多少证据"。
四、为什么这构成壁垒
厂商自建选型器永远做不到这一点。
一个卖关节的厂商，它的选型器如果诚实地说「我这个型号的法兰孔位数据没有公开」，等于劝你别买。卖家不适合同时当裁判——一旦选型结果关系到自家销量，中立就没了。
RoboParts 不生产、不销售、不代理任何零部件。所以我们没有把结论导向某个产品的动机。这是我们唯一无法被复制的位置，也是我们敢留空的原因。
五、这对你意味着什么
如果你是工程师：
- 看到
null/unknown，请不要读成"不兼容"。它是"我们不知道"，需要你自己去厂商文档确认。 - 看到 Tier C 的条目，请把它的参数当"参考"而非"事实"。
如果你在接入我们的 API / MCP：
- 请把三态如实透传给你的用户，不要在你的 UI 里把
null渲染成false。那等于把我们辛苦保住的信息又丢掉。
结语
在一个用"数据量"当卖点的行业里，说"我不知道"是最不讨喜的答案。
但兼容性判定这件事，本质上是帮人避免打样返工的。一个猜错的"兼容"，比一个诚实的"不知道"，代价高得多。
所以我们继续留空。
RoboParts 是机器人零件兼容性判定层。代码 MIT，数据 CC BY 4.0。我们不生产也不销售任何零件——所以没理由骗你选一个。