早掌柜 · AI 采购经营助手

给已经用上收银系统、但采购还停留在纸质单据的小型餐饮门店老板用。销售数据在收银系统里，采购记录在压箱底的纸质送货单上，两边对不上——月底想算清"这个月进了多少货、哪种原料涨价了"，只能靠翻纸和记忆。

早掌柜只做一件事：把进货单从纸上搬进手机，变成可核对、可追溯、可检索的电子台账，再和收银系统导出的销售数据放在一起看。点餐、收银、支付一概不碰——那些门店已经有工具了。

家里有几间门面出租给餐饮租户——早餐店、卤味店都有。我不是门店经营者，但比一般旁观者多一个位置：能接触到一线经营的真实单据和真实流程，而不是靠想象写需求。

2026 年 9 月，我带着"给小微门店做个 AI 工具"的想法走访了 3 家租户门店。访谈里发现的问题和我最初的设想完全不同（见第 5 段），产品方向也因此改了一次。这个项目从调研笔记开始，每一步的依据都留下了文档。

关键设计：拍照识别的时机放在收货那一刻，不是月底补录——单据在手边，原物可对照，确认成本最低。

数据渠道与脱敏：样本门店来自家中门面租户，取数前已取得门店同意；测试材料遮盖电话号码、详细地址和非必要姓名，只保留日期、商品、数量、单价、金额等业务字段。手机号、地址、购货者姓名等无关信息在产品内默认不提取、不入库。

调研笔记里也写了样本的局限：凉皮店、包子店这两家的店主主要靠经验经营，数据多为口述估算、未经过收银记录核验，不足以支撑"采购与销售数据打通"；这也是后来把产品验证单独放在已用上收银系统的猪蹄店的原因之一。

1. 被推翻的痛点假设：备货不准。原始假设是"早餐店经常因备货不准产生大量浪费"。访谈结果：每天确实有剩余，但数量不大，店主凭经验基本能控制，部分原料还能随时补货。备货预测不是最强痛点，不值得做第一版的核心功能。
   ——真正的问题是"算不清账"：以包子店为例，每日营业额约 380–520 元，按 50% 食材毛利率估算，每月食材毛利约 5320–7800 元，扣掉房租水电后夫妻经营所得约 4000–6000 元。这个数是店主自己口述加估算凑出来的，没有账本可核对。老板缺的不是多卖货，是一本能对上数的账。
2. 被自己推翻的第一版方向：做"没有收银系统的门店"。最初的市场分析里，我把"还没有收银系统的门店"当成切入点——这类店高峰排队、顾客留不住、人手不够是站在门口就能看到的痛点，采购和菜品结构反而不是主要矛盾。但方案往下推的时候我意识到问题：围着排队和人手做出来的东西，本质还是一个点餐小程序，市面上同类产品已经很多，我既没有渠道优势、也拿不出差异化的判断，做出来的东西和别家大同小异，体现不出任何独特性。第一版思路文档里落的是"口述记单 + 熟客口味 + 复购触达"；写风险清单时我又发现：早餐高峰期店主两只手都在干活，掏手机口述记单可能比靠记忆更麻烦——这条风险写在第一版文档第七部分，后来成了转向的直接依据。
3. 转折点：把选择标准从"痛点最显眼"换成"数据最完整"。不再挑问题最扎眼的店，而是挑数据基础最好的店。有收银系统的门店，销售已经数字化，唯一还留在纸上的就是采购单——这里既有空白可补，又能拿真实数据做验证，还能做出别人没有的东西。方向由此从"客流 / 点餐"转到"采购台账 + 上下游账单整理 + AI 生意走势建议"：把进货单搬进手机，与收银系统的销售数据放在一起看。
   这也解释了产品为什么只做采购端：收货时单据就摊在手边，拍照确认不打断经营节奏，而点餐、收银、支付那些门店已经有工具了。
4. 认知样本和验证样本分开，不混用。访谈的 3 家门店中，凉皮店、包子店在访谈阶段没有用收银系统，微信收款只有金额、没有商品明细，在这种店做"采购与销售数据打通"缺乏数据基础；而猪蹄店在访谈当时就已决定使用收银系统，销售能够数字化，采购单是唯一还留在纸上的环节。产品验证因此单独落在猪蹄店：3 家样本用来建立认知，1 家门店用来验证产品，两者口径不同、结论不互相借用。

这一版最核心的克制是：AI 只负责读，不负责写。识别结果只能生成待确认草稿，人工确认后才成为正式台账——错误入账的代价高于多按一次确认。

共同判断标准：当数据完整性不足以支撑确定性结论时，产品选择暴露口径与限制，而不是给出看似精确的数字。V1.0 的交付标准不是"算得准"，是"每一步都能被复核"。

• 2026-09访谈 3 家租户门店，形成调研笔记与第一版思路（切入"无收银系统门店"，落点是口述记单 + 熟客经营）依据：手写调研笔记 + 第一版思路文档
• 2026-09 末方向自评：同类点餐/客流产品已足够多，做不出差异；高峰期口述记单增加店主负担；转向接触验证门店确认猪蹄店（卤味）访谈时已决定使用收银系统，销售可数字化、采购单仍纸质，方向收敛到采购端
• 2026-10-04PRD V1.0.0 评审稿 → V1.0.1 复核修订 → V1.0.2 定稿（同日三轮）V1.0.1 校正调研范围表述、补真实单据实测结果；V1.0.2 收紧样本结论与授权表述、补 V0.1 演示范围
• 2026-10-047 张真实进货单实测4 张一次形成完整候选字段 / 2 张靠金额与大小写互校修正 / 1 张过曝虚焦需重拍
• 2026-10-07V0.1 代码完成，微信开发者工具真机调试范围：页面骨架 + 预置识别结果确认 + 本地台账 + 单条提醒，为 V1.0 保留接口
• 待进行门店试用 → 收集反馈 → V0.2 迭代；补充 20 张单据样本与人工标准答案试用记录和反馈对应的改动将更新在此时间线上

真实单据的问题比想象中多：拍摄方向不一、字迹浅、印章遮挡、商品名潦草、斤与公斤混用、同图重复上传。这些直接写进了 PRD 的字段规则与异常流程（低置信标记、金额校验、同图哈希去重、大写互校）。

两组实测不是同一批数据、方法也不同：上表 n=7（2026-10-04）是人工整理口径，验证的是录入流程；Demo n=5（2026-10-08）是模型识别口径，验证的是识别与校验链路——明细与合计核对通过 3 张、被校验层拦下转人工 2 张，拦下的会标出具体原因，不会悄悄入账。两组各自独立成立，不互相换算。Demo 中单据的供应商、地址、电话、公章区域均已不可逆打码。

• 未上线：V0.1 真机调试中，没有真实门店在用，没有用户反馈数据。第一条门店试用记录（含用户原话）将作为 V0.2 迭代的输入更新到时间线。
• 识别能力未充分验证：7 张样本只能说明"AI 提取 + 确定性验算 + 人工确认"流程初步可行，不代表手写识别已经不是瓶颈。计划扩充到 20 张并建立人工标准答案后，再谈字段准确率。
• 销售导入未接真实报表：目前用标准模板验证流程，尚未拿到该门店 POS 的真实导出文件。
• 提醒规则未实测：价涨、销量下降、数据中断等阈值来自规则设计，还没有经过真实经营数据的检验。