一批畜（禽）查不清，问题几乎都落在同一处
养殖场最常被问到的几个问题，答案都指向同一件事：数据不在账上。
- 这批苗哪天进的、从哪家苗场来的、当时多少只？
- 这段时间喂的哪款料、换料是哪天换的？
- 上个月那轮防疫打的是哪批疫苗、谁打的、有没有漏栏？
- 出栏前的检疫怎么办的、报检单和证明放哪了？
- 死亡率是从哪天开始爬起来的，之前有没有征兆？
这些答案通常散在三个地方：班组长的手机相册、饲料间墙上的白板、老板微信里的语音消息。等到要出栏、要报检、要算这批到底赚没赚，才发现台账拼不回来——不是没人记，是记的地方凑不到一起。
这类问题不需要上一套"什么都要"的大系统。它需要的是一个按批次组织起来的业务模块：批次为主线，饲喂、防疫、存栏变动、出栏检疫这些事件往批次上挂；手机端在现场能补录，电脑端能出汇总和清单。这正是 Inkwell AI 构建器擅长交付的形态——用业务语言把需求讲清楚，它生成数据表、管理页面和对应的手机端页面（可参考 /products/ai-builder.html）。
底表怎么建：五张表管住一批畜（禽）
新手最容易犯的错，是把所有信息塞进一张"养殖记录表"里。表一宽，录入就变成考试，越填越少，最后整张表半空着。正确的做法是按"一件事一张表"拆开，用批次把它们串起来。
1. 养殖批次（主表）
一批一记录，是模块的主心骨。关键字段：
- 批次编号（可自动生成，如年份 + 品类 + 序号）
- 品类与品种（猪 / 鸡 / 牛 / 羊 + 具体品种，下拉选项统一走数据字典，做法见 /docs/data-dictionary.html）
- 入栏日期、入栏数量、来源（自繁 / 外购）、供苗单位
- 栏舍编号（从栏舍档案里选，避免同一栋舍写成三种叫法）
- 当前存栏、累计死淘数（由下面的变动记录汇总得出，不靠人手填）
- 批次状态（在养、待出栏、已出栏、已清栏）
- 负责人（从系统用户里选，权限就按这个人划定"看得到哪几批"）
一批一档的好处很直接：查任何一件事，先定位批次，再顺着看它的时间线。
2. 饲喂记录
按"天 × 栏舍 × 批次"记一条，字段少而硬：日期、批次、饲料品名与规格、投喂量、料槽或料线编号、记录人。饲料品名最好做成字典项或从饲料档案里引用，否则"育肥料""育肥期料""肥猪料"会变成三个不同的东西，后面的耗料核算就白做了。
这张表的价值不只是"记了喂多少"，而是把料肉比的原料攒齐：入栏数、出栏数、累计耗料，三个数凑齐就能算这一批的料肉比，也才能横向比出哪栋舍喂得好。
3. 防疫与用药记录
这是养殖台账里最需要留痕、也最容易被监管和客户追问的一张表。建议字段：
- 批次、日期、栏舍
- 类型（免疫 / 驱虫 / 消毒 / 治疗用药）
- 疫苗或药品名称、批号、生产厂家、有效期
- 剂量、给药方式（注射 / 饮水 / 拌料）
- 执行人、复核人
- 应免数量 / 实免数量
- 附件：疫苗瓶标签、免疫证明拍照上传（走平台的文件能力，照片就挂在记录旁边）
"应免 / 实免"这两个字段是这张表的灵魂。只记"打了"不记"打了多少只"，等于没记——漏掉的那几栏，往往就是后来出问题的几栏。
4. 存栏变动与死淘记录
每一次让存栏数字发生变化的动作都记一条：入栏、转栏、死淘、出栏、淘汰。字段：日期、批次、变动类型、数量、原因、处理方式（无害化处理 / 上报 / 出售）、经办人、证明附件。
死淘不是记个数字就完事。原因字段要事先约定好取值，并且不给手填口子——用数据字典固定住，否则一年后会攒出几十种写法，做统计分析时全部作废。
5. 出栏与检疫
记录批次出栏日期、出栏数量、均重、收购方、报检日期、检疫证明编号与照片、运输车牌（需要追溯去向时尤其有用）。批次的"已出栏"状态由这张表的记录触发，而不是手动去改状态——状态由事实驱动，账才不会错位。
五张业务表之外，通常还要配两张轻量档案表：栏舍档案（栏舍编号、面积、容量）和往来单位档案（供苗、供料、兽药、收购方）。它们的作用是让"选"代替"打"：平台的引用引擎可以把档案表直接变成选项数据源，录入速度和数据质量一起上去。## 页面怎么用：三类页面撑起一天的活儿
表建好之后，真正决定这套模块能不能用起来的，是页面。养殖台账一般需要三类页面，各有各的使用者。
录入页：让记录变成三步以内
饲喂、防疫、死淘这三种记录是天天要填的，录入页必须极简。批次、日期、栏舍能带出的就自动带出，能选的就不让手打，只有一个数字必须人手敲——那就是实际数量。
具体做法是：从批次详情页直接点"新增饲喂记录"，批次与栏舍自动带过去；或者做成一路下拉的快速录入，让记录人在手机上一次填完当天的几栏。凡是让人"多点三下才能填一个数"的设计，最后都会退化成不填。
台账页：一屏看清一个批次的来龙去脉
批次详情页是把五张表拼成一条时间线的地方：上面是批次基本信息与当前存栏，下面按日期倒序显示这一批发生过的所有事情——什么时候进的苗、喂了多少料、哪天防疫、哪天死了几头、什么时候出栏。
这一屏的价值在于回答"发生了什么"，而不是"填了哪些表"。老板、场长、兽医、客户、监管，问的都是前者。
汇总页：该看趋势的地方别放明细
汇总页解决的是"哪一批、哪一栋更值得关注"，建议放四个视角：
- 在养批次一览：存栏、日龄、累计耗料、死淘率，按批次数值排序
- 死淘趋势：按周或按日看死淘数量的变化，异常的那几天一眼能跳出来
- 防疫到期与待办：下一轮该防的批次、已过应免日期还没记录的批次
- 每批成本口径的基础数据：入栏数、出栏数、累计耗料、累计用药
指标都由底表汇总计算，不做手工维护的第二份数字。这也是自建模块相比手工台账最实在的一处：同一份数据，只录一次。
自动提醒与待办：把"该做的事"推给人
养殖的很多损失，来自"忘了"而不是"不会"。平台的定时任务能力可以把这类检查固定成每天自动跑一次（用法见 /docs/workflows-scheduler.html）：
- 某批次到了下一轮免疫的应免日期、系统里还没有对应的防疫记录 → 生成待办提醒给批次负责人
- 疫苗或药品批次临近有效期 → 提前提醒，避免用过期苗
- 批次存栏长时间没有更新、或死淘率在短期内明显偏离该批自身的前期水平 → 提醒场长复核
- 批次达到预计出栏日龄 → 提醒准备报检与销售对接
需要审批的环节也能接上：比如大批量的死淘上报、无害化处理确认、外购苗入栏确认，都可以走平台的工作流能力做成一条带签批的流程，而不是只在群里说一声。
移动端：现场的手，别让它非回办公室不可
养殖的录入现场在栏舍里，不在办公桌前。所以移动端不是"锦上添花"，而是这套模块能不能跑起来的前提（移动端能力说明见 /docs/mobile-guide.html）。
在 Inkwell 里，模块在电脑端建好后，手机端页面会跟着同步生成，不需要另外做一套。落到养殖场景，通常这么用：
- 饲喂记录：喂完一栏当场录一条，数量、料线、时间都在现场，不用凭记忆补
- 防疫记录：执行人现场录，顺手把疫苗瓶标签拍下来挂附件；复核人在自己手机上确认
- 死淘登记：发现就报，附一张照片，原因从下拉里选，不做自由发挥
- 批次查询：巡栏时想看某批的日龄、累计死淘、上轮防疫日期，直接查，不用回办公室翻本子
- 待办提醒：手机上收到"该防了""该出栏了"的提醒，点进去就能办
手机上录入的字段不必和电脑端一样多。原则是：现场只填现场才知道的事，其余交给电脑端补。 现场知道的是数量、时间、原因、照片；至于核算口径、成本分摊，那是办公室的活，别压在栏舍里。
权限与责任：谁能看哪几批
一个场往往不止一个负责人，还可能有大场长、兽医、外购对接人、财务。模块上线时顺手把权限划清，比事后追责有用得多：
- 饲养员：只能录入自己负责批次的饲喂、死淘；只能看自己班子管理的批
- 兽医 / 技术员：看全场防疫与用药，能新增防疫记录并复核
- 场长：看全场的批次与汇总，能审批死淘上报
- 财务：只读汇总数据，看成本口径的基础数字，不做录入
- 客户或外部：一般不开放账号，需要证明材料时导出清单
这套划分用平台的角色与权限就能配出来（配置方法见 /docs/roles-permissions.html），不用为养殖单独设计一套权限模型。同时也建议开启操作审计留痕：防疫记录、死淘数量这类数据的修改，谁改的、改前是什么，应当能查到。养殖数据一旦被无声改过，整本账的可信度就没了。## 上线前查什么：八项自查，逐条过一遍
模块建完不等于能用。上线前按这份清单过一遍，能省掉大半返工。
- 字典是否收敛。品种、饲料品名、死淘原因、变动类型，这四个字典项是否已经统一口径、并锁住不让手填？这一步最容易被跳过，也最影响后面的统计。
- 引用关系是否完整。栏舍、供苗单位、饲料档案这几张档案表，是否有历史数据？如果档案是空的，录入页的选项就是空的，现场只能退回手打。
- 历史数据怎么进。上一年度的批次与防疫记录，如果要接进来，先整理成表格再一次性导入（做法见 /docs/excel-to-module.html）。只导入在养批次和最近一年的防疫记录通常就够，不必把十年旧账全搬进来。
- 汇总字段对不对。拿一个已知的批次，用纸面数字对一遍：当前存栏、累计死淘、累计耗料，三个数与实际是否吻合。算错往往是因为一张子表的关联条件漏了。
- 必填与校验是否设到位。日期、数量、批次这三项必须必填；数量要做正数与上限校验，防手滑多打一个零。
- 权限是否试跑过。用不同角色各登录一次，确认饲养员看不到别人的批、财务改不了记录。用测试账号走一遍，别用真实数据试。
- 提醒是否真的会到。把一条提醒的触发条件临时调近，确认它推给了对的人，而不是推给了建模块的人。
- 手机端是否可用。抓一位饲养员用真机录三条饲喂、一条防疫，看他能不能在两分钟内完成。这一步的反馈往往比场长的意见更值钱。
跑完这八条，再走模块的发布预检与挂菜单流程（见 /docs/module-test-publish.html），把页面挂到对应角色的菜单上。建议先在一个场或一个片区试运行两到四周，等现场录入稳定了，再推全场。
之后怎么延伸：从一个场的账，长成一条链
养殖台账是一个很自然的起点，因为它是全场数据的源头。跑顺之后，通常按下面几支往外延伸：
- 成本核算：以批次为单位，把苗费、饲料、兽药、人工、水电摊进去，算出每批的料肉比和单位成本。饲料与兽药若先建成领用记录，这一步就是自动汇总，不需要另起一套账。
- 库存与领料：饲料、兽药、疫苗的出入库与领用，和批次挂钩，领料时选批次，用完能反查到这一批吃了什么（库存逻辑可参考 /solutions/solution-erp-inventory.html）。
- 逆向往上追：供苗单位、饲料批次、疫苗批号在台账里都留了引用，出问题时能顺着批号查到同一批投入品还进了哪些批。这与制造业的批次追溯是同一个思路（见 /solutions/mfg-batch-traceability.html）。
- 销售与结算：出栏记录接上收购方与结算单，形成养殖端的应收。
- 种养打通：如果同时有种植业务，种植农事台账与养殖台账在"地块—饲草—粪肥还田"这条线上是能对接的（见 /solutions/agri-planting-ledger.html）。
延伸的顺序建议按"最痛的那一环先做"来排，而不是按上面写的顺序来排。如果当下最痛的是防疫漏栏，就把防疫与提醒做扎实，其余先放一放。
适用边界：什么情况不适合用它
诚实地说，这套东西有它不擅长的地方：
- 实时环控与智能设备联动不在交付范围。温湿度自动控制、自动喂料机的运行控制这些属于设备与工控侧，本模块只承接人工录入与管理台账。
- 算法类决策不适合放在这里。遗传育种选配、疾病诊断推断、饲料配方优化这类需要模型计算的场景，台账只能提供数据基础，不能替代算法本身。
- 超大规模的全自动场如果已有成熟的行业专用软件，养殖台账更适合做"补位"：把专用软件覆盖不到的现场记录、证明附件、跨批次汇总补上，而不是整体替换。
反过来说，只要你的痛点集中在"现场记录靠脑记、防疫漏栏查不出、出栏时材料拼不齐、养一批算不清成本"这几类，这个模块形态就是对路的。它不追求覆盖所有设备，只追求一件事：一批畜（禽）从进栏到出栏的每一件事，都能在一条时间线上被查到、被证明。
如果你正在管一个自有牧场、合作社或家庭农场，最省力的起点不是先画流程图，而是把现在用的那张纸单拍下来发给 AI 构建器——从"这批的纸单长什么样"开始，比从"养殖管理系统应该有什么功能"开始，落地要快得多。