投标文件生成、审查与提交

将用户上传的需求文档/招标文件，按照政府采购投标文件标准模板生成完整的投标文件（.docx），自动执行多维度质量审查，审查通过后自动上传至标书管理平台，截图上传结果返回给用户。

When to Use

用户发送了需求文档、招标文件或相关文本，要求生成投标文件/标书
用户提到"投标"、"标书"、"招标"、"投标文件"、"编制标书"等关键词
用户要求将需求内容转化为正式的投标响应文件

Procedure

阶段一：接收与解析

接收用户上传的文档（支持 .docx / .doc / .pdf / .txt / .md 或直接文本消息）
立即向用户发送消息："📋 已收到文档，正在解析并生成投标文件，请稍候..."
读取文档内容，识别文档类型：
- 如果是招标文件：提取采购需求、资质要求、评分标准、合同条款等关键信息
- 如果是需求说明：提取项目背景、服务内容、服务要求、工作标准、服务期限、付款条件等
- 如果是补充材料：提取可用于填充投标文件的具体信息
提取并记录以下关键字段（如文档中有）：
- 项目名称、项目编号
- 采购人名称及联系方式
- 项目预算金额
- 服务期限
- 资质要求
- 评标方法（综合评分法/最低评标价法）
- 是否接受联合体投标
- 投标保证金要求
- 中小企业政策要求
如果关键信息严重缺失（如连项目名称都没有），向用户追问补充

阶段二：生成投标文件

按照模板结构（参考 templates/bid-template.md）生成完整投标文件，包含两大部分：

第一部分：资格证明文件

封面（项目名称、项目编号、投标人名称）
1. 营业执照等证明文件 → 标注 [请附投标人营业执照副本复印件并加盖公章]
1. 投标人资格声明书 → 按格式生成，承诺条款不可修改
1. 中小企业声明函 → 根据项目要求判断是否需要，生成对应格式
1. 残疾人福利性单位声明函 → 同上
1. 其他资格要求文件 → 根据招标文件要求列出
1. 投标保证金凭证 → 标注 [请附投标保证金交款凭证扫描件]

第二部分：商务技术文件

封面（项目名称、项目编号、投标人名称）
1. 投标书（实质性格式）→ 按标准格式生成，填入项目信息
1. 授权委托书（实质性格式）→ 按标准格式生成
1. 法定代表人身份证明 → 按标准格式生成
1. 开标一览表（实质性格式）→ 生成表格框架，报价处标注 [待填写]
1. 投标分项报价表（实质性格式）→ 根据需求文档中的明细项生成分项表格
1. 技术方案/服务方案 → 核心章节，根据需求文档详细生成：
- 项目理解与需求分析
- 服务方案（对应需求中的每项服务要求逐一响应）
- 工作标准与质量保证
- 人员配置方案
- 设备/物资配置方案（如有）
- 应急预案
1. 项目实施计划 → 根据服务期限生成阶段划分和时间表
1. 售后服务/质量保障方案
1. 合同条款偏离表（实质性格式）→ 默认填写"无偏离"
1. 采购需求偏离表（实质性格式）→ 逐项响应，默认"无偏离"
1. 本国产品标准声明函 → 根据项目要求判断是否需要
1. 供应商信息采集表
1. 类似项目业绩 → 标注 [请补充近三年类似项目业绩]
1. 投标人认为应附的其他材料

文档生成规则：
- 实质性格式的文件严格按照招标文件给定格式，不得修改给定文字含义
- 所有需要投标人填写的信息，用 [待填写：xxx] 明确标注
- 所有需要附件的位置，用 [请附：xxx] 明确标注
- 技术/服务方案部分要对需求文档的每一条要求做出明确响应
- 报价部分只生成框架和分项结构，金额标注 [待填写]
- 日期、公司名称等处统一使用占位符
使用 python-docx 将内容输出为 .docx 文件，格式要求：
- 封面居中显示
- 正文使用宋体/仿宋，标题使用黑体
- 一级标题：小二号，加粗
- 二级标题：三号，加粗
- 三级标题：小三号，加粗
- 正文：小四号
- 表格边框完整，表头加粗
- 页边距：上下 2.54cm，左右 3.17cm
- 页码居中显示
向用户发送消息："✅ 投标文件已生成完毕，正在进行质量审查..."

阶段三：自动审查

