Anduin2017
使用规范定义的标记语言（例如YAML）来定义每一个菜谱
其实我觉得不需要设计新语言（这太难了），而可以在现有语言上开发一个库。例如用JavaScript描述做菜流程，每个原料都是对象，锅可以处理原料。
其实我觉得不需要设计新语言（这太难了），而可以在现有语言上开发一个库。例如用JavaScript描述做菜流程，每个
原料都是对象，锅可以处理原料。
最好是以配置的形式来做，比如 Dockerfile 这种。 如果是编程语言的库，那灵活性太大了，反而不可预知后果。
用code来表示recipe,然后code可以直接转换成人类可读的菜谱，或机器可读的自动炒菜程序。
我目前能看到的好处是：
- 菜谱编写者可以更容易标准化菜谱。
- 自动补全和高亮能帮助菜谱编写者加快效率。
前几天我在思考，如果有一种语言用来表示中餐食谱，它需要哪些基本语法。
然后我意识到，使用json、xml、yaml这类标记语言，很可能导致语法过度繁琐（他们都是设计用于处理很general的问题的）。这可能会打击贡献菜谱的厨师的积极性。这种语法最好写起来非常方便。
然后我考虑过python、js之类的现有脚本语言，语言的现有语法、灵活性似乎也会对编写者造成困扰。
我写了一个类似这样的sample，但最后想了想又感觉，相比于直接写markdown来说没有太大的优势。（毕竟现在没有家用做饭机器人）
我倾向于学习 Dockerfile 的做法。
From 引入别的菜谱 Material 定义原料 Kitchenware 定义炊具
Put 将原料放入炊具
Chopping 砧板工序（砧板） Steam 蒸炖工序（上什） Fry 烹炒工序（炉头） Paoding 屠宰分解（水台） Seasoning 料头预加工、装饰（打荷） Brine 烧蜡卤味工序（烧腊） Dimsum 点心面食工序（点心） 以上工序参考自这里
Export 将某炊具内容物导出为一个产物，产物可以被其他菜谱引用。也可以直接吃。如豆瓣酱、回锅肉都可以是产物。
抛砖引玉，有别的想法也说说。
是否可以将具体的做菜流程拆分成多个不同的步骤（Step），每个 Step 由一个或多个子 Step 或不可拆分的原子步骤（AtomStep）组成，通过定义触发器（Tigger）之类的组件应该可以描述整个流程。同时可以最大程度的保证每个步骤的清晰性，如 #55 的流程可以表示为：
Step1:
Input: 番茄
Handle:
Step1:
Input: 番茄
Output: $11
Handle: 开水烫番茄表皮
Step2:
Input: $11
Output: $12
Handle: $1 放入冷水
Step3:
Input: $12
Output: $13
Handle: 去掉 $12 外皮
Output: $13
Step2:
Input: $13
Output: $2
Handle: $13 切块
Step3:
Input: 鸡蛋，盐
Output: $3
Handle:
Step1:
Input: 鸡蛋
Output: $31
Handle: 鸡蛋打入碗中
Step2:
Input: $31
Output: $32
Handle: 加入 人数 * 1g 盐
Step3:
Input: $32
Output: $33
Handle: 搅拌均匀
Step4:
Input: 油 油数量为 鸡蛋数量 * 4 ml
Output: $4
Handle: 起锅烧油
Step5：
Input: $4
Trigger: $4 冒烟
Output: $5
Handle:
- 往 $4 中加入 $3
- 等待 10s 或两面金黄
// ……
单纯整活
已经有人做过了, 而且连APP都有了
https://cooklang.org/
Cooklang and the tools we’ve built to use it, you can:
simplify your personal recipe management; streamline your shopping routine; make cooking more fun. Here’s how the Cooklang ecosystem makes that happen:
All recipes are human-readable text files. Everything is a file. No databases. And you have complete control over your information. All the tools are simple, focused, and efficient; the UNIX way.
Cooklang 没有本地化啊，我们需要中文编程。
菜谱怎么会跟自然语言强绑定呢?
>> 中文测试: 张三☺️
@西红柿{2个}洗净。去蒂，切成边长不超过 4cm 的小块
将@鸡蛋{2~3个}打入碗中，加入@盐{2%g}，搅匀
热锅，加@油{8%ml}
（可选）加入@饮用水{300%ml}，并加热 30 秒（这可以避免最终盛盘后可能的汤汁不足）
https://www.dangermouse.net/esoteric/chef.html 这个语言的烹饪技法倒是规范化了，但是种类有点少，而且只有英语。 （其实这个语言根本不是 Recipe as Code 而是 Code as Recipe）
分享一个做菜，你们也太卷了吧
这叫互联网思维啊 我觉得菜谱语言需要支持数量计算，不然得凭经验，对新手不友好 经验部分也能数字化
要不使用扩展 markdown 语法描述好了，还能转成思维导图
感觉食材的处理方式都可以被枚举吧……当成一个class来处理的可能性也是不小的 猪肉 pork1 = new 猪肉( 100g, 五花肉); pork1.切条(手指粗细); 锅 wok1 = new 锅(炒锅); wok1.add(油, 1茶勺); wok1.heat(100摄氏度); wok1.add(pork);
做菜的过程可以抽象成一个整体串行，局部并行的流水线模型。食材和各种配料作为上下文 Context 在这个 Pipeline 中过一遍，最终产物即为烹饪好的菜品。从这个角度看 Github Actions 好像已经给了一个很好的模型了。
Cooklang 功能太弱了，只有食材提取的能力。 更关键的烹饪技法没有规范化。
其实我觉得Cooklang只能够作为定义中的食材提取的部分；而这个烹饪技法--如同大家所说--可以用github action或者gitlab-ci等方式来完成。
而烹饪技法的流水线，又可以进一步提高人类协作的效率，可能这是目前的唯一价值；不然厨师们为啥要用一个不熟悉的语言来定义菜谱呢？
当然最终目标还是输入菜谱之后，锅里面就能够标准化的生产出对应的菜，不过那个时候估计人工智能已经很发达了，还要喂养人类干嘛，当电池吗:)
也是整活儿。。。
用顺序、条件、循环而不是静态配置表示做菜过程更自然。为了让菜谱更标准、可复制，可以把炊具、食材、操作者先做抽象，暴露出一系列API。比如微波炉实现 heater 接口，西红柿实现 cutable 和 isPeeled 接口，操作者可以是人或机器，实现类似 cutter 接口。基于这些抽象就可以写出标准的执行程序，具体使用哪种编程语言不关键。为了让菜谱更好理解，可以利用低代码方式比如可视化编程
感觉可以做一个通用的食谱编辑器，食谱提供者用 UI 界面录入食谱后程序自动转存为一个通用的格式（假定是数据库里），然后根据数据库里的数据可以自动生成各种格式的菜谱（ Markdown , YAML 等 ）。这样第三方的就程序可以自己读取转换后的产物或源数据。
我有个新的想法，写一个脚本， 把食谱生成一个视频来，供大家边做边看，官网可以在菜谱旁边加一个链接，就是视频，当然最主要的是 语音表达好步骤，就行不用边做边看菜谱了。
是否可以将具体的做菜流程拆分成多个不同的步骤（Step），每个 Step 由一个或多个子 Step 或不可拆分的原子步骤（AtomStep）组成，通过定义触发器（Tigger）之类的组件应该可以描述整个流程。同时可以最大程度的保证每个步骤的清晰性，如 #55 的流程可以表示为：
Step1: Input: 番茄 Handle: Step1: Input: 番茄 Output: $11 Handle: 开水烫番茄表皮 Step2: Input: $11 Output: $12 Handle: $1 放入冷水 Step3: Input: $12 Output: $13 Handle: 去掉 $12 外皮 Output: $13 Step2: Input: $13 Output: $2 Handle: $13 切块 Step3: Input: 鸡蛋，盐 Output: $3 Handle: Step1: Input: 鸡蛋 Output: $31 Handle: 鸡蛋打入碗中 Step2: Input: $31 Output: $32 Handle: 加入 人数 * 1g 盐 Step3: Input: $32 Output: $33 Handle: 搅拌均匀 Step4: Input: 油 油数量为 鸡蛋数量 * 4 ml Output: $4 Handle: 起锅烧油 Step5： Input: $4 Trigger: $4 冒烟 Output: $5 Handle: - 往 $4 中加入 $3 - 等待 10s 或两面金黄 // ……单纯整活
支持这个做法，把每一道菜所涉及的每一个步骤、工序、节点都进行量化，加上时间轴的纬度，有利于今后机器学习和炒菜机器人的实施。然后动态生成markdown文件，有利于人类的阅读。
