# 佳友厚苑溯源页第二阶段详细开发设计方案

## 1. 文档说明

### 1.1 文档目的
本文档用于指导 **佳友厚苑溯源页第二阶段** 的产品设计、前端开发、后端接口、数据结构补充与后续联调验收。  
适用对象包括：

- 产品经理
- 前端开发
- 后端开发
- Cursor / AI 辅助开发
- 测试与运营同事
- 后续需求回顾与迭代参考

### 1.2 当前阶段背景
佳友厚苑溯源页第一阶段已完成并具备以下能力：

- 商品信息展示
- 农场信息展示
- 批次信息展示
- 检测报告查看
- 合格证查看
- 二维码标签生成与打印
- 扫码进入 H5 溯源页

第一阶段目标已实现：

> 跑通溯源链路，做到“能看”。

### 1.3 第二阶段目标
第二阶段不再是简单增加模块，而是围绕以下目标展开：

1. 在现有页面风格基础上，增强用户第一眼信任感
2. 加入种植过程可视化内容，形成更完整的可信链路
3. 引入农事时间轴、实时监控、环境状态等内容
4. 将冰冷数据转化为用户可理解、可感知的信任表达
5. 在不破坏当前第一阶段页面风格的前提下，完成信任升级

### 1.4 第二阶段一句话目标
> 从“资料完整的溯源页”，升级为“让消费者放心的信任页”。

### 1.5 第二阶段范围边界

- 首屏信任感优化（基于现有页头与 Hero 商品图，不额外新增 Hero 内重文案）
- 溯源信息卡（由"溯源结论卡"与"批次信息卡"融合而成，作为首个核心信任卡片）
- 关键农事时间轴
- 实时监控画面展示
- 种植环境记录展示
- 检测报告与合格证作为证明层保留
- 页面底部安心收口文案增强

#### 本阶段不包含
- 商城购买链路打通
- 加购、下单、支付等交易能力
- 复杂的多 Tab 页面重构
- 大屏式设备监控看板
- 监管报表、导出报表等后台能力
- 复杂权限系统或内容审核流重构

#### 实施原则
第二阶段以“增强信任表达”为目标，不以增加功能数量为目标。

---

## 2. 用户与信任目标分析

### 2.1 面向用户
当前溯源页主要面向两类用户：

1. 普通消费者
2. 高端用户 / 送礼用户

### 用户共性特征
- 不具备专业农业知识
- 不愿意阅读复杂报告和大量数据
- 更关注结果而非过程细节
- 对“真实性、安全性、新鲜度”敏感
- 希望快速获得“可不可以买、可不可以放心吃”的判断

### 2.2 用户核心关注点
用户普遍会关心以下问题：

- 是否安全，尤其是农药残留、重金属等问题
- 是否真实产地
- 是否真实种植，不是“包装出来的”
- 是否新鲜，是否刚采摘、刚包装
- 是否有检测与证明材料

### 当前阶段优先聚焦的信任点
第二阶段建议重点强化两个核心信任点：

1. **安全**：农残、检测、合格证
2. **真实新鲜**：种植过程、采收、实时现场、环境状态

### 2.3 信任表达策略
第二阶段的信任，不建议以“科技感”作为主导，而应以：

- 真实可信
- 官方可信

为主，技术能力作为辅助支撑。

### 推荐信任构成比例
- 70% 真实可信
- 30% 官方可信

### 不建议作为主表达
- 纯设备炫技
- 纯技术指标堆砌
- 大量术语和参数展示

### 2.4 第二阶段信任表达原则
第二阶段所有新增内容必须遵守以下原则：

#### 原则 1：先给结论，再给证据
错误方式：
- 先给报告、参数、曲线，让用户自己判断

正确方式：
- 先告诉用户“这批产品来源清晰、检测完成、过程可查”
- 再提供报告、证书、数据作为佐证

#### 原则 2：少讲技术，多讲真实
用户不关心：
- 你用了几个传感器
- 采集频率是多少
- 设备品牌是什么

用户关心：
- 现场能不能看见
- 种植过程是不是真的
- 检测是否真实出具
- 数据是否表明环境正常

#### 原则 3：数据是证据，结论才是信任
环境数据、农事数据、检测报告都不是目的，它们只是用于支撑以下结论：

- 本批次产品安全可查
- 本批次产品真实种植
- 本批次产品过程可见
- 本批次产品值得放心食用

---

## 3. 第二阶段页面整体策略

### 3.1 总体策略
第二阶段不推翻第一阶段页面风格与代码结构，而是在当前基础上进行：

- 模块新增
- 模块顺序优化
- 文案升级
- 数据展示策略升级

### 不做的事
- 不做整体视觉重构
- 不引入复杂 tab 结构
- 不把页面做成数据看板
- 不做重后台化表达

### 3.2 页面结构策略
第二阶段页面结构由原来的“资料罗列型”调整为“信任递进型”。

### 信任递进型逻辑
1. 第一屏先建立安全感
2. 第二屏再讲来源与过程
3. 第三屏提供证明材料
4. 最后做安心收口

### 3.3 页面交互策略
#### 建议
- 继续采用单页纵向滚动结构
- 不建议第二阶段上 tab
- 如果后期内容特别多，可考虑“轻锚点导航”，而不是 tab

#### 原因
扫码页不是后台系统页，用户行为是：
- 打开
- 扫一眼
- 往下确认
- 看证明材料

不是：
- 切换 tab
- 主动查不同模块

---

## 4. 第二阶段页面模块设计方案

以下模块顺序为建议实施顺序，也是推荐最终页面展示顺序。

### 4.1 模块一：首屏信任头图（Hero 升级）

#### 4.1.1 模块目标
确保首屏仍然具备“官方溯源页”的气质，但不通过在 Hero 图内叠加大段信任文案来实现。

#### 4.1.2 当前判断
经过页面实际验证后确认：
- 当前顶部 `brandPageHeader` 已具备“官方溯源 / 品质可验”的定调作用
- 当前 Hero 商品图本身已经具备较强的品牌感、品质感与送礼感
- 若在 Hero 图内继续叠加大段信任文案，容易出现：
  - 文案可读性差
  - 遮挡商品主图
  - 信息重复
  - 破坏首屏高级感

因此，第二阶段不建议继续在 Hero 图内新增额外的信任标签、重文案或多行结论文案。

#### 4.1.3 最终策略
模块一保留为“首屏信任感优化”目标，但当前版本的实现策略为：

- 保留现有 `brandPageHeader`
- 保留现有 Hero 商品图表现力
- 保留现有商品信息面板结构
- 不在 Hero 图内额外新增信任标签
- 不在 Hero 图内新增主结论 / 副结论文案

也就是说：

> 首屏的“官方感”和“品质感”由现有页头 + Hero 商品图共同承担，
> 第二阶段真正的信任表达重点下沉到“溯源结论卡”等后续模块。

#### 4.1.4 实现要求
当前版本中，模块一不新增以下内容：
- `heroTrustBlock`
- `heroTrustPill`
- Hero 图内额外标签
- Hero 图内多行信任文案

允许的调整范围仅包括：
- 保持现有 Hero 首屏结构不变
- 如有必要，仅对现有首屏留白、间距、页头与 Hero 之间关系做极轻微优化

#### 4.1.5 设计结论
模块一不是取消，而是经过验证后确认：

- 模块一的目标仍成立：首屏要有“可信的官方气质”
- 但当前最优实现不是“继续加内容”
- 而是“避免重复表达，保持首屏克制”

这是一次经过验证后的设计收敛，而非方案遗漏。

### 4.2 模块二：溯源信息卡（优先级最高）

#### 4.2.1 模块目标
用最短路径同时回答用户两个最关心的问题：

