# Jev 1.14 的边界框没有“找不到”这个选项

**Summary:** Jev 1.14 新增实验性图像定位，但 Box 类型即使目标不存在也返回坐标。我会把存在性检查和位置查询拆开，在让裁剪驱动自动化之前先测缺失目标。

- Canonical: https://markhuang.ai/zh/news/jev-1-14-bounding-box-no-not-found
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-10-14
- Section: News
- Tags: Jev 1.14, TypeSafe AI, 计算机视觉, 边界框, AI 可靠性
- Source: [TypeSafe AI](https://typesafe.ai/blog/jev-1-14)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一个发光的矩形框住了桌面上的空白区域，蓝色杯子在框外](https://cdn.markhuang.ai/news/jev-1-14-bounding-box-no-not-found/hero.webp)

*概念插图：一个精确的矩形框住了空白区域。Box 类型把存在性判断留给了另一个问题。*

[TypeSafe 的 Jev 1.14](https://typesafe.ai/blog/jev-1-14) 新增了实验性图像支持、边界框类型和更长的上下文窗口，附带一些模型改进。[模型文档](https://docs.typesafe.ai/models)显示 Jev 1.14 于 2026 年 10 月 14 日上线。Box 文档里有个细节让我停下来看：你问一个图片里根本不存在的目标，模型照样返回一个矩形。

Jev 用类型约束决策这个方向我挺认同，但这个设计也给了应用层一个新的犯错机会。程序可以消费一个结构完整的返回值，完全没意识到请求的目标压根不在图里。在让 Box 裁剪图片或驱动后续动作之前，我会把"在不在"和"在哪里"拆成两个独立判断。

TypeSafe 把实验性质写得很明白。图像和 Box 需要带上 `TypeSafe-Danger-Zone-Images: true` 请求头，官方也表示这些功能还没达到生产标准。输出类型再稳定，也不代表背后的实验能力可以无人值守地跑。

## 矩形不怕目标消失

[Box 文档](https://docs.typesafe.ai/go/box)说得很清楚：一个问题返回一个答案，四条边用图片宽高的比例表示，附带置信度。没有"未找到"这个选项。TypeSafe 的建议是另外问一个 Noul 问题——他们的"是/否"问题类型——判断目标是否可见，置信度低就忽略 Box。文档也承认目前没有推荐的 Box 置信度阈值，开发者得拿自己的图片反复调。

这个契约我能接受。位置问题回答"在哪里"，存在问题决定"那个位置值不值得关注"。陷阱在于把坐标的存在当成目标存在的证据。想象一个原型在裁剪产品照片里的杯子：杯子根本不在，坐标照样传给下游，一块空白区域就变成了"成功提取"。

这延续了我[之前分析 Jev 时](https://markhuang.ai/news/jev-schema-guarantee-wrong-decision)的判断：类型合法不等于决策正确。一次错误的裁剪可能把另一个步骤需要的证据都裁掉了，而那个步骤本来可以发现错误。

我的原型会同时问存在和位置两个问题，然后让应用层决定要不要接受结果：

```mermaid

flowchart LR
    A[图片和目标名称] --> B[锁定 Jev 1.14 并启用图像]
    B --> C[存在性回答]
    B --> D[Box 和置信度]
    C --> E{应用层检查}
    D --> E
    E -->|不存在或不确定| F[忽略 Box 或请求人工复核]
    E -->|通过已测试的阈值| G[生成候选裁剪]
    G --> H[下游使用前再次检查裁剪]
```

即便目标确实在，最后这一步检查也不能省。TypeSafe 的测试数据显示，用四条独立的边缘问题检查，36 个故意裁剪的画作里抓到了 30 个；单一完整性问题只抓到 26 个。这只是厂商自己的小规模测试，但它点出了一个有用的失败模式：找到正确的对象和保留它的全部内容，是两件事。无论测哪一种，我都会把原始图片留在手边。

## 组合能力带来便利，也需要纪律

[图像文档](https://docs.typesafe.ai/go/images)允许图片出现在状态、问题的指令或判定条件里。示例本身可以成为决策界面的一部分：原型可以把一个场景和参考照片做对比，或者用图片来定义允许的选项。图像输入在 Jev 1.13 和 1.14 上都能用；Box 需要 1.14。

设计大型请求之前，我会先把引用规则读清楚。上传一次图片不代表模型只看到一次——每次引用它，展开后的请求里就多一份副本。文档建议把多个问题共享的图片放在状态里，然后引用那个字段。我会先把请求结构定下来，再假设一次上传能让多次视觉检查变得便宜。

公开讨论也指向一点：保持每个检查的职责明确。Hacker News 上有一个[关于 Jev 文档审阅 demo 的帖子](https://news.ycombinator.com/item?id=50068443)，评论者在争论额外调一个模型到底是在捕捉有用的语义问题，还是在重复用代码就能做好的校验。那个帖子并没有评估 Jev 1.14，但里面的区分在这里同样适用：匹配请求的对象、定位它、决定应用该做什么，是三件不同的事。

## 更长上下文是另一个实验

这次发布还通过 `TypeSafe-Danger-Zone-Long-Context: true` 开放了更长上下文。模型文档列出的默认上限是每次请求 64k token、每个问题 32k token；打开这个头之后，两者都变成 262k。TypeSafe 表示这个模式的 token 单价不变，但速度更慢，准确度也低于默认范围。

我会把这项变化和图像支持分开评估。更大的上下文空间可能让原型携带更多参考资料，但它也改变了我在什么条件下信任决策结果。如果在第一个实验里同时引入新模型、图像和更长上下文，一旦出现回归问题就很难定位原因。

我也会保持模型版本固定。发布说明提到 `jev-latest` 会在一周后切到 1.14，但我查看的文档里它仍然指向 1.13，`jev-preview` 才指向 1.14。TypeSafe 建议在针对特定模型调好阈值后使用带版本号的 ID。我会在原型里锁定 `jev-1.14.0` 并记录返回的模型 ID。

## 从缺失目标开始测

Mike Ramos 的[独立扑克评估](https://backnotprop.com/blog/jev-poker/)提供了一个有用的质疑案例。他测试了 Jev 1.13，发现在输入中加入计算出的手牌标签后，模型的决策会改变。他那套特定的测试设置无法告诉我们 1.14 如何处理图像，但它指向了一个值得追问的方向：喂给决策模型的信息，够不够做出我们期望它做的判断？

对 Box 来说，我会从带标注的图片开始测，包括目标缺失和模糊重复的情况，然后检查被接受的裁剪是否保留了目标对象。我会分别衡量"误报存在"和"定位错误"。单一的成功率会掩盖到底哪条边界需要修。

我很欣赏 TypeSafe 明确说明他们还没准备好担保什么。能被普通代码直接处理的视觉问答值得尝试，但在让这些答案驱动自动化之前，我要把空图片的情况纳入评估。即使模型的 Box 类型总是返回坐标，缺失的目标也应该产生明确的应用结果。