跳转至

提示词心智模型：正确性的定义与边界

绝对正确的 Prompt 不是追求“像人一样会说”，而是让模型输出在目标场景下格式确定、依据可审计、失败可兜底。

本章把提示词工程重新定义为软件工程的一部分：Prompt 是交付物，需要版本控制、验收门槛、回归样本与回滚机制。

章节插图占位：提示词从聊天到交付

先把幻觉掐死：你不是在“沟通”，你是在“定义接口”

很多人写 Prompt 的姿势像写朋友圈：先抒情，再许愿，最后祈祷模型懂你。你以为你在“表达”，模型只会把它当作一段噪声上下文，继续按概率补全它最熟悉的套路句式。

换句话说：不写接口，你就只能赌采样。

你现在可能卡在： 1. 提示词时好时坏，不知道改了哪里就崩了。 2. 模型废话连篇，解析器总是报错。 3. 一旦模型瞎编，你完全没法追踪它是怎么胡扯的。

本章要交付给你的，是一套把自然语言变成确定性调用的工程标准。

提示词正确性的三个等级

不要把所有 Prompt 都写成“生产级”，那是浪费时间。按下游容错率，我们将 Prompt 分为三档：

Level 1：草稿级（Draft）

  • 场景：个人探索、头脑风暴、一次性生成。
  • 验收：人能看懂即可；允许多轮澄清；允许结构不稳定。
  • 风险：不可复用；不可接入自动化流水线。

Level 2：协作级（Collaboration）

  • 场景：团队内部复用、文档产出、批量内容生产。
  • 验收：结构一致（标题层级/表格列/字段名稳定），别人照着就能用。
  • 风险：若进入下游流程（脚本/Agent），往往因为标点或格式微调导致解析失败，需要升级到 Level 3。

Level 3：机器执行级（Machine Execution）

  • 场景：API 输出、Agent 工具链、CI 批处理、任何需要解析器消费的输出。
  • 验收：语法零容忍。严格遵循 JSON Schema 或固定 Markdown 模板；失败必须可检测（退出码/错误码/特定关键字）。
  • 风险：不写失败判定与回滚，就是把事故写进系统默认值。

核心工具：Prompt 交付合同

不要直接开始“写 Prompt 正文”。先把它当作合同填一遍，缺字段就不允许进入协作或机器执行。这是你的第一个模板。

模板 1：Prompt 交付契约表

### Prompt 交付合同

| 维度 | 定义/约束 |
| :--- | :--- |
| ID & Version | <例如：prompt.code_review.v1> |
| 级别 | Draft / Collaboration / Machine Execution |
| 任务 | <一句话：要模型完成什么> |
| 受众 | <人类读者/解析器/下游系统> |
| 输入契约 | 格式：<纯文本/Markdown/JSON>；必填字段：<...>；最大长度：<...> |
| 输出契约 | 格式：<Markdown/JSON>；禁止出现：<寒暄语/多余解释/未定义字段> |
| 判定标准 | Pass/Fail 规则：<可脚本化的检查点> |
| 失败判定 | 命中即失败：<JSON 解析失败/缺关键字段/出现违禁短语> |
| 回滚/降级 | 失败后动作：<重试一次/降级为简版/返回固定错误结构> |

替换指南：只替换 <...>，其余字段保持不变，避免每次写 Prompt 都变口径。

实战示例：机器执行级文本生成

目标：生成一份“可解析、可审查”的 Python 代码审查报告。 要求：禁止客套话；无问题输出 PASS；有问题必须按表格输出。

模板 2：严格结构化审查 Prompt（直接运行版）

此命令将直接在你的终端运行，并将结果保存到 out/review_result.md，方便后续脚本读取。

mkdir -p out
cat <<'PROMPT' | <LLM_CLI> > out/review_result.md
你是 Python 代码审查工具（不是聊天助手）。

输入：一段 Python 代码。
输出：只输出 Markdown（不要输出任何对话、问候、解释性前言）。

