能力边界与已知问题
Jev 在它的设计空间内很强，但设计空间本身有硬边界。这一页汇总官方口径的限制、官方自认的已知问题，以及社区争议的核验状态——评估选型前建议通读。
硬边界（官方口径，2026-09-22 核验）
Section titled “硬边界（官方口径，2026-09-22 核验）”| 边界 | 数值/事实 | 影响 |
|---|---|---|
| 无文本生成 | 只输出题型答案 | 不能写摘要、翻译、改写；需要文本就交给 LLM |
| 纯文本输入 | state 只接受文本（含结构化 JSON 序列化） | 图片、音频需要先转成文字描述 |
| 单请求 ≤ 64k token | 其中 state + 最长问题 ≤ 32k | 长文档要切块或先检索再判断 |
| 限流 250k token/s、1200 req/min | 429 触发，官方注明可能调整 | 高并发需处理退避重试 |
| 输出 token 免费 | 输入 $0.042/Mtok | 成本模型简单，但输入很长时仍要计费 |
官方自认的已知问题
Section titled “官方自认的已知问题”官方专门维护 “Jev 1.13 jaggedness” 页面，列出 jev-1.13 的已知毛边并声明多数会在后续版本修复（经官方 llms.txt 索引核验，2026-09-21）。官方主动公开缺陷清单这一点值得肯定；引用具体缺陷条目前请以该页面当前内容为准，本站不转抄可能过时的列表。
“Can’t hallucinate” 的准确含义
Section titled ““Can’t hallucinate” 的准确含义”官方营销语 “Jev can’t hallucinate” 指的是类型安全属性：答案只能是题型允许的枚举值/数值，不会像 LLM 那样生成格式外的编造文本。它不等于判断永远正确——选错选项、打错分的“语义错误”照样存在，官方文档自己也强调要用 confidence 控制。把这句话理解成“零错误”是发布周最常见的误读。
社区争议与核验状态
Section titled “社区争议与核验状态”| 说法 | 性质 | 本站核验状态 |
|---|---|---|
| “Vercel 用 Jev 后命令执行快 5–18 倍” | 媒体转述（TechCrunch） | 未独立核验；数字来自 Vercel 自报 |
| 首页宣称的 193.6×/444.6× 成本对比 | 官方口径 | 官方博客已自注 caveats：自建工作流、美西评测、对比模型为 GPT-6 Astra 与 Fable 5.1 |
| Theo 等对“用 Jev 做上下文压缩”的批评 | 社区观点 | 观点内容，见视频教程；对应项目 fast-jev-compaction 见开源生态 |
| 大量伪造 Jev Demo | 社区观察 | Builder.io 视频逐一辟谣（标题经核验）；本站不收录未核验 Demo |
| “Jev 是千问/Qwen 套壳” | 社区传闻 | 无任何证据，本站未核验也不采信；官方称自研 RLCD 训练 |
什么时候不该用 Jev
Section titled “什么时候不该用 Jev”本站检查清单（来源：本站编辑）：
- 答案空间是开放的（写文案、起名、自由问答）→ 用 LLM
- 需要多步推理链（数学证明、复杂规划）→ Jev 做单步判断，链式调用反而更贵
- 判断完全规则化（正则、SQL 就能做）→ 不需要模型
- 错误代价极高且无法人工复核 → 谨慎；至少要保留 confidence 阈值与审计日志
反过来，如果你的场景是“高频、窄判断、要概率、要延迟低”，它可能正合适——看应用场景。