产品与软件负责人：角色定位
产品与软件负责人负责把设备数据、模型输出和任务规则组织为可理解、可操作、可追溯的软件产品。该角色同时维护数据契约与用户体验，不改变物理模型含义，也不把平台建议包装为自动飞行控制。
| 来源 | 输入 | 产品与软件工作 | 输出 |
|---|---|---|---|
| 嵌入式硬件 | 实时遥测、质量状态、设备日志、命令回执 | 设备接入、校验、缓存、时序与异常处理 | 统一遥测流、设备状态和历史记录 |
| 物理建模 | 模型 schema、沉积网格、不确定性、警告和版本 | Model Adapter、任务叠加、规则计算 | 覆盖、暴露、风险解释和建议 |
| 用户研究 | 角色任务、信息需求、工作环境和处置流程 | 信息架构、交互、可用性与报告设计 | PWA、回放、报告和验收记录 |
学习目标与产品边界
现场看板以用户任务、注意力限制和数据可信度为设计约束。AeroGuard 的产品边界是提供喷洒质量与风险管理信息，不替代飞控，也不替代操作者的安全责任。
学习目标
- 能够区分飞手、植保服务公司、农场管理者和研究人员的不同任务。
- 理解任务规划、实时作业、任务回放和报告四个阶段的信息需求。
- 能把传感器、模型和平台分析映射为看板组件。
- 理解告警为什么必须有触发原因、严重度、状态和处理记录。
- 能设计一张不混淆实测与预测、不伪造确定性的实时作业页。
1. 核心知识：用户角色与任务
产品设计首先识别角色，而不是先画页面。飞手在作业中关注安全、设备状态和异常；植保服务公司的负责人关注标准化、客诉、返工和证据；农场管理者关注防治效果、成本和地块质量；研究人员关注原始数据、模型版本与实验误差。一个页面不可能同时以相同优先级满足所有人。
| 角色 | 核心任务 | 最需要看到 | 应避免强迫其处理 |
|---|---|---|---|
| 飞手/现场操作员 | 安全完成任务并处理异常 | 连接状态、喷洒是否正常、最高优先级告警、明确建议 | 完整模型公式和复杂统计 |
| 服务公司调度/质控 | 统一团队标准并减少返工争议 | 任务进度、异常任务、覆盖质量、记录完整性 | 单个传感器的高频波形 |
| 种植户/农场管理者 | 确认服务质量和地块结果 | 完成面积、覆盖概览、异常位置、可解释报告 | 设备寄存器与通信日志 |
| 工程/研究团队 | 验证模型并定位系统问题 | 原始数据、输入质量、模型版本、预测与实测残差 | 被评分隐藏的细节 |
第一版产品可以聚焦“现场飞手 + 服务公司质控”这两个核心角色。农场报告和研究工具作为同一数据链的不同视图，而不是把所有功能堆到实时驾驶舱中。
2. 产品应跟随完整作业旅程
用户价值分布在作业前、作业中和作业后。只做实时热力图会失去任务准备和证据追溯；只做报告又不能在异常发生时提醒。建议用四个阶段组织功能。
| 阶段 | 用户问题 | 产品输出 | 完成条件 |
|---|---|---|---|
| 任务规划 | 数据准备好了吗？目标区域和敏感区清楚吗？ | 地块、目标剂量、设备、模型适用域和检查清单 | 必需参数齐全且风险已提示 |
| 实时作业 | 系统是否正常？哪里已覆盖？是否出现异常？ | 实测状态、预测沉积、风险提示、最高优先级建议 | 任务结束或安全暂停 |
| 任务回放 | 异常什么时候发生，受哪些参数影响？ | 时间轴、地图、告警、参数联动和模型版本 | 关键事件可定位并解释 |
| 质量报告 | 完成得怎么样，有什么证据，下一次如何改进？ | 摘要、覆盖、越界、异常、可信度和原始记录索引 | 报告可追溯且不夸大预测 |
3. 产品信息架构
后台看板建议保持五个主要入口：Dashboard 总览、Mission Planning 任务规划、Live Operation 实时作业、Replay & Analysis 回放分析、Reports 报告。设备管理和设置属于辅助入口。导航名称应反映用户任务，不以技术模块命名；用户不需要进入“物理模型引擎页面”才能开始任务。
数据从哪里来到哪里去
设备数据通过本地网关或后台 API 进入数据接收层，完成鉴权、时间同步、单位转换和质量检查。有效数据存入时序记录，同时传给模型适配层。模型返回物理预测，平台再进行空间叠加和风险规则计算。前端通过 WebSocket 或等效实时通道获得轻量状态，通过 REST API 获取任务配置、历史数据和报告。
前端接收的不是一包混杂数据
前端数据应按 Mission、Telemetry、Prediction、Analysis、Alert 和 Recommendation 分组。Telemetry 代表实测，Prediction 代表模型输出，Analysis 代表平台计算，Recommendation 代表规则生成的建议。不同来源在视觉上需要明确标签和更新时间，避免用户把预测当成传感器实测。
4. 实时作业页：只保留现场必须的信息
实时页的第一任务是状态判断，而不是展示科研成果。推荐采用“地图主画布 + 右侧关键状态 + 顶部连接状态 + 底部事件时间轴”的结构。地图展示地块边界、无人机或试验平台位置、已喷轨迹、预测沉积、边界外漂移和敏感区；图层可以切换，但默认只开启最必要的三层。
第一屏需要回答的七个问题
- 当前加载的是哪一个任务？
- 设备、定位、传感器与模型是否在线并有效？
- 喷洒当前是关闭、稳定、异常还是暂停？
- 实时位置和已经执行的区域在哪里？
- 覆盖是否接近目标，是否存在明显不足或过量？
- 最高风险是什么，发生在哪里，依据是什么？
- 操作者现在需要做什么，建议是否必须人工确认？
| 区域 | 必须显示 | 次级信息 | 避免 |
|---|---|---|---|
| 顶部状态栏 | 任务、运行状态、设备连接、数据延迟 | 当前时间、用户 | 堆满天气和账户按钮 |
| 地图画布 | 边界、位置、覆盖/沉积、敏感区 | 风矢量、规划航线 | 同时开启所有彩色图层 |
| 关键遥测 | 风速、速度、高度、流量、压力 | 温湿度、剩余液量 | 只显示数值不显示有效性与更新时间 |
| 风险与建议 | 最高级别风险、原因、位置、建议 | 其他已确认风险 | 多个弹窗互相遮挡 |
| 时间轴 | 告警、暂停、传感器故障、人工标记 | 参数变化点 | 绘制无法阅读的全部高频点 |
色彩不是装饰
绿色应表示达到目标或安全，黄色表示需要注意，橙红表示高风险或过量；水体本身使用蓝色。所有热力图必须配色标、单位和时间，不能让相同红色同时表示“沉积量高”和“危险”。
5. 环境风险中心：风险必须可解释
Environmental Risk Index 可以作为汇总视图，但不能取代底层信息。一个 72 分的圆环没有解释力，除非用户能够看到风险由什么敏感区、什么预测沉积、什么距离与什么模型置信度构成。第一版风险不宜覆盖水体、授粉昆虫、人员和邻田等所有复杂生态模型；可以先建立“非目标区域沉积”和“指定敏感区暴露”的可验证框架。
平台应将风险拆为 Hazard（喷洒材料本身的危害信息，第一版可由任务配置提供）、Exposure（预测暴露量或沉积）、Receptor（敏感对象）和 Uncertainty（不确定性）。如果缺少药剂毒性或生态阈值数据，系统应展示“暴露风险提示”，而不是宣称完成完整毒理风险评估。
| 风险卡片字段 | 含义 | 示例表达方式 |
|---|---|---|
| 风险对象 | 受到影响的敏感区域 | 东侧排水沟 / 北侧邻田 |
| 预测暴露 | 模型估计的沉积或越界比例 | 显示区间与单位，不只显示“高” |
| 空间证据 | 与地块和风向的关系 | 地图高亮、最近距离、相对风向 |
| 置信度 | 输入质量与模型适用性 | 已验证范围内 / 超出风速范围 |
| 建议 | 用户可执行动作 | 暂停喷洒并人工确认现场风况 |
6. 告警与建议：从触发到关闭的完整生命周期
告警不是红色弹窗，而是一条可追溯事件。它至少包含唯一编号、类型、严重度、触发时间、触发条件、相关设备/空间位置、当前状态、建议动作、确认人和解决时间。状态可以是 triggered、acknowledged、resolved 和 archived。用户关闭弹窗只代表“已确认”，不代表风险消失。
| 严重度 | 定义 | 界面行为 | 示例 |
|---|---|---|---|
| 信息 | 不得求立即处置 | 进入时间轴，不打断操作 | 模型版本切换、任务已保存 |
| 注意 | 趋势异常，需要观察 | 固定提示条，可确认 | 风速接近已验证范围上限 |
| 严重 | 可能影响质量或环境 | 突出显示，要求确认原因 | 流量持续偏离目标、越界沉积上升 |
| 紧急 | 需要立即进入安全状态 | 全局告警并优先执行本地安全逻辑 | 通信丢失且阀无法确认关闭 |
建议要写成“动作 + 原因 + 预期影响 + 约束”。例如“暂停喷洒并确认东侧风况；模型预测边界外沉积增大，且当前风速超出已验证范围”。不得输出“向左飞 0.4 米”这类假精确建议，也不得让平台在未经飞控集成和安全验证时自动修正航路。
7. 任务回放与质量报告
任务回放把空间、时间和事件关联起来。用户拖动时间轴时，地图位置、遥测、模型预测和告警应同步变化；点击告警可跳到触发时刻。回放必须读取当时保存的模型版本和任务配置，而不是用今天的模型重算后冒充历史结果。若提供重新分析功能，应明确标记“按新模型重算”。
报告建议结构
- 任务摘要：地块、时间、操作者、设备、作业面积、喷洒体积和数据完整度。
- 质量结果：达到目标、覆盖不足、过量和越界区域，附统一图例。
- 关键异常：流量偏差、传感器故障、风况超域和人工暂停事件。
- 模型说明：版本、验证范围、主要假设与本次预测置信度。
- 改进建议：只列有证据支持的可执行建议，并标出需人工审核的内容。
- 追溯信息：原始数据索引、校准记录、报告生成时间与不可篡改标识的预留。
8. 田间网络不稳定时，产品仍应诚实工作
PWA 可以缓存页面框架和最近任务，但不能假装实时。网络断开后，页面应清楚显示“离线”“最后数据时间”和哪些功能不可用。本地设备若仍在采集，可把数据暂存并在恢复后同步；同步需要去重、顺序处理和冲突规则。关键安全控制应避免依赖云端持续连接。
可信界面的四条规则
- 每个实时数据都显示有效性，不把 stale 数据当当前值。
- 每个预测都显示模型版本和更新时间。
- 每个风险都能追溯到底层预测和平台规则。
- 每个建议都说明是否自动执行、需要谁确认，以及系统不知道什么。
可访问性同样是现场可靠性的一部分：颜色之外使用文字和形状区分状态；重要按钮有足够触控尺寸；横屏平板是核心布局，但手机仍能查看任务摘要与告警；动画尊重减少动态效果设置；打印报告保持清晰。
9. AeroGuard 中的应用与案例推演：风险升高但模型超域
案例条件：实时风速超过模型验证范围，沉积羽流在地图上与东侧水沟相交。风速传感器状态有效，流量和压力正常，模型返回 out_of_domain。
产品处理：界面必须同时显示三类事实：实测风速已超过验证范围；模型给出的空间趋势属于外推；平台规则检测到预测沉积与敏感区相交。最高优先级建议写为“暂停喷洒并人工复核东侧风况”，并附触发依据。界面不得给出经过伪精确计算的固定修正距离，也不得把告警确认视为问题解除。
接口规范
| 对象 | 必需字段 | 来源标签 | 失败状态 |
|---|---|---|---|
| Telemetry | timestamp、field、value、unit、quality、device_id | 实测 | stale、fault、offline |
| Prediction | model_version、grid、uncertainty、domain_status、warnings | 模型预测 | invalid_input、out_of_domain、failed |
| Risk finding | object、exposure、basis、severity、confidence | 平台规则 | insufficient_evidence |
| Recommendation | action、reason、expected_effect、constraint、confirmation | 决策辅助 | not_available |
常见错误
- 在实时页堆叠全部传感器曲线，挤占现场任务所需信息。
- 以红黄绿颜色替代正式图例、阈值、对象和依据。
- 混合显示实测数据、模型预测和平台规则，使用户无法判断来源。
- 告警只有弹窗和关闭按钮，缺少确认、处置、解除与归档状态。
- 历史回放使用当前模型重算，却未标记与原任务结果的差异。
本章总结
- 产品页面按用户任务和作业阶段组织，而非按数据库字段组织。
- 设备、模型、规则和人工输入采用明确来源标签。
- 实时页优先回答位置、喷洒状态、风险、异常和下一步动作。
- 风险必须关联对象、空间证据、置信度和计算依据。
- 告警采用完整生命周期，建议采用结构化字段并保留人工责任。
- 任务回放与报告保存原始数据索引、配置和模型版本。
10. 预习任务与完成标准
开营前提交：产品信息架构包
- 画一条“规划—检查—实时—回放—报告”的用户旅程，标出每阶段核心问题。
- 完成一张 Live Operation 横屏线框图，注明每个组件的数据来源：实测、模型或平台。
- 设计一张可解释风险卡，必须包含对象、预测暴露、置信度、依据和建议。
- 写出一个告警从触发到解决的完整状态变化。
- 设计一页任务报告目录，并指出哪些结论只是预测、哪些来自实测。
完成标准：硬件与建模负责人能够根据产品接口表提供数据，用户能够从线框图识别当前状态、数据来源、最高风险和可执行动作。
自测题
- 为什么实时页应避免显示所有传感器曲线？
- “用户关闭告警”与“问题已解决”有什么区别？
- 为什么历史回放要保存模型版本？
- 当药剂危害数据缺失时，平台应该如何表述环境风险？
- 网络断开后，哪些功能可以继续，哪些必须明确停用？