在大型语言模型的实际部署中，推理成本与响应速度是两大核心瓶颈，而这两者都与模型处理输入的令牌数量直接相关。一个常见的优化思路是：能否在不牺牲模型理解能力的前提下，减少输入提示中的令牌消耗？这不仅是成本问题，也关乎性能。本文将以一个具体的工程实践为例，探讨如何通过重构提示词的结构与内容，实现用更少的令牌完成与“ACE”相关的复杂任务，并确保输出质量不受影响。我们将从概念分析入手，逐步拆解优化策略，提供可操作的代码示例和验证方法，并最终给出在生产环境中落地此类优化的检查清单。

1. 理解令牌经济性：为什么“少即是多”

在深入技术细节前，必须明确一个核心概念：对于大多数按令牌计费的云服务或自托管模型，输入和输出的令牌总数直接决定了单次推理的成本。同时，更长的输入序列也会增加模型的计算负担，可能导致更长的延迟。

1.1 令牌与成本、延迟的关系

令牌是大型语言模型处理文本的基本单位。一个令牌可能是一个单词、一个子词甚至一个标点符号。模型在处理输入时，需要为每个令牌分配计算资源以生成其对应的上下文表示。因此，输入令牌数（n_input_tokens）直接影响：

• 计算成本：更多的输入令牌意味着更多的矩阵运算。
• 内存占用：需要存储更长的键值缓存。
• 推理延迟：序列越长，模型生成第一个输出令牌所需的时间可能越长（对于自回归模型）。

在按量付费的场景下，成本公式通常为：Cost = (n_input_tokens + n_output_tokens) * price_per_token。优化输入令牌数，就是从源头降低成本。

1.2 “ACE”任务的典型提示结构及其问题

假设我们有一个任务，需要模型基于用户提供的“Action”（行动）、“Context”（上下文）和“Expected Result”（预期结果）——即“ACE”框架——来生成一份详细的技术方案。一个未经优化的提示可能如下：

你是一个资深的软件架构师。请根据用户提供的以下三个要素，撰写一份详细的技术实施方案文档。 要素说明： 1. Action（行动）： 用户希望系统执行的核心操作或功能。 2. Context（上下文）： 该行动发生的背景环境、技术栈、约束条件和相关系统状态。 3. Expected Result（预期结果）： 行动成功执行后，系统应达到的状态或输出的具体指标。 用户输入： Action: 为微服务A设计一个熔断机制。 Context: 当前系统使用Spring Cloud框架，服务间通过HTTP调用。在促销活动期间，服务B的响应时间偶尔会飙升到5秒以上，导致调用链路上的服务A也出现线程池耗尽和响应超时。 Expected Result: 实现一个熔断器，当服务B的失败率（如超时、5xx错误）在10秒窗口期内超过50%时，快速失败并进入熔断状态，熔断持续30秒后进入半开状态尝试放行少量请求。 请确保你的方案包含：技术选型理由、核心配置参数、代码结构示例、熔断状态转换逻辑说明以及监控指标设计。方案需要专业、详尽且可直接用于开发评审。

这个提示词清晰、结构化，但存在明显的令牌浪费：

1. 角色定义冗长：“你是一个资深的软件架构师”是有效的，但可以更精简。
2. 框架说明重复：在任务描述中详细解释了“ACE”每个部分的含义，但这些解释可能对于已经理解该框架的模型是冗余的，或者可以更紧凑地表达。
3. 指令分散：需求说明（“请确保你的方案包含...”）与任务描述分离，增加了认知负荷。
4. 格式化空格：为了人类可读性添加的大量换行和缩进，对模型而言都是额外的令牌。

2. 提示词优化策略：从结构到语义的压缩

优化提示词不是简单地删除文字，而是在保留核心指令和信息的前提下，进行结构重组和语义精炼。目标是让模型以最少的“燃料”理解相同的“任务地图”。

2.1 策略一：使用更紧凑的指令格式

将开放式的叙述性指令，转换为模型更易解析的键值对或标记化指令。模型在预训练时见过大量结构化数据，对这种格式的理解效率很高。

优化前（叙述式）:

你是一个资深的软件架构师。请根据用户提供的以下三个要素，撰写一份详细的技术实施方案文档... 用户输入： Action: ... Context: ... Expected Result: ...

优化后（结构化指令）:

角色：软件架构师 任务：基于ACE框架生成技术方案 输入格式： - A: [行动] - C: [上下文] - E: [预期结果] 输出要求：含技术选型、核心配置、代码示例、状态逻辑、监控指标。 输入： A: 为微服务A设计一个熔断机制。 C: Spring Cloud, HTTP调用，服务B偶发5秒+延迟，导致A线程池耗尽。 E: 熔断器：10秒窗口失败率>50%则熔断，30秒后半开。 方案：

