一、两类典型写法错误：产品说明书与正确废话
第一类错误是把需求书写成了某一家产品的产品说明书。常见形态包括：技术参数与某产品的规格书逐条对应，条款措辞直接沿用厂商白皮书，甚至把某产品特有的模块名称、界面术语写进需求。这类需求书的后果不只是「招标失去竞争性」这么简单——只要条款与特定供应商的产品特征高度吻合，就已经进入法规明确禁止的范围。
第二类错误看起来无害，杀伤力却不小：通篇都是无法验证的正确表述。「系统应具备良好的扩展性」「界面应友好易用」「应提供完善的技术支持」——这些条款在评标时无法打分，只能靠评委印象，最后技术分变成主观分，评标结果也难以解释。招标过程一旦被质疑，评标委员会无法说明扣分依据，是很容易被推翻的。
两类错误的根源是同一个：把「描述想要什么」当成了「描述应该怎么做」。需求书的任务是写清楚验收时可以检验的结果，而不是描述实现路径。这个视角一转换，很多难以落笔的条款就有了写法。
二、法规红线：哪些写法会被认定为不合理条件
招标投标的基本要求写在《中华人民共和国招标投标法》中。该法第十八条规定，招标人可以根据招标项目本身的要求，在招标公告或者投标邀请书中要求潜在投标人提供有关资质证明文件和业绩情况，并对潜在投标人进行资格审查，但招标人不得以不合理的条件限制或者排斥潜在投标人，不得对潜在投标人实行歧视待遇；第二十条规定，招标文件不得要求或者标明特定的生产供应者以及含有倾向或者排斥潜在投标人的其他内容。
《中华人民共和国招标投标法实施条例》（国务院令第 613 号，2012 年 2 月 1 日起施行）第三十二条把「不合理条件」具体化为七种情形：一是就同一招标项目向潜在投标人或者投标人提供有差别的项目信息；二是设定的资格、技术、商务条件与招标项目的具体特点和实际需要不相适应或者与合同履行无关；三是依法必须进行招标的项目以特定行政区域或者特定行业的业绩、奖项作为加分条件或者中标条件；四是对潜在投标人或者投标人采取不同的资格审查或者评标标准；五是限定或者指定特定的专利、商标、品牌、原产地或者供应商；六是依法必须进行招标的项目非法限定潜在投标人或者投标人的所有制形式或者组织形式；七是以其他不合理条件限制、排斥潜在投标人或者投标人。
技术撰写的具体尺度还可以参考《工程建设项目施工招标投标办法》（国家发展改革委等多部委令第 30 号，2013 年修正）第二十六条的精神：招标文件规定的各项技术标准应符合国家强制性标准，不得要求或者标明某一特定的专利、商标、名称、设计、原产地或生产供应者，不得含有倾向或者排斥潜在投标人的其他内容；如果必须引用某一生产供应者的技术标准才能准确或清楚地说明拟招标项目的技术标准，则应当在参照后面加上「或相当于」的字样。这条「或相当于」的写法，是技术需求书里最实用的一条宽容性设计。
针对近年突出的隐性壁垒问题，《国家发展改革委等部门关于严格执行招标投标法规制度进一步规范招标投标主体行为的若干意见》（发改法规规〔2022〕1117 号，13 部门 2022 年 7 月 21 日印发、2022 年 9 月 1 日起施行，共 5 方面 20 条）进一步明确：招标文件中资质、业绩等投标人资格条件要求和评标标准应当以符合项目具体特点和满足实际需要为限度审慎设置，不得通过设置不合理条件排斥或者限制潜在投标人；依法必须招标项目不得提出注册地址、所有制性质、市场占有率、特定行政区域或者特定行业业绩、取得非强制资质认证、设立本地分支机构、本地缴纳税收社保等要求，不得套用特定生产供应者的条件设定投标人资格、技术、商务条件。
| 常见写法 | 问题所在 | 合规改写思路 |
|---|---|---|
| 产品功能清单式逐条罗列（含专有模块名与界面术语） | 条款与特定产品特征高度吻合，可能被认定为指向特定供应商 | 改为按业务能力与可验证结果描述，例如不写「应具备 XX 智能稽核模块」，改写为「系统应能对提交单据按预设规则自动校验并输出不符合项清单」 |
| 指定某品牌数据库、某品牌中间件 | 属于限定或者指定特定的品牌或供应商 | 改为描述能力要求并给出等效说明，例如「支持国产数据库，投标人须在方案中说明适配的数据库产品及版本，并提供适配验证方式」 |
| 要求在某地设有本地分支机构或本地缴纳税收社保 | 属于法规明确禁止的隐性壁垒 | 改为对服务的实质要求，例如「须承诺在合同期内提供不少于约定频次的上门服务，并说明服务响应机制」 |
| 以特定行业的业绩、奖项作为加分或中标条件 | 属于法规明确的禁止情形 | 改为要求提供同类项目的实施证明材料，且不限定行业与地域，不以奖项作为评分项 |
| 技术参数与某厂商规格书逐条对应（核数、线程数、某版本号） | 参数来源于特定产品，可能构成套用特定生产供应者条件 | 改为写业务量与验证方式，例如「在买方提供的并发模型与数据量下，约定响应时间指标，由投标人现场演示或提供测试报告」 |
| 要求提供非强制的资质认证证书 | 属于不得提出的非强制资质认证要求 | 改为要求提供国家强制性标准要求的证明，或改为要求投标人自行声明并承担相应责任 |
需要说明的是，上述规则主要针对依法必须进行招标的项目。非强制招标的项目在采购自由度上更大，但把合规写法用在所有采购上仍然划算：它会让比较更公平，也避免后期因为条款争议导致的履约纠纷。
三、四步翻译法：把业务诉求变成可验证条款
写技术条款的难点，往往在于业务部门提的是诉求，不是标准。财务说「审批要快」，信息化说「要能对接现有系统」，这些都进不了需求书。把它们逐条翻译过来，走四步就够了。
- 第一步，动词化：把名词与形容词改成动作。把「良好的报表能力」改成「能够按指定维度生成报表并导出」
- 第二步，加量化：为每个动作补上可度量的边界。把「能够导出报表」改成「在约定数据量下，指定报表的生成时间不超过约定秒数，且导出文件可在通用表格工具中打开」
- 第三步，定证据：写清评审时用什么证明。是现场演示、书面测试报告、还是第三方测评结果。证据形式必须写到条款里
- 第四步，给替代路径：为每一项硬性要求留出「或提供等效证明」的通道。这既是合规要求，也避免因技术路线不同而误伤有实力的投标人
| 业务诉求原文 | 不可验证的写法 | 可验证的条款写法 | 验证方式 |
|---|---|---|---|
| 审批要快，不要卡在领导那里 | 系统应具备高效的审批能力 | 系统应支持按条件路由、会签与或签、加签、超时提醒与自动转交，异常分支行为须与买方现行审批制度一致 | 现场用买方提供的历史单据脚本逐分支演示 |
| 要能对接现有系统 | 系统应具备良好的集成能力 | 系统应提供标准数据接口，接口文档须包含字段说明与错误码；须提供可用的测试环境供买方自研脚本读取数据 | 买方在测试环境现场执行一次数据读取脚本 |
| 数据要能拿得出来 | 数据归买方所有 | 系统应支持全量导出凭证、明细账、往来余额与附件清单；导出格式须为通用格式，不得依赖厂商专用程序读取；不得以任何理由拒绝或延迟导出 | 现场执行一次全量导出，并在未安装厂商软件的机器上打开验证 |
| 凭证不能被随便改 | 应保证数据安全可靠 | 系统不得提供已记账凭证的删除与插入功能，凭证编号须连续；对已记账凭证的日期、币种、汇率、金额、科目、操作人等要素不得修改 | 现场尝试删除、插号与修改三类操作，验证是否均被拒绝 |
| 要符合国产化要求 | 支持信创环境 | 投标人须说明产品在国产处理器、操作系统、数据库上的适配情况，并载明适配的产品名称、版本与适配验证方式；相关产品应为现行有效的通过安全可靠测评的产品 | 核对投标人提交的适配清单与测评公告的对应关系 |
最后一项值得单独提一句：涉及国产化要求时，「支持信创」四个字没有信息量。比较有效的写法是要求投标人给出适配清单——适配了哪一款处理器、哪一款操作系统、哪一款数据库、什么版本，以及用什么方式验证过。清单本身就是可验证的，也避免了把要求写成对某一技术路线的指定。
四、需求书的结构骨架
结构本身不产生合规问题，但结构混乱会放大撰写偏差。建议按下面的骨架组织，每一章都有它必须回答的问题。
| 章节 | 必须写清楚的内容 | 最常见的缺陷 |
|---|---|---|
| 项目概述与建设目标 | 现状、建设范围、边界、与既有系统的关系 | 只写目标不写边界，导致后期需求不断外溢 |
| 业务范围与流程说明 | 纳入系统的组织范围、业务类型、关键流程与例外分支 | 只写主干流程，例外分支留待实施阶段临时决定 |
| 功能要求 | 按业务能力分组，每条含动作、量化边界与验证方式 | 写成功能清单堆砌，无量化与验证方式 |
| 集成与接口要求 | 需要对接的系统清单、接口形式、数据方向、频次 | 笼统写「需要对接」，实施时才发现接口不可用 |
| 性能与容量要求 | 并发模型、数据量级、批处理时间窗、响应时间指标 | 缺少数据量前提，指标无法验证 |
| 安全与合规要求 | 等级保护定级、数据留存、日志要求、国产化适配清单 | 抄一段规范条文，未落到具体功能与验证方式 |
| 实施与服务要求 | 实施周期约束、人员投入要求、培训与文档交付、服务响应机制 | 只写周期不写人员与交付物 |
| 验收标准 | 与功能要求逐条对应的验收方法与判定标准 | 验收标准与需求条款不对应，导致验收时无据可依 |
其中「验收标准」一章最容易被写成套话。有效的做法是把功能要求中的每一条都编上号，验收标准逐号对应写法与判定依据。这样做还有一个附带好处：投标人在报价时无法忽略自己做不到的条款，因为每一条都要在验收时兑现。
五、评标办法与需求书的衔接
需求书与评标办法是同一件事的两端：需求书写了要什么，评标办法决定了怎么比。两者脱节是最常见的技术性失误——需求书写了「按月结批处理时间不超过约定时长」，评标办法里却没有任何一项考察这个能力，结果是写了等于没写。
衔接的方法很简单：把需求书中的条款按「必须满足」与「加分考察」分成两类。必须满足的条款进入符合性审查，一条不满足即废标或要求澄清；加分考察的条款进入评分表，且每一项都要写明分值与评分档次。需要额外注意两点：一是加分项的设置不能触碰前面提到的行业业绩、地域、奖项等禁止情形；二是评分档次之间的差异必须能被评委一致判断，例如「完全满足得满分、部分满足得一半分、不满足不得分」，而不是「优秀、良好、一般」这类无法对齐的标准。
此外，程序的几个时间点也需要在招标文件中一并交代清楚。按照《招标投标法实施条例》，依法必须进行招标的项目，编制资格预审文件和招标文件应当使用国务院发展改革部门会同有关行政监督部门制定的标准文本（第十五条）；招标文件的发售期不得少于 5 日（第十六条）；澄清或者修改的内容可能影响投标文件编制的，应当在投标截止时间至少 15 日前以书面形式通知所有获取招标文件的潜在投标人，不足 15 日的应当顺延投标截止时间（第二十一条）；潜在投标人或其他利害关系人对招标文件有异议的，应当在投标截止时间 10 日前提出，招标人应当自收到异议之日起 3 日内作出答复，作出答复前应当暂停招标投标活动（第二十二条）。对技术复杂或者无法精确拟定技术规格的项目，招标人还可以分两阶段招标，第一阶段由投标人提交不带报价的技术建议，招标人据此确定技术标准和要求后再编制招标文件（第三十条）——这一点对需求边界不清的财务系统项目尤其适用。
六、发布前的十项自查
- 通读一遍，确认没有任何条款指向某一特定供应商、品牌或产品型号；确需引用技术标准的，是否已加上「或相当于」
- 检查是否有注册地址、所有制性质、市场占有率、本地分支机构、本地缴纳税收社保、非强制资质认证等被明确禁止的要求
- 检查资格与业绩要求是否与项目本身的实际需要相适应，是否存在明显超出需要的过高门槛
- 逐条检查是否有量化边界：数字、时间、比例、数据量前提是否写全
- 逐条检查验证方式：每一条硬性要求对应的验证方式是否明确，且具备可操作性
- 检查合规类条款是否落到了具体功能与验证动作上，而不是停留在条文引用
- 检查需求书条款与评标办法的对应关系：写了要考察的，评分表里是否有对应项；评分表里的加分项，需求书里是否有依据
- 检查评分档次是否具备可一致判断的标准，避免出现无法量化对齐的主观表述
- 检查涉及国产化、等级保护、数据留存等要求时，是否给出了可核验的清单或验证路径，而非笼统表态
- 检查标准文本的使用与各时间点设置是否合规，异议与澄清的处理流程是否已写入文件
这十项自查做完，需求书的质量通常已经超过多数同行。剩下的工作是把条款按必答与加分分类，形成评分表，并留出足够的时间做澄清与答疑——把时间给足，比反复修改条款更能降低后期争议。
资料来源：《中华人民共和国招标投标法》第十八条、第二十条、第三十一条；《中华人民共和国招标投标法实施条例》（国务院令第 613 号，2011 年 12 月 20 日公布，2012 年 2 月 1 日起施行，后经国务院修改）第十五条、第十六条、第二十一条、第二十二条、第三十条、第三十二条；《工程建设项目施工招标投标办法》（国家发展改革委等多部委令第 30 号，2013 年修正）第二十六条；《国家发展改革委等部门关于严格执行招标投标法规制度进一步规范招标投标主体行为的若干意见》（发改法规规〔2022〕1117 号，2022 年 7 月 21 日印发，2022 年 9 月 1 日起施行）。