第 1 篇：采购需求管理痛点剖析与可落地解决方案

一句话摘要：采购需求是采购全链条的”源头”，源头不规范，后面招标、合同、履约全是隐患。本篇从”AI 智能审核上线后发现仍有错误”这个真实场景切入，讲清楚错误的四种类型、该不该训练模型、以及一套可落地的三层审核架构。

适用对象：采购管理部门、采购平台建设方 系列定位：第 1 篇 / 共 7 篇

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

痛点	根因	解决方案	价值
需求编制不规范（参数指向品牌、描述含糊）	无模板约束、无自动校验	需求书模板库 + 结构化表单 + 必填字段校验	从源头提升需求质量
审核靠人工、标准不统一	经验在个人、无统一依据	三层审核架构（规则+AI+人工）	审核标准统一、可复制
AI 审核有错误，不知怎么治	错误未归因、方案选错	错误归因方法论（四类错误各自治法）	错误只减不增
需求变更管理混乱	无版本留痕	版本管理 + 变更审批留痕	全过程可追溯

二、痛点剖析

痛点 1：需求编制不规范，源头就埋雷

表现：技术参数里直接写品牌型号（“须为某知名品牌”）、规格描述含糊（“质量好""性能优”）、缺验收标准、缺交付期、缺预算明细。这些问题一旦进入招标文件，轻则废标重来，重则被质疑”指向性”违规。

根因：需求编制靠各使用部门的自觉，没有模板约束，也没有自动校验手段。采购管理部门收上来什么就是什么。

痛点 2：审核靠人工，标准不统一

表现：同样一份需求书，经验丰富的老采购员能挑出”参数指向性”问题，新手可能直接放行。审核结论依赖审核员的个人水平和当日状态。

根因：审核依据散落在几十份法规和制度文件里，没有变成”系统内可执行的规则”，经验没有沉淀。

痛点 3：AI 智能审核上线了，但仍有错误（核心难点）

这是很多单位智能审核项目落地时的真实困惑：客户发现 AI 审核的内容基本符合人工审核的预期，但部分结果有错误，甚至存在明显问题。 此时有人提出”训练模型”，但——

难点一：错误到底是怎么来的，没归因就开药方。 AI 审核的错误至少分四类，病根完全不同：

错误类型	典型表现	病根
幻觉引用	引用不存在的条款、或引用已废止的旧标准	知识库喂了脏数据 / 提示词没约束”只依据检索材料”
漏检	该发现的问题没发现	知识库里没有这条规则 / 检索没召回
误报	没问题的地方报问题	规则太宽泛 / 模型理解偏差
硬规则错	金额与采购方式不匹配这类低级错误	这类事本不该交给 LLM，该用代码判

难点二：“训练模型”是治错了病。 模型微调改的是模型的”脑子”，采购审核是开卷考试——答案都在《政府采购法》《招标投标法》和校内制度里，模型需要的是”找得准、引得对”，不是”背下来”。何况微调需要千条级标注数据，一个单位一年的审核量根本撑不起来。所以方向应该是：确定性判断交给规则引擎，语义判断交给”知识库+LLM”，人工复核兜底。

痛点 4：需求变更管理混乱

表现：需求书改了一版又一版，靠文件名区分（“最终版""最终版2""真的最终版”），改了什么、谁改的、为什么改，全凭记忆。

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

方案一：三层审核架构 —— 把”不该错的事”从 AI 手里抢回来

需求书提交
   ↓
L1 规则引擎（代码判，零幻觉）
   ├─ 限额匹配：预算金额 → 采购方式是否正确
   ├─ 必填字段：品名/数量/技术参数/预算/交付期/验收标准
   ├─ 指向性扫描：品牌名/型号/"指定""唯一"等关键词
   └─ 资质红线：特定证书/注册资本门槛等歧视条款
   ↓ 硬规则违规 → 直接打回，不进 AI
L2 知识库 + LLM（语义判）
   ├─ 倾向性/排他性分析
   ├─ 需求完整性、预算合理性论证
   └─ 依据必须引用检索到的条款原文
   ↓ 低置信度
L3 人工复核（兜底）
   └─ 审核员采纳/驳回 → 驳回理由回流知识库

落地步骤（三步走）：

第 1 步：错误归因（1–2 天） 把客户反馈的错误逐条抄进下面的归因表，确定每一条属于哪一类：

#	错误描述	类型（幻觉/漏检/误报/硬规则错）	处理对策
1	引用已废止的旧限额标准	幻觉引用	补废止标记 + 提示词约束
2	没发现参数指向品牌	漏检	词库补词 + 检索优化
3	……	……	……

第 2 步：硬规则下沉（1 周） 把”限额匹配、必填字段、指向性关键词、资质红线”写成规则。短期可以直接在 Dify 工作流里加一个代码节点（LLM 节点之前），用 Python 实现：

# 伪代码示意：硬规则检查
violations = []
if not all(field in demand for field in ["品名","数量","技术参数","预算","交付期"]):
    violations.append("必填字段缺失")
if "指定" in params or "唯一" in params or "须为" in params:
    violations.append("疑似指向性表述")
if budget > limit_config["公开招标阈值"] and method != "公开招标":
    violations.append("采购方式与预算不匹配")

违规直接拦截，不进 LLM——硬规则错误当场清零。

第 3 步：知识库补齐 + 提示词约束（1–2 周）

知识库补全国家/省/校三级法规，按条款切片、带生效/废止标记（详见第 2 篇）
提示词写死三条硬约束：①只依据检索到的材料下结论；②引用必须附原文；③检索不到就明确说”知识库未覆盖”，宁可暴露短板，不可编造依据

方案二：需求书模板库 + 结构化表单 —— 从源头规范

按采购品目建需求书模板（货物/服务/工程三套底版），把必填项、验收标准写法、预算构成做成表单字段
需求编制人只能按表单填，填不齐提交不了——把”事后审核”变成”事前约束”
模板本身就是知识库的一部分，可以沉淀”本行业优秀需求书”作为范例

方案三：需求版本管理

每次修改自动生成新版本，记录”改了什么（diff）、谁改的、为什么改（变更理由必填）”
历史版本只读留痕，杜绝”最终版2”的文件名混乱

四、落地检查清单（✓）

已把客户反馈的错误逐条填入归因表，确定类型
限额标准表已数据化（按现行法规，标注生效日期）
必填字段校验已上线（表单级 + 规则引擎级）
指向性词库已建（通用层：指定/唯一/须为；品目层补充）
知识库已按条款切片，带废止标记
提示词已加”只依据检索材料 + 引用附原文”约束
低置信度转人工复核流程已通
驳回理由已回流知识库（哪怕先人工整理入库）

五、预期效果与价值

硬规则错误清零：限额、字段、指向性这类确定性错误，规则引擎 100% 拦截，客户一周内看到明显变化
审核标准统一：同样的需求书，AI + 规则给出一致的初审结论，人工只处理低置信度部分，审核效率提升 3 倍以上
经验资产沉淀：每一次人工驳回都在教系统，审核能力越用越强，不再依赖个别老采购员的个人经验

下一篇：《第 2 篇合规管理与知识库治理痛点剖析与可落地解决方案》——很多单位的做法是”把 PDF 直接传进知识库”，为什么这样不对，以及正确的六条优化动作。