Jev 开始读懂照片：从退货核验到定位损坏区域

原创说明图：输入照片，输出独立判断和坐标，并由人检查建议的损坏区域。它展示的是一种工作流，不是实际记录的模型结果。

客户拍了一张有缺口的杯子照片。你的客服工具需要回答三个不同的问题：能否看见杯子？图片是否显示了损坏？审核者应该查看哪里？一段关于陶瓷的流畅说明，并不是最有用的中间结果。

2026 年 10 月 14 日，TypeSafe AI 宣布 Jev 加入实验性图像支持，同时推出 Jev 1.14.0 和新的 box 输出类型。Jev 1.13 与 1.14 都能处理图像；Box 则要求 1.14。TypeSafe 将这些功能称为实验性功能，并明确表示尚不建议用于生产自动化。官方公告

这项有用的变化比“通用多模态助手”更具体：照片可以变成有类型的判断，或程序可以使用的位置坐标。下面会介绍它如何改变退货工作流、接口接受什么，以及怎样构建谨慎的原型，避免把矩形框误当成证据。

简要概览：

• Jev 新增了用于静态图像理解的实验路径，不是图像生成。
• 在相信建议位置之前，先确认目标确实存在。
• 保留原图并由人审核；坐标、权限和后果交由代码验证。

照片可以转化为判断，而不只是描述

Jev 最初的吸引力在于范围明确的回答：从给定选项中选择、按描述的等级评分，或判断一个是/否命题。我们之前的 Jev 决策模型指南介绍了这项基础能力。新进展是，问题现在可以使用视觉证据，还能返回空间坐标。

对于退货界面，工作的分工因此改变。模型可以提示照片里似乎有损坏；应用代码则能把该提示显示在用户提交的图片旁边。但这两步都不能证明损坏何时发生、照片是否属于这笔订单，或是否获准退款。这些是不同的问题，需要不同证据。

这些边界来自模型参考、API 请求契约和支持图像的 SDK。不能因为某些 PDF 页面上有图片，就认为一个 PDF 文件夹自动变成了文档处理流程。同样，提取了若干视频帧，也不代表系统原生理解了视频，或能访问片段中的音轨。

我们的看法是：值得关注的基本单元，是附带证据、范围小且可检查的判断，而不是一张可以把后续所有事情都自动化的通行证。

三个官方示例让同一张照片承担不同工作

TypeSafe 的 JavaScript 文档提供了三个具体起点。它们是公开的代码示例，不是客户实际部署报告，也不是测得的结果。可把它们当作原型模式，而不要当成模型在你照片上的准确率承诺。

第一个示例将杯子损坏的说法和产品照片结合起来，向 Noul 询问是否损坏，向 Score 询问损坏程度。在客服队列中，可以改造成优先展示疑似损坏项目供人检查。审核者仍应看到完整照片、客户描述，以及拒绝建议的选项。

第二个示例将卖家上传的照片与目录图片比较，判断两者是否为同一商品，并评估照片是否清晰可用，包括模糊、裁切和非商品内容等情况。对市集平台来说，这启发了一种有用的区分：商品身份匹配和照片质量不必共用一个批准决定。拍得很清楚但商品不对，也不应仅因图片看起来专业就通过。

第三个示例让 Box 定位受损区域。结果可以用于叠加标记，或为审核者提供建议裁剪区域。应同时保留未经裁剪的原图：缩小注意范围能帮助人检查申诉，也可能遮住改变其含义的上下文。

可以查看官方的损坏评估、目录图片比较和损坏区域定位示例。我们提出的退货流程在这些模式外增加了应用层防护，并非某次试验的记录。

Box 无法告诉你目标不存在

TypeSafe 的 Box 契约有一个关键细节：目标不存在时，没有专门的输出值。即使所请求的目标缺失，Box 问题仍会返回四条边。因此，仅凭一个框套住完整无损的杯子，不能证明损坏确实存在。

