1. 从“咒语”到“工程”为什么提示词是LangChain的灵魂如果你刚开始接触LangChain可能会觉得它像一个功能强大的工具箱里面装满了各种连接大模型、处理数据、构建流程的“扳手”和“螺丝刀”。但用了一段时间后你可能会发现无论你的工具链设计得多么精巧最终决定应用效果上限的往往不是链条本身而是你递给大模型的那句话——也就是提示词Prompt。这就像你拥有全世界最顶级的厨房设备和食材但如果你不知道如何清晰地告诉厨师“我想要一份七分熟、黑胡椒汁的牛排”最终端上来的可能是一盘炒饭。在LangChain 1.2.0的语境下提示词早已超越了早期AI绘画中那种“魔法咒语”的玄学阶段它是一门严谨的“工程”。它不仅仅是向模型提问更是构建一个清晰、结构化、富含上下文信息的指令环境让模型能够稳定、可靠地执行复杂任务。无论是构建一个能回答专业问题的RAG系统还是设计一个能自主调用工具的智能体Agent其核心驱动力都来自于精心设计的提示词模板。可以说不理解提示词就无法真正驾驭LangChain。2. LangChain提示词模板告别字符串拼接的原始时代在早期或最简单的场景中开发者可能会用Python的f-string来拼凑提示词比如f请总结以下文本{text}。这种方式在快速原型验证时没问题但一旦进入生产环境或复杂流程就会立刻暴露出维护难、易出错、无法复用的问题。LangChain的提示词模板PromptTemplate就是为了解决这些问题而生的。2.1 基础模板变量替换与标准化PromptTemplate最基本的功能是定义一个带有占位符的字符串模板并在运行时将变量填充进去。这听起来简单但其价值在于“标准化”和“中心化管理”。from langchain.prompts import PromptTemplate # 定义一个总结文本的模板 summary_template PromptTemplate.from_template( “”” 请基于以下内容生成一段简洁的摘要。 要求 1. 摘要长度控制在100字以内。 2. 突出核心观点和结论。 3. 使用中文输出。 内容 {input_text} “”” ) # 准备输入变量 input_variables {“input_text”: “这里是一段非常长的需要被总结的文档内容...”} # 生成最终的提示词 final_prompt summary_template.format(**input_variables) print(final_prompt)为什么这样做更好首先它将提示词的“结构”和“内容”分离了。你可以在一个地方比如配置文件或专门的模块管理所有模板而不是把提示词逻辑散落在代码各处。其次它强制进行了输入验证。PromptTemplate会检查你提供的变量字典是否包含了模板中定义的所有变量避免了运行时因缺少变量而导致的格式化错误。最后它为更高级的功能如少量示例学习、聊天对话格式奠定了基础。2.2 聊天提示模板适配对话式模型当今主流的大模型如GPT、Claude、DeepSeek大多是基于聊天格式训练的。这意味着它们期望的输入不是单一字符串而是一个消息列表其中每条消息都有“角色”role如system,user,assistant。ChatPromptTemplate就是用来构建这种结构化对话的。from langchain.prompts import ChatPromptTemplate, SystemMessagePromptTemplate, HumanMessagePromptTemplate # 定义不同角色的模板 system_template SystemMessagePromptTemplate.from_template( “你是一位资深技术文档工程师擅长将复杂的编程概念用通俗易懂的语言解释清楚。” ) human_template HumanMessagePromptTemplate.from_template( “请向我解释什么是{concept}并给出一个简单的代码示例。” ) # 组合成聊天提示模板 chat_prompt ChatPromptTemplate.from_messages([system_template, human_template]) # 格式化 messages chat_prompt.format_messages(concept“Python中的装饰器”) # messages 现在是一个列表包含两条消息 # [SystemMessage(content‘...’), HumanMessage(content‘请向我解释什么是Python中的装饰器...’)]关键点在于角色分配system消息用于设定模型的“人设”和全局行为准则它对整个对话的影响是持久且底层的。user消息是用户的当前指令。在复杂任务中你还可以插入assistant的先前回复作为上下文或者使用function/tool角色来封装工具调用结果。这种结构化的对话管理是构建稳定、可控的AI应用的关键。注意不同模型对system消息的支持程度不同。有些模型可能没有明确的system角色概念或者将其与user消息同等处理。在实际使用中需要查阅对应模型的文档。3. 提示词工程的实战核心超越基础模板的设计思维掌握了模板语法只是第一步就像学会了写字但离写出好文章还差得远。真正的提示词工程体现在模板内容的设计上。结合网络上的高频讨论点如“提示词工程”、“RAG”、“Agent”我们可以提炼出几个核心设计模式。3.1 上下文工程为模型装备“短期记忆”这是RAG检索增强生成场景下的核心。模型本身并不知道你的私有知识你需要通过提示词把相关的背景信息“注入”给它。一个典型的RAG提示词模板可能长这样你是一个专业的客服助手根据提供的公司知识库内容来回答问题。 如果知识库内容不足以回答问题请如实告知“根据现有资料我无法回答该问题”不要编造信息。 相关参考信息 {context} 问题 {question} 请根据以上参考信息回答问题这里的{context}就是通过向量检索等技术从知识库中找出的相关文档片段。设计要点在于明确指令告诉模型必须且仅能依据提供的上下文回答。设定边界明确告知模型在上下文不足时该如何处理“拒绝回答”比“胡编乱造”好得多。结构化分隔用清晰的标记如“相关参考信息”、“问题”将指令、上下文、问题分开帮助模型理解不同部分的意图。我踩过的坑早期我曾简单地将上下文和问题拼接在一起如“{context}\n\n问题{question}”。结果发现模型有时会混淆把上下文的一部分也当作是问题来回答或者无法严格遵循上下文。后来强制加入了“根据以上参考信息回答问题”这样的明确指令句生成结果的准确性和依从性大幅提升。3.2 思维链与步骤分解引导模型“慢慢想”对于逻辑推理、数学计算或复杂规划任务直接问结果往往效果不佳。这时需要在提示词中引导模型进行逐步推理即“Chain-of-Thought”CoT。基础CoT提示问题一个篮子里有5个苹果小明拿走了2个又放进去3个梨请问篮子里现在有多少个水果 请一步步思考更工程化的做法是使用“Few-Shot”示例在模板中直接给出几个“问题-推理步骤-答案”的例子让模型学会模仿这种推理模式。cot_template PromptTemplate.from_template( “”” 请参考以下示例的格式进行推理并回答问题。 示例1 问题商店有20支笔卖出8支又进货15支现在有多少支 思考首先卖出后剩余 20 - 8 12支。然后进货后总数为 12 15 27支。 答案27支。 示例2 问题{example_question} 思考{example_thought} 答案{example_answer} 现在请回答我的问题 问题{user_question} 请一步步思考 “”” )在LangChain中你可以用FewShotPromptTemplate来更方便地管理这些示例。对于智能体Agent这个原理同样适用。智能体的提示词通常包含对智能体角色的定义。可用工具的描述及其使用方式。一个强制性的输出格式要求例如必须输出Action:和Action Input:来调用工具。可能包含一两个示例展示如何分析问题、选择工具、处理结果。这种设计本质上是在为模型规划一个“思考-行动-观察”的循环框架。3.3 输出格式化让模型“听话”地返回结构化数据我们经常需要模型输出JSON、XML或特定格式的文本以便后续程序处理。LangChain提供了StructuredOutputParser等组件但其背后离不开提示词的配合。核心是在提示词中明确、详细地描述格式要求请根据用户查询提取其中的关键实体信息并以JSON格式返回。 JSON必须包含以下字段 - “person_names”: 一个数组列出所有出现的人名。 - “locations”: 一个数组列出所有出现的地点。 - “action”: 字符串描述核心事件。 请确保输出**仅**为JSON对象不要有任何额外的解释或标记。 查询{query}更可靠的做法是结合Pydantic模型和LangChain的解析器实现从自然语言到结构化对象的自动转换。提示词模板会动态地将Pydantic模型的字段描述和格式要求插入到指令中确保模型输出与预定模式匹配。这比单纯在提示词里写“输出JSON”要稳健得多。4. 高级模式与组件组装你的提示词流水线LangChain 1.2.0 的提示词模块不是一个孤立的PromptTemplate而是一个可以组装、串联的生态系统。4.1 提示词序列化与持久化当你拥有几十上百个精心调优的提示词模板时把它们硬编码在Python文件里是灾难。LangChain支持将提示词模板保存为JSON或YAML文件。# 保存模板 summary_template.save(“prompts/summary_template.json”) # 从文件加载 from langchain.prompts import load_prompt loaded_template load_prompt(“prompts/summary_template.json”)这极大地方便了提示词的版本管理、团队协作和A/B测试。你可以将提示词文件纳入Git仓库跟踪其迭代历史。4.2 提示词选择器根据输入动态选择最佳模板在复杂应用中你可能需要根据用户输入的内容或意图动态选择不同的提示词。BasePromptSelector及其实现如ConditionalPromptSelector就是干这个的。from langchain.prompts import ConditionalPromptSelector, PromptTemplate # 定义两个不同场景的模板 simple_qa_template PromptTemplate(...) # 简单QA模板 complex_analysis_template PromptTemplate(...) # 复杂分析模板 def length_selector(input_text: str) - bool: “”“根据输入文本长度选择模板。”“” return len(input_text) 500 # 超过500字用复杂模板 selector ConditionalPromptSelector( default_promptsimple_qa_template, condition_prompts[(length_selector, complex_analysis_template)] ) # 根据输入自动选择 chosen_template selector.get_prompt(input_text“一段很长的文本...”)这为实现更智能、自适应的对话流提供了基础。4.3 与链Chain的集成提示词是链的“发动机”在LangChain中链Chain是组合各种调用的核心抽象。而几乎所有的链都离不开提示词。LLMChain最基础的链就是“提示词模板 LLM调用 输出解析器”。它清晰地展示了提示词在流程中的核心位置。SequentialChain顺序执行多个子链前一个链的输出可以作为后一个链的提示词输入变量。这要求你精心设计每个环节的提示词确保信息能准确传递。TransformChain可以在调用LLM前对输入进行转换比如你可以用一个链先根据原始问题生成一个更优的搜索查询词这本身就需要一个提示词再用另一个链执行检索和回答。我的经验是在设计和调试一个复杂链时最有效的方法不是一次性运行整个链而是先单独测试每一个环节的提示词输入和输出。确保每个提示词在独立测试时都能产生符合预期的结果然后再将它们串联起来。LangChain的verboseTrue调试模式非常有用它能打印出每一步传递给模型的真实提示词是排查问题的利器。5. 避坑指南来自实战的提示词设计经验看了这么多理论和组件最后分享一些在LangChain项目中实际编写提示词时容易踩坑的地方和应对技巧。5.1 指令冲突与模糊性这是最常见的问题。提示词中包含了相互矛盾或模棱两可的指令。反面例子“用简短的一句话回答并详细列出三个理由。” 这句话本身就在长度和细节上存在冲突。正面做法指令清晰、分层。例如“首先用一句话给出核心答案。然后分点列出三个主要原因1. ... 2. ... 3. ...”5.2 忽略模型的“视角”与训练数据模型是通过海量文本训练的它有自己理解世界的方式。如果你要求一个通用模型“像一位拥有20年经验的Linux内核开发者一样回答问题”它可能只能模仿那种口吻但无法给出真正的专家级答案。对于高度专业化的问题更好的方式是通过RAG提供专家文档作为上下文而不是仅仅在系统提示词里设定一个角色。5.3 变量注入导致提示词结构破坏当{input}变量中的内容包含一些特殊标记或结构时可能会破坏你精心设计的提示词。例如如果你的提示词是“总结{text}”而text变量本身恰好以“总结”开头就会造成混乱。解决方案在模板中使用更独特、更不可能出现在输入内容中的分隔符或者对输入变量进行简单的清洗和转义。例如用“SUMMARY_TEXT”这样的标记来包裹变量内容。5.4 过度依赖单一提示词缺乏评估与迭代很多人写出一个提示词跑通一次demo就以为万事大吉。实际上提示词需要像代码一样进行测试和迭代。建立测试集准备一批具有代表性的输入用例和期望的输出。量化评估对于分类、提取任务可以使用准确率、召回率。对于生成任务可以人工评估或使用模型本身进行相关性评分。A/B测试对于关键应用可以并行运行不同版本的提示词在线上对比其效果。在LangChain生态中你可以利用langsmith等平台来跟踪和评估不同提示词版本的表现实现数据驱动的提示词优化。5.5 对“系统提示词”的威力认识不足系统提示词System Message是设定模型行为基调的最强大工具。一个常见的误区是把它写得太短、太笼统。比如“你是一个有帮助的助手”。 一个强大的系统提示词应该尽可能具体地定义角色和背景你是什么领域的专家你的知识边界在哪里沟通风格回答应该正式还是随意详细还是简洁安全与边界什么话题不能讨论如何应对模糊或越界的请求输出格式是否倾向于使用列表、表格是否应该主动询问澄清性问题花时间打磨系统提示词往往比在用户消息上绞尽脑汁更能获得整体行为稳定的模型输出。编写提示词不是一个一蹴而就的“魔术”而是一个需要理解模型原理、结合具体场景、不断实验和调整的“工程”过程。在LangChain的框架下通过模块化的模板、可组合的链以及丰富的周边工具我们可以将这门工程实践变得更具可管理性和可扩展性。记住最好的提示词往往是那个最清晰、最无歧义地传达了人类意图的指令。 LangChain提示词工程：从基础模板到RAG与Agent实战
1. 从“咒语”到“工程”为什么提示词是LangChain的灵魂如果你刚开始接触LangChain可能会觉得它像一个功能强大的工具箱里面装满了各种连接大模型、处理数据、构建流程的“扳手”和“螺丝刀”。但用了一段时间后你可能会发现无论你的工具链设计得多么精巧最终决定应用效果上限的往往不是链条本身而是你递给大模型的那句话——也就是提示词Prompt。这就像你拥有全世界最顶级的厨房设备和食材但如果你不知道如何清晰地告诉厨师“我想要一份七分熟、黑胡椒汁的牛排”最终端上来的可能是一盘炒饭。在LangChain 1.2.0的语境下提示词早已超越了早期AI绘画中那种“魔法咒语”的玄学阶段它是一门严谨的“工程”。它不仅仅是向模型提问更是构建一个清晰、结构化、富含上下文信息的指令环境让模型能够稳定、可靠地执行复杂任务。无论是构建一个能回答专业问题的RAG系统还是设计一个能自主调用工具的智能体Agent其核心驱动力都来自于精心设计的提示词模板。可以说不理解提示词就无法真正驾驭LangChain。2. LangChain提示词模板告别字符串拼接的原始时代在早期或最简单的场景中开发者可能会用Python的f-string来拼凑提示词比如f请总结以下文本{text}。这种方式在快速原型验证时没问题但一旦进入生产环境或复杂流程就会立刻暴露出维护难、易出错、无法复用的问题。LangChain的提示词模板PromptTemplate就是为了解决这些问题而生的。2.1 基础模板变量替换与标准化PromptTemplate最基本的功能是定义一个带有占位符的字符串模板并在运行时将变量填充进去。这听起来简单但其价值在于“标准化”和“中心化管理”。from langchain.prompts import PromptTemplate # 定义一个总结文本的模板 summary_template PromptTemplate.from_template( “”” 请基于以下内容生成一段简洁的摘要。 要求 1. 摘要长度控制在100字以内。 2. 突出核心观点和结论。 3. 使用中文输出。 内容 {input_text} “”” ) # 准备输入变量 input_variables {“input_text”: “这里是一段非常长的需要被总结的文档内容...”} # 生成最终的提示词 final_prompt summary_template.format(**input_variables) print(final_prompt)为什么这样做更好首先它将提示词的“结构”和“内容”分离了。你可以在一个地方比如配置文件或专门的模块管理所有模板而不是把提示词逻辑散落在代码各处。其次它强制进行了输入验证。PromptTemplate会检查你提供的变量字典是否包含了模板中定义的所有变量避免了运行时因缺少变量而导致的格式化错误。最后它为更高级的功能如少量示例学习、聊天对话格式奠定了基础。2.2 聊天提示模板适配对话式模型当今主流的大模型如GPT、Claude、DeepSeek大多是基于聊天格式训练的。这意味着它们期望的输入不是单一字符串而是一个消息列表其中每条消息都有“角色”role如system,user,assistant。ChatPromptTemplate就是用来构建这种结构化对话的。from langchain.prompts import ChatPromptTemplate, SystemMessagePromptTemplate, HumanMessagePromptTemplate # 定义不同角色的模板 system_template SystemMessagePromptTemplate.from_template( “你是一位资深技术文档工程师擅长将复杂的编程概念用通俗易懂的语言解释清楚。” ) human_template HumanMessagePromptTemplate.from_template( “请向我解释什么是{concept}并给出一个简单的代码示例。” ) # 组合成聊天提示模板 chat_prompt ChatPromptTemplate.from_messages([system_template, human_template]) # 格式化 messages chat_prompt.format_messages(concept“Python中的装饰器”) # messages 现在是一个列表包含两条消息 # [SystemMessage(content‘...’), HumanMessage(content‘请向我解释什么是Python中的装饰器...’)]关键点在于角色分配system消息用于设定模型的“人设”和全局行为准则它对整个对话的影响是持久且底层的。user消息是用户的当前指令。在复杂任务中你还可以插入assistant的先前回复作为上下文或者使用function/tool角色来封装工具调用结果。这种结构化的对话管理是构建稳定、可控的AI应用的关键。注意不同模型对system消息的支持程度不同。有些模型可能没有明确的system角色概念或者将其与user消息同等处理。在实际使用中需要查阅对应模型的文档。3. 提示词工程的实战核心超越基础模板的设计思维掌握了模板语法只是第一步就像学会了写字但离写出好文章还差得远。真正的提示词工程体现在模板内容的设计上。结合网络上的高频讨论点如“提示词工程”、“RAG”、“Agent”我们可以提炼出几个核心设计模式。3.1 上下文工程为模型装备“短期记忆”这是RAG检索增强生成场景下的核心。模型本身并不知道你的私有知识你需要通过提示词把相关的背景信息“注入”给它。一个典型的RAG提示词模板可能长这样你是一个专业的客服助手根据提供的公司知识库内容来回答问题。 如果知识库内容不足以回答问题请如实告知“根据现有资料我无法回答该问题”不要编造信息。 相关参考信息 {context} 问题 {question} 请根据以上参考信息回答问题这里的{context}就是通过向量检索等技术从知识库中找出的相关文档片段。设计要点在于明确指令告诉模型必须且仅能依据提供的上下文回答。设定边界明确告知模型在上下文不足时该如何处理“拒绝回答”比“胡编乱造”好得多。结构化分隔用清晰的标记如“相关参考信息”、“问题”将指令、上下文、问题分开帮助模型理解不同部分的意图。我踩过的坑早期我曾简单地将上下文和问题拼接在一起如“{context}\n\n问题{question}”。结果发现模型有时会混淆把上下文的一部分也当作是问题来回答或者无法严格遵循上下文。后来强制加入了“根据以上参考信息回答问题”这样的明确指令句生成结果的准确性和依从性大幅提升。3.2 思维链与步骤分解引导模型“慢慢想”对于逻辑推理、数学计算或复杂规划任务直接问结果往往效果不佳。这时需要在提示词中引导模型进行逐步推理即“Chain-of-Thought”CoT。基础CoT提示问题一个篮子里有5个苹果小明拿走了2个又放进去3个梨请问篮子里现在有多少个水果 请一步步思考更工程化的做法是使用“Few-Shot”示例在模板中直接给出几个“问题-推理步骤-答案”的例子让模型学会模仿这种推理模式。cot_template PromptTemplate.from_template( “”” 请参考以下示例的格式进行推理并回答问题。 示例1 问题商店有20支笔卖出8支又进货15支现在有多少支 思考首先卖出后剩余 20 - 8 12支。然后进货后总数为 12 15 27支。 答案27支。 示例2 问题{example_question} 思考{example_thought} 答案{example_answer} 现在请回答我的问题 问题{user_question} 请一步步思考 “”” )在LangChain中你可以用FewShotPromptTemplate来更方便地管理这些示例。对于智能体Agent这个原理同样适用。智能体的提示词通常包含对智能体角色的定义。可用工具的描述及其使用方式。一个强制性的输出格式要求例如必须输出Action:和Action Input:来调用工具。可能包含一两个示例展示如何分析问题、选择工具、处理结果。这种设计本质上是在为模型规划一个“思考-行动-观察”的循环框架。3.3 输出格式化让模型“听话”地返回结构化数据我们经常需要模型输出JSON、XML或特定格式的文本以便后续程序处理。LangChain提供了StructuredOutputParser等组件但其背后离不开提示词的配合。核心是在提示词中明确、详细地描述格式要求请根据用户查询提取其中的关键实体信息并以JSON格式返回。 JSON必须包含以下字段 - “person_names”: 一个数组列出所有出现的人名。 - “locations”: 一个数组列出所有出现的地点。 - “action”: 字符串描述核心事件。 请确保输出**仅**为JSON对象不要有任何额外的解释或标记。 查询{query}更可靠的做法是结合Pydantic模型和LangChain的解析器实现从自然语言到结构化对象的自动转换。提示词模板会动态地将Pydantic模型的字段描述和格式要求插入到指令中确保模型输出与预定模式匹配。这比单纯在提示词里写“输出JSON”要稳健得多。4. 高级模式与组件组装你的提示词流水线LangChain 1.2.0 的提示词模块不是一个孤立的PromptTemplate而是一个可以组装、串联的生态系统。4.1 提示词序列化与持久化当你拥有几十上百个精心调优的提示词模板时把它们硬编码在Python文件里是灾难。LangChain支持将提示词模板保存为JSON或YAML文件。# 保存模板 summary_template.save(“prompts/summary_template.json”) # 从文件加载 from langchain.prompts import load_prompt loaded_template load_prompt(“prompts/summary_template.json”)这极大地方便了提示词的版本管理、团队协作和A/B测试。你可以将提示词文件纳入Git仓库跟踪其迭代历史。4.2 提示词选择器根据输入动态选择最佳模板在复杂应用中你可能需要根据用户输入的内容或意图动态选择不同的提示词。BasePromptSelector及其实现如ConditionalPromptSelector就是干这个的。from langchain.prompts import ConditionalPromptSelector, PromptTemplate # 定义两个不同场景的模板 simple_qa_template PromptTemplate(...) # 简单QA模板 complex_analysis_template PromptTemplate(...) # 复杂分析模板 def length_selector(input_text: str) - bool: “”“根据输入文本长度选择模板。”“” return len(input_text) 500 # 超过500字用复杂模板 selector ConditionalPromptSelector( default_promptsimple_qa_template, condition_prompts[(length_selector, complex_analysis_template)] ) # 根据输入自动选择 chosen_template selector.get_prompt(input_text“一段很长的文本...”)这为实现更智能、自适应的对话流提供了基础。4.3 与链Chain的集成提示词是链的“发动机”在LangChain中链Chain是组合各种调用的核心抽象。而几乎所有的链都离不开提示词。LLMChain最基础的链就是“提示词模板 LLM调用 输出解析器”。它清晰地展示了提示词在流程中的核心位置。SequentialChain顺序执行多个子链前一个链的输出可以作为后一个链的提示词输入变量。这要求你精心设计每个环节的提示词确保信息能准确传递。TransformChain可以在调用LLM前对输入进行转换比如你可以用一个链先根据原始问题生成一个更优的搜索查询词这本身就需要一个提示词再用另一个链执行检索和回答。我的经验是在设计和调试一个复杂链时最有效的方法不是一次性运行整个链而是先单独测试每一个环节的提示词输入和输出。确保每个提示词在独立测试时都能产生符合预期的结果然后再将它们串联起来。LangChain的verboseTrue调试模式非常有用它能打印出每一步传递给模型的真实提示词是排查问题的利器。5. 避坑指南来自实战的提示词设计经验看了这么多理论和组件最后分享一些在LangChain项目中实际编写提示词时容易踩坑的地方和应对技巧。5.1 指令冲突与模糊性这是最常见的问题。提示词中包含了相互矛盾或模棱两可的指令。反面例子“用简短的一句话回答并详细列出三个理由。” 这句话本身就在长度和细节上存在冲突。正面做法指令清晰、分层。例如“首先用一句话给出核心答案。然后分点列出三个主要原因1. ... 2. ... 3. ...”5.2 忽略模型的“视角”与训练数据模型是通过海量文本训练的它有自己理解世界的方式。如果你要求一个通用模型“像一位拥有20年经验的Linux内核开发者一样回答问题”它可能只能模仿那种口吻但无法给出真正的专家级答案。对于高度专业化的问题更好的方式是通过RAG提供专家文档作为上下文而不是仅仅在系统提示词里设定一个角色。5.3 变量注入导致提示词结构破坏当{input}变量中的内容包含一些特殊标记或结构时可能会破坏你精心设计的提示词。例如如果你的提示词是“总结{text}”而text变量本身恰好以“总结”开头就会造成混乱。解决方案在模板中使用更独特、更不可能出现在输入内容中的分隔符或者对输入变量进行简单的清洗和转义。例如用“SUMMARY_TEXT”这样的标记来包裹变量内容。5.4 过度依赖单一提示词缺乏评估与迭代很多人写出一个提示词跑通一次demo就以为万事大吉。实际上提示词需要像代码一样进行测试和迭代。建立测试集准备一批具有代表性的输入用例和期望的输出。量化评估对于分类、提取任务可以使用准确率、召回率。对于生成任务可以人工评估或使用模型本身进行相关性评分。A/B测试对于关键应用可以并行运行不同版本的提示词在线上对比其效果。在LangChain生态中你可以利用langsmith等平台来跟踪和评估不同提示词版本的表现实现数据驱动的提示词优化。5.5 对“系统提示词”的威力认识不足系统提示词System Message是设定模型行为基调的最强大工具。一个常见的误区是把它写得太短、太笼统。比如“你是一个有帮助的助手”。 一个强大的系统提示词应该尽可能具体地定义角色和背景你是什么领域的专家你的知识边界在哪里沟通风格回答应该正式还是随意详细还是简洁安全与边界什么话题不能讨论如何应对模糊或越界的请求输出格式是否倾向于使用列表、表格是否应该主动询问澄清性问题花时间打磨系统提示词往往比在用户消息上绞尽脑汁更能获得整体行为稳定的模型输出。编写提示词不是一个一蹴而就的“魔术”而是一个需要理解模型原理、结合具体场景、不断实验和调整的“工程”过程。在LangChain的框架下通过模块化的模板、可组合的链以及丰富的周边工具我们可以将这门工程实践变得更具可管理性和可扩展性。记住最好的提示词往往是那个最清晰、最无歧义地传达了人类意图的指令。