> 这批产品值不值得信任？是不是我手上这一批？

该模块不是只回答"是否检测通过"，而是对本批次产品的溯源信息做一个前置性的综合结论表达，同时让用户快速核对批次编号与关键时间信息。

#### 4.2.2 重要性说明
当前页面虽然已有检测报告、合格证、批次信息等资料，但之前"溯源结论"和"批次信息"是分开的，存在两个问题：

- 用户需要先理解结论，再继续往后寻找"这是不是我手上这一批"的对应信息
- 页面前半部分信息被拆成多个卡片，信任建立路径不够集中

因此，第二阶段当前版本已确认：

> 将原"溯源结论卡"与"批次信息卡"融合为一张"溯源信息卡"，作为首个核心信任卡片。

这张卡片同时承担两类职责：
- 给出本批次产品的可信判断
- 让用户快速核对批次编号与关键时间信息

#### 4.2.3 模块建议位置
建议放在：
- Hero 后
- 商品信息前

推荐顺序：Hero → 溯源信息 → 商品信息 / 农场信息

#### 4.2.4 模块内容建议
标题建议：
- 溯源信息（推荐）

推荐默认使用：
- `溯源信息`

卡片内部采用三层结构：

##### 第一层：批次身份信息（主视觉）
展示内容：
- 批次编号
- 批次号

当前推荐表现：
- 弱标签：`批次编号`
- 主信息：`THY-20260330-001`

说明：
- 批次号是该卡片中的最强识别信息
- 用于让用户与包装标签上的批次号进行核对
- 不建议在批次号前重复增加"批次号："字段式前缀

##### 第二层：关键时间信息（摘要信息）
展示内容：
- 生产/采收日期
- 包装日期

当前推荐表达：
- `生产/采收日期：2026-04-09 ｜ 包装日期：2026-04-10`

说明：
- 使用严谨字段表达，便于用户与商品外包装信息进行核对
- 采用一行摘要形式，而不是表格式字段区

##### 第三层：轻状态标签（结论层）
展示内容：
- `全程可追溯`
- `已通过安全检测`

说明：
- 使用两个轻标签表达结果状态
- 不再使用长句式结论和说明文案
- 不建议继续使用"来源可查 / 检测合格"这类偏电商宣传式文案

#### 4.2.5 视觉建议
- 保留当前 sectionHeader 风格（英文小标题 + 中文主标题）
- 采用"主信息 → 摘要信息 → 状态标签"的三层结构
- 批次号为卡片最强视觉，但不做成页面主标题级别
- 时间信息采用一行摘要，不做表格、不做字段列表卡
- 状态标签使用轻胶囊标签形式，作为结论层
- 整体风格需与当前页面其他卡片保持同一体系，避免像单独做了一种新卡片
- 不再保留原独立"批次信息卡"样式

#### 4.2.6 数据字段建议
当前前端融合卡所需字段主要来自已有批次信息与结论信息，无需为此额外新建复杂字段。

建议字段如下：

| 字段名 | 类型 | 说明 |
|---|---|---|
| `traceConclusion` | string | 溯源主结论，可选；当前融合卡前端版本中已不作为主展示长句 |
| `traceSummary` | string | 溯源补充说明，可选 |
| `batchNo` | string | 批次号 |
| `produceDate` | datetime/date | 生产/采收日期 |
| `packageDate` | datetime/date | 包装日期 |
| `testPassed` | boolean | 是否通过检测，可用于状态标签兜底 |
| `testSourceType` | string | 检测来源类型，如 `self_device` / `third_party` |

前端当前融合卡推荐结构：

```js
traceInfoCard: {
  title: '溯源信息',
  batchLabel: '批次编号',
  batchNo: 'THY-20260330-001',
  summaryLine: '生产/采收日期：2026-04-09 ｜ 包装日期：2026-04-10',
  tags: ['全程可追溯', '已通过安全检测']
}
```

#### 4.2.7 数据来源建议
当前融合卡的数据来源建议如下：

- `batchNo`：来自批次表
- `produceDate`：来自批次表
- `packageDate`：来自批次表
- `testPassed / testSourceType`：来自检测相关扩展字段

说明：
- 当前已确认前端主展示以"批次号 + 日期 + 状态标签"为核心
- 原 `traceConclusion` / `traceSummary` 字段仍可保留，供后续版本扩展使用
- 但当前版本不再以长句结论作为卡片主展示方式

### 4.3 模块三：商品信息（保留，轻增强）

#### 4.3.1 当前状态
当前商品信息模块已较成熟：
- 商品名称
- 规格
- 商品简介
- 右上角状态徽章

#### 4.3.2 第二阶段建议
- 保留当前结构
- 不做大改
- 只增强与“溯源信息卡”的配合关系

#### 4.3.3 优化方向
- 保持商品信息承担“正式介绍商品”的职责
- 不要让商品信息承担“信任主表达”
- 右上角检验合格徽章可继续保留，但做得更弱一点，避免重复抢戏

### 4.4 模块四：农场信息升级为“真实源头背书卡”

#### 4.4.1 当前问题
当前农场信息更像普通资料卡，表达略偏中性。

#### 4.4.2 业务真实情况
当前农场信息不能一味往“高大上智慧农场”方向包装。  
因为实际情况是：
- 多为有机农场
- 也可能来自普通农户或合作农户
- 不一定都有特别强的规模化、示范化背书

#### 4.4.3 第二阶段策略
不强调“高大上基地”，强调：
- 真实源头
- 明确产地
- 现场可见
- 过程可追溯

#### 4.4.4 推荐标题
- 农场信息（可保留）
- 产地来源
- 源头农场

#### 4.4.5 推荐文案方向
- 产品来源于宿州·萧县种植区域
- 产品来自真实种植农户与合作种植基地
- 农场环境、种植过程及检测信息均可追溯

#### 4.4.6 素材建议
优先使用真实素材：
- 田间实景
- 大棚实景
- 采收现场
- 农户作业现场
- 农场门头或识别图

#### 4.4.7 数据字段建议
现有字段基本够用：
- `farmName`
- `farmRegion`
- `farmImage`
- `farmIntro`

可选补充：

| 字段名 | 类型 | 说明 |
|---|---|---|
| `farmType` | string | 如：合作农户 / 自营基地 / 合作基地 |
| `farmTag` | string[] | 如：有机种植 / 标准化管理 / 真实可追溯 |

### 4.5 模块五：关键农事时间轴（第二阶段核心模块）

#### 4.5.1 模块目标
让用户感受到：

> 这批产品是有过程、有管理、有记录地种出来的。

#### 4.5.2 模块定位
时间轴不是后台操作日志，而是消费者可理解的“成长过程”。

#### 4.5.3 当前难点
农事记录数据来自后台农事任务，存在：
- 数据多
- 任务碎
- 类型复杂
- 表达偏后台管理语义

#### 4.5.4 正确策略
主时间轴不直接展示原始农事记录，而是：

> 将农事记录 + 批次信息 + 检测信息，组合为 4–6 个关键阶段节点。

#### 4.5.5 关键时间轴阶段建议
建议主时间轴最多展示以下 6 类阶段：

1. 开始种植
2. 生长期养护
3. 田间巡检 / 健康管理
4. 成熟采收
5. 安全检测
6. 包装出库

如某阶段无数据，则可跳过。

#### 4.5.6 农事记录 → 时间轴节点映射规则表

