jev-workbench
把判断封装成有版本的服务
实现思路与验证边界 →JEV GUIDE
Jev 提示词的起点是定义判断条件。先明确程序需要什么值,再写题目和候选项。本文的编辑建议与合成示例没有经过真实模型复测。
“判断这个反馈好不好”很难验证。可以拆成“是否描述故障”“属于哪类功能”“复现信息完整到哪一级”。让每个问题只承担一项责任。
官方文档指出,问题 ID 不会传给模型。因此,即使把键命名为 has_steps,也必须在 instructions 中说明判断对象和复现步骤的定义。
要把反馈放入一个队列,用 Choice;要按明确定义的完整度分级,用 Score;只检查是否满足一个条件,用 Noul。
下面是题目片段,需要与 state 和 model 组合成完整请求。候选项保留 other,让不适合现有类别的输入有出口。
{
"route": {
"type": "choice",
"instructions": "Which queue best matches the main request in `report`?",
"criteria": {
"bug": "A feature behaves differently from an explicitly described expectation.",
"idea": "A request to add or change functionality without a described failure.",
"other": "Unclear, unrelated, or insufficient information."
}
},
"detail": {
"type": "score",
"instructions": "How much reproduction information is explicitly present in `report`?",
"criteria": [
"No specific action or outcome.",
"An action and unexpected outcome are described.",
"Actions, expected outcome, and environment are described."
]
},
"has_environment": {
"type": "noul",
"instructions": "Does `report` explicitly name a browser, operating system, or application version?"
}
}Noul 接近 0.5 表示对条件是否成立不确定,不能读成“中等程度满足”。例如“提到了浏览器版本”应检查是否明确出现信息,而不是让模型补猜。需要表达程度时,另写有顺序的等级。
给每条样本写下预期队列和原因,单独标注确实无法决定的输入。以下边界比反复测试一条明显样本更有价值。
把 state 样本、题目定义和预期结果一起存储。一次只调整一个问题或一组相互关联的候选项,比较误判变化。若下游动作会改变数据,先采用建议模式;模型输出不是授权。
把判断封装成有版本的服务
实现思路与验证边界 →核对引用、筛查内容、重排候选
实现思路与验证边界 →02 / JEV GUIDE
用一个合成故障报告了解 Jev API 请求,查看 state、questions、Bearer 鉴权和响应检查步骤,附可下载 JSON 示例。
阅读指南 →06 / JEV GUIDE
用 Jev Choice 设计文本分类和任务路由,明确候选标签、未知类别与人工检查,连接模型路由和语义筛选案例。
阅读指南 →