优化点分析：

• “角色：软件架构师”比“你是一个资深的软件架构师”更直接。
• “任务：基于ACE框架生成技术方案”概括了整个目标。
• 使用“A:”、“C:”、“E:”作为明确的分隔符，模型能快速定位信息块。
• 将“输出要求”紧跟在任务后，作为生成约束。
• 对Context和Expected Result进行了语义压缩，去除了不影响核心信息的描述性词语（如“当前系统”、“促销活动期间”、“偶尔”），但保留了关键约束（“5秒+延迟”，“线程池耗尽”）。

2.2 策略二：利用系统的角色预设或上下文学习

如果调用API（如OpenAI API或本地部署的vLLM），可以利用system角色消息来承载不变的指令和角色设定，从而不在每次的user消息中重复。对于不支持多角色对话的简单接口，可以将系统指令前置并固化。

API调用示例（OpenAI风格）:

import openai # 系统消息包含角色和固定任务框架，通常只发送一次或在会话开头发送。 system_message = { "role": "system", "content": "你是一名软件架构师，负责根据ACE（行动、上下文、预期结果）输入生成技术方案。输出需包含：技术选型、配置、代码示例、逻辑说明、监控指标。" } # 用户消息仅包含当次查询的具体ACE内容，非常精简。 user_message = { "role": "user", "content": "A:设计熔断机制\nC:Spring Cloud,服务B延迟高致A线程池耗尽\nE:失败率>50%熔断，30秒后半开" } response = openai.ChatCompletion.create( model="gpt-4", messages=[system_message, user_message], temperature=0.7 )

在这个例子中，system_message的内容在多次对话中只需传输一次（如果会话保持），后续的user_message可以极其精简，大幅节省了令牌。

2.3 策略三：精简示例与上下文

如果任务复杂，需要少量示例（Few-Shot Learning），示例的选择和呈现方式至关重要。

• 选择最具代表性的示例：一个覆盖边界的复杂示例，可能比两个简单的示例更有效。
• 压缩示例内容：在示例中同样应用上述优化策略，精简输入和输出。
• 使用分隔符：用###、---或<example>等清晰分隔示例与真实查询，避免模型混淆。

3. 工程实践：构建一个提示词优化与评估管道

理论需要实践验证。我们构建一个简单的Python流程，来量化优化效果并确保质量。

3.1 环境准备与依赖

首先，确保你的Python环境（建议3.8+）并安装必要库。我们将使用tiktoken（用于OpenAI模型令牌计数）或transformers（用于开源模型）来计数，并使用一个LLM服务进行质量评估。

# 创建虚拟环境（可选） python -m venv venv source venv/bin/activate # Linux/Mac # venv\Scripts\activate # Windows # 安装依赖 pip install openai tiktoken transformers # 基础工具包 # 如果你使用其他LLM API，如Anthropic Claude，安装对应SDK # pip install anthropic

3.2 实现令牌计数器

编写一个函数，用于计算给定提示词的令牌数。这里以OpenAI的cl100k_base编码器（GPT-4/3.5-turbo使用）为例。

import tiktoken def count_tokens_openai(text: str, model: str = "gpt-4") -> int: """ 使用tiktoken计算文本的令牌数。 Args: text: 输入文本。 model: 模型名称，用于选择编码器。 Returns: 令牌数量。 """ try: encoding = tiktoken.encoding_for_model(model) except KeyError: # 如果模型未找到，使用 cl100k_base (GPT-4/3.5-turbo的编码) encoding = tiktoken.get_encoding("cl100k_base") tokens = encoding.encode(text) return len(tokens) # 测试函数 original_prompt = """你是一个资深的软件架构师。请根据用户提供的以下三个要素...""" # 此处填入完整的原始长提示 optimized_prompt = """角色：软件架构师 任务：基于ACE框架生成技术方案...""" # 此处填入优化后的提示 orig_tokens = count_tokens_openai(original_prompt) opt_tokens = count_tokens_openai(optimized_prompt) print(f"原始提示令牌数: {orig_tokens}") print(f"优化后提示令牌数: {opt_tokens}") print(f"减少的令牌数: {orig_tokens - opt_tokens}") print(f"优化比例: {(1 - opt_tokens/orig_tokens)*100:.2f}%")

3.3 设计质量评估方法

令牌减少了，但输出质量是否下降？我们需要一个评估机制。一个简单有效的方法是使用另一个LLM（或同一模型）作为“裁判”，根据既定标准对原始输出和优化后输出进行评分。