| 后台任务类型 | 是否参与主时间轴计算 | 归属阶段 | 说明 |
|---|---:|---|---|
| 施肥 | 是 | 生长期养护 | 归入养护类任务 |
| 灌溉 | 是 | 生长期养护 | 归入养护类任务 |
| 除草 | 是 | 生长期养护 | 归入养护类任务，不单独成节点 |
| 打药 | 是 | 生长期养护 | 归入养护类任务，前端不单独突出“打药”表述 |
| 巡检 | 是 | 田间巡检 | 归入巡检类任务 |
| 采摘 | 否 | 系统节点补充 | 使用 produceDate 生成成熟采收节点 |
| 测试 | 否 | 系统节点补充 | 使用 reportDate 生成安全检测节点 |
| 包装相关 | 否 | 系统节点补充 | 使用 packageDate 生成包装出库节点 |
| 其他 | 否 | 不进入主时间轴 | 仅用于更多记录展示 |

【说明】
- 主时间轴不按“任务逐条展示”，而是按“阶段聚合展示”
- 所有农事任务先归类，再映射到阶段
- 生长期养护与田间巡检为两个核心聚合节点
- 除草、打药等任务不单独作为时间轴节点展示
- 时间轴表达的是“过程阶段”，而不是“任务流水”
- 生长期养护节点时间取养护类任务的最早完成时间
- 田间巡检节点时间取巡检类任务的最早完成时间

#### 4.5.7 时间轴节点生成规则

规则 1：主时间轴只展示关键阶段，不按“每条农事记录 = 一个节点”，而是按阶段合并。

规则 2：同类任务合并。  
例如多次灌溉 / 施肥，可合并成一个“生长期养护”节点。

规则 3：后台术语转译为消费者语言。  
例如：
- 施肥 → 营养管理
- 打药 → 健康管理 / 病虫害防控
- 巡检 → 田间巡检

规则 4：优先保留高信任价值节点。  
优先级顺序：
1. 开始种植
2. 生长期养护
3. 田间巡检 / 健康管理
4. 成熟采收
5. 安全检测
6. 包装出库

#### 4.5.8 系统节点补充规则（非常重要）
农事记录本身通常不包含“检测完成”“包装出库”这类高信任节点，因此这两个节点不能强依赖农事记录，而应由系统补充生成。

##### 安全检测节点来源
来源：
- `report.items[].detectDate`

生成节点示例：
```json
{
  "time": "2026-03-31",
  "stage": "test",
  "title": "安全检测",
  "desc": "已完成安全检测，相关结果可查"
}
```

##### 包装节点来源
来源：
- `batch.packTime`（即 `data.packageDate`）

生成节点示例：
```json
{
  "time": "2026-04-01",
  "stage": "pack",
  "title": "包装出库",
  "desc": "已完成包装整理，进入销售流通环节"
}
```

##### 采收节点来源
来源：
- `batch.harvestTime`（即 `data.produceDate`）

生成节点示例：
```json
{
  "time": "2026-03-30",
  "stage": "harvest",
  "title": "成熟采收",
  "desc": "本批次产品进入成熟采收阶段"
}
```

#### 4.5.9 推荐前端展示数据结构
```js
timeline: [
  {
    time: '2026-03-01',
    stage: 'planting',
    title: '开始种植',
    desc: '本批次产品进入种植管理阶段'
  },
  {
    time: '2026-03-18',
    stage: 'care',
    title: '生长期养护',
    desc: '种植期间已持续开展灌溉、施肥等日常养护'
  },
  {
    time: '2026-03-26',
    stage: 'inspection',
    title: '田间巡检',
    desc: '种植期间已开展长势检查与环境巡检'
  },
  {
    time: '2026-03-30',
    stage: 'harvest',
    title: '成熟采收',
    desc: '本批次产品进入成熟采收阶段'
  },
  {
    time: '2026-03-31',
    stage: 'test',
    title: '安全检测',
    desc: '已完成安全检测，相关结果可查'
  },
  {
    time: '2026-04-01',
    stage: 'pack',
    title: '包装出库',
    desc: '已完成包装整理，进入销售流通环节'
  }
]
```

#### 4.5.9.1 节点时间取值规则
种植过程记录统一按以下 6 个节点展示，且各节点时间来源需固定，避免前后端理解不一致：

| 节点 | stage | 时间取值规则 |
|---|---|---|
| 开始种植 | `planting` | 取批次/种植周期的 `plantStartTime`，作为时间轴起点 |
| 生长期养护 | `care` | 取当前批次中“养护类农事任务”的最早完成时间 |
| 田间巡检 | `inspection` | 取当前批次中“巡检类农事任务”的最早完成时间 |
| 成熟采收 | `harvest` | 取批次的 `produceDate` |
| 安全检测 | `test` | 取检测报告中最早的 `reportDate` |
| 包装出库 | `pack` | 取批次的 `packageDate` |

说明：
- 养护类与巡检类节点取“最早完成时间”，目的是表达该批次从何时进入该阶段，而不是最后一次任务发生时间
- 时间轴模块表达的是“关键过程阶段”，不是任务流水记录
- 若某一类任务不存在，则不应伪造该节点时间

#### 4.5.9.2 节点文案口径说明
为避免“时间取最早一次”与“文案像最近一次行为”之间的语义冲突，时间轴文案统一按“阶段表达”处理，不使用“最后一次完成”的表达方式。

推荐文案如下：
- 开始种植：`本批次产品进入种植管理阶段`
- 生长期养护：`种植期间已持续开展灌溉、施肥等日常养护`
- 田间巡检：`种植期间已开展长势检查与环境巡检`
- 成熟采收：`本批次产品进入成熟采收阶段`
- 安全检测：`已完成安全检测，相关结果可查`
- 包装出库：`已完成包装整理，进入销售流通环节`

说明：
- “生长期养护”“田间巡检”属于阶段性节点，文案应强调“已持续开展 / 已开展”，不建议写成“最后一次已完成”
- 这样可以保证时间轴既符合阶段表达逻辑，也符合用户阅读理解

#### 4.5.10 更多农事记录
主时间轴之外，建议保留“查看更多农事记录”入口。

用途：
- 满足查证
- 不打断主页面节奏
- 保留完整真实性

展开内容建议：
- 时间
- 任务类型
- 任务名称
- 任务说明
- 执行人（可选）

#### 4.5.10.1 时间轴节点数量控制与排序规则

为避免时间轴过长、过碎、不可读，主时间轴必须增加数量控制与排序规则。

##### 数量控制
- 主时间轴建议展示 4–6 个节点
- 当原始农事记录与系统节点合并后超过 6 个时，按优先级裁剪
- 优先保留的节点顺序为：
  1. 开始种植
  2. 生长期养护
  3. 田间巡检 / 健康管理
  4. 成熟采收
  5. 安全检测
  6. 包装出库

##### 同阶段合并规则
- 同阶段出现多条记录时，不逐条展示
- 应合并为一个阶段节点，并提炼成一句消费者可理解的话术
- 同阶段节点取该阶段对应任务的最早完成时间作为展示时间

##### 排序规则
- 主时间轴统一按时间升序排列
- 当出现同一天多个节点时，建议排序优先级为：
  1. 开始种植
  2. 生长期养护
  3. 田间巡检 / 健康管理
  4. 成熟采收
  5. 安全检测
  6. 包装出库

##### 缺失数据处理规则
- 若无开始种植节点，优先补齐批次字段 `plantStartTime`；在未补齐前可临时从最早一条有效农事记录开始展示
- 若无检测结果日期或可用检测记录，则不生成“安全检测”节点
- 若无包装时间，则不生成“包装出库”节点
- 主时间轴不强行为凑满 6 个节点而制造虚假节点

### 4.6 模块六：实时监控画面

#### 4.6.1 模块目标
把“真实种植现场”呈现出来，形成最直接的可信感。

#### 4.6.2 为什么重要
这是第二阶段最具差异化的模块之一，用户看到实时现场会明显增强真实感。

