周五下午的需求表
周五下午四点，领导甩来一句话：“下个月要招标，你把需求弄一下。”
打开需求表——三行字：
- 办公设备一批
- 质量要好
- 价格合理
这场景不陌生吧？
更熟悉的剧情是：招标结束了，质疑来了。供应商投诉”参数指向特定品牌”，评标委员会退回文件”评分标准无法量化”，审计问”需求依据是什么”——一个都答不上来。
回头复盘，所有问题的根都在那张三行字的需求表里。
**80%的招标争议，根因不在评标，在需求编制。**这不是夸张——采购39条痛点全景图里排前三的痛点，全部指向需求阶段：需求模糊导致无法比价，歧视性条款引发质疑，验收标准缺失导致扯皮。
需求写不好，后面全白费。
采购需求编制5步法
从那张三行字的需求表，到一份经得起质疑、能落地招标的需求文件，中间差的是一套可复用的方法。以下5步，每步解决一个核心问题。
Step 1 业务痛点翻译——把”我要一个好的”翻译成可量化指标
核心问题：业务部门说的不是需求，是愿望。
“要一个好的""要稳定的""要性价比高的”——这些话在需求评审会上出现频率最高，也最没用。
愿望不能招标。能招标的是指标。
业务部门的表达天然是模糊的，这不是他们的错——他们关心的是业务结果，不是采购参数。翻译，是采购人的核心能力。
翻译方法：3层追问
| 层次 | 问什么 | 举例 |
|---|---|---|
| 第1层：痛点 | ”现在出了什么问题？" | "设备老坏” |
| 第2层：场景 | ”坏的时候什么场景受影响？" | "月度汇报投影仪卡死3次” |
| 第3层：量化 | ”怎样算解决？" | "连续运行4小时无故障，年故障≤2次” |
三层追问走完，“要一个好的”变成了”连续运行4小时无故障，年故障≤2次，响应时间≤2秒”——这才是可以写进招标文件的需求。
常见翻译对照
| 模糊表达 | 翻译后 |
|---|---|
| ”质量要好” | 成品率≥99.2%，质保期≥3年 |
| ”要快的” | 交付周期≤15个工作日，紧急订单≤3个工作日 |
| ”服务到位” | 驻场≥2人，7×12小时响应，2小时到场 |
| ”性价比高” | 全生命周期成本（TCO）≤X元，含5年维护 |
甲方检查项： 需求表里每一条，能否用一个数字或明确的”是/否”来判断达标？如果不能，回Step 1重新翻译。
Step 2 标准锚定——找到参照物，别凭空编参数
核心问题：没有参照的参数，要么太松要么太严，而且经不起质疑。
翻译完痛点，拿到量化指标了。下一个坑：这个指标的值怎么定？
拍脑袋定参数，是需求编制最大的风险源之一。参数定高了，只有一家能投——歧视性条款；参数定低了，什么都能投——没法比。两种结果都指向废标。
锚定来源有4类，按优先级排序：
-
行业标准/国家标准——GB/T、行业规范，这是最硬的锚。比如办公家具的GB/T 3325，信息系统的等保2.0标准。标上国标号，质疑来了你有依据。
-
历史合同——上一轮招标的实际执行数据。上一家供应商的响应参数、用户满意度评分、故障记录，都是活生生的参照。但注意：历史数据是下限参考，不是上限绑定。
-
同行参数——同行业公开招标文件里的技术参数。这一条要谨慎使用——直接抄同行的参数，可能复制了对方的歧视性设计而不自知。
-
市场调研——3家以上供应商的技术方案对比。调研本身合规，但调研结果不能只取最优值，否则又变成指向性条款。
锚定实操要点
- 每个关键参数后面标注来源：
连续运行4小时无故障（参照GB/T 9813.1-2016） - 市场调研保留记录——谁提供的、什么时候提供的、参数对比表。质疑来时这是证据
- 不确定参数值时，给区间不给点值：
响应时间2-5秒比响应时间3秒安全得多
甲方检查项： 关键参数是否标注了来源依据？来源是否能经得起”为什么是这个值”的追问？
Step 3 边界划定——明确”不要什么”，比写”要什么”更重要
核心问题：只写正面需求，评标时无法排除不想要的方案。
大多数需求文件只写”要什么”，不写”不要什么”。结果是什么？供应商投来一个技术上”符合”但业务上完全不适用的方案，评标委员会拿着评分表，找不到扣分项——因为需求里没说不可以。
3类必须划的边界
① 排除性边界——明确不接受的方案类型
举例：采购云服务，需求里写了”支持弹性扩容”，但没有写”不接受公有云单租户部署”。结果供应商投了一个逻辑上”支持扩容”但架构完全不符合安全要求的方案，评标无法淘汰。
写法：本采购不接受公有云单租户架构，须为私有化部署或专属云方案
② 底线边界——最低合格标准
举例：写了”提供售后服务”，没写底线。供应商投了一个”5×8电话支持”的方案，甲方要的是”7×24驻场”。需求里没写底线，投诉成立。
写法：售后服务最低要求：7×24小时，含驻场支持≥2人，2小时到场响应
③ 负面清单——历史上踩过的坑
每次招标完的复盘，都应该把”不该出现但出现了的方案”记录下来，写入下次需求编制的负面清单。这是组织级的资产。
甲方检查项： 需求文件中是否明确了”不接受什么”？是否有底线参数而非仅理想参数？
Step 4 合规预检——需求描述是否构成歧视性条款
核心问题：你以为在写好需求，审计认为你在写倾向性条款。
这是需求编制最凶险的一步。技术部门觉得”这个参数就是业务需要的”，法律部门看一眼——歧视性条款，打回。
3类高频合规风险
| 风险类型 | 典型写法 | 合规改写 |
|---|---|---|
| 品牌指向 | ”采用XX品牌或同等品牌” | 写性能参数，不写品牌名 |
| 规模门槛 | ”注册资本≥5000万” | 与采购金额匹配的合理规模要求，或改为履约能力描述 |
| 业绩歧视 | ”具有XX省同类项目业绩" | "具有同类项目业绩≥N个”，不限定地域 |
合规预检的2个核心原则
原则一：参数写性能，不写品牌。 这条说起来人人都懂，做起来人人犯错。最常见的”暗门”是：把某个品牌的独有技术参数写进需求——也许不是故意的，但客观效果就是指向性。
原则二：门槛要必要，不要方便。 “注册资本≥5000万”方便筛选，但不一定必要。合规的问法是：这个门槛与合同履行有没有直接关联？如果说不清楚关联性，这个门槛就是歧视。
自检清单快速过一遍：
- ✅ 是否出现了品牌名、型号？→ 删掉，换成等效性能参数
- ✅ 供应商资质要求是否超出项目需要？→ 对照项目规模匹配
- ✅ 业绩要求是否限定地域或特定客户？→ 去限定，保数量
- ✅ 技术参数是否只有一家能满足？→ 查市场，调范围
甲方检查项： 需求文件是否经过法务/合规部门审查？是否对照《政府采购法》第22条或《招标投标法》第20条做了逐条自查？
Step 5 可招标验证——内部评审3问，通过才能进招标
核心问题：需求写完了≠能招标了。缺少验证环节，问题全部延迟到评标阶段爆发。
需求编制完，直接进招标文件编制——这是多数甲方的流程。省掉的环节叫”可招标验证”。
验证3问，缺一不可：
❶ 能不能比？——可比性验证
需求参数是否允许多家供应商在同一维度上比较？
反例：需求写”提供优质的服务”——每家都说自己优质，没有比较维度。 正例：需求写”故障响应时间≤2小时，驻场人员≥2人”——可以比。
检验方法：把需求参数遮住供应商名称，看能否排出先后名次。排不出，就不具备可比性。
❷ 能不能评？——可评性验证
评分标准能否对应到需求参数？
反例：需求写了10条技术参数，评分标准只有”技术方案30分”——10条参数怎么分配30分？评标委员会自由裁量空间过大，质疑风险飙升。
正例：需求10条参数，评分标准逐条对应——每条参数1-3分，有明确的评分档位描述。
❸ 能不能定？——可定性验证
评完标，能否依据需求和评分结果做出确定的定标决策？
反例：技术分A供应商高，价格分B供应商低，需求里没写”技术权重＞价格权重”的依据——定标时扯皮。
正例：需求编制阶段就明确了权重倾向和定标原则，评标委员会有据可依。
甲方检查项： 需求文件是否通过了”可比、可评、可定”3问验证？验证记录是否归档？
常见错误TOP5
跑完5步法，再对照这张”翻车清单”做最终检查。以下5个错误，覆盖了需求编制90%的返工原因。
❌ 错误1：模糊需求——“好""快""省”写进招标文件
典型症状：需求表里出现”性能优良""服务及时""价格合理”等无法量化的表述。
后果：所有供应商都”符合”，无法筛选，评标沦为形式。
根治方法：回到Step 1，3层追问，全部翻译为可量化指标。如果某个维度确实难以量化，改为”通过方案评审由评委打分”的评审项，而非资格条件。
❌ 错误2：隐形门槛——表面合规，实际指向
典型症状：技术参数只有一家供应商完全满足，其他供应商”差不多但差一点”。
后果：质疑投诉，项目延期，严重的被认定围标串标。
根治方法：Step 4合规预检全覆盖。关键参数做市场验证——至少3家供应商能达到，参数才算安全。
❌ 错误3：过度指定——恨不得把产品手册抄进需求
典型症状：技术参数写了50条，其中30条是某品牌产品的默认配置，与项目实际需要无关。
后果：限制竞争，涉嫌歧视，且增加了供应商响应负担，降低投标积极性。
根治方法：每条参数问一个问题——“这条不写，会不会影响项目目标达成？“不会，删掉。
❌ 错误4：缺验收标准——需求写了，怎么验收没写
典型症状：需求参数齐全，但验收时发现”响应时间≤2秒”测的是实验室环境还是生产环境？谁测？用什么工具测？一概没说。
后果：交付扯皮，验收争议，尾款付不出去。
根治方法：关键参数必须配套验收方式——测试方法、测试环境、合格判定标准、验收周期。
❌ 错误5：需求与预算脱节——需求写满了，预算不够
典型症状：需求按理想方案编制，一算总价超预算30%，打回重来。
后果：需求编制返工，招标延期，更严重的——降标采购，质量缩水。
根治方法：Step 2锚定阶段同步做成本估算。需求编制不是闭门造车，预算是硬约束不是软参考。
AI辅助需求编制：提效但不可替代
AI工具可以大幅加速需求编制的前期工作，但有一条不可越过的红线——
AI生成的需求内容，必须经过人工逐条审核，不得直接写入招标文件。
这来自AI招采10条红线的第1条：AI产出未经人工审核，等同于未审核。
AI能做什么
| 环节 | AI可以辅助 | 提示词示例 |
|---|---|---|
| Step 1 痛点翻译 | 把模糊描述扩展为维度框架 | ”以下是一段业务需求描述，请从性能、服务、交付、成本4个维度拆解为可量化指标：[粘贴原始描述]“ |
| Step 2 标准锚定 | 检索相关国标行标 | ”请列出[XX行业][XX品类]相关的国家标准和行业标准清单，标注标准号” |
| Step 3 边界划定 | 生成排除性条款草案 | ”基于以下需求参数，请列出可能出现的5种不适用方案类型，并给出排除性表述建议” |
| Step 4 合规预检 | 初筛歧视性表述 | ”请逐条检查以下需求参数，标注可能构成歧视性条款的条目并说明原因” |
| Step 5 可招标验证 | 检查可比性/可评性 | ”请检查以下需求参数是否具备可比性，标注无法横向比较的条目” |
人工必须复核的3个要点
- 参数值的准确性——AI可能生成看似合理但实际不存在的参数值，必须与市场调研数据交叉验证
- 合规风险判断——AI可以标注疑似风险，但”是否构成歧视性条款”的法律判断必须由合规人员做出
- 业务适配性——AI不了解甲方的实际业务场景，参数是否真正匹配业务需要，只有业务部门说了算
AI是加速器，不是决策者。用好AI的关键是：让AI干粗活，让人干判断。
更多AI辅助招标文件的实操方法，参见招标文件AI生成实操。
甲方实操清单
打印这张清单，需求编制每完成一步，逐项打勾。全勾完，再进招标。
Step 1 业务痛点翻译
- 每条需求是否可以量化为数字或”是/否”判断？
- 是否完成了”痛点→场景→量化”3层追问？
Step 2 标准锚定
- 关键参数是否标注了来源（国标/行标/历史合同/市场调研）？
- 参数取值是否有≥3家供应商可满足？
Step 3 边界划定
- 是否明确了”不接受什么”（排除性条款）？
- 是否设定了底线参数（最低合格标准）？
Step 4 合规预检
- 需求中是否出现了品牌名、型号？（如有，删除）
- 是否经过法务/合规部门审查并出具意见？
Step 5 可招标验证
- 能不能比——需求参数是否支持横向比较？
- 能不能评——评分标准是否逐条对应需求参数？
- 能不能定——定标原则是否在需求阶段已明确？
结尾：需求编制不是填表，是翻译
采购人最容易犯的错，是把需求编制当成填表——拿个模板，业务部门填几行，采购部门润色一下，交差。
但这不是填表，这是翻译。
把业务部门的模糊愿望，翻译成供应商能响应、评标委员会能评判、审计能追溯的精确语言。翻译不到位，后面所有环节都在为这个翻译失误买单——质疑、废标、扯皮、延期。
5步法不是5个步骤，是5道保险。每一步都是在替后面的环节排雷。
需求写清楚了，招标是技术问题；需求写不清楚，招标是玄学问题。
别让招标从技术问题变成玄学问题。