菜谱信息的处理方法、装置及系统与流程

本申请涉及信息处理技术领域，尤其是涉及到一种菜谱信息的处理方法、装置及系统。

背景技术：

随着社会的高速发展，餐饮行业也发展迅速。目前餐饮行业中菜谱的创建过程多采用传统的一体式菜谱创建方式，在一个菜谱文件里通过人工调整参数实现多种份量菜谱的创建。具体在制作标准份菜谱的时候，同时通过调整标准份菜谱的相关参数实现多份量菜谱的支持，各个多份量与标准份之间存在直接依赖关系，共用一套执行代码，依赖相同的设备，彼此是共生关系。

然而，在上述传统方式中，标准份量是基础，不同份量菜谱之间强耦合，一损俱损，进而造成菜谱管理困难。并且按照现有的创作方法，完成制作一个支持多个不同份量的菜谱，创作+测试的工作量巨大，每增加一个对某份量的支持都需要调整任务步骤里的术语参数、食材配料用量、口味参数等，对参数的调整可能影响到已有的测试结果，需要针对该份量重新进行测试，同时也要准备多份食材，上述太过复杂的流程打击了厨师的创作积极性；菜谱一旦发布则不能更改，所以发布前必须进行非常仔细的检查，某份量下的一个细小的错误会导致整个菜谱全功尽弃，而一体式菜谱的设计原则是把影响菜谱执行的参数都尽可能提取出来加以控制，这导致了需要调整的参数数量非常大，增加了人为犯错误的机会。同时，多参数的调整使得界面操作复杂，在程序实现上也难以设计交互友好的界面，提高了厨师的学习成本，不便于产品的推广。此外，一体式菜谱只能对执行参数进行调整，不能进行执行代码及执行顺序的调整。一体式菜谱需要所包含的多个不同份量都创作完成才能发布；一旦发布，菜谱不能更改，如果对某一份量的参数进行调整则要放弃整个菜谱。

技术实现要素：

有鉴于此，本申请提供了一种菜谱信息的处理方法、装置及系统，主要目的在于解决目前传统一体式菜谱创建方式会造成菜谱管理困难的技术问题。

根据本申请的一个方面，提供了一种菜谱信息的处理方法，可应用于客户端侧，该方法包括：

发送菜谱获取请求，所述获取请求中携带有菜谱标识；

当所述菜谱获取请求中包括相同菜谱标识的多个不同份量菜谱获取请求时，接收与所述菜谱标识对应的菜谱包信息，所述菜谱包信息中包含独立的多个不同份量菜谱；

基于从所述菜谱包信息中选择的目标份量菜谱，发送和/或执行目标份量菜谱解析后的制作指令。

可选的，所述菜谱包信息中的各份量菜谱具有相同的菜谱标识、加工设备、食材和/或配料。

可选的，所述菜谱包信息中的多个不同份量菜谱分别对应的烹饪参数是相同或不同的。

可选的，对所述目标份量菜谱的解析结果中包含所述目标份量菜谱适用的就餐人数；

所述发送和/或执行目标份量菜谱解析后的制作指令，具体包括：

若所述就餐人数与输入的目标就餐人数匹配，则发送和/或执行目标份量菜谱解析后的制作指令；

若所述就餐人数与所述目标就餐人数不匹配，则输出异常提示信息。

可选的，若所述目标份量菜谱发生修改，则与所述目标份量菜谱处于同一菜谱包的其他份量菜谱不存在同步修改操作，所述方法还包括：

当发送新的菜谱获取请求时，判断新接收到的菜谱或菜谱包是否有相同菜谱标识的已接收菜谱包；

若有相同菜谱标识的已接收菜谱包，则将所述新接收到的菜谱或菜谱包中的菜谱加入到所述已接收菜谱包。

根据本申请的另一方面，提供了另一种菜谱信息的处理方法，可应用于服务端侧，该方法包括：

接收菜谱获取请求，所述获取请求中携带有菜谱标识；

判断当所述菜谱获取请求中包括相同菜谱标识的多个不同份量菜谱获取请求时，将多个不同份量的菜谱创建为菜谱包信息；

发送所述菜谱包信息给用户。

可选的，所述多个不同份量菜谱具有相同的加工设备、和/或食材、和/或配料、和/或烹饪步骤，所述方法还包括：

通过调整烹饪参数，分别创建相同菜谱标识对应的多个不同份量菜谱，其中不同份量菜谱中的烹饪参数为不同或相同的；

将创建得到的相同菜谱标识的多个不同份量菜谱进行发布，以便所述多个不同份量菜谱被整套获取、和/或所述多个不同份量菜谱中的一个或多个份量菜谱被选择获取。

可选的，所述方法还包括：

接收所述用户新的菜谱获取请求，判断新请求份量的菜谱是否具有相同菜谱标识的已创建菜谱包；

若存在相同菜谱标识的已创建菜谱包，则将新请求份量的菜谱加入所述相同菜谱标识的已创建菜谱包中并进行返回。

可选的，所述方法还包括：

