--- title: "按锅重算每份热量" date: "2026-08-08" canonical: "https://raytally.com/ideas/2026-08-08-idea-a6b80cbd/" generator: "萤录 RayTally · dev-prompt-v4" signal: query: "I wish there was an app or website where i could calculate the calories of homemade recipes, like i could just add what was in it to a list it could tell me how much it was angel ໒꒰ྀིっ˕ -｡꒱ྀི১ (@angxlbxte) August 6, 2026" observed_at: "2026-08-08T00:33:57.696Z" sources: - url: "https://x.com/angxlbxte/status/2085429909506473988" boundary: "发布于 2026-08-06T18:16:50.000Z。 观测于 2026-08-08T00:33:57.696Z。" - url: "https://fdc.nal.usda.gov/api-guide/" boundary: "来源记录未提供发布时间。" - url: "https://openfoodfacts.github.io/openfoodfacts-server/api/" boundary: "来源记录未提供发布时间。" - url: "https://support.cronometer.com/hc/en-us/articles/360018510311-Create-Custom-Recipe" boundary: "发布于 2024-08-15T18:17:00.000Z。" notice: "本任务书中的信号，是在所列时间点截取的有界观察（搜索关注、论坛分数或新品列表），不是市场验证、用户数量或持续需求证明。转述或据此行动时，必须保留这些时间边界与最强反方。" --- [在 RayTally 阅读原始页面](https://raytally.com/ideas/2026-08-08-idea-a6b80cbd/) 使用声明：以下信号只是带时间边界的公开观察，不是市场验证、用户数量或持续需求证明；转述或执行时必须保留时间边界与最强反方。 你是资深产品工程师。请把下面这条产品灵感做成一个可以本地运行的 MVP。 ## 灵感 按锅重算每份热量 做饭时按实际下锅和盛出重量记食材，出锅就得到整锅及每份的真实热量。 ## 产品概念 做一锅咖喱、炖菜或炒饭时，用户把空锅放上厨房秤后按下开始。每加入一种食材，应用读取重量变化，用户扫包装条码、拍标签或说一句“加了两勺橄榄油”确认品类。屏幕只显示刚加入的重量和整锅累计值，做饭的人不必在油烟里手输一长串克数。 食材录完后，产品把条码数据库中的能量和营养信息换算到实际下锅量。出锅时再称一次可食用总重，系统能把蒸发、骨头或未吃部分和原料重量区分开来。盛饭时把盘子放上秤，取走多少克，就显示这盘实际拿到了整锅多少比例和对应热量。 常做的菜会变成可复用模板。下次用户只需确认肉换了多少、油多倒了多少，产品便沿用其余食材。家庭多人分餐时，每个人也能用自己的盘子称取，不再默认一锅必然等分成四份或六份。 首个版本优先支持条码食品、常见食材和手动校正的营养条目，并保留每次计算来源。它不提供减重建议或医疗判断，重点是把真实下锅量和真实盛出量记清楚。 ## 为什么是现在（有事实支撑） 8 月 6 日，一条 X 帖直接许愿，希望按自制食谱的成分列表计算总热量。 截至 8 月 8 日，该帖记录为发布后累计点赞 5 / 转发 0 / 浏览 53，说明这项具体录入摩擦已被用户公开说出。 ## 方向判断（以下为模型推断，未经独立验证） 目标用户：核心用户是已经称原料、记录热量，却常做一锅多人分食的人。最需要它的时刻，是锅已上火、双手沾水或油时。此时逐项解锁手机和输入克数最容易漏记。另一关键时刻是家人各自盛饭，固定四等份无法反映每个人实际拿走的量。 最小切入点：先做原生移动端，并只适配一种可稳定读数的蓝牙厨房秤。应用把稳定后的重量差记为待确认食材，保留撤回、合并和手动校正。包装食品通过系统条码扫描取码，再查询 Open Food Facts；常见原料用 USDA FoodData Central 搜索和详情接口补齐。 首版不做图片识菜，也不自动判断骨头和残渣。成品熟重与每盘取用量都由秤直接记录，计算结果保存食材条目、数据源和换算过程。 最强反方：秤的漂移、锅铲触碰和中途端锅，会制造错误重量差。每次误判都需要用户停下来确认，省下的输入可能又被校正吃掉。油、酱汁和带包装食材还会遇到单位或营养条目不一致。骨头与未吃部分无法仅靠出锅称重区分，必须增加残余称量或手动说明。兼容多种秤会带来协议、断连和售后成本。若结果常与用户现有记录相差明显，透明的来源记录也难以挽回信任。 以上是模型基于灵感本身与已核验事实的推断，请当作方向假设与真实约束对待：不要默认「最强反方」已被解决，也不要据此在产品里写下确定性结论。 ## 以小博大（模型推断） 第一批用户可从正在用厨房秤和表格记食谱的人中获得。用一段真实做咖喱的视频，展示逐项加料和逐盘盛出的完整过程。视频要同时摆出传统手输流程，直接呈现少了哪些操作。再提供可分享的菜谱模板文件，让备餐群和家庭控卡用户交换常做菜，模板自然带回产品入口。 ## 竞品与缝隙（模型推断） - Cronometer：Cronometer 已支持自定义食谱、按重量设份量，并允许录入成品熟重。这样可以按成品克数计算营养，已覆盖不少备餐需求。 不过其官方流程仍要逐项搜索食材、填写用量，再手动输入熟重。从该流程看，它没有把加料时的连续重量变化直接变成食材记录。做饭者仍需在烹饪前后切换秤、应用和输入框。它也没有围绕家庭分餐设计逐盘称取流程。可切入的缝隙不是更完整的营养日志，而是减少烹饪现场的录入动作。产品必须把换食材、撤回误加和临时加油做得足够快，才能形成明显差异。 ## 怎么赚钱（模型推断） 采用免费基础版加一次性硬件解锁。免费版可手动建食谱和按熟重分餐；购买适配秤或兼容功能后，开放连续称重、家庭成员档案与模板历史。 ## 来源背景 主题：按自制食谱成分计算总热量 触发的网络趋势观察：X @angxlbxte「I wish there was an app or website where i could calculate the calories of homemade recipes, like i could just add what was in it to a list it could tell me how much it was angel ໒꒰ྀིっ˕ -｡꒱ྀི১ (@angxlbxte) August 6, 2026」 有界观察：用户许愿有App或网站能通过添加自制食谱成分列表来计算总热量。；点赞 5 / 转发 0 / 浏览 53（发布后累计） 以上是带发布时间与观测时间的单条网络观察，不代表市场规模或广泛趋势；只用于理解「为什么是现在」。 ## 来源清单 - I wish there was an app or website where I could calculate the calories of homemade recipes（https://x.com/angxlbxte/status/2085429909506473988） - API Guide | USDA FoodData Central（https://fdc.nal.usda.gov/api-guide/） - Introduction to Open Food Facts API documentation（https://openfoodfacts.github.io/openfoodfacts-server/api/） - Create Custom Recipe（https://support.cronometer.com/hc/en-us/articles/360018510311-Create-Custom-Recipe） ## 交付要求 - 开工前，先从上文的产品概念与最小切入点提炼 3–5 条可验证的完成标准并列出，交付时逐条对照说明。 - 先交付「最小切入点」描述的核心流程，让核心用户能走通；范围外的账号、支付、后台等通用系统，除非确有必要否则不做。 - 页面或接口里不要展示未经验证的市场数字。 - 关键文案保持克制、可验证；产品内若需要领域事实、安全指引类内容，从「来源清单」等权威来源取材改写并注明出处，不要凭通识编写。 - 若在已有项目里实现：先读 README、依赖与项目约定，遵循既有技术栈与风格，不重构无关代码。 - 若当前目录为空：选一套轻量技术栈，优先交付可运行原型。 - 完成后说明改了什么、如何运行、如何验证。 - 遇到真正会改变产品方向的歧义再提问，普通实现细节自行做工程判断。