grouchygiraffe-ingest

Grouchygiraffe 导入工作流

参数可以是本地文件路径，也可以是 URL。

根据参数判断输入模式：

• 如果以 http:// 或 https:// 开头：URL 模式——跳转到下方的 URL 路径
• 否则：文件模式——按下方的文件路径操作

文件模式涵盖两种情况：已存放在 grouchygiraffe 数据目录中的媒体文件，以及粘贴或截屏得到的独立图片等。不要假设独立图片与 grouchygiraffe 无关——下方的第 0 步会判断这一点，而且判断成本很低。

除非某一步失败，否则不要在步骤之间向用户提问。

---

URL 模式

参数为 URL 时，跳过文件流程中的第 1 步和第 2 步，直接进行 recipe-cleanup；具体操作根据 URL 类型略有不同：

YouTube URL（youtube.com/watch?v=... 或 youtu.be/...）：

直接使用 YouTube URL 调用 recipe-cleanup 技能。

recipe-cleanup 会从 YouTube 提取视频缩略图并设置 pic 字段——无需单独上传到 Imgur。

Instagram 或其他社交媒体 URL：

首先使用该 URL 调用 social-to-imgur 技能，获取永久的 Imgur 缩略图 URL。

然后使用该 URL 调用 recipe-cleanup 技能。

recipe-cleanup 写入文件后，将 frontmatter 中的 pic 字段更新为 Imgur URL——社交媒体 CDN URL 会过期。

最终报告（URL 模式）：

所有步骤完成后，报告：

• 食谱名称
• 作者姓名
• 写入知识库的食谱文件路径
• 来源 URL

---

文件模式

数据目录为 /Users/mtm/pdev/taylormonacelli/grouchygiraffe/data——下文称为 DATA。

每条归档帖子都以 <shortcode>.mp4（或 .jpg）、<shortcode>.yaml 和 <shortcode>_thumb.jpg 的形式存储在该目录中。

先将文件解析为 shortcode（第 0 步），然后按顺序运行三个技能。

步骤 0：将输入文件解析为 shortcode

如果文件已位于 DATA 中（例如 /Users/mtm/pdev/taylormonacelli/grouchygiraffe/data/DX9oSBkjsZR.mp4），shortcode 就是去掉扩展名和末尾 _thumb 后的文件名。直接进入步骤 1。

否则，该参数是一个散落的图片——粘贴的屏幕截图、保存的缩略图、作业目录或下载目录中的文件。先通过内容哈希找回 shortcode，再进行其他操作。

从 Instagram 帖子保存或粘贴的图片，通常与 grouchygiraffe 已为该帖子存档的 _thumb.jpg 字节完全相同，因此精确摘要匹配即可直接识别帖子，只需两条命令。

计算输入文件的哈希：

md5 -q <input_file>

将每张已存档缩略图的摘要写入临时文件，然后在其中搜索该摘要：

md5 -r <DATA>/*_thumb.jpg > "$TMPDIR/gg_thumb_digests.txt"

rg "^<digest>" "$TMPDIR/gg_thumb_digests.txt"

如果找到匹配项，会得到 <DATA>/<shortcode>_thumb.jpg 格式的路径。移除目录和 _thumb.jpg 后缀，得到 shortcode，然后使用它继续执行步骤 1。

如果摘要没有匹配项，说明图片在某处经过了重新编码、裁剪或缩放——或者它确实并非来自已存档的帖子。但暂时不要得出后一种结论，也不要在此搜索也无结果之前，将图片视为孤立图片处理：

读取图片，识别菜品和任何可见的叠加文字。

搜索已存档的说明文字，例如，若识别出的菜品是薯饼：

rg -il "hash brown" --glob "*.yaml" <DATA>

读取每个候选 shortcode 对应的 _thumb.jpg，并与输入图片进行视觉比较。这样很容易确认同一张照片是否经过了裁剪或重新编码——比对取景、道具和摆盘即可。

只有这一步也没有找到任何结果，才能将该图片视为没有对应的已存档帖子。在这种情况下，直接根据图片识别食谱，在最终报告中注明未找到 shortcode，并跳过步骤 2 中使用 Instagram URL 的操作。

**重复帖子：**同一个账号经常会多次发布同一道食谱，有时还会使用同一张照片的不同裁剪版本。录入实际匹配到的帖子，并在最终报告中提及同一食谱的其他相关帖子，而不是分别为它们撰写笔记。

步骤 1：grouchygiraffe-recipe-lookup

针对步骤 0 中解析出的 shortcode 对应的媒体文件，调用 grouchygiraffe-recipe-lookup 技能——<DATA>/<shortcode>.mp4，如果帖子是静态图片，则使用 .jpg 文件。

如果步骤 0 是从散落的图片中找回 shortcode，请传入已存档的路径，而不是用户提供的路径——查找技能会据此推导同级的 .yaml 和 _thumb.jpg 文件。

从输出中收集：

• 原始 Instagram 帖子 URL（取自 YAML 中的 url 字段）
• 直接的食谱 URL（作者的网站、TikTok 或 Substack）
• 作者姓名和 Instagram 用户名
• 食谱名称

步骤 2：social-to-imgur

使用步骤 1 中收集的原始 Instagram 帖子 URL，调用 social-to-imgur 技能。

从输出中收集：

• 缩略图的永久 Imgur URL

步骤 3：recipe-cleanup

使用步骤 1 中的食谱 URL，调用 recipe-cleanup 技能。

recipe-cleanup 会写入食材的 wikilink，然后委托给 resolve-recipe-ingredient-link 技能，解析所有未指向现有产品笔记的链接——因此，运行此工作流生成的笔记中的食材链接，在步骤 3 返回时已经解析完毕。不要另行解析这些链接。

写入食谱文件后，更新 pic frontmatter 字段，使用步骤 2 中的 Imgur URL 替换清理时设置的 URL——Imgur URL 是永久链接，不会因 CDN 过期而失效。

最终报告（文件模式）

完成全部三个步骤后，报告：

• 菜谱名称
• 作者姓名和 Instagram 用户名
• 写入知识库的菜谱文件路径
• Imgur 缩略图 URL
• 原始 Instagram 帖子 URL
• 短代码；如果输入的是独立图片，还要说明短代码的确定方式（摘要完全匹配，或通过候选说明文字搜索进行视觉确认）
• 其他发布了同一菜谱的关联帖子

先检查是否已有笔记

写入目标笔记前，检查它是否已存在；如果存在，请先阅读。

许多较旧的笔记是仅包含主图和说明文字的存根，但其 pic 已指向先前运行时生成的永久 Imgur URL。

覆盖存根会悄无声息地破坏该 URL，而重新上传同一张图片会消耗共享的 Imgur 配额，这已经是瓶颈所在。

写入前，检查 <name>.md 并运行 git log -- <path>。如果存在先前版本，恢复其中的 pic 值并复用，而不要执行上传；同时保留存根中已有的任何说明文字或笔记。

多个写入进程并发运行时，这一点尤为紧迫：其他进程可能会在错误被发现前提交已被覆盖的文件。