标书智能体（四）——提示词顺序优化，让缓存命中，输入成本直降10倍

用 Python + React 打造一个开源的 AI 写标书智能体~
完整代码已开源。
代码很多，文章只放主要代码和提示词，完整代码可以查看开源项目。
Github： https://github.com/FB208/yibiao-simple
Gitee： https://gitee.com/yibiao-ai/yibiao-simple
今天是第四期，聊一个做 AI 应用大家都特别关心，但容易走错方向的问题：
成本和提示词顺序的关系
提示词的组织顺序如果写对了，除了结果质量，连成本都能一起降下来。
前面三期，我们已经把标书智能体的主流程基本打通了：

• 解析招标文件，提取项目概述和技术评分要求。
  
• 根据解析结果生成技术标提纲。
  
• 根据提纲逐章生成正文。
  

做到这一步，其实系统已经可以用了。
但真用起来就会发现，标书这个场景和普通聊天不一样，最大的成本不一定在输出，而在输入。
一份招标文件动辄几万字，项目概述和评分要求也不短。正文生成时，同一份项目概述、同一套章节层级信息，还会被反复传给模型。
而节约成本最好的办法，不是精简提示词，而是调整提示词的顺序！
如果提示词结构写得不对，服务商的缓存能力就很难吃到，钱就白白花出去了。
一、为什么吃不到缓存

很多大模型服务商都支持 Prompt Cache，或者有类似的缓存机制。
但缓存不是你以为的那种“只要内容一样就行”。
大多数情况下，它看的是请求前缀。
也就是说，前面那一大段内容是不是稳定，是不是一致，是不是每次都放在同样的位置。
如果你把一份很长的正文，放在提示词后面，而前面先拼了很多每次都不一样的说明，那这份长文本虽然看起来是一样的，服务商也未必把它识别成同一个可复用前缀。
拿文档解析这个功能举例。
我们对同一份招标文件，会做两次分析：

• 提取项目概述
  
• 提取技术评分要求
  

最开始我的写法是这样的：

1. def build_analysis_messages(file_content: str, analysis_type: str) -> List[Dict[str, str]]:
2.     if analysis_type == 'overview':
3.         system_prompt = '提取项目概述的 system prompt'
4.         analysis_type_cn = '项目概述'
5.     else:
6.         system_prompt = '提取技术评分要求的 system prompt'
7.         analysis_type_cn = '技术评分要求'
9.     user_prompt = (
10.         f'请分析以下招标文件内容，提取{analysis_type_cn}信息：\n\n{file_content}'
11.     )
13.     return [
14.         {'role': 'system', 'content': system_prompt},
15.         {'role': 'user', 'content': user_prompt},
16.     ]

复制代码

问题出在哪？
不是 file_content 不一样，恰恰相反，file_content 是一样的。
问题在于：

• 两次请求的 system_prompt 不一样
  
• 两次请求的 user_prompt 前缀也不一样
  
• 真正占 token 的大文本 file_content 被放到了后面
  

这样一来，服务商看到的不是“同一个长前缀”，而是“两个不一样的请求，后面有一大段内容刚好相同”。
那缓存命中率自然就高不起来。
二、解决方案

这个问题想通以后，改法其实很简单。
原则就一句话：
把大且稳定的上下文放前面，把这次请求的任务差异放最后。
改造后的文档解析提示词变成了这样：

1. def build_analysis_messages(file_content: str, analysis_type: str) -> List[Dict[str, str]]:
2.     system_prompt = """你是一名专业的招标文件分析助手。请严格基于用户提供的招标文件原文完成分析任务。
4. 通用要求：
5. 1. 保持提取信息的全面性和准确性，尽量使用原文内容，不要自行编造
6. 2. 只输出最终分析结果，不要输出额外说明、过程、提示语或客套话
7. 3. 如果文档内容不足以支持某项结论，应明确说明原文未提及，不要凭空补充
8. """
10.     file_prompt = f"""以下是完整招标文件全文，请先完整阅读，并仅基于原文完成后续任务：
12. {file_content}"""
14.     if analysis_type == 'overview':
15.         task_prompt = '任务：提取并总结项目概述信息。...'
16.     else:
17.         task_prompt = '任务：提取技术评分要求。...'
19.     return [
20.         {'role': 'system', 'content': system_prompt},
21.         {'role': 'user', 'content': file_prompt},
22.         {'role': 'user', 'content': task_prompt},
23.     ]

