提示工程是 LLM 应用里最廉价也最高杠杆的优化手段。改 prompt 不花一分钱算力，改完立刻能验证，效果不好改回去就行。但同样的模型，有人写的 prompt 效果一般，有人写的能让模型表现质变，差距全在结构和方法上。
很多人对 prompt 的理解停在「写一句话描述要什么」。简单场景这够了，但复杂任务里，一句松散的描述会让模型表现很不稳定。这篇讲怎么从「写一句话」走向「结构化提示框架」，把 prompt 工程从碰运气变成有方法论的事。
简单 prompt 为什么不够用
先理解简单 prompt 的局限。
一句话的 prompt，比如「帮我总结这篇文章」，模型会给你一个总结，但每次的格式、长度、详略都不一样，你没法稳定地拿到想要的结果。因为模型不知道你要多长的总结、什么格式、什么角度、给谁看，它只能猜，猜得好不好看运气。
模糊的 prompt 还会让模型「自由发挥」，在你不希望的地方发挥。你要一个简洁的事实陈述，它给你加了一段抒情。你要客观分析，它给你下了主观判断。不是模型不听话，是你的指令没把边界画清楚。
复杂任务更严重。多步骤的任务，一句 prompt 没法把每一步的要求都讲清楚，模型会漏步骤或者顺序错乱。涉及约束的任务（必须用什么格式、不能包含什么），模糊的约束模型经常违反。
这些问题的根因都是同一个，prompt 没有给模型足够清晰、结构化的指导。模型很聪明，但你不告诉它要什么，它就只能猜。
结构化 prompt 的几个组成部分
图：结构化 Prompt 的五个组成部分——角色、任务、约束、上下文、输出格式，分层组织。
一个结构化的 prompt，通常包含这几个部分，按层次组织。
角色定义。告诉模型它在扮演谁。「你是一个资深的数据库工程师」「你是一个严谨的技术文档写作者」。角色定义不只是装饰，它影响模型的回答风格、专业度和视角。一个「资深 DBA」和一个「入门教程作者」回答同一个数据库问题，深度和角度完全不同。
任务描述。明确要做什么。不是「帮我写」，而是「写一篇关于 X 的技术文章，面向有经验的工程师，重点讲设计权衡」。任务越具体，输出越聚焦。
约束条件。画清楚边界。长度限制（不超过 500 字）、格式要求（用 markdown 表格）、内容约束（只基于提供的资料，不加臆测）、风格要求（客观、不带感情色彩）。约束是把模型「框」在你想要的范围里，不让它乱跑。
上下文。提供模型需要的信息。背景资料、参考示例、输入数据。模型不知道的东西，你要给它，不能指望它自己脑补。
输出格式。明确要什么形式的输出。「输出一个 JSON，包含 title 和 content 两个字段」「先给结论，再给三个支撑论点」。格式明确，输出才好用、好解析。
Few-shot，用示例代替描述
这是 prompt 工程里最有效的技巧之一。
与其用一大段文字描述「我要什么样的输出」，不如直接给几个示例。模型从示例里学习模式，比从描述里理解规则更准。
比如你要模型做情感分类。用描述的话，你要解释「什么是正面、什么是负面、什么是中性」，模型理解可能有偏差。用 few-shot 的话，你直接给几个例子，「这个评论 → 正面」「那个评论 → 负面」，模型立刻抓住了分类标准。
few-shot 的几个要点。示例要典型，覆盖你期望的主要情况。示例要和真实输入分布一致，别给的都是简单 case，真实场景却很复杂。示例数量不用多，三五个通常够，多了浪费 token 而且可能让模型过拟合到示例的模式。
few-shot 还能用来「校准」风格。你想让模型用特定的语气和结构回答，给几个符合那种风格的示例，比用文字描述「要这种风格」有效得多。模型模仿示例的能力，比理解抽象描述的能力强。
Chain of Thought，让模型展示推理
对于需要推理的任务，让模型「一步步想」比让它直接给答案效果好得多。
原理是，LLM 的推理能力和它的生成长度相关。直接要答案，模型可能跳过推理给出错误的结论。要求它先写出推理过程再给结论，它「想」得更充分，准确率提升。
实现很简单，在 prompt 里加一句「请一步步思考，先给出推理过程，再给出最终答案」，或者在 few-shot 示例里展示推理过程。模型会模仿这个「先推理后结论」的模式。
这个技巧在数学计算、逻辑推理、多步决策这类任务上效果尤其明显。但也要注意，不是所有任务都需要 CoT。简单的事实回忆或者文本生成，加 CoT 反而啰嗦，没有收益。
图：Few-shot（绿色，用示例教模式与校准风格）与 Chain of Thought（紫色，先推理后结论，适合推理类任务）的对照。
Prompt 的迭代和优化
Prompt 工程不是一次写完就结束的，是个持续迭代的过程。
找到失败 case。在测试集或者线上反馈里，找出模型表现不好的 case。这些 case 是优化的靶子。
分析失败原因。是 prompt 哪部分没说清楚，还是缺了某个约束，还是示例不够典型。针对性地修改。
验证修改效果。改完 prompt，重新跑一遍测试集，看整体效果是变好了还是变差了。有时候修好了一个 case 却弄坏了其他 case，要权衡。
Prompt 的迭代要记录版本。每次改的 prompt 存下来，标注改了什么、为什么改、效果变化。这样能回溯，也能避免「改来改去发现还是老版本好」却找不回来的尴尬。
图：Prompt 迭代优化循环——找失败 case → 分析原因 → 针对修改 → 验证效果，直到整体收敛，全程记录版本。
[important] Prompt 工程是 LLM 优化的第一选择 遇到模型表现不好，第一反应永远是改 prompt，不是换模型、不是微调、不是加复杂架构。prompt 是成本最低、迭代最快的优化手段，先把它的潜力榨干。一个精心设计的 prompt，效果提升可能超过换一个更贵的模型。只有在 prompt 怎么调都不行的时候，才考虑更重的手段。这是性价比最高的优化顺序。
Prompt 工程的局限
最后说说 prompt 工程做不到什么，免得对它期望过高。
它不能弥补模型能力的不足。模型本身做不到的事（比如准确的实时计算、可靠的事实记忆），prompt 再怎么写也变不出来。这时候要靠工具调用或者 RAG，不是 prompt 能解决的。
它不能完全消除不确定性。好的 prompt 能降低输出的方差，但不能让它变成完全确定。LLM 天然有随机性，prompt 是降低不是消除。
它有上限。每个模型对 prompt 的响应有个天花板，到了那个天花板，prompt 怎么优化都提升有限了。这时候要么接受现状，要么换更强的模型。
理解了这些局限，对 prompt 工程的期望就合理了。它是 LLM 优化的第一手段，投入产出比最高，但不是万能的。把它用到位，然后在它到达上限时，再考虑 RAG、工具调用、微调这些更重的手段。这才是合理的优化路径。
