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

极客资料网推荐标书智能体（四）——提示词顺序优化，让缓存命中，输入成本直降10倍这篇文章给大家，欢迎收藏极客资料网享受知识的乐趣

用 Python + React 打造一个开源的 AI 写标书智能体~

完整代码已开源。

代码很多，文章只放主要代码和提示词，完整代码可以查看开源项目。

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

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

今天是第四期，聊一个做 AI 应用大家都特别关心，但容易走错方向的问题：

成本和提示词顺序的关系

提示词的组织顺序如果写对了，除了结果质量，连成本都能一起降下来。

前面三期，我们已经把标书智能体的主流程基本打通了：

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

做到这一步，其实系统已经可以用了。

但真用起来就会发现，标书这个场景和普通聊天不一样，最大的成本不一定在输出，而在输入。

一份招标文件动辄几万字，项目概述和评分要求也不短。正文生成时，同一份项目概述、同一套章节层级信息，还会被反复传给模型。

而节约成本最好的办法，不是精简提示词，而是调整提示词的顺序！

如果提示词结构写得不对，服务商的缓存能力就很难吃到，钱就白白花出去了。

一、为什么吃不到缓存

很多大模型服务商都支持 Prompt Cache，或者有类似的缓存机制。

但缓存不是你以为的那种“只要内容一样就行”。

大多数情况下，它看的是请求前缀。

也就是说，前面那一大段内容是不是稳定，是不是一致，是不是每次都放在同样的位置。

如果你把一份很长的正文，放在提示词后面，而前面先拼了很多每次都不一样的说明，那这份长文本虽然看起来是一样的，服务商也未必把它识别成同一个可复用前缀。

拿文档解析这个功能举例。

我们对同一份招标文件，会做两次分析：

1. 提取项目概述
2. 提取技术评分要求

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

def build_analysis_messages(file_content: str, analysis_type: str) -> List[Dict[str, str]]:
    if analysis_type == 'overview':
        system_prompt = '提取项目概述的 system prompt'
        analysis_type_cn = '项目概述'
    else:
        system_prompt = '提取技术评分要求的 system prompt'
        analysis_type_cn = '技术评分要求'

    user_prompt = (
        f'请分析以下招标文件内容，提取{analysis_type_cn}信息：\n\n{file_content}'
    )

    return [
        {'role': 'system', 'content': system_prompt},
        {'role': 'user', 'content': user_prompt},
    ]

问题出在哪？

不是 file_content 不一样，恰恰相反，file_content 是一样的。

问题在于：

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

这样一来，服务商看到的不是“同一个长前缀”，而是“两个不一样的请求，后面有一大段内容刚好相同”。

那缓存命中率自然就高不起来。

二、解决方案

这个问题想通以后，改法其实很简单。

原则就一句话：

把大且稳定的上下文放前面，把这次请求的任务差异放最后。

改造后的文档解析提示词变成了这样：

def build_analysis_messages(file_content: str, analysis_type: str) -> List[Dict[str, str]]:
    system_prompt = """你是一名专业的招标文件分析助手。请严格基于用户提供的招标文件原文完成分析任务。

通用要求：
1. 保持提取信息的全面性和准确性，尽量使用原文内容，不要自行编造
2. 只输出最终分析结果，不要输出额外说明、过程、提示语或客套话
3. 如果文档内容不足以支持某项结论，应明确说明原文未提及，不要凭空补充
"""

    file_prompt = f"""以下是完整招标文件全文，请先完整阅读，并仅基于原文完成后续任务：

{file_content}"""

    if analysis_type == 'overview':
        task_prompt = '任务：提取并总结项目概述信息。...'
    else:
        task_prompt = '任务：提取技术评分要求。...'

    return [
        {'role': 'system', 'content': system_prompt},
        {'role': 'user', 'content': file_prompt},
        {'role': 'user', 'content': task_prompt},
    ]

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

1. 第一条 system 一样
2. 第二条全文 user 一样
3. 只有最后一条任务说明不一样

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

三、提纲编写部分优化

第二期讲提纲生成的时候，重点主要放在 JSON 格式和目录质量上。

但从成本角度看，提纲生成也有一样的问题。

同一个项目里，用户经常会多点几次“重新生成目录”。

那同一份 overview 和 requirements 就会被反复发给模型。

旧写法通常是把它们拼成一个大 user_prompt：

