结章　什么时候应该停止写提示词

一、先澄清“停止写提示词”

“停止写提示词”不是“不再需要提示词”。

只要系统还在用通用语言模型处理自然语言，就仍然要把任务、必要输入、语义边界和输出契约明确提供给模型（第 3 章）。这些信息不一定全都塞在一段自然语言提示词里——结构化输出可以由平台承载，上下文由应用层注入，工具约定由工具定义承担。提示词仍然存在，只是不再承担整套系统的全部职责。

真正该留给模型的，是代码难以替代的那部分：语义理解、模糊判断和语言表达。 把“电话就不留了”解释成一个明确的结构化事件，就属于这一类——只靠关键词和手写规则，很难可靠覆盖开放语言里的各种表达。第 16 章那条分工的另一半始终成立。

所以真正的问题从来不是“要不要写提示词”，而是：

哪些事，不该让提示词做。

第 1 章那份两千两百行的提示词，问题不在于写得不够好。当时我确实很努力：措辞改了又改，重要规则反复强调，每次事故都补上一条新规则。在“把它当成文案”这个前提下，那些做法几乎都是对的。

错的是前提。状态、控制流、权限、副作用——这些是软件工程要处理的东西。你没法靠把一句话说得更重来让一个状态机变得可靠。

二、真正的判据：下一步由谁决定

这本书讲的是从提示词走向系统的工程过程。“提示词系统”不是一个和工作流、Agent 并列的产品形态——它是被工程化的那个对象，而工作流、状态机、Agent 式规划都是它内部可以采用的控制方式。

真正值得区分的是一根轴：“下一步做什么”这个决定，主要由谁作出。

表 结-1　对话控制方式的演化

这四种不是互斥的产品形态，而是四种运行时控制方式。 一个生产系统完全可能同时包含其中几种——外层是确定性编排，某个节点里让模型在有限动作集合中选择，另一个节点交给多步规划。

这根轴上有一条代价关系：

模型拥有的运行时决策权越大，系统越灵活；相应地，直接可预测性通常越低，对权限边界、验证、追踪和评测的要求就越高。

注意它说的不是“越往右越差”。决策权交出去之后，可预测性不是凭空消失了，而是必须由别的机制重新挣回来。第 9、15、18、20 章讲的权限、不变量、验证和追踪，就是用来补回这部分可预测性的。

所以第 5 章那条原则在这里有了最大尺度的说法：能用更确定的控制方式解决的问题，不要交给更自由的那一种。 一个流程固定的业务用多步规划去跑，你付的不只是算力成本，更是行为更难预测、更难解释、也更难验证的成本。

反过来同样成立。用提示词去承担本该由状态承担的职责，就是第 1 章那份病历——它不是不够努力，是把决定权放错了地方。

三、关于 Agent 的一点保留

一种常见的说法是：这些状态、闸门、契约都太重了，Agent 会让它们变得不必要。

我的判断相反。前面二十五章的东西在 Agent 里不会消失，而是会随着步骤、工具调用和中间结果不断累积：

证据与状态    Agent 的记忆同样会被污染，而且污染会沿着步骤传播
权限与作用域  Agent 能调工具，第 23 章那个"能查订单 vs 只能查这个用户的订单"
              的缺口，危害随工具数量放大
观测结果三态  每一步都可能返回 UNKNOWN，而后续步骤会基于它继续推进
验证与提交    每一次外部副作用都需要，步数越多需要得越频繁
追踪          多步之后如果不可回放，等于不可调试

多 Agent 编排更是如此。每增加一个能向其他组件传递文本、状态或工具结果的 Agent，就增加一条需要按外部输入治理的信任边界——另一个 Agent 的输出，对你这个 Agent 来说同样是外部文本（第 23 章）。

适用边界 上面这段是推论，不是本书验证过的结论。本书的实证材料来自单体多轮对话系统，没有覆盖多 Agent 编排的生产实践。把它当成一组值得先检查的问题，而不是一份结论。

不过有一件事可以说得确定些：在采用模型规划的场景里，“下一步建议做什么”更多由模型产生，但这没有改变“这个动作是否获准执行”，也没有改变“做完之后凭什么说做完了”。

第 9 章那条规则不会因为换了形态就失效：模型可以规划行动，系统仍然负责权限与执行，外部世界仍然决定行动是否真的发生。

四、这本书不能给你什么

按前言那条写作纪律，最后要把局限交代清楚。

第一，样本单一。 全书的生产证据主要来自同一套多轮 AI 客服项目体系；行业、产品、机构和部分流程细节已经为匿名化而抽象。这个处理让案例更便于讨论通用工程问题，但并不意味着这些方法已经在所有行业完成验证。问题结构与工程方法可以迁移，数字、阈值和效果幅度不能直接迁移。 书里出现的行数、条数、通过率，都是那一个项目在某个时刻的快照；你的系统会得到不同的数字，而且应该得到不同的数字。