当同时接收到多个菜谱获取请求时，将请求的多个菜谱中相同菜谱标识所对应的多个不同份量菜谱进行打包处理，分别创建各个菜谱包信息进行返回。

可选的，所述方法还包括：

收集对相同菜谱标识的多个不同份量菜谱的评价信息；

按照所述评价信息，对所述多个不同份量菜谱中相应份量菜谱进行更新调整。

可选的，若所述获取请求中还携带有目标就餐人数，则所述方法还包括：

查询与所述菜谱标识对应的、且与所述目标就餐人数对应的推荐份量菜谱并进行反馈，其中，不同的菜谱标识、就餐人数、推荐份量菜谱三者之间存在映射关系。

可选的，所述方法还包括：

接收目标份量菜谱的更改请求，所述更改请求中携带有目标菜谱标识；

查询与所述目标份量菜谱对应的更改页面并进行反馈，所述更改页面中包含所述目标份量菜谱对应的各个参数更改项；

接收对所述目标份量菜谱的更新请求，所述更新请求携带有所述参数更改项中最新配置的参数信息；

按照所述参数信息对所述目标份量菜谱进行更新。

可选的，在所述发送所述菜谱包给用户之后，所述方法还包括：

接收菜谱更换请求，所述菜谱更换请求中携带有与需要更换的菜谱同名的、且份量不同的目标菜谱标识；

将所述目标菜谱标识对应的菜谱作为更换菜谱进行返回。

可选的，同一菜谱包信息中多个不同份量菜谱的使用权限不同。

根据本申请的又一方面，提供了一种菜谱信息的处理装置，可应用于客户端侧，该装置包括：

发送模块，用于发送菜谱获取请求，所述获取请求中携带有菜谱标识；

接收模块，用于接收与所述菜谱标识对应的菜谱包信息，所述菜谱包信息中包含独立的多个不同份量菜谱；

发送模块，用于基于从所述菜谱包信息中选择的目标份量菜谱，发送和/或执行目标份量菜谱解析后的制作指令。

根据本申请的再一方面，提供了另一种菜谱信息的处理装置，可应用于服务端侧，该装置包括：

接收模块，用于接收菜谱获取请求，所述获取请求中携带有菜谱标识；

创建模块，用于判断当所述菜谱获取请求中包括相同菜谱标识的多个不同份量菜谱获取请求时，将多个不同份量的菜谱创建为菜谱包信息；

发送模块，用于发送所述菜谱包信息给用户。

依据本申请再一个方面，提供了一种存储介质，其上存储有计算机程序，所述程序被处理器执行时实现上述可应用于客户端侧的菜谱信息的处理方法。

依据本申请再一个方面，提供了一种客户端设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述可应用于客户端侧的菜谱信息的处理方法。

依据本申请再一个方面，提供了一种存储介质，其上存储有计算机程序，所述程序被处理器执行时实现上述可应用于服务端侧的菜谱信息的处理方法。

依据本申请再一个方面，提供了一种服务器设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述可应用于服务端侧的菜谱信息的处理方法。

依据本申请再一个方面，提供了一种菜谱信息的处理系统，包括上述客户端设备和服务器设备。

借由上述技术方案，本申请提供的一种菜谱信息的处理方法、装置及系统，与目前传统的一体式菜谱创建方式相比，本申请预先独立制作不同份量菜谱，这些不同份量菜谱之间相互独立，互不干扰，无时间、空间上的联系，在客户端请求菜谱时可返回包含多个不同份量菜谱的菜谱包信息，以便供用户从中进行选择对应的目标份量菜谱。通过这种包式菜谱方式，对某份量菜谱进行调整，不会影响其他份量菜谱，方便菜谱管理。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1示出了本申请实施例提供的一种菜谱信息的处理方法的流程示意图；

图2示出了本申请实施例提供的一种包式菜谱实例示意图；

图3示出了本申请实施例提供的另一种菜谱信息的处理方法的流程示意图；

图4示出了本申请实施例提供的又一种菜谱信息的处理方法的流程示意图；

图5示出了本申请实施例提供的再一种菜谱信息的处理方法的流程示意图；

图6示出了本申请实施例提供的一种菜谱信息的处理装置的结构示意图；

图7示出了本申请实施例提供的另一种菜谱信息的处理装置的结构示意图；

图8示出了本申请实施例提供的又一种菜谱信息的处理装置的结构示意图；

图9示出了本申请实施例提供的再一种菜谱信息的处理装置的结构示意图；

图10示出了本申请实施例提供的一种菜谱信息的处理系统结构示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本申请。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

针对目前传统一体式菜谱创建方式会造成菜谱管理困难的技术问题。本实施例提供了一种菜谱信息的处理方法，可应用于客户端侧，如图1所示，该方法包括：

101、客户端发送菜谱获取请求。

其中，菜谱获取请求中携带有菜谱标识。菜谱标识可以为菜谱名称或id号等。

对于本实施例的执行主体可为用户客户端，如获取菜谱的应用(application，app)、浏览器或电子装置、设备等，具体可以配置在用户手机、平板电脑、或智能烹饪设备等端侧。用户可通过客户端选择需要获取的菜谱，然后客户端识别用户选择的菜谱标识，发送相应的菜谱获取请求。