user_prompt = f"""请基于以下项目信息生成标书目录结构：

项目概述：
{overview}

技术评分要求：
{requirements}

请生成完整的技术标目录结构，确保覆盖所有技术评分要点。"""

这当然没错，但对于缓存来说，不够细。

我们现在改成了多消息结构：

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

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

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

这么写的好处很直接：

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

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

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

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

这个思路本身没有问题。

但从缓存的角度再回头看，会发现正文生成这一段才是真正的大头。

因为正文生成是整个系统里调用次数最多的功能。

一个项目几十个叶子章节很正常。每个章节都要发一次请求，那下面这些内容就会被反复传很多遍：

1. 同一份 project_overview
2. 相同的 parent_chapters
3. 高度重叠的 sibling_chapters
4. 一模一样的正文写作规则

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

user_prompt = f"""请为以下标书章节生成具体内容：

{context_info}

当前章节信息：
章节ID: {chapter_id}
章节标题: {chapter_title}
章节描述: {chapter_description}

请根据项目概述信息和上述章节层级关系，生成详细的专业内容..."""

现在改成了分层消息：

def build_chapter_content_messages(
    chapter: Dict[str, Any],
    parent_chapters: List[Dict[str, Any]] | None = None,
    sibling_chapters: List[Dict[str, Any]] | None = None,
    project_overview: str = '',
) -> List[Dict[str, str]]:
    messages = [
        {'role': 'system', 'content': system_prompt},
    ]

    if project_overview.strip():
        messages.append(
            {'role': 'user', 'content': f'项目概述信息：\n{project_overview}'}
        )

    if parent_chapters:
        messages.append({'role': 'user', 'content': parent_context})

    if sibling_chapters:
        messages.append({'role': 'user', 'content': sibling_context})

    messages.append(
        {
            'role': 'user',
            'content': f'''请为以下标书章节生成具体内容：

当前章节信息：
章节ID: {chapter_id}
章节标题: {chapter_title}
章节描述: {chapter_description}

请根据项目概述信息和上述章节层级关系，生成详细的专业内容...''',
        }
    )

    return messages

这一步的价值特别大。

因为同一个父章节下面的多个叶子节点，往往都有下面这些共同点：

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

也就是说，正文生成这一块，不仅请求多，而且重复上下文还特别长。

这也是为什么正文生成最值得做缓存优化。

五、总结

这次改完以后，我觉得最重要的不是某一段具体提示词，而是下面这套规则。

以后只要是高频 AI 任务，都可以优先按这个思路来组织提示词：

1. system 只放稳定规则

不要把这次请求特有的差异塞进 system。

system 更适合放：

1. 通用角色
2. 通用写作规范
3. 通用输出要求

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

比如：

1. 招标文件全文
2. 项目概述
3. 技术评分要求
4. 目录树
5. 上级章节链

这些内容越稳定、越长、越可能重复利用，就越应该尽量往前放。

3. 任务差异尽量放最后

比如：

1. 提取项目概述
2. 提取技术评分要求
3. 生成目录
4. 生成 3.2.1 章节正文

这些都是每次请求最容易变化的内容，应该尽量放到最后。

4. 同一份数据的组织格式要保持稳定

缓存看的是前缀，不只是“意思差不多”。

所以这些细节都要保持一致：

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

这些看起来都是小事，但对缓存命中影响非常直接。

六、实测结果

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

测试环境如下：

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

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

request_id: c405ec7f755549629e8a47c04d5b2633
prompt_tokens：19349
cached_tokens: 0
upstream_inference_prompt_cost: 0.0058047

第一次请求相当于把缓存写进去，所以 cached_tokens 为 0，输入提示词费用按正常价格计算。

第二次请求日志里的关键字段变成了：

request_id: b4cfd26bdef74b9c941263a96b692cea
prompt_tokens：19737
cached_tokens: 19442
upstream_inference_prompt_cost: 0.00067176

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

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

也就是说，同样是一份很长的招标文件上下文，第二次请求的输入成本已经降到了第一次的大约九分之一，基本就是接近 10 倍的差距。

这一点特别重要。因为它说明了，缓存优化不是玄学，也不是“可能会省一点”。

只要下面几个条件满足：

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

那它省下来的钱，是可以直接从日志里看到的。

完整代码已开源

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

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

文章来源:https://www.cnblogs.com/yibiaoai/p/19817535
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！