微信扫一扫标书分析（Bid Analysis）
1. 技能概述
1.1 技能定位
标书分析技能是一个面向招投标业务场景的专业化智能分析工具，旨在通过对标书文档的结构化解析、关键信息提取、合规性校验及评分预测，辅助用户高效完成标书评估与决策。分析完成后同步生成结构化分析报告文件，存储至源文件所在目录，便于后续查阅与归档。
1.2 核心价值
- 提效降本：将传统人工逐页审阅标书的时间从数小时缩短至分钟级
- 降低风险：系统性检测标书响应缺失、格式偏离等合规风险点
- 决策支持：基于评分规则模型提供量化的得分预估与竞争力分析
- 报告输出：分析完成后自动生成结构化分析报告文件，与源文件同目录保存，便于归档与查阅
1.3 使用场景
| 场景 | 说明 | |------|------| | 投标前自查 | 投标方在提交标书前进行完整性自查与评分预判 | | 招标方评标 | 招标方对标书进行规范化评审与横向对比 | | 竞争分析 | 分析多家投标方的标书优劣，辅助定标决策 | | 文档归档 | 标书关键信息的结构化提取与存档管理，分析报告自动保存至源文件目录 |
1.4 触发条件
当用户出现以下任一情况时，本技能应被自动调用：
- 上传或打开
.pdf、.docx、.doc、.xlsx格式的标书文件 - 提出"分析标书"、"评估投标文件"、"检查标书合规性"等请求
- 询问"标书评分"、"投标条款"、"技术方案评估"等与招投标相关的内容
- 需要对比多份标书或提取标书中的关键信息
- 需要生成或导出标书分析报告
执行说明：本技能被触发后，除在对话中输出分析结果外，必须按第11章（报告输出执行指令）的要求，自动将分析报告保存为文件。
2. 功能模块划分
2.1 模块总览
┌─────────────────────────────────────────────────────┐
│ 标书分析系统 │
├─────────────────────────────────────────────────────┤
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 文档解析 │ │ 信息提取 │ │ 合规检查 │ │
│ │ 模块 │ │ 模块 │ │ 模块 │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ └──────────────┼──────────────┘ │
│ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 评分预测 │ │ 对比分析 │ │ 报告生成 │ │
│ │ 模块 │ │ 模块 │ │ 模块 │ │
│ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────┘
2.2 文档解析模块
功能描述：支持多格式标书文档的导入与结构化解析。
| 功能点 | 详细说明 | |--------|----------| | 格式识别 | 自动识别文件格式（PDF/DOCX/DOC/XLSX），调用对应解析引擎 | | 文本提取 | 提取文档正文文本，保留段落结构与层级关系 | | 表格解析 | 识别并提取文档中的表格数据，保持行列结构与合并单元格信息 | | 元数据提取 | 提取文档属性（标题、作者、创建日期、页数、修订版本等） | | 目录结构重建 | 基于文档大纲/目录标签重建完整的章节树结构 | | 附件识别 | 识别并标记标书中的附件材料及其引用位置 |
2.3 信息提取模块
功能描述：从解析后的文档中提取关键业务信息。
| 信息类型 | 提取内容 | |----------|----------| | 基本信息 | 项目名称、招标编号、招标人、投标人、投标金额、投标日期 | | 资质信息 | 企业资质等级、人员资质、业绩案例数量与类型 | | 技术方案 | 技术路线、技术指标参数、实施方案、质量保证措施 | | 商务条款 | 报价明细、付款方式、质保期、交付周期、违约责任 | | 评分因素 | 评分项名称、分值权重、评分标准描述 | | 时间节点 | 投标截止时间、开标时间、答疑时间、合同签订期限 | | 未识别条款 | 记录无法匹配任何已知类别的条款原文及所在位置，纳入"未识别条款说明"附注 |
识别失败处理规则：对于无法归入上述任何已知类别的条款内容，必须记录其原文片段和所在文档位置（段落号/页面/表格位置），不得静默跳过。这些记录将在报告生成阶段汇总至"附注 - 未识别条款说明"章节。
2.4 合规检查模块
功能描述：对标书进行格式合规性、响应完整性、资质有效性检查，以及条款可识别性和冲突检测。
| 检查维度 | 检查项 | 判定标准 | |----------|--------|----------| | 格式合规 | 页码编号、目录完整性、页眉页脚、签章位置 | 是否符合招标文件格式要求 | | 响应完整 | 逐项对照招标文件要求，检查是否有漏项 | 招标要求覆盖率 >= 95% | | 资质时效 | 营业执照有效期、资质证书有效期 | 是否在有效期内 | | 签字盖章 | 法人签字、公司公章、骑缝章 | 是否为有效签章 | | 密封要求 | 密封袋标识、密封方式（如适用） | 是否符合招标文件要求 | | 条款可识别性 | 检查条款内容是否可归入已知类别 | 无法匹配则标记为"未识别"，记录原文及位置 | | 条款冲突 | 跨章节同主题条款是否存在语义矛盾 | 对立语义相似度 >= 0.6 视为冲突，标记为高风险 |
2.5 评分预测模块
功能描述：基于招标评分规则，对投标文件进行量化评分预估。
| 评分维度 | 评估方法 | 输出结果 | |----------|----------|----------| | 价格评分 | 基于报价与基准价的关系计算得分 | 价格得分、价格排名 | | 技术评分 | 根据技术参数与评分标准逐项打分 | 技术总分、分项得分明细 | | 商务评分 | 根据商务条款响应程度评分 | 商务总分、偏离度分析 | | 综合评分 | 加权汇总各维度得分 | 综合得分、竞争力评级 |
2.6 对比分析模块
功能描述：支持多份标书的横向对比与差异化分析。
| 对比维度 | 对比方式 | 展示形式 | |----------|----------|----------| | 价格对比 | 算术对比、相对差异计算 | 柱状图、数据表 | | 技术对比 | 逐项参数对照、方案优劣标记 | 对比矩阵、雷达图 | | 资质对比 | 资质等级排序、业绩数量统计 | 排名表 | | 综合对比 | 加权得分对比、优劣项汇总 | 排序表、SWOT分析图 |
2.7 报告生成模块
功能描述：根据分析结果自动生成标准化评估报告，并自动保存为文件。
2.7.1 自动触发机制
分析流程完成（信息提取、合规检查、评分计算全部结束后）后，系统自动触发报告生成与文件保存，无需用户手动干预。
2.7.2 文件命名规则
| 输入源文件 | 生成的分析报告文件名 | 规则说明 |
|-----------|---------------------|----------|
| 公开招标文件1.docx | 公开招标文件1_标书分析报告.md | 取源文件主名 + _标书分析报告.md |
| 项目技术方案.pdf | 项目技术方案_标书分析报告.md | 取源文件主名 + _标书分析报告.md |
| 投标文件_某公司.docx | 投标文件_某公司_标书分析报告.md | 取源文件主名 + _标书分析报告.md |
命名规则公式：{源文件主名}_标书分析报告.md
其中源文件主名指去除扩展名后的文件名称部分。
2.7.3 文件存储位置
报告文件保存至与源招标文件相同的目录下。例如：
- 源文件路径：
c:\Users\xxx\Documents\投标项目\公开招标文件1.docx - 报告文件路径：
c:\Users\xxx\Documents\投标项目\公开招标文件1_标书分析报告.md
2.7.4 报告输出格式
| 属性 | 规范 | |------|------| | 文件格式 | Markdown（.md） | | 编码 | UTF-8（无BOM） | | 换行符 | LF（Unix风格），兼容各平台查看 | | 文件大小 | 原则上不超过1MB，超长内容适当精简 |
Markdown格式同时具备以下优势：
- 纯文本，体积小，打开速度快
- 支持表格、代码块、列表、标题层级等丰富排版
- 可被Git等版本控制系统追踪变更
- 可方便转换为PDF/HTML等其他格式
2.7.5 报告内容结构
自动生成的分析报告必须包含以下10个标准章节，按顺序编排：
| 章节序号 | 章节标题 | 内容说明 | |----------|----------|----------| | 一 | 基本信息摘要 | 项目名称、编号、采购人、代理机构、预算金额、合同期限、投标截止时间等关键信息卡片 | | 二 | 时间节点梳理 | 以表格形式列出所有关键时间节点（投标开始/截止、开标、投标有效期、合同签订期限等） | | 三 | 采购需求与技术规格 | 产品清单、技术指标参数、性能要求、遵循标准规范等 | | 四 | 评分标准深度解析 | 评分项名称、分值权重、评分规则说明，标注主观分/客观分，计算客观分可达上限 | | 五 | 商务条款与投标要求 | 付款条件、资格要求、实质性要求标记（★）、知识产权条款、验收标准等 | | 六 | 投标重点分析 | 按分值高低排序标注投标重点领域，给出策略建议 | | 七 | 技术难点分析 | 列出项目实施中可能遇到的技术难点及应对思路 | | 八 | 潜在风险提示 | 按风险等级（🔴高风险/🟡中风险/🟢低风险）分类列出所有风险项及应对建议 | | 九 | 需特别关注的条款 | 高亮标注无效投标情形、围标串标审查条款、特殊限制条件等 | | 十 | 综合竞争态势分析 | 评分权重一览、核心结论、投标准备建议清单（按优先级排序） | | 附注 | 未识别条款说明（按需） | 列出本次分析中无法识别或存疑的条款原文片段及所在位置，标注需人工复核的原因 |
2.7.6 报告类型对照
| 报告类型 | 适用对象 | 内容概要 | 自动生成 | |----------|----------|----------|----------| | 标书分析报告 | 投标方/评标委员会 | 完整分析过程、评分明细、合规检查结果 | ✅ 默认自动生成 | | 投标诊断报告 | 投标方 | 优势分析、改进建议、风险提示 | ⚠️ 用户要求时生成 | | 对比分析报告 | 决策层 | 多标书横向对比、推荐排序、决策建议 | ⚠️ 用户要求时生成 | | 摘要报告 | 管理层 | 关键信息摘要、核心结论、评分汇总 | ⚠️ 用户要求时生成 |
3. 核心算法设计
3.1 算法架构
输入文档 → 预处理 → 特征提取 → 模型推理 → 结果聚合 → 输出报告
3.2 文档预处理算法
| 算法 | 用途 | 技术实现 | |------|------|----------| | OCR 预处理 | 扫描件图片转文字 | 基于 CNN+Transformer 的端到端 OCR 模型 | | 版面分析 | 识别文档中的文本块/表格/图片区域 | LayoutLMv3 / DocTR 版面检测 | | 段落重组 | 将散落文本按阅读顺序重组为连贯段落 | 基于图模型的阅读顺序排序算法 | | 噪音过滤 | 去除页眉页脚、水印、无关标记等 | 基于规则 + 轻量分类器的过滤策略 | | 编码统一 | 统一文档编码为 UTF-8 | 字符编码检测 + 自动转换（chardet/charset-normalizer） |
3.3 关键信息抽取算法
| 抽取目标 | 算法类型 | 具体实现 | |----------|----------|----------| | 命名实体 | 序列标注 | BERT-BiLSTM-CRF 模型，标注 PER/ORG/DATE/MONEY 等实体 | | 关键段落 | 文本分类 | 基于 RoBERTa 的段落级分类器，区分"技术方案"/"商务条款"等 | | 表格数据 | 结构识别 | Table Transformer + 规则后处理，提取表格行列关系 | | 评分规则 | 规则推理 | 基于正则模板 + 语义匹配的混合规则引擎 | | 条款关系 | 关系抽取 | 基于依存句法分析的条款引用关系识别 |
3.4 合规性检查算法
| 检查类型 | 算法策略 | 阈值/标准 | |----------|----------|-----------| | 完整性检测 | 基于招标清单模板的语义相似度匹配 | 语义相似度 >= 0.75 视为已响应 | | 格式检测 | 基于文档结构模板的偏差度量 | 结构偏差率 <= 10% | | 资质有效期 | 日期提取 + 时效性计算 | 截止日期 > 当前日期 + 项目周期 | | 签字检测 | 基于目标检测的签章区域识别 | YOLOv8 签章检测模型，置信度 >= 0.85 | | 一致性检测 | 跨章节同一数据项的数值比对 | 数值偏差率 <= 1% | | 条款可识别性检测 | 基于模板匹配的未知条款识别，检测无法归入已知类别的文本片段 | 匹配失败即标记为"未识别" | | 条款冲突检测 | 跨章节同主题条款的语义矛盾识别 | 对立语义的相似度 >= 0.6 视为冲突 |
3.5 评分预测算法
score_prediction = Σ(weight_i × score_i)
其中:
- weight_i: 第 i 个评分项的权重系数
- score_i: 第 i 个评分项的模型预测得分
- 权重系数从招标文件的评分标准中解析得到
- 预测得分基于历史评分数据训练的回归模型
| 评分因子 | 预测模型 | 特征维度 | |----------|----------|----------| | 价格评分 | 线性回归 + 基准价浮动模型 | 报价金额、基准价、浮动比例 | | 技术评分 | XGBoost 回归模型 | 技术参数达标率、完整性、创新性评分 | | 商务评分 | 规则引擎 + 向量相似度 | 条款偏离度、优惠幅度、响应速度 | | 综合评分 | 加权融合 | 各分项得分及权重 |
3.6 文本相似度计算
# 伪代码示例：基于混合策略的文本相似度评估
def compute_similarity(text_a, text_b):
# 基础语义相似度 (基于 Sentence-BERT 编码)
sem_sim = cosine_similarity(encode(text_a), encode(text_b))
# 关键词覆盖度 (基于 TF-IDF 的关键词交集)
kw_a = extract_keywords(text_a)
kw_b = extract_keywords(text_b)
kw_overlap = len(kw_a & kw_b) / len(kw_a | kw_b)
# 结构相似度 (基于文档树结构匹配)
struct_sim = tree_edit_distance(doc_tree_a, doc_tree_b)
# 混合加权
final_sim = 0.5 * sem_sim + 0.3 * kw_overlap + 0.2 * struct_sim
return final_sim
4. 数据处理流程
4.1 数据流架构
输入层 处理层 输出层
┌───────┐ ┌──────────────────────────────────┐ ┌──────────┐
│ PDF │──▶│ 文档解析 → 文本清洗 → 结构重建 │──▶│ JSON │
├───────┤ ├──────────────────────────────────┤ ├──────────┤
│ DOCX │──▶│ 信息提取 → 实体识别 → 关系抽取 │──▶│ Excel │
├───────┤ ├──────────────────────────────────┤ ├──────────┤
│ XLSX │──▶│ 评分计算 → 合规检查 → 对比分析 │──▶│ 分析报告 │
└───────┘ │ 报告生成 → 格式渲染 → 文件保存 │ │ (.md) │
└──────────────────────────────────┘ │ │
│ 保存路径 │
│ 同源文件 │
│ 目录 │
└──────────┘
4.2 输入数据处理
| 数据来源 | 数据格式 | 处理方式 | |----------|----------|----------| | 标书文件 | PDF (含扫描件) | 直接解析 / OCR 引擎处理 | | 标书文件 | DOCX / DOC | python-docx / LibreOffice 转换 | | 报价明细 | XLSX / CSV | openpyxl / pandas 解析 | | 招标文件 | PDF | 作为参照模板，提取评分标准和条款清单 | | 用户补充 | 文本输入 | 直接作为上下文输入处理 |
4.3 数据清洗规则
| 清洗类型 | 规则说明 | 处理策略 |
|----------|----------|----------|
| 空白处理 | 去除多余空白字符与空行 | re.sub(r'\s+', ' ', text) |
| 编码修复 | 修复乱码字符与编码错误 | 基于 Unicode 规范化 + 常见乱码映射表 |
| 特殊字符 | 去除控制字符与不可打印字符 | Unicode 类别过滤 (Cc/Cf 类别) |
| 重复段落 | 检测并标记疑似重复的内容 | 基于局部敏感哈希 (LSH) 的近似去重 |
| OCR 纠错 | 修正 OCR 识别中的常见错误 | 基于业务词典 + 编辑距离的纠错 |
| 敏感信息 | 检测并脱敏个人信息（身份证号、电话等） | 正则匹配 + 掩码替换（保留后4位） |
4.4 结构化数据模型
{
"bid_document": {
"metadata": {
"title": "项目名称",
"bidder": "投标人",
"date": "2026-01-15",
"total_pages": 120,
"file_format": "pdf"
},
"structure": {
"chapters": [
{
"id": 1,
"title": "投标函",
"level": 1,
"page_start": 1,
"page_end": 3,
"content": "..."
}
],
"tables": [...],
"appendices": [...]
},
"extracted_info": {
"qualifications": [...],
"tech_solution": {...},
"pricing": {...},
"key_personnel": [...],
"past_performance": [...]
},
"compliance": {
"overall_status": "pass",
"issues": [...],
"coverage_rate": 0.97
},
"scoring": {
"price_score": 28.5,
"tech_score": 42.3,
"commercial_score": 18.2,
"total_score": 89.0,
"confidence": 0.87
}
}
}
4.5 输出数据格式
4.5.1 主要输出：Markdown分析报告文件
分析完成后，系统自动生成Markdown格式的分析报告文件，保存至源文件同一目录。
| 属性 | 规范 |
|------|------|
| 文件格式 | Markdown（.md） |
| 文件名 | {源文件主名}_标书分析报告.md |
| 保存路径 | 与源招标文件相同目录 |
| 触发方式 | 分析流程结束后自动触发 |
| 编码 | UTF-8（无BOM） |
4.5.2 辅助输出格式
| 输出格式 | 适用场景 | 生成方式 | |----------|----------|----------| | JSON | 程序接口对接、数据持久化 | 完整结构化数据序列化 | | Excel (.xlsx) | 评分明细导出、数据二次加工 | pandas DataFrame 输出，含自动格式与条件着色 | | Markdown | 在线预览、文档嵌入（主输出格式） | Jinja2 模板引擎渲染 | | PDF 报告 | 正式提交、打印存档 | WeasyPrint / ReportLab 渲染 | | HTML 看板 | 交互式浏览、图表展示 | ECharts 可视化 + 响应式布局 |
5. 用户交互界面规范
5.1 交互流程
用户上传标书 → 系统自动解析 → 展示解析进度 → 输出分析结果 → 自动保存报告文件 → 告知用户文件路径
5.2 对话式交互模式
| 交互类型 | 用户输入示例 | 系统响应 | |----------|-------------|----------| | 上传文件 | "请分析这份标书" | 接受文件 → 显示解析进度 → 返回结构化分析结果 → 自动保存分析报告文件并告知路径 | | 信息查询 | "报价是多少？" | 从提取信息中检索 → 精准返回报价详情 | | 合规检查 | "检查是否符合要求" | 逐项检查 → 返回合规报告与问题清单 | | 对比分析 | "对比这两份标书" | 启动对比引擎 → 返回对比矩阵与推荐建议 | | 评分预测 | "预估能得多少分" | 基于评分规则计算 → 返回得分预估与置信区间 | | 报告导出 | "生成分析报告" | 调用报告引擎 → 返回指定格式的报告文件链接，并告知文件保存路径 |
5.3 进度反馈标准
| 处理阶段 | 进度百分比 | 反馈文案 | |----------|-----------|----------| | 文件上传 | 0% - 10% | "正在接收文件..." | | 格式识别 | 10% - 15% | "识别文件格式：{format}" | | 文档解析 | 15% - 40% | "正在解析文档内容 ({page}/{total_pages} 页)..." | | 信息提取 | 40% - 65% | "提取关键信息中..." | | 合规检查 | 65% - 80% | "进行合规性检查..." | | 评分计算 | 80% - 90% | "计算评分结果..." | | 报告生成 | 90% - 95% | "生成分析报告..." | | 文件保存 | 95% - 100% | "保存分析报告至 {文件路径}..." |
5.4 结果展示规范
| 展示区域 | 展示内容 | 交互方式 | |----------|----------|----------| | 摘要面板 | 关键信息卡片：项目名/投标人/金额/总分 | 点击卡片跳转详情 | | 评分看板 | 雷达图 + 分项柱状图 + 总分 | 悬停显示数值，点击查看评分依据 | | 合规清单 | 通过/警告/失败标记 + 问题描述 | 点击问题项展开建议 | | 原文对照 | 提取的信息高亮显示在原文中 | 支持原文检索与定位 | | 对比视图 | 多列并列显示，差异行高亮标注 | 支持列排序与筛选 |
5.5 视觉设计规范
| 设计元素 | 规范要求 | |----------|----------| | 颜色主题 | 专业蓝色系 (#1a73e8 主色)，搭配绿色 (#34a853) 表示通过、黄色 (#fbbc04) 表示警告、红色 (#ea4335) 表示问题 | | 排版层次 | 一级标题 24px/加粗，二级标题 18px/加粗，正文 14px/常规，标注文字 12px/常规 | | 间距规范 | 模块间距 24px，卡片内边距 16px，元素间距 8px | | 响应式 | 适配桌面 (>= 1200px) 和平板 (>= 768px) 分辨率 | | 加载状态 | 骨架屏 (Skeleton) 过渡动画，避免白屏 |
6. 性能指标要求
6.1 处理性能指标
| 指标名称 | 目标值 | 度量方式 | |----------|--------|----------| | 文档解析时间 | ≤ 30 秒 (100 页以内文档) | 从上传完成到解析完成的耗时 | | 信息提取时间 | ≤ 15 秒 | 从解析完成到信息提取完成的耗时 | | 合规检查时间 | ≤ 10 秒 | 从提取完成到合规检查完成的耗时 | | 评分计算时间 | ≤ 5 秒 | 从检查完成到评分输出的耗时 | | 全流程耗时 | ≤ 60 秒 (100 页以内标准文档) | 端到端的总处理时间 | | 多文档对比 | ≤ 30 秒 (3 份以内同时对比) | 从触发对比到结果输出的耗时 | | 报告生成时间 | ≤ 10 秒 | 从触发生成到可下载的耗时 |
6.2 质量性能指标
| 指标名称 | 目标值 | 度量方式 | |----------|--------|----------| | 实体识别准确率 | ≥ 90% | 正确识别的实体数 / 总实体数 | | 关键信息召回率 | ≥ 85% | 正确提取的信息数 / 应提取信息总数 | | 表格识别准确率 | ≥ 85% | 正确还原的表格单元格数 / 总单元格数 | | 合规检查准确率 | ≥ 92% | 正确判定的检查项数 / 总检查项数 | | 评分预测误差率 | ≤ 5% | |预测分 - 实际分| / 实际分 | | OCR 识别准确率 | ≥ 95% (印刷体) / ≥ 80% (手写体) | 正确识别的字符数 / 总字符数 |
6.3 并发与容量指标
| 指标名称 | 目标值 | 说明 | |----------|--------|------| | 单次处理文档上限 | 300 页 / 50 MB | 超过此限制的文档需要分段处理或提示用户 | | 同时处理文档数 | ≥ 5 份 | 支持并行处理 | | 对比分析上限 | 10 份 | 同时参与对比分析的标书数量上限 | | 批量处理能力 | ≥ 20 份/小时 | 批量导入场景下的处理吞吐量 |
6.4 可用性指标
| 指标名称 | 目标值 | |----------|--------| | 服务可用率 | ≥ 99.5% | | 单次无故障运行时间 | ≥ 72 小时 | | 最大恢复时间 (MTTR) | ≤ 15 分钟 | | 最大故障间隔 (MTBF) | ≥ 168 小时 |
7. 兼容性说明
7.1 文件格式兼容性
| 文件格式 | 版本/规范 | 支持程度 | 注意事项 | |----------|-----------|----------|----------| | PDF 1.4 - 1.7 | ISO 32000-1 | 全文支持 | 扫描件需 OCR 处理 | | PDF 2.0 | ISO 32000-2 | 全文支持 | 部分高级特性可能丢失 | | PDF/A-1/2/3 | ISO 19005 | 全文支持 | 符合归档标准 | | DOCX | Office Open XML | 全文支持 | 支持嵌入式图片与表格 | | DOC | OLE2 复合文档 | 全文支持 | 需要 LibreOffice 或 python-docx 转换 | | XLSX | Office Open XML | 全文支持 | 支持多工作表与公式 | | XLS | OLE2 复合文档 | 全文支持 | 需要转换 | | 图片格式 (PNG/JPG/TIFF) | — | 仅 OCR 支持 | 每张图片视为一页 |
7.2 平台兼容性
| 平台 | 支持状态 | 说明 | |------|----------|------| | Windows 10/11 | ✅ 完全支持 | 主开发平台 | | macOS 12+ | ✅ 完全支持 | 同架构运行 | | Linux (Ubuntu 20.04+) | ✅ 完全支持 | Docker 容器化部署 | | Web 浏览器 | ✅ 支持 | 通过 REST API 接口调用 |
7.3 字符编码兼容性
| 编码类型 | 支持状态 | 说明 | |----------|----------|------| | UTF-8 | ✅ 完全支持 | 首选编码 | | GBK / GB2312 / GB18030 | ✅ 完全支持 | 中文标书常见编码 | | ISO-8859-1 | ✅ 支持 | 拉丁字符编码 | | Big5 | ⚠️ 部分支持 | 繁体中文编码 | | Shift-JIS | ⚠️ 部分支持 | 日文编码 |
7.4 依赖兼容性
| 依赖组件 | 最低版本 | 推荐版本 | |----------|----------|----------| | Python | 3.9+ | 3.11+ | | PyMuPDF (fitz) | 1.21.0 | 1.24.0+ | | python-docx | 0.8.11 | 1.1.0+ | | openpyxl | 3.0.10 | 3.1.0+ | | pandas | 1.5.0 | 2.1.0+ | | scikit-learn | 1.2.0 | 1.3.0+ | | transformers | 4.30.0 | 4.36.0+ | | sentence-transformers | 2.2.0 | 2.2.2+ |
8. 安全机制设计
8.1 数据安全
| 安全维度 | 措施说明 | 实施方式 | |----------|----------|----------| | 数据传输 | TLS 1.3 加密传输 | 全链路 HTTPS，证书双向验证 | | 数据存储 | AES-256 加密存储 | 文件加密存储，密钥由 KMS 管理 | | 临时文件 | 处理完成后自动清除 | 设置 TTL（默认 30 分钟），到期自动清理 | | 数据隔离 | 租户级数据隔离 | 每个用户/项目的文件独立存储，互不可见 | | 脱敏处理 | 敏感信息自动脱敏 | 身份证号、手机号、银行账号自动掩码处理 |
8.2 敏感信息脱敏规则
| 信息类型 | 脱敏策略 | 示例 | |----------|----------|------| | 身份证号 | 保留前6位后4位，中间掩码 | 110101****1234 | | 手机号码 | 保留前3位后4位，中间掩码 | 1385678 | | 银行账号 | 保留后4位 | **** **** **** 8888 | | 电子邮箱 | 保留域名，用户名掩码 | u*@company.com | | 企业统一社会信用代码 | 保留前2位后4位 | 91*****9X8 | | 项目预算金额 | ★ 不脱敏（招投标信息通常需公开透明） | — |
8.3 访问控制
| 控制层级 | 控制策略 | 实施方式 | |----------|----------|----------| | 用户认证 | OAuth 2.0 / JWT | 身份验证通过后颁发访问令牌 | | 角色权限 | RBAC (基于角色的访问控制) | 定义 admin/analyst/viewer 角色 | | 操作审计 | 全量操作日志 | 记录谁在何时做了什么操作 | | 频率限制 | 基于令牌桶的 API 限流 | 每分钟每用户 ≤ 30 次请求 | | 文件权限 | 文件级访问控制列表 (ACL) | 仅文件所有者与授权用户可访问 |
8.4 安全审计
| 审计项 | 记录内容 | 保存期限 | |--------|----------|----------| | 上传记录 | 上传时间、文件名、用户、文件大小 | 180 天 | | 下载记录 | 下载时间、文件名、用户、下载格式 | 180 天 | | 删除记录 | 删除时间、文件名、操作者 | 180 天 | | 异常操作 | 多次尝试失败、疑似爬虫、越权访问 | 365 天 | | 模型调用 | 调用时间、模型名称、输入输出大小 | 90 天 |
8.5 隐私合规
- 遵循《个人信息保护法》（PIPL）对个人信息处理的要求
- 标书分析结果仅保留必要时间，到期自动清除
- 用户可随时请求删除自己的分析记录
- 不将标书内容用于模型训练或任何非授权用途
- 如需使用用户数据进行模型优化，需事先获得明确授权
9. 维护与更新策略
9.1 维护周期
| 维护类型 | 频率 | 内容 | |----------|------|------| | 日常巡检 | 每日 | 服务可用性检查、错误率监控、资源使用率检查 | | 常规维护 | 每周 | 模型性能评估、规则库更新、日志轮转 | | 版本发布 | 每月/每季度 | 功能迭代、模型升级、架构优化 | | 紧急修复 | 按需 | 安全漏洞修复、关键 Bug 修复、服务降级处理 |
9.2 模型更新策略
| 模型类型 | 更新频率 | 更新触发条件 | 验证方式 | |----------|----------|--------------|----------| | 实体识别模型 | 每季度 | 准确率下降超过 2% 或新实体类型出现 | A/B 测试 + 回归测试 | | 文档分类模型 | 每季度 | 分类准确率低于 85% | 10 折交叉验证 | | 评分预测模型 | 每半年 | 预测误差率超过 8% | 历史回测 + 实际标注 | | OCR 模型 | 按需 | 新文档类型引入或识别率下降 | 标注数据集评估 |
9.3 规则库维护
| 规则类型 | 维护方式 | 责任人/机制 | |----------|----------|-------------| | 合规检查规则 | 业务专家定期审核更新 | 每季度由业务专家审核 | | 评分标准模板 | 根据行业标准动态更新 | 自动侦测招标文件中的评分标准变化 | | 实体抽取规则 | 基于新样本的增量学习 | 新增标注数据 → 模型微调 → 上线验证 | | 文档模板库 | 用户反馈 + 主动采集 | 支持用户提交新模板 = AI 辅助标注 |
9.4 文档模板更新机制
# 伪代码示例：文档模板自动更新流程
def update_template_library(new_bid_document):
# 1. 对新文档进行结构解析
structure = parse_document_structure(new_bid_document)
# 2. 与现有模板库进行匹配
best_match = find_best_template(structure)
similarity = compute_structure_similarity(structure, best_match)
# 3. 如果相似度低于阈值，则创建新模板
if similarity < 0.7:
new_template = create_template(structure)
flag_for_review(new_template)
return {"action": "created", "template_id": new_template.id}
# 4. 如果相似度足够高，更新现有模板
merge_into_template(structure, best_match)
return {"action": "merged", "template_id": best_match.id}
9.5 性能监控指标
| 监控项 | 采集频率 | 告警阈值 | 告警方式 | |--------|----------|----------|----------| | 处理耗时 P95 | 每分钟 | > 90 秒 | 邮件 + 即时通讯通知 | | 错误率 | 每分钟 | > 2% | 即时通讯通知 | | 实体识别准确率 | 每日 | < 85% | 邮件通知 | | 内存使用率 | 每 30 秒 | > 85% | 自动扩容 + 通知 | | CPU 使用率 | 每 30 秒 | > 90% 持续 5 分钟 | 自动扩容 + 通知 | | 磁盘使用率 | 每 5 分钟 | > 80% | 邮件通知 |
9.6 版本管理与回滚
| 版本管理项 | 策略 | |------------|------| | 版本号规范 | 语义化版本号 (MAJOR.MINOR.PATCH)，如 2.1.3 | | 模型版本 | 每次部署保留至少 3 个历史版本 | | 回滚机制 | 蓝绿部署 + 即时回滚（< 5 分钟） | | 变更日志 | CHANGELOG.md 记录每次版本变更详情 | | 兼容性保证 | 小版本更新保持向后兼容；大版本更新提供迁移指南 |
10. 附录
10.1 术语表
| 术语 | 说明 | |------|------| | 招标文件 (ITT/ITB) | 招标方发布的招标邀请文件，包含评标标准与合同条款 | | 投标文件 (Bid) | 投标方响应招标文件而提交的全部文件 | | 评分标准 | 招标文件中明确的对各项评审内容的打分方法 | | 基准价 | 计算价格得分时参考的基础价格 | | 响应性 | 投标文件对招标文件要求的满足程度 | | 偏离 | 投标文件与招标文件要求之间的差异 | | 合规性 | 投标文件在格式、内容、程序上符合要求的程度 |
10.2 参考资料
- 《中华人民共和国招标投标法》（2017 修订）
- 《电子招标投标办法》（国家发改委令第 20 号）
- ISO 32000-1:2008 文档管理 — 便携式文档格式
- GB/T 36344-2018 信息技术 — 文档格式兼容性要求
11. 报告输出执行指令
重要：本章节为AI执行指令，当执行标书分析任务时必须严格遵循以下流程。
11.1 执行流程
当用户请求分析标书文件时，AI必须按以下步骤执行：
Step 1: 读取源招标文件，提取完整内容
Step 2: 按 2.3 信息提取模块要求提取关键信息，**同步记录无法识别的条款**
Step 3: 按 2.4 合规检查模块要求进行合规性检查（**含条款可识别性检测和冲突检测**）
Step 4: 按 2.5 评分预测模块要求进行评分计算
Step 5: 按 2.7.5 报告内容结构生成完整分析报告正文（**如有未识别条款，追加附注章节**）
Step 6: 确定文件保存路径（同源文件目录）和文件名
Step 7: 使用 Write 工具将报告写入文件
Step 8: 告知用户报告已生成并说明文件路径，**如有异常同步提示**
11.2 文件保存指令
必须执行的保存操作：
保存路径: 源招标文件所在目录
文件名: {源文件主名}_标书分析报告.md
文件格式: Markdown (UTF-8编码)
保存方式: 使用 Write 工具写入文件
路径确定规则示例：
- 源文件：
c:\Users\xxx\Documents\投标项目\公开招标文件1.docx - 主名：
公开招标文件1 - 报告路径：
c:\Users\xxx\Documents\投标项目\公开招标文件1_标书分析报告.md
11.3 报告内容生成规范
生成报告正文时必须包含以下内容，按顺序编排：
# {项目名称} 标书分析报告
> **生成时间**：{当前日期时间}
> **源文件**：{源文件完整路径}
---
## 一、基本信息摘要
（关键信息卡片表格）
## 二、时间节点梳理
（时间节点表格）
## 三、采购需求与技术规格
（产品清单、技术指标、性能要求等）
## 四、评分标准深度解析
（评分项目表、分值权重、评分规则说明）
## 五、商务条款与投标要求
（付款条件、资格要求、实质性要求标记等）
## 六、投标重点分析
（按分值排序的重点领域及策略建议）
## 七、技术难点分析
（技术难点及应对思路）
## 八、潜在风险提示
（按🔴🟡🟢分级风险列表）
## 九、需特别关注的条款
（无效投标情形、围标串标审查等）
## 十、综合竞争态势分析
（评分权重一览、核心结论、准备建议）
## 附注、未识别条款说明
> 📝 本附注章节仅在有未识别条款或存疑内容时出现。
> 以下为本次分析中无法自动识别或存疑的条款，需人工复核确认。
| 序号 | 所在位置 | 原文片段 | 问题类型 | 建议处理方式 |
|------|----------|----------|----------|-------------|
| 1 | 第X章/第X段/表格X | ... | 未识别格式/OCR低置信度/外部引用等 | 人工核查原始文档 |
---
*本报告由标书分析技能自动生成*
11.4 内容质量要求
| 要求 | 说明 | |------|------| | 完整性 | 必须包含全部10个标准章节，如有未识别条款须追加"附注"章节，不得省略 | | 准确性 | 所有提取的数据必须与源文件一致，不得虚构 | | 可读性 | 使用表格、列表、分级标题等Markdown元素提升可读性 | | 格式化 | 表格须对齐，标题层级合理，重点内容可适当加粗 | | 客观性 | 保持中立客观的语气，分析结论基于提取的数据 | | 时效性 | 文件生成时间、投标截止日期等动态数据使用实际值 |
11.5 异常处理
| 异常类型 | 异常情况 | 检测时机 | 处理方式 | 报告中体现 | |----------|----------|----------|----------|-----------| | 🔴 条款识别失败 | 条款文本无法匹配任何已知类别模板 | 信息提取阶段 | 记录原文片段及所在位置（段落号/页面/表格位置），不得静默跳过 | 在"附注 - 未识别条款说明"章节列出，标注"需人工复核" | | 🔴 条款间冲突 | 跨章节同主题条款存在语义矛盾 | 合规检查阶段 | 提取冲突双方的原文对照，判定冲突等级 | 在"潜在风险提示"章节以🔴高风险级别列出冲突条款的原文对照 | | 🟡 OCR置信度不足 | 扫描件文字识别置信度低于80% | 文档解析阶段 | 保留原始截图或文本片段，标记置信度 | 在"附注 - 未识别条款说明"章节标注，提示人工核查原始文档 | | 🟡 条款引用外部附件 | 条款内容指向不可读的外部附件 | 信息提取阶段 | 记录引用位置和被引用文件信息 | 在"需特别关注的条款"章节提示用户手动核查附件内容 | | 🟡 格式异常 | 条款以非标准格式呈现（如嵌套表格、图片内文字） | 文档解析阶段 | 尝试多引擎解析，失败则记录原文位置 | 在"附注 - 未识别条款说明"章节列出 | | 🟢 源文件无法读取 | 文件损坏、格式不支持 | 文档解析阶段 | 告知用户无法解析并说明原因 | 不生成报告，直接向用户反馈 | | 🟢 源文件为空或无内容 | 文件无有效文本 | 文档解析阶段 | 提示用户文件无效 | 不生成报告，直接向用户反馈 | | 🟢 保存路径无写入权限 | 目标目录无写入权限 | 文件保存阶段 | 尝试备用路径（用户桌面或文档目录）并告知用户 | 告知用户实际保存位置 | | 🟢 报告内容过长 | 生成的Markdown文件超过1MB | 报告生成阶段 | 保持核心10章节结构，适当精简过度细节，确保文件在合理大小内 | 按精简版输出 |
核心原则：所有无法识别或存疑的条款，必须以"附注 - 未识别条款说明"章节的形式在报告中明确记录，不得静默跳过或忽略。用户应当清楚知道哪些内容被完整分析、哪些内容需要人工复核。
11.6 验证确认
报告文件保存后，AI应在回复中向用户输出以下确认信息：
✅ 标书分析已完成，分析报告已自动保存至：
{完整文件路径}
报告包含以下内容：
一、基本信息摘要
二、时间节点梳理
三、采购需求与技术规格
四、评分标准深度解析
五、商务条款与投标要求
六、投标重点分析
七、技术难点分析
八、潜在风险提示
九、需特别关注的条款
十、综合竞争态势分析
附注、未识别条款说明（如有）
若分析过程中存在未识别的条款或检测到条款冲突，应额外提示用户注意"附注 - 未识别条款说明"章节和"潜在风险提示"章节中的相关内容。
本文档遵循行业最佳实践编制，版本号：2.0.0，更新日期：2026-05-20。