#### 4.6.3 展示原则
- 不强调“摄像头”，强调“现场可见”
- 不讲技术术语，讲“当前画面”“实时可见”

#### 4.6.4 推荐标题
- 种植现场实时画面
- 当前农场监控画面

#### 4.6.5 推荐文案
- 当前为农场种植区实时画面
- 现场环境与种植状态可见

#### 4.6.6 展示方式建议
第一版推荐：
- 视频窗口
- 在线状态
- 轻说明

如果视频流接入稳定，可直接嵌实时视频。  
如果考虑移动端性能，也可先使用封面图 + 点击播放。

#### 4.6.7 数据字段建议

| 字段名 | 类型 | 说明 |
|---|---|---|
| `camera.liveUrl` | string | 实时视频流地址 |
| `camera.coverImage` | string | 封面图 |
| `camera.status` | string | online / offline |
| `camera.desc` | string | 辅助说明 |

### 4.7 模块七：种植环境记录（历史背书优先）

#### 4.7.1 当前风险
如果把“当前实时环境数据”作为主表达，会存在明显问题：
- 用户看到的是已采摘、已发货的产品
- 当前实时环境并不能直接为历史种植过程背书
- 容易让用户误解为“现在的环境”就是“当时的生长环境”

因此，第二阶段环境模块不应以“当前实时数据”作为主展示逻辑，而应以：

> 历史种植环境记录 + 当前环境摘要

的方式进行表达。

#### 4.7.2 正确策略
> 先给历史环境结论，再用趋势图与摘要做佐证。

其中：
- 历史环境记录是主表达
- 当前实时环境仅作为辅助参考

#### 4.7.3 推荐展示形式
标题：
- 种植环境记录（推荐）
- 生长环境记录

推荐默认使用：
- `种植环境记录`

模块内部建议分为三层：

##### 第一层：环境结论
主结论示例：
- 本批次种植期环境稳定，整体处于适宜生长区间
- 种植期内环境指标整体平稳，处于适宜生长区间

##### 第二层：核心趋势图（主视觉）
以一张“土壤养分综合趋势图”作为主视觉，重点展示：
- 氮（N）
- 磷（P）
- 钾（K）

表达目标：
- 体现土壤养分在种植周期内整体稳定
- 体现养分管理较为均衡
- 强化“这批产品是被持续管理出来的”感知

##### 第三层：环境摘要（辅助信息）
摘要项仅展示用户较容易理解、且对信任感有帮助的 4 项：
- 气温
- 湿度
- 降雨量
- 光照
前端当前展示口径为：平均气温、平均湿度、累计降雨量、光照结论。

不建议在主展示中加入：
- 风速
- 风向
- 气压

因为这些数据对普通用户感知弱，容易增加理解负担，但对信任表达帮助有限。

#### 4.7.4 是否加入曲线图
结论：建议加入，但曲线图主角不再是温度/湿度，而是土壤养分（N/P/K）综合趋势。

推荐方案：
- 只做 1 张综合趋势图
- 图中展示 N / P / K 三条趋势线
- 横轴为种植周期时间
- 纵轴为对应养分值
- 如条件允许，可增加“适宜区间”浅色带作为辅助

这样既能控制页面长度，又能明显提升专业感与可信度。

#### 4.7.5 视觉建议
- 土壤养分综合趋势图作为主视觉区域
- 线条保持轻量、细腻，不做重数据大屏风格
- N / P / K 三条线颜色需区分，但保持低饱和度
- 可弱化坐标轴与网格线，避免技术感过强
- 4 个环境摘要项作为辅助信息，位于趋势图下方或下一区域
- 不建议同时展示多张环境曲线图，避免页面过长、注意力分散

#### 4.7.6 数据结构建议
```js
environment: {
  summary: '本批次种植期环境稳定，整体处于适宜生长区间',
  chart: {
    type: 'npk_trend',
    sourceTable: 'weather_data_statistics',
    values: {
      n: [],
      p: [],
      k: []
    }
  },
  items: [
    { label: '气温', value: '22.3℃', status: '种植期平均' },
    { label: '湿度', value: '45%', status: '种植期平均' },
    { label: '降雨量', value: '118mm', status: '种植期累计' },
    { label: '光照', value: '充足', status: '表现稳定' }
  ]
}
```

#### 4.7.7 数据库 / 接口建议
种植环境模块统一基于：
- `weather_data_statistics`

该表为聚合统计表，前端环境模块不直接读取原始设备时序数据。

当前页面展示所需的数据包括：
- 土壤养分趋势图：氮 / 磷 / 钾
- 平均气温
- 平均湿度
- 累计降雨量
- 光照结论

建议后端在聚合接口中直接返回：

| 字段名 | 类型 | 说明 |
|---|---|---|
| `environmentSummary` | string | 种植环境结论文案 |
| `environmentChart` | json | 土壤养分综合趋势图数据（N/P/K） |
| `environmentItems` | json | 环境摘要项（平均气温/平均湿度/累计降雨量/光照结论） |
| `environmentRaw` | json | 可选，返回聚合原始值用于排查，如平均光照值 |

#### 4.7.8 统计时间范围规则
种植环境数据的统计时间范围统一定义为：

- 起点：开始种植时间（`plantStartTime`）
- 终点：成熟采收时间（`harvestTime`）

不使用包装出库时间作为环境统计结束时间。

环境数据用于描述作物生长过程，作物在采收后已脱离生长环境，包装出库属于流通阶段，不应继续计入种植环境统计。

#### 4.7.9 指标统计口径说明
当前页面中的环境数据展示口径统一为：

- 氮 / 磷 / 钾：种植期区间趋势
- 气温：种植期平均
- 湿度：种植期平均
- 降雨量：种植期累计
- 光照：种植期光照结论（非实时值）

说明：
- 前端展示的是“种植期统计结果”
- 不是实时环境数据

#### 4.7.10 光照结论映射规则
当前光照展示为：

- value：充足
- status：表现稳定

后端计算规则：

- 数据来源：`weather_data_statistics` 日聚合表
- 日口径：当日非 0 光照值平均（单位：lux）
- 周期口径：种植期内日均值再平均，得到：`cycleLightAvg`

结论映射（面向消费者的简化展示规则）：

- `cycleLightAvg < 8000 lux` → `lightLevel = 偏弱`，`lightStatus = 光照较弱`
- `8000 ≤ cycleLightAvg < 20000 lux` → `lightLevel = 适宜`，`lightStatus = 整体平稳`
- `20000 ≤ cycleLightAvg ≤ 50000 lux` → `lightLevel = 充足`，`lightStatus = 表现稳定`
- `cycleLightAvg > 50000 lux` → `lightLevel = 充足`，`lightStatus = 光照偏强`

对应关系说明：
- 后端根据 `cycleLightAvg` 按 lux 阈值规则生成前端展示文案

推荐返回结构示例：
```json
{
  "cycleLightAvg": 24000,
  "lightLevel": "充足",
  "lightStatus": "表现稳定"
}
```

前端展示对应关系：
- `cycleLightAvg`：后端计算出的种植期平均光照值，仅用于排查或后台查看，可不直接展示给消费者
- `lightLevel`：前端 `value` 展示值，对应“偏弱 / 适宜 / 充足”
- `lightStatus`：前端 `status` 展示值，对应“表现稳定”等辅助描述

- 本规则第一版采用基于 lux 的简化映射方式，展示语气更接近日常天气类表达，便于消费者理解
- 阈值区间参考常见自然光照强度范围，属于面向消费者展示的“合理分档”，不强调农业专业术语，也不用于农业精细化控制
- 后端应负责输出“平均光照数值 + 光照等级文案 + 状态文案”三层结果
- 前端最终展示 `lightLevel` 与 `lightStatus`，不负责做 lux → 文案 的阈值判断
### 4.8 模块八：批次信息（已并入溯源信息卡）