102、当菜谱获取请求中包括相同菜谱标识的多个不同份量菜谱获取请求时，接收与菜谱标识对应的菜谱包信息。其中，菜谱包信息中包含独立的多个不同份量菜谱。在本实施例中，这些不同份量菜谱预先相互独立制作、独立测试，无时间、空间上的联系，制作单个菜谱的工作量和复杂度是基本恒定的。当不同份量菜谱制作出来后，创建一个相同菜谱标识的电子菜谱包，该相同的菜谱标识可以是菜谱名称相同，或者具有相同的菜谱编码等，例如当菜谱标识是菜谱名称时，把同名不同份量的电子菜谱加入到该菜谱包中即可。这样厨师无需提前规划要创建支持多少个不同份量的菜谱，而是根据用户需求制作后再组合为菜谱包。需要说明的是，本实施例主要以相同的菜谱名称作为示例，但并不局限于菜谱名称。

客户端在接收到菜谱包信息之后可进行输出展示，例如，如图2所示，用户可查看菜谱包中包含的多个不同份量菜谱，然后从中选择需要烹饪的目标份量菜谱。

103、基于从菜谱包信息中选择的目标份量菜谱，发送和/或执行目标份量菜谱解析后的制作指令。

若客户端配置在用户手机、平板电脑等操作端侧，则可发送对目标份量菜谱解析后的制作指令给智能烹饪设备，用于指示智能烹饪设备按照菜谱解析后的内容进行相应菜品烹饪制作；若客户端配置在智能烹饪设备侧，则可直接执行对目标份量菜谱解析后的制作指令。

对于本实施例提供的方法，与目前传统的一体式菜谱创建方式相比，本实施例预先独立制作不同份量菜谱，这些不同份量菜谱之间相互独立，互不干扰，无时间、空间上的联系，在客户端请求菜谱时可返回包含多个不同份量菜谱的菜谱包信息，以便供用户从中进行选择对应的目标份量菜谱进行烹饪。通过这种包式菜谱方式，对某份量菜谱进行调整，不会影响其他份量菜谱，方便菜谱管理。

进一步的，作为上述实施例具体实施方式的细化和扩展，为了完整说明本实施例的具体实施过程，本实施例提供了另一种可应用于客户端侧的菜谱信息的处理方法，如图3所示，该方法包括：

201、客户端发送菜谱获取请求。

在具体的应用场景中，还可预先展示相同菜谱标识的各个份量菜谱，用户从中选择需要获取的一个或多个不同份量菜谱，然后客户端发送相应的菜谱获取请求。

202、当菜谱获取请求中包括相同菜谱标识的多个不同份量菜谱获取请求时，接收与请求中携带的菜谱标识对应的菜谱包信息。

在请求处理端侧，如果客户端请求的是相同菜谱标识的一个或多个不同份量菜谱，那么可将请求的这些份量菜谱创建为菜谱包并返回。其中，一个或多个不同份量菜谱是根据用户需求来定的，比如用户a需要1人份和2人份的菜谱，用户b需要2人和4人份的菜谱，则分别将二人需求的菜谱创建成两个菜谱包，a菜谱包包括1人份和2人份的菜谱，b菜谱包包括2人和4人份的菜谱，基于此，不同用户的需求不同，获取得到菜谱包不同；如果客户端请求中没有指定需求份量的菜谱，那么会将该菜谱标识对应默认创建的菜谱包返回给客户端，以便用户从中选择合适份量的菜谱。

可选的，菜谱包信息中的各份量菜谱具有相同的菜谱标识、加工设备、食材和/或配料。菜谱包中包含相同菜谱标识的各份量菜谱，这些菜谱所需的加工设备、食材、配料等可以相同，也可以不同。

例如，对于不同份量的菜品a，由于食材份量越多其越不易煮熟，因此可选用较大功率的加工设备进行烹饪，因此不同份量的菜品a其对应的加工设备有可能是不同，而选用的食材、配料可以是相同的。除此之外，在选用不同加工设备烹饪的同时，还可以结合选用更易煮熟的食材替代原来的食材，或是结合选用其他可帮助煮熟的配料等。

再例如，对于不同份量的菜品b，由于相同食材份量越多其食材成本越高，为此可选用其他食材来代替，如对于1人份和2人份等的菜品b可选用童子鸡，而对于5人份和6人份等的菜品b可选用成年鸡，这样可节省一定的食材成本，而对于相应的加工设备、配料依然可以相同。除此之外，在选用不同食材加工的同时，其相应的配料也可以有所不同，进而保证虽然是食材实质相同而材料不同的菜品，但是用户品尝时味道没有差异性。

再例如，对于不同份量的菜品c，由于食材份量越多其在烹饪时更难入味，如果选用相同配料，不但需要放很多，并且有时也很难入味，因此可选用其他替代配料，这些替代配料可以更好的入味，且与原配料的味道相同。而对于相应的加工设备、食材可以相同。

由于相同菜品的份量不同，其对应的制作步骤、制作时间、口味配置、使用设备等或有所不同，因此可选的，菜谱包信息中的多个不同份量菜谱分别对应的烹饪参数有可能是相同的，或者有可能是不同的。

