AI 标书自动生成系统产品系统Vibe Coding

一、立项原因（解决什么产品问题）
1. 编制周期长：一份招标文件动辄数百页，投标团队需逐条研读技术规格、商务条款、资质要求，再人工拼装应答，单份标书常耗时数天至一周，难以应对密集投标节奏。
2. 合规风险高：废标项、强制性条款、参数偏差极易在人工比对中遗漏，一处疏忽即可能导致整标作废，损失巨大。
3. 知识难复用：历史标书、产品手册、认证证书、过往案例分散在各处，企业多年沉淀的投标经验无法结构化检索与自动复用，新人上手成本高。
4. 质量不稳定：标书质量高度依赖个别专家，人员流动即造成能力流失，应答内容口径不一。

二、行业场景与业务背景
1. 投标是工程建设、装备制造、IT 集成、医疗、政府采购等各行业获取业务的核心环节，"读招标文件—检索素材—撰写应答—合规校验—导出交付"的流程在全行业高度一致，具备通用化、产品化基础。
2. 各行业招标文件结构相似（资格、技术、商务、报价等章节）、应答逻辑相通，差异主要体现在专业术语与模板章节，适合"行业无关核心 + 配置驱动适配层"的架构沉淀为通用平台。
3. 投标方普遍存在"高频、重复、强合规、强知识依赖"的共性诉求，AI 辅助标书生成具备明确刚需与规模化落地空间。

平台采用"知识底座 + Agent 场景应用"架构，划分为 12 个业务模块，覆盖投标全流程：
1. 知识库管理（knowledge）：证书、技术规格、案例、图纸等知识资产的分类管理与 RBAC 权限控制；内置"解析 → 分块 → 向量化 → 元数据抽取 → 上下文增强"的文档处理流水线。
2. 招标文件解析（tender）：自动拆分章节、抽取关键信息、识别应答要求并做缺口分析。
3. 模板管理（template）：基于 Jinja2 的章节变量模板系统，支持行业专属模板。
4. 产品库（products）：参数化检索、Excel 批量导入、产品与配件关系管理。
5. 混合检索（search）：pgvector 语义检索 + Postgres 中文全文检索（FTS）经 RRF 融合，再用 BGE-reranker 重排，结合 RBAC 权限过滤。
6. 标书生成（bid_generation）：5 节点 DAG 流水线编排，A/B/C 内容路由，由 LangGraph Agent 自动撰写应答内容。
7. 合规矩阵（compliance）：招标要求与应答的逐条映射，提供合规视图。
8. 偏差分析（deviation）：跟踪技术/商务偏差，并由 LLM 生成偏差说明。
9. 评审流程（review）：评审人分配、反馈、审批流转。
10. 清单核查（checklist）：投标前置核查清单，防止漏项废标。
11. 文档导出（export）：DOCX/PDF 生成，支持脱敏与盖章处理。
12. 系统配置（system）：行业画像、模型配置、运行时设置等。

一、项目标准
1. 严格的 DDD 分层规范（Domain / Application / Repository / ACL / Infrastructure）与依赖约束。
2. 搭建文档处理与标书生成的工作流编排，实现知识库检索与 Agent 撰写的核心链路。
3. 设计 LLM 双通道路由与行业适配层，保障多行业复用与成本可控。

二、技术栈与架构
1. 后端：FastAPI（async）+ SQLAlchemy 2.0 + PostgreSQL 16（pgvector + zhparser），Alembic 迁移，Casbin RBAC，JWT 鉴权。
2. 检索/AI：BGE-M3 向量 + BGE-reranker（经 Infinity 推理），MinerU / PaddleOCR 文档解析，LangGraph + LangChain 构建 ReAct Agent。
3. 编排：Temporal 编排文档处理与标书生成工作流；对象存储 SeaweedFS；前端 React 19 + TipTap 富文本。
4. LLM 双通道：本地 Ollama/Qwen 跑廉价批量任务（清洗、元数据抽取、检索增强），云端 Claude/OpenAI 跑推理与内容撰写，按工作负载在代码中固定通道、独立计费。

三、亮点
1. 行业无关核心 + 配置驱动适配层：以模板与行业画像驱动差异，实现一套平台支撑多行业标书生成。
2. 可信生成：三层幻觉检查 + Top-5 来源溯源，保证应答内容可追溯、可核验。
3. 混合检索：语义 + 全文 RRF 融合 + 重排，显著提升素材召回与精排质量。