复制代码

这样改完以后，这两个请求的共同前缀就很清晰了：

• 第一条 system 一样
  
• 第二条全文 user 一样
  
• 只有最后一条任务说明不一样
  

这个结构，就比原来那种“先写不同任务，再塞同一份全文”的方式，更容易命中缓存。
三、提纲编写部分优化

第二期讲提纲生成的时候，重点主要放在 JSON 格式和目录质量上。
但从成本角度看，提纲生成也有一样的问题。
同一个项目里，用户经常会多点几次“重新生成目录”。
那同一份 overview 和 requirements 就会被反复发给模型。
旧写法通常是把它们拼成一个大 user_prompt：

1. user_prompt = f"""请基于以下项目信息生成标书目录结构：
3. 项目概述：
4. {overview}
6. 技术评分要求：
7. {requirements}
9. 请生成完整的技术标目录结构，确保覆盖所有技术评分要点。"""

复制代码

这当然没错，但对于缓存来说，不够细。
我们现在改成了多消息结构：

1. def generate_outline_prompt(overview: str, requirements: str) -> List[Dict[str, str]]:
2.     return [
3.         {'role': 'system', 'content': _build_outline_system_prompt()},
4.         {'role': 'user', 'content': f'项目概述：\n{overview}'},
5.         {'role': 'user', 'content': f'技术评分要求：\n{requirements}'},
6.         {
7.             'role': 'user',
8.             'content': '请生成完整的技术标目录结构，确保覆盖所有技术评分要点。',
9.         },
10.     ]

复制代码

如果是结合用户旧目录一起生成，也照样拆开：

1. def generate_outline_with_old_prompt(
2.     overview: str,
3.     requirements: str,
4.     old_outline: str | None,
5. ) -> List[Dict[str, str]]:
6.     return [
7.         {'role': 'system', 'content': _build_outline_system_prompt()},
8.         {'role': 'user', 'content': f'项目概述：\n{overview}'},
9.         {'role': 'user', 'content': f'技术评分要求：\n{requirements}'},
10.         {'role': 'user', 'content': f'用户自己编写的目录：\n{old_outline or ""}'},
11.         {
12.             'role': 'user',
13.             'content': '请在满足技术评分要求的前提下，充分结合用户自己编写的目录，生成完整的技术标目录结构。',
14.         },
15.     ]

复制代码

这么写的好处很直接：

• 项目概述和评分要求变成了稳定的共享上下文
  
• 普通目录生成和旧目录扩写，也能共享前面一部分前缀
  

四、消耗最大的正文编写，必须优化

第三期讲正文生成时，我们已经解决了两个最核心的问题：

• 标书太长，不能一次性生成，必须拆成叶子章节逐节写
  
• 分节写容易重复，所以要把上级章节和同级章节信息一起传给模型
  

这个思路本身没有问题。
但从缓存的角度再回头看，会发现正文生成这一段才是真正的大头。
因为正文生成是整个系统里调用次数最多的功能。
一个项目几十个叶子章节很正常。每个章节都要发一次请求，那下面这些内容就会被反复传很多遍：

• 同一份 project_overview
  
• 相同的 parent_chapters
  
• 高度重叠的 sibling_chapters
  
• 一模一样的正文写作规则
  

旧写法是把这些内容全拼进一个大 user_prompt：

1. user_prompt = f"""请为以下标书章节生成具体内容：
3. {context_info}
5. 当前章节信息：
6. 章节ID: {chapter_id}
7. 章节标题: {chapter_title}
8. 章节描述: {chapter_description}
10. 请根据项目概述信息和上述章节层级关系，生成详细的专业内容..."""

复制代码

现在改成了分层消息：

