严格基于指定城管住建相关文件（核心为《06行业应用系统功能设计-01城管住建.docx》，简称《06-01城管》；《01智慧城市一网统管平台-系统总体架构及其功能要点-20251018修订.docx》，简称《01总体架构》；《03智慧城市一网统管平台-系统数据库表.docx》，简称《03数据库表》），聚焦市政设施、市容秩序、违建处置、环境卫生四大核心场景，拆解传统治理痛点及对应功能需求，所有分析均来自指定文件，不涉及外部信息。

一、需求分析前置：城管住建的“文件定位”

《01总体架构》2.3节“业务领域17+应用场景”明确，城管住建是城市治理的“核心基础领域”，承担“市政设施维护、市容秩序管控、违建治理、环境卫生保障”四大职责，需解决传统治理“碎片化、响应慢、数据不通”痛点（《01总体架构》P15）；《06-01城管》开篇进一步细化，明确城管住建需覆盖11类设施、5类秩序场景，所有功能需求均需适配《03数据库表》的“城管专属表结构”（如sys_urban_fac市政设施表、biz_urban_event城管事件表）。

二、核心场景1：市政设施管理——解决“设施碎片化、监测滞后”痛点

2.1 传统治理痛点（文件原文提炼）

《06-01城管》3.2节“市政设施监测”明确传统市政设施管理存在三大痛点，直接影响设施维护效率：

1. 数据割裂，归属不清：

   • 道路、桥梁、燃气管网等11类设施数据分散存储（如道路数据存“市政系统”、管网数据存“水务系统”），无统一台账（《06-01城管》P32）；

   • 对应《03数据库表》：传统模式下无sys_urban_fac（城管设施基础表），设施数据分散在gen_road_fac_mon（道路监测）、gen_bridge_fac_mon（桥梁监测）等独立表，无法跨设施类型关联查询。

2. 状态监测滞后，故障发现难：

   • 依赖人工巡查发现设施故障（如路灯不亮、井盖缺失），平均发现周期超24小时，故障处置滞后（《06-01城管》P33）；

   • 无物联网设备联动（如路灯传感器、井盖定位器），无法实时获取设施状态（《05智慧城市一网统管平台 数据中枢系统功能设计.docx》，简称《05数据中枢》20.7节“设备管理”缺失对接）。

3. 维护协同弱，处置效率低：

   • 设施维护需跨部门协调（如道路修复需市政部门、交通部门临时封路），无统一调度机制，处置时长超48小时（《01总体架构》P11）；

   • 对应《03数据库表》：无rel_fac_dept（设施-部门关联表），无法快速定位责任部门。

2.2 核心功能需求（基于痛点的解决方案）

结合《06-01城管》3.2节“市政设施监测”功能描述，需落地三大核心需求：

1. 设施统一台账管理：

   • 需求目标：建立全类型设施统一台账，覆盖道路、桥梁、管网等11类设施，支持“新增/编辑/查询/删除”；

   • 文件支撑：基于《03数据库表》sys_urban_fac表（含fac_id设施ID、fac_type设施类型、coord_x/y坐标、fac_status状态），实现设施数据标准化存储（《02数据库表设计命名规范及英文简称对照表.docx》，简称《02命名规范》P5“sys_前缀为基础层”）；

   • 关键功能：按设施类型（下拉框关联sys_dict_fac_type字典表）、行政区划（area_code关联sys_area）筛选查询，支持设施坐标在地图上标注（对接《05数据中枢》20.1节“地理编码管理”）。

2. 设施实时状态监测：

   • 需求目标：通过物联网设备实时采集设施状态，替代人工巡查，故障发现周期缩短至1小时内；

   • 文件支撑：对接《05数据中枢》20.7节“设备管理”，将路灯传感器、井盖定位器数据同步至biz_device_telemetry_data（设备遥测表），关联sys_urban_fac的device_code字段，实时更新设施状态（fac_status=0正常/1故障）（《06-01城管》P33）；

   • 关键功能：设施状态异常时自动触发预警（推送至biz_early_warn_alert预警表），支持查看设施历史状态曲线（基于stat_fac_status_history统计 table）。