应另外用 Noul 判断所请求目标是否存在。在这个工作流中，要区分杯子是否可见和损坏是否可见。杯子判断为是，不足以授权显示损坏区域。只有当相关存在性检查符合经过验证的规则时，才使用建议的损坏框。

存在性门控不是避免错误的灵丹妙药；两种判断也可能同时出错。明亮反光可能看起来像缺口，真实裂纹也可能被花纹釉面掩盖。选定阈值前，应测试没有杯子的照片、完好杯子、含糊的反光、多个物体，以及损坏清晰可见的照片。

原创决策图：只有通过目标存在性检查，矩形框才可使用。检查失败或结果不确定时，保留原图供人工审核，而不是自动拒绝申请。

把矩形框看作指示位置的指针，而不是裁决。

把坐标当作几何数据，再检查它的含义

Box 返回 left、right、top 和 bottom，表示从左上角量起、相对于图像尺寸的比例值。取值在 0 到 1 之间，并满足 left < right、top < bottom。一个问题只产生一个框，不会返回物体检测列表。Box 响应契约

以一张用于说明的 1200 x 900 图像为例，左边 0.20、上边 0.30、右边 0.60、下边 0.70，对应的像素边界为 240、270、720、630。这是算术示例，并非 Jev 的实际响应。裁剪 API 通常要求左、上、右、下的顺序，因此应按字段名称有意映射，不要依赖 JSON 属性顺序。

绘制之前应验证数值有限、处于范围内且顺序正确。然后还要检查区域是否真的框出了损坏。如果你调整、旋转、填充边缘或切分了照片，就保留相应转换信息以便把坐标映射回原图；否则，一个看似合理的框可能会指到错误像素。

在发出请求前准备图片，而不是报错后再处理

官方图像限制具体且包含边界值。超出范围的图片会被拒绝，不会自动缩放；一张图片被拒绝，整个请求都会失败。

展开后的请求中，重复引用的图片也会重复计入。文件大小、尺寸和上下文长度是不同的检查项。图像限制

原创限制示意图，依据 TypeSafe 图像文档制作，核对于 2026 年 10 月 18 日。单文件、处理后图像、展开后的请求和请求体限制各自独立生效。

TypeSafe 还建议发送前先旋转像素，使图像正向。API 会移除元数据，不会应用 EXIF 方向信息。先转换不受支持的格式。准备指南

准备原型时，为自己拥有的照片制作一份名称清晰的副本，原图保持不变。在本地检查尺寸，并预览将要发送的准确副本。如果窄长裁剪图需要填充边缘才能达到最小尺寸，请在解释坐标时记下填充量。

固定使用 1.14，并明确启用实验功能

截至 10 月 18 日，已发布的别名表将 jev-latest 映射到 jev-1.13.0，将 jev-preview 映射到 jev-1.14.0。Box 示例应固定使用 jev-1.14.0，不要想当然地认为 latest 就是最新预览版。模型别名

下面的步骤会创建一个仅供本地审核的示例。运行最后一条命令会提交一次计费推理请求，SDK 也可能重试；它不会批准退货，也不会修改账户。请使用自己拥有且经过暂存处理的照片，不要包含人物、运单标签、地址或私人文件。

1. 获取访问权限，并选好组织。 TypeSafe 表示注册不再需要候补名单审批。在控制台创建 API 密钥，并在测试前检查组织积分。账户访问、积分设置

2. 使用 Node.js 22 或更高版本。 支持图像的 JavaScript SDK 版本为 0.7.0，日期为 10 月 14 日。固定版本能明确此示例使用的客户端依赖。SDK 更新日志

node --version
mkdir jev-photo-check
cd jev-photo-check
npm init -y
npm install @typesafe-ai/[email protected]

