别把所有要求混成一张打分表：先设「必过门槛」，再调「质量滑杆」 (2026)

很多人给 AI 提写作要求时，习惯写成一段综合愿望：“写得专业、准确、亲切、通俗，不要遗漏信息，篇幅适中，综合评分 1 到 5 分”。

这种提示词常带来一种隐蔽的失误：成稿读起来文采飞扬、语气亲切体贴，但关键的生效时间被抄错了，退款限制条件被漏掉了，或者文末顺手捏造了一个并不存在的操作入口。如果让人或 AI 按综合标准打分，往往会因为语言流畅而给出 4 分的高分，最终把带有致命事实硬伤的文字发了出去。

在工程评测与提示词设计中，这种现象被称为“平均分陷阱”。文笔好不能抵消事实错，99 分的表达流畅度也弥补不了 1 个错误的日期。

更稳妥的做法是把要求明确拆成两层：先设一票否决的「必过门槛」，再调连续微调的「质量滑杆」。

Anthropic 在其评估指南中明确指出，评估标准应区分为二值判断与定性量表。二值检查用于核验绝对不可妥协的硬性指标，非对即错；定性量表用于评估连贯性、语调等主观体验。1

OpenAI 在构建韧性提示词的评估飞轮中也提出，自动化评测器通常分为两类：一类是格式与事实准确性的硬性检查（如可用性数据与真实基线比对），另一类是针对风格的主观评估。通过分析反复出现的失败模式，优先确保必须通过的底线指标不失分，再优化整体质量。2

OpenAI 的 GPT-5.2 提示指南进一步建议，执行任务时应严格限于用户明确要求的范围，避免擅自扩充未经支持的细节，并在交稿前扫描未声明的假设与过强措辞。3

分清两层要求的不同职责

必过门槛只做二值判断（PASS / FAIL）。它不负责评价写得好不好看，只负责守住成稿的事实与边界底线：

事实原样保留：日期、版本号、具体金额、责任部门、系统名称必须完全符合原始材料；
限定词完整：材料里的“仅限”、“暂未公布”、“部分支持”等限定范围，不可被删减或泛化；
禁止臆造内容：材料没有提及的原因、审批时限、未来规划或按钮入口，严禁顺手脑补；
硬性边界：如总字数绝对上限、必须包含的核心行动链接。

只要有一项判定为 FAIL，整篇成稿直接判定为不合格，必须立即阻断并指出具体错误，无需进入任何文笔打分。

质量滑杆则负责连续体验调节。它在所有必过门槛 100% 达成的前提下发挥作用：

语气刻度：在“正式庄重”与“平实质朴”之间寻找落点；
展开层次：在“极简要点流”与“完整段落叙事”之间分配权重；
句式节奏：长短句交替，避免机械的同构排比。

只有把门槛从评分表里拆出来单列，模型才不会用流畅的语气去稀释事实错误。

一条可直接复制的 Prompt 模板

把提示词分成任务上下文、原始材料、必过门槛、质量滑杆与交付协议五块：

你是严谨的中文内容编写助手。请根据提供的材料撰写成稿。

<task_context>
成稿类型：[例如：功能变更通知 / 客户沟通邮件 / FAQ 说明]
目标读者：[读者身份与已有认知背景]
读者目标：[读完后需要获知的事实、做出的判断或执行的动作]
</task_context>

<source_material>
[在此粘贴原始事实材料]
</source_material>

<must_pass_gates>
成稿发布前必须逐项核对以下 5 条硬性门槛，判定必须非 PASS 即 FAIL：
1. 事实一致性：材料中的日期、数字、版本、专有名词与责任主体，是否逐字原样保留？（PASS / FAIL）
2. 限定词完整性：材料中的限定范围（如“仅限”、“部分”、“暂不包括”）是否未被擅自放大？（PASS / FAIL）
3. 承诺边界：是否没有任何材料未提及的原因解释、时效承诺或未定结论？（PASS / FAIL）
4. 行动闭环：读者完成目标所需的操作入口或指引是否准确且完整？（PASS / FAIL）
5. 篇幅红线：总字数是否严格控制在[指定字数]字以内？（PASS / FAIL）
</must_pass_gates>

<quality_rubrics>
在上述 5 条门槛全部为 PASS 的前提下，按以下滑杆倾向优化表达：
- 语调：平实克制，少用煽动性副词，不出现“隆重推出”、“震撼上线”等套话。
- 结构：结论先行，先写变化与核心影响，再写应对动作，最后标注待确认事项。
- 密度：避免车轱辘话，同一事实不换词重复表述。
</quality_rubrics>

<delivery_protocol>
生成流程：
第一步：先输出《门槛核查表》，逐项标明 PASS 或 FAIL，并附一句话事实依据。
第二步：
- 若 5 项均为 PASS：在核查表下方输出正式成稿正文，不带助手式寒暄。
- 若存在任一项 FAIL：直接停止输出成稿正文，输出《阻断说明》，标明违规句子与打回原因。
</delivery_protocol>

这条提示词的关键在于 <delivery_protocol> 里的条件分支：必须先出核查表，存在 FAIL 则阻断正文交付。这种机制迫使模型在吐出成稿前先进行一次确定性的二值扫描。

