中式美食的链路走到买菜清单以后，下一步就是厨房执行。

这个页面和普通菜谱详情页不一样。菜谱详情页通常是“看信息”，厨房执行页更像“边做边跟”。用户手上可能有水、有油、有锅铲，不会慢慢读长段文字。所以页面必须非常直接：现在做哪一步、还剩多久、火候怎么控制、下一步是什么。

这篇拆当前项目里的KitchenExecutionPage。它的核心状态只有两个：making表示是否已经开始做菜，currentStepIndex表示当前走到第几步。两个状态配合起来，就能让预览态、制作态、当前步骤卡、下一步提示和底部按钮保持一致。

本文验证环境

这里讲的是当前 Flutter 工程里的实现。后面迁到 ArkUI 时，最值得保留的是这个状态拆法：一个状态控制页面模式，一个状态控制当前步骤。

先分清预览态和制作态

厨房执行页刚打开时，不应该直接把用户扔进倒计时。用户可能只是想先看一眼节奏。所以页面有一个making状态：

class_KitchenExecutionPageStateextendsState<KitchenExecutionPage>{bool making=false;int currentStepIndex=1;KitchenStepDatagetcurrentStep=>kitchenSteps[currentStepIndex];voidstartMaking()=>setState(()=>making=true);}

making = false时，页面展示预览：先做什么、关键调味、出锅判断。用户点“开始制作”以后，才进入真正的步骤跟随模式。

这个区别很重要。很多工具页一上来就给用户一堆步骤，用户还没准备好就被推着走。中式美食这里先给预览，再让用户主动开始，会更符合厨房场景。

当前步骤只认 currentStepIndex

当前步骤通过currentStepIndex取出来：

KitchenStepDatagetcurrentStep=>kitchenSteps[currentStepIndex];

然后页面里的标题、步骤卡、下一步提示都会围绕currentStep变化。

我不建议给标题、卡片、底部按钮分别存一套当前步骤。这样看着灵活，其实很容易错位。比如标题显示第 2 步，卡片还是第 1 步，底部按钮又跳到第 3 步。只要用户遇到一次，就会觉得这个工具不可靠。

一个 index 驱动整个页面，是更稳的写法。

完成一步，只移动 index

步骤切换也很直接：

voidcompleteStep(){setState((){making=true;currentStepIndex=(currentStepIndex+1).clamp(0,kitchenSteps.length-1,);});}voidpreviousStep(){setState((){making=true;currentStepIndex=(currentStepIndex-1).clamp(0,kitchenSteps.length-1,);});}

这里有两个细节。

第一，切换步骤时顺手把making设成true。用户点上一部或完成当前步骤，本质上已经进入制作态了，不应该再回到预览页。

第二，用clamp()卡住边界。厨房场景里用户可能连续点，边界保护必须有。否则最后一步再点一次，数组越界就是很低级的体验事故。

步骤数据要写得像厨房话

KitchenStepData不是为了服务代码，而是为了服务用户做菜：

classKitchenStepData{constKitchenStepData({requiredthis.index,requiredthis.timeRange,requiredthis.title,requiredthis.command,requiredthis.tool,requiredthis.timer,requiredthis.icon,requiredthis.ingredients,requiredthis.heat,requiredthis.seasoning,requiredthis.doneCue,requiredthis.rescue,this.warning,});}

这里我比较看重doneCue和rescue。

很多菜谱只写“煮 8 分钟”“大火翻炒”，但用户真正需要的是判断依据和补救办法。比如汤太油怎么办，青菜出水多怎么办，鱼太厚怎么办。把这些字段提前放进模型里，页面就能把“怎么判断”和“出错怎么救”讲清楚。

这也是中式美食和普通菜谱列表不一样的地方：它不是只告诉你做法，而是尽量让你在厨房里少慌一点。

下一步提示要一直露出来

制作态里除了当前步骤卡，还有一个下一步提示：

KitchenNextStepStrip(step:kitchenSteps[(currentStepIndex+1).clamp(0,kitchenSteps.length-1,)],isLast:currentStepIndex==kitchenSteps.length-1,)

这个设计很实用。用户在做当前步骤时，眼睛扫一下就知道下一步要准备什么。比如现在在煮汤，下一步要备鱼；现在在蒸鱼，下一步要准备上桌。这样能减少临场慌乱。

在厨房里，“下一步是什么”比“完整步骤列表”更重要。完整列表适合学习，下一步提示适合执行。

底部操作栏跟着模式变化

页面底部根据making切换两套操作：

bottomNavigationBar:making?KitchenMakingBottomBar(onPrevious:previousStep,onComplete:completeStep,):KitchenPreviewBottomBar(onStart:startMaking),

预览态只需要一个核心动作：开始制作。

制作态需要两个核心动作：上一部、完成这一步。

这个地方不要贪多。厨房里用户不需要一排按钮，不需要复杂菜单，只需要顺着走。按钮越少，越不容易误操作。

工程验收记录

本文小结

厨房执行页的难点不是做出一个复杂页面，而是把用户当时的状态照顾好。

还没开始做时，先给预览；开始做以后，只突出当前步骤和下一步；切换步骤时，只移动currentStepIndex，别让多个组件各管一套状态。这个思路很简单，但对生活工具特别有效。

中式美食后面如果继续做家庭偏好、库存提醒、菜谱记录，这个厨房执行页会成为很重要的承接点。因为用户真正产生价值，不是在看到推荐那一刻，而是在照着它把一桌饭做出来的时候。

最后留个问题：厨房执行页里的倒计时，你会做成真实计时器，还是先做成步骤提示和手动完成？我现在更倾向先手动完成，因为厨房节奏受锅具、火力和食材大小影响很大，强行倒计时反而容易误导。