3. 设置仅在当前会话中有效的密钥。 Windows PowerShell 使用第一段；macOS 或 Linux 的 Bash/Zsh 使用第二段。在本地替换占位内容，不要提交真实密钥。

$env:TYPESAFE_API_KEY = "your-api-key"

export TYPESAFE_API_KEY="your-api-key"

4. 准备 owned-mug.jpg，并创建 inspect-return.mjs。 这是基于官方 SDK 辅助函数改编的原创示例。任何图像请求发出之前，都会配置实验功能请求头。以下两个概率阈值只是应用层示例规则，不是 TypeSafe 的建议。所有结果仍须人工审核。SDK 用法

import { readFile } from "node:fs/promises";
import { box, image, noul, TypeSafeClient } from "@typesafe-ai/sdk";

if (!process.env.TYPESAFE_API_KEY) {
  throw new Error("Set TYPESAFE_API_KEY before choosing to run this example.");
}

const client = new TypeSafeClient({
  defaultHeaders: { "TypeSafe-Danger-Zone-Images": "true" },
});
const photo = image(await readFile("owned-mug.jpg"));
const response = await client.systemOne({
  model: "jev-1.14.0",
  state: { photo },
  questions: {
    mugVisible: noul("Is a mug clearly visible in `photo`?"),
    damageVisible: noul("Is physical damage clearly visible on the mug in `photo`?"),
    damageRegion: box("The physically damaged area of the mug in `photo`"),
  },
});

const { mugVisible, damageVisible, damageRegion } = response.answers;
const edges = damageRegion.box;
const coordinates = [edges.left, edges.top, edges.right, edges.bottom];
const validBox = coordinates.every(
  (value) => Number.isFinite(value) && value >= 0 && value <= 1,
) && edges.left < edges.right && edges.top < edges.bottom;

const presencePasses = [mugVisible.noul, damageVisible.noul].every(
  (value) => Number.isFinite(value) && value >= 0.95 && value <= 1,
);

console.log({
  model: response.model,
  usage: response.usage,
  humanReviewRequired: true,
  suggestedBox: presencePasses && validBox ? edges : null,
});

5. 只有准备好发送图片并承担用量费用时才运行。 三种操作系统都执行 node inspect-return.mjs。如果发生异常或 suggestedBox: null，应让原图继续供人审核，而不是自动重复提交。

这些问题共用一次请求，但除非应用层门控通过，否则会忽略边界框。这并不能免去计算一个最终未使用的框的费用。后续可以改为：存在性检查通过后再单独请求定位，以多一次往返换取避免不必要的定位调用。

Token 单价低，不等于每张照片的价格低

两种版本公布的输入价格都是每百万 token 0.042 美元，输出 token 免费。也就是说，一千万个计费输入 token 的价格为 0.42 美元；这不代表一千万张图片只要这么多钱。已公布的价格

图片按文本价格计为输入 token，不另收图片费用。TypeSafe 的文档尚未提供图像 token 估算公式。因此，在获准的评估期间做预算，应使用响应中的 usage.input_tokens，而不是编造每张照片的成本。图像计费

预算还应包括失败尝试、重试、预处理、存储和审核时间。将成本与质量数据放在一起：如果裁剪得太紧，导致每位审核者都要重新打开原图，那么省下几分之一美分并无意义。应将完整审核任务与简单的人工基准流程比较。

围绕不确定性、隐私和繁忙服务来设计

Noul 返回概率，但没有单独的 confidence 字段。Choice 和 Score 会返回分布和衍生置信度。这些数值描述的是模型的不确定程度，不是保证正确的通行证。置信度文档

对于杯子工作流，应在带有商定标签的留出照片上验证门控。把相似输出分组，再与观测到的正确性比较，以检查任务上的校准情况。将漏检损坏和误报分开衡量；也要区分定位框错位和退款决定错误。模型、光线、商品类别或拍摄流程发生变化后，应重新评估阈值。

