这本书要解决的问题
一份提示词写得好不好，和一个提示词系统稳不稳定，是两个问题。
前一个问题，市面上已经有很多答案：怎么写清楚任务、怎么举例子、怎么给复杂任务留出推理空间、怎么要求它输出 JSON。这些方法在合适的任务里都有效。第一篇会用最小篇幅把这层基础讲清楚，但不会整理成一套现成模板。它们主要回答的是“这一次怎么答得更好”。
后一个问题是：当一段提示词开始承担业务闭环——它要在多轮对话里记住用户说过什么，判断什么时候可以推进关键动作，决定这一轮该问哪个字段，保证不重复索取已经拿到的信息，在适用范围内记住用户的拒绝、不再反复追问，最后把结果交给下游系统——它还能不能在长期、大量的真实会话里，稳定地做对同一件事。
这时候你面对的已经不是一段文案，而是一个提示词系统：提示词、状态、控制、验证与提交共同构成的运行时系统。本书讲的就是这样的系统。
这两个问题的差距，比大多数人预期的要大。
第一个问题的失败是“这次答得不够好”，重写一遍就行。第二个问题的失败是：规则明明写在那里，模型某些时候就是不执行；同一句输入，今天测是对的，明天测就错了；禁掉一种说法，它换一种同义的说法绕过去；补一条例外，另一个场景就塌了。你会发现自己在打地鼠，而且地鼠越打越多。
如果你已经经历过“规则写了但模型不执行”，那么这本书是为你写的。如果你还没有，可能是因为你的系统还足够简单——第 5 章会告诉你，那其实是件好事，很多任务本来就不需要走到这一步。
这套方法是怎么长出来的
它不是先从文献里搭出一套理论，再回头找案例佐证。它首先来自一个真实系统的反复失败。
那是一个真实的多轮 AI 客服系统：它回答产品问题、识别用户需求、持续维护关键信息，并在需要后续处理时把请求交给业务系统。书中涉及的提示词设计、测试方案、重构和复盘由我独立完成；客服反馈、业务要求和技术运行环境构成了项目发生的真实背景。它的提示词从三十几行开始，几个月之后长到两千两百行，然后开始不听话。我花了很久才明白问题出在哪里，又花了更久才明白，“提示词写得不够好”从来不是那个问题的答案。第 1 章是这份病历的完整记录，包括我当时的误判——那个误判很合理，也差点让我在错误的方向上继续修。
后来发生了一件有意思的事：那些在生产里折磨过我的现象——规则越加越多之后开始互相干扰、用户分几轮说出来的信息更容易丢、写在长材料中间的内容更容易被忽略、把流程完全交给模型自己决定就变得难以预测——我陆续在一些公开研究里读到了可以互相参照的结果。这些结论在不同模型和不同任务上的表现并不一致，具体证据与适用条件放在对应章节交代；它们不构成本书方法的依据，但让我确认了一件事：我撞上的不是这一个项目的怪毛病。先在生产里撞上，后在研究里看懂——这个顺序比反过来更踏实。
为了降低真实企业、客户或具体项目被反向识别的风险，本书不公开案例所属行业。机构、产品、人物、对话和部分流程细节均经过抽象或同构改写；正文统一把它称为AI 客服系统。改写保留的是故障结构、状态变化、约束关系和工程决策，不代表原项目的原始业务记录。
涉及具体对象时，正文统一使用“产品 A／产品 B”“A 公司／B 公司”“后续业务人员”等通用称呼；“单位、联系人、联系方式”只作为多轮状态字段示例。它们不是把真实项目伪装成另一个行业，而是把与论证无关的业务特征拿掉。读者只需要关注：多轮状态怎么保存，关键动作由谁批准，外部结果怎样确认，以及系统出错后如何定位。
真正让我决定把它写成一本书的，是回头整理那些修改记录、事故复盘和几个版本的提示词原文时的一个发现：从提示词到槽位、闸门、状态机、契约和可观测，并不是一堆零散技巧的堆叠，而是一条有明确台阶的工程升级路径——每一级都在解决上一级解决不了的问题。关于“怎样把一句提示词写好”的资料已经很多；关于“提示词开始承担生产流程之后该怎么办”的系统讨论，还很少。
也正因为来源如此，有件事必须提前说清：这本书的生产证据主要来自同一套项目体系。 主要材料贯穿一条业务线，少量对照来自同一体系下的另一条业务流；它们不构成跨项目、跨行业的独立复现。我会把机制抽象成尽可能通用的形式，但不能据此声称它们已经在所有领域得到验证。可以迁移的是问题结构与工程方法，不能直接迁移的是项目里的数字、阈值和效果幅度。这不是谦虚，而是一本技术书应该交代清楚的边界。
这本书讨论什么，不讨论什么
它不是提示词技巧合集。 你不会在这里找到一百条现成模板。越往后读，本书越关注哪些职责应该继续留给模型，哪些职责应该由确定性机制承担。
它不涉及模型训练、微调与部署。 本书面向多轮对话与 Agent 类应用，讲的是运行时的状态、控制流、契约与治理。数据工程、监督微调、偏好对齐、推理优化、向量库选型一样都不讲，那些内容有更好的书。
“提示词系统”不是“提示词管理平台”。 市面上有一类叫 Prompt Management 的工具，负责提示词的版本存储、模板变量、A/B 分流与调用统计。它们很有用，但不是本书的主题——本书说的是前面定义的那个运行时。你可以用任何管理平台托管它，也可以完全不用。
它也不是入门书。 我假定你已经写过提示词，并且亲手搭过、测过，或者深度参与过一个基于大模型的应用；你至少知道检索增强和工具调用大致解决什么问题。第一篇会快速过一遍基础，但那是为了统一术语和确立取舍标准，不是从零教学。
这本书怎么读
全书六篇，是一条从简到繁、最后又往回收的路。
第一、二篇从一句提示词出发，走到上下文、检索与工具——讲怎么把任务定义清楚，以及怎么管理模型看见的世界。
第三、四篇是全书的重心：怎么让对话拥有可解释的状态（槽位、证据、归并、闸门、决策表、状态机），以及在具备应用层条件时怎样继续工程化（什么适合留给模型、什么适合由确定性机制承担，怎么拆开一次模型调用，怎么验证、提交与回滚）。
第五、六篇讲怎么验证、治理与落地。第 24 章用贯穿案例的问题结构构造一套可复现的新系统走查；第 25 章回到真实旧提示词，讲迁移顺序、验证方式和应该停在哪里。
全书贯穿的是同一组业务问题和同一套职责，不是把一个真实项目改写成从 L1 一路实现到 L5 的历史记录。真实项目提供故障、重构和版本证据；目标架构、构造走查与配套仓库负责展示具备应用层条件后可以怎样继续推进。为了让阅读保持连续，这条方法线上有两件事值得留意。
第一，中途有三个停靠点。每到一个停靠点，我会明确告诉你：“如果你的任务是这一类，读到这里就够了，再往下加是过度工程。”这本书的主张从来不是“每个系统都需要状态机”，而是用能解决问题的最小复杂度。
第二，演进线中间有一次减法。真实项目先做的，不是把格式校验、计数和状态持久化真正迁入外部程序，而是把它们从散乱的自然语言补丁中拆出来，在提示词内部改写成槽位、规则表、状态机和检查清单。这一步让职责边界变得清楚，但执行这些结构的仍然是模型。第 16 章会先交代这个真实停点，再讨论具备应用层条件时，哪些确定性职责应该继续迁往代码、存储或工作流节点。配套仓库中的实现用于展示这一步怎样落地，不冒充原项目已经完成的生产改造。
配套代码仓库提供三个停靠点（A/B/C）的可运行参考实现，覆盖书中的核心组件；代码注释反向标注章节号，正文与实现可以互查。
三条阅读路径：想从头系统学，按顺序读；手上已经有一个正在出问题的系统，先读第 1 章和第 25 章，再回到第三、四篇；只负责安全与合规评审，可以先读第 23 章，把它当作整套系统的安全复查入口。如果对槽位、闸门、作用域等术语不熟悉，建议先读第 2 章的职责地图。
关于证据与时效
对影响设计取舍的机制，我会尽量同时交代三件事：它防的是哪一类真实失败，它的代价是什么，以及什么时候不该用它。正文按需要使用四种标记：研究支持表示有外部研究可供印证；生产观察表示结论来自本书案例系统；适用边界说明结论在什么条件下可能失效；时间数据只在引用容易随模型、版本或市场变化的信息时使用，并写明参考时间；原始日期没有完整保留时也会明确说明。这样读者不必自己猜测每个判断的证据强度。
讲大模型的技术书，都绕不开一个问题：过时。
我的处理办法是把内容分层。机制与方法——状态怎么建模、闸门怎么设计、失败怎么定位、评测怎么做——属于相对稳定层，它们依赖的是“模型是概率生成器而不是规则解释器”这个基本事实，而不是某个具体模型的脾气，写进正文。架构与工艺——调用怎么拆、成本怎么算、缓存怎么用——同样进正文，但会标注“实现随平台变化”。如果正文必须引用具体模型的行为、价格、上下文长度等容易变化的信息，则放进“时间数据”框并注明参考时间；不依赖这些数据就能成立的论证，不为了凑标记而额外引入它们。
勘误与更新统一维护在 https://prompt2system.com。带版本号的发布版固化生命周期较长的部分，在线版负责追赶变化快的部分——这是我能给出的、对读者比较诚实的安排。
最后
这本书的结论，可能和书名给人的第一印象相反。
它不会教你写出更长、更强、更聪明的提示词。你会发现越往后，方法会先把状态、规则、闸门和验证从自然语言叙述中拆开，用结构化、代码式的方式显式表达；当系统具备应用层条件时，再把确定性的计算交给代码，持久的状态交给存储，权限和副作用交给应用层。留给模型的，是语义理解、模糊判断和语言表达。
这不是对模型能力的不信任，而是分工：让模型处理它擅长的语义与语言，让确定性的要求落到能够被验证、测试和约束的机制里。
提示词工程的终点，不是写出越来越高级的提示词，而是逐渐知道什么不该继续写进提示词。
那两千两百行教会我的，最终是这句话。
