提示词工程

提示词是与大模型交互的唯一界面，其质量直接决定了输出的质量。好的提示词能让模型理解意图、遵循约束、生成符合预期的内容；差的提示词则会导致模型产生幻觉、偏离主题、输出格式混乱。提示词工程不是玄学，而是一套可学习、可复用的设计原则和技巧。在深入设计技巧之前，需要先理解提示词生效的底层约束——Token 机制、采样参数和上下文窗口。

底层约束

LLM 不直接处理文本，而是将文本切分为 Token 序列。Token 是子词级别的单元，一个英文单词通常对应 1-2 个 Token，一个中文字通常对应 1-2 个 Token。1k Tokens 约等于 750 个英文单词或 500 个中文字。模型按输入和输出的 Token 数量计费，输出 Token 的单价通常高于输入。Token 机制意味着提示词不是"越详细越好"——每多一个 Token 都增加成本和延迟，需要在信息量和经济性之间找到平衡。

Temperature 和 Top-p 控制模型输出的随机性，直接影响提示词的稳定性和创造性。Temperature 调整概率分布的"尖锐度"：0 时模型始终选择概率最高的 Token（确定性输出，适合代码生成、数据提取），1 时保持原始分布（最随机，适合创意写作），0.7 是通用场景的常用值。Top-p（Nucleus Sampling）从累积概率达到 p 的最小 Token 集合中采样，典型值 0.9，过滤掉低概率的极端输出但不完全消除多样性。Temperature 和 Top-p 通常配合使用，Temperature 控制整体随机程度，Top-p 控制候选范围。高 Temperature 下如果提示词约束不够强，模型更容易偏离预期方向。

上下文窗口（Context Window）是模型一次能处理的最大 Token 数，包括输入和输出。GPT-4o 是 128K，Claude 3.5 是 200K，开源模型如 Qwen2.5-72B 是 128K。窗口大小决定了提示词能包含多少信息——历史对话、检索文档、系统指令都占用窗口空间。但窗口大不等于"有效利用"长：模型对中间位置内容的关注度最低（Lost in the Middle 现象），关键信息放在提示词的开头或结尾更容易被模型利用。窗口快满时，需要在历史对话压缩、检索结果裁剪和输出长度预留之间做权衡。

设计原则

清晰性是提示词的首要原则。模型需要明确知道任务是什么、输入是什么、输出应该是什么形式。"写一篇文章"太模糊，"写一篇关于人工智能发展历史的文章，1000 字左右，包含三个章节"则更具体。避免歧义表达，"翻译这段文字"应该指定目标语言，"总结以下内容"应该明确总结的粒度和角度。

结构化的提示词更容易被模型理解。常见模板是"角色设定 + 任务描述 + 输入数据 + 输出格式 + 约束条件 + 示例"。角色设定让模型知道以什么身份响应，"你是一位资深软件工程师，负责代码审查"会触发模型的专业知识库。任务描述用祈使句开头，"分析以下代码的性能问题并给出优化建议"。输出格式明确期望的结构，"以 JSON 格式返回，包含 problem 和 solution 两个字段"。约束条件限制模型的回答范围，"只使用提供的文档，不要添加外部知识"。

示例是最有效的引导方式。Few-shot Learning 通过提供几个输入-输出示例，让模型理解任务模式。示例质量比数量更重要，一两个精心设计的示例比十个噪声示例更有效。示例应该覆盖边界情况，比如分类任务应该包含容易混淆的样本。代码生成任务中，示例展示了函数签名、注释风格、错误处理模式，模型会模仿这些模式。

常用技巧

思维链 (Chain-of-Thought, CoT) 是复杂推理任务的利器。直接问"小明有 5 个苹果，吃了 2 个，又买了 3 个，现在有几个"，模型可能直接输出 6（错误）。如果在提示词中加入"让我们一步步思考"，模型会生成推理过程："小明开始有 5 个，吃了 2 个后剩 3 个，又买了 3 个，现在有 6 个"，虽然过程有误，但展现了推理链条。CoT 的本质是让模型显式展示思考步骤，降低了推理的复杂度，适合数学问题、逻辑推理、多步骤任务。

自洽性 (Self-Consistency) 通过多次采样提升准确率。对于确定答案的问题（如数学题），可以让模型生成多个推理路径，选择出现最多的答案。"请思考这个问题并给出答案，重复 5 次这个过程，然后投票选出最可靠的答案"。这种方法基于一个假设：正确的推理路径会收敛到相似答案，错误的路径则分散。