不要把每张未通过检查的照片都当成客户有问题的证据。照片质量可能只是因为相机性能差、物体反光，或缺陷需要从另一个角度拍摄。实用的审核状态应提供补拍和人工检查路径，而不是把模型的不确定归咎于客户。

TypeSafe 表示，客户请求和响应不会用于训练 Jev。其帮助中心也解释，处理过程可能包括提供服务、计费、防滥用和遥测；保留期限则取决于数据类型、协议及是否采用零数据保留安排。不用于训练不等于不保留。数据处理政策

公开的服务状态页面列出美国地域及 us-east-1、us-east-2、us-west-2 这些区域。对有数据驻留要求的团队来说，应先解决处理位置问题，再上传客户照片；能够访问控制台，不等于签订了数据驻留协议。

上传之前执行数据最小化。如果地址标签无关，就在准备副本中裁掉；限制原图访问权限，避免把图片或密钥写入常规日志。独立于供应商政策，为自己的审核记录决定保留期限。

组织级限制包括每秒请求数和 token 数。API 用 429 表示速率限制，用 529 表示过载；输入格式错误或尺寸过大时需要修正，而不是不加更改地重试。速率限制、API 错误

JavaScript SDK 的默认重试策略为两次，并会遵循受支持的重试延迟响应头。不要再叠加无上限的外层重试循环。设置时间预算、保留可操作的错误状态，并将未来可能执行的业务操作分开，避免推理重试造成重复退款。重试策略

第一次处理照片之前，先回答这些问题

Jev 会编辑或生成退货照片吗？

不会。图片只是判断或建议区域的证据。你的应用使用常规图像处理代码绘制叠加层或裁剪图片。未经修改的源图应单独保留；一个有用的矩形框不能替代原始证据。

为什么示例固定使用 1.14，而不选 latest？

已发布的别名表目前把 jev-latest 指向 1.13，而 Box 需要 1.14。固定 jev-1.14.0 能明确这项依赖。更改版本前，应重新查看发布说明和测试集，而不要假设别名更新后行为不变。

损坏概率很高，就能触发退款吗？

仅凭这项证据，不应安全地自动退款。概率针对的是提交图片上的问题，并不能验证订单身份、认定责任或应用退款政策。先从辅助审核开始，用有代表性的示例做验证，并对会产生实际后果的操作保留人工决策。

输出免费，是否意味着图像请求不收费？

不是。输入 token（包括图像 token）仍会计费。公布的费率不是每张照片的报价，因为文档尚未说明图像 token 的估算公式。获准试点时，检查报告用量，并将重试和审核时间纳入总成本。

可以直接发送产品视频或 PDF 吗？

不能通过文档说明的静态图像接口直接发送。你的应用必须先提取合适的视频帧、文字或渲染页面，并取得处理这些材料的许可。提取单帧会丢失时间和音频信息，因此只能询问所提供证据能够回答的问题。

总结：先指引注意力，再委托决定权

Jev 的图像预览提出了一个实际方向：将视觉证据转成软件可以检查的小型答案。杯子退货工具可以通过区分存在性、损坏情况、损坏位置和审核来验证这个想法。最有价值的第一步不是自动退款，而是帮助审核者减少搜寻，更有依据地理解结果。

值得衡量的标准是：即使模型出错，建议区域是否仍能帮助人理解原始证据？

来源与范围

一手来源核对于 2026 年 10 月 18 日：TypeSafe 的10 月 14 日公告、模型与价格、图像限制与计费、Box 契约、JavaScript 示例及 SDK 发布说明。其他政策和可靠性来源已在相应说法旁链接。本文工作流和图表是说明性改编，不是实测基准；没有为本文付费调用模型。图表为原创，未复制供应商媒体。

让来源与结论放在一起

在自己的模型研究中，应将原始来源与据此得出的结论分开保存。创建 Telli.sh 账户，整理研究材料和派生笔记，同时保留来源上下文。