← Back to skills
extension
Category: OtherAPI key requirement unconfirmed

消防检测报告核查

逐项核查建筑消防设施检测报告的合规性与可用性:机构从业条件、报告必备要素、不合格项分级、判定结论逻辑、整改闭环与有效期。输出可直接提交的核查意见表。

personAuthor: u_71222164hubenterprise

消防检测报告核查(fire-inspection-check)

一份检测报告能不能拿去备案、能不能扛住消防监督检查,看四件事:谁出的、写全了没有、不合格项怎么定的、整改闭环有没有。

这个技能做四件事:查要素 → 定分级 → 判结论 → 出整改意见。


硬边界(先看这条)

| 能做 | 不能做 | |---|---| | 核查报告要素是否齐全 | ❌ 代替检测机构出具检测结论 | | 对照规范列出应检项目 | ❌ 认定某设施"实际合格" | | 对不合格项做 A/B/C 分级 | ❌ 代替消防设施维护保养与现场处置 | | 输出整改意见与复检建议 | ❌ 保证通过消防监督检查 | | 提示有效期与复检时间 | ❌ 出具设计、施工或验收文件 |

遇到以下情况,务必转交具备从业条件的消防技术服务机构或当地消防救援机构:

  • 报告涉及的人员密集场所、易燃易爆场所、超高层或大型综合体
  • 存在 A 类不合格项且未整改
  • 报告被用于消防验收、开业前检查等行政程序
  • 现场实际情况与报告描述明显不符

永远不要为了让报告"看起来合格"而建议修改、删减不合格项记录。 A 类项漏报在后续检查中会被直接认定为虚假报告。


一、什么时候用这个技能

| 用户这样说 | 就用 | |---|---| | "这份消防检测报告合格吗,能备案吗" | ✅ | | "帮我看看检测报告缺什么" | ✅ | | "检测机构有没有资质 / 从业条件够不够" | ✅ | | "不合格项这么多,哪些必须先改" | ✅ | | "检测报告下个月到期,什么时候复检" | ✅ | | "维保单位给的报告被消防队退回来了" | ✅ | | "我要自己做检测" | ❌ 需具备从业条件的机构实施 |


二、完整工作流

第 1 步  拿到报告与基础信息(机构、项目、日期、建筑情况)
第 2 步  先读规则文件 rules/report_elements.md 与 rules/defect_grading.md
第 3 步  跑核查脚本
    python scripts/fire_check.py --file 报告.txt --as-of 2026-10-08
第 4 步  逐项人工确认(脚本只做关键词匹配,不做工程判断)
第 5 步  按 templates/核查意见表.md 输出四段式结论

三、报告必备要素(缺一项就可能被退)

rules/report_elements.md 里有完整清单,核心 12 项:

| # | 要素 | 缺了会怎样 | |---|---|---| | 1 | 机构名称(全称,与从业条件公示一致) | 无法核实主体,直接退 | | 2 | 项目负责人与检测人员签字 | 报告无效 | | 3 | 检测日期与报告编号 | 无法追溯与判定有效期 | | 4 | 建筑名称、地址、使用性质 | 无法判定适用规范 | | 5 | 建筑面积、层数、高度 | 无法核对抽检比例 | | 6 | 检测范围与系统清单 | 漏项无法发现 | | 7 | 依据标准(含代号与年代号) | 判定依据不成立 | | 8 | 主要检测仪器设备 | 数据可信度存疑 | | 9 | 各系统检测记录(逐项) | 核心内容缺失 | | 10 | 不合格项清单与分级 | 无法判定整改优先级 | | 11 | 综合判定结论 | 报告不完整 | | 12 | 整改建议与复检要求 | 闭环断掉 |

特别注意:年代号。写「GB 50116」不写年代号,或沿用已废止版本,是退回的高频原因。


四、八类应检系统(对照看有没有漏)

| 系统 | 常见漏检点 | |---|---| | 火灾自动报警系统 | 探测器抽检比例、联动逻辑、主备电切换、接地 | | 自动喷水灭火系统 | 末端试水、报警阀组、水流指示器、稳压装置 | | 消火栓系统 | 静压/动压、充实水柱、栓口方向、水泵接合器 | | 防排烟系统 | 风机启动、风量风速、正压送风余压、防火阀联动 | | 应急照明与疏散指示 | 照度、持续供电时间、方向正确性 | | 消防电源与配电 | 双电源切换、末端切换、线路防火保护 | | 灭火器配置 | 类型匹配、级别、数量、压力、有效期、放置点 | | 防火分隔与疏散 | 防火门闭门顺序、防火卷帘下降、疏散通道占用 |