3. 维护协同调度：

   • 需求目标：设施故障后自动关联责任部门，生成维护工单，跨部门协同处置时长缩短至8小时内；

   • 文件支撑：基于《03数据库表》rel_fac_dept（设施-部门关联表），设施故障时自动匹配责任部门（dept_id关联sys_org），生成biz_urban_evt_wo（城管工单表），推送至《04我的工作台-系统功能设计.docx》（简称《04工作台》）“我的待办”模块（《06-01城管》P34）；

   • 关键功能：工单进度实时跟踪（biz_evt_disposal_track处置跟踪表），支持跨部门协同消息推送（对接《04工作台》1.4节“消息中心”）。

三、核心场景2：市容秩序管控——解决“秩序混乱、处置被动”痛点

3.1 传统治理痛点（文件原文提炼）

《06-01城管》3.3节“市容秩序监管”明确传统市容管理存在三大痛点，聚焦占道经营、户外广告、渣土清运等场景：

1. 问题发现被动，依赖投诉举报：

   • 占道经营、违规广告等问题需市民投诉或网格员现场发现，无自动识别手段，问题存在周期超12小时（《06-01城管》P36）；

   • 无AI识别支撑（《05数据中枢》20.16节“AI监测识别”未对接），无法通过摄像头自动抓拍违规行为。

2. 处置流程割裂，跨场景协同难：

   • 占道经营处置需城管部门清理，但涉及道路停车泊位时需交通部门配合，无统一工单调度，处置效率低（《01总体架构》P11）；

   • 对应《03数据库表》：传统模式下占道经营数据（gen_road_occupy_supv）与停车泊位数据（gen_park_berth_occupy）无关联，无法协同处置。

3. 处置效果无追溯，易反弹：

   • 违规问题处置后无复查机制，占道经营、违规广告易反复出现，复查率不足30%（《06-01城管》P37）；

   • 无处置结果存档表（如biz_urban_violation_recheck复查表），无法评估处置效果。

3.2 核心功能需求（基于痛点的解决方案）

结合《06-01城管》3.3节“市容秩序监管”功能描述，需落地三大核心需求：

1. 违规行为自动识别与上报：

   • 需求目标：通过AI摄像头自动识别占道经营、违规广告，结合网格员APP手动上报，问题发现周期缩短至1小时内；

   • 文件支撑：对接《05数据中枢》20.16节“AI监测识别”，将摄像头抓拍数据存入biz_ai_image_recognition（AI识别表），关联sys_urban_fac的fac_id（如违规广告关联广告设施），生成biz_urban_violation（城管违规表）；同时支持网格员通过APP填写biz_manual_report（人工上报表）（《06-01城管》P36）；

   • 关键功能：AI识别结果人工复核（verify_status字段：0待复核/1准确/2误判），复核通过后自动生成处置工单。

2. 跨场景协同处置：

   • 需求目标：占道经营、违规广告等问题处置时，自动联动关联部门（如交通、市场监管），协同处置时长缩短至4小时内；

   • 文件支撑：基于《03数据库表》rel_evt_cross_domain（跨域事件关联表），占道经营工单（biz_urban_evt_wo）自动关联停车泊位数据（gen_park_berth_occupy），推送至交通部门协同清理泊位；同时通过《05数据中枢》20.10节“指挥协调”模块调度跨部门资源（《06-01城管》P37）；

   • 关键功能：协同部门处置进度实时同步至工单详情页，支持“一键催办”（推送消息至《04工作台》）。

