Mill：为餐饮副业者打造本地优先AI运营助手

从厨房混乱到AI运营中枢

卖预制餐——健身餐、每周家庭碗、生酮套餐——是当下最火热的副业之一。但在每一盒精致的餐盒背后，是运营层面的混乱。开发者 @justcallmemarko 在 Hacktoberfest 开源AI挑战赛第二周提交的项目 Mill，正试图用本地优先的AI代理解决这些痛点。

他总结了餐饮副业者面临的三个核心问题：原材料在采购、称量和调味油消耗中悄悄吃掉15–20%的净利润；面对临时订单需求（比如周五突然要15份照烧鸡饭），无法快速判断库存是否充足；厨房四灶齐开、烤箱预热、50个餐盒待装时，根本腾不出手查表格或记笔记。Mill 的思路是把笔记本电脑变成一个自主的厨房指挥中心。

据 GitHub 仓库和 dev.to 提交说明，Mill 是一个面向餐饮副业者的本地优先、自主AI助手，核心能力围绕库存审计、订单管理、备餐引导与AI对话展开。

Mill 项目截图

核心功能拆解

Mill 的功能设计紧扣餐饮副业的实际工作流，可以拆成四条主线。

实时库存与原材料审计台账：追踪大宗食材到克和毫升级别，记录精确的单位成本。每一次手动调整、补货或厨房履约扣减都写入不可篡改的审计流水。

配方测试实验室与利润定价：计算精确的批次原料成本，并根据目标毛利率（70%以上）建议售价。

可视化看板履约流水线：在 Upcoming、Preparing、Completed 三列之间拖拽管理订单。把订单卡片拖到 Completed 列时，系统自动计算所需配方原料并从库存中扣减，同时写入审计台账。

主动备餐模式：分步检查清单，自动识别倒计时（比如“炖煮15分钟”），配合视听提示，避免在装盒时烧糊整批食材。

通过 FastMCP 驱动的自主AI副厨：这是一个直连本地 SQLite 数据库的AI助手，背后是16个类型化的 FastMCP 工具。你可以告诉 Mill：“检查我是否有足够库存做8份蜜汁酱油鸡饭”“为 Sarah 记录一个周六的订单”“把鸡胸肉库存下调500克”，它会自主完成数据库事务。

技术架构与实现亮点

Mill 采用前后端分离的本地部署方案。前端使用 React 19、TypeScript、Tailwind CSS，配合 @dnd-kit 实现可访问的物理感看板拖拽，React Query 管理数据请求，支持深浅色主题。后端基于 FastAPI 与 SQLAlchemy 2.0 操作 SQLite，通过 Server-Sent Events 实现AI token的实时流式输出。

工具协议层是 FastMCP，暴露16个类型化工具，挂载在 http://127.0.0.1:8000/mcp。AI代理引擎基于 openai-agents，连接 OpenAI 兼容端点。关键设计在于：把 OPENAI_BASE_URL 指向 http://localhost:11434/v1，就能通过 Ollama 运行开源权重模型（如 gemma、llama3.2、qwen2.5），完全本地化，零代码改动。

实现上有三个值得关注的细节。第一，不可篡改的审计台账：拖拽订单到完成列时，Mill 并非简单地对数据库数字做减法，而是查找每个配方缩放后的原料行、计算扣减量，并记录一条审计事务（源码位于 backend/src/mill/services/orders.py）。第二，FastMCP 工具执行：作者引用社区关于工具描述与准确率的研究指出，显式类型提示加确定性数据库操作，能防止小型本地模型出现推理错误。第三，厨房导向的交互设计：厨房环境需要大点击目标、高对比按钮、零冗余，任何带时长的备餐步骤都会自动解析时间并渲染交互式倒计时。

FastMCP 与 MCP 协议：MCP（Model Context Protocol）是 Anthropic 于 2024 年底提出的一种开放协议，用于标准化大语言模型与外部工具、数据源之间的交互方式，可类比为“AI 世界的 USB-C 接口”。它规定了工具如何被声明、描述、调用以及结果如何返回，使同一个模型能够无差别地接入不同的工具服务。FastMCP 是基于该协议的 Python 服务端框架，开发者只需用装饰器声明函数与类型提示，即可自动生成符合 MCP 规范的工具描述。Mill 正是借助这一框架把 16 个数据库操作封装成类型化工具，让本地小模型在不接触原始 SQL 的前提下安全地完成库存加减、订单创建等多步事务，从而兼顾灵活性与可控性。