例如，加工设备有普通家用炒菜机和商用炒菜机，当菜谱份量较大时，可以匹配商用炒菜机，因此，其加热功率时间等都有可能不同。又或者不同的用户有不同的口味信息，例如用户a喜欢吃辣，制作仅适于他的单人份量菜时，配料中的辣椒可以多加，但是当制作满足全家人份量的菜肴时，由于可能有不吃辣的小朋友，因此，配料辣椒可能会取消，而造成烹饪参数不同。

对于本实施例的菜谱包事先可进行脱敏(或加密)处理，即将菜谱包中的菜谱细节内容大部分采用混淆脱敏、掩盖脱敏等方式，用户可通过购买权限获取未脱敏的菜谱细节内容，具体可以包月、包年等授予使用权限，或者按使用次数授予使用权限等。在获取得到菜谱包之后，其他具有相同使用权限的用户还可以直接复制获取。

进一步的，菜谱包中各份量菜谱的使用次数也可根据实际需求预先配置，还可根据用户使用习惯或购买记录分别授予不同份量菜谱不同次数的使用权限等。例如，对于餐厅用户，根据其购买记录将菜谱包中某些热卖份量的菜谱配置更高的可使用次数，而相应降低其他份量菜谱对应的可使用次数；对于家庭用户，根据其家庭用户的成员数量，将菜谱包中适合该成员数量同时就餐的一些份量菜谱配置更高的可使用次数；同样的，对于社区厨房用户，将菜谱包中适合该社区就餐人数同时就餐的一些份量菜谱配置更高的可使用次数。

如果需要限制菜谱包每日使用次数(即各份量菜谱每日可使用次数相加之和)，在此条件下为了帮助用户更合理的使用，且尽量减少对用户业务运营的影响，再进一步的，本实施例还可以根据每日当天的天气情况、是否节假日、周边就餐人群信息的变化等因素，配置菜谱包中各份量菜谱在每日的可使用次数。例如，对于餐厅用户来说，如果当天天气是暴雨、且非节假日、周边就餐人群数量在本周内不是很集中，那么一起就餐的人数通常不是很多，可相应降低较多人份的菜谱的可使用次数；如果当天天气晴好，为节假日，周边就餐人群数量相对集中，那么可提高2-3人份、4-6人份的菜谱可使用次数；如果当前天气是晴好，非节假日，周边就餐人群主要是学生，但是正值寒暑假期间，那么可整体减少各份量菜谱的可使用次数，然后在上学期间整体再调高。

203、输出接收到的菜谱包信息。

在本实施例中，不同份量的菜谱单独制作，之间是独立的个体单元，相互不影响，是一个松散的、低耦合的组合，可以从菜谱包里删除或增加一个某份量的菜谱。而对包里具体某个菜谱的操作，可通过菜谱包这个外壳进行管理。在使用上，用户执行该包式菜谱时，可以在操作界面上选择相应的份量，然后设备就执行相应份量的菜谱。

在灵活性方面，标准份和其他多份量的烹饪步骤可以相同，也可以不同，现实中，由于菜谱份量的不同，其步骤也有可能需要进行调整，比如多份量的菜谱为了受热均匀在烹饪过程中需要适当加水，或者为了使菜品入味，相比标准菜谱需要更早加入调料。同名不同份量菜谱在组合成电子菜谱之前并没有包的概念，彼此相互独立，单独发布和执行，无彼此联系，对其中一个份量修改与其他份量无任何关系。

在具体的应用场景中，用户在获取得到菜谱包后，可能不清楚选择适合就餐人数对应份量的菜谱，造成菜谱包展示时不具有一定的指导性。为此可选的，用户在获取菜谱时，可同时输入就餐人数，相应的，客户端发送的菜谱获取请求中还可携带有目标就餐人数。然后接收与目标就餐人数对应的、且与菜谱标识对应的推荐份量；最后输出接收到的推荐份量，以便被选择作为所述目标份量。其中，在请求处理端侧，预先统计不同的菜谱标识、就餐人数、推荐份量三者之间存在映射关系，即针对某菜品，预先统计不同的就餐人数分别适合就餐的份量，然后在客户端请求时给出相应的指导建议，方便用户进行选择。

204、对从菜谱包信息中选择的目标份量菜谱进行解析。

目前传统的一体式菜谱创建方式得到的一体式菜谱，由于其菜谱格式不统一，每个菜谱由于支持的多份量数目不一样，导致不同菜谱间格式各不一致，虽然它们都遵从约定的规范和语法，但可读性比较差。而对于本实施例中的包式菜谱，每一种份量的子菜谱都是一个独立完整的菜谱，使用标准格式即可解析；菜谱是最小单位，包不支持导出，可以选择包里的某个份量子菜谱进行菜谱导出操作，其导出的格式遵循标准格式。

可选的，为了方便用户选择合适份量的菜谱，预先配置各份量菜谱分别适用的就餐人数，因此在对目标份量菜谱的解析结果中可包含目标份量菜谱适用的就餐人数。接下来为了减少用户的选择错误，可通过执行步骤205a至205b所示的过程。

