水务项目的技术参数，写松了会被低质中标，写紧了会被质疑定向。真正的难点不在“写多细”，在“怎么写得既唯一又不排他”——这两件事听起来矛盾，但用对方法是可以同时做到的。
这篇讲三条写法原则、三个核心指标的可验收表述，以及评分表怎么设。
一、参数写成什么样会被围标
三种典型写法，每一种都在给围标留门：
写品牌型号。“计量精度不低于 X 品牌 Y 型号”——这是最直接的定向采购，被质疑基本没有辩护空间。即使本意只是想要那个精度，写法也必须改成参数描述。
写独家功能名。把某家厂商产品手册里的功能名称原样搬进参数，比如“支持 XX 智能诊断引擎”。这类表述在其他厂商的参数表里找不到对应词，评审时会被判定为排他。
写无法验证的形容词。“系统应具备高效稳定的数据处理能力”“界面应简洁友好”。这类表述看起来中立，实际是废条款——投标时人人响应，验收时无从检验，最后变成谁都能过、谁都不用负责。
第三种最隐蔽，危害也最大。因为它让技术分失去区分度，最后只能比价格。
二、三条写法原则
原则一：功能用业务语言描述，不用产品语言。不要写“具备分区计量模块”，要写“能按 DMA 分区统计供水量、售水量、产销差，并支持按日、月、年三个粒度导出”。前者是产品功能名，后者是业务能力描述。后者任何一家真做过水务的都能响应，没做过的响应不了。
原则二：指标必须可量化、可测量、有统计口径。凡是带“高效”“稳定”“友好”“完善”的，全部换成数字加口径。写“设备在线率不低于 98%”不够，要写“按自然日统计，单台设备单日离线累计超过 30 分钟计为当日离线，月度在线率 =（1 - 离线设备日数 / 应在线设备日数）× 100%，不含计划内维护窗口”。
原则三：每个关键项留至少两条技术路径。想用 NB-IoT 智能水表，参数就该写成“支持 NB-IoT 或 LoRaWAN 任一窄带物联网通信方式，且满足以下指标……”，再在指标里把 NB-IoT 的优势（如深度覆盖、免布线）转成量化要求。这样既达到目的，又不排他。
这三条原则的核心是：用“要达到什么效果”约束，而不是用“必须用什么技术”约束。
三、三个核心指标怎么写才可验收
抄表成功率。这是水务项目最容易扯皮的指标。常见写法“抄表成功率不低于 99%”有三个漏洞：统计周期没定、分母没定、失败后补抄算不算成功没定。
可验收的写法是：“抄表成功率 = 当期成功抄见表数 / 应抄表数 × 100%，按月统计。成功抄见指在抄表例日前 3 个自然日内获得有效读数；首次失败后经补抄在例日后 2 日内成功的，计为成功。连续两个抄表周期失败的表计需单独列表说明原因。验收期连续三个月平均不低于 98%。”
注意这里用的是抄表成功率而不是通信成功率。通信成功率是设备厂商的指标，抄表成功率才是水务公司关心的结果——中间还差着数据校验、异常值剔除、补抄机制。写通信成功率会让供应商把责任推到“通信正常但表计异常”上。
DMA 分区产销差。常见写法“分区产销差控制在 12% 以内”。问题在于：产销差受季节、水价调整、大用户用水结构影响，不是软件能单方面决定的。
更合理的写法是把责任边界切开：“系统应能按 DMA 分区自动计算供水量、售水量、产销差率，日粒度数据完整率不低于 99%，月结数据与营业收费系统核对差异不超过 0.5%。分区产销差率的实际下降幅度由双方在试运行期共同测定基线后另行约定考核目标。”
把“软件能保证的”（数据完整、核对一致）和“需要运营配合的”（实际漏损下降）分开，是避免验收僵局的关键。
系统响应时间。常见写法“页面响应时间不超过 2 秒”。漏洞是没定并发数、没定数据量、没定测法。
可验收的写法：“在 200 个并发用户、单分区 5 万表计、查询跨度 12 个月的条件下，分区产销差报表的 95 分位响应时间不超过 3 秒；使用 JMeter 或同等工具在验收环境实测，测试脚本和结果数据双方留存。”
四、评分表怎么设才不让价格战赢
技术参数写得再好，评分表设错也会前功尽弃。三个关键设置：
技术分与价格分的比例。水务这类涉及民生和长期运营的项目，技术分占比不宜低于 50%。技术分占比 30% 以下时，价格几乎决定结果。
价格的评分曲线。不要用“最低价得满分、按比例递减”的线性算法，那等于鼓励低价。改用基准价法：以有效投标报价的算术平均值下浮一定比例作为基准价，接近基准价得满分，明显低于基准价的要扣分并要求说明成本构成。
业绩分的写法。不要写“具有类似项目业绩得 X 分”，要写“近三年完成过单个体量不低于 5 万户的供水企业营销系统或 DMA 分区计量项目，每提供 1 个得 X 分，需提供合同关键页和验收证明”。有量化门槛的业绩分才能区分真假。
还有一个容易被忽略的设置：把关键指标写进合同而不是只写进招标文件。招标文件是评标依据，合同才是履约依据。指标只在招标文件里出现、合同里没有对应条款的，后期无法追责。
五、招标前必须自己先做的三件事
第一件，把现有系统的家底摸清。营销系统用了多少年、数据库什么版本、有多少张表、多少存储过程、有没有文档。这些数字直接决定迁移工作量，也决定参数里该不该写“不停业迁移”。我们在水务行业页里写过运行十一年的营销系统怎么迁，那类项目的真实工作量往往是最初估算的三倍。
第二件，先划清 DMA 分区边界。分区边界没定，参数里写“支持 DMA 分区管理”就是空话。边界涉及管网改造、阀门加装、大用户归属，这些是土建和运营的事，不是软件能解决的。
第三件，定一个可测的基线。现在的抄表成功率是多少、产销差是多少、系统响应多快。没有基线，“提升 20%”这种要求无法验收。基线测定最好请第三方参与，避免后期争议。
这三件事做完，参数自然就写得出来——因为你已经知道自己要解决什么，而不是在抄别人的招标文件。
下一步
如果项目还处在方案阶段，先看水务行业页里的三个典型场景和四期实施路径，能帮你判断哪些内容该放进本期招标、哪些该留到下一期。
需要的话，把现有系统的规模和本次招标范围发过来，我们可以按上面的原则帮你过一遍技术参数，标出哪些条目存在排他风险、哪些无法验收。