#### 4.8.1 当前结论
原独立"批次信息卡"已不再保留，相关核心信息已并入前部"溯源信息卡"。

#### 4.8.2 合并原因
这样调整的原因包括：
- 用户在页面前半部分就能完成"这是不是我手上这一批"的核对
- 减少卡片数量，避免页面前半部分被拆碎
- 让"信任建立"和"批次核验"合并为一个完整路径

#### 4.8.3 当前保留内容
已并入溯源信息卡的字段包括：
- 批次编号
- 批次号
- 生产/采收日期
- 包装日期

当前不再在融合卡中展示：
- 种植时间（已在种植过程记录中体现）
- 产地（已在农场信息中体现）
- 规格（已在商品信息中体现）

### 4.9 模块九：检测报告（证明层）

#### 4.9.1 建议
保留当前横向滑动卡片列表。

#### 4.9.2 第二阶段定位
检测报告是“证据层”，不是“主结论层”。

#### 4.9.3 原则
- 保留“点击查看大图”
- 不再强调报告本身
- 通过前面的溯源信息卡，先让用户理解“结果”
- 再通过这里让用户验证“材料”

### 4.10 模块十：合格证（证明层）

#### 4.10.1 建议
保持当前单证小图模式，不放大，不复杂化。

#### 4.10.2 目的
作为信任补充证明材料，和检测报告共同构成证据层。

### 4.11 模块十一：底部安心收口

#### 4.11.1 当前问题
当前 footer 已经有客服电话和品牌签名，但结束稍显平淡。

#### 4.11.2 建议新增一行轻收口文案
例如：
- 本产品已完成全流程溯源记录，信息真实可查，请放心食用。

#### 4.11.3 当前 footer 可继续保留
- 联系客服
- 电话
- 品牌签名

#### 4.11.4 推荐签名文案
- 佳友厚苑 · 安心之选
- 佳友厚苑 · 源头可见
- 佳友厚苑 · 溯源可鉴

---

## 5. 第二阶段推荐模块顺序

最终推荐页面顺序如下：

1. 品牌页头
2. Hero 首屏延续现状（不新增额外信任标签或重文案）
3. 溯源信息卡（由溯源结论与批次信息融合）
4. 商品信息
5. 农场信息
6. 关键农事时间轴
7. 种植现场实时画面
8. 种植环境记录
9. 检测报告
10. 合格证
11. 收口说明 + footer

---

## 6. 数据结构与接口设计建议

### 6.1 溯源页主接口建议
建议继续使用一个聚合接口，例如：
- `getTraceDetail(batchId)`

但返回数据要扩展。

#### 建议返回结构
```json
{
  "product": {},
  "farm": {},
  "batch": {}, // 批次号、生产/采收日期、包装日期等
  "report": {},
  "certificate": {},
  "timeline": [],
  "farmTasks": [],
  "camera": {},
  "environment": {},
  "traceConclusion": "",
  "traceSummary": ""
}
```

### 6.2 字段增补建议

#### 新增字段：溯源信息 / 溯源结论扩展
| 字段名 | 类型 | 说明 |
|---|---|---|
| `traceConclusion` | string | 溯源主结论 |
| `traceSummary` | string | 溯源补充说明 |
| `testPassed` | boolean | 是否通过检测 |
| `testOrganization` | string | 检测机构名称或检测来源说明 |
| `testSourceType` | string | 检测来源类型，如 `self_device` / `third_party` |

#### 新增字段：时间轴
| 字段名 | 类型 | 说明 |
|---|---|---|
| `timeline` | json/array | 关键时间轴节点（由批次信息、农事任务、检测报告、包装信息聚合生成） |
| `plantStartTime` | datetime/date | 开始种植时间，作为种植过程记录时间轴起点 |
| `farmTasks` | json/array | 原始农事记录列表 |

#### 新增字段：实时监控
| 字段名 | 类型 | 说明 |
|---|---|---|
| `cameraLiveUrl` | string | 实时流地址 |
| `cameraCover` | string | 封面图 |
| `cameraStatus` | string | 在线状态 |

#### 新增字段：种植环境记录
| 字段名 | 类型 | 说明 |
|---|---|---|
| `environmentSummary` | string | 种植环境结论 |
| `environmentItems` | json | 环境摘要项（平均气温/平均湿度/累计降雨量/光照结论） |
| `environmentChart` | json | 土壤养分综合趋势图数据，来源于 `weather_data_statistics` |
| `environmentRaw` | json | 可选，返回聚合原始值用于排查，如平均光照值 |

### 6.3 缺省数据与前端兜底策略

第二阶段页面涉及多个新增模块，后端字段可能存在分阶段补齐的情况，因此前端必须设计缺省数据兜底策略。

#### 溯源信息卡
- 若 `batchNo` 为空，则该模块整体不展示
- 不建议在前端写死“第三方检测”等具体来源类文案；
-“已通过安全检测”可作为状态标签展示，但需以后端真实字段为准
- 若仅 `produceDate` / `packageDate` 缺失，可仅展示批次号与状态标签
- 不建议因为 `traceConclusion` 为空就隐藏整张卡
- 当前前端主展示以“批次号 + 日期 + 状态标签”为核心，`traceConclusion` / `traceSummary` 为可选扩展字段

#### 农事时间轴
- 若无农事记录，但有采收 / 检测 / 包装等系统节点，则仍可展示简化版时间轴
- 若农事记录与系统节点都为空，则隐藏时间轴模块
- 真实接口场景下，若后端未返回时间轴或可用于生成时间轴的真实数据，前端不得直接回退展示 mock 农事过程

#### 实时监控画面
- 若 `camera.liveUrl` 为空但 `camera.coverImage` 有值，则展示封面图模式
- 若监控数据整体为空，则隐藏该模块

#### 种植环境记录
- 若仅有 summary，无具体 items / charts，则只展示结论文案
- 若 summary、items、charts 全为空，则隐藏该模块

#### 检测报告 / 合格证
- 延续第一阶段逻辑：无数据时展示“待补充”或直接隐藏，由产品最终确定

#### 总体原则
- 前端不得为了页面完整性伪造关键可信信息
- 对于“检测通过”“实时在线”“环境正常”等结论性内容，必须以真实字段为准

---

## 7. 数据库字段增补建议

> 目标：支持第二阶段页面展示，但避免一次性扩表过度。

### 7.1 批次表（建议已有字段复用）
建议确认并继续使用以下字段：

| 字段名 | 类型 | 说明 |
|---|---|---|
| `batch_no` | varchar | 批次号 |
| `produce_date` | datetime/date | 生产/采收时间 |
| `package_date` | datetime/date | 包装时间 |
| `status` | varchar | 批次状态 |
| `product_name` | varchar | 商品名称 |
| `product_spec` | varchar | 商品规格 |
| `product_desc` | text | 商品简介 |
| `product_image` | varchar | 商品图片 |
| `farm_name` | varchar | 农场名称 |
| `farm_region` | varchar | 农场地区 |
| `farm_image` | varchar | 农场图片 |
| `farm_intro` | text | 农场介绍 |

### 7.2 溯源结论扩展表 / 扩展字段（建议新增）
可新建扩展表，也可挂在批次表上。推荐扩展表：`trace_batch_extra`

