烘焙App开发实战：从配方到上线的全链路拆解

去年秋天我接了一个私活，帮一家开了七年社区烘焙工作室的老板做一款内部用的配方与订单管理 App。老板的原话是：“我只要一个能让我和三个师傅不用再翻纸质本子的东西。”这句话听着简单，做起来却踩了不少坑。这篇文章就把我从需求梳理到上线迭代的完整过程拆开讲，重点说那些真正影响进度和成本的决策点，而不是泛泛而谈的“先做原型再开发”。

先想清楚：你的烘焙 App 到底给谁用

烘焙这个行业有个特点，角色非常分明：老板、师傅、前台、顾客。四类人对 App 的期待完全不同。老板想看成本和销量，师傅关心配方和排产，前台要快速下单和核销，顾客只想看今天有什么新鲜出炉的。

我的建议是第一版只服务内部角色。原因很现实：面向顾客的 App 意味着你要处理注册登录、支付、推送、评价、售后，开发量至少翻两倍，而且上线后还要持续运营。内部工具则可以把范围锁死，两到三周就能跑通闭环。

当时我们定的 MVP 范围是：

• 配方库：原料、克数、步骤、成品数量，支持按成品份数自动换算
• 生产计划：每天排产，师傅在手机上看当日任务
• 原料库存：低于阈值提醒补货
• 简易订单：前台录入，支持自提和配送两种标记

就这四块，没有会员体系，没有优惠券，没有积分。后来证明这个克制是对的，因为光是配方换算这一个功能，就改了四版交互。

技术选型：小程序还是原生 App

这是问得最多的问题。我的判断标准只有一个：使用场景是否重度依赖手机硬件或离线能力。

烘焙工作室的实际使用环境是后厨，手机经常沾面粉、戴手套操作，而且信号一般。这种情况下，微信小程序的即开即用优势很明显，师傅不用装 App，扫码就能看配方。但如果你的场景涉及大量图片、离线缓存配方、蓝牙连接电子秤或标签打印机，那原生 App 或跨端框架会更稳。

最终我们选了小程序加云开发。理由很朴素：老板不懂服务器运维，我也不想为了一个小项目长期维护一台云主机。云开发的数据库、云函数、存储一套下来，前期成本几乎为零，等业务量起来了再迁移也不迟。

如果换成原生路线，一个容易被忽略的成本是审核与发版周期。小程序的审核通常几小时到一天，原生 App 遇到节假日可能拖三五天。对于需要快速修 bug 的小团队，这个差异会直接影响体验。

配方模块：看似简单，实则最容易返工

配方管理是整个 App 的核心，也是最容易低估的地方。一开始我以为就是存几个字段，写完才发现业务逻辑比想象中复杂。

单位换算与损耗率

烘焙配方里经常出现“鸡蛋 2 个（约 100g）”“黄油 室温软化”这种非结构化描述。如果强行做成纯数字字段，师傅录入时会骂人。我的处理方式是：数量字段允许填数字或文本，同时在旁边保留一个备注字段，换算时只对数字部分做运算。

损耗率是另一个坑。面粉、奶油在搅拌和烘烤过程中会有损耗，配方里的理论用量和实际领用量并不一致。我们在原料表里加了一个可配置的损耗系数，排产时自动上浮，库存扣减按实际上浮后的数量走。这个细节让库存准确率从大概七成提到了九成以上。

版本管理不能省

师傅改配方是常态，今天少放 5g 糖，明天换个品牌的面粉。如果没有版本记录，出了问题根本查不到原因。我们的做法是每次保存生成一条历史快照，配方详情页可以查看修改时间和修改人。实现上不需要多复杂，一张历史表加一个版本号字段就够了。

// 保存配方时写入历史快照（云函数示例）
async function saveRecipe(recipe) {
  const db = cloud.database();
  const now = Date.now();
  const version = (recipe.version || 0) + 1;

  await db.collection('recipe_history').add({
    data: {
      recipeId: recipe._id,
      version,
      snapshot: recipe,
      createdAt: now
    }
  });

  await db.collection('recipes').doc(recipe._id).update({
    data: { ...recipe, version, updatedAt: now }
  });

  return { ok: true, version };
}

排产与库存：让数据自己流动

排产的本质是把订单和配方关联起来。前台录入订单后，系统根据订单里的商品数量，反查对应配方，再乘以份数得到原料需求，最后汇总成当天的领料单。这条链路一旦打通，师傅就不用手工算料了。

库存扣减要注意时机。不要在下单时扣库存，而应该在确认生产时扣。因为订单可能取消，也可能改数量，提前扣会导致数据混乱。我们用一个状态字段控制流转：待确认、已排产、生产中、已完成、已取消，只有进入“已排产”才触发扣减。

一个血的教训：早期版本没有做幂等处理，师傅手抖点了两次“开始生产”，库存被扣了两遍，第二天盘点对不上账，查了半天才发现是重复提交。后来所有写操作都加了唯一请求 ID 做去重。

成本控制与上线节奏

整个项目从零到上线大概六周，其中开发四周，测试和调整两周。如果按外包报价，这类内部工具通常在几万块区间，具体取决于功能边界。自己开发的话，主要成本是时间，云开发的基础套餐前期基本够用，真正花钱的地方在图片存储和短信通知，量小的时候可以忽略。

上线节奏上，我建议先灰度给两三个人用一周，别一上来就全员推广。真实使用中暴露的问题往往集中在交互细节上，比如按钮太小、戴手套点不准、输入框弹起遮挡内容。这些问题在演示阶段根本发现不了。

后续迭代优先级我的排序是：数据报表、顾客端下单、会员储值。报表放第一位是因为老板最关心，而且实现成本低；顾客端放最后，因为它会引入全新的运营负担。

给准备动手的开发者几句实话

• 别急着写代码，先去店里待半天，看师傅怎么用本子记东西，那才是真实需求
• 配方和库存的字段设计宁可多留备注位，也别为了“规范”牺牲录入效率
• 所有涉及数量的写操作都要考虑重复提交和并发
• 第一版不做顾客端，把内部闭环跑顺，比什么都重要
• 留好数据导出功能，老板迟早会想把数据导到 Excel 里做分析

烘焙 App 这个方向技术难度不算高，难的是把线下那套模糊的、靠经验运转的流程翻译成清晰的软件逻辑。谁把这一步做扎实了，后面的开发反而轻松。