# 安洁物业安全生产巡查巡检：竞赛验证与答辩设计

日期：2026年10月22日。

定位：为本次园区“AI＋政务”业务知识本体技能竞赛设计讲解、规则演示、应用验证和答辩方式。总场景覆盖安全巡查巡检全流程，以六类场景、18项拟建岗位任务、16类业务来源和14类本体概念组组织方案；首批深入通道与应急照明事项，相关工单按条件接入。

**方案包括业务场景、本体框架、对象属性与交互原型。[规则演练](../deepening.html#sandbox)以12个固定样本展示状态、材料、范围与授权的判断逻辑。AI接入、独立业务标注与岗位效果评测属于实施和验收内容；规则演练结果不作为模型实测效果或业务标准答案。**

## 1. 参赛范围怎样讲清楚

建议开场表达：

> 我们研究的是安洁物业一次安全巡查怎样有依据地完成：先明确对象和应查内容，再记录现场发现；发现问题后关联工单、组织处置，随后按具体问题核对材料、由授权岗位复核，并把未决事项带入后续复查。首批深入通道和应急照明，工单管理中的相关业务作为发现、处置、证据和协同来源接入同一条主线。

这一说明既保留安全巡查全流程，也明确最初实施的对象范围。不要把16个模块讲成16个参赛主题，或宣称已经接通16个生产接口。

| 接入层次 | 模块 | 在同一主线中的作用 | 进入演示的条件 |
|---|---|---|---|
| 核心入口与处置 | 项目自检、运营巡检、品质检查、巡更打点、设备档案与巡检、公区报修 | 组织任务、产生发现、承接处置、提供整改与复核记录 | 有明确来源、范围、原状态及对象关系。设备实际台账和专业要求单独确认 |
| 处置与计划协同 | 室内报修、建议与投诉、值班日志、年度/月度计划、大项改造、业主拜访 | 补充安全线索，承接交接、长期整改和必要沟通 | 与具体安全对象或问题有关，且职责、处理边界可说明 |
| 知识与治理支撑 | 工作汇报、共享管理、处罚管理、住户表扬 | 汇总已核事实，维护知识，提供履责与经验反馈 | 不将汇报替代原证据；处罚按人工制度与权限处理；表扬和品质优秀项分别建模 |

每项接入都标明关系来自何处：源系统明确关联、人工确认关联、AI候选关联或设计演练关联。独立的现场案例分别展示；完整演练链不冒称同一宗真实工单已经贯通。

## 2. 20分钟讲解：先全业务，再展示知识如何培育

正式通知给出20分钟现场路演及30%／40%／30%的评价权重。下表是内部排练方案，时间分配不是组委会硬性规定；最新赛程、问答是否占用时长以正式补充通知确认。

| 时间 | 讲解主题 | 屏幕应实际展示什么 | 评委应理解什么 |
|---|---|---|---|
| 00:00—03:00 | 一次安全巡查的完整任务 | 巡前→巡中→转单→处置→材料→复核→复查；显示通道/应急照明范围，选三个不同类型的工单入口作例子 | 我们解决哪一项实际业务，各岗位怎样接续，为什么需要源记录和问题事项分开 |
| 03:00—06:00 | 本体怎样表达业务 | 一页框架图；点击任务、问题、工单、待证明事实、复核事件；用复合描述说明关系与属性 | 本体表达对象身份、适用条件和关系，不只是画业务流程 |
| 06:00—11:00 | 一条知识的培育过程 | 经脱敏的原文摘录、来源版本、完整语义切片、AI候选示例、人工纠正、最终规则卡及测试输入 | 条件、例外和适用范围怎样被保留；错误为何修正；谁负责发布 |
| 11:00—14:00 | 知识怎样更新与复用 | 演练版本变更；明确历史任务和新任务分别使用什么；列出受影响清单和应重跑的测试 | 有维护机制；规则变化不会静默覆盖历史事实；复用依赖明确条件 |
| 14:00—18:00 | 贯通业务的应用推演 | 七步交互与实际运行的确定性规则演示；改变材料、源状态或人工事件，观察三类状态及下一步怎样变化 | 设计规则怎样计算，为什么材料覆盖和人工结论分别保留；该演示尚非AI分析 |
| 18:00—20:00 | 验证与实施边界 | 展示已通过的12个固定样本＋19项边界断言；再展示六岗位业务验收、三种方法对照及尚待标注和实测的部分 | 代码一致性测试已经完成；业务正确性、模型效果和真实增效仍需分别验证 |

知识建设共8分钟，以《项目经理巡检工作任务》表演示“从一张真实工作表培育可执行知识”：纠正A列语义、识别任务组和检查项、区分经理核查频率与专业作业频率、把残句和待确认月份送入审核。再用“结束整改允许存在未完项但须填原因”展示跨工单流程规则。避免连续念出所有模块和所有节点。

当前应分别使用“交互说明”“规则演练输入”“确定性规则实际计算结果”。尚未实现的模型能力仍标为拟建；只有模型接入并实际运行后，才使用“模型输出”。演示前保存实际规则计算，后续模型阶段再保存真实检索和人工修改记录。预录结果或录屏须标为演示备份。

## 3. 列表、检索问答与业务本体分别增加什么

这三种方式可以互补。结构化列表适合按明确字段查找和统计；检索问答适合从材料中定位依据并解释文字；业务本体适合显式维护对象身份、跨记录关系、适用条件和事件范围。能力取决于数据、实现和校验，不能由技术名称直接推出准确率。

| 真实业务问题 | 传统列表／关键词检索能够做什么 | 检索问答能够增加什么 | 本体及经审核规则拟增加什么 | 本例仍需人员确认 |
|---|---|---|---|---|
| 临芳三区：6/6已整改、A级，仍待验收且有两次位置退回 | 找到原单、历次提交和退回文字；按状态筛出待验收 | 汇总“什么时候退回、理由是什么”，定位相关说明 | 显式分开源状态、材料覆盖、人工复核；将意见限定到问题、对象和轮次 | 当前材料实际对应哪个对象、其支持范围及专业适用依据 |
| 澄泮：一条描述含通道自行车与多处应急指示灯不亮 | 找到含关键词的原记录及附件 | 理解复合句并提出拆分候选 | 保留一条源记录、两个问题族与未明确的灯具范围；逐项关联措施和证据，不猜数量 | 拆分是否符合实际处置边界，具体灯具清单是什么 |
| 金益二村：“巡检位置”内容实际为五项客服工作 | 直接查看字段原文，按名称检索计划 | 解释这些词表示工作事项而非地点 | 将源字段与本体概念分开映射，按内容筛选安全范围，防止进入安全点位分母 | 混合事项中的具体安全内容及项目适用范围 |
| 管理项目下包含不同名称的真实空间 | 按项目过滤或人工查找空间字段 | 概括管理范围与地点名称 | 分别建管理项目、物理空间及“管理”关系，避免由名称推出地理或产权关系 | 对象与空间映射是否已由业务确认 |
| 巡更存在离线采集与稍后上传 | 查看源系统完成状态、采集及提交记录 | 解释手册缓存和上传条件 | 在已确认规则下区分采集时间、提交时间、源系统接收事实与有效记录；保留不能判断的现场事实 | 安洁当前配置、是否实际接收、审批例外及现场情况 |
| 项目经理每周核查的12类区域中，含每日、每月、每年等专业要求 | 按原表查看经理周任务及对应检查文字 | 从长段内容提取不同频率和对象 | 分别保存经理核查频率、被核记录周期、专业执行频率，按相应时间范围查证据 | 表格正式版本、专业要求适用性、经理任务当前平台映射 |

不能将“普通检索一定不会拆分问题”“问答一定无法使用结构化信息”作为论据。问答可以调用结构化查询，列表也可以增加关联字段。本体的价值应在保持业务定义一致、减少重复解释和形成可追溯约束上验证；实现可以采用关系表，不以图数据库作为必要条件。

### 3.1 可比实验设计

| 配置 | 提供给操作人员或系统的能力 | 应固定的条件 |
|---|---|---|
| A 列表与关键词 | 同一批源记录、原文、附件索引；搜索、筛选与人工核对 | 同一案例范围、相同字段可见性、同等业务权限 |
| B 检索问答 | A的相同材料，加文档检索与同一模型进行问答 | 模型版本、资料版本、提问集合、输入预算及输出要求 |
| C 本体辅助 | B基础上提供经确认的对象关系、任务版本、问题—工单—证据关系及审核规则查询 | 不能额外添加A/B无法取得的业务事实；新增结构和规则本身必须明确列示 |

对“本体本身”的技术收益需要更谨慎：C同时增加关系和规则，效果不能全部归于本体。条件允许时在同一应用内部关闭规则或关系查询，作受控消融，不必另建多套系统。结构化规则可同时提供给B的工具查询作为进一步公平对照。

业务人员对案例进行盲评，记录漏项、误补件、依据错误和总工时。按案例家族划分开发与留出集，同一原单的近似改写和相邻轮次不跨组。记录首次结果与纠正结果，不只挑选最好的一次输出。

### 3.2 项目经理任务表：知识培育演示

《项目经理巡检工作任务》工作表包含37行（含表头）、36行工作内容和7个调度组。A列表头虽为“任务状态”，实际写每天、每周、每月等频率与按项目/小区合并任务规则；B列“巡检位置”混合工作项与区域。不能把36行当成36个物理点位，也不能将A列映射成“未开始／已完成”等状态枚举。

| 原始位置与事实 | 演示中的错误AI候选 | 业务修正应说明什么 | 拟保留的本体或规则结果 |
|---|---|---|---|
| A列调度文字及B列混合内容 | “36行就是36个位置，A列表示执行状态” | 原表描述的是7组任务生成安排；组内条目有工作项、区域和复合要求 | 调度规则、合并范围、任务组、检查项、物理空间分别保存；源表头保留 |
| 每周组共12类区域，内容中出现每日巡查、月度试机/记录、年度疏通等 | “经理每周查，所以所有专业工作都是每周执行” | 经理本次核查的是不同周期事项是否有适用记录，专业作业频率不随经理检查频率改变 | `经理核查周期`、`证据覆盖周期`、`专业执行周期`分别建模，不互相覆盖 |
| A28“每半年，6月、1月（合并1个任务）” | “自动改为6月、12月，或改为7月、1月” | 原文需要确认是固定月份还是半年间隔；不能替业务方纠正月份 | 保存原文，标记调度解释待确认，暂不发布自动任务生成规则 |
| C18含“垃圾点位每周冲洗不”残句 | “自动补全为每周冲洗不少于某次” | 缺少的数量或条件无法从原文恢复；需原编制人员补充 | 原文可查、残句待修订；不得生成完整强制频次或次数 |
| C13出现电梯相关次数、到达时间和比例等数值 | “这些数字就是通用法规要求” | 仅能证明工作表有这些文字；须确认依据、版本及适用范围，不能默认其为法规 | 表格业务要求候选与正式专业依据分层；审核前不用于专业合格判定 |

可以让评委直接问：“经理每周检查消控室，月度试机记录要按周补做吗？”设计期望回答是：先说明经理核查周期与月度专业事项周期不同，核对本次适用月份的记录；具体试机要求须有已审核依据。该回答的来源、对象和时间条件都能在图上找到。

岗位任务表、项目计划、生成任务和执行记录分别管理，按具体项目建立有依据的对应关系。岗位职责和专业授权独立于账号可见功能；配置项数量不直接换算为物理对象数量。

## 4. 六个岗位的验收问题与有条件指标

指标先定义“谁在什么范围完成了什么判断”，再定义分子分母。下列目标均为待测方案，当前不填正确率、提效百分比、节省人数或金额。

| 岗位与验收问题 | 可观察输出 | 指标及分母 | 指标成立的条件 |
|---|---|---|---|
| 巡查人员：我这一次应该检查哪些对象、按哪版要求、怎样记录？经理每周核查是否改变专业作业周期？ | 本次检查卡，含对象、任务窗口、检查项、来源与未知条件，区分核查周期和专业执行周期 | 适用检查项匹配正确数／人工确认适用项数；另计无依据新增项及频率串用数 | 取得真实任务快照与经审核检查要求；不同项目和周期分别测试 |
| 项目负责人：发现的问题应关联哪份工单、由谁推进、目前卡在哪里？ | 问题—工单关联、责任候选及待协调清单 | 已确认正确关联数／所建议关联数；已确认应关联事项中的漏联数；未决原因说明正确数／可确定原因事项数 | 人工明确事项身份、职责和处理范围；候选关联不纳入已确认统计 |
| 维修／处置人员：我应处理哪一项，需要交回什么事实和材料？ | 逐项处置与材料清单、未完原因及下一步 | 必要处置/取证项覆盖数／人工确认必要项数；不必要补件数；完成材料整理总工时 | 材料要求和专业边界已审核；不得以多要求拍照提高表面完整率 |
| 品质／授权复核人员：材料支持到哪一步，什么还不能确认？ | 分项证据矩阵与带范围的复核草稿 | 应发现缺口的漏报数；误报缺口数；无依据肯定结论数；有效引用数／用于结论的引用数 | 独立业务人员标注参考结果；未知与冲突样本占有明确比例；专业合格与材料覆盖分别评估 |
| 值班／交接人员：哪些未决事项必须接续，责任与下一步是否清楚？ | 交接清单，含问题、临时措施、阻塞、下一步、承接岗位 | 交接遗漏数／人工确认应交接事项数；过期或重复无效事项数 | 明确交接时点与范围、源记录完整性和有效例外；待办页不被默认视为全量台账 |
| 知识维护／审核人员：这条规则从哪里来，改动影响哪些任务和核验？ | 原文、候选、修订理由、发布版本、影响清单和回归记录 | 来源可定位规则数／发布规则数；应受影响对象漏报数；不应受影响对象误报数 | 有发布审核记录、历史任务版本和影响参考答案；演练规则与正式规则分开 |

总工时比较应包括巡前查找、现场记录整理、工单关联、补正、复核、交接以及知识维护与纠错新增负担。净工时减少先报告增效；只有真实成本发生变化并扣除新增投入，才讨论现金降本。

确定性规则实现验证：12个设计样本全部符合约定输出，另有19项边界与兼容性断言通过，包括原始输入不变、材料不足不撤销人工结论、批准无法巡检不计完成及浏览器／Node输出一致。通过这些测试只说明实现符合当前设计约定，不代表专业业务正确率、AI准确率或上线表现已验证。

## 5. 12个可执行规则演示样本

### 5.1 状态与输入约定

下列样本是供实现人员编码的固定测试夹具，使用虚构的演练对象和材料编号。案例结构来自真实业务资料，数值、对象映射和材料覆盖由本文件明确设定；未使用生产单号、个人信息或实际照片判断。

固定输出合同：

```text
source_status       原单状态原样保留，不由AI覆盖
scope_status        纳入安全 / 范围外 / 待确认
execution_status    应检执行状态；与安全结论独立，可为不适用
issue_status        待确认 / 待处置 / 待协同 / 待补材料 / 待复核 / 限定范围复核通过 / 无问题事项
evidence_status     未核验 / 覆盖不足 / 有冲突 / 已覆盖已审核要求 / 依据待确认 / 不适用
human_review_status 未复核 / 待复核 / 退回补正 / 指定范围已通过 / 授权或范围待核 / 不适用
required_next       一项或多项具体行动及责任岗位，不生成生产操作
basis               本次使用的规则版本、事实引用与尚未确认条件
```

演练通用规则包名为 `DEMO-R1`，状态为“设计测试专用”，不是安洁正式制度。用于自动断言时，测试运行器只在隔离环境将其设为可执行；正式发布必须取得业务审核。所有样本同时断言：未发生生产回写、未生成不存在的复核事件、未把空值补成正常或0。

材料充分的演练条件：对象/位置对应、措施回应本问题、经确认要求中的结果材料均覆盖，且属于有效轮次。这里是结构化覆盖条件，输入中的“已覆盖”来自设计夹具，不代表模型识图结果或专业判断结论。

### T01 正常巡查完成，不自动生成问题

**固定输入**：源任务“已完成”；适用任务快照含5项检查，执行记录5项均有效，记录性质均为正常；没有异常线索和待处置事项；正常记录满足本演练记录要求。

**期望状态**：`source_status=已完成`；`execution_status=本次5/5有效完成`；`issue_status=无问题事项`；`evidence_status=不适用（问题整改核验）`；`human_review_status=不适用（问题整改复核）`。正常执行记录保留，不生成5条隐患，也不输出“整个项目安全合格”。下一步为按既定安排继续巡查。

### T02 源工单已关闭，材料和复核仍为空

**固定输入**：一个已确认的应急灯问题；源报修工单状态“已关闭”，关闭原因为演练中设定的无人评价到期；对应对象明确；`DEMO-R1`要求的定位、处理、结果材料均未提供；无人工复核事件。

**期望状态**：源工单保持“已关闭”；`issue_status=待补材料`；`evidence_status=覆盖不足`；`human_review_status=未复核`。下一步列出三类具体缺口及材料准备岗位；不将该关闭事件视作安全销项，不擅自重开源工单。

**依据性质**：手册存在到期关闭机制；本例触发时间与业务内容是测试设定，不证明安洁当前采取同一配置。

### T03 已整改数量和A级不覆盖位置冲突

**固定输入**：演练品质单6/6已整改、88分A级、源状态“待验收”；6个已确认问题中5项材料满足演练要求，第6项材料的对象关联明确指向另一处灯具；无当前整改轮次的有效通过意见。

**期望状态**：三项源字段原样保留；第6项 `issue_status=待补材料`、`evidence_status=有冲突`、`human_review_status=待复核`；冲突原因为对象对应错误。其余5项可以显示待复核，不自动通过；整单不能被AI概括为“六项全部合格”。

**依据性质**：源状态并存结构取自临芳样本；第6项明确错配的输入为演练设定，不是在判定真实当前照片。

### T04 结束整改但仍等待配件，未完原因继续有效

**固定输入**：源状态“待验收”，最新源事件“结束整改”；问题尚未完成；未完原因“等待配件”，有项目负责人确认的下一步与临时措施记录；临时措施材料只支持临时控制，不支持最终功能恢复；源流程已通知品质验收。

**期望状态**：`source_status=待验收`，保留“结束整改”事件；`issue_status=待协同`；`evidence_status=覆盖不足（最终处置结果）`；`human_review_status=待复核`。保留未完原因、临时措施、承接岗位与后续时间；不删除待办、不生成最终完成结论。

**配套校验**：同样输入若将未完原因改为空，输出“缺少未完原因，需补充”，仍保留源系统已经发生的结束整改事实。该变体检验必填条件，不另计为新的业务实证案例。

### T05 复合描述拆分，不猜“多处”的数量

**固定输入**：一条源记录：“安全通道停放自行车及多处应急指示灯不亮”；没有灯具清单或编号；尚未由业务人员确认拆分；其他条件未知。

**期望状态**：`source_record_count=1`；提出2个问题族候选：通道占用、照明异常；`confirmed_issue_count=0`；`lamp_count=未知`；`issue_status=待确认`；`evidence_status=未核验`。下一步为人员确认问题边界并补清灯具范围，不把2个候选写成2个已确认设备隐患。

### T06 通道材料不能覆盖灯具功能

**固定输入**：人工已确认通道占用、灯具异常两个问题；只有一份材料，经演练标注明确支持原位置的通道清理及通行检查，不能说明灯具功能；通道项其余要求均满足；灯具项没有结果材料。

**期望状态**：通道项 `evidence_status=已覆盖已审核要求（演练）`、`issue_status=待复核`；灯具项 `evidence_status=覆盖不足`、`issue_status=待补材料`；两项均无人工通过。原单附件数为1，不把一张材料视为整单覆盖。

### T07 未审核的表格或配置文字不能成为专业肯定依据

**固定输入**：记录声称“设备正常”；检索材料含项目经理任务表C13的设备相关数值与一段技防设施比例配置；各材料的专业依据、生效时间及对本对象的适用性均未审核；没有其他有效专业要求；源任务可为已完成。

**期望状态**：源任务状态保留；`evidence_status=依据待确认`；`issue_status=待确认`；`human_review_status=未复核`。说明缺少适用依据及应由哪类业务/专业岗位确认，不套用比例、不输出专业合格或不合格，不凭本例新增强制整改要求。

### T08 当前计划更新，不静默改变已生成任务

**固定输入**：演练设备巡检任务在V1计划下生成，应检5项；当前计划已编辑为V2，未来任务应检6项；本任务持有完整V1快照，5项有效记录；无要求追溯适用的额外规则。

**期望状态**：本任务仍用V1的5项分母；`execution_status=本次5/5有效完成`；不会因当前V2新增项生成漏检或缺项。未来生成任务可用V2。输出同时显示任务版本与当前计划版本，明确差异来源。

**依据性质**：手册明确设备计划编辑不影响已生成任务。这里的5项、6项和版本号为演练值；该规则不外推为“任何新专业标准永不影响在办任务”。

### T09 历史退回后后续轮次通过，限定范围保留

**固定输入**：同一已确认问题R1轮被退回；R2轮提交新材料；该材料与对象和R2关联明确；经演练预置，R2覆盖全部已审核要求；有授权有效、明确针对该问题R2的人工通过事件。

**期望状态**：`issue_status=限定范围复核通过`；`evidence_status=已覆盖已审核要求（R2）`；`human_review_status=指定范围已通过（R2）`。保留R1退回，当前结论不被R1覆盖；不将通过扩展至整个项目、其他对象或未来时段。

**边界断言**：如果授权或意见目标不明，须转为“授权或范围待核”，不能沿用本例的通过输出。真实澄泮的任务级验收事实不自动满足本例全部专业授权条件。

### T10 项目经理工作表按语义建模，不按行数造地点

**固定输入**：使用经理任务表第一张工作表的固定设计样本，37行含表头、36行工作内容、7个调度组；每周组12类区域；A列为频率及合并安排，B列包含任务与区域；A28月份安排未澄清、C18存在残句；没有业务审核发布记录。

**期望状态**：源工作内容行数仍为36，候选调度组为7；不得输出36个物理地点、36个已执行巡检点或36项隐患。A列映射调度规则而非执行状态；每周12类区域中的专业日/月/年要求分别保留，不能统一改成每周。A28与C18的相关规则标记待确认，不发布自动排期或残句补全规则。`execution_status=不适用（配置资料）`；`issue_status=无问题事项（未提供现场发现）`；`evidence_status=不适用（尚无整改材料）`。

**结果限制**：工作表调度组、具体项目计划和任务实例分别记录。仅使用工作表的本例不推导实际执行；安全相关检查项按内容和项目范围确认，不预填风险或点位数量。

### T11 离线采集后在有效窗口上传并被接收

**固定输入**：演练任务实际开始08:00；经测试配置确认的时长60分钟，接收截止09:00；点位采集08:35、上传08:55，源系统明确接收成功；签到只证明到场，未设定具体设备检查结果。

**期望状态**：`execution_status=本点位有效到场记录`；采集和上传两个时间均保留；`evidence_status=不适用（尚无问题整改材料）`；对设备检查完成度输出“无对应检查结果”，不推导全部设备正常。依据字段记录演练时窗和接收事实。

### T12 现场采集早于截止，但超时上传未被接收

**固定输入**：与T11相同的演练任务与时窗；采集08:35、上传09:20；源系统明确拒收并保留源状态“已结束”、有效点位0/1；没有已批准的例外或补打。

**期望状态**：保留源状态与0/1；`execution_status=源系统未接收本次离线提交`；离线材料作为待核线索保存，不增加源有效完成数；`evidence_status=不适用（尚无问题整改核验）`，`human_review_status=不适用（尚无问题复核）`。下一步核对离线记录、当前规则及是否存在有效例外；员工实际到场及责任结论仍待核，不自动指认未到场、造假或应处罚。

**依据性质**：手册允许缓存后提交，也存在超时不再接受的说明；本例60分钟与拒收事件是演练设定。若实际截止规则或接收事实未知，正确输出应为“提交有效性待核”，不能复制本例拒收结论。

## 6. 实现和验收时优先检查的边界

1. **保持原单事实。** 全部12例都保留原状态、原数量及时间；应用判断只能添加自己的结果，不改写来源记录。
2. **区分三种状态。** 源工单已关、材料待补、人工未复核可以同时成立；相互之间没有无条件自动转换。
3. **正常执行有位置。** 一次正常巡查应能完成其业务流程，不要求必须生成问题或工单才算演示完成。
4. **同一材料支持范围有限。** 对象、轮次、要求或问题之一改变，应重新核对支持关系；附件存在不自动等于证据覆盖。
5. **引用不等于适用。** 要求有来源但未审核、对象不适用、版本未知，都应保留具体缺口，不默认套用。
6. **未知不等于不合格。** 无单位、无对象身份、没有可见标准或材料不完整时，输出待确认条件；不能把数据缺失当现场未做。
7. **事件时间不能合并。** 现场采集、上传、源系统接收、复核和快照时间分别保存。任务有效性与现场实际行为分别说明。
8. **补打和例外采用真实条件。** 手册写明有补打机会时可返回补打，不能统一写“所有漏点都不能补打”；具体任务权限和当前配置需核实。
9. **复核意见有目标和授权。** 一次任务级“通过”与某设备专业确认不是天然同一结论；目标不清先保留范围待核。
10. **当前验证的是设计规则实现。** 已运行测试校验规则计算、固定输入输出及关键边界；不能把确定性计算或交互切换结果统计为AI准确率。
11. **管理核查与专业执行分层。** 每周经理核查可以查看月度或年度专业事项的适用记录，不能把内嵌要求全部改写成周频率；7个调度组、36行内容与物理空间数分别统计。
12. **输入缺陷先留痕再处理。** A28固定月份安排、C18残句和C13未审核数值都保留来源与问题类型。AI可以提出问题，不静默修订原文或补造法规依据。

## 7. 答辩问题与建议回答

| 可能提问 | 建议回答重点 | 应准备的可回查材料 |
|---|---|---|
| 你们到底是做巡检，还是做验收？ | 总场景是安全巡查巡检全流程，任务、发现、工单、处置、复核与复查连续。整改证据核验是首批做深的一环 | 一页主图与七步演练，不只展示整改页面 |
| 为什么接16个模块，还算一个具体场景？ | 模块提供不同入口和协同事实，纳入条件统一为是否服务同一安全对象或问题；首批深入通道与应急照明 | 模块接入表、范围外客服工作反例、当前数据覆盖说明 |
| 原系统已经有闭环，新增价值在哪？ | 继续使用既有流转，新增一致的对象身份、逐项问题、证据支持范围、版本和责任解释；效果需对照验证 | 临芳三状态、澄泮复合描述、问题与工单关系及测试约定 |
| 检索问答也可以实现这些，为什么要本体？ | 检索问答保留使用。本体把需反复一致使用的对象关系和规则明确保存，支持查询、复核和维护；比较实验验证实际差异 | 同资料同案例的A/B/C对照设计，以及关闭关系或规则的配置说明 |
| 你们有没有真实AI输出和节约数据？ | 现有成果包括业务方案、交互说明与实际可执行的确定性规则演示，12个样本及19项边界断言已通过；模型接入、独立业务标注与实际增效评测尚未完成 | 测试报告和完成状态表，区分规则计算、拟建模型能力及真实业务成效 |
| AI将照片对应错了怎么办？ | 对象对应先是候选，材料仅支持限定事实；未知或冲突进入人工确认，正式结论保留岗位授权与引用范围 | 错位、跨问题材料、历史轮次和范围不明的测试样本 |
| 规则谁审核、更新会不会影响旧任务？ | 规则由相应业务/专业岗位审核；发布保留版本与范围。计划配置变化和专业要求变化分别处理，历史任务保留当时快照 | 原文→候选→人工修订→发布→影响清单→回归案例 |
| 计划如何推广？ | 先完成一个对象族的真实规则与完整样本，再按来源和对象条件扩展；实际接入、权限及运营维护逐项验收 | 首批标准、责任人、样本与接入清单，不以项目总数作为已覆盖规模 |

## 8. 下一阶段需要形成的验证包

第一份是来源包：经审核的短原文、版本、适用范围和使用权限。第二份是业务案例包：保留原记录、关联关系、整改轮次、材料索引和人工确认范围。第三份代码测试包已经形成：本文件12例已转成可机器读取的输入与断言，配套规则引擎、测试脚本及实际运行报告，并保留“设计样本”标签。后续重点是补齐业务审核与独立评测资料。

之后由未参与调试的业务人员确认或改写参考结果，记录分歧和修订理由，才形成业务评测基线；另取得留出案例，避免全部验证都围绕规则开发用例展开。模型运行后保存实际输入、检索引用、规则结果、输出、人工修订、时长与成本记录。

交付状态按已有原始来源、已完成设计、已实现待业务验证、已通过指定范围验证分别管理，明确能力范围与验收依据。

## 9. 资料来源与适用口径

- [竞赛评价要求](competition-rubric.txt)：业务场景、本体与知识建设、应用价值及路演要求。
- [安全生产巡查巡检方案](proposal.md)：全流程、六类场景、16类业务来源及问题、材料、复核关系。
- 平台品质检查和项目巡检业务记录：临芳苑三区的位置退回与待验收、澄泮的复合描述与验收事件、客服工作事项及项目配置差异。各案例按来源和范围独立使用。
- [规则演练](../deepening.html#sandbox)：12个固定样本展示业务约束及条件变化，不作为AI实测或业务参考答案。
- 《项目经理巡检工作任务》“综合巡检区域列表”A1:C37：调度组、工作事项、区域类型、专业周期和资料要求，相关内容见[项目经理任务解析](manager-analysis.md)。原表要求按版本、项目和专业依据确认适用性。
- 《红石榴物管平台运营管理使用手册》：巡更时长与离线上传、补打条件、评级和计划版本、未完原因及品质验收等流程，相关条件见[业务流程规则](workflow-rules.md)。

平台操作说明用于解释办理流程，岗位材料用于说明工作要求，专业判断采用经确认且适用于具体对象的有效依据。来源类型、适用条件与版本分别保存，不将任一资料直接推广为所有项目的统一安全标准。