| 字段名 | 类型 | 说明 |
|---|---|---|
| `id` | bigint | 主键 |
| `batch_id` | bigint | 批次 ID |
| `trace_conclusion` | varchar(500) | 溯源主结论 |
| `trace_summary` | varchar(500) | 溯源补充说明 |
| `test_passed` | tinyint | 是否检测通过 |
| `test_organization` | varchar(200) | 检测机构或检测来源说明 |
| `test_source_type` | varchar(50) | 检测来源类型，如 self_device / third_party |
| `camera_live_url` | varchar(500) | 实时视频流地址 |
| `camera_cover` | varchar(500) | 监控封面图 |
| `camera_status` | varchar(20) | 摄像头状态 |
| `environment_summary` | varchar(500) | 种植环境结论 |
| `environment_items` | text/json | 环境摘要项（平均气温/平均湿度/累计降雨量/光照结论） |
| `environment_chart` | text/json | 土壤养分综合趋势图数据，来源于 weather_data_statistics |
| `environment_raw` | text/json | 可选，返回聚合原始值用于排查，如平均光照值 |
| `plant_start_time` | datetime/date | 开始种植时间，作为环境统计起点 |
| `harvest_time` | datetime/date | 成熟采收时间，作为环境统计终点 |
| `footer_statement` | varchar(500) | 页底收口文案，可选 |

### 7.3 农事记录表（优先复用）
建议复用现有农事记录表，无需为第二阶段专门新建。

建议前端所需字段至少包括：

| 字段名 | 类型 | 说明 |
|---|---|---|
| `task_name` | varchar | 任务名称 |
| `task_type` | varchar | 任务类型 |
| `farm_id` | bigint | 所属农场 |
| `plot_id` | bigint | 所属地块 |
| `operator_name` | varchar | 执行人 |
| `crop_name` | varchar | 作物名称 |
| `task_status` | varchar | 任务状态 |
| `plan_start_time` | datetime | 计划开始时间 |
| `plan_end_time` | datetime | 计划完成时间 |
| `task_desc` | text | 任务说明 |

### 7.4 原始农事记录查询接口建议
建议提供一个按批次/农场/作物过滤后的农事记录查询接口，供前端或聚合接口使用。

例如：
- 根据批次 ID 查询关联农事记录
- 或根据农场 + 作物 + 时间范围查询

---

## 8. 开发实施建议

### 8.1 开发优先级建议
#### P1
- 溯源信息卡
- 时间轴模块

#### P2
- 实时监控画面
- 种植环境记录

#### P3
- 土壤养分综合趋势图
- 更多农事记录展开
### 8.2 前端实施策略
建议基于当前 `detail.vue`：

- 继续复用 card 体系
- 新增模块，不推翻结构
- 通过 computed 对新字段做兼容
- mock 数据先行，后续联调替换

### 8.3 后端实施策略
建议后端分两步：

#### 第一步
先补字段并返回 mock / 半真实数据：
- traceConclusion
- timeline
- camera
- environment

#### 第二步
再接入真实数据聚合：
- 农事记录
- 摄像头实时流
- 设备环境状态
- 溯源结论文案生成 / 检测结论解析

### 8.4 联调建议

#### 联调顺序建议
1. 溯源信息卡
2. 时间轴聚合逻辑
3. 实时监控画面
4. 种植环境记录
5. 报告 / 合格证与第二阶段模块的顺序联调

#### 联调原则
- 先打通字段与接口，再优化文案与样式细节
- 先保证“有无逻辑”正确，再优化“展示效果”
- 时间轴联调时必须重点验证：
  - 同类任务是否正确合并
  - 系统节点是否正确拼入
  - 节点顺序是否正确
  - 超过 6 条时是否正确裁剪
  - 无真实时间轴数据时是否正确隐藏模块，而不是回退展示 mock 节点

### 8.5 开发推进策略（前端先行，但非原型）

本项目第二阶段采用“前端先行”的开发策略，但需特别强调：

> 本阶段前端不是原型开发，而是直接开发可上线的正式页面。

#### 8.5.1 开发阶段划分

##### 阶段一：前端页面落地开发（非原型）
目标：
- 完成第二阶段所有页面模块的真实开发（非原型）
- 页面结构、样式、交互均按正式上线标准实现
- 使用 mock 数据或前端示例数据填充

本阶段重点：
- 验证“信任感是否成立”
- 验证模块组合是否合理
- 验证页面节奏（是否冗长 / 是否跳跃 / 是否像后台）

注意事项：
- 不允许使用低保真原型结构（如占位框、简化布局）
- 所有模块需按最终 UI 标准开发
- 文案需接近最终运营版本（可后续微调）

##### 阶段二：运营 & 老板评审
目标：
- 确认页面是否达到“第一眼可信”的目标
- 确认内容表达是否符合运营使用习惯

评审重点问题建议：
- 第一屏是否让人产生安全感
- 哪个模块最有信任感
- 哪个模块显得多余或干扰
- 文案是否过于技术化或不接地气
- 页面是否有“真实感”而不是“系统感”

##### 阶段三：方案冻结（非常关键）
目标：
- 确认最终模块结构
- 确认字段需求
- 确认展示逻辑

原则：
- 页面结构一旦确认，不再大改
- 避免在联调阶段频繁调整页面结构

##### 阶段四：后端接口开发
目标：
- 根据已确认页面补充字段与接口
- 提供聚合数据结构

开发重点：
- 溯源结论字段
- 时间轴聚合逻辑
- 摄像头数据
- 种植环境记录聚合

##### 阶段五：前后端联调
目标：
- 数据与页面完全对齐
- 校验所有兜底逻辑

联调重点：
- 时间轴节点是否正确合并与排序
- 无数据时页面是否合理隐藏模块
- 溯源结论与检测来源、报告材料是否一致
- 实时监控状态是否真实反映

---

#### 8.5.2 前端开发数据策略

为提高开发效率，建议前端阶段采用三套数据策略：

##### 1. 理想数据（全量）
用于展示最佳效果：
- 完整时间轴
- 有检测结论
- 有实时视频
- 有环境状态与趋势图

##### 2. 常规数据（部分缺失）
用于验证页面健壮性：
- 无视频或无趋势图
- 有时间轴 + 报告

##### 3. 缺省数据（极端情况）
用于验证兜底逻辑：
- 无检测结论
- 无时间轴
- 无环境数据

要求：
- 三种状态页面都必须表现正常
- 不允许出现“空白块”“占位尴尬”“结构断裂”

---

#### 8.5.3 本阶段核心目标再次强调

第二阶段前端开发的核心目标不是“功能完成”，而是：

- 是否让用户第一眼产生信任感
- 是否让用户快速理解“安全 / 真实 / 新鲜”
- 是否避免页面呈现为后台系统或数据面板

最终标准：

> 用户扫码打开页面后，不需要解释，就能感知“这批产品是可信的”。

---

## 9. 风险点与注意事项

### 9.1 不要把页面做成数据看板
重点是信任，而不是设备展示。

### 9.2 不要直接展示过多原始农事记录
主时间轴必须提炼，原始记录仅用于展开查证。

### 9.3 不要把“打药”原词直接做主节点
应转译为“健康管理 / 病虫害防控管理”。

### 9.4 不要过度堆卡片
内容多时优先靠模块层级和收纳，不先上 tab。

### 9.5 不要打破第一阶段视觉风格
第二阶段是在第一阶段上增强，而不是重做。

### 9.6 不要让“当前实时环境”冒充“历史种植环境”
环境模块若作为溯源背书，主表达必须优先使用历史记录或种植周期聚合结果，避免让用户误以为“当前天气”就是“当时环境”。

---

## 10. 验收标准

第二阶段完成后，页面应满足以下验收标准：

### 10.1 体验层
- 用户打开页面后第一屏即可感知“安全、可信”
- 页面整体不冗长、不杂乱
- 所有新增模块都能自然融入现有风格