思维树 (Tree-of-Thoughts) 将推理过程扩展为树状结构。当问题有多种可能的解决路径时（如规划、决策），让模型探索不同的分支，评估每个分支的可行性，再选择最优路径。这类似于人类的战略思维，先列出方案，比较优劣，再决策。实现时可以分两步：第一步让模型生成多个可能的行动方案，第二步让模型评估每个方案的预期结果。

Generated Knowledge 是处理知识密集型任务的方法。先让模型生成与问题相关的背景知识，再基于这些知识回答问题。"在回答以下问题之前，先列出你可能需要的背景知识"。这种方法激活模型的内部知识库，减少了检索不准确的影响。比如问"量子计算机如何破解 RSA"，模型会先解释量子计算原理、Shor 算法、RSA 的数学基础，然后再回答破解过程，答案的准确性和完整性都会提升。

结构模式

角色扮演是常见的提示词模式，让模型以特定身份、语气、专业水平响应。"你是一位有 20 年经验的内科医生，正在向患者解释检查结果，使用通俗易懂的语言，避免专业术语"。角色设定不仅影响内容的准确性，还影响表达方式。技术文档、学术论文、科普文章需要不同的风格，角色扮演让模型自动调整语气和深度。

格式约束确保输出符合程序处理要求。"以 JSON 格式返回，不要包含任何其他文字"、"使用 Markdown 表格展示对比结果"、"每个要点不超过 20 字"。约束条件应该在提示词的末尾强调，因为模型对位置靠后的指令更敏感。如果格式约束被忽略，可以尝试"必须严格遵守以下格式"、"任何不符合格式的输出都是错误的"等强化表达。

分步执行将复杂任务拆解为子任务。"第一步，提取文章中的关键实体；第二步，分析实体之间的关系；第三步，绘制关系图谱"。明确步骤后，模型会按顺序执行，减少遗漏。对于超长任务，可以采用迭代方式，每轮完成一个步骤，下一轮基于上一轮的输出继续。

对比和评估是分析类任务的有效模式。"对比以下两种方案的优缺点，从成本、性能、可维护性三个维度分析"。模型会组织结构化的对比，而不是混杂的描述。评估类提示词应该明确评估标准，"给这篇论文打分（1-10），并解释理由，关注创新性、实验设计、写作质量"。

常见陷阱

提示词过长会导致注意力分散。模型对开头和结尾的内容更关注（U-shaped attention），中间的指令容易被忽略。如果提示词超过 2000 字，考虑拆分成多个步骤，或者将重要约束放在开头和结尾重复强调。

指令冲突会让模型无所适从。"简要回答，但详细解释每个要点"就是矛盾的指令，模型要么忽略"简要"，要么忽略"详细"。设计提示词时应该检查一致性，确保所有约束是兼容的。

过度限制会抑制模型的创造力。"在 100 字以内回答这个问题，使用 3 个要点，每个要点不超过 20 字，使用专业术语，但又要通俗易懂"，这些约束几乎不可能同时满足。合理的方法是确定优先级，核心约束优先，次要约束可以适当放松。

忽略负面约束是模型的常见问题。"不要使用 markdown 格式"、"不要输出解释性文字"，这些否定指令经常被违背。更好的方式是正面引导，"以纯文本格式输出"、"只返回 JSON 数据"。如果必须使用否定，可以在结尾再次强调，或者通过示例展示什么是错误的输出。

提示词优化

迭代优化是改进提示词的标准方法。先写出初始版本，用几个测试用例验证，分析失败原因，针对性调整。常见失败模式包括：格式不符（需要加强格式约束）、内容偏离（需要更明确的任务描述）、遗漏要求（需要分点列出约束）。每次迭代只修改一处，这样才能定位问题根源。

A/B 测试可以客观评估提示词效果。准备一组标准问题，用不同版本的提示词生成答案，用另一个 LLM 或人工评分，选择得分更高的版本。评分标准应该具体化，准确率、完整性、格式符合度、可读性都是可以量化的维度。

提示词库是积累经验的宝贵资产。将验证有效的提示词分类保存，注明适用场景、注意事项、示例。团队成员可以复用和改进，避免重复造轮子。LangChain 的 PromptTemplate、Haystack 的 PromptBuilder 都是管理提示词的工具。