写好问题

Valen 针对你发送的 state 回答类型化的问题。准确率的提升大多来自问题和 state 的结构，而不是措辞技巧。本页汇总有效的写法，以及目前记录到的难点和对应的改法。

Valen 做判断，代码做决策

把决策写成真值表。Valen 提供输入（"商品上有没有水印？""这条消息表达的是哪种意图？"），代码把它们映射成动作。像"这个商品该不该下架？"这样的问题，把业务规则藏进了模型里。把它拆成所依赖的判断，规则留在代码里，便于阅读和测试。算术、日期、精确查找和业务策略也都放在代码里。

人类测试

一个聪明人只看这份 state 和这个问题，能不能凭直觉很快答出来？答不出来时，先改 state：

• 说明这段文本是什么，例如 "inbox": "一家小型服装网店的客服邮件"。只加这一个字段，简短的"我的东西呢"就从 none 变成了物流查询，概率 0.99。
• 给出人会看的内容：邮件的主题和正文、每条消息的发送者、完整的对话、名称而不是原始 ID，并且只给与问题相关的那一项。
• 写明代码已经知道的事实，解释内部产品名。
• 删掉没有问题用到的字段；为一个问题加的字段可能影响另一个问题。
• 用带描述性键名的 JSON 对象，问题里用反引号路径引用，例如 message 或 order.items。
• 保留用户的语言：英文问题可以直接用于中文或其他语言的 state。
• 把图像裁剪到人会去看的区域。视频由代码选帧（静态属性用中间帧，动作用多个间隔帧），并在每个回答旁记录帧序号。

一个问题只问一个判断

• 问可观察的事："商品图是否模糊？"，而不是"图片质量差吗？"。
• 会导向不同动作的条件拆成两个问题，检查清单里的每条规则各占一个问题。同一个判断的几种表现（语气、讽刺、威胁都表示"生气"）用一个 Noul，在 criteria 里写明这些表现；拆成多个 Noul 再在代码里取 OR，误报会叠加。
• 直接点名对象，让"是"代表条件成立。
• 写得朴素。开场白、分步指令和输出格式只会增加噪声；选项描述放进候选项里。
• 两个结果总被混淆时，把容易混淆的情形写进它真正归属的候选项。政策咨询总被分到 refund 时，在 none 里写上"购买前询问店铺政策"。如果在 refund 的描述里写"询问政策不算退款请求"，反而会在那里提到这个概念，把概率拉向 refund。改完后要重跑原本已经正确的样本。如果仍然判错，就加一个从结构上区分它的 Noul（"message 是否关于客户已经下的订单"），在代码里组合判断。

候选项

• 候选值用有含义的名字，如 refund_request；A、option_1 给不了模型任何信息。
• 让模型判断它看得出的区别，再在代码里映射到业务类别：与其用一个 other 涵盖跳舞、演奏和走路，不如分别询问后再映射。多个候选导向同一动作时，先把它们的概率相加再比阈值。
• 候选项之间要有区分度。共用的措辞会把概率拉到一起；一个候选项覆盖多种含义时就拆开。
• Score 的每个等级写成能单独读懂的情形，从低到高排列。
• Noul 的否定情形用 criteria: {"true": "...", "false": "..."} 写成具体情形（"包裹按时送达"）。
• 多个陈述可能同时成立时，每个陈述用一个 Noul。
• 识别混合请求用一个 Noul：在意图 Choice 旁边问"客户提出了不止一个独立请求"。每个类别各设一个 Noul，在"hi"这类几乎为空的消息上会整体偏高。它的 false 描述要写明哪些不算第二个请求，例如备选方案（"换货，换不了就退款"）和背景说明；中间区间去哪里，按人工审核的成本决定。

合并问题，保持问题集稳定

同一请求中的问题共享一次对 state 的前向计算，合并提问比分开调用便宜得多。可以预先提问：把后续问题（"要退的是哪件商品？"）和决定它是否需要的问题放在一起，由代码在需要时才读取。

Valen 把一个请求里的问题放进同一条因果序列（见多问题共享计算），所以其他问题和它们的顺序也是输入的一部分。后面的问题几乎不影响前面的问题，所以把最重要、最稳定的问题放在最前面。固定验证过的问题集合和顺序，增删或调整顺序后重新验证。当一个问题明显影响另一个问题的回答，或者代码需要先拿到一个回答才能构造下一次请求时，分成多次请求。

已记录的难点

Valen 在哪些情形下不够可靠、影响多大、各自怎么改写，见已知弱点：state 里的规则表、长列表和算术；候选里缺少正确类别；结尾的通用套话；只有一个候选的 Choice；两极分化的 Score；大图里的小目标；用单帧给整段视频打标签。

读回答，定阈值

confidence 衡量分布的集中程度；该自动处理哪些情况，要看留出集上的准确率。Noul 的阈值可以从 0.7 和 0.3 起步，中间区间单独给出结果，通常是人工审核。Choice 的门控可以从最高概率 0.8、与第二名差距 0.2 起步。同一请求和模型的回答是确定的，每种写法跑一次就能比较。最终数值用你业务中的标注样本，通过校准流程确定；精确公式见如何使用概率。

回答看起来不对时

按顺序检查：实际发出的请求（图像、模型 ID）；state 能否通过人类测试；正确答案是否在候选项里；问题能否再拆；同一请求里的其他问题；最后才是措辞。为了得到某个数值而写的措辞、在 criteria 里点名测试样本、拿少数几个样本拟合的阈值，换了新输入往往就失效。迭代前先留出一组验证样本，定稿后再写一组新的复查。更好的 state、单独的问题或者代码，才是长期有效的改法。

下一步：Agent skill · API 调用 · Cookbook