简介一套围绕电力巡检系统的原型与需求分析资料包面向产品经理、需求分析师及前端开发人员用于理解电力设施智能巡检的业务流程与界面交互并可直接作为原型搭建和需求梳理的参考。压缩包共1041个文件、约14.41MB核心包含Axure原型源文件.rp及配套HTML原型页面47个html、43个css、70个js另有787张PNG界面图辅助查看效果82个VSD流程图/架构图便于梳理监控、预警、任务管理等模块同时附1份doc需求文档、1份txt说明及Axure浏览器插件crxrp源文件可直接用Axure打开进行二次修改。目前已吸引1587人学习下载。通过这套资料可快速掌握实时监控、故障预警、巡检任务管理、GIS集成、报告生成等核心功能的设计思路获得从业务流程到高保真页面的一体化样例适合在电力信息化项目启动前用于需求确认与原型验证。1. 电力巡检系统原型需求分析动手画页面之前先让业务方和开发看见同一张图做电力巡检系统的人常急着画页面登录、任务列表、拍照上传。但真正让项目翻车的从来不是页面不好看而是需求没把“任务怎么派、缺陷怎么定、离线怎么交、消缺怎么闭环”说清。原型需求分析的实质是在编码前用最低成本把业务流程、角色权限和数据闭环完整走一遍让巡检员、审核班长、管理员三类人对着同一张图表态。这篇笔记适合正要立项的产品经理、项目经理和负责需求对接的工程师目标不是教画图而是给出一套能评审、能排期、能指导开发的文档组织方法。电力巡检自带现场条件差、网络不稳、责任界定严三个特点不能照搬通用巡检App的套路。下文按先理业务、再定需求、后画原型、避坑、验证的顺序展开每个环节都给出可直接抄用的表格和参数。2. 先理清业务再画原型巡检对象、角色与主流程原型画得别扭多半是业务没理透。电力巡检的业务范围其实很收敛先把“巡什么、谁在巡、怎么流转”三个问题答清楚页面自然就浮出来了。这一章是后面所有原型页面的依据建议和业务方一起过而不是自己埋头写。2.1 巡检对象与巡检类型设备台账是原型的“数据底座”电力巡检系统管理的东西说到底就两件设备台账和巡检行为。台账回答“有什么设备、在哪、属于谁”巡检行为回答“谁在什么时候看了什么设备、发现了什么问题”。很多原型一上来把台账当成普通字典表只画一个“设备列表新增按钮”开发阶段才发现一台杆塔挂在哪条线路、属于哪个供电所、电压等级多少、上次巡检是什么时候这些字段直接决定了任务派工逻辑和报表统计口径台账必须当核心模块设计。常见的做法是先按设备类型拆台账。架空线路的巡检对象主要是杆塔、导线、绝缘子、金具变电站里是主变、开关、刀闸、避雷器电缆通道则是电缆本体、中间接头、工井。这几类对象的巡检周期差异很大杆塔通常一月一次变电站设备按周期检定加日常巡视电缆接头在迎峰度夏期间要加密。任务是怎么生成的就是按台账里的巡检周期推算出来的。所以台账字段里必须预留“巡检周期”“上次巡检时间”“责任班组”三个字段原型阶段就要把它们画在台账编辑页上少一个后面补都麻烦。巡检类型也要在需求里明确不能只画一个“巡检任务”了事。我一般把巡检拆成例行巡检、特殊巡检、故障巡视、夜间巡视、保电特巡五类。其中例行巡检和故障巡视差异最大例行巡检是周期性的走固定路线故障巡视是突发性的目标是排查故障点没有固定路线。这两类在原型里的表现完全不同前者需要“任务列表路径导航”后者需要“地图选点自由上报”。如果你把两类混成一个流程开发做到一半就会发现路线规划、完成率统计全都对不上。这里有一个可以在需求阶段就定死的数据结构每个巡检点必须绑定设备ID而不是只存一个名称。很多原型里巡检点就是一个文本输入框巡检员到了现场手打“#45杆塔”后果是报表阶段的统计全部靠字符串匹配同名不同写的杆塔直接查不出来。更稳的做法是每个巡检点对应一条台账记录带设备编码和经纬度任务下发时直接引用资产ID。这个决策往早了定开发的数据模型就不会走弯路。2.2 三个核心角色与权限边界巡检员、班长、管理员电力巡检系统通常至少有三类角色原型阶段就把权限边界画清楚能省掉后面大量返工。巡检员是移动端主要使用者负责接收任务、到点打卡、填写表单、拍照、上报缺陷。班长是审核者负责看班组任务完成情况、审核缺陷、把缺陷转成消缺工单。管理员坐后台负责台账维护、任务派发、人员组织架构和报表查看。角色使用端核心权限典型页面巡检员移动端领取/执行任务、上报缺陷、查看个人记录任务列表、巡检执行、缺陷上报班长/审核人移动端PC端审核缺陷、下发消缺工单、查看班组统计待审核列表、缺陷详情、班组看板系统管理员PC端台账维护、任务派发、用户与组织管理台账管理、任务管理、系统设置权限设计上最容易漏掉的是“班组范围内可见”这条规则。巡检员不该看到全公司所有缺陷只能看到自己上报的和本班组相关的记录班长能看到自己班组的全部数据跨班组的只能看统计不能看明细管理员一般也不应该直接改巡检记录只能调台账和任务。这些边界在原型里用列表数据范围来体现不是靠按钮显隐。需求文档里建议写一句硬规则所有列表查询必须带组织架构过滤条件默认按当前用户所属班组过滤。2.3 主业务流程与状态流转派工、到位、巡检、缺陷上报、审核、消缺主流程是需求文档的骨架建议用一个状态流转表把任务全生命周期定下来。任务从生成到归档至少经历待派工、待执行、执行中、待审核、已归档五个状态缺陷经历待审核、已确认、待消缺、已消缺、已关闭五个状态。这两个状态机是原型页面跳转的依据开发的状态图也照这个画。状态触发动作执行人前置条件待派工系统按周期生成或管理员手动创建系统/管理员台账存在且巡检周期到期待执行班长派给巡检员班长任务已生成执行中巡检员点击“开始巡检”巡检员任务在当天计划内待审核巡检员提交巡检结果巡检员所有必巡检点已打卡已归档班长确认无缺陷或缺陷已转工单班长缺陷审核完成这里有一个高频争议点巡检员提交了带缺陷的任务后任务算完成还是算待审核我的做法是任务和缺陷分开走。任务提交即进入待审核缺陷独立走自己的流程班长审核任务时只确认巡检过程是否规范缺陷是不是真缺陷、严不严重单独定级。如果你把两者绑在一起缺陷没审完任务就永远不能关闭月底统计任务完成率时数据非常难看。这个决策必须在需求分析阶段写清楚否则开发的状态机没法落地。除了主线流程还要在需求里预留临时任务入口。抢修、保电、上级临时检查都会产生计划外任务原型的任务列表页需要一个“新建临时任务”的入口支持管理员指定巡检点和巡检员。很多系统上线后才发现跑不通的恰恰是这类非计划场景需求分析时多问一句“有没有临时任务”能避开一个大坑。3. 需求分析怎么做功能模块、非功能指标与版本优先级业务模型定下来后需求分析要做的事就是把业务转化成可开发的功能清单、可衡量的非功能指标和可分级的版本计划。这一章给出的是我在类似现场作业系统项目里反复用的一套拆法可以直接套用。3.1 功能模块拆解从业务事件反推而不是从竞品抄功能清单最靠谱的产出方式是从业务事件反推。把巡检员在现场的每一个动作列出来接任务、去现场、定位打卡、填表、拍照、上报缺陷、提交把班长和管理员的管理动作也列出来派工、审核、消缺、统计。每个动作都是一个功能点按对象归类后就是功能模块。从竞品抄功能清单看起来很省事但竞品没有你所在单位的组织架构和考核口径抄回来往往对不上业务。按这个方式拆下来电力巡检系统的功能模块大致是七个任务管理、巡检执行、缺陷管理、设备台账、统计报表、地图与定位、系统管理。原型的信息架构可以完全按这七个模块走不需要额外加花哨的东西。每个模块的核心功能点和优先级建议如下模块核心功能点优先级关键字段/规则任务管理手动派工、周期自动生成、任务改派P0任务编号、计划日期、巡检类型、关联路线巡检执行定位打卡、表单填写、离线暂存、照片上传P0到位时间、离位时间、定位偏差、照片时间戳缺陷管理缺陷上报、审核定级、消缺工单、闭环归档P0缺陷类型、严重等级、照片、处理状态设备台账台账新增/修改/停运、表格模板导入P1设备编码、所属线路/站点、经纬度、巡检周期统计报表任务完成率、缺陷统计、消缺及时率、班组排名P1按日期/班组/设备类型多维过滤地图与定位巡检轨迹回放、电子围栏提醒P1轨迹点集、围栏半径系统管理用户/组织/角色/字典管理P0角色权限矩阵这个拆解里最容易忽略的是台账的表格模板导入导出。电力公司的存量设备数据动辄几千上万条如果原型里没有导入入口靠管理员一条条录上线光数据初始化就要拖一个月。我在需求文档里一般会强制写一条台账模块必须支持标准模板导入导入要有错误回执能定位到第几行第几列出错。这个需求在原型里就是一个上传按钮加一个错误提示区但价值非常大。3.2 非功能性需求离线可用、定位精度、照片防篡改非功能需求是电力巡检系统在原型阶段最容易被忽略、上线后最痛苦的部分。第一是离线可用。变电站、山区线路的现场网络状况很差App必须支持无网环境下打开任务、填写表单、拍照暂存等有信号后再批量上传。这个需求直接决定了原型的每个提交按钮旁边都要有“暂存”状态列表里要有“待上传”角标。如果不在原型里把这些状态画出来开发默认就做成在线提交上线后现场一片“提交失败”的投诉。第二是定位精度与到位判定。一般要求到位定位精度在10米以内判定巡检员是否到点用的是巡检点坐标和手机定位坐标的距离差超出阈值就提示“未到位”。原型里要画出到位打卡失败的提示态。这里要注意室外GPS和室内站所定位精度差异很大室内经常拿不到GPS信号需求里要预留“手动确认到位拍照佐证”的兜底方案否则巡检员在站房里根本打不了卡。第三是照片防篡改。巡检记录是责任认定依据照片必须带时间戳和拍摄人信息原型上不能提供从相册选择的入口只能调起摄像头实时拍摄。这个细节在评审时经常被挑战但必须坚持否则责任界定的时候说不清。需求文档里把“禁止相册导入、强制实时拍摄、照片写入时间和位置元数据”写死。非功能项指标原型/开发落地方式离线能力断网可执行完整巡检流程本地数据库待上传队列状态标记定位精度室外10米内室内支持辅助定位到位判断阈值手动确认兜底照片防篡改禁止相册导入强制实时拍摄相机直调时间戳拍摄人水印响应性能列表页首屏2秒内分页加载本地缓存数据安全换手机不丢已填记录本地加密存储导出备份性能指标里还藏着一个常见坑大列表的加载方式。任务列表和缺陷列表数据量到几千条之后如果开发没做分页客户端会越用越卡。我一般会在需求文档里写明列表页默认分页20条、滚动加载不采用一次性全量拉取。这个虽然不是原型能画出来的但要在需求文档里占一行开发才不会忽略。3.3 优先级划分与版本规划P0 保主线P1 保完整P2 留增强原型评审时业务方容易什么都想要这时候需求分析的价值就体现在优先级上。我的分法很简单P0 是主线闭环缺了它系统跑不起来任务派发、巡检执行、缺陷上报审核、任务归档这条路必须完整。P1 是管理增强台账、统计报表、轨迹回放决定系统好不好用可以晚一个版本。P2 是锦上添花比如巡检路线智能优化、缺陷图片AI识别前期不要在原型里展开否则评审会彻底跑偏。版本内容说明V1.0任务管理、巡检执行、缺陷管理、系统管理全是P0跑通巡检业务主线满足上线要求V1.1台账导入、统计报表、轨迹回放、电子围栏全是P1让管理层愿意用减轻运维负担V2.0智能路线规划、缺陷AI预判、语音录入全是P2依赖历史数据积累适合二期给原型评审一个非常实用的建议P0 页面做高保真P1 页面做低保真线框P2 页面只列标题不画页面。这样评审的注意力会被引导到关键路径上不会花一小时争论某个报表的饼图颜色。我见过太多评审会80%的时间浪费在P2功能上P0的离线逻辑反而没人细看。提示优先级不是业务方口头定的而是按“没有它主线能否闭环”来判断。每一条需求都问一句“去掉它系统还能用吗”能就是P1或P2。4. 原型设计落地信息架构、关键页面与交互状态需求文档定的是逻辑原型定的是界面和交互。这一章直接给出移动端和PC端的信息架构、巡检执行页和缺陷审核页的核心设计以及原型工具和粒度的控制方法。照着这套做法一个没有专职交互设计的团队也能把原型做到可评审、可开发。4.1 信息架构与导航移动端底部三栏PC端左侧菜单电力巡检系统的原型分两个端巡检员用的移动端和后台管理的PC端。移动端的信息架构建议底部三栏首页、任务、我的。首页放今日待办和消息提醒任务是核心工作台我的里放个人统计和设置。不要做四五个底部栏巡检员在野外单手操作导航越少越好任务入口必须在拇指可及的位置。任务页默认展示“待执行”分类这是巡检员打开App后最常看的内容。PC端后台的信息架构按七个功能模块走左侧菜单工作台、任务管理、缺陷管理、设备台账、统计报表、地图监控、系统管理。地图监控建议单独占一个菜单轨迹回放和电子围栏的交互密度很高混在缺陷管理里页面会非常拥挤。原型里每个菜单下先画一个列表页和一个详情页外加一个新建/编辑弹窗三件套足够覆盖大部分后台需求不需要为每个菜单单独设计花哨布局。任务列表页是移动端的核心原型里一定要画出三种状态卡片待执行、执行中、待审核。待执行卡片显示计划时间和巡检类型按钮是“开始”执行中的显示已检查点数和总检查点数按钮是“继续”待审核的直接给“查看结果”入口。如果你只用了一个统一的“任务详情”入口巡检员点进去还要自己判断该干什么现场操作效率会明显下降。状态卡片同时也是开发端的列表接口设计依据一个卡片对应一个状态枚举。4.2 巡检执行页表单字段、拍照流程与离线暂存巡检执行页是移动端最重的页面字段设计直接影响现场录入效率。一个巡检点的表单建议控制在8个字段以内超过就要拆成多个检查项。常见字段是设备状态正常/异常/其他、运行参数温度、油位等按设备类型动态显示、缺陷照片、缺陷描述、备注。每个字段都要标注是否必填必填字段在原型里用星号标出这个约定在需求和开发之间必须一致开发才能正确做校验。字段控件类型必填说明设备状态单选是正常/异常/其他运行参数数值输入否按设备类型动态显示如油位、温度现场照片相机拍摄异常时必填强制实时拍摄带时间戳缺陷描述文本/语音异常时必填支持语音转文字提升录入效率备注文本否自由填写不做长度硬限制页面上必须有“暂存”和“提交”两个动作。暂存是把已填写内容存到本地任务状态保持执行中提交是校验必填项后进入待审核并触发数据上传。原型里要画一个明显的“待上传”角标和网络状态条让巡检员知道当前数据是已同步还是仅本地。离线提交时系统不报错而是提示“已保存网络恢复后自动上传”这是电力巡检原型和普通App原型最大的差别之一。画原型时把这句话写进交互说明开发就不会做成断网直接报错。4.3 缺陷上报与审核状态可见性是评审重点缺陷管理的原型设计要点是让状态全程可见。巡检员提交缺陷后能在自己的记录里看到缺陷走到哪一步待审核、已确认、待消缺、已消缺、已关闭。班长端看到的是待审列表每条缺陷显示上报人、设备位置、严重等级和照片缩略图点击进入详情做确认或驳回。驳回必须填原因原型里把驳回原因做成必填项这是需求文档里要写死的规则否则巡检员不知道自己要补什么。严重等级建议分三级一般、严重、紧急。紧急缺陷要在列表上置顶并用红色标识同时触发消息推送。这里的消息机制也要在原型里体现紧急缺陷推送给班长和值班人员一般缺陷只在任务详情里留待办标记不能所有缺陷都推消息否则一个月后大家就把通知关了。你可以在原型里直接用一句推送规则说明替代消息中心页面但这条规则要写进需求文档。缺陷详情页还要把“关联任务”和“关联设备”两个字段放上去。缺陷必须能反查到是哪个巡检任务、哪个巡检员报上来的这既是为了责任界定也是为了按班组统计缺陷率。原型里用两个链接字段即可但需求文档里要写明这两个关联是强制的不能为空。开发建模时缺陷表的外键就靠这两个字段。4.4 原型工具选择与粒度控制低保真起步关键路径高保真工具上见过用专业原型软件、在线协作设计工具甚至手绘白板照片推进项目的关键不在工具而在粒度控制。我的习惯是分两轮第一轮全部用低保真线框只画结构、字段和按钮用来和业务方捋流程第二轮只对P0的巡检执行页和缺陷审核页做高保真带完整交互状态用来做开发前的UI走查。这样既不在工具上耗太多时间又保证关键页面的还原度。如果团队里没有专职交互用一个页面标注规则就够了每个页面上传一张原型图配一个字段说明表。字段说明表包含字段名、控件类型、是否必填、默认值、校验规则、异常提示。这张表其实就是需求文档的最小单元开发拿到它不需要再看第二遍原型就能写代码。很多项目后期扯皮缺的就是这张字段表开发只能对着原型图猜字段含义。数据结构也可以在这个阶段提前确认。画原型时就把任务对象的JSON结构写出来给开发看避免页面画完后数据结构返工。下面是一个包含离线暂存设计的巡检任务简化结构{ taskId: TASK20250120001, planDate: 2025-01-20, inspectionType: ROUTINE, inspector: user_1003, routeId: ROUTE_024, targets: [ { assetId: TOWER_045, deviceName: 35kV线路A段#45杆塔, longitude: 118.7321, latitude: 32.0485, checkItems: [基础, 塔身, 绝缘子, 金具] } ], status: PENDING, offlineDraft: null }这个JSON的关键点有两个targets数组里每一项都带assetId巡检结果按assetId回写保证一个杆塔对应一份检查记录offlineDraft字段预留了离线暂存的数据入口开发做离线模块时不需要改表结构。在需求分析阶段把数据结构确认掉比开发写代码时再讨论要省事得多。5. 电力巡检原型与需求分析避坑五个最常见的问题和排查方法这一章列的是我在电力巡检和同类现场作业系统项目里反复遇到的五个坑每个都按“现象、原因、解决”三步写排查时可以直接对号入座。前四个是需求和流程层面的第五个是资源策略层面的按踩坑频率排序。5.1 任务和缺陷关系没定清开发返工现象开发把任务和缺陷设计成一对一的父子关系一个任务只能挂一个缺陷。到了现场巡检员在一个杆塔上同时发现绝缘子破损和基础塌陷两个问题想上报两条缺陷发现系统不让他提交第二条或者第二条把第一条覆盖了。原因需求分析阶段只画了“上报缺陷”的入口没明确任务和缺陷的关系开发按最简单的方式建了模。解决在需求文档里把关系写成“任务 1:N 缺陷缺陷 N:1 设备”原型里在缺陷上报页支持一条任务连续上报多条缺陷每条独立进入审核流程。排查时直接看缺陷列表页是否按任务分组、每条缺陷是否独立显示状态做不到就是关系没定对。5.2 离线场景想当然现场数据丢失现象原型评审时业务方说“现场没信号很正常”开发说“做本地缓存就行”。结果上线后巡检员在山区提交后界面显示“已提交”回公司发现数据没了因为记录没进上传队列App一杀进程就丢。原因需求文档没定义离线策略的细节暂存数据存哪、什么时候进上传队列、上传失败怎么重试、用户怎么感知。解决把离线策略写进非功能需求所有提交先落本地库网络恢复后按队列顺序上传上传成功才清除本地记录列表页常驻网络状态条和待同步数量。排查方法是关掉网络完整跑一遍巡检流程再恢复网络看数据是否出现在后台不通过就说明离线设计没落地。5.3 定位“假准”到位判定形同虚设现象巡检员人在距杆塔两三百米外的车里点“到位”系统照样打卡成功反过来巡检员站在杆塔正下方因为GPS漂移提示“未到位”只能反复点确认。原因原型里只画了打卡按钮没画到位判定的反馈和偏差容忍逻辑也没有兜底方案。判定半径、漂移补偿、违规记录这些参数全部缺失。解决需求里明确到位判定的三个参数判定半径默认30米、GPS连续采点3次取均值做漂移补偿、超时未到位给提示。同时给“手动到位”加拍照佐证和可追溯标记允许到位但系统记录偏差距离。排查方法是拉一条实际巡检轨迹回放看打卡点坐标和真实位置差多远。5.4 审核缺了“退回重报”缺陷闭环断掉现象班长发现巡检员报上来的缺陷描述不清、照片拍糊了想退回去补充系统里没有这个操作只能手动把缺陷改成“已关闭”再让巡检员重新报一条。结果缺陷编号变成两条统计口径全乱。原因原型阶段只画了“确认”和“驳回”两个状态驳回后数据没有去处开发随手把驳回等同关闭。解决缺陷状态机里明确“驳回”是独立状态驳回后缺陷回到巡检员名下变成“待补充”巡检员补充后重新提交编号不变。原型里在驳回操作上加必填原因在巡检员端加“被驳回需补充”的醒目标记。5.5 照片存储与压缩策略没定上线就爆现象一张巡检照片原图5MB一个巡检点两张照片一天50个巡检点就是500MB。上线三个月后客户端内存满了、服务器存储告急列表页加载照片转圈转半天。原因需求分析只写了“拍照上传”没定照片分辨率、压缩比、存储路径和缩略图策略开发只能存原图前端也只会一次加载全尺寸图。解决需求里写清楚照片链路拍摄压缩后单张不大于800KB、服务端原图保留30天、列表和详情页用缩略图、原图点击后按需加载。原型阶段就把“上传成功后生成缩略图”这个交互状态画出来。排查方法是看缺陷详情页图片加载耗时超过3秒基本就是没有缩略图策略。6. 原型做出来后怎么验证反向走查与需求追溯矩阵原型和需求文档做完直接拿去评审效果往往不好因为评审会容易变成“看图提意见”。我习惯先做两件事再上会反向走查和需求追溯矩阵。反向走查是拿着原型每一个可点击控件反向问“这个控件对应哪条需求”。比如看到“开始巡检”按钮要问点完之后任务状态怎么变没有GPS信号怎么办离线状态下能不能点问不出答案的地方就是需求缺口。走查的产出是一份问题清单不是当场改原型。把问题分成两类影响主线闭环的当场定方案优化类的记录到待办避免走查会变成改图会。需求追溯矩阵是给需求文档收尾的关键动作。每一行是一条需求描述列分别是需求编号、功能模块、优先级、对应原型页面、验收要点。这张表既能在评审时让业务方逐条确认也能在开发完成后逐条打勾验收是最省成本的验收清单。下面是一个简化的例子规模大的项目可以按模块拆成多张表。需求编号功能模块优先级原型页面验收要点REQ-001任务管理P0任务列表页支持按日期、类型、状态筛选REQ-002巡检执行P0巡检执行页离线可填写并暂存恢复网络自动上传REQ-003缺陷管理P0缺陷上报页一条任务可连续上报多条缺陷REQ-004缺陷管理P0缺陷审核页驳回必填原因缺陷回到待补充REQ-005设备台账P1台账管理页模板导入并返回错误行评审会我一般只控制两个议题先逐条过P0的追溯矩阵再对巡检执行页做一次现场模拟演示。让业务方扮演巡检员按“接任务、到现场、填表单、拍缺陷、提交”的路径走一遍他们会立刻发现流程里哪里别扭。这就是原型最大的价值花一天改原型好过上线后花一个月改代码。做完这套验证原型和需求文档就可以放心交底给开发了。这也是我自己踩过不少坑之后固定下来的习惯先理业务、再定需求、后画原型、最后反向走查。这套流程不保证一次做对但能保证每一次评审都有增量希望帮到你。本文还有配套的精品资源点击获取