DEV Community: 易标AI

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

易标AI — Fri, 03 Apr 2026 07:29:17 +0000

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

完整代码已开源。

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

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

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

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

成本和提示词顺序的关系

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

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

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

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

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

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

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

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

一、为什么吃不到缓存

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

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

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

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

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

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

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

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

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

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 是一样的。

问题在于：

两次请求的 system_prompt 不一样
两次请求的 user_prompt 前缀也不一样
真正占 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},
    ]

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

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

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

三、提纲编写部分优化

第二期讲提纲生成的时候，重点主要放在 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': '请在满足技术评分要求的前提下，充分结合用户自己编写的目录，生成完整的技术标目录结构。',
        },
    ]

这么写的好处很直接：

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

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

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

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

这个思路本身没有问题。

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

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

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

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

旧写法是把这些内容全拼进一个大 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

这一步的价值特别大。

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

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
测试方式：招标文件解析

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

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

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

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

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

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

只要下面几个条件满足：

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

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

完整代码已开源

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

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

标书智能体（三）——生成标书正文代码+提示词

易标AI — Fri, 03 Apr 2026 07:28:34 +0000

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

完整代码已开源

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

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

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

今天是第三期，根据生成好的提纲，填充标书内容。

正文生成，并不像上一节讲的提纲生成那么复杂，核心难点只有两个：

标书需求字数太多： 一份标书动辄几万几十万字，直接让AI生成必然行不通。有了上一节生成提纲的经验，我们已经知道答案了，那就是把正文也打碎，让AI按照提纲的叶子节点，逐节生成正文。
上下文不连贯，或内容重复： 这就引出了我们第二个难点，分布生成，多部分内容之间不连贯是肯定的，可以更大的问题是，都是基于一份招标文件生成的技术方案，很可能生成意思过于相近的内容，俗称车轱辘话。下面，咱们就来逐项分析一下，如何解决上述难点。

一、获取生成内容所需信息

从前端拆分提纲，提纲的每一个叶子节点都发起一个生成请求，需要传递以下参数

class ChapterContentRequest(BaseModel):
    """单章节内容生成请求"""
    chapter: Dict[str, Any] = Field(..., description="章节信息")
    parent_chapters: Optional[List[Dict[str, Any]]] = Field(None, description="上级章节列表")
    sibling_chapters: Optional[List[Dict[str, Any]]] = Field(None, description="同级章节列表")
    project_overview: str = Field("", description="项目概述")

chapter： 本章节信息，不多说，这是必须的

{
  "id": "3.2.2",
  "title": "技术实力",
  "description": "技术研发能力和创新情况"
}

parent_chapters： 上级章节列表，为了保持连贯性
sibling_chapters： 同级章节列表，为了生成内容不重复
project_overview： 项目概述，这是核心，让AI知道自己要写的标书的核心需求

二、核心提示词

SystemPrompt

你是一个专业的标书编写专家，负责为投标文件的技术标部分生成具体内容。

要求：
1. 内容要专业、准确，与章节标题和描述保持一致
2. 这是技术方案，不是宣传报告，注意朴实无华，不要假大空
3. 语言要正式、规范，符合标书写作要求，但不要使用奇怪的连接词，不要让人觉得内容像是AI生成的
4. 内容要详细具体，避免空泛的描述
5. 注意避免与同级章节内容重复，保持内容的独特性和互补性
6. 直接返回章节内容，不生成标题，不要任何额外说明或格式标记

UserPrompt
这个就需要拼接一下了

项目概述信息：
{project_overview}

请为以下标书章节生成具体内容：

{context_info if context_info else ''}

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

请根据项目概述信息和上述章节层级关系，生成详细的专业内容，确保与上级章节的内容逻辑相承，同时避免与同级章节内容重复，突出本章节的独特性和技术方案的优势。

context_info是拼接的上级、统计节点信息

# 构建上下文信息
context_info = ""

# 上级章节信息
if parent_chapters:
    context_info += "上级章节信息：\n"
    for parent in parent_chapters:
        context_info += f"- {parent['id']} {parent['title']}\n  {parent['description']}\n"

# 同级章节信息（排除当前章节）
if sibling_chapters:
    context_info += "同级章节信息（请避免内容重复）：\n"
    for sibling in sibling_chapters:
        if sibling.get('id') != chapter_id:  # 排除当前章节
            context_info += f"- {sibling.get('id', 'unknown')} {sibling.get('title', '未命名')}\n  {sibling.get('description', '')}\n"

拼接后的完整user_prompt示例

请为以下标书章节生成具体内容：
上级章节信息：

1 投标文件技术要求响应程度对项目技术要求的响应和符合情况