205a、若目标份量菜谱适合的就餐人数与用户输入的目标就餐人数匹配，则发送和/或执行目标份量菜谱解析后的制作指令。

与步骤205a并列的步骤205b、若目标份量菜谱适合的就餐人数与用户输入的目标就餐人数不匹配，则输出异常提示信息。

后续如果用户根据异常提示仍然确定执行时，可发送和/或执行目标份量菜谱解析后的制作指令。

进一步可选的，后续当发送新的菜谱获取请求时，判断新接收到的菜谱或菜谱包是否有同名的已接收菜谱包；若有同名的已接收菜谱包，则将新接收到的菜谱或菜谱包中的菜谱加入到该已接收菜谱包。这样方便进行数据统一化管理，提高后续管理效率。

在具体的应用场景中，后续用户还可主动更改某份量菜谱，相应可选的，本实施例方法还可包括：发送目标份量菜谱的更改请求；然后接收目标份量菜谱的更改页面，其中，更改页面中包含目标份量菜谱对应的各个参数更改项；然后获取参数更改项中最新配置的参数信息，并发送对目标份量菜谱的更新请求。通过这种方式满足了用户在线更改某份量菜谱的需求，并且可在云端保存该用户个性化的菜谱包方案，方便用户后续再获取菜谱时，可直接获取其更新后的菜谱包，减少用户后续的菜谱调整操作。

需要说明的是，由于相同菜谱标识的不同份量菜谱之间相互独立，因此若目标份量菜谱发生修改，则与目标份量菜谱同名的其他份量菜谱不存在同步修改操作。这样对菜谱同名的其他份量菜谱不存在影响，不会存在如现有技术当中存在的一损俱损的问题。

本实施例提供的方法，与目前传统的一体式菜谱创建方式相比，采用包式菜谱方式，对其中包含的某份量菜谱进行调整，不会影响其他份量菜谱，方便菜谱管理。

需要说明的是，上述可应用于客户端侧的菜谱信息的处理方法，是在客户端侧描述具体的菜谱信息的处理过程，而为了完整说明本实施例的具体实施方式，提供了一种可应用于服务端侧的菜谱信息的处理方法，以便说明在请求处理端侧的菜谱信息处理过程，如图4所示，该方法包括：

301、服务端接收菜谱获取请求。

其中，菜谱获取请求中携带有菜谱标识。

302、判断当菜谱获取请求中包括相同菜谱标识的多个不同份量菜谱获取请求时，将多个不同份量的菜谱创建为菜谱包信息。

其中，这些不同份量菜谱预先分别独立创建得到。

例如，当菜谱获取请求中除了携带菜谱标识以外，还携带该菜谱标识对应的多个不同份量标识，用于请求相同菜谱标识的多个不同份量菜谱时，可按照该菜谱标识查询对应的各个份量菜谱，然后再从中获取与这些份量标识对应的份量菜谱，最后根据获取到的多个不同份量菜谱创建得到菜谱包。

303、发送创建得到的菜谱包信息给用户。

本实施例提供的方法，与目前现有技术相比，本实施例预先独立制作不同份量菜谱，这些不同份量菜谱之间相互独立，互不干扰，无时间、空间上的联系，在用户请求相同菜谱标识的不同份量菜谱时，可返回包含这些不同份量菜谱的菜谱包信息，以便供用户从中进行选择对应的目标份量菜谱。通过这种包式菜谱方式，对某份量菜谱进行调整，不会影响其他份量菜谱，方便菜谱管理。

进一步的，作为上述实施例具体实施方式的细化和扩展，为了完整说明本实施例的具体实施过程，本实施例提供了另一种可应用于服务端侧的菜谱信息的处理方法，如图5所示，该方法包括：

401、通过调整烹饪参数，分别创建相同菜谱标识对应的多个不同份量菜谱。

可选的，这些不同份量菜谱中的烹饪参数可为不同或相同的。即烹饪参数有可能相同，或者有可能不同，具体根据实际需求而定。这些多个不同份量菜谱可具有相同的加工设备、和/或食材、和/或配料、和/或烹饪步骤。例如，标准份和其他多份量的烹饪步骤可以相同，也可以不同，现实中，由于菜谱份量的不同，其步骤也有可能需要进行调整，比如多份量的菜谱为了受热均匀在烹饪过程中需要适当加水，或者为了使菜品入味，相比标准份菜谱需要更早加入调料。

例如，同一菜品的其他份量菜谱都是基于其标准份菜谱调整得到，首先基于大数据分析手段，汇总不同厨师对于同一菜品的不同份量菜谱的调整方案，然后采用大多数原则，获取对该菜品某份量菜谱相对统一的调整方案，作为该份量菜谱的方案内容。依照这种方式，分别独立创建得到该菜品的不同份量菜谱。

除了上述创建菜谱方式以外，为了创建更加符合用户口味的菜谱，可选的，本实施例方法还可收集对相同菜谱标识的多个不同份量菜谱的评价信息；然后按照评价信息，对这些多个不同份量菜谱中相应份量菜谱进行更新调整。

