第 3 篇：供应商资质与信用管理痛点剖析与可落地解决方案

一句话摘要：“不同招标项目对供应商的要求不一样，指向性扫描和资质红线写死到规则里是不是很难维护？“——这是建设智能审核时最常被问到的问题。本篇的答案是”引擎与数据分离 + 白/黑/灰三区模型”：把规则内容从代码里解放出来，让新项目进来就是配一套规则集，零改代码。

适用对象：采购管理部门、供应商库建设方、智能审核系统建设方 系列定位：第 3 篇 / 共 7 篇

一、概览：痛点 → 根因 → 方案 → 价值

痛点	根因	解决方案	价值
不同项目资质要求不同，规则难维护	规则内容与代码耦合	引擎与数据分离（三表设计）	新项目=配规则集，零改代码
合法资质 vs 歧视条款分不清	一锅烩、无分层	白名单/黑名单/灰色地带三区模型	合法可要求的自动放行，歧视条款自动拦截
供应商信息孤岛	无统一库、无关联分析	供应商库 + 关联图谱（股权/联系方式归一化）	一人多企、企业关联现形
资质造假/过期难发现	无证照核验、无到期预警	证照库 + 到期预警 + 联网核验	资质风险提前暴露

二、痛点剖析

痛点 1：不同项目要求不一样，规则写死就废了（核心难点）

这是智能审核建设中最尖锐的质疑：医疗器械项目要求”经营许可证”，工程项目要求”施工资质”，信息化项目要求”等保测评”——每个项目对供应商的要求都不一样，如果把”资质红线”写进规则代码，岂不是每个项目都要改一遍代码？

难点在于把两个概念混为一谈了：

“可以要求什么资质” —— 这是因项目而异的（医疗器械要经营许可、工程要施工资质），确实每个项目不一样
“禁止要求什么资质” —— 这是任何项目都一样的（注册资本门槛、注册地域、指定品牌授权，任何项目都禁止）

把这两件事拆开建模，维护焦虑就化解了一大半：“因项目而异”的部分用数据配置（每个品目配一次），“全局禁止”的部分配置一次所有项目生效。

痛点 2：合法资质与歧视条款，边界难判断

表现：一份需求书里写”投标人须具有电子与智能化工程专业承包二级以上资质”——这是合法的；写”投标人注册资本不低于 5000 万”——这是歧视条款。但还有大量灰色地带：“要求项目经理具备 10 年以上经验”——相关吗？等级过高吗？规则代码写不出来，也不该写。

难点认知：你担心”难维护”的那部分，一大半本来就不该进规则代码。 规则引擎只留”确定性判断”（在清单内/不在清单内、命中关键词/不命中），凡是”看情况”的判断全部上交给 AI 检索法规和案例来论证。

痛点 3：供应商信息孤岛，关联关系看不见

表现：同一批人注册多家公司轮流投标、两家公司法人是夫妻、联系方式是同一个手机号——这些在评标现场靠肉眼很难发现，尤其是”轮流坐庄”式的围标，单看一次招标毫无异常。

痛点 4：资质造假、资质过期

表现：供应商的资质证书靠人工核验，造假的没发现、过期的没预警，直到中标后被质疑才发现问题。

三、解决方案（可落地执行）

方案一：引擎与数据分离——代码是执行器，规则是数据

┌─────────────────────────────────────────────┐
│  代码层（写一次，所有项目复用）                    │
│  4个执行器：限额匹配 / 字段校验 / 指向性扫描 / 资质审核 │
├─────────────────────────────────────────────┤
│  数据层（按维度维护，业务人员可改）                 │
│  通用规则集 ← 品目规则集 ← 项目规则集（三套组合加载）  │
└─────────────────────────────────────────────┘

落地三张表：

表名	字段	说明
`rule_set`	id, name, dimension（通用/品目/项目）, scope（品目编码或项目ID）	规则集定义
`rule_item`	id, set_id, rule_type（限额/字段/指向性/资质）, content(JSON), priority, enabled	规则条目
`project_rule_bind`	project_id, set_id	项目绑定哪些规则集

