首页 知识分组 G00 地基:模型是概率采样器 PE-F-05
指令的具体性与可验证性
Instruction Specificity and Verifiability
PE-F-05 内容已写满 G00 地基:模型是概率采样器 第 4 层
地基 指令设计 可验证性
一句话结论
目标与约束写到可判定,方法提示尽量克制,并且不重复同一指令。
本页结构(可跳转)
A
具体性:说了多少细节
现行口径向「更一般」移动
(推理路径不写死)
B
可验证性:结果能否被判定
现行口径向「更严格」移动
(交付契约必须可判定)
A->B
不矛盾:一个管推理路径,一个管交付契约
N
混为一谈的两种后果
把「具体」当「长」 ⇒ 重复指令只烧 token
把「一般」当「模糊」 ⇒ 契约不可判定
B->N
双维图:具体性(说多少细节)与可验证性(能否判定)方向相反却不矛盾,因为对象不同。 (本站自制)
01 为什么需要它
指令写得越细不一定越好:在新一代模型上,过度具体的手写步骤反而会降低效果,因为模型对模糊与细微差别的处理能力已经提高。
真正需要的是可验证性——把「做到什么算完成」写成可判定的条件,而不是把「怎么做」写成操作手册。
适用边界
「偏好一般性指令」针对的是推理能力已被底座内化的任务;在需要严格流程合规的场景(审计、合规流水线)里,显式步骤仍然是必要的,此时应把步骤写成可检查的产出条件而非叙述。
02 机制说明
指令质量可以从两个维度拆开:具体性(说了多少细节)与可验证性(结果能否被判定)。
现行厂商口径在具体性上整体向「更一般」移动:偏好一般性指令而非规定性步骤,理由是模型的推理常常超出人类预先规定的步骤;同时把「只写一次、不重复指令」列为反堆砌原则。 在可验证性上则相反,要求把输出形态、判定标准与失败条件写清,因为那是自动化校验的前提。 二者并不矛盾:一般性针对的是推理路径,可验证性针对的是交付契约。
03 何时该用 / 何时不该用
04 实验台
file markdown
查看代码 把一条模糊指令改写成可验证契约,逐项填表
原句 | 输出形态(交付物长什么样) | 判定条件(怎样算通过) | 失败条件(出现什么就是没做到) | 是否可自动校验
判据:三列齐全才算契约成立;只剩「输出形态」的是格式要求,不是契约。
不得把「尽量好」「专业一点」这类词写进判定条件——它们不可判定,等于没有判据。预期观察:读者能写出能被脚本校验的交付契约,并意识到「可验证性」与「具体性」是两个独立维度。
shell bash
查看代码 # 同一任务两种写法:A 规定性步骤(先做 1、2、3) / B 目标 + 约束 + 可验证契约
# 用同一个校验脚本对两版输出打分,各跑 20 次
for style in prescriptive layered; do
echo "== style=$style =="
for i in $(seq 1 20); do
run_task "$style" | validate_contract.py -
done | awk '{p+=$1} END {print "通过率", p/NR}'
done预期观察:在推理型任务上 B 版通过率不低于 A 版、token 更少;若 A 版更好,说明该任务其实需要严格流程(审计类),那就把步骤改写成可检查的产出条件而不是删掉步骤。
05 证据
06 术语
术语 指令的具体性与可验证性 Instruction Specificity and Verifiability
界定 指令应写到可被判定的程度:明确输出形态、判定标准与失败条件,使结果可被自动化校验而非靠人工观感。
相关节点 —
07 失效模式
把「具体」等同于「长」 重复同一指令只增加 token 与注意力消耗,不增加任何约束力。 把「一般性」当成「模糊」 一般性针对推理路径,交付契约仍必须可判定;写成「尽量好」就无法自动校验。 在合规与审计流水线上照搬「少写步骤」 需要流程可追溯的场景里显式步骤是必要产出,只是要写成可检查的条件。 只写成功标准、不写失败条件 出错时无法区分「没做到」与「没测到」,评测集也无法定位回归。
08 在本站知识结构中的位置
所属分组 G00 地基:模型是概率采样器 依赖深度 第 4 层(同层节点彼此无先后约束)
在 交互全景图 中定位本节点。