### 10.2 内容层
- 能看到融合后的溯源信息卡（含批次核验信息）
- 能看到关键种植过程
- 能看到实时现场
- 能理解环境状态
- 能继续查看检测报告、合格证

### 10.3 业务层
- 支持普通消费者快速判断“能不能放心买”
- 支持高端用户快速建立送礼信任感
- 保持后续第三阶段“能卖”的承接空间

### 10.4 数据真实性验收
- 溯源结论文案必须与真实检测结果、检测来源及页面材料一致
- 时间轴节点不得伪造不存在的种植过程
- 未接入真实农事记录或系统节点时，不得以前端 mock 时间轴替代真实过程展示给用户
- 实时监控若为封面图或非实时模式，前端文案不得误导为“实时”
- 种植环境记录结论必须与真实设备数据或后端聚合结论一致
- 产地、批次、检测报告、合格证之间的批次关联必须一致

---

## 11. 最终结论

第二阶段不是简单加功能，而是围绕“安全、新鲜、真实”三件事，完成一次信任表达升级。

### 第二阶段要做的本质
- 把数据转成结论
- 把功能转成场景
- 把资料页升级成信任页

### 最终目标
> 让用户扫码打开页面后，不只是“看见很多资料”，而是“愿意相信这批产品”。

---

## 12. 第二阶段前端开发拆解清单

> 本章节用于指导第二阶段前端页面的实际开发落地，适用于前端开发人员、Cursor 辅助开发以及后续联调前的自查。

### 12.1 开发目标说明

第二阶段前端开发不是做低保真原型，而是直接开发可上线的正式页面。  
因此拆解清单不仅关注“做哪些模块”，也关注：

- 模块顺序是否正确
- 信息层级是否合理
- 信任感是否成立
- 缺省状态是否可用
- 后续联调是否方便

---

## 12.2 页面模块开发顺序建议

建议按以下顺序逐步开发，而不是一次性同时改完整个页面：

### 第一批（优先落地，最快形成第二阶段效果）
1. 溯源信息卡
2. 关键农事时间轴
3. 首屏与后续模块衔接细节校准

### 第二批（强化真实感与差异化）
4. 种植现场实时画面
5. 种植环境记录

### 第三批（整体验收与细节增强）
6. 检测报告与合格证顺序校准
7. 页脚安心收口增强
8. 缺省状态与兜底逻辑处理

---

## 12.3 前端组件 / 模块拆解建议

建议在当前 `detail.vue` 基础上按模块拆分开发思路推进，即使不立即拆成独立组件，也应按组件思维组织代码。

### 模块 A：首屏信任感收敛优化

#### 目标
确保首屏具备“官方溯源页”的气质，但不通过在 Hero 图上继续叠加额外标签或文案来实现。

#### 当前结论
经过实际页面验证，已确认：
- 顶部 `brandPageHeader` 已承担“官方溯源”的定调作用
- Hero 商品图本身已承担品牌感、品质感与高端感表达
- 继续在 Hero 图内增加额外标签或结论文案，会造成信息重复与视觉干扰

#### 本模块当前需完成内容
- 保持首屏现有结构不变
- 不新增 `heroTrustBlock` / `heroTrustPill` 等额外元素
- 如有必要，仅微调页头与 Hero 的节奏关系、留白、间距

#### 开发检查点
- 首屏是否仍然一眼能感知“官方感”
- Hero 商品图是否仍然保持主视觉地位
- 是否避免了重复表达“官方溯源”
- 是否没有因为新增元素而破坏高级感

### 模块 B：溯源信息卡

#### 目标
作为页面前半部分的首个核心信任卡片，同时完成"信任建立"与"批次核验"。

#### 需完成内容
- 将原"溯源结论卡"与"批次信息卡"融合为一个模块
- 标题调整为：溯源信息
- 展示批次编号与批次号
- 展示生产/采收日期与包装日期摘要
- 展示轻状态标签（如：全程可追溯、已通过安全检测）
- 删除原独立"批次信息卡"

#### 推荐前端数据结构
```js
traceInfoCard: {
  title: '溯源信息',
  batchLabel: '批次编号',
  batchNo: 'THY-20260330-001',
  summaryLine: '生产/采收日期：2026-04-09 ｜ 包装日期：2026-04-10',
  tags: ['全程可追溯', '已通过安全检测']
}
```

#### 当前前端实现口径
- 批次号作为该卡片中的主视觉信息
- 时间信息使用一行摘要表达：生产/采收日期：xxxx ｜ 包装日期：xxxx
- 状态信息使用两个轻标签，不再使用长句式结论和说明
- 不再单独保留"批次信息卡"

#### 开发检查点
- 是否已将原"批次信息卡"完全并入
- 批次号是否为卡片中的最强识别信息
- 时间信息是否使用一行摘要表达，而不是表单式字段列表
- 标签文案是否为状态表达，而非营销口号
- 是否避免在该卡中重复展示产地、规格、种植时间等其他模块已有信息

---

### 模块 C：农场信息卡优化

#### 目标
将当前农场资料卡提升为“真实源头背书卡”。

#### 需完成内容
- 保留现有农场图片、名称、地址、简介结构
- 优化简介表达，使其更偏“真实来源”而非“高大上基地宣传”
- 必要时补充轻标签（如：真实产地 / 可追溯）

#### 开发检查点
- 避免过度包装为大型智慧农场
- 图片优先体现“真实感”而不是“概念感”
- 文案应更强调来源、产地、过程可查

---

### 模块 D：关键农事时间轴

#### 目标
将农事记录转化为消费者可理解的成长过程。

#### 需完成内容
- 新增时间轴卡片
- 根据当前设计方案中的映射规则生成时间轴数据
- 支持最多展示 4–6 个关键节点
- 可预留“查看更多农事记录”入口

#### 推荐前端数据结构
```js
timeline: [
  {
    time: '2026-03-01',
    stage: 'planting',
    title: '开始种植',
    desc: '本批次产品进入种植管理阶段'
  },
  {
    time: '2026-03-18',
    stage: 'care',
    title: '生长期养护',
    desc: '种植期间已持续开展灌溉、施肥等日常养护'
  },
  {
    time: '2026-03-26',
    stage: 'inspection',
    title: '田间巡检',
    desc: '种植期间已开展长势检查与环境巡检'
  },
  {
    time: '2026-03-30',
    stage: 'harvest',
    title: '成熟采收',
    desc: '本批次产品进入成熟采收阶段'
  },
  {
    time: '2026-03-31',
    stage: 'test',
    title: '安全检测',
    desc: '已完成安全检测，相关结果可查'
  },
  {
    time: '2026-04-01',
    stage: 'pack',
    title: '包装出库',
    desc: '已完成包装整理，进入销售流通环节'
  }
]
```

#### 前端实现建议
- 前期可先用 mock timeline 数据做页面展示验证
- 后期联调时应由 `farmTasks + batch + report` 计算生成
- 真实接口场景下，若缺少真实时间轴数据，不得直接回退展示 mock timeline
- `planting` 节点应明确取 `plantStartTime`
- `care` 节点应取养护类任务的最早完成时间
- `inspection` 节点应取巡检类任务的最早完成时间
- 时间轴文案应采用“阶段表达”，不使用“最后一次任务完成”口径
- 若某些系统节点缺失，应按文档中的缺失规则隐藏或简化

#### 开发检查点
- 时间轴不能做成后台操作日志样式
- 不允许逐条展示所有农事记录
- 必须有数量控制与排序控制
- 时间轴为空时应整体隐藏或显示简化版
- `planting` 是否明确取 `plantStartTime`
- `care` 是否取养护类任务的最早完成时间，而不是最后一次时间
- `inspection` 是否取巡检类任务的最早完成时间，而不是最后一次时间
- 时间轴文案是否采用“阶段表达”而不是“最近一次任务表达”