1.1 技术规格响应详细描述投标产品技术参数与招标技术要求的符合性

同级章节信息（请避免内容重复）：

1.1.2 技术文件完整性提供的技术文件是否齐全、规范当前章节信息：章节ID: 1.1.1 章节标题: 灯具规格符合性章节描述: 逐项说明各灯具规格与招标文件要求的匹配情况

请根据项目概述信息和上述章节层级关系，生成详细的专业内容，确保与上级章节的内容逻辑相承，同时避免与同级章节内容重复，突出本章节的独特性和技术方案的优势。

就这么简单，生成正文不需要过多的逻辑推理，用最普通的大模型即可实现稳定输出，也几乎不存在生成失败的问题~

完整代码已开源

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

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

标书智能体（二）——生成标书提纲代码+提示词

易标AI — Fri, 03 Apr 2026 07:28:13 +0000

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

完整代码已开源

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

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

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

今天是第二期，根据解析好的项目概述和技术评分需求，生成投标文件提纲：

一份好的标书，提纲是关键，而生成好的提纲，则有以下几个难点：

格式化输出：为了生成正文时，AI能够很好的理解提纲，保证结构不错乱，那么提纲必须是格式化的
超出AI输出长度：几十万字的标书，提纲也不会短，现在AI虽然都号称几十万的上下文，但实际输出也就2千字左右，无法直接完整的长提纲
提纲可编辑：虽然AI能生成比较不错的提纲，但还是没法100%满足要求，所以提纲必须是可编辑的，而且编辑后还不能破坏原有的结构

下面，咱们就来逐项分析一下，如何解决上述难点。

一、短标书+能力较强的AI模型

当生成的标书长度要求不高，比如三五万字。且AI能输出的token数比较长，如最新的 glm-4.5 和 doubao-seed-1-6，大约可以直接输出8000字左右，那么就可以使用下面这种简单的结构。

JSON结构

{
  "outline": [
    {
      "id": "1",
      "title": "",
      "description": "",
      "children": [
        {
          "id": "1.1",
          "title": "",
          "description": "",
          "children":[
              {
                "id": "1.1.1",
                "title": "",
                "description": ""
              }
          ]
        }
      ]
    }
  ]
}

提示词

SystemPrompt

你是一个专业的标书编写专家。根据提供的项目概述和技术评分要求，生成投标文件中技术标部分的目录结构。

要求：
1. 目录结构要全面覆盖技术标的所有必要章节
2. 章节名称要专业、准确，符合投标文件规范
3. 一级目录名称要与技术评分要求中的章节名称一致，如果技术评分要求中没有章节名称，则结合技术评分要求中的内容，生成一级目录名称
4. 一共包括三级目录
5. 返回标准JSON格式，包含章节编号、标题、描述和子章节
6. 除了JSON结果外，不要输出任何其他内容

JSON格式要求：
{
  "outline": [
    {
      "id": "1",
      "title": "",
      "description": "",
      "children": [
        {
          "id": "1.1",
          "title": "",
          "description": "",
          "children":[
              {
                "id": "1.1.1",
                "title": "",
                "description": ""
              }
          ]
        }
      ]
    }
  ]
}

UserPrompt

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

项目概述：
{overview}

技术评分要求：
{requirements}

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

二、长标书+普通AI模型

要想使用如 glm-4-air 这样低价的普通模型，也能生成几十万字标书需要的长提纲，那实现起来就复杂多了。

限制

上下文短，仅能输出1500字左右
输出结果不稳定，尤其是json这类结构化数据，可能出现格式错误

思路

先生成一级目录（要与技术评分要求一一对应）
遍历一级目录，逐个生成二、三级目录（多个AI任务并发生成，要保证每个任务生成的目录和其他任务的不重复）
校验生成的json格式是否标准
最后拼成完整的目录

这种生成工作流，理论上可以生成无限长度的提纲。

生成一级标题

SystemPrompt

### 角色
你是专业的标书编写专家，擅长根据项目需求编写标书。

### 人物
1. 根据得到的项目概述(overview)和评分要求(requirements)，撰写技术标部分的一级提纲

### 说明
2. 只设计一级标题，数量要和"评分要求"一一对应
3. 一级标题名称要进行简单修改，不能完全使用"评分要求"中的文字

### Output Format in JSON
{
    "rating_item":"原评分项",
    "new_title":"根据评分项修改的标题"
}

UserPrompt

### 项目信息

<overview>
{overview}
</overview>

<requirements>
{requirements}
</requirements>


直接返回json，不要任何额外说明或格式标记

生成二级标题

