“粘贴任意菜谱链接，我们帮你导入”——这句话听起来简单，直到你真正要同时支持TikTok、Instagram、YouTube、Pinterest、某个随机美食博客、一张截图，还有一张手写菜谱卡的照片。所有来源都得走同一条处理管线，而且输出质量不能跌到最低水平。

问题真正的形状是这样的：每一种来源交给你的原始材料都完全不同。TikTok的文案可能把整份菜谱塞进一堆标签里。美食博客把真正的菜谱埋在800字的人生故事后面，配料表才姗姗来迟。截图在OCR跑完之前根本没有文字。YouTube视频可能只把菜谱放在口播音频里，从头到尾没有一个字写出来。

两段式管线，而不是“全丢给大模型碰运气”

我们没有做一个“把所有东西扔给大模型然后祈祷”的大函数，而是把它拆成两段。第一段是智能链接路由器，它识别来源类型，选择对应的提取策略。第二段是一个共享的AI解析器，它只会看到一种统一格式的导入文档——不管这份文档来自博客的结构化标记，还是三分钟视频音频转写出来的文字，形状都一样。

路由器的全部工作，就是把乱七八糟、来源各异的输入整理成一种一致的形状。解析器的全部工作，就是把这种一致的形状变成结构化菜谱。两者都不需要知道对方的问题。这个拆分之所以重要，是因为增加第8个来源时不用重写解析器，改进解析器时也不用重新测试每一种来源的提取逻辑。这跟把编译器拆成词法分析器和语法分析器、而不是用一个函数从原始文本直接生成抽象语法树，是同一个道理——不同的失败模式，应该交给不同的、相互隔离的代码。

更难的是：提取不完整时，不许AI补全

更考验纪律的是，当提取结果不完整或含糊时该怎么办。让AI解析器自信地填补空缺很容易——推断一个缺失的用量，猜一个在文案里被截断的步骤。我们不这么做。管理营养引擎的“不插补”原则，同样管理着导入功能：如果来源里没有真正写出来，导入的菜谱就不会声称自己知道。用户检查一份导入菜谱时，看到的应该是实际能提取到什么内容的诚实反映，而不是一份看起来很有把握、其实在空白处悄悄脑补出来的菜谱。

这才是“粘贴任意链接，我们帮你导入”背后真正的工程权衡：它不是一个难题，而是八个来源各自的提取难题，加上一条共享的诚实约束。把它当成更简单的东西来处理，最后做出来的导入功能，就是那种演示时很惊艳、一碰到真实互联网上乱七八糟的内容就崩掉的东西。

我正在开发Rasora，一款能从TikTok、Instagram、YouTube等平台导入菜谱的AI应用——可以在myrasora.com查看。