import openai import json def evaluate_response_with_llm(original_output, optimized_output, evaluation_criteria): """ 使用LLM评估两个回复的质量。 Args: original_output: 原始长提示得到的回复。 optimized_output: 优化后提示得到的回复。 evaluation_criteria: 评估标准列表。 Returns: 包含评分和理由的字典。 """ prompt = f""" 你是一个技术方案评审专家。请比较以下两个技术方案回复（Reply A 和 Reply B）的质量。 评估标准如下： {json.dumps(evaluation_criteria, indent=2, ensure_ascii=False)} 请从每个标准出发，分析两个回复的优劣。最后，给出一个综合评分（1-10分，10分为最佳），并说明哪个回复更优或是否相当。 Reply A (来自原始提示):

{original_output}

Reply B (来自优化提示):

{optimized_output}

请以JSON格式输出你的评估结果，包含以下字段： - "criteria_analysis": 对每个标准的详细分析。 - "score_a": Reply A的综合得分。 - "score_b": Reply B的综合得分。 - "conclusion": 最终结论，说明哪个回复更优或是否持平。 """ # 调用LLM API，这里需要替换为你自己的API密钥和端点 openai.api_key = "your-api-key" response = openai.ChatCompletion.create( model="gpt-4", messages=[{"role": "user", "content": prompt}], temperature=0.2 # 低温度保证评估稳定性 ) evaluation_text = response.choices[0].message.content # 尝试解析JSON，如果失败则返回原始文本 try: return json.loads(evaluation_text) except json.JSONDecodeError: return {"raw_evaluation": evaluation_text} # 定义评估标准 criteria = [ "完整性：是否涵盖了所有要求的要点（技术选型、配置、代码示例、状态逻辑、监控指标）。", "准确性：技术细节、配置参数、代码逻辑是否正确无误。", "清晰度：方案结构是否清晰，表述是否易于理解。", "实用性：方案是否可直接或经少量修改后用于开发评审。" ] # 假设我们已经获得了original_output和optimized_output # evaluation_result = evaluate_response_with_llm(original_output, optimized_output, criteria) # print(json.dumps(evaluation_result, indent=2, ensure_ascii=False))

3.4 运行完整对比实验

将以上步骤组合，形成一个完整的A/B测试流程。

def run_ace_prompt_experiment(original_prompt_text, optimized_prompt_text, ace_input, api_key): """ 运行完整的提示词对比实验。 """ openai.api_key = api_key # 1. 计算令牌节省 orig_tokens = count_tokens_openai(original_prompt_text + "\n" + ace_input) opt_tokens = count_tokens_openai(optimized_prompt_text + "\n" + ace_input) token_saving = orig_tokens - opt_tokens print("=== 令牌消耗对比 ===") print(f"原始提示组合令牌数: {orig_tokens}") print(f"优化提示组合令牌数: {opt_tokens}") print(f"预计单次节省令牌: {token_saving} ({token_saving/orig_tokens*100:.1f}%)") # 2. 调用模型获取回复 def get_completion(prompt): response = openai.ChatCompletion.create( model="gpt-3.5-turbo", # 可使用gpt-4，但成本更高 messages=[{"role": "user", "content": prompt}], temperature=0.7, max_tokens=1500 ) return response.choices[0].message.content.strip() print("\n=== 生成回复... ===") original_full_prompt = original_prompt_text + "\n用户输入：\n" + ace_input optimized_full_prompt = optimized_prompt_text + "\n输入：\n" + ace_input reply_original = get_completion(original_full_prompt) reply_optimized = get_completion(optimized_full_prompt) # 3. 评估回复质量 print("\n=== 进行质量评估... ===") criteria = [...] # 同上文的评估标准 evaluation = evaluate_response_with_llm(reply_original, reply_optimized, criteria) print("\n=== 评估结果 ===") print(f"原始回复得分: {evaluation.get('score_a', 'N/A')}") print(f"优化回复得分: {evaluation.get('score_b', 'N/A')}") print(f"结论: {evaluation.get('conclusion', 'N/A')}") # 4. 综合报告 print("\n=== 实验总结 ===") if evaluation.get('score_b', 0) >= evaluation.get('score_a', 0) * 0.95: # 优化后质量不低于原始的95% print("✅ 成功：在保持质量的前提下，显著减少了令牌消耗。") print(f" 令牌节省比例: {token_saving/orig_tokens*100:.1f}%") else: print("⚠️ 注意：令牌减少但质量有较明显下降，需要调整优化策略。") return { "token_original": orig_tokens, "token_optimized": opt_tokens, "reply_original": reply_original, "reply_optimized": reply_optimized, "evaluation": evaluation } # 执行实验 # 注意：需要准备好 original_prompt_text, optimized_prompt_text, ace_input 和有效的 api_key # result = run_ace_prompt_experiment(original_prompt_text, optimized_prompt_text, ace_input, "sk-...")

4. 常见问题与排查指南

在实际优化过程中，你可能会遇到以下问题。

4.1 优化后模型输出偏离预期

