chore: 导入清理前的完整工程状态（含 Capacitor 原生壳，作为回滚备份点）

2026-10-21 11:50:10 +08:00
commit 8ded87a3a8
389 changed files with 52242 additions and 0 deletions
@@ -0,0 +1,119 @@
+---
+name: recipe-data-review
+description: 定期审查和优化 Cook 的菜谱数据与筛选：汇总应用内反馈和筛选信号、处理菜谱 issue 和失效视频、补全缺失字段、按评测优化别名和排序，最后开一个 PR 交给维护者审核。维护者说"跑一下数据审查""处理菜谱反馈""优化菜谱数据/筛选"，或定时任务调用时使用。
+metadata:
+  author: YunYouJun
+  repository: https://github.com/YunYouJun/cook
+---
+
+# 菜谱数据审查
+
+你在维护 Cook（食用手册）的菜谱数据和筛选逻辑。每次运行产出**一个** PR，由维护者审核合并。你从不直接推送到 main，也从不合并 PR。
+
+数据规则以 `docs/dev/data.md` 为准，开始前先读一遍。
+
+## 硬性规则
+
+- 数据只改 `packages/data/recipe.csv`。需要新食材或厨具时，不要改 `packages/data/food.json`，写进 PR 描述的「需要维护者决定」部分。
+- 列为 `name,stuff,bv,difficulty,tags,methods,tools,id`；单元格内多个值用顿号「、」分隔。
+- **id 不能修改、不能复用。** 收藏、反馈、筛选信号都按 id 记录。新菜谱追加到末尾，id 用当前最大 id + 1。
+- 不删除菜谱。重复或失效的菜写进「需要维护者决定」，由维护者决定是否删除（删除会让收藏它的用户丢失这一条）。
+- 食材、厨具只能用 `packages/data/food.json` 里的名称。难度只能是 简单 / 普通 / 困难，或留空。
+- **不编造视频号。** 替换视频时，必须用 `https://api.bilibili.com/x/web-interface/view?bvid=<BV号>` 确认 `code` 为 0，并且标题和菜名对得上；做不到就保留原值，写进 PR 描述。
+- 筛选逻辑只允许改 `packages/data/aliases.json`（别名）和 `packages/cook/src/utils/recommend.ts`（排序），且必须有评测数据支撑（见第 6 步）。
+- 拿不准的改动不做，写进 PR 描述。宁可少改，不要错改。
+
+## 步骤
+
+1. **准备分支**
+
+   ```bash
+   git fetch origin main && git checkout -B data/review-$(date +%F) origin/main
+   pnpm install --frozen-lockfile
+   ```
+
+2. **收集输入**
+
+   ```bash
+   pnpm feedback:pull   # 应用内反馈和筛选信号；没配置 .env 就跳过这一步
+   pnpm validate --json > /tmp/recipe-validate.json
+   gh issue list --label recipe-data --state open --json number,title,body
+   gh issue list --label dead-video --state open --json number,body
+   ```
+
+   读 `.cook/feedback/summary.md`。如果 `pnpm validate` 有错误，先修错误。
+
+3. **处理应用内反馈**（summary 里的「菜谱反馈」，按分数从高到低）
+   - 视频打不开：先用上面的接口确认确实失效，再按规则找替代视频。
+   - 食材或厨具不对、难度或做法不对：对照视频信息核实后再改。
+   - 只有 1 个人反馈且无法核实的，不改，列在 PR 描述里。
+
+4. **处理 issue**
+   - `recipe-data`：新增菜谱（视频可访问、食材能用词典描述、不和已有菜重复）或按 issue 纠错。信息不足就跳过，在 PR 描述里列出 issue 号和缺什么，不要在 issue 里发评论。
+   - `dead-video`：能找到同一道菜的可用视频就替换 `bv`，找不到就列在 PR 描述里。
+
+5. **补全缺失字段**，每次最多 20 行，挑最有把握的：
+   - `methods`：菜名里明确写了做法才填（如「炸胡萝卜块」→ 炸）。
+   - `difficulty`：只有看过视频信息（时长、步骤）能判断时才填，否则留空。
+   - 食材明显漏了主料（菜名里有、`stuff` 里没有，且词典里有）时补上。
+
+6. **优化筛选**（`test/fixtures/search-eval.json` 不为空时才做）
+
+   ```bash
+   pnpm eval:search --json > /tmp/eval-before.json
+   ```
+   - 「没有结果的食材组合」里，用户输入的词是已有食材的别名（如「羊排」之于「羊肉」）→ 在 `packages/data/aliases.json` 加别名。词典里根本没有的食材 → 写进「需要维护者决定」。
+   - 被频繁点开却排在 10 名以后的菜 → 可以调整 `recommend.ts` 的排序，但改动要小、要能解释。
+   - 改完再跑一次，对比前后：
+
+   ```bash
+   pnpm eval:search --json > /tmp/eval-after.json
+   ```
+
+   命中率（hitAt10）或 MRR 下降、或 `pnpm test` 失败，就撤销这次筛选改动。
+
+7. **验证**
+
+   ```bash
+   pnpm validate --base origin/main
+   pnpm fixtures
+   pnpm test -- --run
+   ```
+
+   `test/recommendations.test.ts` 里的数量断言会随数据变化。只有当变化是你的修改直接造成的，才更新这些数字，并在 PR 描述中说明。其他测试失败就停下，不要提交。`pnpm fixtures` 会重新生成 Web 和 iOS 共用的推荐用例 `packages/data/fixtures/recommend.json`，一起提交。
+
+8. **提交并开 PR**
+   ```bash
+   git add packages/data/recipe.csv packages/data/fixtures/recommend.json test/fixtures/search-eval.json test/recommendations.test.ts packages/data/aliases.json packages/cook/src/utils/recommend.ts
+   git commit -m "chore(data): recipe review $(date +%F)"
+   git push -u origin HEAD
+   gh pr create --title "chore(data): recipe review $(date +%F)" --body-file /tmp/recipe-review-pr.md
+   ```
+   没有任何改动就不开 PR，直接结束。
+
+## PR 描述模板
+
+```markdown
+## 本次改动
+
+| id  | 菜名 | 改动 | 依据（反馈 / issue / 视频信息） |
+| --- | ---- | ---- | ------------------------------- |
+
+## 筛选
+
+- 别名 / 排序改动：……
+- 评测：hitAt10 A → B，MRR A → B，仍无结果 A → B
+
+## 需要维护者决定
+
+- （新食材 / 新厨具、要删除的重复或失效菜谱、拿不准的改动、找不到替代视频的菜）
+
+## 统计
+
+- 校验：错误 0，警告 N
+- 缺难度 X% → Y%，缺做法 X% → Y%
+
+Closes #...
+```
+
+只在确实解决了的 issue 上写 `Closes`。