新一代提示词工程 · 知识全景图面向有工程基础、提示词工程尚未系统化的工程师
显示设置

指令的具体性与可验证性

Instruction Specificity and Verifiability

PE-F-05内容已写满G00地基:模型是概率采样器第 4 层

地基指令设计可验证性

一句话结论

目标与约束写到可判定,方法提示尽量克制,并且不重复同一指令。

本页结构(可跳转)

A 具体性:说了多少细节 现行口径向「更一般」移动 (推理路径不写死) B 可验证性:结果能否被判定 现行口径向「更严格」移动 (交付契约必须可判定) A->B 不矛盾:一个管推理路径,一个管交付契约 N 混为一谈的两种后果 把「具体」当「长」 ⇒ 重复指令只烧 token 把「一般」当「模糊」 ⇒ 契约不可判定 B->N
双维图:具体性(说多少细节)与可验证性(能否判定)方向相反却不矛盾,因为对象不同。 (本站自制)

01为什么需要它

指令写得越细不一定越好:在新一代模型上,过度具体的手写步骤反而会降低效果,因为模型对模糊与细微差别的处理能力已经提高。

适用边界

「偏好一般性指令」针对的是推理能力已被底座内化的任务;在需要严格流程合规的场景(审计、合规流水线)里,显式步骤仍然是必要的,此时应把步骤写成可检查的产出条件而非叙述。

02机制说明

指令质量可以从两个维度拆开:具体性(说了多少细节)与可验证性(结果能否被判定)。

03何时该用 / 何时不该用

按场景对照:先看条件,再看该怎么做。
类别场景 / 条件(总结)具体做法(细节)
该用需要自动化校验输出时把输出形态与判定条件写成可判定的契约。
该用推理类任务上给目标与约束,少写规定性步骤,避免限制模型的推理路径。
不该用合规与审计流水线需要流程可追溯时,显式步骤仍是必要产出。
不该用把「具体」等同于「长」重复同一指令只增加 token,不增加约束力。

04实验台

  1. filemarkdown

    查看代码
    把一条模糊指令改写成可验证契约,逐项填表
      原句 | 输出形态(交付物长什么样) | 判定条件(怎样算通过) | 失败条件(出现什么就是没做到) | 是否可自动校验
    判据:三列齐全才算契约成立;只剩「输出形态」的是格式要求,不是契约。
    不得把「尽量好」「专业一点」这类词写进判定条件——它们不可判定,等于没有判据。

    预期观察:读者能写出能被脚本校验的交付契约,并意识到「可验证性」与「具体性」是两个独立维度。

  2. shellbash

    查看代码
    # 同一任务两种写法: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证据

主张现行官方口径承认:过度具体的指导在新一代模型上会由助力转为阻力——这是「指令具体性整体向更一般移动」的一手依据。

分级official

来源S-0013 https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra

原文

展开原文关键句
Models have gotten much better at understanding nuance and ambiguity, so overly specific guidance can now hinder results where it previously helped.

主张官方把「可验证性」的边界摆在台面上:并非所有成功标准或失败的评测都最适合用提示工程解决,换模型有时更省力——所以先判断这个失败到底该不该由提示工程承担。

分级official

来源S-0002 https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview

原文

展开原文关键句
Not every success criteria or failing eval is best solved by prompt engineering. For example, you can sometimes improve latency and cost more easily by selecting a different model.

06术语

术语指令的具体性与可验证性 Instruction Specificity and Verifiability

界定指令应写到可被判定的程度:明确输出形态、判定标准与失败条件,使结果可被自动化校验而非靠人工观感。

相关节点—

07失效模式

08在本站知识结构中的位置

所属分组
G00地基:模型是概率采样器
依赖深度
第 4 层(同层节点彼此无先后约束)
前置PE-F-04→PE-F-05 本节点→后继PE-F-06

在 交互全景图 中定位本节点。