第二，模型会变。 书里若干观察——长上下文的位置效应、多条约束并存时的遵循稳定性、重复运行的方差——都可能随模型代际变化。方法比现象耐久，但也只是比较耐久。 因此第 21 章把“换模型之后重新验证”当成常态，而不是意外。

第三，领域偏向。 本书面向多轮对话与 Agent 类应用。批处理、代码生成、创意写作的路径与此不同，其中一些结论会直接失效——比如“渲染的自由度只在措辞”这条，对创意写作就是错的。

第四，完全没有涉及的。 模型训练与微调；账号体系、传输加密、依赖漏洞这类通用安全（第 23 章已声明）；成本与延迟的深度工程优化；以及多智能体协作、智能体间通信、并行化编排与在线学习——这些属于另一类问题，已有专门的模式目录在讨论。本书与那类文献的关系是互补的：模式目录回答“有哪些做法”，本书回答“这些做法放进生产之后为什么会塌，以及靠什么守住”。 术语对照见附录 A 第十节。

所以这本书能给的不是一套现成方案：

它给的是一套判断依据——在你自己的系统里，用你自己的证据，决定复杂度该停在哪一层。

五、六条更接近系统性质的原则

如果这本书的其余部分都过时了，下面六条我认为还会成立——因为它们描述的更多是系统的性质，而不是某一代模型的特性：

一、能交给确定性机制的，不要压给概率生成器。（第 16 章） 确定性代码同样会错，但在相同的输入、版本和配置下，它的错误能够稳定复现，因此更容易被测试和回放。

二、未知不是空值。（第 10 章） 一个不能表达“我拿不准”的系统，会把每一次拿不准都变成一次硬猜。（第 15 章）

三、模型建议行动，不创造结果。（第 9 章） 对外说出的事实主张，必须与能证明它的结果严格对应——完成语需要结果证据，未来承诺需要可兑现的行动基础。（第 18、24 章）

四、复杂度的增加必须有证据。（第 5 章） 真实事故是证据，明确的业务要求、合规要求和已识别的风险同样是证据。不要凭想象增加复杂度，也不要为了等一次事故，才承认一个已经明确存在的风险。

五、没有评测，删除永远比新增危险。（第 19 章） 因为新增的理由具体，删除的理由抽象——没有退出机制的系统只会单调增长。（第 22 章）

六、不要让模型的服从性成为唯一防线。（第 7、23 章） 对每一条安全规则，假设它失效，然后看后果。

这六条都不建立在某个模型的具体行为特征之上。它们在今天成立，多半在下一代模型上也成立——因为它们说的其实是同一件事：在一个不保证确定性的模型之上，怎么搭一个仍然可以被验证、被约束、被信任的系统。

六、终点

回到第 1 章那份病历。

那段时间真正的错误不是把提示词写长了，而是我一直以为自己在写文案。写文案的隐含假设是：话说清楚了、说得足够重，对方就会照做。所以做法是改措辞、加粗、声明优先级、补充说明——较早审计快照里的 18 处“最高优先级”就是这么来的。后来其中 3 处被删掉，但提示词整体仍从 1925 行涨到 2196 行：局部在收敛，系统却还在增长。

而那个系统实际在做的事，是记住用户说过什么、判断什么时候可以推进、决定这一轮该问哪个字段、保证不重复索取、在被拒绝之后不再追问、最后把结果交给下游。

这些是状态、控制流、约束和副作用。它们属于软件工程。

这本书从头到尾只在做一件事：先把混在自然语言提示词里的职责一项一项分开，让证据、状态、闸门、验证和治理都有明确边界；再根据风险、成本和平台能力，把确定性的部分逐步交给代码、存储、工作流节点或独立验证器。贯穿案例真实完成的是前一阶段，配套参考实现展示的是后一阶段。留给模型、并由提示词约束的，是语义理解、模糊判断和语言表达。

所以这本书的题目，最终是这样一句话：

提示词工程的终点，不是把提示词写得更好，而是知道哪些事不该让提示词做。

最后一句给读者。

这本书记录的是一次具体的失败，以及一次发生在提示词内部的骨架重构；在此基础上，它继续推演了怎样把这些职责落到更完整的运行时。它给出的答案未必适用于你的系统。但如果它还有点用，大概不是因为哪个答案是对的，而是因为它提供了一种提问方式——

下一次线上出问题，先别急着改那句话。先问一句：

这件事，本来该由哪一层负责？