402、将创建得到的相同菜谱标识的多个不同份量菜谱进行发布。

进一步的，以便于多个不同份量菜谱被整套获取、和/或多个不同份量菜谱中的一个或多个份量菜谱被选择获取。

目前一体式菜谱需要所包含的多个不同份量都创作完成才能发布；一旦发布，菜谱不能更改，如果对某一份量的参数进行调整则要放弃整个菜谱。并且用户只能获取包含多份量的整个菜谱，无法单独获取某份量菜谱。

而对于通过本实施例方法分别独立创建得到的相同菜谱标识的各份量菜谱，彼此相互独立，单独发布和执行，无彼此联系，对其中一个份量修改与其他份量无任何关系。这些不同份量菜谱可以单独发布，也可以以菜谱包形式整套发布；用户可以自由选购再组合，比如用户选择了糖醋菠萝骨的例牌和大份菜谱，例牌是三口之家日常使用，大份是家庭聚餐用，该2个电子菜谱在用户域里自动生成菜谱包；创作者可以自由组合电子菜谱包进行发布，比如将例牌、中份、大份组合为家庭版菜谱包，将4份量、8份量、10份量组合为商业版菜谱包等。

403、服务端接收菜谱获取请求。

404、判断当菜谱获取请求中包括相同菜谱标识的多个不同份量菜谱获取请求时，将多个不同份量的菜谱创建为菜谱包信息。

405、发送创建得到的菜谱包信息给用户。

进一步的，当服务端同时接收到多个菜谱获取请求时，将请求的多个菜谱中相同菜谱标识所对应的多个不同份量菜谱进行打包处理，分别创建各个菜谱包信息进行返回。通过这种方式，可提高菜谱获取效率，彼此之间相互不影响，便于用户规范化管理各个菜谱标识对应的不同份量菜谱。

在具体的应用场景中，用户在选择菜谱时，可能不清楚选择适合就餐人数对应份量的菜谱，因此为了给用户指导性推荐建议，可选的，可预先针对某菜品，统计不同的就餐人数分别适合就餐的份量，然后再接收到菜谱获取请求、且请求中携带有目标就餐人数时给出相应的指导建议，方便用户进行选择。相应的具体实现为：若服务端接收到的菜谱获取请求中还携带有目标就餐人数，则查询与菜谱标识对应的、且与该目标就餐人数对应的推荐份量菜谱并进行反馈，其中，不同的菜谱标识、就餐人数、推荐份量菜谱三者之间存在映射关系。

除此之外，还可以在创建不同份量菜谱时，标记其对应的适合就餐人数，以方便用户进行选择使用。

进一步的，为了满足用户对菜谱的更改需求，可选的，本实施例方法还可包括：接收目标份量菜谱的更改请求，其中更改请求中携带有目标菜谱标识；然后查询与目标份量菜谱标识对应的更改页面并进行反馈，该更改页面中包含目标份量菜谱对应的各个参数更改项；后续可接收对目标份量菜谱的更新请求，该更新请求携带有参数更改项中最新配置的参数信息；按照接收到的参数信息对目标份量菜谱进行更新。

406、服务端接收菜谱更换请求。

其中，菜谱更换请求中携带有与需要更换的菜谱同名的、且份量不同的目标菜谱标识。

407、将目标菜谱标识对应的菜谱作为更换菜谱进行返回。

例如，用户当初获取的是某菜品菜谱包中包含2人份和4人份的菜谱，如果用户需要将4人份的菜谱更换为该菜品6人份的菜谱，可将该该菜品6人份的菜谱作为之前4人份菜谱的更换菜谱进行返回。以此来满足用户的菜谱更换需求。

进一步的，本实施例方法还可包括：服务端接收用户新的菜谱获取请求，判断新请求份量的菜谱是否有同名的已创建菜谱包；若存在同名的已创建菜谱包，则将新请求份量的菜谱加入该同名的已创建菜谱包中并进行返回。通过这种方式来满足不同的业务需求。

例如，用户a当初获取的菜谱包中包含某菜品的2人份和3人份菜谱，后续用户a又需要获取该菜品的4人份菜谱，服务端可判断之前是否有同名的已创建菜谱包，具体可通过用户a的菜谱包获取记录中查询，如果查询到同名的已创建菜谱包(即之前的包含2人份和3人份菜谱的菜谱包)，并且用户a当前仍然具备该已创建菜谱包中的各份量菜谱的使用权限，那么可将该菜品的4人份菜谱加入到这个已创建菜谱包中，并返回给用户a；除此之外，如果确定用户a当前只具备该菜品2人份菜谱的使用权限，3人份菜谱的使用权限已经过期，那么可将该菜品的4人份菜谱加入到这个已创建菜谱包中，并剔除3人份菜谱然后返回给用户a。通过这种方式可便于用户a查看该菜品已获取的且具备使用权限的各份量菜谱，方便用户a进行菜谱管理。