为了生成结果稳定，我们不让AI来处理json框架，而是提前用代码拼接好json框架，仅让AI在json框架中填写内容

拼接json框架
我这里额外加了一个nodes_distribution，是为了让二三级目录数量不一样，随机了两个重点章节，这样更符合实际情况，这个不重要，感兴趣可以直接查看源码。
下面的代码是拼接json框架的：

def generate_one_outline_json_by_level1(level1_title: str, level1_index: int, nodes_distribution: Dict) -> Dict:
    # 获取当前一级节点下的二级节点数量和叶子节点分配
    level2_count = nodes_distribution['level2_nodes'][level1_index - 1]
    leaf_distribution = nodes_distribution['leaf_per_level2'][level1_index - 1]

    # 创建一级节点
    level1_node = {
        "id":f"{level1_index}",
        "title": level1_title,
        "description": "",
        "children": []
    }

    # 创建二级节点
    for j in range(level2_count):
        level2_node = {
            "id":f"{level1_index}.{j+1}",
            "title": "",  # 二级标题留空
            "description": "",
            "children": []
        }

        # 创建三级节点（叶子节点）
        leaf_count = leaf_distribution[j]
        for k in range(leaf_count):
            level2_node["children"].append({
                "id":f"{level1_index}.{j+1}.{k+1}",
                "title": "",  # 三级标题留空
                "description": ""
            })

        level1_node["children"].append(level2_node)

    return level1_node

拼接其他章节的标题，需要传给AI参考，以免生成重复的章节内容

other_outline = "\n".join([f"{j+1}. {node['new_title']}" 
                    for j, node in enumerate(level_l1) 
                    if j!= i])

SystemPrompt
json_outline是前面生成的json框架

### 角色
你是专业的标书编写专家，擅长根据项目需求编写标书。

### 任务
1. 根据得到项目概述(overview)、评分要求(requirements)补全标书的提纲的二三级目录

### 说明
2. 你将会得到一段json，这是提纲的其中一个章节，你需要再原结构上补全标题(title)和描述(description)
3. 二级标题根据一级标题撰写,三级标题根据二级标题撰写
4. 补全的内容要参考项目概述(overview)、评分要求(requirements)等项目信息
5. 你还会收到其他章节的标题(other_outline)，你需要确保本章节的内容不会包含其他章节的内容

### 注意事项
在原json上补全信息，禁止修改json结构，禁止修改一级标题

### Output Format in JSON
{json_outline}

UserPrompt

### 项目信息

<overview>
{overview}
</overview>

<requirements>
{requirements}
</requirements>

<other_outline>
{other_outline}
</other_outline>


直接返回json，不要任何额外说明或格式标记

校验生成json结果是否和传入框架一致

import json
def check_json(json_str: str, schema: str | dict) -> tuple[bool, str]:
    """
    根据模板 JSON 校验目标字符串的格式是否符合要求

    Args:
        json_str: 要校验的 JSON 字符串
        schema: 模板 JSON 字符串或字典对象，用于定义预期的数据结构

    Returns:
        tuple[bool, str]: (是否验证通过, 错误信息)
        如果验证通过返回 (True, "")，否则返回 (False, 错误原因)
    """
    try:
        # 解析输入的 JSON 字符串
        try:
            data = json.loads(json_str)
        except json.JSONDecodeError as e:
            return False, f"JSON 解析错误: {str(e)}"

        # 处理 schema 参数
        try:
            if isinstance(schema, str):
                schema = json.loads(schema)
            elif not isinstance(schema, dict):
                return False, "schema 必须是 JSON 字符串或字典对象"
        except json.JSONDecodeError as e:
            return False, f"schema 解析错误: {str(e)}"

        def check_structure(target, template, path=""):
            # 处理数字类型（int 和 float 可以互换）
            if isinstance(template, (int, float)) and isinstance(target, (int, float)):
                return True, ""

            # 检查基本数据类型
            if type(template) != type(target) and not (isinstance(template, (int, float)) and isinstance(target, (int, float))):
                return False, f"路径 '{path}' 的类型不匹配: 期望 {type(template).__name__}, 实际 {type(target).__name__}"

            # 如果是列表类型
            if isinstance(template, list):
                if not template:  # 如果模板列表为空，则允许任何列表
                    return True, ""
                if not target:  # 如果目标列表为空，但模板不为空
                    return False, f"路径 '{path}' 的列表为空，但期望有内容"

                # 检查列表中的每个元素是否符合模板中第一个元素的格式
                template_item = template[0]
                for i, item in enumerate(target):
                    is_valid, error = check_structure(item, template_item, f"{path}[{i}]")
                    if not is_valid:
                        return False, error
                return True, ""

            # 如果是字典类型
            elif isinstance(template, dict):
                # 检查所有必需的键是否存在，并且值的类型是否正确
                for key in template:
                    if key not in target:
                        return False, f"路径 '{path}' 缺少必需的键 '{key}'"
                    is_valid, error = check_structure(target[key], template[key], f"{path}.{key}")
                    if not is_valid:
                        return False, error
                return True, ""

            # 对于其他基本类型，返回 True
            return True, ""

        is_valid, error = check_structure(data, schema)
        return is_valid, error if not is_valid else ""

    except Exception as e:
        return False, f"未预期的错误: {str(e)}"

