怪兽厨房 MonsterChef

MonsterChef 是一个把怪兽点单做菜包装成可玩前端项目，同时把 SDD、Harness 和 AI 质量门 直接纳入研发流程与展示叙事中的实验型作品。

1. 项目总览

MonsterChef 的目标不是只做一个“能点能玩”的小网页，而是尽量把创意玩法、前端工程组织、质量验证证据三条线同时做实。项目以怪兽厨房为表层主题，以规格驱动、场景回放、自动化质量关卡为底层方法，适合用于课程展示、社区分享、作品集陈述和研发方法实践。

1.1 项目概要表

项目项	内容
项目名称	MonsterChef / 怪兽厨房
项目类型	创意型前端单页 Web 应用
当前阶段	可运行、可测试、可回放、可生成质量摘要的原型版
研发方法	SDD + Harness + AI Quality Gate
质量管控	CI/CD 自动化质量检查 + AI 智能质量门 + 证据链
主要目标	让玩法表达、研发方法和质量验证形成闭环
适用场景	课堂展示、社区分享、作品集项目、工程流程实践

1.2 项目核心判断

维度	目标	当前状态
产品表达	玩家能快速理解怪兽点单与做菜循环	已形成主循环
工程结构	核心规则与 UI 解耦	已完成基础拆分
验证能力	关键路径可重复验证	已具备 Harness 回放
质量闭环	发布前有统一检查入口	已具备质量命令
团队协作	能按角色推进不同产物	已形成分工方向

2. 快速入门与架构说明

本章节帮助新贡献者和用户快速了解项目架构、模块职责和开发流程。

2.1 快速开始（5分钟上手）

2.1.1 环境要求

依赖项	版本要求	用途
Node.js	≥ 16.0.0	运行开发服务器和执行脚本
npm	≥ 7.0.0	包管理器
现代浏览器	Chrome/Firefox/Edge/Safari	运行前端应用

2.1.2 快速启动步骤

# 1. 克隆仓库
git clone https://gitlink.org.cn/goodfamily/MonsterChef.git
cd MonsterChef

# 2. 安装依赖（可选，本项目无外部依赖）
npm install

# 3. 启动开发服务器
npm start

# 4. 打开浏览器访问
# http://127.0.0.1:4173

2.1.3 常用命令速查

命令	功能	使用场景
npm start	启动本地服务器	开发和体验游戏
npm test	运行单元测试	验证核心逻辑
npm run harness	场景回放	验证关键路径
npm run quality	完整质量检查	提交前验证
npm run quality:specs	SDD规格检查	验证文档完整性
npm run quality:gate	AI质量门	生成质量摘要

2.2 系统架构概览

2.2.1 整体架构图

┌─────────────────────────────────────────────────────────────────┐
│                         用户界面层 (UI Layer)                    │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐         │
│  │  当局厨房     │  │ 记录与徽章   │  │ 研发控制台   │         │
│  │  (Game View) │  │ (Records)    │  │ (Dev Console)│         │
│  └──────────────┘  └──────────────┘  └──────────────┘         │
│           │                  │                  │                │
│           └──────────────────┴──────────────────┘                │
│                              ↓                                   │
└─────────────────────────────────────────────────────────────────┘
                               ↓
┌─────────────────────────────────────────────────────────────────┐
│                       核心逻辑层 (Core Layer)                    │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐            │
│  │ gameState   │  │roundProcessor│  │  scoring    │            │
│  │ (状态管理)  │  │ (回合推进)   │  │ (得分计算)  │            │
│  └─────────────┘  └─────────────┘  └─────────────┘            │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐            │
│  │ matchRecipe │  │   badges    │  │achievement  │            │
│  │ (菜谱匹配)  │  │ (徽章系统)  │  │ (成就系统)  │            │
│  └─────────────┘  └─────────────┘  └─────────────┘            │
└─────────────────────────────────────────────────────────────────┘
                               ↓
┌─────────────────────────────────────────────────────────────────┐
│                       数据层 (Data Layer)                        │
│  monsters │ recipes │ ingredients │ events │ badges │ etc.     │
│  (怪兽)   │ (菜谱)  │ (食材)      │ (事件) │ (徽章) │          │
└─────────────────────────────────────────────────────────────────┘
                               ↓
