JEV 输入设计指南
如何为 Jev 设计高质量 State
把 Jev state 组织成紧凑的决策证据：去掉噪声，保留标签与单位，并让业务策略继续由代码掌握。
1. 从决策边界倒推输入
先写清楚 Choice、Score 或 Noul 问题，再只保留可能改变答案的事实。上下文更多，并不代表决策证据更好。
2. 优先使用带标签的记录
稳定字段名更便于审计，也能减少歧义。保留标识符、时间、单位和来源标签，不要把所有信息压成一段无结构文本。
3. 先用代码完成确定性过滤
权限、精确计算、白名单、去重和长度限制应由普通代码处理。Jev 只处理这些检查之后剩下的语义判断。
4. 独立测试 State 的变化
维护标注测试集，每次只改变一个字段；记录规范化后的 State 结构，才能判断回归来自输入变化还是问题设计。
动手验证：完整示例与失败路径
下方是完整文件，不需要补写省略函数。示例仅打印建议或转人工状态，不修改工单、不执行支付或发布。
验证范围：锁定依赖的类型/语法检查和模拟传输；未进行真实 API 性能或准确率测试。真实运行需要自己的服务端密钥，可能产生费用。纯校准和输入处理示例不联网。
坏输入把工单、密钥和全部历史直接序列化；好输入先由代码提取 message 与 failure_band。字段白名单不会自动清除 message 内的隐私，发送前还须脱敏。空消息和错误计数返回 request_context；超长消息转人工，不悄悄截断关键证据。
state-design.py
"""Deterministic prefilter; no model call and no secrets in returned state."""
def build_state(ticket):
message = ticket.get('message')
if not isinstance(message, str) or not message.strip():
return {'action': 'request_context', 'reason': 'missing_message'}
if len(message) > 4000:
return {'action': 'review', 'reason': 'oversized_message'}
failures = ticket.get('failure_count')
if not isinstance(failures, int) or isinstance(failures, bool) or failures < 0:
return {'action': 'request_context', 'reason': 'invalid_failure_count'}
return {'action': 'evaluate', 'state': {
'message': message.strip(),
'failure_band': 'repeated' if failures >= 3 else 'isolated',
# Explicit allowlist: api_key, email and unrelated history are not copied.
}}
if __name__ == '__main__':
print(build_state({'message': 'Checkout fails.', 'failure_count': 4, 'api_key': 'do-not-send'}))
print(build_state({'failure_count': 4}))
# Free text can itself contain secrets. Review/redact it before provider upload.
运行
python state-design.py如何判断是否运行正确
有 API 的示例应输出 action、team 等结构化字段；具体标签与分数会随输入和模型变化，不能要求与模拟值一致。删除密钥应走复核分支，不应泄露异常正文。校准脚本输出 development 与 held-out 两组指标；它不验证模型质量。