现象：令牌数下降了，但生成的方案遗漏关键要求，或格式混乱。可能原因与解决方案：

1. 指令过度压缩导致歧义：过度精简丢失了关键约束。例如，删除了“包含监控指标”的要求。
   • 检查：对比优化前后提示词，确保所有硬性要求（Must-have）都被保留。
   • 解决：使用更精确的关键词而非删除。将“请确保你的方案包含：...监控指标设计”优化为“输出要求：含...监控指标。”。
2. 结构变化导致模型解析困难：模型可能不熟悉你自定义的极简标记（如只用“A:”）。
   • 检查：在优化提示中是否使用了模型在预训练中常见的分隔符或格式。
   • 解决：在system消息或提示开头，用一句话明确格式：“请严格按以下格式理解输入：A: [行动] C: [上下文] E: [结果]”。
3. 上下文长度不足：过度压缩的Context可能丢失了关键边界条件。
   • 检查：优化后的Context是否仍包含所有影响技术决策的约束（如“Spring Cloud框架”、“HTTP调用”、“线程池耗尽”）。
   • 解决：优先保留名词性关键约束，删除形容词和副词性描述。

4.2 令牌计数与API计费不一致

现象：本地计算的令牌数与云服务商账单显示的令牌数有差异。可能原因与解决方案：

1. 编码器不一致：不同模型使用不同的分词器（Tokenizer）。
   • 检查：确认你使用的计数工具（如tiktoken）是否与目标API模型匹配。
   • 解决：对于OpenAI API，使用tiktoken并指定正确模型名（如gpt-4）。对于其他模型，需使用其官方或兼容的分词器（如Hugging Face的transformers库）。
2. 计入了特殊令牌：API计费可能包括了消息角色（如<|im_start|>user）等特殊令牌。
   • 检查：API文档是否说明了输入输出的具体计数方式。
   • 解决：对于精确成本测算，最好使用API提供商提供的计数工具或在实际调用后查看返回的usage字段。

4.3 质量评估结果不稳定

现象：同一对输出，多次评估得分波动较大。可能原因与解决方案：

1. 评估提示词本身不精确：评估标准过于主观（如“质量更好”）。
   • 检查：评估标准是否具体、可衡量（如“是否提及Hystrix或Resilience4j”）。
   • 解决：将评估标准细化、量化。使用清单式评估，让LLM裁判做“是非题”而非“论述题”。
2. 评估模型温度（Temperature）设置过高：导致评估结果随机性大。
   • 检查：在评估调用中是否设置了较低的temperature（如0.1或0.2）。
   • 解决：将评估模型的temperature设为0，或使用确定性更高的模型（如gpt-4）。

5. 生产环境最佳实践与扩展方向

将提示词优化纳入开发流程，需要系统化的方法。

5.1 建立提示词版本管理与测试套件

像管理代码一样管理提示词。

• 版本控制：使用Git管理原始提示和优化后提示，提交信息记录优化策略和预期收益。
• 回归测试：为关键任务提示词建立一组标准测试用例（ACE输入和期望输出的关键点）。每次优化后，运行测试套件，确保输出质量不低于基线。
• A/B测试：在允许的情况下，在生产流量中进行小比例的A/B测试，直接比较优化前后版本的用户满意度或任务完成率。

5.2 制定提示词优化清单

在重构任何提示词前，对照此清单检查：

1. 角色定义：能否用一两个词概括？能否移到system消息中？
2. 任务描述：核心指令是否在开头用一句话说清？
3. 输入格式：是否使用模型熟悉的结构（如JSON、键值对、清晰分隔符）？
4. 输出要求：是否以清单形式列出，而非段落描述？
5. 示例：是否必要？如果必要，是否已最大程度精简？
6. 冗余修饰词：是否删除了“请”、“一个”、“详细的”等不影响核心语义的词语？（注意：有时“请”有助于改善语气，需权衡）。
7. 上下文信息：是否只保留了影响决策的关键名词和数字，删除了背景故事？

5.3 探索自动化与高级优化技术

对于大规模应用，可以考虑：

• 提示词压缩算法：研究如LLMLingua等基于小型语言模型识别并删除提示中冗余令牌的技术。
• 提示词微调（Fine-tuning）：针对特定任务训练一个模型，使其在极简指令下就能输出高质量结果，从根本上减少对长提示的依赖。
• 语义缓存：对于相同或相似语义的查询，直接返回缓存的结果，避免重复调用LLM。

最终，记住优化的黄金法则：先确保提示词清晰、准确、能稳定产生高质量输出，然后再对其进行压缩。不能本末倒置，为了节省少量令牌而引入输出不确定性和错误风险。通过本文提供的策略、工具和清单，你可以系统化地开展这项工作，在成本、速度和效果之间找到最佳平衡点。