审标项目 按项目推进审标 · 每个项目独立固化规则集
新建审标项目 上传招标文件 PDF → OCR → AI 提炼 → 勾选确认 → 固化规则集
📄
点击或拖拽上传招标文件 PDF
支持扫描件，将自动进行 OCR 文字识别
我的项目
AI 提炼审查点 提炼结果先进入「待确认」，您确认后才固化为本项目规则集
提炼进度 按维度分阶段提炼
待确认清单 按维度分组 · 勾选纳入本项目规则集 · 来源：A 招标文件 / B 强制法规
预置规则库 行业范本 + 强制法规的通用规则库 · 只读
这里是行业范本 + 强制法规构成的通用规则库，不是本项目生成的 —— 它不针对任何一份招标文件，也没有页码出处，不能直接当作本项目的审查依据。
每个项目都应当以本项目的招标文件原文为提炼对象，生成项目专属规则集（含出处页码）之后，再运行审查。
通用规则库清单 只读 · 共 —
工作台
当前项目：尚未创建项目 · 固定总价 — 万元（限额设计） · 商务标文本 6 份（A~F，自编脱敏）
目标值
≥80%
审标效率提升
设计目标：单份 ≤200 页标书 ≤5 分钟
目标值
<1%
核心废标条款漏检率
设计目标：标准化审标点零漏检
目标值
≥98%
商务标审标准确率
设计目标：与专家一致性 ≥98%
实测值 · 真实链路
--%
AI 初判与人工核对一致率
尚未运行真实审查
关于本 DemoPOC 分层说明 —— 哪些是真跑，哪些是设计呈现
✅ 真实链路（可现场验证）
上传标书 PDF → 浏览器本地解析文本（pdf.js）→ 关键词召回上下文 → 真实调用 LLM API → 结论与耗时留档，支持人工核对并统计一致率。商务标检查点（报价、最高限价、业绩、承诺工期、签字盖章、资质等级等）+ 技术标 4 项（总建筑面积比对、容积率测算、规范引用核查走 LLM；专业章节完整性走本地规则引擎）。
🎭 产品设计呈现（规划中 / 非真实链路部分）
其余 — 项检查点属技术标入口或本期转人工处理（详见「商务标审查」页检查点表）；技术标图纸参数（多模态）为规划下一期能力。生产规则库 — 项（A 招标文件 / B 强制法规两级来源）、全自动/半自动/全手动分类策略、强制复核与合规追溯机制详见各功能页。
想先走一遍完整流程？
（产品自带仿真数据，不是你的真实项目；载入后可一键移除）
功能模块
📋
商务标审查
真实链路 · 真调 LLM
📐
技术标审查
演示 · 多模态规划下一期
📝
任务书生成
演示
🔍
同类项目调研
演示
📊
项目总结报告
演示
审查方式分类策略
按 4 个维度加权评分，将每条审查条款划分为「全自动 / 半自动 / 全手动」
| 评估维度 | 权重 | 说明 |
|---|---|---|
| 风险等级 | 40% | 触发废标、高金额偏差等高风险项强制复核 |
| 规则明确性 | 30% | 规则越明确，越适合全自动审查 |
| AI 置信度 | 20% | 判「是」<90% 转复核；判「否」一律人工 |
| 数据可用性 | 10% | 外部数据可联网核验程度 |
LLM 模型选型（规划：全私有化部署）
| 任务环节 | 推荐模型 |
|---|---|
| 文件解析 | 智谱 ChatGLM3-6B-128K |
| 商务条款审查（逻辑推理） | DeepSeek-R1 / 通义千问 |
| 报告生成 / 文案润色 | 通义千问（本地版） |
| 图纸参数提取（多模态） | Qwen2-72B（昇腾优化版） |
| 规则兜底 | 自研规则引擎 |
POC 阶段：直接调用云端 API（DeepSeek / 智谱 / 通义任选），Key 仅存本机。
商务标审查
真实链路：— 项检查点真跑 LLM · 其余为规则核查 / 人工核查项（见下方检查点表）
真实 AI 审查 真实链路PDF 本地解析 → 真调 LLM → 结论留档可核对
⚠️ 数据安全红线：请勿上传任何真实投标文件（含投标人商业机密）。现场演示请使用
仿真测试数据/ 目录下 6 份自编仿真投标文件（T1 完全合规 / T2-T6 各含典型缺陷，演示文件存于演示者本机）；自行体验请使用各地公共资源交易平台公开发布的文件。
| 检查点 | 审查内容 | AI 初判 | AI 判断依据 | 耗时 | 人工核对 |
|---|
📊 实测记录：—
核心检查点 按维度分组 · 勾选决定纳入审查 · 点击行展开依据 · 黄色为 B 类强制法规（非招标文件原文，默认不启用）
| 启用 | 检查点 ID | 类别 / 来源 | 审查内容 | 审查方式 | 链路 | 结论 | 操作 |
|---|
跨文件串标检测 v1.8 新增 · 跨文件比对不是「文本相似度排序」，而是扣掉公共来源之后仍然异常相似
判定分三层：① 扣招标原文转述（15 字片段包含判定，响应招标要求而雷同属正常）；② 扣版式噪声（页眉页脚、水印、章节标题）；③ 扣行业套话（在多数文件中都出现的句子判为通用、不计分，本例 6 份中 ≥4 份）。
仅对过滤后仍高度雷同的段落计分：仅两份共有（DF=2）权重 1.5，4 份以上共有（DF≥4）不计分。
| 对比 | 加权得分 | 判定 | 最长公共块 | 主要命中（已过滤通用套话） | 操作 |
|---|
⚠️ 能力边界：本 POC 的串标检测使用构建期预抽取的文本索引——中文 PDF 无法在浏览器端可靠抽取文本（pdf.js 缺 CJK cMap），故真实链路的串标检测需服务端解析，当前 POC 未包含。
技术标审查
真实链路：4 项检查点（3 项 LLM + 1 项规则引擎） · 测试材料：脱敏技术标文本 A/B（47/41 页真实设计文档）
真实 AI 审查 真实链路指标提取与比对走 LLM · 章节完整性走本地规则引擎（规则兜底演示）
T1-T3 调用 LLM（复用「商务标审查」页的 API 配置与代理）；T4 为本地规则引擎检查，不调模型。建议使用
脱敏技术标/ 目录下的两份文本测试。| 检查点 | 审查内容 | 引擎 | AI 初判 | 依据 | 耗时 | 人工核对 |
|---|
图纸参数提取与招标要求比对 示例数据（非真实链路）
| 参数项 | 图纸提取值 | 招标要求 | 比对结论 | 置信度 |
|---|---|---|---|---|
| 总建筑面积 | 81,790 ㎡ | 81,790 ㎡ | ✔ 一致 | 98.6% |
| 用地面积 | 44,587 ㎡ | 44,587 ㎡ | ✔ 一致 | 99.0% |
| 容积率 | 1.83（81,790 / 44,587） | ≤2.0 | ✔ 满足 | 97.8% |
| 功能面积构成 | 教学 29,700 · 生活服务 35,100 · 车库设备 11,340 · 架空 4,200 · 办公 1,450 | 合计 81,790 ㎡ | ✔ 一致 | 96.4% |
| 绿地率 | 32% | ≥30% | ✔ 满足 | 96.9% |
| 图纸与文本一致性 | 柱网 8m×8m / 文本 8m×8m | 偏差 ≤5% | ✔ 一致 | 99.0% |
技术方案响应性审查 示例数据（非真实链路）
| 审查项 | 结论 | 方式 |
|---|---|---|
| 方案针对招标 10 条要求逐条响应 | 是 · 逐条响应 | 半自动 |
| 是否引用已废止规范 | 否 · 均为现行版本 | 全自动 |
| 是否违反强制性条文（消防分区 800㎡≤1000㎡） | 未违反 | 全手动 |
| 承诺设计周期 55 天 ≤ 招标要求 60 天 | 满足 | 全自动 |
规范引用核验（对接规范库） 示例数据（非真实链路）
| 引用规范 | 状态 |
|---|---|
| 《建筑设计防火规范》GB50016-2014（2018 年版） | 现行有效 |
| 《建筑结构荷载规范》GB50009-2012 | 现行有效 |
| 《绿色建筑评价标准》GB/T50378-2019 | 现行有效 |
| 《中小学校设计规范》GB50099-2011 | 现行有效 |
审查报告
由筑智通 AI 智能审标系统生成 · 商务标 / 技术标分模块成稿 · 报告整理 / 汇总效率目标提升 ≥95%
尚未生成报告。请先在「商务标审查」或「技术标审查」页完成真实审查与人工核对。
报告生成中心 规划中 · 未接真实能力
调用 AI 能力自动生成任务书 / 调研报告 / 总结报告初稿，人工复核后定稿
建筑设计任务书生成
选择建筑类型/主题→输入设计参数→调用知识库→AI 生成初稿→人工复核
| 参数 | 取值 |
|---|---|
| 建筑类型 | 教育建筑 · 高级中学 |
| 用地面积 / 建筑面积 | 4.46 万㎡ / 8.18 万㎡ |
| 核心指标 | 容积率 ≤2.0 · 建筑密度 ≤30% · 绿地率 ≥30% |
| 特殊要求 | 绿色建筑设计 · 无障碍设计 · 海绵城市 |
同类项目调研报告生成
选择报告模板→案例库语义检索→AI 生成报告→人工复核
| 检索命中案例 | 关键指标 | 参考价值 |
|---|---|---|
| 广州大剧院 | 容积率 6.0 · 高 250m | 高 |
| 深圳湾科技生态园 | 建筑面积 50 万㎡ | 高 |
| 滨海市第二高级中学新校区 | 装配式教学楼体系 | 中 |
项目总结报告生成
自动提取项目概况、关键里程碑、成果与亮点、问题与经验、入围方案、专家评审意见摘要，沉淀知识库供后续项目检索复用。
合规追溯
真实链路审查的全过程操作 / 判断依据 / 复核记录留痕 · 追溯覆盖率目标 100%
操作追溯时间线
暂无记录。
能力验证 真实链路
28 样本测试集 · 四轮提示词配置真实复测 · 还原弱模型时代的迭代优化过程，每一轮都是真实 API 调用
为什么有这个模块
在弱模型时期（如 6B 级本地模型），让模型稳定输出严格的「是/否」判断需要多轮提示词迭代优化。 本模块用与当年相同的 28 个核心检查点测试集（JSONL：question / context / answer）， 按当年四个关键轮次的提示词配置实时调用当前模型复测，真实测量每一轮的准确率与格式合规率—— 既还原历史情形，也直接验证「基座能力提升后，同样的测试集表现如何」。
当年迭代决策记录（源自技术验证文档）
| 轮次 | 发现问题 | 原因分析 | 决策 | 当年结果 |
|---|---|---|---|---|
| 第 1 轮 | 模型输出长篇解释 | 指令未有效传递 | question 中嵌入严格系统指令 | 开始出现「是」，仍带解释 |
| 第 4 轮 | 准确率仅 50%（随机水平） | 缺乏上下文信息 | 为所有检查点补充上下文 | 准确率升至 78.6% |
| 第 6 轮 | 标准答案与上下文矛盾 | 标注逻辑错误 | 修正 2 个样本的标准答案 | 准确率升至 92.9% |
| 第 9 轮 | 否定问题理解错误 | 上下文否定信号弱 | 上下文中添加明确结论 | 准确率 96.4% |
| 第 10 轮 | — | 达到目标 | 确认验证通过 | 100% 准确率，格式完美 |
实时复测 真实链路选择轮次配置 → 对 28 个样本逐一真实调用 → 统计准确率/格式合规率
R1/R4/R9/R10 的配置差异只在提示词与上下文，模型与测试集完全相同。选「本地 1.5B」可真实复现当年的失败模式（需先启动
本地小模型服务，CPU 推理较慢，一轮约几分钟——这正是当年需要 GPU 工作站的原因）。评测记录计入合规追溯。| ID | 类别 | 检查点 | 标准答案 | 模型输出 | 判定 | 格式 | 输出摘录 |
|---|