公共安全预警系统的试运行如何安排？

白天、夜间、天气及遮挡条件可能不同，测试应覆盖实际使用场景，并写明没有验证的条件。

真正使用系统的岗位应参与接收、确认、转派和回填，检查流程是否符合日常工作而非只看演示顺序。

将点位问题、规则问题和流程问题分别安排整改，复测结果与原记录关联，便于判断问题是否真正解决。

第一，输入数据是否可靠，点位、画面、时间和状态能否对应现场；第二，识别提示是否满足约定的业务定义；第三，提示进入后续流程后是否有人处理。三者相互连接，但需要分别留下验证记录，避免一次顺利演示掩盖其他环节尚未完成的事实。

建议先确定哪些属于功能联调、哪些属于效果测试、哪些属于人员培训。功能联调可以检查接口与状态，效果测试需要合适样本，培训则要确认岗位能独立操作。把测试目的区分清楚，能够减少用同一张“通过”表笼统覆盖全部系统能力的情况。

真实运行中可能遇到不同光照、天气、遮挡、距离和人流条件。测试样本应尽可能反映目标使用范围，并说明哪些条件没有覆盖。仅挑选画面清楚、目标明显的片段，无法解释系统在困难场景下的表现；但也不能把不属于任务范围的条件强行计入同一指标。

样本的参考判断应有确定方式，例如由被授权且了解业务的人员核对事件定义。若不同复核人员对同一情况意见不同，应先澄清定义或标注争议样本，而不是直接把分歧当作算法错误。保留样本范围和判断规则，可以帮助后续复测保持可比。

建议分别记录有效提示、误报线索、人工发现而系统未提示的相关事项，以及无法判断的情况。不同事件类型可能具有不同样本量和业务代价，不宜用一个整体百分比掩盖关键类别表现。没有独立参考记录时，也不能仅依据系统自身日志宣称已经计算出完整漏报率。

试运行记录还应标注规则和版本。参数调整后，如果更换了测试范围或参考判断，前后结果就不能直接比较。可以保留一组已确认的共同样本用于检查变化，同时逐步补入新环境样本，避免只对熟悉数据反复优化而忽略实际使用条件。

试运行应邀请实际值守、派单和现场岗位参加，检查消息送达、确认、接收、拒收、转交和复核等动作。关键不在于每个按钮都点过，而在于每个状态之后是否有明确负责方，工作人员是否知道为什么进入这一状态以及下一步需要做什么。

还应检查交接班、接收终端不可用、重复告警和事件需要外部单位参与等情况。测试事件要明确标记，并采用管理方认可的方式开展；不能为了展示功能制造真实危险，或将测试事项混入正式运营统计，使后续数据解释出现偏差。

试运行结论应说明已验证范围、尚未完成事项、已知限制和上线后的观察安排。高影响问题如果尚未处理，应由相应负责人决定是否具备继续推进条件；不能只因到了计划日期，就把遗留问题从记录中删除。整改后应针对问题复测，并关注是否影响其他场景。

NIST AI 风险管理框架中的 Measure 内容涉及部署前测试与运行期间的评估。对本类应用，可以将环境变化、规则调整和人工反馈纳入持续观察，并记录每次评估的条件与结论。

建议报告分别呈现系统发现、人工确认和后续处置的情况。只有明确各阶段对应的记录，才能知道问题出在识别、通知还是现场执行。测试条件与样本范围应一并列出，便于理解哪些场景已检查、哪些仍需继续观察。

调整规则时应说明希望改善什么、可能影响哪些其他提示，以及采用何种方式复查。单纯减少通知数量不等于效果提高；如果工作人员因此漏掉需要关注的线索，表面上的安静并没有改善管理。

正式移交前，应确认值守排班、账号权限、联系方式与升级流程已经生效。技术调试人员离场后，事件仍需有人接收和跟进。运维支持范围与故障反馈渠道，也应在交接时说明。

1. 确定测试范围分别列出数据、识别、流转和岗位培训目标，并明确责任方。
2. 确认代表性样本记录事件定义、环境条件、参考判断和未覆盖范围。
3. 执行分类记录区分有效提示、误报、人工发现与争议情况，标明规则版本。
4. 试跑异常流程验证交接班、转交、重复、超时及接收异常，使用明确测试标记。
5. 复测与交接逐项确认整改结果，保存限制条件与上线后的观察计划。