我花了几个月的时间构建对比表，直到我意识到我的数据库在对我撒谎。

界面看起来很完美。整洁的行、规整的勾选框，以及在工具不足之处标注的红色 X。访客们浏览着这些表格，偶尔点击一下。但在表面之下，模式（schema）正在悄无声息地破坏每一个结论。我在错误的数据之上构建了一个漂亮的 UI。

布尔值陷阱

对比页面通常遵循一种显而易见的模式。你创建一个网格，行是功能，列是产品，每个单元格存储一个布尔值。True 表示该工具具备此功能，False 表示不具备。一段时间内，这看起来很有序。但当你试图对比两个项目管理工具、三个云数据库或四个 API 网关时，网格就开始“反叛”了。

布尔值单元格无法承载细微的差别。当一个单元格显示为 false 时，它可能意味着五种完全不同的情况。也许该工具确实缺乏这项能力；也许它通过不同的机制解决了相同的问题；也许该功能存在，但被锁在了企业版付费墙之后；也许它需要一个你没注意到的插件；或者，也许你只是忘了去验证，那个红色的 X 仅仅是你自身不确定性的占位符。

这很重要，因为用户信任对比网格来做出昂贵的决策。当你将一个基于 CLI 的工具标记为“缺失实时协作功能”时，你的意思可能是它没有实时光标共享。但该工具可能通过基于分支的工作流和评审队列来实现完全相同的效果。将其标记为 false，会将一种设计选择降级为一种缺陷。如果你在二十个功能上都这样做，你并不是在对比两个工具，而是在宣布其中一个工具是坏掉的。

布尔值模式还会训练你用供应商的术语而非用户需求来思考。如果你的行名借用了行业领军者的名称，你最终会去询问每个竞争对手是否都有 Workspaces，仅仅因为 Notion 把它们称为 Workspaces。另一个工具可能称之为 Projects。第三个工具甚至没有专门的容器，但允许你对单个文件进行权限设置，直到实现相同的隔离效果。你的行名强迫每个产品都进入领军者的思维模型，这对市场巨头来说很方便，但对其他所有人都不公平。

更优的状态描述词汇

解决办法从数据类型本身开始。停止存储布尔值。存储一个带有明确词汇的状态字段。

请考虑以下六种状态。

Full 意味着该工具无需变通方法或额外购买即可完成任务。

Partial 意味着它能处理其中的一部分，或者只有在你配置了某些晦涩的设置后才能处理。这是大多数对比表隐藏不准确之处的地方。一个提供加密但仅限于静态加密（at rest）的工具应该被标记为 Partial，而不是 Full。

Different Model 意味着问题得到了解决，只是解决方式与行业领军者不同。拥有分支和评审功能的 CLI 工具属于这一类。使用只读副本而非单一池化连接的数据库也是如此。这种状态保留了产品设计的智慧，而不是因为它没有模仿竞争对手而对其进行惩罚。

Not Applicable 意味着该概念本身无法转化到此类工具中。无服务器函数平台不需要像虚拟机那样拥有持久的本地存储。在那里强行标记为 false 是类别混淆。

Absent 意味着你已经查看过了，该功能确实不存在。没有变通方法，没有插件，没有替代工作流。这种差距是真实存在的。

Unknown 意味着你尚未验证