Community生产力与协作github.com

tiny-glitch/recipe-timeline

将传统菜谱转换为按执行顺序排列的烹饪时间线,帮助厨师高效安排步骤。

recipe-timeline 是什么?

这是一个将传统菜谱重新渲染为执行顺序烹饪时间线的AI工具技能。它解决了菜谱通常按书写顺序列出步骤,而实际烹饪需要按依赖关系和时机执行的问题。该技能支持四种模式:时间线模式(默认,适用于大多数主菜)、序列模式(适用于关注时间极短、无空闲时间的菜肴)、计划模式(适用于主动工作时间少、等待时间长的烘焙或发酵菜肴)以及混合模式。它具备提取菜谱信息、扩展隐含准备步骤、构建依赖图、处理设备冲突和营养信息计算等功能,并严格遵守不凭空编造步骤或成分的原则。该技能主要适用于Claude Code等AI助手,通过保持代码、命令和文件路径不变,确保专业翻译的准确性。

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add tiny-glitch/recipe-timeline

Installed? Explore more 生产力与协作 skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

食谱时间线

将常规菜谱转换为单人厨师的可执行计划。

菜谱按书写顺序列出操作。此技能将其重新渲染为执行顺序——一个对照时钟布局的烹饪依赖图。

每个计划行同时回答三个问题:

  • 我在哪里? — 累计位置
  • 距离我必须行动还有多久? — 间隔标记
  • 我现在有空吗? — 垂直规则的权重

准备工作的根本规则:

尽可能晚地准备,同时又尽可能早地必要


0. 首先路由:模式和适切性

在任何其他操作之前,先对菜谱进行分类。选择错误的模式是最常见的失败。

如果菜谱少于5个操作且没有有意义的时机或并行性——比如炒蛋、沙拉、冰沙——建议使用简单的编号序列而非完整计划,并用一句话说明为什么使用完整计划会是过度设计。如果用户明确要求时间线格式,则提供给他们。 此阈值是默认值,而非拒绝。

否则选择一种模式:

模式 A — 时间线(默认)

至少有一个超过3分钟的时间间隔且操作数不少于6个。适用于大多数炉灶主菜、炖菜、咖喱、意面、烤盘晚餐。

模式 B — 序列(注意力主导)

大多数间隔小于90秒:比如炒菜、煎蛋卷、强烈调温的菜肴、快速翻炒——任何厨师无法离开锅具的情况。

模式B中没有空闲时间,所以不要假装有。输出:

  1. 按拿取顺序准备的食材——在加热前全部准备好并排列好,按照将要被拿取的顺序列出。
  2. 一个加热前块,包含任何预热门槛及其前置时间,位于序列时钟之外。时钟从前菜接触热源时开始计算,而非从锅具接触热源时。
  3. 一个快速序列,带有累计秒数和门槛,没有[+n]标记且内部无准备任务。
  4. 显式说明行:"从加热到上菜大约N分钟,中间无暂停。以上所有物品必须首先放在触手可及之处。"

模式B是"不要在时钟前倾倒所有准备好的食材"规则的例外。在这里,这样做是正确的。

模式 C — 计划(等待主导)

主动工作时间仅占整个耗时的一小部分:烘焙、面包、冷制甜点、发酵、真空低温烹饪、隔夜炖菜、任何有长达数小时尾段的菜肴。输出从服务时间倒推的工作会话,而非从零点开始的连续时钟。

混合模式

许多菜谱是模式A加模式C的尾段——香蕉面包是20分钟的时间线加上70分钟的冷却。渲染时间线,然后添加一个主动烹饪后部分。在尾段完成之前不要标记菜肴已完成。

修改现有计划

当用户改变已有计划的菜谱——添加配菜、删除组件、设置服务时间、加倍数量——从原始来源重新运行整个技能。不要修补之前的输出。

计划是图,而非列表。一个新组件会改变合并的操作列表,下游标记也会随之移动;它还可能造成冲突,消耗最后一个空闲准备窗口,占用炉头上的第二个灶眼,超过锅具容量,或将餐食推过两条车道并进入服务时间锚定。局部编辑正是导致计划内部不一致、过时标记指向已移动操作的原因。

重新运行成本很低。真正高昂的是丢失先前通过建立的内容,因此要在一个保留内容标题下显式地延续它们:

  • 用户提供的、但原来源中未包含的方法
  • 他们给出的服务时间、份数或容器数量
  • 他们对上次输出做出的更正
  • 他们说的任何不同做法

陈述这些信息使其可修正,而非默默假设。

然后,在新计划下方,添加一个简短的移动的内容列表——仅限改变了位置或关注点的内容,而非重新列举:

