学校买无线Portal，最常栽在需求书上。要么写得太虚，厂商用演示带偏；要么边界不清，上线了才发现这也不含那也不含。我们帮不少学校改过招标参数，发现坑就那么几个，提前避开能省掉后面一堆扯皮。下面把最容易踩的几点摊开讲。
坑一：认证边界写不清
需求书里最该写清的，是这套系统管什么不管什么。很多学校只写“建设无线认证系统”，没说清是否含内容过滤、是否含带宽管理。结果厂商按最小集交付，学校想要的功能要二次付费。我们建议需求书把边界一条条列：认证、计费、漫游、日志各管到哪一层，不含哪些。边界写清了，厂商不敢偷换概念。
坑二：容量拍脑袋
容量是招标里最容易糊弄的一项。有的学校写“支持全校并发”，没给数字；有的抄别校的参数，和自己实际不符。我们建议容量按摸底后的峰值模型来定，写清楚并发在线数、单账号终端数、晚高峰指标。没有数字的容量要求，评标时根本比不出真假，厂商随便填都满足。把数字写死，才挡得住注水。
坑三：对接要求含糊
对接统一身份这件事，需求书常写“支持身份认证对接”，不写协议、不写身份源清单。结果中标方说我们的平台太老对接不了，要加钱做适配。我们建议把对接协议、身份源类型、是否含访客都写进需求，最好要求提供对接测试报告。对接含糊，后面就是无底洞。
坑四：验收没有可测量标准
很多需求书写“系统稳定”“体验良好”，这种形容词评标时没法比。我们建议每条要求对应一个可测量的验收动作：支持高并发，那验收就压测；保障数据安全，那验收就查密码是否明文存储、日志是否留痕；跨楼漫游，那验收就真拿设备走两栋楼。需求书一旦可测量，厂商就不敢用话术填空。
坑五：运维责任不清
无线Portal上线后谁运维、故障响应多久、升级谁买单，需求书常不写。我们建议把运维条款写进合同附件：响应时限、驻场还是远程、重大故障的赔付。责任不清，上线后出问题厂商和学校的网络中心互相推，最后学生遭殃。运维条款看着琐碎，真出事它就是护身符。
坑六：换代预留没提
招标时没人想三年后的事，但无线Portal一用就是好几年。我们建议需求书要求开放接口、数据可导出、支持平滑升级，别绑死在私有协议上。换代预留写进去了，后面升级不用推倒重来。很多学校当初图便宜选了封闭方案，换代时发现数据导不出，只能连硬件一起扔。
演示环境的真实性
评标时厂商都喜欢拿精心准备的演示环境秀能力，但那个环境和你学校真实情况往往差很远。我们建议要求厂商在学校的测试环境或真实数据上做演示，而不是用自带的样机。尤其是并发和对接，必须在接近真实的条件下来测。演示真实了，中标后的落差才小。这条写进评标办法，能挡掉不少花架子。
别漏了培训
系统买来是给人用的，网络中心老师会不会用、能不能排障，直接决定上线顺不顺。我们建议需求书把厂商的培训义务写清楚：培训多少人、培训多久、给不给操作手册和排障指南。很多学校招标忘了这一条，系统到了没人会用，厂商远程指导又慢，头一个月苦不堪言。培训是隐形的交付物，不能省。
把需求写进合同正文
需求书里定的边界、容量、对接要求，最终得落到合同正文，不能只当附件。我们建议评标后把中标方确认的参数逐条抄进合同，作为验收依据。很多学校需求书写得硬，合同却写得软，最后厂商按合同最低标准交付，需求书白写。合同和需求对齐，验收才有抓手。
别把宝压一家
招标时留一两家备选厂商，评标才有的比，也能避免被一家绑定。我们建议短名单至少三家，参数公开，谁达标谁上，不靠关系。
无线Portal招标需求最容易在边界、容量、对接、验收、运维、换代这六个点上踩坑。把形容词换成数值和动作，标书才有杀伤力，评标时才能横向比出真假，不会被人用演示带偏。需求书硬一点，后面几年都省心，这比砍价重要得多。