烹饪屏的体验分水岭，往往不在硬件，而在菜谱的数据结构。苹果 HomeView 把 iPhone 靠近屏幕投上 Safari 食谱链接后，烹饪模式能呈现菜图、菜名、作者、时间、份量，并把内容分为“配料”和“开始烹饪”；进入烹饪后步骤变成可滑动卡片，还带计时器快捷方式。这套交互看起来顺滑，但有一个前提常被忽略：菜谱发布者是否提供了分步结构。没有这个结构，用户只能面对一长段文字滚到底。
结构化与非结构化，差的是交互可能性
从信息架构角度看，菜谱至少包含配料清单、步骤序列、时间参数和份量换算四类字段。配料清单是购物清单的输入源，HomeView 已经支持让 Siri 把配料加进提醒事项；步骤序列则是烹饪卡片的骨架。如果发布者只输出连续段落，屏幕端就无法切分卡片、无法绑定计时器、无法做步骤跳转。这不是苹果没做好，而是源数据没有提供可解析的粒度。
对烹饪场景来说，手上有油、眼睛离屏幕有距离，滑动卡片和滚动长文是两种完全不同的认知负荷。前者一次只处理一个动作，后者要求用户在文字流里自行定位进度。屏幕尺寸固定为 7 英寸方形，长文滚动会进一步压缩可视区域，体验差距被放大。
格式约定比功能宣传更值得关注
苹果展示的是理想状态下的烹饪体验，但不保证每次都有。这句话点出了智能屏内容生态的普遍问题：终端厂商能定义交互容器，却定义不了内容供给方的输出规范。菜谱平台若继续以网页长文为唯一形态，烹饪屏的辅助价值就停留在“把手机屏幕放大”这一层。
真正决定体验的，是菜谱是否被写成机器可读的步骤单元。对内容发布者而言，这意味着一套轻量的结构化约定：配料独立成列表、步骤按顺序分段、时间参数显式标注。对终端用户而言，判断一块烹饪屏是否好用，与其看演示视频，不如先投几个自己常做的菜谱链接，观察它们能否被切成卡片。格式决定了屏幕能做到什么，硬件只是提供了可能性。