审计27条AI提示词后发现：22条都是废的——四段式提示词框架

一位长期构建AI智能体和自动化工作流的开发者，上个月做了件挺扎心的事：他打开自己积累了一年的prompts.md文件，像陌生人一样重新审读里面的27条提示词。结果是——22条没能通过一个最基本的测试：

把提示词交给别人，他们能不能得到和你一样的输出？

答案是不能。这个数字足够糟糕，糟糕到他把失败模式写了下来。而让人意外的是，这些失败模式枯燥、重复，而且每次都一模一样。

提示词失效的三种方式

作者把所有翻车案例归纳成了三类，每一类背后其实都是同一个问题：你以为自己说清楚了，但模型并不这么认为。

第一种：描述的是一种“感觉”，而不是一份“任务”。

You are an expert developer. Review this code and tell me if it's good.

这里没有任何标准可言。“专家”不是标准，“好”也不是标准。模型只能自己去发明你心里的那把尺子——而它周二发明的尺子，和周三的大概率不一样。

第二种：允许模型自行填补空白。

Summarise this customer feedback.

当输入信息很稀薄时，模型不会停下来。它会生成听起来很合理的填充内容，而你因为读起来通顺就直接发布了。这是最隐蔽的陷阱：错误被包装得很体面。

第三种：从没说清楚“完成”长什么样。

Write tests for this function.

你拿到了六个测试用例，但你真正想要的是边界情况。你没说哪些才重要，于是它只能靠猜。

真正的解法是“契约”，不是“更好的句子”

很多人优化提示词的方式是反复打磨措辞，换一个更漂亮的说法。但作者的观点很直接：问题不在句子的质量，而在于缺少一份明确的契约。

他用四个显式部分重写了全部27条提示词，同一个模型、同一天测试：

部分	回答什么问题	糟糕写法	良好写法
角色 Role	是谁，被哪种标准约束	“你是专家”	“你是审查PR的资深工程师，拒绝投机性抽象”
上下文 Context	它无法凭空发明的事实	（缺失）	“技术栈：Next.js 15 + Supabase，未知项标记为TODO”
约束 Constraints	硬性规则和禁止动作	（缺失）	“只标记真实缺陷，绝不发明diff里没有的API，不超过150字”
输出结构 Output schema	答案的确切形状	“告诉我好不好”	明确的JSON结构

下面是重写后的代码审查提示词全貌，可以清楚看到四个部分如何协同：

ROLE: You are a staff engineer reviewing a pull request. You optimise for
correctness and maintainability and reject speculative abstraction.

CONTEXT: Language: TypeScript. Framework: Next.js 15. The diff is below.
Tests: passing.

CONSTRAINTS: Only comment on real defects (bugs, race conditions, missing
error handling, security). Do not restyle. Never invent APIs that are not
in the diff. If the diff is too small to judge, say so.

OUTPUT: Return only JSON:
{"blocking":[{"file":string,"line":string,"issue":string,"fix":string}],
 "nits":string[],"verdict":"approve"|"request_changes"}

这套结构之所以有效，是因为它把模型需要“猜测”的空间全部压缩了：角色定下了评判标准，上下文给出了不可发明的事实，约束画出了禁区，输出结构则锁死了结果的形状。

重写之后，到底改变了什么

作者给出了两个可量化的变化，这也是整篇文章最有说服力的部分。

第一，输出不再漂移。 同一个提示词跑五次，返回的JSON结构完全一致。这意味着他可以直接把结果接进n8n节点，不需要额外的修复步骤。对任何做自动化流水线的人来说，这一点价值巨大——结构稳定才能被程序消费。

第二，模型不再瞎猜。 那个TODO的“逃生出口”把原本的“合理填充”变成了null，而null是一个可以被程序处理的明确值。

第二点才是真正少有人谈论的洞见。作者点破了提示词漂移的本质：

提示词漂移不是模型在随机发挥，而是模型在指令缺失时努力“帮忙”——而这恰恰就是你要求它做的。

换句话说，幻觉和漂移往往不是模型的缺陷，而是你的提示词给了它过多的自由裁量权。

