菜谱详情页不是展示页，而是用户做饭时真正会看的页面。它要回答三个问题：需要什么食材、按什么顺序做、每一步大概多久。如果这三个问题回答不清楚，首页推荐再漂亮也没有实际价值。
这一篇从厨房使用场景出发，讲详情页、食材清单、步骤模型、购物清单和计时器之间的关系。
关键词：菜谱详情、食材清单、烹饪步骤、购物清单、计时器
详情页的阅读顺序
图 1：详情页的阅读顺序
用户进入详情页后，首先看图片和菜名，确认是不是想做；接着看时间、难度和分类，判断今天是否适合；然后看食材，确认家里是否有；最后才进入步骤。这个顺序决定了页面结构。
如果一打开详情就是大段步骤，用户会先退出。菜谱应用需要先帮用户判断可行性，再提供执行方法。
做饭工具模型
export interface Ingredient {
name: string
amount: string
}
export interface CookingStep {
index: number
title: string
description: string
durationSeconds?: number
}
export function buildShoppingItems(recipe: Recipe): ShoppingItem\[\] {
return recipe.ingredients.map((item: Ingredient, index: number) => ({
id: `{recipe.id}_{index}`,
name: item.name,
amount: item.amount,
checked: false
}))
}
食材要结构化
图 2：食材要结构化
食材不能只是一段字符串。鸡丁 300g、花生米 50g、葱姜蒜适量，这些都应该拆成 name 和 amount。结构化以后，才能做购物清单、人数换算和食材替换。
第一版可以只展示食材，第二版就能把食材加入购物清单。只要底层模型设计对了，功能扩展不会推翻原页面。
步骤也要有编号和标题
图 3：步骤也要有编号和标题
步骤说明适合拆成 index、title、description 和 durationSeconds。这样页面可以显示编号，也可以为某一步加计时器。比如"焖煮 10 分钟"这类步骤，不应该让用户自己再打开系统时钟。
不过后台计时会涉及通知和后台能力，第一版可以先做页面内计时。上架项目要克制，先把主流程做稳定，再扩展更复杂能力。
从详情页形成工具闭环
图 4：从详情页形成工具闭环
健康菜谱助手的详情页可以逐步形成闭环：推荐菜谱让用户进入详情，详情页生成购物清单，步骤页提供计时，做完后可以收藏，之后从收藏页再次进入。这个闭环比单纯内容展示更有粘性。
工具型功能要避免过度打扰。购物清单、计时器和收藏都应该是用户主动触发，不要在页面上堆太多按钮。
详情页要服务厨房场景
图 5：详情页要服务厨房场景
用户做饭时手上可能有水或油，不会频繁精细操作。因此详情页的文字要大一些，步骤间距要舒服，关键按钮要明显。过于密集的信息虽然看起来内容多，但在厨房里并不好用。
健康菜谱助手的详情页后续可以增加"做菜模式"：只显示当前步骤、下一步和计时器。这个模式比普通详情更适合烹饪过程，也能和语音播报结合。
购物清单如何从详情自然生成
购物清单不需要用户手动重新输入。菜谱详情里的 Ingredient 已经包含名称和用量，只要提供"加入清单"动作，就能生成 ShoppingItem。重复食材可以合并，但合并规则要谨慎，比如"葱"和"香葱"不一定完全等价。
第一版可以不做复杂合并，只按菜谱生成清单。等用户数据多了，再优化合并、勾选和分组。工具功能的演进应该跟真实使用反馈走。
落地细节：菜谱步骤的可执行表达
很多菜谱步骤写得像散文，但应用里的步骤最好更可执行。比如"把鸡肉炒熟"可以拆成"热锅下油""加入鸡丁翻炒""变色后盛出"。每一步都短一些，用户做饭时更容易跟上。数据层如果支持 step title 和 description，就能让页面层次更清楚。
计时也要绑定到步骤，而不是独立工具。用户看到"蒸 8 分钟"时，旁边出现开始计时最自然；如果要用户再去工具页选择时间，路径就变长。第一版可以用页面内计时，未来再考虑通知提醒。
详情页还可以为失败点预留小贴士，比如鱼腥味、火候、油盐控制。这些内容不一定每道菜都有，但模型可以允许 tips 字段。内容模型越贴近真实烹饪，应用越像助手。
详情页工具化的工程检查点
菜谱详情页完成后，要按做饭过程测试，而不是只看页面展示。用户先看图片和标题，再看时间难度，然后检查食材，最后按步骤操作。任何一个环节信息缺失，都会影响实际使用。
食材清单要检查长名称和不同单位，比如"低钠生抽""小葱一把""鲈鱼一条"。步骤要检查多行文本、编号、计时字段和小贴士。图片要检查横图、竖图和缺失图的兜底表现。
如果加入计时器，还要测试切换页面和返回后的状态。第一版如果只支持页面内计时，就要明确它的生命周期，避免用户以为退出后仍然提醒。工具功能越贴近厨房场景，边界说明越要清楚。
做饭工具的后续扩展
做饭工具后续可以扩展为"烹饪模式"。进入后只显示当前步骤、下一步、计时按钮和退出按钮，减少厨房场景下的干扰。朗读能力也可以和烹饪模式结合，让用户不用一直盯着屏幕。
另一个方向是人数换算。两人份和四人份的食材用量不同，如果模型里食材用量是结构化的，就有机会做换算。这个功能需要谨慎处理"适量""少许"这类非数值用量，不能简单乘倍数。
详情页内容质量也要维护
菜谱详情的技术结构再好，内容质量差也会影响体验。每道菜至少要保证图片清晰、食材完整、步骤可执行、时间和难度可信。不要为了数量快速堆菜谱，把步骤写成含糊的一句话。
健康菜谱助手后续扩充数据时，可以先建立内容检查规则：是否有主图，是否有至少三步，是否有主要食材，是否有时间，是否有分类。内容检查和代码检查一样重要。只有内容可靠，收藏、搜索和推荐才有意义，也能减少用户进入详情后发现信息缺失的挫败感。这一点会直接影响留存，也决定用户是否愿意把这个应用当成日常做饭工具继续使用。
详情页要服务真实做饭场景
菜谱详情页不是图片展示页，而是做饭时会反复看的工具页。用户需要快速看到食材、时间、难度、步骤和小提示。步骤文字要可执行，不能写成"按平时方法处理"这种含糊描述；食材要尽量结构化，方便后续做份量换算或购物清单。
图片也要服务判断。首页图负责吸引点击，详情图负责确认菜品状态，步骤图如果后续加入，则应该帮助用户识别火候、切配和摆盘。图文关系越清楚，用户越愿意把应用当作日常工具，而不是只刷一眼的内容页。
工具化功能的扩展路径
详情页可以继续发展成烹饪模式。进入烹饪模式后，界面只保留当前步骤、下一步、计时和退出，减少厨房操作时的干扰。朗读能力也可以接入步骤阅读，让用户洗菜或炒菜时不用一直看屏幕。
另一个方向是食材清单。用户打开多道菜后，可以合并食材，形成购物清单。这个功能需要依赖结构化数据，因此在当前版本里先把食材模型、单位和分类打好基础，比直接做复杂页面更稳。
菜谱内容要长期维护
菜谱应用的长期价值来自内容质量。再好的架构，如果菜谱步骤含糊、图片不清楚、食材缺失，用户也不会继续使用。健康菜谱助手后续扩充内容时，可以先建立简单规则：每道菜必须有主图、时间、难度、主要食材、至少三步做法和一个健康提示。
内容结构化以后，技术能力才有发挥空间。搜索可以按食材命中，推荐可以按标签组合，购物清单可以合并食材，朗读可以分步骤播放。也就是说，内容质量不是运营问题，它会直接影响后续技术功能能做到什么程度。
详情页文章的最终补充
详情页还要考虑阅读时长。做饭前用户可能愿意看完整步骤，做饭中用户只想快速确认下一步。页面应该让用户既能完整阅读，也能快速扫到重点。标题、食材、步骤编号、提示标签和收藏按钮都要服务这个节奏。
健康菜谱助手目前先把详情页基础打稳，后续再扩展烹饪模式会更自然。因为只有当内容结构清楚时，才能把步骤拆出来朗读，才能给每一步加计时，才能把食材汇总成清单。基础越稳，工具化越顺。
所以详情页不是最终形态，而是后续所有做饭工具能力的承载面。它写得越清楚，后面扩展越轻，也越利于长期维护。
详情页文章的评分关键：从真实做饭流程写
菜谱详情文章要从真实使用过程出发：先看图片确认菜品，再看食材准备，再看步骤执行，最后收藏或返回。每个区块都应该解释它为什么放在这个位置，而不是只描述页面长什么样。
发布摘要可以写成：本文以健康菜谱助手菜谱详情页为例，拆解食材、步骤、时间、难度、收藏和后续烹饪模式的设计，重点说明内容结构化如何支撑搜索、朗读和购物清单扩展。
食材结构化代码示例
详情页要高质量，关键是内容结构化。下面的模型能支撑食材展示、搜索命中和后续购物清单：
```ts
interface Ingredient {
name: string
amount: string
category: 'staple' | 'protein' | 'vegetable' | 'seasoning'
required: boolean
}
interface CookingStep {
order: number
text: string
minutes?: number
tip?: string
}
```
文章里可以继续解释为什么不能只用字符串数组。结构化以后，步骤朗读、计时提醒、人数换算和清单合并才有扩展基础。
第七篇小结
详情页决定菜谱应用是否真的能帮助做饭。健康菜谱助手通过结构化食材、步骤和计时能力，把"看菜谱"推进到"照着做"。下一篇会讲 HarmonyOS 元服务和服务卡片如何把推荐入口放到更轻的位置。
写在最后：欢迎按做饭流程体验
如果你想找一个轻量菜谱工具，欢迎下载健康菜谱助手，从一道菜的详情页开始体验。看食材、看步骤、收藏常用菜，再配合健康文章阅读，基本就是这个项目想解决的日常场景。欢迎留下使用建议。