移动的内容
- 大蒜 9 分钟 → 11 分钟(意面锅现在从4分钟开始)
- 22分钟处冲突:沥水操作移到了菠菜枯萎步骤中
- 现在有两个热组件,因此计划锚定到服务时间

用户可能已将旧计划记在脑中。告诉他们哪些内容发生了迁移,正是重新运行而非修补的意义所在。


1. 来源门槛

如果食材存在但方法缺失,则停止。报告无法构建可靠的计划。不要凭空编造一个看似合理的菜谱。

如果方法存在但时间缺失(在菜谱博客和传统菜谱中非常常见),则继续——但根据§7标记推断的时长,并为每个基于线索的步骤首先给出线索而非数字。


2. 提取

从来源中捕获:标题、份数、食材、说明、声明的时间、温度、设备、熟成线索、配菜以及任何声明的营养数据。

不要改变食材数量。

如果用户要求缩放菜谱,请注意时长不会线性缩放——加倍的量会更慢地变色,可能需要更大的锅具,或者可能需要分批操作(§7,重复周期)。


3. 营养信息

每个输出在顶部附近带有份数、能量和宏量营养素,位于设备和食材上方。厨师根据此块决定是否制作该菜肴。

## 营养信息 *(计算值)*

- **能量** ~300大卡/份 · ~1,200大卡总量
- **蛋白质** 13 克 · **碳水化合物** 42 克 · **脂肪** 9 克

蛋白质、碳水化合物和脂肪是默认的三项。仅在来源给出时才包含纤维、糖或钠。始终同时显示每份和总量。

来源,始终标注

(来自来源) — 菜谱声明了这些数据。逐字引用。不要重新计算,即使你自己的估算与之不符,也不要"修正"。

(计算值) — 由你根据食材列表计算。永远不要将这些呈现为菜谱本身的数字。

省略 — 食材无法支持估算。保留标题未标记,并在列表中说明障碍:

## 营养信息

- **能量** 未估算——"用于油炸的油"没有数量,且吸收的油脂主导了该数值。

标签放在章节标题中,而非列表下方的单独一行。标签单独成行会成为孤儿:它既不属于上面的块也不属于下面的块,因此渲染器不会给它锚点,读起来像是后续章节的标题。任何无法放入标题的注意事项放在列表下方的普通行中:"仅 rajma;米饭每份约增加205大卡。"

来源用文字表示,而非括号。括号有它们的用武之地——[+n]标记,它们位于自己的一列中;在标题中没有列,并且括号读起来像机器输出。

这种区分类似于时长的[+n] / [≈n],并遵循相同规则:将编造的数字呈现为来源数字是保真度失败。

份数

每份数值需要份数。

  • 来源声明 → 使用它。像"分装到6个容器"这样的储存说明也声明了份数。
  • 未声明 → 根据总量推断并在列表下方说明:"份数根据容量计算。"
  • 无法推断 → 仅显示总量,并说明每份数值需要份数。

当来源仅给出每份数值时,将其乘以总量是基于其数字的算术运算,而非新的估算。它仍然是(来自来源)。

当来源自相矛盾时

在回复中一次性提出,然后继续。不要等待答案,也不要将调和结果渲染到计划中——计划是会被发布的,而只看到一组数字的读者不需要了解选择背后的算术。

解决方法:采用与所写菜谱匹配的数字——食材列表起主导作用,而非基于其他数量计算的表格。将其标记为(来自来源),就像其他声明的数字一样。

在计划旁边,一次性:

食材列表说20-30克帕玛森芝士,但第二个营养表是基于66克计算的。
我使用了20-30克的数字——如果你想要另一组请告诉我。

如果用户回答,根据他们的选择重新运行。如果没有,计划已经成立,无需重做。

诚实估算

以下是导致食材列表估算结果错误的原因。每个都有规则:

  • 油炸油——只有吸收的部分算数,而非整锅油。浅炸和深炸大约吸收食物重量的10%的油。如果食谱说"适量油炸用油"但没有数量,则无法估算——跳过而不是猜测。
  • 丢弃的腌料——大约计算四分之一,即附着在食物上的量。
  • 盐水、盐水煮开的水——大部分丢弃。除非来源追踪钠含量,否则忽略。
  • "盐适量"、"油根据需要"——视作零并说明。
  • 修剪物、骨头、壳、皮——根据可食用产量估算,而非购买重量。
  • 浓缩——蒸发去除水分,而非能量。浓缩后的酱汁热量与浓缩前相同。不要因为炖煮而缩小数值。
  • 酒精——假设炖煮菜肴中大约保留一半,未加热菜肴中几乎全部保留。
  • 菜谱中未计价的配菜——排除它们,并说明数值仅针对菜肴本身。

