最近在做一个基于ChatTTS的智能客服项目，发现提示词（Prompt）的设计真是门大学问。调得好，对话流畅自然；调不好，机器人要么答非所问，要么像个复读机。网上资料虽然多，但大多是零散的经验，缺乏系统性的工程化指导。今天就把我踩过的坑和总结的技巧整理出来，希望能帮到正在入门的朋友们。
1. 背景痛点：为什么提示词设计这么难？
刚开始做的时候，我觉得不就是写几句话告诉AI该干嘛吗？但实际一跑起来，问题接踵而至：
- 多轮对话状态维护困难：用户问“北京的天气怎么样？”，AI回答“晴，25度”。用户接着问“那上海呢？”。如果提示词里没有维护好“天气查询”这个意图和“北京”这个实体，AI很可能就懵了，不知道“那上海呢？”指的是上海的天气。
- 意图歧义消除：用户说“帮我订一张票”。这可能是火车票、机票、电影票。单靠一句话，AI很难准确判断。需要结合上下文（比如之前聊过出行）或者通过追问来澄清，这对提示词的上下文设计提出了高要求。
- 效果不稳定：同样的提示词，有时候回答得很棒，有时候又很离谱。这往往是因为输入的用户query存在微小变化，或者AI模型本身存在一定的随机性，导致输出波动。
- 效率低下：每新增一个业务场景或对话分支，就要手动编写和调试大量提示词，缺乏可复用的模板和自动化组装逻辑，开发迭代慢。
这些痛点让我意识到，提示词设计不是一个“写作文”的活，而是一个需要严谨设计和工程化思维的“系统搭建”过程。
2. 技术方案对比：条条大路通罗马，哪条最适合你？
解决上述问题，主要有几种思路，各有优劣：
规则模板驱动：预先定义好大量的
if-else规则和填充模板。比如，检测到关键词“天气”+城市名，就组装成“请查询{city}的天气”的提示词。- 优点：可控性极强，响应速度极快（几乎无时延），结果完全可预测。
- 缺点：维护成本随着业务复杂度指数级上升，无法处理未预定义的query，灵活性差。
机器学习生成：训练一个专门的模型，输入用户query和对话历史，直接生成适合大语言模型的提示词。
- 优点：泛化能力强，能处理未见过的query组合，自动化程度高。
- 缺点：需要标注数据训练，存在生成时延，生成结果可能存在不可控的风险（比如生成低质或有害提示）。
动态组装（当前主流）：结合了规则和学习的优点。核心是有一个“提示词骨架”，里面包含系统指令、上下文槽位、示例等。然后根据实时对话状态，动态地将用户信息、历史记录等“填充”到骨架的对应槽位中。
- 优点：在可控性和灵活性之间取得了很好的平衡，易于维护和迭代，性能较好。
- 缺点：设计“骨架”需要一定的经验，对上下文管理和状态跟踪模块要求较高。
对于大多数追求快速落地和稳定性的项目，动态组装是目前最实用和主流的选择。下面我们就重点聊聊如何实现它。
3. 核心实现：手把手搭建动态提示词引擎
3.1 动态提示词组装逻辑（Python示例）
我们先定义一个基础的提示词模板，它包含系统角色、对话历史和用户当前问题三个部分。
from typing import Dict, List, Optional from dataclasses import dataclass @dataclass class DialogueTurn: """表示对话中的一轮交互。""" role: str # 'user' 或 'assistant' content: str class DynamicPromptEngine: """ 动态提示词组装引擎。 负责根据对话历史和当前查询，组装成发送给LLM的完整提示。 """ def __init__(self, system_prompt: str, max_history_turns: int = 5): """ 初始化引擎。 Args: system_prompt: 系统级别的指令，定义AI的角色和能力。 max_history_turns: 最大保留的历史对话轮数。 """ self.system_prompt = system_prompt self.max_history_turns = max_history_turns self.dialogue_history: List[DialogueTurn] = [] def add_to_history(self, role: str, content: str) -> None: """添加一轮对话到历史记录中。""" if not content.strip(): return # 忽略空内容 self.dialogue_history.append(DialogueTurn(role=role, content=content.strip())) # 限制历史记录长度，保留最近的对话 if len(self.dialogue_history) > self.max_history_turns * 2: # 因为包含user和assistant self.dialogue_history = self.dialogue_history[-self.max_history_turns * 2:] def assemble_prompt(self, current_query: str) -> str: """ 组装完整的提示词。 Args: current_query: 用户当前的问题。 Returns: 组装好的完整提示字符串。 """ # 1. 开头是系统指令 prompt_parts = [f"System: {self.system_prompt}\n\n"] # 2. 拼接历史对话（格式：角色: 内容） for turn in self.dialogue_history: prompt_parts.append(f"{turn.role.capitalize()}: {turn.content}\n") # 3. 加入当前用户问题 prompt_parts.append(f"User: {current_query}\n") prompt_parts.append("Assistant:") # 提示AI开始生成 full_prompt = "".join(prompt_parts) return full_prompt def process_user_query(self, query: str, llm_client) -> str: """ 处理用户查询的完整流程：组装提示 -> 调用LLM -> 更新历史。 Args: query: 用户输入。 llm_client: 配置好的大语言模型客户端。 Returns: AI的回复内容。 Raises: ValueError: 如果用户输入为空。 RuntimeError: 如果LLM调用失败。 """ # 异常处理：输入检查 if not query or not query.strip(): raise ValueError("用户查询内容不能为空。") # 组装提示词 try: full_prompt = self.assemble_prompt(query) except Exception as e: raise RuntimeError(f"组装提示词失败: {e}") # 调用LLM（这里用伪代码表示，实际替换为OpenAI、ChatGLM等SDK调用） try: # 模拟调用，实际中需传入full_prompt ai_response = llm_client.generate(full_prompt) # 假设ai_response是字符串 ai_response_text = ai_response.strip() except Exception as e: raise RuntimeError(f"调用语言模型失败: {e}") # 成功获取回复后，更新对话历史 self.add_to_history("user", query) self.add_to_history("assistant", ai_response_text) return ai_response_text # 使用示例 if __name__ == "__main__": # 定义系统提示，明确AI的角色和任务 sys_prompt = """你是一个专业的天气查询助手。你的回答应简洁、准确。 如果用户没有提供城市名，你需要礼貌地询问。 只回答与天气相关的问题，其他问题告知无法回答。""" engine = DynamicPromptEngine(system_prompt=sys_prompt, max_history_turns=3) # 模拟一个简单的LLM客户端（实际项目中替换为真实客户端） class MockLLMClient: def generate(self, prompt): # 这是一个非常简化的模拟，实际响应应基于prompt内容生成 if "北京" in prompt and "天气" in prompt: return "北京今天晴天，气温20-28度，微风。" elif "上海" in prompt: return "上海今天多云，气温22-30度，东南风3-4级。" else: return "请问您想查询哪个城市的天气？" client = MockLLMClient() try: reply1 = engine.process_user_query("北京天气怎么样？", client) print(f"AI: {reply1}") # 此时历史中已有上一轮对话 reply2 = engine.process_user_query("那上海呢？", client) # AI能通过历史知道是问天气 print(f"AI: {reply2}") except (ValueError, RuntimeError) as e: print(f"处理出错: {e}")这个示例展示了核心的组装逻辑和基本的异常处理。DialogueTurn类结构化地存储每一轮对话。DynamicPromptEngine类负责管理历史、组装提示。process_user_query方法封装了从输入到输出的完整流程，并加入了输入验证和调用失败的处理。
3.2 上下文Embedding的缓存策略
当对话历史很长时，每次都将完整历史文本发给LLM会导致token消耗巨大、速度变慢。一个优化策略是使用向量检索：将历史对话片段转换为向量（Embedding）存入缓存，当新query到来时，只检索最相关的历史片段加入提示词。
import hashlib from typing import Tuple # 假设我们使用 sentence-transformers 库生成向量 # from sentence_transformers import SentenceTransformer class EmbeddingCacheManager: """管理对话历史片段的嵌入向量缓存。""" def __init__(self, embedding_model, cache_size: int = 100): """ Args: embedding_model: 用于生成文本向量的模型。 cache_size: 缓存的最大条目数。 """ self.model = embedding_model self.cache: Dict[str, Tuple[List[float], str]] = {} # key: 文本MD5, value: (向量, 文本) self.cache_size = cache_size self._keys_queue = [] # 用于LRU淘汰的队列 def _get_text_hash(self, text: str) -> str: """生成文本的唯一哈希键。""" return hashlib.md5(text.encode('utf-8')).hexdigest() def get_embedding(self, text: str) -> List[float]: """获取文本的向量，优先从缓存读取。""" text_hash = self._get_text_hash(text) if text_hash in self.cache: # 缓存命中，更新LRU队列（移到末尾） self._keys_queue.remove(text_hash) self._keys_queue.append(text_hash) return self.cache[text_hash][0] else: # 缓存未命中，计算并存储 vector = self.model.encode(text).tolist() # 假设返回numpy数组 self.cache[text_hash] = (vector, text) self._keys_queue.append(text_hash) # 如果缓存满了，淘汰最久未使用的 if len(self._keys_queue) > self.cache_size: oldest_key = self._keys_queue.pop(0) del self.cache[oldest_key] return vector # 在DynamicPromptEngine中集成 class AdvancedPromptEngine(DynamicPromptEngine): def __init__(self, system_prompt: str, embedding_cache_manager: EmbeddingCacheManager, top_k: int = 2): super().__init__(system_prompt) self.cache_manager = embedding_cache_manager self.top_k = top_k # 检索最相关的K段历史 def assemble_prompt(self, current_query: str) -> str: # 1. 系统指令 prompt_parts = [f"System: {self.system_prompt}\n\n"] # 2. 基于向量检索，选择最相关的历史片段，而不是全部历史 if self.dialogue_history: # 为当前查询生成向量 query_vector = self.cache_manager.get_embedding(current_query) # 为每段历史生成或获取向量，并计算相似度（这里用余弦相似度伪代码） scored_history = [] for turn in self.dialogue_history: hist_vector = self.cache_manager.get_embedding(turn.content) # 计算余弦相似度 (sim = dot(a,b)/(|a||b|)) # ... 此处省略具体计算代码 ... similarity = 0.5 # 假设值 scored_history.append((similarity, turn)) # 按相似度排序，取top-k scored_history.sort(key=lambda x: x[0], reverse=True) relevant_turns = [turn for _, turn in scored_history[:self.top_k]] for turn in relevant_turns: prompt_parts.append(f"{turn.role.capitalize()}: {turn.content}\n") # 3. 当前问题 prompt_parts.append(f"User: {current_query}\nAssistant:") return "".join(prompt_parts)这个策略能显著减少提示词的长度，尤其是在长对话场景下，既节省了成本，又可能因为去除了无关历史的干扰而提升回复质量。
4. 生产环境考量：稳定与安全并重
系统上线后，不能只关注功能，还要考虑性能和安全性。
4.1 性能测试指标设计
- 首字节时间（TTFB）：从用户发送请求到收到AI回复第一个字的时间。这直接影响到用户体验。需要监控提示词组装、模型调用、网络传输各阶段的耗时。
- 错误率：请求失败（如网络超时、模型服务异常、提示词组装异常）的比例。需要设立警报阈值。
- 平均响应长度/Token消耗：监控每个请求消耗的Token数，用于成本核算和优化提示词长度。
- 意图识别准确率：对于有明确意图分类的系统，需要定期抽样评估AI是否正确理解了用户意图。
4.2 敏感词过滤的异步处理方案
直接在主流程中同步进行复杂的敏感词过滤（如调用外部API或运行大模型）会增加响应延迟。一个更好的方案是异步审核：
- 主流程（同步）：快速生成AI回复，立即返回给用户，保证体验流畅。
- 旁路流程（异步）：将生成的回复放入消息队列（如Redis Stream, RabbitMQ）。
- 审核服务（消费者）：从队列中取出消息，进行更严格、更耗时的敏感词、合规性审核。
- 处置：如果审核不通过，可以通过站内信、客服介入等方式联系用户进行后续处理，甚至对AI回复进行“打补丁”或撤回。
这样实现了体验与安全的平衡。
5. 避坑指南：三个常见的设计反模式
反模式：提示词中过度嵌套条件判断
- 问题：在系统提示里写大量的“如果用户问A，你就回答B；否则如果问C，就回答D...”。这本质上是把业务逻辑硬编码进了提示词，导致提示词臃肿，且LLM可能无法正确理解复杂的指令逻辑。
- 改进方案：将业务逻辑判断放在应用层代码中。用代码判断用户意图和对话状态，然后根据判断结果，选择或组装不同的基础提示词模板再发给LLM。让LLM专注于“生成自然语言”，而不是“执行逻辑判断”。
反模式：忽视上下文长度限制
- 问题：无限制地将所有对话历史都塞进提示词，很容易超过模型的最大上下文长度（如4K、8K、32K tokens），导致请求被拒绝或历史被截断，丢失重要信息。
- 改进方案：实现智能上下文窗口。如前面提到的向量检索缓存，只保留最相关的历史。或者采用“摘要”技术，将较旧的对话历史总结成一段简短的摘要，再将摘要和近期对话一起送入提示词。
反模式：使用模糊或矛盾的指令
- 问题：提示词中包含“请给出简短回答”和“请详细解释原因”这类矛盾指令，或者使用“很好”、“不错”等模糊的形容词来定义输出质量。
- 改进方案：指令要具体、明确、可操作。用结构化要求替代模糊描述。例如，将“给出简短回答”改为“答案不超过2句话”；将“详细解释”改为“请分步骤说明，并每步举一个例子”。
6. 代码规范：保持整洁与可维护性
上面的示例代码已经努力遵循PEP8规范，并添加了类型注解和docstring。这里再强调几个关键点：
- 函数单一职责：每个函数只做一件事，比如
assemble_prompt只负责组装，不负责调用LLM。 - 善用数据类：像
DialogueTurn这样结构固定的数据，使用dataclass让代码更清晰。 - 防御式编程：在
process_user_query中对输入进行校验，对可能失败的LLM调用进行try-catch。 - 清晰的命名：变量和函数名要能直观反映其用途，避免使用
tmp,data等泛泛的名称。
7. 互动与思考
实践出真知。在搭建你自己的提示词引擎时，不妨带着下面两个问题去思考和优化：
- 如何量化评估你设计的提示词的好坏？除了人工测试，能否设计一些自动化的评估指标（如回复相关性评分、用户满意度预测模型）来驱动提示词的迭代优化？
- 当业务场景非常复杂，涉及多步骤任务（如订票、退改签）时，单纯的“历史对话”作为上下文是否足够？是否需要引入更复杂的“对话状态跟踪（DST）”模块来显式管理任务进度、槽位填充情况，并将这个状态也作为提示词的一部分？
提示词工程是连接业务需求与大模型能力的桥梁，需要不断地调试、观察、分析和迭代。希望这篇笔记能为你打下坚实的基础，少走一些弯路。如果你有更好的想法或遇到了新的坑，欢迎一起交流探讨！
