——全书导引
上一章结尾停在一个问号：提示词回涨到七百行之后，路该往哪里走。
但在回答“往哪走”之前，得先回答一个更基础的问题：我现在在哪。 这一章给两把尺子和一张图——量清楚位置，你才知道这本书的二十多章里，哪几章现在就该读，哪几章可以先放着。
一、同一个问题，三种答案
为了说明这种差异，先看三个经过抽象的典型场景。它们都会问出几乎相同的一句话：
“我们这个系统，要不要上状态机？”
而正确答案并不相同。
场景一：工单自动分类。 用户提交一段描述，系统判断它属于哪一类问题，转给对应的处理队列。单轮、无状态、结果可以直接和人工标注比对。困扰是分类准确率上不去，尤其几个相邻类别老是混。
答案是：不要。问题在示例和标签定义上，加状态机只会多出一堆永远停在同一个状态的字段，然后要额外花时间维护它。
场景二：产品知识问答。 接了一个几千篇文档的知识库，用户问什么答什么，偶尔追问两句。困扰是有时候会答出知识库里没有的内容，还有时候把 A 产品的参数安到 B 产品头上。
答案是：还不到时候。这里缺的是证据和引用的约束——回答必须能追溯到具体片段，追溯不到就说不知道。这件事和状态机没关系。
场景三：多轮产品客服。 要持续收集需求和必要信息，判断用户是否需要后续处理，并在条件满足时生成摘要交给后续流程。困扰是“用户明明说过的东西，它过两轮又问一遍”，以及“有时候还没问全就把摘要发出去了”。
答案是：早就该上了，而且这里遇到的每一个问题，都是没有显式状态的直接后果。
同一个问题，三种答案。差别不在于哪一种做法更高级，而在于这三个系统处在不同的位置上。
如果没有一把尺子，这种判断只能靠经验，而经验是不可传递的。所以这一章先立尺子。
二、第一把尺子：六级工程成熟度
第一把尺子量的是你的系统已经工程化到了哪一步。
表 2-1 提示词系统的六级工程成熟度
| 级别 | 名称 | 它要解决的问题 | 该升级的信号 |
|---|---|---|---|
| L0 | 自然语言指令 | 让模型听懂这次要做什么 | 输出格式不稳，无法被程序消费 |
| L1 | 结构化提示 | 让任务、资料、格式互不混淆 | 规则说清楚了，边界情况仍然判错 |
| L2 | 示例与推理 | 用样例和推理方式把规则演给模型看 | 模型不知道的事、办不了的事开始变成主要瓶颈 |
| L3 | 上下文与行动 | 接入检索与工具，让它知道并且能办事 | 多轮之间开始丢信息、重复索取、流程走错 |
| L4 | 对话控制 | 用字段、闸门和阶段管住多轮业务闭环 | 状态算对但表达失控；确定性规则越堆越多；错误无法分层定位；版本优劣无法验证 |
| L5 | 系统工程化 | 拆开职责、立契约、可验证可治理 | —— |
表 2-1 只回答“问题发展到了哪一级”。图 2-1 再把第二把尺子放进来：上半部分看成熟度，下半部分查责任。两者不是一一对应关系——先判断当前问题处在哪个复杂度阶段，再判断具体故障落在哪项职责。
图 2-1 六级成熟度与九项系统责任
先澄清一个容易混淆的地方：这六级描述的不是六种不同的东西，而是同一个东西被工程化的程度。 从写下第一句提示词开始，你就在构造这个系统最初的组成部分。随着任务复杂度上升，原本不存在、或者由模型隐式承担的职责才会逐步出现，并被一个个显式化，再交给合适的承担者。“提示词系统”是对象，L0 到 L5 是这个对象的成熟度。
还有三件事必须说在前面。
第一，级别不是荣誉榜。 L5 不比 L2“高级”，只是更贵——更多的调用、更长的链路、更高的维护成本、更陡的上手曲线。前面那个分类场景如果去做 L4，做出来的不是更好的系统，而是一个更难改的系统。匹配比先进重要。
第二，升级由痛点触发，不由计划触发。 每一级的“该升级的信号”那一列，才是判据。信号没出现就升级，叫过度工程；信号出现了还在原地打补丁，就是上一章那个故事。
第三，级别之间不是台阶而是斜坡。 大多数真实系统同时具备好几级的特征：可能状态管理已经到了 L4，但评测还停在“人工看看”的 L2。这很正常，也正是尺子的用处——它能告诉你哪一段落后了。
所以本书不要求给整个系统打一个唯一等级。这把尺子适合用来判断“我现在面对的主要问题走到了哪一级”，而不是给系统颁一张证书。至于“问题具体出在哪项职责上”，那是第二把尺子的事。
适用边界 这是一个便于判断的经验阶梯，不是任何标准或规范。它对多轮对话类系统最有效；批处理、单轮生成、代码类任务的演化路径与此不同。跳级、停留、局部倒退都可能是合理的。
三、第二把尺子：九项系统责任
第一把尺子量“到了哪一步”，第二把尺子量“系统里有哪些职责”。
这九项职责不是每个系统都必须具备的九个模块，而是一张完整的职责地图。 随着系统进入真实业务并逐渐变复杂，它可能涉及下面九类职责——区别在于：有些还不存在，有些隐含在提示词里，有些已经被显式实现。
表 2-2 参考架构的九项系统责任
| 层 | 负责什么 | 这一层出问题时的典型表现 |
|---|---|---|
| 任务层 | 这次要做什么、什么算做对 | 答非所问、格式无法解析 |
| 上下文层 | 这一轮模型该看见什么 | 该看的没看见、不该看的干扰了判断 |
| 证据层 | 哪些信息有依据、来自哪里、可信到什么程度 | 编造事实、张冠李戴、引用不可追溯 |
| 状态层 | 当前哪些事实仍然有效 | 重复追问、旧值污染、用户改口后不生效 |
| 控制层 | 此刻允许做什么、应该做什么 | 条件没满足就推进、该推进时卡住 |
| 行动层 | 调用外部世界并拿回真实结果 | 声称已完成而实际没有发生 |
| 表达层 | 把决定好的事说成人话 | 话术改掉了业务决策、一轮问了三个问题 |
| 验证层 | 发出去之前再检查一遍 | 明显违规的内容直接送到用户面前 |
| 治理层 | 版本、评测、可观测、规则生命周期 | 无法证明新版更好、出了问题定位不到 |
这张表最有用的不是左边，是右边那一列。当线上出现某种症状时，它直接告诉你该去哪一层找问题——这就是第 20 章“失败定位”的雏形。
所以在一个 L1 系统里，这九项职责可能全部由同一段提示词兼任，其中好几项还是空的——没有工具就没有行动责任，没有回归集就没有治理责任。某项职责是否存在，和它是否被显式实现，是两回事。
四、把两把尺子叠起来
把成熟度和职责层放在一起看，会出现这本书最重要的一个观察。
表 2-3 成熟度升级与职责显式化
| 级别 | 新出现或被显式化的职责 | 主要由谁承担 |
|---|---|---|
| L0 | 任务层 | 提示词 |
| L1 | 任务层（显式化）、表达层雏形 | 提示词 |
| L2 | 上下文层（示例即上下文） | 提示词 |
| L3 | 证据层、行动层 | 提示词 ＋ 检索／工具 |
| L4 | 状态层、控制层 | 提示词为主，代码开始介入 |
| L5 | 验证层、治理层；状态层与控制层中的确定性逻辑逐步外置 | 确定性部分归代码，语义与表达归模型 |
看最后一行。L4 到 L5 描述的是一种目标分工，不是贯穿案例已经发生的历史。从 L4 继续工程化时，新增的职责其实不多，主要变化是重新安排承担者：状态怎么合并、什么时候允许做什么、字段格式是否合法、问过几次，这些确定性工作在具备应用层条件时，应逐步交给代码、存储或工作流中的确定性节点；模型更多负责语义理解、模糊判断和语言表达。
注意搬走的是确定性的那部分，不是整层。即使在 L5 系统里，从用户那句话里认出“他在改口”、判断两句话是不是同一个需求、给工具生成合适的参数，仍然是模型的工作。
生产观察 这解释了上一章那个问号。两千两百行的时候，项目是在用 L2 的手法（改措辞、加禁令）解决 L4 的问题（状态与控制）；一百七十五行是把 L4 的核心骨架在提示词内部显式化了；而回涨到七百行说明，只要状态与控制的权威执行仍然依赖模型理解提示词，复杂度就会持续累积。贯穿案例真实完成的是这一步，还没有把这些职责整体迁入外部代码和存储。L5 描述的是下一阶段的工程方向，不是本项目已经完成的生产事实。
所以这本书的书名不是修辞。从提示词到系统，不是把提示词写得更长，也不是给它换一个更大的名字，而是先把原本混在一段文字里的职责分开，再根据风险、成本和平台条件，把确定性的职责交给更合适的承担者。
两把尺子的分工到这里也清楚了：六级回答“我现在面对的是哪一阶段的问题”，九项职责回答“问题具体发生在哪项职责上”。 前者决定你该读哪一篇，后者决定你该查哪一章。
这里先堵一个很容易产生的误解：本书后文所说的“交给代码”，并不只指手写程序。 普通代码、规则引擎、数据库约束，以及可视化工作流平台里的确定性节点，都可以承担这些职责。
这里区分的不是界面形式，而是每项职责由谁承担——模型理解语义，确定性执行层落实规则，外部事实源提供可核验的结果。至于工作流平台具体该放在哪一格，第 16 章会正面回答。
五、全书的骨架：参考架构
如果把职责搬家之后的系统画出来，就是图 2-2。它是本书第三、四篇的骨架，后面每一章基本都在放大其中的一格。
图 2-2 提示词系统参考架构
为了便于纯文本阅读和复制，下面保留同一架构的文字版：
┌───────────────────── Trace 贯穿全链 ─────────────────────┐
│ 成功与失败同等记录——被拦截、被拒绝、没提交，尤其需要留痕 │
└─────────────────────────────────────────────────────────┘
输入（用户消息 / 工具回执 / 外部事件）
↓
Evidence 证据：谁说的、原话是什么、什么时候说的
↓
Event 事件：这句话对系统意味着什么（新增／纠正／拒绝／撤回）
↓
Reducer 归并：把事件折叠进已有事实
↓
候选状态 ← 本轮算出来的，尚未生效
↓
Gate 闸门：此刻允许做哪些事
↓
Policy 策略：在允许的事里，这一轮做哪一件
↓
Planned Action 计划动作 ─┬── 对话动作 ──────────────┐
└── 工具动作 → 执行 → 回执 ─┘
（回执重新变成证据，回到上面）
↓
Renderer 渲染：把决定好的事说成人话
↓
Validate 验证：发出去之前再检查一遍
↓
Commit 提交：候选状态转为已提交状态，消息发出图中的 Commit 只表示本轮状态与消息的提交；工具已经造成的外部副作用不等价于这里的 Commit——三种“提交”的区别在第 18 章。
为了让母图保持可读，图 2-2 没有把不变量单独画成节点：候选状态形成后先检查状态不变量，计划动作形成后再检查动作不变量；两类检查的具体位置在第 15 章展开。
这一章不解释每一格怎么实现——那是第 10 到第 18 章的事。这里只说明为什么是这个顺序，因为顺序本身就是全书的三条主张：
第一，证据先于状态。 先确定“发生了什么、这条信息来自哪里”，再决定“它对系统意味着什么”。证据不只来自用户，也来自检索结果、工具回执和外部事件。把两件事混在一起，就会出现“模型觉得他大概是想留电话”这种既非事实也非决策的中间产物。
第二，状态先于决策。 先把事实合并完整，再判断该做什么。反过来做——先想好要问什么再回头找理由——就是重复追问的根源。
第三，决策先于表达。 先确定这一轮做哪件事，再考虑怎么说得自然。让话术层有权改动决策，是“状态算对了但话说错了”的一个常见根源。
这三条会在后面反复出现。你可以把它们当作本书的三条红线。
适用边界 完整实现这条链是有成本的：更多的调用、更多的代码、更长的链路。第 5 章会给一棵判断树，帮你决定应该在哪一格停下——大多数系统不需要走完全程，走完全程的系统也不是一开始就走完的。
六、术语约定
在讲机制之前，需要先约定几个词。
这不是形式主义。在一个团队里，三个人说“状态”时很可能指着三样东西——一个指对话历史，一个指用户填过的字段，一个指流程走到了哪一步。词不统一，讨论就是各说各话。
本书全程使用下面这套词。完整定义见附录 A，这里先给最小可读集合：
表 2-4 核心术语的最小定义
| 术语 | 在本书中的含义 |
|---|---|
| 提示词 | 一次调用中提供给模型的指令与材料 |
| 提示词系统 | 提示词、状态、控制、验证与提交共同构成的运行时系统 |
| 证据 | 有出处、可追溯的原始信息（谁说的、原话、何时） |
| 事件 | 证据对系统状态的影响（新增／纠正／拒绝／撤回／新范围） |
| 归并 | 把事件折叠进已有事实的过程 |
| 候选状态 | 本轮算出、尚未提交的状态 |
| 已提交状态 | 通过验证并生效的权威状态 |
| 闸门 | 判断“此刻允许做什么”的唯一判定点 |
| 策略 | 在允许的动作中选出这一轮唯一要做的那件 |
| 渲染 | 把已批准的动作变成自然语言 |
| 验证 | 发出前的最后一道检查 |
| 追踪 | 一轮执行的完整记录，可回放 |
其中最需要提前说清的是字段状态。本书里，一个字段不只有值，还有状态；而且“字段现在是什么状况”与“系统对它做过什么”分属两组，不能混：
状态（互斥，七选一）
未知 / 有效 / 无效 / 已拒绝 / 冲突 / 已过期 / 已撤回
元数据（与状态正交）
问过几次、上次何时问、是否经用户二次确认、证据来源、适用范围为什么必须分开：一个用户可能“被问过而且拒绝了”。如果把“问过”塞进状态枚举，这种再普通不过的情况就无法表达。这是第 10 章的核心论点，也是很多系统重复追问的真正原因。
七、怎么用这本书
先量位置，再决定读法。 这是这一章存在的全部理由。
- 如果你在 L0–L2：从第一篇读起，重点是第 5 章——它会告诉你，你可能根本不需要往下走。分类器、抽取器、单轮生成类任务，做扎实 L2 就够了。
- 如果你在 L3：第二篇是你的主场。检索接了、工具接了，问题多半出在证据和行动的边界上——什么是证据、什么是指令、模型能不能宣称一件事已经完成。
- 如果你在 L4：直接进第三篇。你的症状（重复追问、提前推进、状态对话术错）在第 10 到第 15 章逐个对应。
- 如果你在 L4 但提示词正在回涨：先读第 16 章，再回到第三篇。这是上一章那个系统的处境。
- 如果你负责安全或合规评审：可以先读第 23 章，把它当作安全复查入口；如果对槽位、闸门、作用域等术语不熟悉，先看本章的职责地图。
关于本书的三个阅读装置，前言已经交代过。这里再把适用边界说清：本书用同一组问题解释 L1–L5，但真实项目可核验的演化停在 L4 的提示词内结构化。 L5 由第 16 章的目标分工、第 24 章的构造走查和配套参考实现来展示。三个停靠点回答的是“什么复杂度已经够用”，不是这个真实项目依次经历的三个生产阶段。
正文按需要使用四种标记：研究支持（有外部研究印证，条件在对应章节说明）、生产观察（来自本书案例系统的实践结论）、适用边界（该结论的失效场景）、时间数据（只用于容易随模型、版本或市场变化的信息，并注明参考时间；原始日期缺失时明确说明）。没有相应类型的信息时，不为了形式完整而强行加框。这些标记用来帮助你区分不同结论的证据强度。
八、回到那个问号
现在可以把上一章的时间线重新读一遍了：
三十几行 L0–L1：能用，也够用
↓
2200 行 用 L2 的手法（改措辞、加禁令）解决 L4 的问题
↓
175 行 显式字段、唯一闸门、固定主干，进入 L4
↓
700+ 行 L4 做对了，但状态与控制仍在提示词里，复杂度继续累积
↓
？ L5（目标形态）：确定性职责逐步迁往代码、存储或工作流节点那个问号的答案，就是这本书剩下的部分。
但在走向它之前，我想先泼一盆冷水——大多数系统不需要走到 L5，有些甚至不该离开 L2。 判断的方法，是下一篇要讲的第一件事。
