jev模型要求输入必须配合预定义schema，不支持自由文本提示；需明确声明choice、score或noul等结构化任务类型，并提供对应取值范围；仅接受纯文本输入，支持单次请求并行多任务判断，不可用于生成式任务。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
Jev模型不接受自由文本提示，它要求输入必须配合预定义的schema——换句话说，你得先告诉模型“你要它判断什么”，再给它原始材料。这不是写Prompt，而是声明一个结构化任务。
输入必须带schema声明
每次调用Jev，都要在请求体中明确指定输出类型和取值范围。比如做分类，不能只说“判断这是什么问题”，而要写成：
- Choice：提供完整、互斥、穷尽的选项列表，如["账号问题", "支付异常", "技术故障", "其他"]
- Score：定义数值区间与粒度，如{"min": 0, "max": 100, "step": 1}，或更语义化的等级["低", "中", "高", "紧急"]
- Noul（布尔判断）：写成一个可验证的 yes/no 问题，如"日志中是否出现'license expired'字样？"
原始输入内容是纯文本，但需保持语义完整
模型只支持文本输入，不解析图片、PDF或二进制数据。如果你有日志、工单、用户消息、代码片段等，直接转成UTF-8字符串传入即可。注意两点：
- 保留关键上下文，比如报错堆栈里哪一行触发了异常，不要只截前10个字
- 避免冗余噪音，像邮件签名、重复分隔线、大量空行会稀释信号，建议简单清洗
- 长度不是越大越好：实测3万token输入耗时约160ms，但多数业务场景200–2000字已足够
一次请求可同时发起多个独立判断
你不需要为“归类+打分+查敏感词”发三次API。Jev允许在一个请求里并行提交多个任务，例如：
- 对同一段客服对话，同时执行：Choice（归属部门）、Score（情绪强度0–10）、Noul（是否含辱骂词汇）
- 所有任务共享同一份输入文本，模型一次性完成全部前向传播，响应仍是单个JSON
- 这样既省延迟，又省token成本，适合构建轻量级决策流水线
别把Jev当LLM用，它不理解“改写”“总结”“解释”
所有输入必须指向一个可枚举、可校验的决策目标。以下写法是无效的：
- ❌ “请分析这段SQL有没有性能风险” → 没有预设风险维度，模型无法映射到schema
- ❌ “用一句话说明用户意图” → Jev不生成任何自然语言
- ✅ 正确做法：“这段SQL是否含全表扫描？”，选项为[true, false]；或“扫描行数预估等级”，选项为["100k"]
