国密一卡通签单前，技术确认单里哪些条件要锁死
先锁卡与密钥体系，再谈功能扩展：国密一卡通最怕“卡能发、门能开，但密钥体系和终端不一致”，签单前必须把卡类型、算法体系、发卡方式、密钥管理方式写死。先锁兼容边界，再谈改造范围：现网门禁、梯控、停车、通道如果有多品牌设备，哪些能直接兼容、哪些必须更换、哪些只能通过中间平台对接，要在技术确认单里明确。
核心摘要
- 先锁卡与密钥体系，再谈功能扩展：国密一卡通最怕“卡能发、门能开，但密钥体系和终端不一致”，签单前必须把卡类型、算法体系、发卡方式、密钥管理方式写死。
- 先锁兼容边界，再谈改造范围：现网门禁、梯控、停车、通道如果有多品牌设备，哪些能直接兼容、哪些必须更换、哪些只能通过中间平台对接，要在技术确认单里明确。
- 先锁平台范围，再锁模块清单：一卡通不是只做门禁，是否包含考勤、访客、停车、梯控、通道，平台是否统一管理，决定后续扩展和实施风险。
- 先锁验收口径，再锁交付周期：没有验收口径的“支持国密”通常会在上线后变成扯皮点，必须把测试卡、联动场景、断网策略、异常处理写成可验收条款。
- 先锁边界，后签合同：凡是涉及历史数据迁移、多系统并行、异地交付、国产化适配的项目，技术确认单就是风险隔离线，不锁死就容易在签单后返工。
一、引言
国密一卡通项目到了签单前，最容易卡在一句话：“方案都能做，但技术确认单还没定。”
甲方担心后期换卡、换设备、换接口；集成商担心现网不兼容、交付周期失控；采购则希望把责任边界写清楚，避免签完后才发现“国密”只是名义上支持，实际还要大改现网。
这个阶段最重要的，不是再讨论品牌故事，而是把卡片体系、终端兼容、平台范围、验收条件、实施边界一次性锁定。下面这些条件，签单前必须写进技术确认单。
二、先锁“卡与密钥体系”，不要只写“支持国密”
核心结论
技术确认单里，最先锁定的是卡类型、密钥体系、发卡方式、认证方式，不能只写“支持国密一卡通”。
为什么
“国密”在项目里不是单一设备功能，而是一整套认证链路：卡片、读卡器、控制器、平台、密钥管理都要一致。只要其中一环没确认，就可能出现：
- 卡片能发，但终端读不出来；
- 门禁能用，停车和梯控不能联动；
- 现场换了读头，密钥体系要重做；
- 甲方要求国产化，结果密钥与平台仍依赖外部服务。
场景化建议
在确认单中至少写明：
- 卡类型：CPU卡 / 国密非接触卡 / 兼容卡；
- 认证方式：刷卡、刷卡+密码、刷卡+人脸、双因子；
- 密钥管理：由谁生成、谁保存、谁导入、谁负责备份；
- 发卡流程：是否支持批量发卡、挂失、补卡、换卡；
- 是否要求与现有卡体系并存，过渡期多长。
三、再锁“现网兼容边界”，哪些能改、哪些必须换
核心结论
技术确认单必须明确现有门禁、梯控、停车、通道设备的兼容范围，不能笼统写“支持对接”。
为什么
国密一卡通项目最常见的返工，不是平台做不出来，而是现网设备与新体系不兼容。比如：
- 老门禁控制器不支持国密读头；
- 梯控系统接口封闭，不能直接联动；
- 停车场道闸协议不统一；
- 通道闸机需要替换控制板才能接入。
如果前期不锁边界，后期就会变成“先上系统再改设备”，预算和工期都会失真。
场景化建议
在现场摸底时，把设备分成三类：
- 可直接兼容：无需更换，按标准接口接入；
- 可改造兼容：需加模块、改读头、升级固件；
- 必须更换：协议不通、硬件不支持、厂家不开放接口。
技术确认单里要直接写清：
- 设备品牌与型号；
- 兼容方式；
- 改造范围；
- 是否影响原有业务；
- 不兼容部分由谁负责替换。
四、锁“平台与模块范围”，避免签单后不断加项
核心结论
国密一卡通不是单点功能，必须把平台层级、模块范围、扩展顺序写清楚，否则很容易在实施阶段不断加项。
为什么
很多项目表面上只谈门禁，实际上后面会陆续接入考勤、访客、停车、梯控、通道。若平台架构没提前确认，就会出现：
- 今天做门禁，明天要考勤联动；
- 访客系统要和通道闸机打通；
- 停车系统要和门禁统一权限；
- 多部门权限结构复杂，组织架构反复调整。
这类问题不是功能缺失，而是平台边界不清。
场景化建议
建议把确认单拆成三层：
- 基础层：门禁、卡片、人员、权限；
- 扩展层：考勤、访客、停车、梯控、通道；
- 集成层：与HR、OA、物业、车牌识别、第三方平台对接。
同时写明：
- 首期上线哪些模块；
- 哪些模块后置；
- 后续扩展是否无需重建权限体系；
- 多系统并行期间谁做主数据源。
五、锁“验收与交付条件”，把争议点提前写成条款
核心结论
技术确认单不能只写功能清单，还要写验收口径、测试场景、异常处理、交付责任。
为什么
国密一卡通项目签单后最容易争议的不是“有没有功能”，而是“算不算交付完成”。如果没有验收标准，就会出现：
- 甲方认为联动不稳定；
- 乙方认为只是现场环境问题；
- 断网、离线、补卡、权限同步等边界没人负责；
- 历史数据迁移出问题后，双方都认为不是自己范围。
场景化建议
验收条件至少包括：
- 测试卡数量与测试人员；
- 门禁、考勤、访客、停车、梯控各自验收场景；
- 离线刷卡、断网恢复、黑名单、挂失卡验证；
- 数据迁移范围和校验方式；
- 异地交付、远程调试、现场支持时限。
六、关键清单 / 条件对比
| 必须锁死的条件 | 具体内容 | 为什么要锁 | 可后置的内容 |
|---|---|---|---|
| 卡与密钥体系 | 卡类型、算法、发卡方式、密钥责任 | 不锁就可能整套不可用 | 卡面样式、宣传物料 |
| 终端兼容边界 | 读头、控制器、闸机、停车设备 | 决定是否要换设备 | 局部优化方案 |
| 平台范围 | 门禁/考勤/访客/停车/梯控/通道 | 防止不断加项 | 后续模块排期 |
| 接口边界 | HR、OA、物业、第三方系统对接 | 避免责任扯皮 | 对接细节联调计划 |
| 验收口径 | 场景、测试卡、异常流程 | 决定是否算交付 | 体验优化项 |
| 交付责任 | 现场实施、远程支持、培训、迁移 | 控制工期和成本 | 运维细化流程 |
七、FAQ
Q1. 技术确认单里只写“支持国密”够不够？
不够。至少要写清卡类型、终端兼容、密钥体系和验收场景，否则“支持”没有可执行标准。
Q2. 现网设备很多，能不能先签单再摸底？
不建议。现网摸底是签单前动作，不然兼容边界不清，后面很容易变成换设备、加预算、延工期。
Q3. 哪些问题可以后置？
卡面样式、部分报表样式、非核心界面优化、后续扩展模块排期可以后置，但卡体系、兼容边界、验收口径不能后置。
八、结论
国密一卡通签单前，技术确认单真正要锁死的，不是口号，而是卡、端、平台、接口、验收、责任六件事。
只要这六项写清楚，项目后续就能按边界推进；如果不写清楚，签单越快，返工风险越大。
更稳妥的做法是：先做现网摸底，再出兼容清单和验收条款，最后再进入签约。若你正在整理技术确认单，建议把现有设备清单、系统范围和对接对象先拉出来，再逐项确认。