五、不合格项分级(A/B/C)

规则全文在 rules/defect_grading.md,判定口径:

| 等级 | 含义 | 处置 | |---|---|---| | A 类 | 系统整体失效或关键功能丧失 | 立即整改,整改前该场所不具备消防安全条件 | | B 类 | 局部功能缺陷,影响可靠性 | 限期整改(通常 30 日内) | | C 类 | 一般性缺陷,不影响主要功能 | 结合维保计划整改(通常 90 日内) |

脚本按关键词分级,工程判断必须人工复核。 同一句话里同时出现多个缺陷时,按最高等级记。


六、脚本用法

python scripts/fire_check.py --file "D:\报告\某某大厦检测报告.txt" --as-of 2026-10-08

| 参数 | 说明 | |---|---| | --file | 必填。报告文本(.txt / .md,支持从 PDF 复制出来的纯文本) | | --as-of | 核查基准日,默认今天,用于算有效期 | | --out | 报告输出路径,默认打到屏幕 | | --format | md(默认)或 json | | --selftest | 跑内置样例自检 |

脚本做四件事:

  1. 要素扫描:12 项必备要素逐项查有没有
  2. 系统覆盖:八类系统逐项查报告里提没提
  3. 缺陷抽取与分级:按 A/B/C 关键词库抽不合格项并分级
  4. 有效期与复检:从检测日期推算有效期(通常 12 个月)与建议复检窗口

⚠️ 脚本只做关键词匹配,不代表工程判断。标"命中"不等于这一项真的做了。


七、人工确认(这步不能省)

  • [ ] 机构名称与公示的从业条件信息是否对得上
  • [ ] 报告里的建筑面积、层数是否与现场一致
  • [ ] 抽检比例是否符合该建筑规模的要求
  • [ ] 不合格项是否被分级,还是混在一起写"已整改"
  • [ ] 整改建议是否对应到具体部位,而不是泛泛写"加强管理"
  • [ ] 判定结论与不合格项是否自洽(有 A 类项却写"合格"是重大异常)

三类高频异常,见到就退回:

| 异常 | 表现 | 后果 | |---|---|---| | 结论与内容打架 | 列了 A 类项仍写"合格" | 报告不可用 | | 整份报告零不合格项 | 老旧建筑却一项问题都没有 | 高度怀疑未实检 | | 整改项写"已整改" | 无复检记录、无照片、无日期 | 闭环不成立 |


八、输出结构(固定四段)

  1. 能不能用 —— 结论先行:可用 / 需补正 / 不可用
  2. 要素核查表 —— 12 项逐项标有/缺/存疑
  3. 不合格项分级表 —— 等级、部位、描述、整改期限
  4. 整改与复检建议 —— 先后顺序、复检时间窗口、留存材料

九、最常见的坑

坑一:把"维保记录"当"检测报告"。 两者不是一回事。维保记录是周期性维护的凭证,检测报告是对整体系统状态的年度判定。备案、检查要的是后者。

坑二:只看结论页。 结论页写"合格"不代表可用。要素缺 3 项、八类系统只检了 4 类,结论照样能印。要翻到记录页。

坑三:忽略年代号。 依据标准只写代号不写年代号,或用已废止版本,是最容易在形式审查阶段被退的原因。

坑四:整改闭环只写一句话。 "已整改"三个字没有复检日期、没有复检人、没有前后对比,等于没闭环。

坑五:有效期算错。 从检测日期起算,不是从报告出具日期、也不是从拿到手那天算。差一个月就可能过期。

坑六:同一份报告多处复用。 不同建筑、不同层数的报告,系统清单和抽检比例不可能完全一致,模板套用会露出破绽。


十、边界与免责

  • 本技能不代替具备从业条件的消防技术服务机构出具的正式检测结论
  • 分级规则与期限口径可能因地区、建筑类型、适用规范版本而不同,以现行规范和当地消防救援机构要求为准
  • 不得用于修改、删减、伪造检测记录或报告
  • 涉及重大火灾隐患时,应立即向消防救援机构报告,不以核查报告替代现场处置

十一、许可

本技能由 刘天宝|墨燊 原创,采用 Apache License 2.0。

rules/ 中的核查要点为工程实践方法论整理,不构成正式检测结论;使用前请核对现行国家标准(如 GB 50116、GB 50084、GB 50974、GB 51251 等)及当地消防救援机构的具体要求。