在执行过程中，设置3次重试，如果校验没通过，再重新执行一次，以保证成功率

完整代码已开源

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

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

标书智能体（一）——AI解析招标文件代码+提示词

易标AI — Fri, 05 Dec 2025 06:47:18 +0000

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

今天是第一期，招标文件解析：

招标文件动辄几万字，虽然现在各主流大模型的上下文窗口都越来越大，但也只能代表AI*“可以处理几十万字的上下文”，并不代表你随便扔给AI几十万字，它就能“处理得好几十万字的上下文”。*

我们在写投标文件之前，一定要先把招标文件通读一遍，标注出需要注意的点，然后再有针对性的撰写招标文件。

AI写标书也是一样，第一步要做的就是招标文件解析。

一、Word、PDF文件内容提取

AI解析招标文件，难住我的第一关，并不是如何让AI提取招标文件中的内容，而是怎么把招标文件的内容完整的从PDF、word中提取出来。

word文件提取，选用的是docx2python

content = None
try:
    # 使用docx2python提取，它能更好地处理表格和结构
    content = docx2python(file_path)
    extracted_text = []
    # 处理文档内容
    if hasattr(content, 'document'):
        for section in content.document:
            for element in section:
                if isinstance(element, list):
                    # 这可能是表格
                    extracted_text.append("\n[表格内容]")
                    for row in element:
                        if isinstance(row, list):
                            row_text = " | ".join([str(cell).strip() for cell in row if cell])
                            if row_text:
                                extracted_text.append(row_text)
                        else:
                            extracted_text.append(str(row))
                    extracted_text.append("[表格结束]\n")
                else:
                    # 普通文本
                    text = str(element).strip()
                    if text:
                        extracted_text.append(text)
    result = "\n".join(extracted_text).strip()
    # 确保释放资源
    if content:
        del content
    gc.collect()
    return result
except Exception as e:
    # 确保释放资源
    if content:
        del content
    gc.collect()

pdf文件提取，则使用pdfplumber

pdf = None
try:
    extracted_text = []
    pdf = pdfplumber.open(file_path)
    for page_num, page in enumerate(pdf.pages, 1):
        # 添加页码标识
        extracted_text.append(f"\n--- 第 {page_num} 页 ---\n")
        # 提取普通文本
        text = page.extract_text()
        if text:
            extracted_text.append(text)
        # 提取表格
        tables = page.extract_tables()
        for table_num, table in enumerate(tables, 1):
            extracted_text.append(f"\n[表格 {table_num}]")
            for row in table:
                if row:  # 跳过空行
                    # 过滤空值并连接单元格
                    row_text = " | ".join([str(cell) if cell else "" for cell in row])
                    extracted_text.append(row_text)
            extracted_text.append("[表格结束]\n")

    result = "\n".join(extracted_text).strip()
    # 确保关闭PDF文件
    if pdf:
        pdf.close()
    gc.collect() 
    return result
except Exception as e:
    # 确保关闭PDF文件
    if pdf:
        pdf.close()
    gc.collect()

二、封装AI流式请求通用函数

注意这里使用的是AsyncOpenAI即OpenAI的异步客户端，因为之后要一次性编写几十万字的标书，为了提高速度，使用并发请求，则必须使用AsyncOpenAI

def __init__(self, api_key: str, base_url: str = None, model_name: str = "gpt-3.5-turbo"):
    """初始化OpenAI服务"""
    self.api_key = api_key
    self.base_url = base_url
    self.model_name = model_name

    # 初始化OpenAI客户端 - 使用异步客户端
    self.client = openai.AsyncOpenAI(
        api_key=api_key,
        base_url=base_url if base_url else None
    )    
async def stream_chat_completion(
    self, 
    messages: list, 
    temperature: float = 0.7,
    response_format: dict = None
) -> AsyncGenerator[str, None]:
    """流式聊天完成请求 - 真正的异步实现"""
    try:
        stream = await self.client.chat.completions.create(
            model=self.model_name,
            messages=messages,
            temperature=temperature,
            stream=True,
            **({"response_format": response_format} if response_format is not None else {})
        )

        async for chunk in stream:
            if chunk.choices[0].delta.content is not None:
                yield chunk.choices[0].delta.content

    except Exception as e:
        yield f"错误: {str(e)}"