用一则系统升级通知看拦截效果

以下是一段虚构的原始事实材料：

1. 核心数据库将于 10 月 15 日 02:00-06:00 进行例行停机维护。
2. 维护期间，用户端交易与提现功能暂停，查询功能不受影响。
3. 维护若超时，运维团队将通过群公告同步进展，恢复的具体时间暂未确定。
4. 如遇紧急事故，拨打值班电话 010-88889999。

拦截演示：当 AI 擅自承诺时

如果提示词没有设置阻断机制，AI 常常会顺手写出：“预计不会超时，请大家放心，系统会第一时间自动恢复”。

在双层机制下，核查表会直接拦截该错误：

【门槛核查表】
1. 事实一致性：PASS（时间、功能影响、值班电话均与材料一致）
2. 限定词完整性：PASS（明确区分了暂停与不受影响的功能）
3. 承诺边界：FAIL（草稿中写有“预计不会超时”，而材料明确写明“恢复的具体时间暂未确定”，属于未经支持的擅自承诺）
4. 行动闭环：PASS（附有群公告途径与值班电话）
5. 篇幅红线：PASS（字数在限制内）

【阻断说明】
触发第 3 项门槛阻断。
违规表述：“预计不会超时，请大家放心”。
修改动作：删除擅自保证的措辞，严格按照材料标注“若有超时将通过群公告同步，具体恢复时间暂未确定”。成稿正文已暂停输出，待修正后重新生成。

放行演示：门槛全过后的成稿

当所有门槛项全部显示 PASS 后，质量滑杆开始发挥作用，生成干净克制的成稿：

【门槛核查表】
1. 事实一致性：PASS（10 月 15 日 02:00-06:00、暂停交易与提现、查询正常、电话 010-88889999）
2. 限定词完整性：PASS（明确了停机时间段与受影响功能范围）
3. 承诺边界：PASS（未承诺必定按时完成，注明具体恢复时间待定）
4. 行动闭环：PASS（交代了超时获取信息的渠道与紧急电话）
5. 篇幅红线：PASS（正文共 136 字，符合 200 字以内要求）

【成稿正文】
核心数据库将于 10 月 15 日 02:00 至 06:00 进行停机维护。

维护期间，交易与提现功能暂停服务，数据查询功能不受影响。

请相关业务团队提前调整操作安排。若维护超出预定时间，运维团队将通过系统群公告同步最新进展，具体恢复时间暂未确定。如有紧急突发事项，请拨打值班电话 010-88889999。

为什么分开后更容易控制质量

把门槛和滑杆混在一起时，人的大脑和大语言模型都会面临注意力稀释。当指令同时包含“亲切生动”和“绝对准确”时，模型在概率采样中往往会为了让句子读起来更有温度，而给客观事实增添修饰词。这些修饰词一旦越界，就会演变为虚假承诺或模糊表述。

将要求拆分后，两者的运行逻辑互不干扰：

门槛是确定性断言：它对应的是材料里白纸黑字的证据，检验的是准确性底线。
滑杆是偏好度调节：它处理的是句子长短、用词风格和阅读体验，属于润色层。

这种结构也让后续的 Prompt 调试变得清晰。如果成稿经常出现事实纰漏，说明是门槛项不够具体，应该收紧二值检查标准；如果成稿事实完全正确但读起来像机器翻译，说明门槛已经稳固，此时只需在滑杆层调整修辞引导，而不需要重写整套提示词。

适用场景与安全边界

这条实践适合所有对事实准确度要求严苛、容错空间小的书面写作：

业务与系统通知：时间节点、受影响范围、备选方案明确的公告；
客户服务邮件与 FAQ：退换货规则、赔付标准、处理时效等涉及权益的说明；
产品版本变更与操作指引：明确指引新旧功能差异与配置路径的文档；
跨部门协作与项目纪要：记录决策事实、代办人和明确截止期的汇报。

必须指出，提示词内的二值门槛是模型侧的一种自检过滤机制，它能大幅降低无意识的幻觉与过度发挥，但无法完全替代人工的事实核准与合规审批。原始材料本身的真实性、是否有敏感信息遗漏，依然需要写作者在发布前进行最终确认。

发布前 30 秒检查清单

在将双层 Prompt 投入日常使用前，可以快速过一遍以下 5 个关键点：

二值性检验：门槛列表中的每一项，是否都能非黑即白地回答 PASS 或 FAIL？（如果包含“写得比较好”等模糊字眼，请移入滑杆层）
阻断声明：提示词中是否明确写出“任一项 FAIL 则立即停止输出正文”的规则？
事实对照：原始材料中的关键数字、日期和专有名词，是否在成稿中逐一完成了原文对齐？
限定词扫描：成稿中是否保留了“部分”、“暂定”、“仅限”等防御性限定词？
多余承诺剔除：成稿中是否删除了所有未经材料授权的“一定会”、“预计很快”、“无需担心”等口头承诺？

References

1
Define success criteria and build evaluations — Claude Platform Docs
docs.anthropic.com
2
Building resilient prompts using an evaluation flywheel — OpenAI Developers
developers.openai.com
3
GPT-5.2 Prompting Guide — OpenAI Developers
developers.openai.com