崇左应用场景示例：门店巡检与问题上报小程序的需求拆解
这类小程序先解决一条可闭环的巡检链路
门店巡检常被简化成“拍照后提交”，但真正决定可用性的，是任务如何下发、异常如何流转、记录能否回看。示例场景可设定为：运营在后台创建巡检计划，巡检员在小程序接收任务，按检查项逐条填写；发现异常时可拍照和补充说明，提交后由负责人判断是否需要整改，整改完成后再复核关闭。这里只讨论需求拆解方法，不指向任何真实客户，也不预设交付结果。
第一版不必把报表、积分和复杂消息都装入。判断优先级的依据是：每个状态是否有明确责任人，异常提交后能否追到关闭。如果这两点没有打通，功能再多也难支撑现场使用。
角色和状态要先定，页面随后
示例中至少需要运营管理员、巡检员、门店负责人和复核人。运营管理员维护门店、人员、检查模板和计划；巡检员执行任务；门店负责人处理整改；复核人确认关闭。权限不只看“能不能进入”，还要看可编辑字段和可执行操作。比如巡检员提交后不应继续改原始记录，补充说明应另存为处理记录。
状态可先采用：待执行、进行中、待审核、待整改、待复核、已关闭。每个状态写明进入条件、可操作人和退回路径。待复核不通过时回到待整改，而不是重新生成任务，这样问题编号和处理历史才能连续。状态名称可按业务习惯调整，但不要把“审核”和“复核”合并成同一个动作，否则责任边界会变模糊。
检查项与问题记录分开建模
检查模板适合放重复执行的条目，可分是否项、评分项和描述项。是否项用于消防通道是否畅通、证照是否有效等判断；评分项用于陈列、卫生等分级评价；描述项用于设备异常和现场补充。必填字段只保留影响判断的内容，照片可约定异常项至少一张、正常项可选，减少为留痕而增加的操作负担。
问题记录建议独立于任务保存。一个问题至少包含来源任务、门店、检查项、问题描述、照片、责任人、期望完成时间和处理记录。这样同一门店的重复问题能按检查项汇总，整改过程也不会被下一次巡检覆盖。如果第一版只存任务结果，后续统计高频问题会很被动；即使页面简单，也值得保留问题编号和任务关联。
方案组成围绕现场填写和后台配置展开
小程序端重点做任务入口、分段填写、草稿保存、照片上传和提交确认。管理端负责门店与人员配置、检查模板维护、计划下发、问题列表和复核操作。服务端承担权限、状态流转、文件存储和消息触达。若已有账号体系可优先复用；没有时可先用手机号登录，再由后台分配角色，避免第一版自建过重的账号系统。
通知不宜只依赖订阅消息。未授权时要有站内待办兜底，整改提醒和审核结果可分别设置。照片存储需确认访问权限和保留周期，原图与压缩图是否都保留应在开发前定。检查模板若允许修改，历史任务应展示提交时的版本，否则旧记录会被新条目解释错位。
实施顺序建议从线下流程开始
- 收集现有巡检表和实际问题处理方式，区分判断字段与习惯性记录。
- 确定角色、门店层级和状态流转，画出任务从生成到关闭的路径。
- 设计检查模板与问题字段，先用表格或纸质方式模拟一轮填写。
- 评审小程序任务列表、填写页、问题详情页和管理端配置页。
- 开发时先打通一条完整链路，再补充通知、统计和批量配置。
- 准备试用数据，检查权限、照片上传、退回和超时等异常路径。
权限与状态最好在页面开发前定稿；检查项尚未稳定时，可先冻结字段结构，把模板内容做成可配置项，减少后续改代码的频率。
验收看闭环，维护看边界
验收可围绕任务完整性、权限边界、异常路径和数据追溯展开：计划能否生成任务，草稿能否恢复，提交后原始记录是否锁定，退回后能否重新整改，照片失败和网络中断是否有提示，操作时间与处理人是否可查。验收记录应写明通过条件和未通过项，不用“基本可用”代替具体判断。
上线后的日常维护包括人员调整、模板修改和消息配置；新增审批层级、改变问题闭环规则或接入其他系统，则属于功能调整，需要重新评估。维护约定中可写明故障响应、数据备份和版本更新方式，避免把运营配置和二次开发混在一起。实际方案仍要按门店规模、现有系统和资料准备情况重新核对。