执行逻辑：项目提交审核 → 查 project_rule_bind → 加载”通用+品目+项目”三套规则集 → 逐个执行器跑规则 → 输出违规清单。

维护动作：新项目 → 选品目（自动带入品目规则集）+ 增补项目特殊词 → 完成。全程不碰代码。

方案二：资质审核三区模型——把”确定”和”看情况”分开

┌─ 白名单区：法定资质，按品目维护 ─────────────┐
│  医疗器械→经营许可证 / 工程→施工资质 /        │
│  信息化→等保测评        → 规则引擎判定：有/无 │
├─ 黑名单区：歧视条款，全局禁止 ──────────────┤
│  注册资本门槛 / 注册地域 / 指定品牌授权 /      │
│  特定年限业绩            → 规则引擎判定：命中/未命中 │
├─ 灰色地带区：相关性强弱、等级是否过高 ─────────┤
│  "这个资质要求与项目到底相不相关"              │
│        → RAG+LLM 语义判断：检索法规+历史案例论证 │
└────────────────────────────────────────────┘

三个区的职责划分：

区	谁来判	判断方式	维护成本
白名单	规则引擎	配置表里”该品目允许要求的资质清单”，命中清单即合法	每个品目配一次
黑名单	规则引擎	关键词/模式匹配，任何项目都禁止	配置一次全局生效
灰色地带	RAG+LLM	检索相关法规 + 历史审核案例，输出论证意见	无需维护，靠知识库

关键价值：规则引擎的规则量会保持在一个很小的、可维护的规模——因为**“看情况”的判断全部上交给了 AI，规则引擎只留确定性的**。

方案三：供应商库 + 关联图谱

一期（MySQL 就够）：

供应商主档：统一社会信用代码、法人、股东、注册地址、联系方式
归一化：手机号、邮箱、地址去空格/去格式后存储，比对重复
共投矩阵：SELECT 供应商A, 供应商B, COUNT(*) FROM 投标记录 GROUP BY ...——两家公司历史共同投标次数，超过阈值预警
交叉核对：供应商注册信息里法人/股东/电话与其他供应商重复 → 提示关联

二期/三期（数据量大再上图数据库 Neo4j）：

股权穿透：二级以上关联自动发现
轮流中标模式：统计”AB 同场次数 vs 交替中标次数”，显著高于随机基线则预警
陪标识别：某公司”从不中标但总陪跑”，报价总是陪标价

方案四：资质证照管理

证照库：证书编号、类型、发证机关、有效期截止日、扫描件
到期预警：提前 90/30/7 天自动提醒（定时任务扫描即可，规则引擎一条规则）
联网核验：对接全国建筑市场监管公共服务平台等官方接口验真（按预算和场景选择）

四、落地检查清单（✓）

已建 rule_set / rule_item / project_rule_bind 三张表
已梳理”通用黑名单”（注册资本/地域/指定品牌等，配置一次）
已按主要品目配置白名单资质清单（至少覆盖本单位高频采购品目）
灰色地带判断已明确交给 AI 处理（不进规则代码）
指向性词库分三层维护（通用/品目/项目）
供应商主档已建，手机号/邮箱/地址已归一化
共投矩阵查询已上线（哪怕先手动跑 SQL）
证照库已建，到期预警已配置
配了一个”规则维护”管理界面（哪怕先只读列表+手动编辑 JSON）

五、预期效果与价值

新项目零代码接入：规则集配置化，业务人员自助维护，不再依赖开发排期
资质审核口径统一：合法资质自动放行、歧视条款自动拦截、灰色地带 AI 论证，审核标准不再因人而异
关联风险提前暴露：一人多企、轮流坐庄、共投过高，在开标前就能看到提示
这套能力全产品线复用：广东某高校、北中医、央美、东莞理工等所有采购项目，同一套引擎 + 各自的数据配置

下一篇：《第 4 篇招投标防串标围标痛点剖析与可落地解决方案》——五大检测层、风险评分卡、以及”文件指纹/元数据指纹/报价模式”这些技术到底是怎么组合起来干活的。