---

### 模块 E：种植现场实时画面

#### 目标
用“现场可见”强化真实可信感。

#### 需完成内容
- 新增实时画面卡片
- 支持视频流模式
- 支持封面图兜底模式
- 支持在线 / 离线状态展示

#### 推荐前端数据结构
```js
camera: {
  liveUrl: '',
  coverImage: '',
  status: 'online',
  desc: '当前为农场种植区实时画面'
}
```

#### 前端实现建议
- 第一版先保证卡片结构正确
- 如果视频能力已成熟，可直接接已有方案
- 若 `liveUrl` 缺失，则自动回退为封面图模式

#### 开发检查点
- 文案不强调“摄像头”，强调“现场画面”
- 不要把该模块做成监控控制台
- 若为非实时模式，文案不得误导为实时

---

### 模块 F：种植环境记录

#### 目标
把环境数据转成“历史背书”，而不是简单展示当前实时数值。

#### 需完成内容
- 新增种植环境记录卡
- 展示环境总结文案
- 展示 1 张土壤养分综合趋势图
- 展示 4 个环境摘要项（气温/湿度/降雨量/光照）
- 可选展示“当前环境参考”作为辅助信息

#### 推荐前端数据结构
```js
environment: {
  summary: '本批次种植期环境稳定，整体处于适宜生长区间',
  chart: {
    type: 'npk_trend',
    sourceTable: 'weather_data_statistics',
    values: {
      n: [],
      p: [],
      k: []
    }
  },
  items: [
    { label: '气温', value: '22.3℃', status: '种植期平均' },
    { label: '湿度', value: '45%', status: '种植期平均' },
    { label: '降雨量', value: '118mm', status: '种植期累计' },
    { label: '光照', value: '充足', status: '表现稳定' }
  ]
}
```

#### 数据来源与统计规则
- 数据来源：`weather_data_statistics`
- 时间范围：`plantStartTime ~ harvestTime`

当前展示口径：
- 氮磷钾：趋势
- 气温：平均
- 湿度：平均
- 降雨：累计
- 光照：结论（后端返回）

光照由后端计算，不由前端判断。
后端建议同时返回平均光照数值（如 `cycleLightAvg`）以及映射后的展示文案（如 `lightLevel`、`lightStatus`），前端仅负责展示文案结果。
光照文案整体表达风格应偏消费者理解口径，更接近日常天气描述，不需过多强调农业专业术语。

#### 前端实现建议
- 第一版先完成 summary + 1 张土壤养分综合趋势图 + 4 个环境摘要项
- 当前实时环境数据不作为主表达，只作为辅助参考信息
- 图表建议单独封装为轻趋势图子模块
- 若仅有 summary，无 chart / items，则只展示 summary

#### 开发检查点
- 是否表达的是“历史种植环境”
- NPK 是否为主视觉
- 是否只保留 4 个环境项（平均气温/平均湿度/累计降雨量/光照结论）
- 数据是否来自 `weather_data_statistics`
- 时间范围是否为种植 → 采收
- 光照是否由后端返回结论

---

### 模块 G：批次信息角色调整（已合并）

#### 目标
确认"批次信息"在第二阶段中不再作为独立卡片存在，而是以前部融合信息的方式呈现。

#### 当前结论
- 批次信息不再单独成卡
- 批次核验信息前移并融入"溯源信息卡"
- 页面后半部分不再重复展示同一组批次字段

#### 开发检查点
- 页面中是否已删除独立批次信息卡
- 批次号 / 生产采收日期 / 包装日期是否已在前部融合卡中正确展示
- 是否避免重复展示造成信息冗余

---

### 模块 H：检测报告与合格证证明层整理

#### 目标
让检测报告与合格证作为证明材料存在，而不是抢主结论。

#### 需完成内容
- 保持当前报告横滑卡片与合格证单证模式
- 校准两者在页面中的出现顺序
- 确保前面已有溯源信息卡后，材料层逻辑自然成立

#### 开发检查点
- 不要再次放大报告与合格证的视觉权重
- 继续保持“点击查看大图”逻辑
- 与第二阶段新模块之间的节奏要顺

---

### 模块 I：页脚安心收口

#### 目标
让页面结尾不突兀，形成“安心结束”的感觉。

#### 需完成内容
- 在现有 footer 上方新增一行轻收口文案
- 保留客服电话与品牌签名
- 校准页尾留白与整体节奏

#### 推荐收口文案
- 本产品已完成全流程溯源记录，信息真实可查，请放心食用。

#### 开发检查点
- 页尾不能突然结束
- 不要做成重按钮区域
- 应保持当前第一阶段的克制风格

---

## 12.4 前端开发文件级任务拆解建议

建议以当前 `pages/trace/detail.vue` 为主文件推进，并视需要拆出子组件。

### 推荐拆解方式（建议，但不强制）

#### 方案 A：先在 `detail.vue` 内完成全部模块
适合：
- 先快速确认页面效果
- 便于统一调整顺序和节奏

#### 方案 B：边开发边提炼子组件
推荐可拆分子组件如下：
- `TraceHeroTrust.vue`
- `TraceInfoCard.vue`
- `TraceTimeline.vue`
- `TraceCameraCard.vue`
- `TraceEnvironmentCard.vue`
- `TraceFooterStatement.vue`

### 建议优先
先在 `detail.vue` 内完成版面，老板确认后再酌情抽组件，避免过早拆分影响迭代速度。

---

## 12.5 页面开发验收清单（前端阶段）

### 第一屏验收
- 是否一眼看出是品牌官方溯源页面
- 首屏是否保持克制，而没有重复堆叠“官方溯源”信息
- Hero 商品图是否仍然是首屏主视觉
- 是否仍保持当前高级感
- 溯源信息卡是否已承担"信任建立 + 批次核验"的双重职责

### 模块层级验收
- 是否先给结论，再给过程，再给证明
- 是否避免了“信息一上来就太多”
- 是否避免了后台感 / 数据面板感

### 时间轴验收
- 节点是否控制在 4–6 条
- 是否能看懂而不是像日志
- 是否包含采收 / 检测 / 包装等关键节点
- 真实数据缺失时是否没有错误展示 mock 过程节点

### 实时画面验收
- 是否有真实感
- 是否不显技术化
- 封面图兜底是否自然

### 种植环境记录验收
- 是否先有“历史种植环境”结论
- 土壤养分综合趋势图是否成为主视觉
- 环境摘要是否控制为 4 项（平均气温/平均湿度/累计降雨量/光照结论）
- 图表与摘要数据是否统一来源于 `weather_data_statistics`
- 光照是否展示后端返回的结论值，而不是前端直接映射 lux
- 图表是否克制，不抢戏

### 页面完整性验收
- 各模块间距是否协调
- 页面是否过长
- 页脚是否收得住
- 无数据场景是否自然

---

## 12.6 前端阶段输出物要求

第二阶段前端开发完成后，应至少形成以下输出物：

1. 可运行的正式页面版本（非原型）
2. 至少一套全量 mock 数据
3. 一套部分缺失数据
4. 一套缺省数据
5. 页面截图 / 演示视频，用于老板与运营评审

---

## 12.7 本章节总结

第二阶段前端开发不是为了“把功能都放上去”，而是为了验证：

- 页面是否真的比第一阶段更可信
- 第二阶段内容是否能被“溯源信息卡”自然串起来
- 后续后端接口应该围绕哪些字段补齐

前端先行的价值不在于“首屏不断加元素”，而在于：

> 先把正确的页面表达验证清楚，再让后端围绕正确的目标补数据。