本实施例提供的方法，提出了一种电子菜谱包或套装方案，它由拥有相同的菜谱名称、加工设备、食材、配料的不同份量电子菜谱组合而成，不同份量的菜谱单独制作，之间是独立的个体单元，相互不影响，是一个松散的、低耦合的组合。因此与现有的一体式菜谱相比，管理起来更加方便，方便用户使用。

进一步的，作为图1和图3所示方法的具体实现，本申请实施例提供了一种可应用于客户端侧的菜谱信息的处理装置，如图6所示，该装置包括：发送模块51、接收模块52。

发送模块51，可用于发送菜谱获取请求，所述获取请求中携带有菜谱标识；

接收模块52，可用于接收与所述菜谱标识对应的菜谱包信息，所述菜谱包信息中包含独立的多个不同份量菜谱；

发送模块51，还可用于基于从所述菜谱包信息中选择的目标份量菜谱，发送和/或执行目标份量菜谱解析后的制作指令。

在具体的应用场景中，可选的，所述菜谱包信息中的各份量菜谱具有相同的菜谱标识、加工设备、食材和/或配料。

在具体的应用场景中，可选的，所述菜谱包信息中的多个不同份量菜谱分别对应的烹饪参数是相同或不同的。

在具体的应用场景中，可选的，对所述目标份量菜谱的解析结果中包含所述目标份量菜谱适用的就餐人数；

所述发送模块51，具体可用于若所述就餐人数与输入的目标就餐人数匹配，则发送和/或执行目标份量菜谱解析后的制作指令；若所述就餐人数与所述目标就餐人数不匹配，则输出异常提示信息。

在具体的应用场景中，可选的，所述获取请求中还携带有目标就餐人数；

如图7所示，本装置还包括：输出模块53；

所述接收模块52，还可用于接收与所述目标就餐人数对应的、且与所述菜谱标识对应的推荐份量，其中，不同的菜谱标识、就餐人数、推荐份量三者之间存在映射关系；

所述输出模块53，可用于输出接收到的所述推荐份量，以便被选择作为所述目标份量。

在具体的应用场景中，如图7所示，本装置还可包括：判断模块54、添加模块55；

判断模块54，可用于当发送新的菜谱请求时，判断新接收到的菜谱或菜谱包是否有同名的已接收菜谱包；

添加模块55，可用于若通过所述判断模块判定新接收到的菜谱或菜谱包有同名的已接收菜谱包，则将所述新接收到的菜谱或菜谱包中的菜谱加入到所述已接收菜谱包。

在具体的应用场景中，所述发送模块51，还可用于发送目标份量菜谱的更改请求；

所述接收模块52，还可用于接收所述目标份量菜谱的更改页面，所述更改页面中包含所述目标份量菜谱对应的各个参数更改项；

所述发送模块51，还可用于获取所述参数更改项中最新配置的参数信息，发送对所述目标份量菜谱的更新请求。

在具体的应用场景中，可选的，若所述目标份量菜谱发生修改，则与所述目标份量菜谱同名的其他份量菜谱不存在同步修改操作。

需要说明的是，本实施例提供的一种可应用于客户端侧的菜谱信息的处理装置所涉及各功能单元的其它相应描述，可以参考图1和图3中方法的对应描述，在此不再赘述。

进一步的，作为图4和图5所示方法的具体实现，本申请实施例提供了一种可应用于服务端侧的菜谱信息的处理装置，如图8所示，该装置包括：接收模块61、创建模块62、发送模块63。

接收模块61，可用于接收菜谱获取请求，所述获取请求中携带有菜谱标识；

创建模块62，可用于判断当所述菜谱获取请求中包括相同菜谱标识的多个不同份量菜谱获取请求时，将多个不同份量的菜谱创建为菜谱包信息；

发送模块63，可用于发送所述菜谱包信息给用户。

在具体的应用场景中，可选的，所述多个不同份量菜谱具有相同的加工设备、和/或食材、和/或配料、和/或烹饪步骤。

在具体的应用场景中，所述创建模块62，具体可用于通过调整烹饪参数，分别创建相同菜谱标识对应的多个不同份量菜谱，其中不同份量菜谱中的烹饪参数为不同或相同的。

在具体的应用场景中，如图9所示，本装置还包括：发布模块64；

发布模块64，可用于将创建得到的相同菜谱标识的多个不同份量菜谱进行发布。

进一步的，以便于所述多个不同份量菜谱被整套获取、和/或所述多个不同份量菜谱中的一个或多个份量菜谱被选择获取。

在具体的应用场景中，所述创建模块62，还可用于当同时接收到多个菜谱获取请求时，将请求的多个菜谱中相同菜谱标识所对应的多个不同份量菜谱进行打包处理，分别创建各个菜谱包信息；

所述发送模块63，还可用于返回所述创建模块创建得到的各个菜谱包信息。

在具体的应用场景中，如图9所示，本装置还包括：收集模块65、调整模块66；

收集模块65，可用于收集对相同菜谱标识的多个不同份量菜谱的评价信息；

调整模块66，可用于按照所述评价信息，对所述多个不同份量菜谱中相应份量菜谱进行更新调整。

