标书从上传解析到正文生成的业务流程说明¶

本文面向运营同学，说明用户从上传招标文件到生成正文，后台大致会经过哪些流程。

文中提到的 Worker，可以简单理解为“后台处理员”：负责排队处理耗时任务，并把结果写回系统。

第一部分：业务流程图¶

这条业务链路可以拆成 6 个主要服务：

除 OSS 直传这种前置上传能力外，后面几个耗时服务的处理方式大体类似：页面发起动作后，系统先创建任务，把任务放进后台队列；Worker 领取任务后处理业务；处理过程中通过 Redis 通知页面刷新进度；最终结果写回数据库。

代表性后台任务流程¶

下面用“正文生成服务”举一个代表性的后台任务流程：

flowchart TD
    A["页面发起正文生成"] --> B["创建生成任务"]
    B --> C["任务进入后台队列"]
    C --> D["正文 Worker 领取任务"]
    D --> E["组装章节材料"]
    E --> F["调用模型生成正文"]
    F --> G["保存正文和任务状态"]
    G --> H["Redis 发布进度通知"]
    H --> I["页面订阅并刷新进度"]
    G --> J{"任务是否完成"}
    J -->|"未完成"| C
    J -->|"完成"| K["页面展示最终结果"]

标书生成总览流程¶

下面是用户从上传招标文件到生成正文的完整业务流程：

flowchart TD
    A["选择招标文件"]

    subgraph UPLOAD["OSS 直传提高性能"]
        direction TD
        B["向后端申请OSS上传凭证"] --> C["浏览器文件直传到阿里云 OSS"]
    end

    A --> B

    C --> D["后端确认上传并发起解析"]
    D --> E["系统确认文件存在、大小和格式"]

    subgraph CONFIRM["文件提取服务"]
        direction TD
        F["确认之后抽取标书全文并解析转化"]
        F --> G["保存可复用的标书原文 Markdown"]
    end

    E --> F
    G --> H["创建解析任务并绑定标书"]

    subgraph PARSE_WORKER["标书解析服务"]
        direction TD
        J["提取项目概览和项目要求"]
        J --> J2["提取评分标准"]
        J2 --> J1["整理并保存解析结果"]
    end

    H --> J
    J1 --> K1{"解析结果是否可用"}
    K1 -->|"可用"| L["进入目录编制"]
    K1 -->|"失败或缺失"| X["进入重新解析或人工修正"]

    subgraph OUTLINE_SERVICE["一二级目录生成服务"]
        direction TD
        M1["读取评分标准和页数要求"]
        M1 --> M2["组合目录提示词"]
        M2 --> M3["生成一二级目录"]
        M3 --> M4["保存一二级目录"]
    end

    L --> M1
    M4 --> N["一二级目录确认与调整"]

    subgraph SUB_OUTLINE_SERVICE["子目录和编写思路解析服务"]
        direction TD
        O["按二级目录生成三级/四级目录"]
        Q["为目录节点生成编写思路"]
        O --> P["保存完整目录树"]
        Q --> R["编写思路确认与编辑"]
        P --> READY["目录和编写思路准备完成"]
        R --> READY
    end

    N --> O
    N --> Q
    READY --> WRITE_MODE{"正文编写方式"}

    subgraph CONTENT_SERVICE["正文生成服务"]
        direction TD
        S["创建全文正文生成任务"]
        S --> T["按章节排队写作"]
        T --> U_FULL["组装当前章节材料"]
        U_FULL --> V_FULL["生成当前章节正文"]
        V_FULL --> W_FULL["保存正文并刷新全文进度"]
        W_FULL --> Y{"是否全部章节完成"}

        S1["选择单个章节生成"]
        S1 --> U_SINGLE["组装该章节材料"]
        U_SINGLE --> V_SINGLE["生成该章节正文"]
        V_SINGLE --> W_SINGLE["保存单章节正文"]
        W_SINGLE --> Z1["单章节正文生成完成"]
    end

    WRITE_MODE -->|"一键全文编写"| S
    WRITE_MODE -->|"单章节编写"| S1
    Y -->|"全文未完成"| T
    Y -->|"全文已完成"| Z["标书正文生成完成"]

    style UPLOAD fill:#ffffff,stroke:#ff2a00,stroke-width:3px,color:#d40000
    style CONFIRM fill:#ffffff,stroke:#ff2a00,stroke-width:3px,color:#d40000
    style PARSE_WORKER fill:#ffffff,stroke:#ff2a00,stroke-width:3px,color:#d40000
    style OUTLINE_SERVICE fill:#ffffff,stroke:#ff2a00,stroke-width:3px,color:#d40000
    style SUB_OUTLINE_SERVICE fill:#ffffff,stroke:#ff2a00,stroke-width:3px,color:#d40000
    style CONTENT_SERVICE fill:#ffffff,stroke:#ff2a00,stroke-width:3px,color:#d40000

