场景一：监理例会
输入是议程、上周纪要、监理通知单与进度照片，输出是本周决议、待办清单与需业主协调的事项。复核人是总监理工程师或项目总工，重点核对决议是否越权、待办是否有责任人和完成时限。怎么复核按这个顺序走。
场景二：安全专题会
输入是隐患台账、整改回复单与近期事故通报，输出是新增风险清单与责任分工。这类会议结论敏感，必须由安全总监确认后才能下发；系统只能把讨论整理成条目，不能替会议定性。这是它的能力边界。
场景三：日常巡检
输入是检查表、点位清单与现场照片，输出是问题条目、部位描述与初判等级。复核人是安全员或专业工程师，照片必须带部位与时间，否则条目无法回溯，整改时只能重新跑现场。照片怎么拍直接决定可用性。
场景四五：检查与复查
专项检查输入方案与评分表，输出得分项与扣分依据；整改复查输入原问题编号与整改照片，输出关闭或退回的结论。复查最容易走过场，必须由原检查人确认关闭，不能由被检方自行勾选。边界是关闭权不转移。
别用最顺的场景验收
选试点场景时，团队容易挑最顺的一个：点位固定、人员配合、问题不多。这样跑出来的结果好看，却验不出系统在复杂场景下的短板。建议试点场景里至少包含一个历史返工多的场景，例如整改复查或专项检查，跑通之后扩到其余场景，结论才站得住。
适用与不适用
适合谁
- 每周固定开例会、巡检点位明确的房建项目
- 正在推行安全管理标准化的施工企业
- 需要把会议与检查纳入同一台账的单位
不适合谁
- 会议无议程、巡检无检查表的项目部
- 希望系统直接判定隐患等级并出具整改单的企业
典型场景
某住宅项目先把日常巡检做成单场景：安全员按点位清单拍照，系统按检查表生成问题条目与部位描述，安全员逐条确认等级后开出整改单。跑顺一个月后，才把监理例会接入，用同一套编号规则串联会议决议与整改事项，避免两套台账并行。
可执行步骤
- 按会议与巡检列出五个场景，逐个写明输入材料、输出物与复核责任人
- 优先选一个点位固定、结构清晰的场景做试点，例如日常巡检或临电检查
- 为每个场景固定输入模板与文件命名规则，减少临时文件格式带来的返工
- 输出的条目采用统一编号规则，使会议决议与巡检问题可以互相引用追溯
- 按月统计各场景的产出量、闭环率与返工情况，据此决定下一个扩展场景
常见坑
- 五个场景同时上线，每个都只做到半成品，最后没有一个能进入日常使用，团队也失去信心。
- 会议纪要与巡检记录各用一套编号，同一个问题出现两个身份，无法合并统计与追责，资料员每天要在两处对账。
- 巡检照片只拍问题不拍部位，整改回复时对不上原位置，复查只能凭检查人回忆，效率极低。
- 复查由被检方自行勾选关闭，未整改项在系统里显示已完成，日常检查几乎形同虚设，真实风险被掩盖。
自检与验收清单
- 五个场景的输入材料、输出物与复核人是否写明
- 是否只选一个场景先行试点，跑顺之后再逐步扩展
- 各场景的输出条目是否使用同一套编号规则并留档
- 巡检问题是否包含部位描述、照片编号与检查项
- 复查关闭结论是否由原检查人确认，而非被检方勾选
常见问题
五个场景必须都做吗？
不必。多数项目先做一到两个，跑顺再扩。同时铺开会让人手与校对跟不上，输出的草稿没人复核，反而积累错误记录，后期清理成本比重新做还高，也消耗管理层信任。
专项检查与日常巡检能合并吗？
可以共用问题库与编号规则，但不建议共用检查表。日常巡检按点位走，专项检查按方案评分，字段与判定标准不同，硬合并会让两类数据都无法用于统计，最后还得拆开。
会议录音要不要保留？
建议保留一段时间并写进管理办法，便于争议时回溯；保留期限、访问权限与销毁方式要事先约定。涉及个人信息的内容应限制访问范围，不宜长期无差别留存。