# Cook From Zero

> 从零教会一道菜或一种烹饪手法。讲清每一步背后的通用原理，让人能把这次学到的东西迁移到别的菜上，而不只是照抄一份菜谱。凡是用户问"怎么做某道菜""某种食材怎么处理""某个烹饪手法（煎/炖/腌/焯水/收汁/解冻/熟成）是怎么回事""为什么我做出来是这样"，或者带着具体食材和厨具来问该怎么料理，都应该使用这个 Skill——即使他们只是随口问了句菜谱。不适用于烘焙类（见「何时不用」）。

- Skill: `xqs-xqs/cook-from-zero` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add xqs-xqs/cook-from-zero`
- Raw SKILL.md: https://api.skillmd.com/api/skills/xqs-xqs/cook-from-zero/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: xqs-xqs (https://skillmd.com/u/xqs-xqs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/xqs-xqs/cook-from-zero

---


# 🍳 从零学做菜 (Cook From Zero)

把一次做菜，变成一次可迁移的能力积累。

**核心信念：用户读完之后必须马上能动手。** 讲得再对，如果让人不敢开火，就是失败的输出。

---

## 何时不用

- 用户只要一份配料表或一个数字（"红烧肉放多少糖"）→ 直接答，别套模板
- **烘焙、精确发酵类**：这类是"前期精确配比 + 中途不可干预"，本 Skill 的骨架建立在"感官反馈 + 中途调节"上，会失效。可以借用其中的原理部分，但不要套完整结构，并主动说明差异

---

## 三条铁律

### 1. 行动优先于完备

宁可让用户先做出一版 80 分的，也不要让他读完 3000 字后决定"明天再说"。

- **L1（最小可行版）硬上限 5 条**。超过 5 条说明你在把提升项塞进必做项
- 主流程写完后插一行**阅读分界线**：`—— 读到这里就够了，去做。下面的等你做过一次再回来看 ——`
- 分界线以上必须完整可执行。以下全是可选

### 2. 感官信号 > 时间参数

时间参数编码的是别人的锅、别人的灶、别人的食材规格，直接抄必然出错。

**每个关键判断点都要给一个不依赖设备的可观察信号，时间只作参考值并标注。**

- ❌ 煎 90 秒后翻面
- ✅ 轻推能滑动就翻面（约 90 秒，视锅温）

### 3. 指令与原理物理分离

- **步骤行**：只写做什么。祈使句，一句话，可执行
- **原理**：用 `>` 引用块挂在步骤下方，**语法上可整段跳过**，每条 ≤2 句

**自检（硬性）：把所有 `>` 引用块整段删掉，剩下的步骤能不能独立做出这道菜？** 不能就说明关键信息藏在解释里了，必须提回步骤行。

---

## 开始前：先确认约束

**不问清约束，输出的就是通用菜谱，不是给这个人的方法。**

四项，用户没说就用默认值并标注出来：

| 项 | 为什么重要 |
|---|---|
| **锅具** | 决定整个方法。只有平底锅就别教爆炒；只有铸铁就别教长时间煮水 |
| **热源** | 燃气 / 电磁 / 空气炸锅 / 烤箱，火力上限差别巨大 |
| **已有调料** | 缺一样就给替代方案，不是让人去买 |
| **时间预算** | 30 分钟和一整天是两套方案 |

用两三句话确认，**不要做成问卷**。约束已经出现在对话里时直接用，别再问一遍。

---

## 输出结构

七节。括号内是字数预算，**超了就是写坏了**。

```
1. 核心矛盾            (1 句)
2. L1 关键变量         (≤5 条)
3. 主流程              (步骤 ≤600 字，原理批注另计)
   ——— 阅读分界线 ———
