一张小票照片进 Notion：让 Agent 把每笔采购拆成库存和单价，再按现有存货排菜单
D I G IX (Twitter) · 2026-09-21
打开原帖Connected @muse with my @NotionHQ meal planner. Now I can take a picture of my grocery receipt have each purchase registered to an ingredient in my pantry, Updating my pantry stock, tracking per item cost, and suggests meals based on what I actually have in stock vs my recipes. I also had it update all the broken/empty image links in my Recipes database so my gallery view is fully populated now 🤩
业务摘要
把一张购物小票照片解析成逐项条目（品名、数量、单价、小计），再把每一项映射到食材库里已存在的条目上（处理别名与单位换算），据此更新库存数量、记录这项食材最近几次的单价，然后把「现在实际有什么」与食谱库比对，输出三档菜单：现在就能做、只差一两样、需要专门采购。顺带把库里的脏数据一次性清出来：失效链接、空白图片、缺条目的食材、重复条目。
自己做饭、常囤货、经常因为不知道冰箱里有什么而重复买同一种东西的人；想知道一顿饭实际成本、或想跟踪哪些食材在涨价的人；以及做餐饮、烘焙、咖啡、花艺这类需要管原料库存与成本的小生意经营者——把「食材」换成「原料」，同一套结构直接可用。
执行链路
- 先把食材库建好，别急着接小票
统一品名、单位与别名（牛奶/鲜奶/全脂牛奶算同一个），并定好库存字段。库不统一，小票解析得再准也落不进去，最后变成一堆重复条目。
- 让 Agent 把小票照片解析成逐项
输出固定字段：品名、数量、单价、小计；认不出的项写「未识别」，不许按常见商品名猜——猜错一条，库存和成本就同时错了。
- 把每项映射到条目并更新库存
按别名表匹配到已存在的食材条目，做单位换算后加减库存；匹配不上的先建新条目并标注待你确认，不直接并入相近条目。
- 记下单价，攒出价格曲线
每次采购都把单价存下来，保留最近几次的记录。只有一次单价看不出任何东西，三次以上才知道哪样在涨、哪样该囤。
- 按现有库存对照食谱排菜单
分三档输出：现在就能做、只差一两样、需要专门采购，并把临期项排在最前。推荐必须写明用掉了哪些库存，说不清消耗的不算推荐。
- 顺手把脏数据一次清出来
让它列出失效链接、空白图片、缺条目的食材与重复条目，交你确认后再改。作者修食谱库图片链接就是这一步，改动可回滚、不做自动覆盖。
复用方案
- 已有一套可写入的库存/食谱库（Notion 或任意结构化表格），且能授权 Agent 读写
- 愿意先花时间统一品名、单位与别名，而不是边用边乱
- 能提供清晰的小票照片（折痕、反光、热敏褪色都会影响识别）
- 接受识别会有错、需要逐项复核，不把解析结果当账本直接采信
- 涉及账号授权与数据改动时由本人确认，不让 Agent 自动覆盖原库
起步草稿
AgentFlow 整理的起步草稿，未在原案例业务环境实测，不保证效果；合成示例测试不代表原作者收入已验证。
你是我的食材库存助手。我要的不是一份菜单，而是把「我手上到底有什么」变成可靠的数据，再基于这份数据排菜。你不得在未经过我确认的情况下覆盖或删除库里原有内容。 【输入：我会提供什么】 1) 一张或多张购物小票照片； 2) 我的食材库结构（字段、单位、已有的品名与别名表）； 3) 我的食谱库结构（含每份食谱所需的食材与数量）； 4) 现有的库存快照（如有）； 5) 我的饮食约束（忌口、过敏、人数、每餐大致预算）。 【执行步骤】 1. 先把小票解析成逐项，字段固定为：品名、数量、单价、小计；认不出的项写「未识别」，不许按常见商品名猜测，也不许合并看起来像同一类的项。 2. 把每一项按我提供的别名表匹配到已存在的食材条目；匹配不上的列为「待建条目」，并给出建议名称与单位，交由我确认，不许自动并入相近条目。 3. 做单位换算后更新库存：记录食材、本次变动、变动后数量、单位；换算依据不明确的一律标「待我确认」。 4. 记录每一项本次的单价，并保留最近几次的单价记录，标出与上次相比的变化方向；只有一次记录时，不得给出任何涨价或降价结论。 5. 把更新后的库存与食谱库比对，输出三档菜单：现在就能做、只差一两样、需要专门采购；临期项排在最前。每条推荐必须写明消耗哪些库存、各消耗多少。 6. 最后扫一遍库里的脏数据：失效链接、空白图片、缺条目的食材、重复条目，列成修复清单交我确认，由我决定改哪些。 【输出格式】 - 表一：小票解析（品名、数量、单价、小计、匹配到的条目、未识别项） - 表二：库存更新（食材、变动、变动后数量、单位、换算依据） - 表三：成本记录（食材、本次单价、上次单价、变化方向、记录次数） - 表四：菜单建议（档位、菜名、消耗库存、缺口、是否含临期项） - 末尾：数据修复清单 + 「未识别 / 待我确认」清单 【必须由我人工确认后才会继续】 - 未识别项与待建条目经我确认后才入库； - 任何对原有库的写入、覆盖或删除都由我本人执行，你只给出变更清单； - 单价与数量以小票为准，你不得估算、凑整或用常见价格代替； - 涨价/降价结论只有在同一食材有三次以上记录时才可给出，并注明是依据我自己的记录； - 涉及过敏与忌口的判断以我的输入为准，你不得自行放宽或替我决定可以吃。
运行成本与避坑指南
成本：作者未披露 token 或费用。成本主要来自小票条目数与图片数量，以及每次都要重新读取库存与食谱库；本条不给出未经核实的费用数字。
运行条件：受限于小票清晰度（热敏褪色、折痕、反光）、平台是否允许 Agent 读写该库，以及库结构是否稳定。库字段一旦频繁变动，映射规则就要跟着改。
避坑：最大的坑是没建别名表就开跑：同一个食材会出现三四个条目，库存从此不可信，而清理重复条目的成本远高于一开始统一。第二大坑是让 Agent 猜未识别项——猜错一条，库存和成本同时错，且很难被发现。第三是把解析结果当账本直接采信，省掉了逐项复核这一步。第四是库结构频繁改动导致映射失效。第五是让 Agent 直接覆盖原库，出错后无法回滚。
