审核才是功能

我对自己的 AI 功能做了一件“不该做”的事：给它做了基准测试。它输了。

十二份来自公开 Nutrition5k 数据集的称重餐食，交给我正在为 Dayplan 开发的餐食照片功能——只有照片，没有标签、没有重量、没有任何提示。只有五项热量估算与参考值的偏差在 20% 以内。模型为十一份餐食给出了完整的营养数据，第十二份则因为无法识别其中的蛋白质而拒绝给出结果。已完成估算的平均热量误差为 31.9%。宏量营养素更糟——碳水化合物只有一次落在 20% 以内。

一次运行，一个小规模的固定子集。这是一条基线，不是一次验证——但它是实际测量出来的基线，而那些失误比平均值更能说明问题：

• 一盘普通糙米实际重 112 克。模型说是 150 克，外加“一些无法识别的东西”。分量，就是披着小数点外衣的猜测。
• 葡萄被认成了圣女果。热量总数几乎是对的，而这本身就是个警示：数字看起来合理，不代表食物认对了。
• 一份沙拉被识别成了绿叶菜：14 千卡，参考值却是 52——浆果、燕麦脆和油醋汁全都藏起来了。

最有诱惑力的做法是去追这个数字：更好的提示词、更好的模型、再等一年。也许吧。但当一个模型有三分之一的概率出错时，产品要回答的问题不是“怎么让它对”，而是“怎么让出错的代价变小”。

所以在 Dayplan 里，照片生成的从来不是记录，而是草稿：食材、预估分量、营养总计，以及模型想问的问题——这十二份餐食一共产生了 36 个澄清问题。我可以纠正食物种类、调整克数、回答问题并请它重新估算；它会展示修改前后的对比，并保留我的手动修改。当食物认对了、但数字值得更可靠的来源时，可以用 USDA 数据库的匹配结果替换掉猜测。这一切之后，才会真正保存。而当模型认不出某样东西时，它会直接说“未知”，并拒绝给出总计——被拒绝的第十二份餐食不是一次失败，而是系统拒绝编造。

这些都不会让最初的估算变得更准确。我在开发记录里写过这一点，现在依然成立。审核这一步真正做到的，是让错误变得廉价：一次糟糕的估算只需要我改一次，而不是悄悄污染我日后会信任的几周数据。

这也是这些数字出现在博客里、而不是锁在抽屉里的原因。每个 AI 功能发布时都带着演示视频，却很少有谁附上自己的误差表。如果你在决定要不要信任某个功能——包括我的——你应得的是测出来的数字，而不是营销里的数字。等纠正工具更成熟后，我会重新跑这个基准测试，并把结果也发出来。无论变好还是变坏。

Dayplan 仍然运行在我的开发服务器上，用我自己的三餐做测试。模型负责猜，我负责审。审核才是功能。