1. def build_chapter_content_messages(
2.     chapter: Dict[str, Any],
3.     parent_chapters: List[Dict[str, Any]] | None = None,
4.     sibling_chapters: List[Dict[str, Any]] | None = None,
5.     project_overview: str = '',
6. ) -> List[Dict[str, str]]:
7.     messages = [
8.         {'role': 'system', 'content': system_prompt},
9.     ]
11.     if project_overview.strip():
12.         messages.append(
13.             {'role': 'user', 'content': f'项目概述信息：\n{project_overview}'}
14.         )
16.     if parent_chapters:
17.         messages.append({'role': 'user', 'content': parent_context})
19.     if sibling_chapters:
20.         messages.append({'role': 'user', 'content': sibling_context})
22.     messages.append(
23.         {
24.             'role': 'user',
25.             'content': f'''请为以下标书章节生成具体内容：
27. 当前章节信息：
28. 章节ID: {chapter_id}
29. 章节标题: {chapter_title}
30. 章节描述: {chapter_description}
32. 请根据项目概述信息和上述章节层级关系，生成详细的专业内容...''',
33.         }
34.     )
36.     return messages

复制代码

这一步的价值特别大。
因为同一个父章节下面的多个叶子节点，往往都有下面这些共同点：

• project_overview 一样
  
• parent_chapters 一样
  
• sibling_chapters 高度接近
  
• 真正变化最大的，其实只是最后那条当前章节任务
  

也就是说，正文生成这一块，不仅请求多，而且重复上下文还特别长。
这也是为什么正文生成最值得做缓存优化。
五、总结

这次改完以后，我觉得最重要的不是某一段具体提示词，而是下面这套规则。
以后只要是高频 AI 任务，都可以优先按这个思路来组织提示词：
1. system 只放稳定规则

不要把这次请求特有的差异塞进 system。
system 更适合放：

• 通用角色
  
• 通用写作规范
  
• 通用输出要求
  

2. 最大、最稳定的上下文尽量前置

比如：

• 招标文件全文
  
• 项目概述
  
• 技术评分要求
  
• 目录树
  
• 上级章节链
  

这些内容越稳定、越长、越可能重复利用，就越应该尽量往前放。
3. 任务差异尽量放最后

比如：

• 提取项目概述
  
• 提取技术评分要求
  
• 生成目录
  
• 生成 3.2.1 章节正文
  

这些都是每次请求最容易变化的内容，应该尽量放到最后。
4. 同一份数据的组织格式要保持稳定

缓存看的是前缀，不只是“意思差不多”。
所以这些细节都要保持一致：

• 标题写法一致
  
• 换行数量一致
  
• 列表顺序一致
  
• 不要一会儿 strip() 一会儿不 strip()
  
• 不要把随机信息、时间戳塞进共享上下文
  

这些看起来都是小事，但对缓存命中影响非常直接。
六、实测结果

我用OpenRouter上的gemini-2.5-flash模型做了一次标书解析的测试，从几万字的招标文件中解析项目概述和技术评分要求，很明显可以看出第一轮请求是正常的，第二轮请求的输入提示词，基本都吃到了缓存，成本直降90%以上。
测试环境如下：

• 服务商：OpenRouter
  
• 模型：google/gemini-2.5-flash
  
• 请求地址：https://openrouter.ai/api/v1/chat/completions
  
• 测试方式：招标文件解析
  

第一次请求日志里的关键字段是：

1. request_id: c405ec7f755549629e8a47c04d5b2633
2. prompt_tokens：19349
3. cached_tokens: 0
4. upstream_inference_prompt_cost: 0.0058047

复制代码

第一次请求相当于把缓存写进去，所以 cached_tokens 为 0，输入提示词费用按正常价格计算。
第二次请求日志里的关键字段变成了：

1. request_id: b4cfd26bdef74b9c941263a96b692cea
2. prompt_tokens：19737
3. cached_tokens: 19442
4. upstream_inference_prompt_cost: 0.00067176

复制代码

这个结果就很说明问题了：

• 第二次请求已经成功命中了缓存
  
• 命中的缓存 token 数达到了 19442
  
• 输入提示词费用从 0.0058047 降到了 0.00067176
  

也就是说，同样是一份很长的招标文件上下文，第二次请求的输入成本已经降到了第一次的大约九分之一，基本就是接近 10 倍的差距。
这一点特别重要。因为它说明了，缓存优化不是玄学，也不是“可能会省一点”。
只要下面几个条件满足：

• 前缀稳定
  
• 大文本够长
  
• 第二次请求跟得足够快
  
• 模型和服务商本身支持缓存
  

那它省下来的钱，是可以直接从日志里看到的。
完整代码已开源

Github： https://github.com/FB208/yibiao-simple
Gitee： https://gitee.com/yibiao-ai/yibiao-simple

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！