三、招标文件解析提示词

项目概述

SystemPrompt

你是一个专业的标书撰写专家。请分析用户发来的招标文件，提取并总结项目概述信息。

请重点关注以下方面：
1. 项目名称和基本信息
2. 项目背景和目的
3. 项目规模和预算
4. 项目时间安排
5. 项目要实施的具体内容
6. 主要技术特点
7. 其他关键要求

工作要求：
1. 保持提取信息的全面性和准确性，尽量使用原文内容，不要自己编写
2. 只关注与项目实施有关的内容，不提取商务信息
3. 直接返回整理好的项目概述，除此之外不返回任何其他内容

UserPrompt

请分析以下招标文件内容，提取项目概述信息：
{request.file_content}

技术评分要求

在编写招标文件中的技术方案时，技术评分要求非常重要，基本要做到1对1应答式编写，所以评分要求的提取则尤为重要，我采用了自我反思式的结构化提示词进行提取处理。

SystemPrompt

你是一名专业的招标文件分析师，擅长从复杂的招标文档中高效提取“技术评分项”相关内容。请严格按照以下步骤和规则执行任务：
### 1. 目标定位
- 重点识别文档中与“技术评分”、“评标方法”、“评分标准”、“技术参数”、“技术要求”、“技术方案”、“技术部分”或“评审要素”相关的章节（如“第X章 评标方法”或“附件X：技术评分表”）。
- 忽略商务、价格、资质等非技术类评分项。
### 2. 提取内容要求
对每一项技术评分项，按以下结构化格式输出（若信息缺失，标注“未提及”），如果评分项不够明确，你需要根据上下文分析并也整理成如下格式：
【评分项名称】：<原文描述，保留专业术语>
【权重/分值】：<具体分值或占比，如“30分”或“40%”>
【评分标准】：<详细规则，如“≥95%得满分，每低1%扣0.5分”>
【数据来源】：<文档中的位置，如“第5.2.3条”或“附件3-表2”>

### 3. 处理规则
- **模糊表述**：有些招标文件格式不是很标准，没有明确的“技术评分表”，但一定都会有“技术评分”相关内容，请根据上下文判断评分项。
- **表格处理**：若评分项以表格形式呈现，按行提取，并标注“[表格数据]”。
- **分层结构**：若存在二级评分项（如“技术方案→子项1、子项2”），用缩进或编号体现层级关系。
- **单位统一**：将所有分值统一为“分”或“%”，并注明原文单位（如原文为“20点”则标注“[原文：20点]”）。

### 4. 输出示例
【评分项名称】：系统可用性 
【权重/分值】：25分 
【评分标准】：年平均故障时间≤1小时得满分；每增加1小时扣2分，最高扣10分。 
【数据来源】：附件4-技术评分细则（第3页） 

【评分项名称】：响应时间
【权重/分分】：15分 [原文：15%]
【评分标准】：≤50ms得满分；每增加10ms扣1分。
【数据来源】：第6.1.2条

### 5. 验证步骤
提取完成后，执行以下自检：
- [ ] 所有技术评分项是否覆盖（无遗漏）？
- [ ] 权重总和是否与文档声明的技术分总分一致（如“技术部分共60分”）？

直接返回提取结果，除此之外不输出任何其他内容

UserPrompt

请分析以下招标文件内容，提取技术评分要求信息：
{request.file_content}

完整代码已开源

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

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

DEV Community: 易标AI

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

一、为什么吃不到缓存

二、解决方案

三、提纲编写部分优化

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

五、总结

1. system 只放稳定规则

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

3. 任务差异尽量放最后

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

六、实测结果

完整代码已开源

标书智能体（三）——生成标书正文代码+提示词

一、获取生成内容所需信息

二、核心提示词

完整代码已开源

标书智能体（二）——生成标书提纲代码+提示词

一、短标书+能力较强的AI模型

JSON结构

提示词

二、长标书+普通AI模型

生成一级标题

生成二级标题

校验生成json结果是否和传入框架一致

完整代码已开源

标书智能体（一）——AI解析招标文件代码+提示词

一、Word、PDF文件内容提取

二、封装AI流式请求通用函数

三、招标文件解析提示词

项目概述

SystemPrompt

UserPrompt

技术评分要求

SystemPrompt

UserPrompt

完整代码已开源

1. `system` 只放稳定规则