第二部分：核心点介绍¶

1. 上传、确认文件并抽取全文¶

1. 技术点¶

这一阶段主要做文件上传确认和全文抽取，不调用大模型。系统会根据文件类型选择对应的文档解析方式，把原始招标文件整理成 Markdown 全文。

2. 关键描述¶

用户选择招标文件后，系统不是直接把文件传到业务服务器里长期保存，而是先给前端一个临时上传凭证。浏览器拿到凭证后，会把文件直传到阿里云 OSS。OSS 可以理解为文件仓库，用来保存原始招标文件。

文件传到 OSS 后，前端会自动调用确认解析接口。这个确认动作很关键：系统会去 OSS 核对文件是否真的存在、文件大小是否有效、格式是否支持。确认通过后，系统会把 OSS 中的文件下载回来，先抽取成一份可读的全文正文，一般以 Markdown 形式保存。

3. 设计优点¶

这一步的业务价值是：后续提取项目概览、评分标准、目录生成、正文写作，都可以复用同一份“标书原文”，不需要每一步都重新读原文件。

4. 流程动作¶

这一阶段的主要结果：

2. 标书解析服务¶

1. 技术点¶

标书解析主要使用 qwen3.6-flash。这一阶段不是继续处理文件格式，而是基于已经抽取好的标书全文，提取后续目录和正文会用到的关键信息。

2. 关键描述¶

全文正文保存后，系统会进入标书解析服务。这个服务会把标书原文交给模型识别，先整理项目概览和项目要求，再继续提取评分标准。

项目概览主要回答“这是一个什么项目”，项目要求主要回答“招标文件要求我们做什么”，评分标准主要回答“评审时怎么打分”。这三类结果会成为后续目录生成、编写思路和正文写作的基础材料。

3. 设计优点¶

把解析结果提前整理出来，后面的目录和正文就不用每次都从整份标书里重新找信息。运营和编写人员也能先看到项目基本情况、要求和评分点，方便判断后续生成内容是否贴合招标文件。

4. 流程动作¶

这一阶段主要会用到：

流程动作如下：

3. 一二级目录生成服务¶

1. 技术点¶

一二级目录主要使用 qwen3.6-flash。这个模型响应更快，适合先生成“章 / 节”这种目录骨架。

2. 关键描述¶

解析结果可用后，系统会先生成一二级目录。这里不是简单拿“项目名称”去生成目录，而是把已经解析出来的评分标准和页数要求组合起来，让目录尽量围绕得分点展开。

一二级目录可以理解为整本标书的“大框架”：先确定有哪些章、每章下面有哪些节，后续三级/四级目录和正文都会在这个框架下继续展开。

3. 设计优点¶

先生成一二级目录，可以让用户先看到整本标书的大方向，及时调整章节结构。这样后面生成细目录和正文时，就不容易跑偏，也能减少返工。

4. 流程动作¶

这一阶段主要会用到：

流程动作如下：

4. 子目录和编写思路解析服务¶

1. 技术点¶

子目录生成主要使用 qwen3.6-plus，编写思路生成也使用写作模型 qwen3.6-plus。这一步比一二级目录更细，需要结合更多项目材料，所以使用能力更强的模型。

2. 关键描述¶

一二级目录确定后，系统会继续往下补两类内容：一类是三级/四级目录，另一类是每个目录节点的编写思路。

这两件事在流程上是并行准备的：子目录负责把章节继续拆细，编写思路负责告诉后续正文“这一节应该怎么写”。两边都完成后，目录和写作方向就准备好了。

3. 设计优点¶

子目录和编写思路并行生成，可以缩短等待时间。按二级目录逐步细化，也方便后续调整单个章节，不需要反复重做整本目录。

4. 流程动作¶

这一阶段主要会用到：

流程动作如下：

5. 正文生成服务¶

1. 技术点¶

正文生成主要使用 qwen3.6-plus。正文比目录更长，也更需要结合上下文，所以会先整理章节材料，再交给模型写作。

2. 关键描述¶

目录和编写思路准备好后，正文可以从两个入口开始：一种是一键全文编写，系统按完整目录逐章生成；另一种是单章节编写，只针对当前选中的章节生成或重写。

这两种方式是独立入口：一键全文适合批量生成整本标书，单章节适合用户只想处理某一节。进入正文生成后，系统都会先准备这一节需要的材料，再生成正文并保存。

3. 设计优点¶

一键全文和单章节分开，可以同时满足“快速生成整本”和“精修某一节”两种使用场景。正文按章节生成，也方便失败重试、进度展示和后续人工修改。

4. 流程动作¶

正文生成有两种入口：

生成正文时，系统会先组装这一节需要的材料：

流程动作如下：