精度纪律

基于食材列表的估算最多精确到±15%。永远不要渲染得比这个支持更精确:~520大卡,而非518大卡。能量四舍五入到最接近的10大卡,宏量营养素四舍五入到最接近的克。不要在宏量营养素上使用范围——硬性四舍五入,让(计算值)承载不确定性。来源给出的范围则按原样保留。

范围

报告算术结果,然后停止。不要评论数据是高是低,建议替换以改变它们,或附上饮食建议——这些都不是该技能被要求做的事情。删除来源自身携带的任何评价性语言("非常饱腹"、"中等饱和脂肪"),保留数字。

不要为已在来源门槛处失败的菜谱产生估算。如果方法不可信,数字也不可信。


4. 扩展隐含准备

菜谱省略了明显的执行步骤。对于每个操作,问:

此操作发生时,该食材必须处于什么物理状态?

加入洋葱 → 洋葱必须切好 → 创建准备任务。 加入番茄泥但来源列出的是完整番茄 → 创建:制作番茄泥。 加入香料且列出了五种香料 → 创建:量取香料。

常见的合理添加:切碎或切片芳香蔬菜;剁碎或磨碎姜和蒜;沥干并冲洗罐头食品;洗米;量取香料;切柑橘;切香菜;打开包装;取出冷冻品;在倒出或沥干前放置容器;当方法依赖时,将乳制品或鸡蛋恢复至室温。

执行推断 vs 烹饪发明

允许的——推断方法所预设的准备要求。

不允许的——添加来源中没有的食材;将来源中说的切碎改为泥状;缩短声明的时间;改变温度或技术;替换。

推断准备。不要重写菜肴。


5. 构建图

主干

一个主要流程:具有最多顺序依赖关系、需要最多干预、并决定其他所有步骤何时开始的流程。

流程并不是仅仅因为它们同时进行或在不同容器中执行就被视为独立组件。煮豆子、制作豆糊、以及将它们合并是一道菜、一个车道。

分支,以及其方法的来源

分支是真正独立的餐食组件:米饭、意面、土豆、蔬菜配菜、raita、单独制作的酱汁。从它实际上应该开始的时间点开始,而不是从时钟0开始。

**分支需要方法。**服务建议不是分支:

来源仅说"配米饭上菜"——未给出方法:

  ## 配菜
  米饭——方法未给出。

用户提供了方法——允许分支,并注明来源:

  米饭方法由你提供,而非来源:
  洗 · 煮 · 小火 + 盖煮12分钟

10分钟   ├·······→ 🔪 洗米 · 锅上炉

方法可能来自来源、第二个菜谱或用户。当来自用户时,在输出中说明,以便读者了解这些步骤的来源。不要凭空制造方法。

门槛和停止条件

条件是,而非时长。永远不要仅靠时钟推进。

◆ 当条件为真时继续 — ◆ 直到油光闪烁、◆ 烤箱200°C、◆ 水滚沸、◆ 面团体积翻倍、◆ 牙签拔出干净

◇ 一旦为真立即停止 — ◇ 刚刚混合均匀、◇ 出现第一点颜色、◇ 稍欠火候。与◆极性相反,混淆它们会毁掉面糊、蛋奶和乳液。

🌡 内部温度 — 只要来源给出就使用。一个门槛,而非感官线索;它绝对凌驾于时钟之上。

门槛也包括设置前提条件,如果错过该步骤将不可逆。将其放在操作上方行,而非操作内部:

         │         ◆ 水槽边放杯子
23分钟   │         ● 保留1杯 · 沥干

余热烹饪

烤肉、厚切块和大件烘焙品在离开热源后继续烹饪——通常对于大块肉或禽类为3-5°C,对于非常大的块更多。当来源给出最终温度时,在该数值减去余热效应后取出并说明:

🌡 在71°C时取出——静置期间升至约75°C

设备

尊重共享的锅具、灶眼、烤箱空间、搅拌机。两种情况,它们不同:

共享——两者同时使用且温度相同。注意负荷并继续。

争用——一次只能用一个,或温度冲突。按以下顺序解决:

  1. 温度差在~15°C内——使用较高温度,并通过更早检查其门槛来提前取出更娇贵的物品。
  2. 温度差更大——排序它们。耐热性更好的物品先进行并等待:烤肉可以愉快地静置20分钟,而土豆在更高温度下变脆。
  3. 两者都不可行——说明冲突并提供选择。不要默默选择其中一个。

同时标记容量:计算终产物的总体积,当菜谱需要...

…[翻译截断]

相关技能