文中提到将结果"接进n8n节点"，这涉及一个在AI工作流自动化领域日益重要的概念：结构化输出（Structured Output）。大语言模型默认生成自由文本，但当LLM作为自动化流水线中的一个节点时，下游程序需要消费确定格式的数据（如JSON、XML），而不是自然语言。目前主流的实现路径有两种：一是通过提示词约束（即本文的方法），在指令中明确要求输出特定格式；二是利用OpenAI、Anthropic等平台提供的原生结构化输出API（如OpenAI的response_format参数），从模型层面强制保证JSON schema合规。提示词层面的约束成本低、可移植，但在极端输入下仍有概率漂移；API层面的约束更可靠，但与特定平台绑定。两种方式结合使用——提示词定义语义，API保证格式——是当前生产环境的最佳实践。

一段“反幻觉”代码块

如果整篇文章只能带走一样东西，作者建议带走这段。把它粘贴在任何“答错会让你损失金钱”的提示词末尾：

If the answer is not supported by the CONTEXT above, respond exactly:
{"error":"insufficient_context","missing":[<what you need>]}
Never fill gaps with plausible-sounding facts.

就这四行。作者说，这段代码消除了他自己智能体技术栈中单个最昂贵的失败模式。它的逻辑很朴素：给模型一个“承认不知道”的合法出口，比指望它凭空变准确要可靠得多。

这套方法为什么值得记录下来

作者最终不仅重写了27条提示词，还新增了19条真正会反复使用的——代码审查、重构规划、冷启动邮件、销售线索评分、事故复盘、市场规模估算。他把四段式模板固定在文件开头，原因很实在：他总是忘记。

对于国内正在搭建AI工作流的开发者和产品团队，这篇文章的借鉴意义在于：提示词工程的重点正在从“写得漂亮”转向“写得确定”。当提示词进入生产环境、要被下游程序消费时，确定性（determinism）比创造性重要得多。四段式契约、显式输出结构、反幻觉兜底——这些都是把LLM从“聊天玩具”变成“可靠组件”的工程手段。

作者本人也坦言，这套框架才是全部重点，而且是免费的。他的建议很具体：现在就挑一条你最讨厌的提示词，用这个框架重写一遍，第一次运行你就能感受到区别。

背景补充

这里所说的"契约"思维，与软件工程中的**契约式设计（Design by Contract）**一脉相承。该理念由Bertrand Meyer在1980年代提出，核心是：调用方与被调用方之间应通过前置条件、后置条件和不变量来明确界定各自的责任边界。把这个框架映射到提示词工程上，角色和上下文对应"前置条件"（告诉模型进入任务前必须知道什么），约束对应"不变量"（无论如何都不能违反的规则），输出结构则对应"后置条件"（任务完成时结果必须满足的形状）。传统的自然语言提示词之所以脆弱，正是因为它把这三层边界全部隐式化了——人类读者可以凭借常识推断，但模型在推断过程中会悄悄引入自己的假设。显式契约的价值不仅在于减少歧义，更在于让"提示词是否正确"变成一个可以独立验证的问题，而不再依赖于运行结果的主观判断。

这段代码所针对的问题，在AI安全领域被称为幻觉（Hallucination），更精确的学术表述是"忠实性失败（faithfulness failure）"——模型生成的内容在事实上无法被给定上下文所支撑，但语言上流畅可信。幻觉的成因目前有多种理论解释，主流观点认为，语言模型的训练目标是最大化下一个token的预测概率，而非最大化事实准确性；当上下文信息不足以约束输出时，模型会从预训练阶段学到的统计关联中"补全"答案，产生听起来合理但并不真实的内容。文中给出的反幻觉代码块，本质上是一种**拒绝选项（refusal option）**的显式建模：它给模型提供了一条有明确回报的"认错"路径，使"承认不知道"在模型的生成策略中成为一个合法且低成本的选择，从而抑制它去"猜测补全"的动机。这与RLHF（人类反馈强化学习）中鼓励模型表达不确定性的训练信号异曲同工，只是在推理时通过提示词层面实现。