在具体的应用场景中，所述发送模块63，还用于若所述获取请求中还携带有目标就餐人数，则查询与所述菜谱标识对应的、且与所述目标就餐人数对应的推荐份量菜谱并进行反馈，其中，不同的菜谱标识、就餐人数、推荐份量菜谱三者之间存在映射关系。

在具体的应用场景中，如图9所示，本装置还包括：更新模块67；

所述接收模块61，还可用于接收目标份量菜谱的更改请求，所述更改请求中携带有目标菜谱标识；

所述发送模块63，还可用于查询与所述目标份量菜谱对应的更改页面并进行反馈，所述更改页面中包含所述目标份量菜谱对应的各个参数更改项；

所述接收模块61，还可用于接收对所述目标份量菜谱的更新请求，所述更新请求携带有所述参数更改项中最新配置的参数信息；

所述更新模块67，可用于按照所述参数信息对所述目标份量菜谱进行更新。

在具体的应用场景中，所述接收模块61，还可用于接收菜谱更换请求，所述菜谱更换请求中携带有与需要更换的菜谱同名的、且份量不同的目标菜谱标识；

所述发送模块63，还可用于将所述目标菜谱标识对应的菜谱作为更换菜谱进行返回。

在具体的应用场景中，所述接收模块61，还可用于接收所述用户新的菜谱获取请求，判断新请求份量的菜谱是否有同名的已创建菜谱包；

发送模块63，还可用于若存在同名的已创建菜谱包，则将新请求份量的菜谱加入所述同名的已创建菜谱包中并进行返回。

需要说明的是，本实施例提供的一种可应用于服务端侧的菜谱信息的处理装置所涉及各功能单元的其它相应描述，可以参考图4和图5中方法的对应描述，在此不再赘述。

基于上述如图1和图3所示方法和如图6和图7所示的虚拟装置，相应的，本申请实施例还提供了一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述如图1和图3所示的方法。基于上述如图4和图5所示方法和如图8和图9所示的虚拟装置，本申请实施例还提供了另一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述如图4和图5所示的方法。

基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景的方法。

基于上述如图1和图3所示的方法，和如图6和图7所示的虚拟装置实施例，为了实现上述目的，本申请实施例还提供了一种客户端设备，具体可以为个人计算机、平板电脑、智能手机、智能手表、智能手环、智能烹饪设备或其他网络设备等，该设备包括存储介质和处理器；存储介质，用于存储计算机程序；处理器，用于执行计算机程序以实现上述如图1和图3所示的方法。

基于上述如图4和图5所示的方法，以及图8和图9所示的虚拟装置实施例，为了实现上述目的，本申请实施例还提供了一种服务器设备，具体可以为个人计算机、服务器、网络设备等，该服务器设备包括存储介质和处理器；存储介质，用于存储计算机程序；处理器，用于执行计算机程序以实现上述如图8至图9所示的方法。

可选的，上述两种实体设备都还可以包括用户接口、网络接口、摄像头、射频(radiofrequency，rf)电路，传感器、音频电路、wi-fi模块等等。用户接口可以包括显示屏(display)、输入单元比如键盘(keyboard)等，可选用户接口还可以包括usb接口、读卡器接口等。网络接口可选的可以包括标准的有线接口、无线接口(如wi-fi接口)等。

本领域技术人员可以理解，本实施例提供的一种客户端设备和服务器设备的实体设备结构并不构成对这两种实体设备的限定，可以包括更多或更少的部件，或者组合某些部件，或者不同的部件布置。

存储介质中还可以包括操作系统、网络通信模块。操作系统是管理上述两个实体设备硬件和软件资源的程序，支持信息处理程序以及其它软件和/或程序的运行。网络通信模块用于实现存储介质内部各组件之间的通信，以及与信息处理实体设备中其它硬件和软件之间通信。

基于上述内容，进一步的，本申请实施例还提供了一种菜谱信息的处理系统，如图10所示，该系统包括客户端设备71、服务器设备72；

其中，客户端设备71可用于执行如图1和图3所示的方法，服务器设备72可用于执行如图4和图5所示的方法。

具体的，客户端设备71，可用于向服务器设备72发送菜谱获取请求，所述获取请求中携带有菜谱标识。

服务器设备72，可用于接收客户端设备71发送的菜谱获取请求。判断当所述菜谱获取请求中包括相同菜谱标识的多个不同份量菜谱获取请求时，将多个不同份量的菜谱创建为菜谱包信息；然后发送所述菜谱包信息给客户端设备71。其中，菜谱包信息中包含独立的多个不同份量菜谱。

客户端设备71，还可用于接收服务器设备72发送的与所述菜谱标识对应的菜谱包信息。然后基于从所述菜谱包信息中选择的目标份量菜谱，发送和/或执行目标份量菜谱解析后的制作指令。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以借助软件加必要的通用硬件平台的方式来实现，也可以通过硬件实现。本申请提出了一种电子菜谱包或套装方案，它由拥有相同的菜谱名称、加工设备、食材、配料的不同份量电子菜谱组合而成，不同份量的菜谱单独制作，之间是独立的个体单元，相互不影响，是一个松散的、低耦合的组合。因此与现有的一体式菜谱相比，管理起来更加方便，方便用户使用。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。