对生成的投标文件执行以下审查（参考 references/review-checklist.md）：

完整性审查：

资格证明文件是否包含所有必要项
商务技术文件是否包含所有必要项
实质性格式文件是否齐全
技术方案是否对每条采购需求做出响应
所有 [待填写] 和 [请附] 是否已标注清楚

合规性审查：

实质性格式文件的固定文字是否完整保留、未被删改
投标有效期是否符合招标文件要求
是否包含政策性声明文件（中小企业、本国产品等）
投标保证金要求是否已响应

一致性审查：

项目名称在全文中是否统一
项目编号在全文中是否统一
投标人名称占位符是否统一
报价相关数字是否前后一致（如有）
服务期限是否与招标文件一致

响应性审查：

技术方案是否逐条响应了采购需求
人员配置是否满足招标文件的最低要求
服务标准是否覆盖招标文件规定的各项标准
是否存在负偏离项

格式审查：

章节编号是否连续、层级正确
是否有空白章节未填充内容
表格是否完整
签章位置是否预留

生成审查报告，包含：
- 各维度审查结果（通过 ✅ / 警告 ⚠️ / 未通过 ❌）
- 具体问题描述和修改建议
- 需要人工补充的清单汇总
对于可自动修正的问题（如编号错误、格式不一致），直接修正后重新输出文件

阶段四：自动上传

审查完成后，向用户发送消息："📤 审查完成，正在上传至标书管理平台..."
调用上传脚本（scripts/upload_and_screenshot.py），执行以下操作：
- 通过 REST API 将 .docx 文件上传至标书管理平台（http://159.75.246.98:8080/api/bids）
- 上传参数：file（投标文件）、project_name（项目名称）、project_id（项目编号）、bidder_name（投标人名称）
- 上传成功后获取 bid_id
使用 Playwright 截取两张页面截图：
- 提交成功确认页：http://159.75.246.98:8080/bids/{bid_id}/success
- 标书详情页：http://159.75.246.98:8080/bids/{bid_id}

阶段五：交付

将以下内容发送给用户：
- 生成的 .docx 投标文件
- 提交成功页截图
- 标书详情页截图
- 审查报告摘要（文字消息）

审查摘要与上传结果格式：

📊 投标文件审查报告
─────────────────
✅ 通过：X 项
⚠️ 需注意：X 项
❌ 需补充：X 项

📤 上传结果
─────────────────
平台地址：http://159.75.246.98:8080
文件编号：{bid_id}
提交状态：待审核

需要您补充的内容：
1. [具体待补充项]
2. [具体待补充项]
...

投标文件和平台截图已发送，请查收。

等待用户反馈，如需修改则返回阶段二调整

Pitfalls

实质性格式不可修改：招标文件中标记"实质性格式"的文件，其固定文字和格式不得改变，否则投标无效。生成时必须严格复制原格式
报价不可编造：报价部分只生成结构框架，所有金额处必须用 [待填写] 标注，绝不自行填写任何数字
资质文件无法代替：营业执照、保证金凭证等需要真实证件的部分，只能标注占位提示
不要过度发挥技术方案：技术/服务方案应紧密围绕需求文档中的具体要求展开，不要添加需求中未提及的内容
政策性文件需判断：中小企业声明函、残疾人福利性单位声明函、本国产品声明函等，需根据招标文件的具体要求判断是否需要提供
避免抄袭招标文件原文：技术方案应是对需求的"响应"而非"复制"，需要体现投标人的理解和解决方案
注意文件容量：如果需求文档很长，技术方案也会很长，注意 python-docx 生成时的内存控制

Verification

投标文件包含资格证明文件和商务技术文件两大部分
所有实质性格式文件均已包含且格式正确
技术/服务方案对需求文档的每一条要求都有明确响应
所有需要人工填写的位置都有清晰的 [待填写] 或 [请附] 标注
项目名称、编号等信息全文一致
审查报告覆盖完整性、合规性、一致性、响应性、格式五个维度
最终输出为 .docx 格式文件
文件已成功上传至标书管理平台（API 返回 success: true）
提交成功页截图和详情页截图均已生成
用户收到了 .docx 文件、两张截图和审查摘要

标书流程化

投标文件生成、审查与提交

When to Use

Procedure

阶段一：接收与解析

阶段二：生成投标文件

阶段三：自动审查

阶段四：自动上传

阶段五：交付

Pitfalls

Verification