3. 处置结果复查与归档：

   • 需求目标：违规问题处置后72小时内完成复查，复查率提升至90%以上，形成“发现-处置-复查”闭环；

   • 文件支撑：处置完成后自动生成复查任务（biz_urban_recheck_task复查任务表），网格员通过APP上传复查照片（存储至biz_urban_recheck_media），复查结果更新至biz_urban_violation的recheck_status字段（0待复查/1已整改/2未整改）（《06-01城管》P38）；

   • 关键功能：未整改问题自动升级预警（推送至biz_early_warn_alert，预警等级提升），整改数据纳入stat_urban_violation_rpt（违规统计报表）。

四、核心场景3：违建处置——解决“发现晚、处置难、追溯弱”痛点

4.1 传统治理痛点（文件原文提炼）

《06-01城管》3.5节“违建处置”明确传统违建治理存在三大痛点，是城管住建的重点难点场景：

1. 违建发现滞后，成型后拆除成本高：

   • 依赖人工巡查发现违建，平均发现时违建已施工50%以上，拆除成本比早期制止高3-5倍（《06-01城管》P45）；

   • 无卫星遥感、AI摄像头等技术手段（《05数据中枢》20.16节未落地），无法实时监测新增违建。

2. 处置流程长，跨部门审批慢：

   • 违建处置需经“线索核查→立案→处罚→拆除”4个环节，涉及城管、规划、住建等多部门，审批周期超15天（《01总体架构》P11）；

   • 无电子化审批流程（《04工作台》1.5节“工作流程”未对接），纸质材料流转耗时占比60%。

3. 违建线索无追溯，历史数据难复用：

   • 违建线索（如位置、面积、施工进度）仅存于纸质档案，无电子化存储，历史违建数据无法复用（如同一区域反复违建）（《06-01城管》P46）；

   • 无gen_illegal_build_clue_mng（违建线索表），线索与处置结果无法关联。

4.2 核心功能需求（基于痛点的解决方案）

结合《06-01城管》3.5节“违建处置”功能描述，需落地三大核心需求：

1. 违建多源线索采集与识别：

   • 需求目标：通过“AI摄像头+卫星遥感+群众举报”多渠道采集违建线索，新增违建发现周期缩短至24小时内；

   • 文件支撑：对接《05数据中枢》20.16节“AI监测识别”，卫星遥感数据、摄像头抓拍数据存入biz_ai_image_recognition，群众举报数据通过biz_public_complain（公众投诉表）采集，所有线索统一录入gen_illegal_build_clue_mng（违建线索表），关联sys_area的area_code和sys_urban_fac的fac_id（如违建关联周边道路设施）（《06-01城管》P45）；

   • 关键功能：线索自动分类（clue_type：0新增/1扩建/2存量），高优线索（新增违建）自动推送至biz_early_warn_alert（红色预警）。

2. 电子化处置流程与跨部门审批：

   • 需求目标：违建处置流程电子化，审批周期缩短至7天内，跨部门协同效率提升50%；

   • 文件支撑：基于《04工作台》1.5节“工作流程”模块，搭建违建处置电子化流程（线索核查→立案→处罚→拆除），每个环节自动推送至责任部门（sys_org），审批结果实时更新至gen_illegal_build_disposal（违建处置表）；同时通过《05数据中枢》20.10节“指挥协调”模块调度规划部门提供违建认定意见（《06-01城管》P46）；

   • 关键功能：流程节点超时预警（如核查环节超24小时未完成，推送预警至《04工作台》），审批材料电子化存档（存储至gen_illegal_build_archive）。

3. 违建历史数据追溯与分析：

   • 需求目标：违建线索、处置结果、复查数据全生命周期存档，历史数据复用率提升至80%，同一区域违建复发率下降40%；

   • 文件支撑：所有违建数据（线索、处置、复查）关联gen_illegal_build_clue_mng的clue_id，存入stat_illegal_build_history（违建历史统计表），支持按区域（area_code）、时间（disposal_time）查询历史违建；同时基于历史数据生成“违建高发区域热力图”（对接《07城市全局总览系统功能设计.docx》大屏）（《06-01城管》P47）；

   • 关键功能：违建高发区域自动推送“预防性巡查任务”（生成biz_inspect_task_info巡查任务表），降低复发率。

