📋 技术需求澄清清单
货车进场全流程无纸化 · V1.0
🎯 目的 细化技术规格，识别风险，对齐预期
📌 使用 需求评审会 · 技术选型 · 排期评估
⚡ 优先级 高 (红色) · 中 (橙色) · 低 (蓝色)
🔁 一、业务流程与规则澄清
超时、异常、切换机制等核心逻辑需明确
❓ 待澄清
- 每个节点（计划分配、装车、过磅、结算等）的标准耗时是多少？
- 超时阈值是固定值还是动态计算（如根据货物量）？
- 超时后提醒频率（仅一次/每N分钟重复）？
💡 建议
- 与业务方共同制定《节点SLA表》，例如：计划分配≤15min，装车≤45min。
- 超时后每10分钟提醒一次，直至确认或人工干预。
- 支持管理员调整阈值。
❓ 待澄清
- 切换粒度：全局一键切换 / 按角色切换 / 按单辆车切换？
- 切换时正在执行的流程如何处理？ (允许完成 / 强制中断？)
- 手动模式下，数据如何录入 (PC端表单/纸质后补)？
💡 建议
- 初期采用“全局开关”，平稳后细化到“角色级”。
- 切换时，进行中的流程不受影响，新流程按新模式执行。
- 手动模式需提供Web端快速录入页面，确保数据留痕。
❓ 待澄清
- 司机输错车牌/手机号，是否允许修改？修改后流程是否重置？
- 计划员分配错误，能否撤回/重新分配？
- 过磅重量与发货单不一致，流程应如何分支？
- 货物损坏/装车异常，如何中断或标记？
💡 建议
- 提供“异常登记”入口，由管理员或主管强制扭转流程状态。
- 设计“作废/重来”流程，并记录作废原因。
- 过磅差异超阈值时，自动推送至主管审批。
❓ 待澄清
- “任意一人确认即生效”是否会导致误操作？
- 若确认人临时离岗，如何转移任务？
💡 建议
- 改为“抢单锁定”模式：第一位点击“领取任务”的保管员获得操作权。
- 增加“代确认”功能，由主管或指定人员代操作，并留下代理记录。
❓ 待澄清
- 方案中“盖车”在过磅之后，但物理上通常装车后即盖车。
- 是否会导致车辆二次移动或重复操作？
💡 建议
- 将流程微调为：装车完成 → 盖车 → 过磅 → 对账打款 → 出厂。
- 与业务方确认实际作业习惯，避免流程与物理动作冲突。
🔌 二、技术架构与集成澄清
对接、地图、硬件选型等关键技术点
❓ 待澄清
- U8具体版本 (U8+? U8 Cloud?) 及接口方式 (Web API/中间表/文件?)
- 过磅数据字段映射：发货单号、物料编码、毛重/皮重/净重等。
- 对接失败时的降级方案 (手动录入/重试机制)？
💡 建议
- 提前与U8运维/供应商沟通，获取接口文档和测试环境。
- 设计“接口监控看板”，实时显示对接状态。
- 降级方案：支持人工在系统内补录过磅数据，并标记“人工录入”。
❓ 待澄清
- 静态平面图 or 3D建模？成本与效果差异大。
- 二维码是静态固定码还是动态生成码（含车辆信息）？
- 导航是否支持实时拥堵/临时封路提示？
💡 建议
- 初期采用高精度平面图+标注路线，成本可控。
- 二维码使用动态生成，便于统计和个性化导航。
- 若仓库/道路变动频繁，需提供地图后台维护功能。
❓ 待澄清
- 采用专用车牌识别相机还是通用摄像头+软件算法？
- 夜间/雨雾天气识别准确率要求？是否需要补光设备？
- 识别失败时的备用方案 (手动输入)？
💡 建议
- 推荐专用车牌识别相机 (如海康/大华)，准确率≥99%。
- 在入口和门岗各部署一台，并配置补光灯。
- 识别失败时，自动弹窗提示司机/门岗手动输入验证。
❓ 待澄清
- 采用微信服务号H5 还是 独立小程序？
- 是否需要消息推送能力 (服务号模板消息/小程序订阅消息)？
💡 建议
- 初期可先开发服务号H5，快速上线验证流程。
- 后续如需更丰富交互，再迭代小程序版本。
- 消息推送使用服务号模板消息 (需认证) 或短信备用。
❓ 待澄清
- 需记录哪些操作日志 (操作人、时间、IP、设备、变更前后)？
- 数据保留周期 (如3年/5年)？是否需满足等保要求？
💡 建议
- 默认记录所有关键操作 (增删改查、流程扭转、异常) 。
- 保留周期建议≥3年，并支持数据导出备份。
- 若涉及等保，需提前规划日志加密和存储方案。
⚡ 三、非功能性需求澄清
性能、可靠性、扩展性等
❓ 待澄清
- 网络或服务器中断时，业务如何继续？
- 是否有手持PDA离线记录方案？
- 恢复后数据如何同步？
💡 建议
- 为门岗、保管员配备手持PDA，支持离线本地记录。
- 设计“极简纸质应急卡”，作为最后保障。
- 网络恢复后，PDA自动同步数据，并标记为“离线补录”。
❓ 待澄清
- 高峰时段同时进场的货车数量预估？ (如早高峰50辆/小时)
- 系统响应时间要求 (页面加载≤2秒, 接口≤500ms)？
💡 建议
- 根据厂区历史数据评估并发量，设计弹性扩容架构。
- 核心接口 (扫码、确认、放行) 需保证高可用，建议集群部署。
❓ 待澄清
- 预留的对接接口是否标准化 (RESTful API/消息队列)？
- 是否提供API文档和沙箱环境供第三方测试？
💡 建议
- 采用RESTful API + OpenAPI 3.0 规范，便于后续对接。
- 提供模拟数据沙箱环境，降低联调成本。
📊 四、验收与量化指标
将“价值”转化为可测量KPI
❓ 待澄清
- 当前平均单车进场等待时间、场内流转总时长基线是多少？
- 目标值：等待时间缩短至?分钟，总时长缩短?%？
- 超时预警准确率要求 (≥99%)？
💡 建议
- 在试运行前采集一周历史数据作为基线。
- 设定可量化目标，例如：平均等待时间从15min降至5min。
- 超时预警准确率100%作为硬性验收条件。
❓ 待澄清
- 一车一档的数据完整率要求 (100%)？
- 节点操作记录是否支持按车牌/时间/操作人检索？
💡 建议
- 数据完整率100%作为基本要求，缺失数据需有明确标记和原因。
- 提供多维度查询报表 (日/周/月，按角色/仓库等)。
⚠️ 五、风险与依赖项
❓ 待澄清
- U8及车辆中标软件的接口开放程度、响应时间、SLA承诺？
- 若第三方系统升级，接口变更如何同步？
💡 建议
- 在合同中明确第三方接口的SLA和变更通知机制。
- 设计接口适配层，隔离第三方变更对核心流程的影响。
❓ 待澄清
- 厂区网络覆盖情况 (WiFi/4G/5G)？是否满足所有点位？
- 入口/仓库/门岗的强电、弱电布线是否到位？
💡 建议
- 提前进行网络勘测，对信号盲区增加AP或使用4G路由器。
- 硬件安装需与厂务部门协调，避免影响日常生产。