4. L2 提升项           (≤400 字)
5. 翻车诊断表          (≤8 行)
6. 扩展与边界          (≤300 字)
7. 带走的东西          (表格)
```

**分界线以上目标 ≤1200 字。全文 ≤3000 字。**

---

### 1. 核心矛盾（1 句）

一句话说清这道菜/这个手法**难在哪里**。给读者一个挂钩，后面所有内容都往上挂。

> 例：鸡胸的核心矛盾——安全温度 74°C，但过了 65°C 就开始柴，窗口只有几度。
> 例：煎牛排的核心矛盾——焦壳要表面高温，粉红中心要内部低温，两者靠厚度和时间互相竞争。

放开头。不要放结尾——读者读完 3000 字之后，总结救不了前面的混乱。

### 2. L1 关键变量（≤5 条）

**决定"能不能吃"的少数变量**，不是"最容易做的几件事"。排序标准是**对结果方差的贡献**，和难易无关。

常见错误：把"买个温度计"当成进阶项。它是前置条件——没有它连"完成"都判断不了。

**必须写明这一版能达到什么水平**，让读者知道在哪停：

> L1 目标：熟度正确、有焦壳、不柴。达不到就别看 L2。

### 3. 主流程

从冰箱/食材原始状态写到装盘。该有的环节一个不落（解冻、回温、预处理、腌制、备料、下锅、火候、调味、收汁、静置、切法），**但不该有的环节一个不加**。

- 步骤行：祈使句，一句话
- 原理：`>` 挂在下方，≤2 句，且只写**能推导出操作**的原理

**原理的准入判据（替换测试）：**

> 能不能在一道完全不同的菜里，靠这条原理推出正确操作？
> 能 → 写。不能 → 它只是操作说明，别套原理的壳。

**坑就地绑定，不集中成节。** 没人能带着 15 条警告进厨房。

- **不可逆的坑**（糊了、过熟、酵素腌过头）→ 前置到步骤上方警告
- **可逆的坑**（咸了、汁不稠、上色不足）→ 丢进第 5 节诊断表

坑必须给可观察信号：❌"别把锅烧过头" / ✅"油冒黑烟就是过头了，倒掉重来"

### 4. L2 提升项

做过一次之后再看的东西。每条标注成本：**免费 / 花钱 / 花时间**，让读者自己排优先级。

### 5. 翻车诊断表

固定四栏，≤8 行：

| 症状 | 真正原因 | 当场补救 | 下次预防 |
|---|---|---|---|

**再给一个归因方法**，比查表更值钱。例：中式炒菜的失败 90% 能归到**火候 / 时间 / 水分**三个变量之一，翻车后按序自问即可。

### 6. 扩展与边界

只允许三个方向，各 1–2 句：

- **横向迁移**：同一原理换食材
- **纵向进阶**：同一道菜的高阶变体
- **边界条件**：**这条原理什么时候不成立** ← 最重要，最常被跳过

第三项必写。知道原理的失效边界才算真懂。

### 7. 带走的东西

不写"总结"（重复一遍不产生新信息）。写**能带进厨房的东西**：

**a) 极简 checklist** —— 一屏内，纯动作，无解释

**b) 空白参数表** —— 复用真正发生的地方：

| 日期 | 食材/规格 | 火力档 | 各阶段时长 | 关键读数 | 结果 | 下次调整 |
|---|---|---|---|---|---|---|

告诉用户：**记三次，你就有了匹配自己厨房的参数，比任何菜谱都准。**

---

## 语言与语气

- 用词专业但不端着，直给结论，不铺垫
- 避免"值得注意的是""不难看出"这类填充
- 有取舍就明说取舍和代价，不要两边都夸
- 用户方案有问题就直接指出问题和原因，不用鼓励性客套
- 表格 > 段落。能用表说清的别写成散文

---

## 交付前自检

五条，全过才输出：

1. **删除测试**：删光所有 `>` 原理块，步骤还能独立执行吗？
2. **分界线测试**：分界线以上是完整可做的吗？≤1200 字吗？
3. **信号测试**：每个关键判断点都有可观察信号吗，还是只有秒数？
4. **约束测试**：换一个约束（"没有烤箱"），方案会**实质改变**吗？还是只多一句提醒？
5. **L1 测试**：L1 是不是刚好 ≤5 条，且都是硬变量、不是好做的事？

---

## 版本

v0.1 — 首版。测试方法见同目录 [`EVAL.md`](./EVAL.md)。