校园网络认证系统招标，最怕需求书写成厂商产品手册的翻版。学校图省事，直接拿某家厂商的彩页改成需求，结果招来的就是那家的方案，价格和扩展都被框死。需求文档是学校的矛，写好了才能筛选厂商、守住底线；写歪了，整个采购就被牵着走。这里讲讲怎么把需求写扎实。

先写业务场景，再列功能点

很多需求书一上来就是"支持网页认证、支持多设备、支持审计"，全是功能罗列，没有场景。问题是不同厂商对这些功能的理解深度不同，列功能点反而给了他们发挥空间。更好的写法是先写业务场景：开学并发峰值多少、一人几台设备、访客怎么放、物联网怎么隔。场景写清楚，厂商才知道自己的能力到底够不够，学校评标时也能看谁真的答到了点。场景是需求的主干，功能点只是它的枝叶，顺序别反。

把"必须"和"锦上添花"分开

需求里最坑的是所有条目一个样，厂商随便凑几个加分项就能糊弄。建议把需求分成三档：必须满足的硬指标、应该满足的重要项、有了更好的可选项。硬指标不达标直接淘汰，重要项占评分大头，可选项才用来拉开差距。这样写，厂商就没法用一堆花哨功能掩盖核心能力的缺失。学校评标时也有据可依，不会被"我们有人工智能运维"这类话术带偏。分档是需求文档的骨架，缺了它，评分就会失真。

接口和兼容要写死

认证系统不是孤岛，它要接统一身份、要管各种接入设备、可能还要和计费系统打交道。需求里必须写死兼容性要求：支持哪些标准协议、能不能和现有交换机对接、对接不上时谁负责改造。我们见过需求只写"具备良好扩展性"，结果中标后发现不支持学校现有的无线控制器，改造费另算，预算直接超。兼容条款写得越具体，后期被加价的概率越低。这是防厂商留口子的关键一招。

验收标准要比功能清单更细

需求书里功能写了满满几页，验收却只写"系统正常运行"。这种不对称是纠纷温床。正确的做法是对每条重要需求配验收方法：并发能力怎么测、故障切换耗时多少算合格、多设备并发上限怎么验证。把这些写进合同附件，厂商报价时就不敢虚标参数，上线时也有尺子量。验收标准细到可操作，需求才真正有约束力，否则就是一纸愿望。

容量和扩容要留活口

招标时按当前规模买，三年后校区扩建就傻眼。需求里应该明确：当前规模是多少，未来三年的预估增量是多少，扩容是加节点还是换大机，授权怎么计，单价是否锁定。把这些写进需求，厂商在方案里就得给出平滑扩容路径，而不是等你要扩了再坐地起价。容量条款看着是技术细节，实则是保护学校议价权的阀门。

别把运维责任写丢

最后提醒，需求里要写清运维责任边界。系统故障谁响应、多久到场、重大事件怎么升级，日常策略配置归谁，这些必须进需求。我们见过需求只管交付、不管运维，结果上线后小问题拖成大故障，厂商说"不在服务范围"，学校只能自己扛。运维条款写进需求书，才算把全生命周期兜住。招标不是买个软件就完事，是把后面好几年的合作关系先定个规矩。

评标要求厂商实地演示

需求书写得再好，厂商真本事得拉出来溜。我们建议在评标环节要求厂商用学校提供的真实场景数据，现场演示关键流程：并发登录、故障切换、多设备接入。看彩页谁都会画，真用你的数据跑一遍，能力虚不虚立刻现形。演示表现该占评分实打实的比重，别让它沦为形式。这一关把住，中标方案的水分能挤掉大半。

计价口径要写死防加价

招标商务里最容易被做文章的，是授权计价口径。按用户数计还是按终端数计，价格能差出一大截；扩容单价锁不锁，决定三年后你被不加价挟持的程度。需求书里必须把计价单位、当前规模、未来增量、扩容单价全写清。这些商务条款看着琐碎，实则是保护学校议价权的阀门。含糊的口径，就是留给厂商后期加价的口子。

付款节点要和验收挂钩

招标商务里还有一条容易被忽略：付款节奏。别验收前就把全款付了，那样厂商交完货就没动力管细节。我们建议把尾款和试运行验收绑死，系统平稳跑满约定周期、关键指标达标，尾款才释放。这条对厂商是实打实的约束，比合同里的漂亮话管用。同时也别把首付款压太低，合理首付能让厂商有资源把实施做扎实。付款节奏是商务里最硬的指挥棒，写好了，服务质量自然跟上。