痛点：检查表签满了，却说不清哪一具灭火器漏了
先说三个几乎每栋楼都会出现的场景。
场景一：检查卡。 灭火器挂钩上挂着一张卡片，每月划一个勾、签一个名。年底一看，三月的勾和六月的字迹一模一样；压力表指针早就掉进红区，卡片上照旧写着"正常"。卡片能证明有人写过字，证明不了有人真的看过。
场景二：维保报告在文件夹里。 消防设施每年请维保单位来一次，来完给一份报告，塞进柜子。等到有人问"这台报警主机上次检测是哪天、结论是什么、提的整改项做完了没有"，只能翻柜子，翻不到就打电话问。
场景三：检查发现的问题悬在半路。 巡检时看到消火栓箱门变形、水带发霉，在群里说了一句，有人回"收到"。一个月后再看，还是那样——没人在系统里记它，就没有人去关它。
这三件事指向同一个缺口：消防设施管理真正要回答的，不是"有没有检查"，而是四件事能不能一句话查到——这栋楼里共有多少具灭火器、分别在哪；这一件这个月该检了没有；检出来的毛病谁在跟、跟到哪一步；这台设备的年检和维保下次什么时候到期。
注意，这跟车间里的设备点检是两套不同的东西。设备点检管的是"这台机器今天运转正常不正常"（对象是生产设备，目的是防停线），消防设施管理管的是"这件器材/这套系统还在不在有效状态"（对象是安全设施，目的是合规与可用）。点检这套方法论本身是通用的，本篇不重复讲点检表怎么写——那部分可以看 设备点检巡检：把例行检查变成可追溯的记录 与 设备点检表怎么做？模板字段与执行要点 两篇。这里要讲的是消防这个场景特有的三件事：台账颗粒度、有效期、隐患必须关掉。
消防设施模块同样是构建器可以直接交付的形态：业务数据（台账与记录）+ 管理页面（台账、待检清单、隐患看板）+ 流程闭环（隐患关闭审批）+ 移动端伴同（现场打勾拍照）。用一句话需求描述清楚，AI 构建器会给出数据模型与页面骨架，剩下的工作是把这几张表的关系定对。
数据怎么建：先把"一件一行"这件事定死
模块能不能用，八成取决于第一步的台账粒度。这里有一个最容易犯的错：按类型建台账——"灭火器 120 具"写成一行。这样写，后面所有功能都塌了：你没法知道哪一具到期、哪一具压力不足、哪一具换了位置。
决定一：设施台账一件一行。 灭火器的"一具"、消火栓的"一套"、报警主机的"一台"各占一行。关键字段：
- 设施编号：唯一，建议带区域前缀（如 A 栋-3F-灭火器-014），设唯一约束防重复建档。同一个对象出现两种叫法（"手提式干粉灭火器"与"干粉灭火器"）是最常见的脏数据来源。
- 设施类型：走数据字典集中维护，一次把类型列表定死——灭火器、消火栓、火灾报警主机、烟感/温感探测器、应急照明、疏散指示、防火门、喷淋头、消防水泵等。字典的好处是后面筛选、统计、按类型配检查项都有着落，具体做法见 数据字典：管好下拉选项的统一口径。
- 安装位置：区域 + 点位描述（楼栋/楼层/房间或走廊段），最好引用已有的部门或区域档案，让"B 栋二楼东侧"在全系统只有一种写法。
- 规格与时间：规格型号、出厂日期、投用日期、有效期或下次检测日期——消防场景的到期管理全靠这个字段，不能省。
- 责任落点：责任部门、责任人（岗位）；一件设施没有人认领，它就会长期处于"没人管但也没人报"的状态。
- 状态：在用、停用、送修、待更换、报废，走数据字典固定几态，别让各部门自己发挥。
决定二：检查项模板（应做）与检查记录（实际）拆两张表。 模板表按设施类型定义"这类东西每次要看哪几项"：灭火器看压力表指针位置、瓶体锈蚀、铅封是否完好、放置位置是否被遮挡、挂钩是否牢固；消火栓看箱门、水带、水枪、阀门、水压；应急照明看指示灯、切换试验、电池时长。记录表一次检查一行（设施引用、检查时间、检查人、所属计划），逐项结果挂在明细子表里，一项一行。模板改了不影响历史记录——这是拆表的意义，别把检查项塞进 JSON 字段或者干脆做成几个固定列。
决定三：周期与提醒不内置法定数值。 检查频次、提前提醒天数、检测有效期这些参数，不同地区、不同建筑性质、不同企业制度都可能不一样。系统里把它做成可配置字段（周期、提前提醒天数、责任岗位），初始值由企业按属地主管部门要求与企业制度确认后录入，正文与模板里都不预置具体天数。
决定四：异常单独立主表，不做成"备注"。 检查发现压力不足、铅封断裂、过期、损坏，这不是一条记录的备注，而是一张需要有人负责关掉的单子：隐患单（描述、发现时间、发现人、关联设施、风险等级、处置方式：现场处理/报修/更换/报废），下挂处置跟进子表，每次跟进一行、只增不改，最后关闭要填整改结论与复核人。
决定五：所有记录只增不改。 检查记录、隐患跟进、维保记录一旦提交就不覆盖，改错的方式是"作废另起一行并注明原因"。这条约定看起来小题大做，但它决定了年底能不能向检查方解释清楚"这条记录为什么变过"。## 页面怎么用：四种角色，四个入口
同一套数据，不同的人只该看到自己那一段。落地时按角色分页面，比做一个"什么都有"的大页面有效得多。
安全管理员（PC 端，主战场）
- 设施台账页：列表按类型、区域、状态、到期区间筛选；把"已过有效期""即将到期"做成可筛的视图，让隐患设施自己浮上来，而不是靠人一页页翻。
- 设施详情页：一件设施一页看全——基本信息、历次检查记录、挂在它名下的隐患单、维保与年检记录、附件（照片、检测报告）。这张页面的价值在于：检查方随口问"这具灭火器上次检是什么时候、换过没有"，一页就能答。
- 待检清单页：本周/本月应检多少、已检多少、还没检的是哪些、谁负责。这是整个模块最该被每天打开的页面。
- 隐患看板：未关闭隐患按风险等级和超期天数排序，能看出"哪几条挂了太久"。
岗位检查人（手机端，现场用）
从手机工作台的待检清单进入，点选一件设施，逐项打勾或填数值，异常项勾上后必须填缺陷描述，可以拍照上传（压力表读数、铅封、箱门损坏处）。提交后记录进系统，同时如果是异常项，隐患单自动生成。现场在手机上完成，才能消灭"回办公室补录"这个作弊入口。
维保与年检对接人
外部维保单位每次作业登记一张维保单：日期、单位名称、作业人员、作业内容、结论、附件报告、下次到期日。年检结果同样按一类记录处理。这张单子接上"下次到期日"之后，到期提醒就有数据源了。
管理者（月度看，不看细节）
按区域和设施类型的检查完成情况、不合格项分布、隐患平均关闭时长、到期未处理数量。这类报表的每个数字都要能点到明细——报表上写"完成率 92%"，点进去要看得到是哪几件没检。
自动化：四类规则把"人记得住"换成"系统跑得动"
建好表和页面，还剩一件关键的事：让重复动作自己跑。这几类规则在平台里都是现成能力，不需要写代码。
1. 定时任务生成待检清单。 按设施类型的周期设置，每天（或每周固定时点）扫描"下一个检查日落在窗口内"的设施，生成当期待检任务并派给责任岗位。这里要注意：任务生成时间要早于提醒时间，否则提醒发出去的时候清单还是空的。定时任务的配置方式见 工作流与定时任务：让重复性工作自动跑。
2. 到期与超期提醒。 每天扫三类日期——设施有效期/下次检测日、维保单的"下次到期日"、隐患单的处置时限——命中提前提醒天数的，给责任人发通知（站内信、邮件或短信通道）；已经超期的，同时抄送责任部门的负责人。提醒要发给"人"，不是发给"群"。
3. 数据流规则串起记录与隐患。 检查记录提交时，只要明细里出现不合格项，就自动生成隐患单并置为待处理状态，把设施、发现人、缺陷描述一起带过去；隐患关闭或设施状态变更为"停用/待更换"，回写设施台账的当前状态。这一步省掉的正是"发现了问题但没人建单"的断点。
4. 审批与留痕。 隐患关闭前的复核、设施停用或报废、维保费用结算，走工作流审批，谁批的、什么时候批的都有记录；台账修改、记录作废、隐患关闭这些敏感操作，在审计日志里查得到。审计日志的价值不在于追责，而在于当检查方问"这条记录为什么改过"，你能给出时间、人和原因。
移动端：让检查发生在设施前面
消防设施点检的现场性比大多数台账都强——东西挂在墙上、在楼道里、在配电间。手机上要能用三件事：领任务（本月我负责哪些设施待检）、做记录（逐项打勾、填数值、拍照）、看状态（这件设施上次什么时候检的、有没有未关闭的隐患）。
在构建器里做模块时，PC 端页面建好、发布时勾选同步移动端即可，不需要另做一套手机页面——具体流程见 移动端使用指南：工作台、模块页与手机上的 AI 构建 与 模块的测试与发布：预检、挂载菜单与移动端同步。
有一条边界要提前说清楚：现场如果网络信号不好，按当前平台能力，记录是提交到系统后才有数据的，不要把"离线填写、联网自动同步"写进承诺。稳妥做法是保留纸质记录本作为极端情况的兜底，回到有信号的地方补录，并在记录里标明"后补"，让数据本身可解释。## 上线前查什么：九条清单
模块建好不等于能交出去用。上线前逐条过一遍，这九条大多是"顺手就能改、上线后很难改"的东西。
- 台账是不是一件一行、编号唯一。 抽样 20 件核对现场：编号对不对、位置写没写清、有没有同一具灭火器被两个人各建了一次档。唯一约束要在表结构里设，不能靠人工自觉。
- 类型字典有没有一次定死。 抽一遍全部设施，看是否出现"灭火器/干粉灭火器/手提灭火器"三种叫法并存。字典混了，按类型配检查项和统计报表都会歪。
- 检查项模板按类型配齐了没有。 每类设施至少走通一次：建模板 → 生成待检任务 → 手机端提交 → 记录回到详情页。模板里要区分"必检项"和"记录项"（只看一眼 vs 必须填数值）。
- 周期与提前提醒天数确认过没有。 按企业制度与属地主管部门要求定，别照抄别人的数；不同楼龄、不同建筑性质可能不同。
- 每件设施的责任人是否落实。 待检任务派给岗位还是派给个人要想清楚：派岗位时人员调岗要有人接，派个人时离职要有人接。没有归属的任务等于漏检。
- 权限分对了没有。 谁能改台账、谁能提交记录、谁能关闭隐患、谁能看报表——用角色与权限配置，别让"所有人都是管理员"。
- 提醒通道通不通。 站内信、邮件、短信至少验证一遍收得到；只走站内信的话，现场人员可能一个月不看一次。
- 附件能传、能留。 照片大小、格式是否受限，检测报告归档后能不能按设施检索到。历史纸质档案如果不补录，至少扫描成附件挂在设施详情页上，别做逐条补录这种体力活。
- 移动端同步出来了没有。 发布预检通过后，确认手机工作台里能看到这个模块、待检清单能打开、拍照能上传。这一步没过，现场就用不起来。
之后怎么延伸：从"能查"到"好用"
台账跑稳两个月、数据干净了，再往上加，顺序建议是：
- 消防档案一页化。 把某栋楼或某个区域的设施台账、检查记录、维保与年检报告、演练记录汇总成一份可导出的档案，迎检时按栋导，不再满柜子翻。
- 与危险作业许可联动。 动火作业这类高风险作业开工前，核对作业区域的消防设施状态（有没有停用、有没有未关闭隐患），把"作业前检查"变成一条系统判断，做法可参考 危险作业许可与监护：作业票、措施确认与到期关票。
- 设施里的"设备"接进设备台账。 消防水泵、排烟风机这类本身是设备的，可以在设施台账里引用设备档案，让维修工单走设备维保那套流程，避免同一台泵在两张表里各有一套维修记录。
- 更换与报废接上资产流程。 到期的灭火器、报废的主机，走资产处置流程出库、登记，与固定资产台账的处置口径对齐。
这套方案不做什么
写清楚边界比多列几个功能更有用：
- 不做消防主机与探测器的硬件信号接入。 平台没有硬件接入能力，报警主机的火警与故障记录仍由值班人员人工登记，系统负责把这些登记结构化、可检索。
- 不替代检测与判定。 压力表指针是否合格、灭火剂是否失效、系统联动是否达标，由持证检测人员或检测机构判定，系统只记录结论、判定人和报告附件，不下判定结论。
- 不承诺"零隐患""通过验收"这类结果。 系统能保证的是：该检的有清单、检过的有记录、超期的看得见、发现的问题有人关。验收结论由主管部门给出。
- 不做原生的设施扫码识别。 现场定位设施目前靠手机端清单点选；如果希望扫二维码直接打开某件设施的记录页，需要单独评估实现方式，不在本次方案范围内。
- 不内置法定周期与法规数值。 频次、有效期、整改时限一律以属地主管部门要求和企业自身制度为准，由企业录入并在制度变化时更新。
如果设施规模不大（比如一栋自用办公楼、几十件器材），也可以只上前四张表：设施台账、检查模板、检查记录、待检清单——把"该检的有没有检"先管住，隐患单和维保记录等下一轮再加。小步上、先把数据养干净，比一次性堆满功能更容易活下来。