硬约束：
1) 若无明显问题，直接输出 PASS。
2) 若有问题，必须按固定结构输出（见下方模板），且表格列名不得改动。
3) 禁止输出推理过程；改为输出“审查依据列表”（最多 6 条）。
4) 严禁使用 markdown 代码块包裹整个输出，直接输出正文。

输出模板：

## 审查摘要
- 评分：<0-100>
- 状态：PASS/WARN/FAIL

## 问题清单
| 行号 | 级别 | 问题描述 | 建议修复 |
| --- | --- | --- | --- |

## 审查依据列表
1. <...>

代码：
def fetch_data(url):
    import requests
    return requests.get(url).content
PROMPT

实战示例：图片生成配置（无文字底图）

目标：为技术文档生成“系统架构示意图”的底图，禁止文字与水印，避免乱码风险。 注意：这里输出的是给画图模型的提示词配置，而不是直接生成图片。

模板 3：无文字架构图配置块

示例插图占位：生成的架构底图效果

image_prompt:
technical sketch style, flat 2D vector art, minimal color palette (blue, white, grey), clean composition,
abstract software architecture diagram with three layers (client/server/database) represented by geometric shapes,
directional arrows showing data flow, high contrast, solid white background

negative_prompt:
text, letters, numbers, watermark, signature, handwriting, 3d, isometric, photorealistic, shadow, blurry, messy lines, noisy background, humans, faces

params:
aspect_ratio=16:9, quality=high

静态审查清单（提交前必过）

在运行 Prompt 之前，先过一遍这个静态检查。这能帮你省下 80% 的调试 Token。

  1. 量化模糊词：是否清除了“尽快/适当/专业/好看”等词，并改写为阈值/数量/具体窗口？
  2. 载体明确：是否明确了输出载体（Markdown/JSON/表格），并给了固定模板或 Schema？
  3. 负向约束：是否写清“不做什么”（禁止项），而不是只写“别废话”这种不可执行要求？
  4. 审计线索：是否要求输出依据列表、检查点列表或不确定性清单，方便人工或脚本复核？
  5. 失败兜底：是否包含失败判定（命中即失败）和降级/回滚动作（失败后做什么）？
  6. 事实边界：若涉及事实，是否依据 02-facts.md 的规则，配置了拒答或冲突并列机制？
  7. 无字检查：若是图片 Prompt，是否包含 negative_prompt 并明确 no text 语义？

常见陷阱与修复（失败样本库）

1) 话痨输出（Chatty Output）

  • 现象：要求输出 JSON，模型在 JSON 前后加“好的，这是结果”，导致 json.loads 失败。
  • 根因：模型默认处于对话礼貌模式；你没把“输出纯净度”写成硬约束。
  • 修复：添加约束“只输出数据结构本体；禁止任何前后缀文本；禁止 Markdown 代码块包裹”。
  • 验证：连续运行 10 次，输出可直接被解析器读取。

2) 幻觉补全（Hallucination Fill-in）

  • 现象：输入缺少信息，模型仍给出确定结论，或编造“来源/数字/术语解释”。
  • 根因：你隐含传达了“必须回答”；没有给“未知出口”。
  • 修复：加规则“仅基于提供材料；缺信息必须回答‘材料未提及/无法确认’，并列出缺失字段”。
  • 验证：输入缺关键字段时，模型输出“缺口清单”，而不是编造细节。

3) 逻辑跳步（Un-auditable Leap）

  • 现象：模型给出决策结论，但无法指出依据来自哪里，或结论与依据不匹配。
  • 根因：你只要结论，不要“检查点”；模型会跳到概率最高的答案句式。
  • 修复：强制输出“依据列表 -> 阈值检查 -> 最终结论”三段式结构。
  • 验证：检查“阈值检查”与“最终结论”是否逻辑自洽；不一致即判失败并回炉。

下一章：02-facts.md