提问设计：写好 Choice、Score、Noul
当一个结果不符合预期时，先检查问题是否允许另一个人稳定作答。“这篇文章好不好？”没有说明好在哪里；“这条工单该怎么办？”把理解诉求、分配部门和执行权限挤在了一起。模型给出数值之后，这些分歧仍然存在。
写问题之前，先写出程序要用答案完成的动作。若程序要把文章送回补充步骤，就问稿件是否包含符合定义的步骤。若程序需要给工单选择队列，就先列出队列和边界。可检查的标准往往比更长的提示词更有帮助。
一张问题卡，先补齐四件事
| 字段 | 要写清什么 | 本书自拟示例 |
|---|---|---|
| 对象 | 究竟判断哪一段材料 | 只判断 draft.body |
| 性质 | 只判断一个可观察维度 | 是否给出可执行操作 |
| 标准 | 满足与不满足的边界 | 包含动作及其对象，口号不算 |
| 使用方式 | 程序准备怎样使用答案 | 缺少操作时进入补充队列 |
另写一条反例。例如“你应该重视效率”表达了建议，却没有告诉读者执行什么操作。这条反例能帮助你检查标准是不是只识别到积极语气。
API 中的 ID 是返回值的索引，不负责向模型解释问题。因此，把 ID 命名成 has_actionable_steps 之后，仍要在 instructions 写完整判断含义。问题定义
Choice：让每个候选项都有明确的位置
Choice 适合从已知集合中选一个值。选项名称与说明共同定义类别，返回中包含所选值及各选项的概率。Choice 文档
下面是一个应当修改的定义：
{
"type": "choice",
"instructions": "Which team should handle this?",
"criteria": {
"billing": "Billing issues",
"technical": "Technical issues"
}
}
问题不是它短，而是它没有解释“扣款两次，而且登录失败”该去哪；收到合作邀请时也没有合适类别。修订时先确定业务政策：本例让混合诉求进入独立复核队列，非目标消息保留兜底。
{
"type": "choice",
"instructions": "Select a queue using only the stated concerns.",
"criteria": {
"billing": "Only charges, invoices, or subscriptions.",
"technical": "Only login failures or broken product features.",
"mixed": "Both billing and technical concerns are present.",
"other": "Neither category fits, or the message is unclear."
}
}
这四个英文值与前章最小程序一致。other 不是让模型“想不到就随便选”的垃圾桶：你应定期读它包含什么。如果合作邀请频繁出现，就可以评估是否值得增加 partnership；不要为了消灭兜底率，提前发明几十个几乎没有输入的类别。
有时一条消息确实可以有多个标签。例如你想同时知道它是否涉及账单和登录，不应强迫单个 Choice 输出两个值。可以使用两个独立的存在性问题，再由代码决定主队列。选择哪一种方案，取决于最终需要一个去向，还是一组标签。
Score：先写等级，再接受数字
Score 使用有顺序的等级说明；等级从 0 开始编号，返回分数按等级概率加权，可能落在两个等级之间。官方当前接口接受 2–10 个等级。Score 文档
“给这条工单打 0–10 分”没有说明分数含义。本例只评估原文描述的工作受阻程度，不把客户情绪、客户价值和影响程度揉成一个数字。
{
"type": "score",
"instructions": "Rate the workflow impact stated in the message.",
"criteria": [
"No workflow is blocked; the issue is cosmetic or informational.",
"A workflow is impaired, with a stated usable workaround.",
"A core workflow is blocked, with explicitly no usable workaround."
]
}
写完后立即找缺信息样例：“导出失败了。”它没有说明替代方法是否存在。你的规则需要单独检查材料是否足够；不能把“没有提到解决办法”自动等同于“明确没有解决办法”。可以增加一个证据问题，缺少信息时忽略分数并请求补充。
以下只有算术示意，不是模型实测：若三个等级概率为 0.1、0.6、0.3，则分数为 0×0.1 + 1×0.6 + 2×0.3 = 1.2。它不是满分 10 分中的 1.2 分，也不代表有 120% 的把握。
同一个平均分可能来自不同分布：全部集中在等级 1，与一半在 0、一半在 2，平均值都为 1。业务含义却不同。需要复核时保留分布和 confidence，不要只把小数四舍五入成一个漂亮标签。
Noul：把命题限制在可见证据内
Noul 回答明确的是非命题，返回“是”的概率。它不衡量某种品质的程度；需要等级时使用 Score。Noul 文档
比较下面两种写法：
| 模糊问题 | 更容易核对的问题 |
|---|---|
| 这家公司值得信任吗？ | 提供的页面是否明确写出退款期限？ |
| 这篇文章准确吗？ | 指定主张旁是否有来源链接？ |
| 客户很着急吗？ | 客户原文是否明确要求在某个期限前处理？ |
| 用户有权查订单吗？ | 该权限应由应用代码根据可信身份检查 |
“页面写了退款期限”与“商家一定履约”不是同一个命题。提问时把这个区别放进范围，而不是在得到结果后再补一句解释。对内容检查，下面问题只判断稿件可见结构：
{
"type": "noul",
"instructions": "Does `draft.body` contain an actionable step?",
"criteria": {
"true": "A reader can perform a named action on a named object.",
"false": "Only goals, slogans, or general recommendations appear."
}
}
“打开设置页，关闭邮件提醒”符合本例定义；“优化你的工作方式”不符合。这个标准是否适合你的内容团队仍需讨论，但争论已经有具体对象，可以逐句检查。
多个问题共享材料，组合规则留在代码里
把“能不能发布”拆成“是否明确读者”“是否包含操作”“是否给出示例”“是否具备要求的来源”等独立问题。每个问题都应能直接依据稿件作答，不需要猜另一个答案。同一请求中的问题独立评估共享 state；有真正的先后依赖时，再由代码组织后续步骤。多问题与依赖
本书自拟的内容政策可以写成下面的伪代码：
输入为空或格式错误 → 停止，记录输入问题
必需答案缺失 → 复核，记录响应问题
任一必要内容未通过 → 返回补充队列
全部必要内容通过 → 建议进入编辑审阅
这里的“编辑审阅”仍不是自动发布。模板可以列出待补项目，但不会从一个 Noul 数值生成原文不存在的解释或引文。若需要定位具体句子，必须另外设计可验证的提取与展示环节；不要假定三种判断类型会返回自由文本证据。
用反例修改标准，保留一次完整记录
准备六条样例：清楚的正例、清楚的反例、否定表达、引用别人的话、同时包含两类内容、缺少必要信息。先给出人工标签，再运行真实调用；没有 Key 时只完成标注和代码分支验证。
对每个错误，记录“材料 ID → 问题版本 → 人工预期 → 实际答案 → 原因猜测”。一次只修订一个边界。若你为了某条消息加入“账单优先”，就要回头检查技术故障是否被不合理地压到后面。增加局部特例可能改善一个样例，也可能改变整套政策。
最后留出几条没用来修改标准的输入。修订完成后再检查它们；若每个例子都参与过改题，你只知道新题更贴合这几条材料，还不知道它能否适应新消息。离线 fixture 只能帮你演练返回值与分支，模型表现必须由真实调用另行验证。