┌─────────────────────────────────────────────────────────────────┐
│                    验证层 (Verification Layer)                   │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐            │
│  │   Tests     │  │   Harness   │  │Quality Gate │            │
│  │ (单元测试)  │  │ (场景回放)  │  │ (AI质量门)  │            │
│  └─────────────┘  └─────────────┘  └─────────────┘            │
└─────────────────────────────────────────────────────────────────┘

2.2.2 架构分层说明

层级	职责	关键文件	设计原则
UI层	用户交互、页面渲染、状态展示	src/ui/main.js, src/ui/styles.css	只消费核心逻辑结果，不包含业务规则
核心层	游戏规则、状态管理、数据处理	src/core/*.js	纯函数化，与UI解耦，可独立测试
数据层	游戏内容配置	src/data/*.js	数据驱动，易于扩展
验证层	质量保证、回归测试	tests/, harness/, scripts/quality/	自动化、可重复、证据化

2.3 模块职责详解

2.3.1 核心模块 (src/core/)

模块文件	职责描述	主要功能	依赖关系
gameState.js	游戏状态管理	初始化状态、回合推进、状态快照	依赖 data 层
roundProcessor.js	回合处理器	处理每回合的怪兽订单、事件触发	依赖 gameState, matchRecipe
scoring.js	得分计算系统	基础分、事件加成、连击奖励计算	依赖 data/events
matchRecipe.js	菜谱匹配引擎	食材组合→菜谱匹配算法	依赖 data/recipes
badges.js	徽章系统	徽章解锁条件判断与奖励	依赖 gameState
achievementSystem.js	成就系统	长期目标追踪与达成判定	依赖 gameState
comboSystem.js	连击系统	连续高分奖励机制	依赖 scoring

2.3.2 数据模块 (src/data/)

数据文件	内容说明	数据规模	扩展方式
monsters.js	怪兽角色数据	6个怪兽，各有偏好/避雷/口头禅	添加新怪兽对象
recipes.js	菜谱数据	10个菜谱，定义食材组合	添加新菜谱对象
ingredients.js	食材数据	食材列表及标签	添加新食材
events.js	厨房事件数据	4个事件，影响得分	添加新事件
badges.js	徽章数据	徽章定义与解锁条件	添加新徽章
achievements.js	成就数据	成就定义与达成条件	添加新成就

2.3.3 UI模块 (src/ui/)

模块文件	职责	主要功能
main.js	主界面逻辑	三栏切换、交互处理、渲染更新、结算弹层
styles.css	样式系统	视觉呈现、响应式布局、动画效果

2.3.4 验证模块

模块	职责	执行方式
tests/*.test.js	单元测试	npm test
harness/scenarios/*.json	场景剧本	npm run harness
scripts/quality/*.mjs	质量脚本	npm run quality

2.4 执行流程说明

2.4.1 游戏主循环流程

用户打开页面
    ↓
初始化 gameState (gameState.js)
    ↓
生成回合数据（怪兽、订单、事件）
    ↓
用户选择食材组合
    ↓
菜谱匹配 (matchRecipe.js)
    ↓
计算得分 (scoring.js)
    ↓
检查徽章/成就 (badges.js, achievementSystem.js)
    ↓
更新状态并展示结算
    ↓
推进到下一回合 (roundProcessor.js)
    ↓
循环直到回合结束

2.4.2 质量检查流程

代码提交
    ↓
SDD 规格检查 (check-sdd.mjs)
    ↓ 失败则阻断
单元测试 (tests/*.test.js)
    ↓ 失败则阻断
场景回放 (harness-runner.mjs)
    ↓ 失败则阻断
AI 质量门 (ai-quality-gate.mjs)
    ↓
生成质量报告 (quality-report.md)
    ↓
通过/阻断合并

2.5 开发环境配置

2.5.1 推荐开发工具

工具类型	推荐工具	用途
代码编辑器	VS Code	JavaScript/HTML/CSS 开发
Node.js 版本管理	nvm 或 nvm-windows	切换 Node.js 版本
Git 客户端	Git Bash / Git GUI	版本控制
浏览器开发者工具	Chrome DevTools	调试前端

2.5.2 VS Code 推荐扩展

- ESLint (代码规范)
- Prettier (代码格式化)
- JavaScript (ES6) code snippets
- Live Server (可选，替代 npm start)

2.5.3 环境变量配置

项目根目录的 .env 文件（可选）：

# 开发服务器端口（默认 4173）
PORT=4173

# AI 质量门 API 密钥（用于 AI 功能）
AI_API_KEY=your_api_key_here

2.6 常见用例示例

2.6.1 用例1：添加新怪兽

场景：想要添加一个新的怪兽角色

步骤：

1. 打开 src/data/monsters.js
2. 在数组中添加新怪兽对象：

{
  id: 'new_monster',
  name: '新怪兽',
  avatar: '🦊',  // 表情符号
  preferences: ['食材1', '食材2'],  // 喜欢的食材
  dislikes: ['食材3'],  // 不喜欢的食材
  catchphrase: '口头禅',  // 口头禅
  difficulty: 'medium'  // 难度等级
}

3. 运行测试验证：npm test
4. 启动游戏查看效果：npm start

2.6.2 用例2：添加新菜谱

场景：想要添加一个新的菜谱

步骤：

1. 打开 src/data/recipes.js
2. 添加新菜谱对象：

{
  id: 'new_recipe',
  name: '新菜谱',
  ingredients: ['食材A', '食材B', '食材C'],
  baseScore: 100,  // 基础分
  tags: ['标签1', '标签2'],  // 用于事件加成
  difficulty: 'hard'
}

3. 运行质量检查：npm run quality
4. 提交代码

2.6.3 用例3：添加新测试场景

场景：想要添加一个新的 Harness 测试场景

步骤：

1. 在 harness/scenarios/ 创建新的 JSON 文件
2. 编写场景剧本：

{
  "name": "新场景名称",
  "description": "场景描述",
  "rounds": [
    {
      "monsterId": "monster_1",
      "order": { "recipeId": "recipe_1" },
      "event": null,
      "playerChoice": ["ingredient_1", "ingredient_2"],
      "expectedScore": 80
    }
  ]
}

3. 运行场景回放：npm run harness
4. 检查报告：harness/reports/latest-report.json

2.6.4 用例4：调试核心逻辑

场景：想要调试得分计算逻辑

步骤：

1. 打开 src/core/scoring.js
2. 在浏览器开发者工具 Console 中：

// 导入得分计算函数（在开发服务器运行时）
import { calculateScore } from './src/core/scoring.js';

// 测试用例
const result = calculateScore({
  matchedRecipe: { baseScore: 100 },
  event: { multiplier: 1.5 },
  combo: 2
});
console.log(result);  // 预期输出：300

2.6.5 用例5：运行完整质量检查

场景：提交代码前执行完整质量检查

步骤：

# 执行完整质量流程（串联所有检查）
npm run quality

# 或者分步执行
npm run quality:specs  # 1. SDD 规格检查
npm test               # 2. 单元测试
npm run harness        # 3. 场景回放
npm run quality:gate   # 4. AI 质量门

# 查看质量报告
cat harness/reports/quality-report.md

2.7 新贡献者指南

2.7.1 贡献流程

1. Fork 仓库
    ↓
2. 克隆到本地并创建特性分支
    ↓
3. 进行开发（参考常见用例）
    ↓
4. 运行质量检查 (npm run quality)
    ↓
5. 提交代码（遵循 commit 规范）
    ↓
6. 创建 Pull Request
    ↓
7. 等待 CI 检查和代码评审

2.7.2 代码提交规范

提交类型	说明	示例
feat	新功能	feat: 添加新怪兽"火焰龙"
fix	Bug修复	fix: 修复菜谱匹配错误
docs	文档更新	docs: 更新快速入门指南
refactor	重构	refactor: 优化得分计算逻辑
test	测试更新	test: 添加菜谱匹配边界测试
chore	其他	chore: 更新依赖版本

2.7.3 项目目录导航

想要修改…请查看…| 文件/目录 | | :— | :— | | 游戏规则和逻辑 | src/core/ | | 游戏数据（怪兽、菜谱等） | src/data/ | | 用户界面 | src/ui/ | | 测试用例 | tests/ | | 场景剧本 | harness/scenarios/ | | 质量脚本 | scripts/quality/ | | 规格文档 | specs/ | | CI配置 | .github/workflows/ |

3. 项目定位与目标

MonsterChef 的定位不是纯游戏，也不是传统后台管理页，而是一个“可体验的前端项目样本”。它既要让用户看到怪兽厨房的趣味，也要让团队和外部观察者看到这个项目如何通过规格、回放和质量门被组织起来。

3.1 目标拆解表

目标层	目标内容	说明
产品目标	做出有辨识度的怪兽厨房体验	主题明确、节奏清楚、反馈即时
工程目标	用规格与场景驱动开发	降低创意项目常见的逻辑漂移
质量目标	提供可读、可复核的质量证据	不只说“没问题”，而是拿出报告
展示目标	能讲清研发过程与方法论	适合作品说明和社区传播

3.2 这个项目要解决的问题

问题	常见情况	MonsterChef 的处理方式
创意项目容易边做边改	最后规格与实现脱节	先写 product-sdd 与 engineering-sdd
体验验证过度依赖手点	改动后回归成本高	用 Harness 剧本固定关键路径
项目完成度难证明	只能靠截图和口头说明	用测试、回放、报告串成质量证据
团队协作职责模糊	产出混在一起难复盘	明确开发、质量、社区三条职责线

4. 当前版本范围

4.1 已完成能力表

模块	已完成内容
页面结构	当局厨房、记录与徽章、研发控制台 三栏切换
玩法数据	怪兽、菜谱、食材、厨房事件、徽章数据已落地
核心逻辑	菜谱匹配、得分计算、回合推进、声望累计、徽章解锁
结算反馈	每局上菜后展示表现拆解与奖励结果
场景回放	基于 JSON 剧本回放关键体验路径
质量命令	支持规格检查、测试、Harness、质量摘要生成

4.2 当前版本数据规模

项	数量	说明
默认总回合数	10	由状态模型控制
怪兽角色	6	各自带偏好、避雷项、口头禅
菜谱	10	由食材组合匹配
厨房事件	4	会影响得分加成
Harness 剧本	2	当前已沉淀两条关键路径
逻辑测试	9	在研发控制台与质量门中作为核心指标使用

4.3 当前版本边界

当前已覆盖	当前未覆盖
单页体验主循环	多人协作或联机
核心规则引擎	后端持久化存档
回放与报告生成	复杂账号体系
研发方法展示	正式部署流水线平台化界面

5. 游戏玩法与体验结构

5.1 单局流程

步骤	系统行为	玩家行为	结果
1	生成怪兽、订单、厨房事件	阅读当前局面	建立预期
2	显示角色偏好与目标菜谱	判断要用的食材	准备上菜
3	提供食材选择网格	组合食材	形成提交方案
4	匹配菜谱并计算分数	提交结果	获得回合反馈
5	结算得分、评价、徽章	阅读结算层	理解表现原因
6	推进到下一回合	继续服务	完成整局

5.2 玩法设计重点

设计点	说明
怪兽角色化	怪兽有偏好、避免特征、喜爱食材和口头禅，而不是普通订单卡片
事件影响真实得分	厨房事件会给特定标签、特征、食材数量带来加成
反馈必须即时	每一局上菜后都要能解释为什么高分、低分或翻车
研发展示嵌入产品	研发控制台直接把方法论带进产品视图中

5.3 三大主视图说明

栏目	作用	核心内容
当局厨房	当前回合主战场	怪兽、订单、事件、食材、AI 小抄、上菜结算
记录与徽章	沉淀过程结果	回合记录、分数走势、徽章收集
研发控制台	方法与证据展示层	SDD、Harness、AI Gate 三条研发主线

6. SDD 驱动的开发方式

MonsterChef 尽量避免“先画页面，再慢慢补逻辑”的松散方式，而是优先建立规格，再让实现和验证跟上。

6.1 规格文档表

文档	作用	当前关注内容
specs/product-sdd.md	定义产品目标与体验结构	定位、用户场景、玩法主循环、信息架构、成功标准
specs/engineering-sdd.md	定义工程模型与约束	状态模型、规则引擎、回放机制、质量门串联

6.2 SDD 驱动链路

需求想法
   |
   v
产品 SDD --------------------+
   |                         |
   v                         v
工程 SDD                 验收标准
   |                         |
   +-----------+-------------+
               |
               v
         核心逻辑实现
               |
               v
            UI 消费

6.3 SDD 在项目里的实际作用

作用	表现方式
约束范围	先明确页面要承载哪些栏目、玩法和目标
约束规则	评分、状态、事件和回合推进先写进工程描述
约束协作	新增功能需要能说明对应哪条规格
约束验收	规格覆盖不足时，质量检查直接不通过

7. Harness 驱动的验证方式

Harness 是这个项目从“好像能玩”走向“可以稳定回放验证”的关键部分。

7.1 Harness 核心流程图

场景剧本 JSON
   |
   v
固定怪兽 / 固定订单 / 固定事件 / 固定选择
   |
   v
processRound 逐轮推进
   |
   v
结构化结果输出
   |
   v
latest-report.json

7.2 当前场景剧本表

场景文件	场景意图	代表验证内容
critic-recovery.json	挑嘴局面恢复	精准命中与特殊徽章结果是否正确
perfect-service.json	连续高分服务	多轮推进、连胜与组合徽章是否正确

7.3 Harness 的管理价值

价值点	说明
回归验证	改逻辑后可以快速看关键路径是否变化
叙事稳定	创意玩法不再只靠人工记忆核对
协作明确	新玩法上线前可以先补场景，再补页面
结果沉淀	回放结果可直接进入报告与质量门

8. AI 质量门与证据链

MonsterChef 当前不是只跑测试，而是把规格、逻辑、回放和摘要整合成一个统一入口。

8.1 质量命令表

命令	作用	输出
npm run quality:specs	检查规格章节覆盖	规格通过 / 失败
npm test	验证核心逻辑	测试结果
npm run harness	回放关键场景	latest-report.json
npm run quality:gate	生成质量摘要	quality-report.json、quality-report.md
npm run quality	串联完整质量流程	一次性发布前检查

8.2 质量关卡架构

specs/*.md
   |
   +------> check-sdd.mjs ------------------+
                                             |
tests/*.test.js ------> node --test ---------+----> quality gate
                                             |
harness/scenarios/*.json -> harness runner --+
                                             |
latest-report.json + SDD --------------------+
                                             |
                                             v
                           quality-report.json / quality-report.md

8.3 当前质量证据

指标	当前值
质量门状态	green
Harness 场景数	2
场景平均得分	159
产品规格章节数	5
工程规格章节数	4

8.4 质量门的意义

层面	作用
对开发	减少改动后悄悄破坏玩法的问题
对团队	让讨论基于报告而不是感觉
对展示	能证明项目有工程流程，不只是好看页面
对后续扩展	为新增怪兽、菜谱、事件提供统一验收入口

9. 质量管控的实践

MonsterChef 的质量管控不仅是代码测试，而是建立了一套完整的质量证据链和管控体系，融合 AI 能力实现智能化质量管控，并通过 CI/CD 自动化执行。

9.1 质量管控理念

理念	说明
预防优于发现	通过 SDD 规格先行，在开发前明确质量标准
证据可追溯	每次质量检查都生成报告，形成可回看的质量证据链
自动化执行	CI/CD 流水线自动执行质量管控，避免人为遗漏
AI 辅助决策	融合 AI 能力生成质量摘要和改进建议
持续改进	基于质量报告和社区反馈持续优化

9.2 质量管控体系架构

┌─────────────────────────────────────────────────────────────┐
│                    质量管控全流程                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  规格层面        SDD 规格检查                                │
│     ↓                                                       │
│  逻辑层面        单元测试验证                                │
│     ↓                                                       │
│  场景层面        Harness 场景回放                            │
│     ↓                                                       │
│  AI 层面         AI 质量门评估                              │
│     ↓                                                       │
│  报告层面        统一质量报告生成                            │
│     ↓                                                       │
│  CI 层面         CI/CD 自动化执行                           │
│                                                             │
└─────────────────────────────────────────────────────────────┘

9.3 CI/CD 融合 AI 的质量管控实践

8.3.1 CI 流水线质量关卡

关卡顺序	关卡名称	执行命令	验证内容
1	SDD 规格检查	npm run quality:specs	产品规格与工程规格的完整性
2	单元测试	npm test	核心业务逻辑的正确性
3	Harness 回放	npm run harness	关键体验路径的稳定性
4	AI 质量门	npm run quality:gate	AI 生成的质量摘要和改进建议

8.3.2 CI 自动触发条件

• 代码推送：推送到 main 或 master 分支自动触发
• Pull Request：创建 PR 时自动执行质量检查
• 手动触发：通过 workflow_dispatch 手动执行

8.3.3 质量报告产物

报告文件	内容	用途
latest-report.json	Harness 场景回放结果	关键路径验证证据
quality-report.json	AI 生成的结构化质量摘要	机器可读的质量评估
quality-report.md	AI 生成的可读质量报告	人类可读的质量说明

9.4 AI 融合的质量管控能力

AI 能力	说明
质量摘要生成	AI 分析测试、回放结果，生成结构化质量摘要
问题识别	AI 识别潜在的质量风险和改进点
建议生成	AI 基于质量数据生成改进建议
智能评审	AI PR 评审提供代码质量建议
失败诊断	CI 失败时 AI 自动分析原因并给出诊断报告

9.5 质量门禁标准

质量指标	阈值	说明
SDD 规格覆盖度	100%	产品规格和工程规格必须完整
单元测试通过率	100%	所有测试用例必须通过
Harness 场景通过率	100%	所有关键场景必须回放成功
AI 质量评分	通过	AI 综合评估通过

9.6 质量管控效果

效果维度	具体表现
质量可视化	每次提交都有明确的质量报告
回归可控	Harness 场景确保关键路径不退化
问题可追溯	CI 失败时有清晰的诊断和报告
改进有方向	AI 提供具体的改进建议
发布有信心	质量门通过后才允许合并

9.7 质量管控实践的价值

价值点	说明
对开发	减少改动后悄悄破坏功能的问题，快速定位质量风险
对团队	基于报告而非感觉讨论质量，减少争议
对项目	形成可追溯的质量证据链，证明项目工程化程度
对展示	能清楚展示质量管控方法论，提升项目可信度
对社区	提供稳定可靠的版本，减少用户遇到的问题

10. 技术与代码架构

10.1 技术栈表

技术	用途
Node.js	本地服务与脚本执行
ES Modules	模块化组织
JavaScript	规则实现与前端交互
HTML / CSS	页面结构与视觉呈现

10.2 目录结构

monsterchef/
├── src/
│   ├── ai/                  # AI 建议文案
│   ├── core/                # 状态、评分、规则、回合推进
│   ├── data/                # 怪兽、菜谱、事件、徽章等内容数据
│   └── ui/                  # 视图渲染与样式
├── tests/                   # 核心逻辑测试
├── harness/                 # 场景剧本与报告
├── scripts/quality/         # 规格检查与质量门
├── specs/                   # 产品 / 工程 SDD
├── docs/                    # 辅助说明
├── community/               # 社区运营与反馈文档
├── server.mjs               # 启动入口
└── REMEDE.md                # 项目详细说明

10.3 逻辑分层图

┌──────────────────────────────────────────────┐
│                  UI Layer                    │
│  src/ui/main.js + styles.css                 │
│  页面切换、状态展示、交互触发、结算弹层        │
└──────────────────────┬───────────────────────┘
                       │
┌──────────────────────▼───────────────────────┐
│                 Core Layer                   │
│  gameState / roundProcessor / scoring        │
│  matchRecipe / badges                        │
│  核心状态、匹配规则、得分和回合推进            │
└──────────────────────┬───────────────────────┘
                       │
┌──────────────────────▼───────────────────────┐
│                 Data Layer                   │
│  monsters / recipes / events / badges        │
│  内容配置与可扩展数据源                       │
└──────────────────────┬───────────────────────┘
                       │
┌──────────────────────▼───────────────────────┐
│            Verification Layer                │
│  tests / harness / quality scripts           │
│  逻辑校验、剧本回放、质量摘要                 │
└──────────────────────────────────────────────┘

10.4 模块职责表

模块层	核心职责	设计原则
src/core	处理状态与规则	尽量纯函数化，不依赖 UI
src/data	管理游戏内容	尽量数据驱动，便于扩展
src/ui	承接交互与渲染	只消费规则结果，不隐藏业务逻辑
tests	验证逻辑正确性	关注回归与边界条件
harness	验证体验路径	关注关键场景是否可重复
scripts/quality	汇总质量证据	形成发布前统一入口

11. 团队分工与推进角色

这个项目当前按照“开发与管理主线”“质量与 CI 主线”“社区与反馈主线”来分工，避免所有事情都落到同一种产出里。

11.1 团队分工表

成员	主负责方向	角色定位	主要产出
Xuaya	SDD / Harness 驱动的项目开发与管理	负责把项目往规格驱动、回放驱动的开发管理方式推进	规格梳理、开发组织、结构推进、核心落地进度
good123	融合 AI 能力的 CI 与质量管控	负责把 AI 能力与质量流程整合进项目交付链路	质量命令、质量摘要、发布前证据链
s111	社区运营与反馈闭环	负责真实用户侧的展示、互动、收集与整理	社区运营、试玩反馈、意见回流

11.2 Xuaya 负责重点

你的部分更靠近“尽力把项目往 Harness 或 SDD 驱动的开发与管理方式构建起来”，因此在文档中定位为以下几个重点：

方向	说明
规格驱动开发	优先明确产品规格与工程规格，再推进实现
Harness 驱动管理	尝试让关键体验路径先形成剧本，再进入回归链路
结构化推进	不只是写功能，还负责让模块、目录和流程变得可维护
开发节奏管理	让产品表现、工程实现、验证方式尽量同步推进

11.3 good123 负责重点

方向	说明
AI 质量摘要	让质量结果不止有机器输出，还能有结构化说明
CI 思路落地	把测试、回放、规格检查连接成可重复执行的流程
证据链组织	让项目发布前有清楚的检查顺序和可回看结果

11.4 s111 负责重点

方向	说明
两周社区运营	在社区进行持续展示和试玩触达
外部反馈收集	获取玩法、视觉、信息表达方面的真实反应
反馈闭环	将有效意见回流到规格、剧本或后续迭代方向

12. 协作流程与管理方式

12.1 协作流程图

想法 / 需求
   |
   v
Xuaya 梳理规格与推进开发结构
   |
   +--------------------+
   |                    |
   v                    v
核心功能实现         Harness 场景补齐
   |                    |
   +---------+----------+
             |
             v
good123 组织质量命令与 AI 摘要
             |
             v
形成版本结果与证据
             |
             v
s111 进入社区展示与反馈回收
             |
             v
意见回流到规格 / 场景 / 下一轮迭代

12.2 协作机制表

环节	主要负责人	目标
规格形成	Xuaya	先定义要做什么和怎么验证
逻辑实现	Xuaya	推动核心功能落地
质量流程	good123	让验证链路可重复执行
社区反馈	s111	获取外部视角并形成回流

13. 社区反馈与外部验证

仓库中的 community/launch-plan.md 和 community/feedback-loop.md 说明了项目不是闭门开发，而是希望通过短周期社区运营得到更真实的反馈。

13.1 社区反馈关注表

关注点	说明
玩法理解成本	玩家能否快速理解怪兽点单与做菜逻辑
栏目表达清晰度	三个主栏目是否各自职责明确
研发控制台信息量	方法展示是否清楚，是否压过主体验
视觉与节奏反馈	是否有记忆点，是否足够顺滑

13.2 反馈回流对象

反馈类型	优先回流位置
玩法理解问题	product-sdd、UI 文案、流程提示
规则歧义	engineering-sdd、核心逻辑、测试
关键路径问题	Harness 剧本
展示效果问题	页面样式、动效、信息编排

14. 运行与质量命令

14.1 本地启动

npm install
npm start

启动后访问：

http://127.0.0.1:4173

14.2 常用命令表

命令	用途
npm start	启动本地服务
npm test	运行核心逻辑测试
npm run harness	执行场景回放并生成报告
npm run quality:specs	检查规格章节覆盖
npm run quality:gate	生成 AI 质量摘要
npm run quality	执行完整质量流程

15. 后续迭代方向

15.1 下一阶段重点表

方向	说明
内容扩展	增加更多怪兽、菜谱、事件与徽章
验证扩展	增加更多 Harness 剧本，覆盖翻车、补救、极限得分等路径
报告增强	让质量报告更图形化、更适合展示
管理增强	继续把开发流程往 SDD / Harness 驱动方式收紧
社区闭环	持续吸收两周运营反馈并回写到规格与实现

16. 总结

MonsterChef 的价值不只在于题材有趣，而在于它尝试把一个创意型前端项目做成更有方法论支撑的案例：

• 产品线上，它要能玩、能看懂、能留下印象。
• 工程线上，它要让规则、结构和模块关系可维护。
• 管理线上，它要尽量向 SDD / Harness 驱动的开发与管理方式靠拢。
• 质量线上，它要让测试、回放和 AI 摘要形成证据链。

Test AI Review branch

Re-trigger AI review test

New PR test trigger

PR test #2

New AI review test

AI review test v4

Final test for AI review

One more test

Another test push

# Test iteration

## Keep testing

### Final test push

#### Additional test

##### Continuous test

###### Keep pushing

####### More testing

######## Extra test

######### Final push

########## One more

########### Push again

############ Continue

############# Another push

############## Keep going

############### Push again

################ One more

################# Push again

################## Another one

################### Push again

#################### One more