一款用您自己的语言描述的蜂场管理应用

为何手账本终将力不从心

五群蜂用手账本记录完全可行；但一旦需要回答跨维度的问题，手动操作便迅速变得繁琐低效：哪些蜂群已六周未巡检？哪些连续两年发生分蜂？某处蜂场产蜜多少公斤？某批蜂蜜源自哪些继箱？

这些问题并非要求记更多笔记，而是要求笔记之间彼此关联。这正是数据库的核心能力，而手账本永远无法做到：一次巡检属于某一群蜂，一群蜂位于某个蜂场位置，一次采收产出一个蜂蜜批次。

您描述的内容，与引擎生成的结果

您用日常中文清晰表达需求——「我是养蜂人，管理着分布在四个地点的约百群蜂，需记录巡检、采收和分蜂情况」。引擎据此提炼出业务模型：实体类型、字段定义、各实体间的关联关系。

在编写任何一行代码之前，系统会先向您展示该模型，并允许您自由编辑：重命名实体、新增字段、删减模块、修正状态列表中的选项值。此时，应用才真正成为您自己的工具，而非对您语句的粗略解读。

蜂群与巡检跟踪

每群蜂拥有独立身份标识——编号、蜂王信息、出生年份、所在位置、健康状况——每次巡检均与其精确绑定。因此，蜂群档案页呈现的是其完整巡检历史，而非电子表格中孤立的一行数据。

所有列表均支持筛选与排序：按蜂场位置、按状态、按最近巡检日期。删除操作不会永久清除数据，而是移入回收站，您可随时恢复误删记录——当您因手快错删蜂群时，这一功能尤为关键。

• 每群蜂独立建档，附带完整巡检历史
• 带日期的巡检记录：子脾状况、蜂粮储备（蜜、粉）、用药处理、现场观察
• 按蜂场位置、状态或日期进行筛选与排序
• 删除记录进入回收站，支持一键恢复

采收、批次与蜂场位置

一次采收关联至参与生产的蜂群，由此产出的蜂蜜批次亦继承该关联。可追溯性并非独立模块，而是内生于数据结构——因为从建模阶段起，各条记录就已相互关联。

蜂场位置作为普通实体之一进行描述。若您在需求描述中提及坐标信息，模型可自动包含地图视图；否则仅以列表形式呈现，这对大多数蜂场而言已完全足够。

• 采收记录精准关联至对应蜂群
• 蜂蜜批次信息：花期、重量、包装方式
• 蜂场位置与蜂群转场
• 所有数据集均可随时导出为 JSON 或 CSV 格式

该应用不具备的功能

它是一款内部管理工具，而非监管合规类软件。它不承担行政法规要求的《养蜂登记册》职能，不向任何政务平台提交申报，不出具税务合规发票，亦不替代官方规定的蜂群健康监测流程。

它所实现的所有功能，均由您完全拥有的标准代码驱动：基于 Next.js 与 Prisma 的常规项目，可导出 ZIP 包或推送至您自己的 GitHub 仓库。若有缺失功能，开发者可直接扩展，无需依赖第三方厂商授权。