一、先说清楚：巡更到底难在哪
安保巡更这件事，几乎每个园区、写字楼、小区都在做，但真正能拿出证据的很少。常见的四种局面，做过物业的人应该都不陌生。
第一，打卡方式本身就是漏洞。 挂在墙上的签到卡，一支笔谁都能代签；巡更棒打点，数据要拿回办公室连电脑导出，等导出来已经是第二天；也有用微信群发照片的，照片翻起来过两天就找不到了。工具换了三种，核心问题没变：签到的动作和真实的到岗，本来就不是一回事。
第二，外包队和物业之间没有中间凭据。 保安是外包的，月底结算的时候，外包队长说"我们按班次都巡了"，物业主管说"三号楼消防通道那几天没人去"。两边都没说谎，但谁也没有可查的记录，最后往往按和气的方式抹平，或者一直拖着。
第三，异常发现了，但没人接。 夜班巡逻发现消防通道被货物堵住、地下车库有渗水、围栏被撬开一个口子，用对讲机报给班长，班长在交接班本上写一笔。第二天换班，这件事就停在纸上了。等到真出事，回头查不到"谁在什么时候发现的、当时报没报、后面谁处理了"。
第四，被问数据答不上来。 项目开会或者甲方检查，问"这个月各点位到岗率多少""哪条路线漏得最多""外包队这个月异常几起"，只能现翻本子、现数照片，凑出来的数字自己都不敢签字。
这四个问题的共同点，是"应巡的计划"和"实际发生的记录"没有分开存，也没有留下不可随手改的凭据。所以在 AI 构建器里搭这一套，重点不在页面多漂亮，而在底表怎么拆。
二、底表怎么建：把"计划"和"实际"分开
下面这套是通用做法，园区、写字楼、住宅小区、厂区门岗都能套用，只是点位和路线的数量不同。
点位档案（应巡的基准）
每个需要有人去看一眼的地方，就是一条点位记录：点位编码、点位名称、所属区域/楼栋、具体位置描述（如"B 座 3 层东侧消防通道"）、点位类型、启用状态。点位编码建议加唯一约束，避免同一个通道被录成两条、后面统计重复计数。
关键设计决定：点位是档案，不是任务。人换、班次变、路线调，点位本身不动。这样历史记录的统计口径才不会漂。
巡检路线（点位的顺序集合）+ 路线点位子表
一条路线由若干个点位按顺序组成，所以路线主表只存路线名称、适用区域、预计耗时；顺序和点位放在路线点位子表里：路线、点位、顺序号、计划间隔分钟。
关键设计决定：路线点位一定要拆子表，不要在路线主表里存一串逗号分隔的点位。串在一个字段里，改一个顺序就要重写整串，历史记录也没法按点位统计。
班次与排班（谁在什么时间该走哪条线）
班次表定义每个班次的起止时间，并且要显式处理跨零点：22:00 到次日 06:00 是一个班次，不能被系统算成两天两个班次，否则任务会重复生成或凭空丢掉一段。排班表按日期 + 班次 + 路线 + 巡逻人（或班组）来记，它回答的是"这一班该谁走哪条线"。
巡更任务（计划落到具体一次）
排班不是任务，排班只是规则。每天由系统按排班生成一条条巡更任务：任务编号、日期班次、路线、巡逻人、计划开始与结束时间、实际开始与结束时间、完成状态、缺失点位数。
关键设计决定：任务表单独存在，不合并进排班表。同一个排班被执行一次，就产生一条任务；临时换人、临时加一条路线，都在任务上调整，规则本身不动。这样月度统计可以直接从任务表出数。
打卡记录（实际发生的凭据）
每个点位的实际到岗，是任务下面的一条明细：所属任务、点位、打卡时间、打卡人、现场照片、备注、是否标记异常。这一张表是整套系统里最要紧的地方。
关键设计决定：打卡记录只增不改。发现漏打、点错点位、时间不对，不要覆盖原记录，而是另起一条更正记录并写明原因，原记录保留。原因很实在——这张表要拿去和外包队对账、要在甲方检查时出示，一张能被随手改写的表，等于没有。
异常事件（发现之后谁在管）
巡更中标记异常时，单独立一条异常事件：事件编号、来源打卡记录、异常类型、现场描述、紧急程度、处理人、状态、是否转工单。它把"巡逻员看一眼"变成"有人负责到底"的链路。
字典先定，别边跑边加
点位类型、班次、异常类型、紧急程度、任务状态、处理结果这几组选项，全部放进数据字典统一维护，可以看数据字典：管好下拉选项的统一口径。上线后再加选项，历史数据要回填，成本比一开始想清楚高得多。尤其任务状态，建议上线前就定成：待开始、进行中、已完成、超时未完成、已作废——五种就够用，不要更多。## 三、四个角色，四套页面
同一个模块，不同的人打开应该看到不一样的东西。巡更系统里至少要分四种视角。
巡逻员：只有"我的任务"和"打卡"
手机上一进页面就是今天的任务列表，点进任务是一条点位清单，走到哪个点就打卡哪个点：可选点位、填备注、上传现场照片。发现异常就地标记并写一句描述，比在群里发一段语音管用得多。巡逻员不需要看统计、不需要看别人，页面越少越好。
安保班长：今天谁在巡、哪条线卡住了
看板按班次列出当日全部任务，每条带状态和已打卡点位数。班长最关心三件事：还没开始的（可能人没到岗）、超时未完成的（可能卡在某处）、以及标记异常的。这里要放一个"催办"动作，直接给巡逻员推一条通知。
项目经理/物业主管：到岗率和异常趋势
按区域、按路线看近 7 天的到岗率和漏巡点位 TOP，看异常事件的类型分布和处理时长。这里不需要知道每个点位几点打的卡，只要看哪一片在系统性漏巡——漏巡往往不是人的问题，是路线排得不合理或者点位本身没必要。
行政/结算：月度对账单
按外包队或按路线汇总：应巡次数、实际完成次数、漏巡次数、异常起数、处理完结数，然后导出明细。这张表就是月度结算的谈判依据。
再加一个基础配置视角：点位档案、路线与顺序、班次与排班规则，只给少数几个人权限。在角色与权限配置里把"配置"和"执行"分开授权，巡逻员不应该能看见排班表。
四、四类自动化，把"要人盯"的事交给系统
页面解决"看得见"，自动化解决"不用盯"。这套系统里真正省人的是下面四类规则，全部用平台的既有能力配，不需要写代码。
第一类，定时任务：每天准时生成与扫尾。
每天零点过几分，按排班规则生成当日巡更任务——人不用记得"今天要给谁排班"。再配一个每小时跑的扫描，把超过计划结束时间还没走完的任务标成"超时未完成"，并记下缺了几个点位。定时任务的配置与执行记录可以看工作流与定时任务。
第二类，数据流规则：状态自己往前走。
打卡记录一标记异常，自动在异常事件表里生成一条待处理事件，同时通知值班主管；一条任务下面所有点位都打完卡，任务状态自动置为"已完成"并写入实际结束时间。这类"满足条件就改数据、发通知"的规则，用数据流规则引擎配，不需要人工点确认。
第三类，工作流：需要人负责的环节走审批。
异常事件转工单要有人确认、派工、验收；外包队的月度结算单要走一遍审核。这两处用审批流做，节点和流转条件在工作流可视化编辑器里配置。
第四类，通知与审计：提醒到位、改动留痕。
超时未完成推给班长，异常上报推给值班主管，站内信是基础通道，需要时按企业自己的配置接邮件或短信。同时打开审计日志：谁修改了已完成任务、谁作废了任务、谁改了排班，都要能查到人。巡更系统的公信力就建立在这两件事上——提醒不会漏，改动跑不掉。## 五、移动端是主战场，别把 PC 页面照搬
巡更这件事，九成的操作发生在巡逻员走动的路上。所以设计的时候要反过来想：先想手机上一屏能干什么，再想 PC 上补什么。
手机端只放三块内容：今天的任务、点位打卡、异常上报。配置类的页面（点位档案、路线、班次）只在电脑上做，手机上再放一遍只会让人点错。
在 AI 构建器里，模块发布时按页面平台分别挂载，PC 页面会同步生成手机端视图，发布前的预检会提示同步情况，具体步骤见模块的测试与发布和移动端使用指南。
几个实操上必须提前说清的点：
- 照片是凭据，不是装饰。 打卡时要求上传现场照片，照片与打卡记录绑定存储，回看时和点位、时间、人在一条记录里。没有照片的打卡记录，事后争议时说服力差很多。
- 打卡动作要短。 巡逻员戴手套、在楼梯间、一只手拿手电，操作步骤超过三步就会开始有人敷衍。所以点位清单按顺序排、默认带出时间、照片一次拍完就提交。
- 打卡的方式要提前和一线确认。 这一版的做法是在手机上选中点位打卡，系统记录提交时间与提交人，不依赖额外的硬件。是否需要引入扫码、定位这类能力，属于现场条件问题，需要按企业实际环境单独立项评估，不建议在首版里放进范围。
- 网络不好的楼层别做成必填长流程。 电梯间、地下室信号差是常态，能把打卡记录先提交成功最重要，照片类的附件按平台实际界面提示重试补传。
六、上线前必须查的八件事
系统本身一天能搭完，能不能用得下去，看这八条有没有过。
- 点位编码有没有重号。 给点位编码加唯一约束，重号会让统计凭空多出一条。
- 路线顺序是不是真走一遍对过。 让班长按系统里的顺序实际走一趟，把计划时长按实际走时改一遍，否则超时提醒天天响，很快就会被关掉。
- 跨零点班次试生成两天。 22:00 到次日 06:00 的班次最容易出错，上线前连跑两天任务核对有没有重复或缺口。
- 状态和异常类型字典定稿。 上线后每加一个选项都要回填历史数据，前七天定稿成本最低。
- 权限按"看自己、看本队、看全园区"三档配。 巡逻员看不到别人的任务，班长看本队，项目经理看全部，配置权限单独给一两个人。
- 试运行一周并行比对。 纸质签到或巡更棒先别停，两边跑七天，比对漏巡次数是否一致；差得多说明点位或路线设计有问题，不是人的问题。
- 历史数据不硬搬。 老的巡更棒记录格式杂、点位对不上，建议只在系统上线当天切换，历史记录另行归档，不要为了"数据完整"把脏数据塞进新表。
- 发布前跑一遍预检，确认手机端同步成功。 电脑上看着好、手机上是空白，是这类双端模块最常见的上线事故。
七、这套东西还能往哪延伸
巡更做起来之后，园区里另外几件事可以用同一套底表思路接上去，数据还能互相引用：
- 门岗的访客登记与通行轨迹，和巡更是同一个安保视角的两端，见访客登记与门岗通行。
- 巡逻对象从"点位"扩展到"设备"，就变成设备点检巡检，可以看设备点检巡检，两者的记录结构几乎一致。
- 巡更中发现的设施损坏，可以直接转成业主报修单，见物业报修。
- 巡逻员本人在不在岗，最终会和考勤排班对上，如果企业已经在用考勤模块，可以按人员编码关联。
八、这套方案的边界：它不做什么
说清楚不做什么，比说能做什么更有用。
- 不做摄像监控、门禁、道闸这类硬件接入。 巡更模块记录的是人的动作和数据，硬件侧的联动需要单独评估。
- 不做人脸识别、活体检测。 到岗凭据以打卡记录、时间与现场照片为准，不涉及生物识别。
- 不做排班优化求解。 排班由人按经验定，系统负责按排班生成任务并核对执行，不替人算最优班表。
- 不替代现场判断。 系统保证的是"去没去、几点去的、看了什么、异常有没有人管"，隐患该不该报、怎么处置，仍然是人的判断。
- 不承诺效果。 上线后能确定拿到的是三样东西：查得到、追得回、对得上——每天的巡更记录查得到，漏巡和异常追得回，外包结算的账对得上。
如果你们园区现在还在用签到卡，不妨先从一条路线、二十个点位起步，跑两周再决定要不要铺开。做小做对比一次全铺开更容易成。