全部作品02 / 04

状态与确认

建议、计划与记录各自清楚

推荐是候选,计划是打算吃,记录是确认吃过。

计划一份餐食,实际只吃半份,应怎样记录?

项目性质
饮食管理交互原型
实现方式
本地规则识别与示例菜品
本次展示
条件核对、计划与实际记录
时间
2026.10 – 至今
开发工具
Codex、Claude
TasteTwin 首页:湖边场景中的数字分身,两侧是饮食数据面板
本地规则原型,示例数据,没有调用真实模型。它验证的是交互与账务,不作为健康建议。

确认吃过,才计入摄入

把“打算吃”和“已经吃”分开,避免直接把推荐值记成摄入。点下面的步骤,看三个数字怎么变。

已吃
1,344kcal
未吃计划
0kcal
预计
1,344kcal

三道示例菜品。推荐只是候选,什么都还没记。

1 / 5

TasteTwin:看到推荐TasteTwin:加入计划TasteTwin:核对实际份量TasteTwin:确认记录TasteTwin:查看这一餐
这组画面怎么来的

同一示例存档的连续操作,不是真实用户的健康记录。计划行仍显示 1 份,实际摄入按已保存的半份记账。

把识别到的条件摆出来

输入“清淡鸡肉,20 分钟内”,再手动改成鱼虾、15 分钟内。

用一句话说这顿想吃什么。

1 / 3

TasteTwin:输入一句话TasteTwin:规则识别TasteTwin:手动修改

档案与本次要求分开

右侧条件可以改选。这些标签尚未驱动完整的推荐匹配。

这组画面怎么来的

同一规则示例任务的连续界面。本地规则原型,没有调用真实模型。

推荐流程的录屏

80 秒,示例数据演示。

这组画面怎么来的

录屏来自本地原型的示例数据演示。