五、核心场景4：环境卫生管理——解决“清运不及时、监管缺失”痛点

5.1 传统治理痛点（文件原文提炼）

《06-01城管》3.4节“环境卫生监管”明确传统环卫管理存在两大痛点，聚焦垃圾清运、公厕管理场景：

1. 垃圾清运不及时，满溢率高：

   • 垃圾转运站、垃圾桶满溢依赖人工巡检发现，满溢时长超4小时，影响市容（《06-01城管》P39）；

   • 无重量传感器、满溢传感器（《05数据中枢》20.7节未对接），无法实时监测垃圾存量。

2. 环卫作业监管弱，责任难追溯：

   • 环卫车辆清运路线、作业时长无监管，存在“漏清运、延时清运”问题；公厕清洁频率、卫生状况无量化评估（《01总体架构》P11）；

   • 无gen_garbage_collect_supv（垃圾清运监管表）、gen_public_toilet_supv（公厕监管表），作业数据无法量化。

5.2 核心功能需求（基于痛点的解决方案）

结合《06-01城管》3.4节“环境卫生监管”功能描述，需落地两大核心需求：

1. 垃圾清运实时监管与调度：

   • 需求目标：垃圾转运站、垃圾桶满溢率下降至5%以下，清运响应时长缩短至1小时内；

   • 文件支撑：对接《05数据中枢》20.7节“设备管理”，将垃圾站重量传感器、满溢传感器数据同步至biz_device_telemetry_data，关联sys_urban_fac的fac_id（垃圾站/垃圾桶设施ID），实时更新gen_garbage_collect_supv的fill_rate（填充率）；满溢时自动生成清运工单（biz_urban_evt_wo），推送至环卫车辆调度模块（《06-01城管》P39）；

   • 关键功能：环卫车辆实时定位（gen_garbage_truck_gps），系统自动规划最优清运路线，避免绕路；清运完成后自动更新fill_rate=0。

2. 环卫作业量化监管与评价：

   • 需求目标：环卫车辆作业完成率提升至95%以上，公厕卫生合格率提升至90%以上；

   • 文件支撑：基于《03数据库表》gen_garbage_collect_supv记录环卫车辆清运次数、路线、时长，gen_public_toilet_supv记录公厕清洁次数、卫生评分（hygiene_score）；作业数据同步至《05数据中枢》20.15节“综合评价”模块，生成“环卫作业效率排名”（《06-01城管》P40）；

   • 关键功能：作业异常（如漏清运）自动触发预警（推送至biz_early_warn_alert），公厕卫生评分低于80分时自动生成清洁任务（biz_inspect_task_info）。

六、需求分析核心总结（文件闭环）

城管住建核心功能需求的本质是“解决传统碎片化治理痛点，实现‘数据统一、实时监测、跨域协同、闭环追溯’”，所有需求均紧扣指定文件：

1. 数据层：依赖《03数据库表》的sys_urban_fac（设施）、biz_urban_evt_wo（工单）、gen_illegal_build_clue_mng（违建）等表，确保数据可存储、可关联；

2. 技术层：对接《05数据中枢》的“设备管理”“AI识别”“指挥协调”模块，支撑实时监测与跨域协同；

3. 应用层：适配《04工作台》的“待办”“工作流程”模块，确保功能落地到用户操作层面；

4. 目标层：呼应《01总体架构》“从碎片化到一体化”的核心目标，所有需求均以“提升效率、降低成本”为导向（如处置时长缩短、故障发现周期缩短）。

所有需求无外部依赖，完全基于指定文件，为后续“架构设计、代码落地”奠定业务基础。