Ollama 与 OpenAI 兼容端点：Ollama 是一个面向本地推理的开源模型运行器，支持在笔记本上一键拉取和运行 Gemma、Llama 3.2、Qwen 2.5 等开源权重模型，并默认在 11434 端口暴露一个与 OpenAI Chat Completions API 高度兼容的 HTTP 接口。这种“接口兼容”是关键：任何原本面向 OpenAI 编写的客户端代码，只要把 OPENAI_BASE_URL 改为本地地址，就能无缝切换到本地模型。Mill 的 AI 代理层基于 openai-agents 框架，正是利用这一特性实现了“云端/本地一键切换”，同时保留流式 SSE 输出等能力，让使用者无需改动业务代码即可在成本、隐私与硬件性能之间自由权衡。

为什么本地优先对餐饮副业至关重要

Mill 的开源与本地优先定位，作者给出了四条面向商业可持续性的理由。

餐饮副业净利润率通常只有15–25%，按 token 计费的云端API在每次询问配方定价或查库存时都在侵蚀利润，而通过 Ollama 本地运行开源权重模型的持续API费用为零。商业厨房、地下室和备餐空间往往 Wi-Fi 信号极差，依赖云端延迟的助手在备餐高峰期会直接失效，Mill 100%在本机运行。副业者会收集客户配送地址、食物过敏信息和健康目标，存于本地 SQLite 并用本地模型处理，能确保客户数据不流入第三方模型训练管道。由于 Mill 使用标准工具调用契约，卖家可以自由选择 Gemma、Llama 3.2、Qwen 2.5 或任何适配自己笔记本硬件的开源模型，没有供应商锁定。

项目提供两步启动流程：克隆仓库后，后端通过 uv run mill-seed 播种真实的库存、配方和示例订单，uv run mill-api 启动API服务；前端用 bun install 与 bun dev 拉起看板。之后可以在 http://localhost:5173 拖拽订单观察库存自动扣减、切换到 Preparation 标签启动引导式烹饪计时器并与范围限定的AI副厨对话，或在 AI Assistant 标签让 Mill 通过 FastMCP 工具调用执行多步数据库调整。

按 token 计费的成本模型：当前主流云端大模型 API 普遍采用“按 token 计费”，即输入和输出的文本片段（约 0.75 个英文单词或 1–2 个汉字算一个 token）都被单独计费，且推理过程越复杂、对话轮次越多，费用越高。对于频繁查询库存、反复确认配方定价的运营类助手，单次会话往往涉及数千 token，长期累积会产生可观支出。而本地推理的边际成本几乎为零——只在首次下载模型权重和耗电上付出固定成本，后续调用不再产生费用。这正是利润率仅 15–25% 的餐饮副业者倾向于本地运行开源权重模型的核心经济动因。

一个值得关注的副业工具范式

Mill 的价值不只是一款餐饮副业软件。它展示了一种可复用的产品思路：把本地优先的AI代理嵌入到垂直行业的实际操作流程中，用类型化工具约束模型行为，用不可篡改的审计流水保障业务可信度，用开源权重模型控制成本与隐私。对于利润率微薄、网络环境不稳定、数据敏感度高的副业场景，这套组合拳比通用云端助手更贴合现实约束。项目同时申报了 Hacktoberfest 第二周主赛道与“最佳 Gemma 使用”奖项。

Hacktoberfest 与开源AI挑战赛背景：Hacktoberfest 是 DigitalOcean 自 2014 年起每年十月举办的全球性开源贡献活动，鼓励开发者向开源仓库提交 Pull Request。近两年随着生成式 AI 兴起，衍生出专门的“开源AI挑战赛”主赛道，要求参赛项目在开源框架内实际使用 AI 能力。除主赛道外还设有主题奖项，例如文中提到的“最佳 Gemma 使用”，即鼓励选手基于 Google 开源的 Gemma 系列权重模型构建应用。Mill 同时申报两个奖项，意味着它既满足了 AI 应用完整性的评审要求，又在模型选型上体现了对开源权重生态的采用，对希望了解此类赛事评审取向的读者具有参考意义。