4. 记录表单的数字化设计与字段规范
纸质养殖日志最大的问题不是“记不记”,而是“记了没法用”。同一口塘,有人写“投料30斤”,有人写“30kg”,有人只写“正常”;水温有时写“28”,有时写“28℃”,有时干脆空着。这样的记录在塘边翻看尚可,一旦要汇总月度饲料系数、追溯某次缺氧事件的处置过程,就会立刻暴露出字段含义不清、单位混乱、缺失值无法区分等硬伤。数字化设计要解决的正是这些问题:把一张纸质日志拆解为可计算、可校验、可追溯的字段集合,再用表单承载它。
先定字段,再画表单
电子表单不是把纸面格子搬到屏幕上,而是先做“字段建模”。一个字段至少要说清五件事:字段名(业务含义唯一)、数据类型(数值、文本、日期时间、枚举、布尔、附件)、计量单位(统一到基准单位)、是否必填(与业务判断相关才必填)、校验规则(取值范围、精度、跨字段约束)。以养殖日志为例,“投饲量”应定义为数值型、单位千克、保留一位小数、必填且大于等于0;“水温”为数值型、单位摄氏度、范围0~40、必填;“天气”为枚举(晴/多云/阴/小雨/大雨/大风),必填;“增氧机开启时长”为数值型、单位小时、范围0~24、非必填但建议填写;“异常情况”为文本型、限500字、非必填,但一旦“溶解氧”低于阈值则转为必填并触发说明要求。
这里有一个容易被忽视的原则:单位在字段层统一,不在录入层自由。表单界面可以显示“kg”,但数据库存储统一为基准单位,避免“斤/公斤”混录导致后续统计翻倍或减半。同理,日期时间应统一为“YYYY-MM-DD HH:mm”格式存储,界面可用日期选择器降低录入成本。
校验规则要分层设计
校验不是越严越好,而是分层:格式校验(是否为数字、日期是否合法)、范围校验(水温0~40、pH 5~10)、逻辑校验(投饲量不能为负、增氧时长不能超过24小时)、跨字段校验(若“溶解氧”低于3 mg/L,则“异常情况”必填且“增氧机开启时长”应大于0)、时序校验(本次记录的日期不得早于上次记录日期)。分层的好处是错误提示精准:格式错误立即拦截,逻辑冲突给出警告并允许暂存,跨字段异常则要求补充说明后才能提交。
必填项的设计也要克制。把“备注”设为必填只会逼出“无”“正常”这类无效文本。合理的做法是:核心观测项(水温、溶解氧、投饲量、死鱼数)必填;条件必填项(异常说明、用药名称)由触发条件激活;辅助项(气压、透明度)选填。这样既保证关键数据完整,又不增加无效录入负担。
把纸质日志改造成电子表单
假设某塘口原纸质日志包含:日期、天气、水温、投料量(斤)、死鱼数、备注。改造时先做字段映射:日期→记录时间(日期时间,必填);天气→枚举,必填;水温→数值,单位℃,范围0~40,必填;投料量→数值,单位由“斤”统一换算为“kg”(1斤=0.5 kg),保留一位小数,必填且≥0;死鱼数→整数,≥0,必填;备注→拆分为“异常情况”(文本,条件必填)与“现场照片”(附件,条件必填)。同时补充“塘口编号”“记录人”两个基础字段,因为数字化后记录要能归属到具体塘口和责任人。
接着定义校验:水温超出0~40提示“请核对温度计读数”;投料量为负直接拦截;若溶解氧字段被启用且低于3 mg/L,则“异常情况”由选填转为必填,且“增氧机开启时长”必须大于0,否则提交按钮置灰并高亮这两个字段。提交成功后,系统回写当日塘口汇总:累计投饲量、平均水温、异常标记,供后续统计饲料系数和预警使用。
feed_kg、water_temp_c、do_mg_l,避免使用“投料量1”“水温2”这类随表单版本变化的名称,否则后期数据汇总时字段对不上。表单交付示例(字段规范表)
下面给出一份可直接参照的字段规范表,作为养殖日志数字化改造的交付物。表中“校验规则”一栏即表单实现时的判断依据,“必填”一栏区分“是/否/条件”三种状态。
| 字段标识 | 中文名 | 类型 | 单位 | 必填 | 校验规则 |
|---|---|---|---|---|---|
| pond_id | 塘口编号 | 文本 | — | 是 | 长度6~12,须存在于塘口档案 |
| record_time | 记录时间 | 日期时间 | — | 是 | 不早于上一条记录,不晚于当前时间 |
| weather | 天气 | 枚举 | — | 是 | 晴/多云/阴/小雨/大雨/大风 |
| water_temp_c | 水温 | 数值 | ℃ | 是 | 0~40,保留1位小数 |
| do_mg_l | 溶解氧 | 数值 | mg/L | 是 | 0~20,保留1位小数;<3 触发条件必填 |
| ph | pH | 数值 | — | 是 | 5~10,保留1位小数 |
| feed_kg | 投饲量 | 数值 | kg | 是 | ≥0,保留1位小数 |
| aerator_h | 增氧机时长 | 数值 | h | 条件 | 0~24;溶解氧<3 时须>0 |
| dead_fish | 死鱼数 | 整数 | 尾 | 是 | ≥0 |
| abnormal_note | 异常情况 | 文本 | — | 条件 | ≤500字;溶解氧<3 或死鱼数>0 时必填 |
| photo | 现场照片 | 附件 | — | 条件 | 用药记录时必传,单张≤5MB |
设计时容易踩的三个坑
一是把“正常”当数据。备注里写“正常”无法参与任何计算,也无法在异常回溯时提供信息。正确做法是把“正常/异常”做成布尔或枚举字段,异常时再要求填写说明,让判断可统计。二是单位混用。同一表单里既有“斤”又有“kg”,汇总时必然出错,必须在字段层统一并保留换算说明。三是校验过严导致弃填。如果每个字段都必填、每个值都卡死范围,养殖户在塘边会直接放弃录入。合理策略是核心项严格、辅助项宽松、异常项条件触发,并允许草稿暂存,待复核后再正式提交。
表单数字化完成后,还应做一次“回填验证”:用过去一周的纸质记录逐条录入,检查是否有字段无法表达、是否有校验规则误拦合理数据、是否有必填项在实际场景中经常缺失。这一步能暴露设计阶段想不到的问题,也是表单从“能填”走向“好用”的关键环节。