state是程序当前可结构化表达的业务上下文，须为系统已有字段拼装的可验证事实集合，覆盖所有问题判断依据，采用扁平结构、显式键名，避免主观描述与嵌套逻辑。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
State 不是提示词，而是程序当前可结构化表达的业务上下文。它要足够完整，又不能带主观引导；要贴近真实数据形态，又得为 Jev 的三种问题类型（Noul、Choice、Score）留出清晰判断边界。
State 必须是“可验证的事实集合”
State 应由系统已有字段拼装而成，避免自由描述或推测性语句。例如处理客服工单时：
- ✅ 好的写法：
{"message": "鞋码不对，退款还没到账", "order_status": "shipped", "refund_history": [{"status": "pending", "created_at": "2026-09-18"}], "customer_tier": "gold"} - ❌ 避免写法：
{"summary": "客户很生气，可能要投诉"}—— 这是结论，不是事实；Jev 无法基于结论再做判断
官方强调：State 是“输入给模型的事实”，不是“喂给模型的解释”。所有情绪、意图、风险等级等，都应交给 Jev 用 Noul 或 Score 去判断，而不是提前塞进 State 里。
State 要覆盖所有问题的判断依据
每个问题都独立作用于同一份 State，所以 State 必须包含所有 questions 所需的支撑信息。若一个问题失败，大概率是 State 缺了关键字段，而非问题本身写得不好。
- 比如同时问：
"is_refund_request"（Noul）、"assign_to"（Choice）、"urgency"（Score），那么 State 就至少得含客户原文、订单状态、历史操作、服务等级等字段 - 若 State 中没有
refund_policy_version，但问题中要求判断“是否符合当前退款政策”，Jev 就无法校验，置信度会显著下降
State 结构建议：扁平 + 显式键名 + 无嵌套逻辑
Jev 不解析深层嵌套语义，也不执行 JSONPath 查询。推荐用扁平结构，关键信息直接挂顶层，必要时加前缀区分来源。
- ✅ 推荐：
{"user_message": "...", "order_id": "ORD-789", "order_items_count": 2, "has_shipping_label": true, "csat_last_30d": 0.82} - ⚠️ 谨慎使用：
{"order": {"details": {"items": [...]}}}—— 若问题只关心 items 数量，就该直接提上来，避免 Jev 在理解路径上引入偏差 - 不要在 State 里藏条件分支逻辑，比如
"if order_status == 'delivered' then include_tracking"—— 这类逻辑应由调用方代码控制，Jev 只消费最终确定的字段
State 长度与粒度：宁多勿少，但需可测
Jev 支持 64k token 上下文，但不意味着 State 越长越好。重点在于“相关性”和“可观测性”：
- 保留原始日志片段（如用户原话、错误堆栈第一行）比加工后的摘要更可靠
- 剔除明显无关字段（如用户头像 URL、埋点时间戳毫秒部分），它们不参与判断，却拉高 token 成本
- 对长文本字段（如邮件正文），可截取关键段落 + 添加位置标记，例如：
"email_body_snippet": "[开头]您好，我上周下的单...[结尾]请尽快处理，谢谢。"
实际工程中，建议把 State 构建过程写成纯函数，并配套单元测试：输入固定样本，输出固定 JSON 字段集。这样能确保每次请求的 State 具备可复现性和可审计性。
