需求整理 / 访谈摘要

MediaPipe 手势与动作识别需求简报

这份页面整理了与詹娜老师讨论后的核心需求：当前项目希望用普通摄像头识别手势和身体动作来控制体感游戏，但基于 MediaPipe 的 AI 生成方案稳定性很低，常出现骨架不显示、基础动作识别不准、提示词反复调试的问题。

01 / Problem

当前问题

目前的问题不是简单的“MediaPipe 不能用”，而是用 AI 工具生成 MediaPipe 动作识别项目时，结果非常不稳定。同一个需求，有时能跑通，有时连关键点和骨架都无法显示。

“它不是完全做不到，而是准确率和稳定性像抽盲盒。”

整理自本次需求讨论
Symptom 01

骨架经常不显示

  • 页面里没有红点、绿线或人体骨架。
  • 摄像头画面可能存在，但 landmarks 没有正确绘制。
  • 多轮提示词后仍可能卡在基础可视化问题上。
Symptom 02

基础动作识别率低

  • 跳跃、跑步、挥砍、斜向动作等基础动作效果不稳。
  • 动作明明简单，但需要反复 debug。
  • 运行结果受生成代码质量影响很大。
Symptom 03

复杂动作难描述

  • 自然语言说“跑步”，AI 不一定知道该看哪些关键点。
  • 缺少角度、速度、节奏、时间窗口等动作定义。
  • 最后输出的判断逻辑容易含糊或误判。
02 / Need

真实需求

詹娜老师想解决的不是“找一个新模型替代 MediaPipe”，而是找到一套稳定产出 MediaPipe 体感识别方案的方法，让 AI 不再靠运气生成代码。

问题域 需要回答的问题 期望产出 优先级
现成案例 有没有普通摄像头体感游戏已经用 MediaPipe 或类似技术实现？ 可参考项目、游戏案例、技术栈拆解 High
动作定义 跳跃、跑步、挥砍、斜向动作分别应该怎么用关键点表达？ 动作规则表、关键点组合、阈值建议 High
工程模板 如何保证摄像头、模型加载、canvas 绘制、debug 面板稳定出现？ 黄金骨架 demo、稳定 HTML 模板 High
提示词策略 怎样写提示词，才能让 AI 生成更可靠的 MediaPipe 项目？ 提示词模板、验收清单、常见错误修复指令 Medium
模型路线 哪些动作规则判断就够，哪些需要训练分类器或时序模型？ 规则识别 vs 训练模型的边界判断 Medium
03 / Analysis

初步判断

当前痛点很可能由四类问题叠加造成：MediaPipe 接入不稳、动作定义不清、识别策略过于单帧化、以及 AI 提示词缺少工程约束。

Root Cause 01

MediaPipe 接入链路没有被固定

摄像头权限、模型资源路径、版本 API、canvas 尺寸、坐标映射、镜像翻转和绘制层级都可能导致“骨架不显示”。这类问题应该先用一个稳定的黄金模板锁死。

Root Cause 02

动作没有被拆成可计算规则

“跑步”“跳跃”“挥砍”不能只停留在自然语言层面，需要拆成关键点位置、角度变化、速度方向、持续帧数和置信度阈值。

Root Cause 03

只看单帧会导致误判

动作识别更适合使用时间窗口和状态机，例如“准备态、触发态、恢复态”。只看某一帧姿势，容易把噪声误判成动作。

Root Cause 04

AI 提示词缺少验收标准

需要明确要求 AI 输出可视化骨架、调试面板、关键变量、识别日志、置信度和可调参数，而不是只说“做一个能识别跳跃的 HTML”。

04 / Next

后续调研方向

下一步建议围绕“现成案例、最佳实践、稳定模板、提示词模板、动作规则库”展开，目标是把抽盲盒式开发变成可复用流程。

找已有体感游戏和开源 demo

优先调研普通摄像头、Web、MediaPipe、Pose Detection、Motion Game 相关案例，确认别人是怎么做动作事件判断的。

整理动作识别规则

把跳跃、跑步、左右挥手、斜向挥砍、深蹲等动作拆成关键点、角度、速度和状态机规则。

沉淀稳定工程模板

建立一个最小可用 HTML：摄像头可用、骨架必出、debug 信息可见、参数可调、日志可追踪。

生成 AI 提示词模板

把工程约束、验收标准、常见 bug 修复步骤写进提示词，减少 Trae / Workbody 生成代码时的不确定性。

判断是否需要训练模型

对简单、边界清晰的动作先用规则识别；对连续、相似、复杂动作，再评估分类器或时序模型。

05 / Answer

调研后的回答

结论是：上一阶段的方向是对的，但要把“调研结论”继续落成一套可复用的开发约束。MediaPipe 仍然适合作为基础输入层，真正要补的是工程模板、动作定义和验收机制。

原需求 调研回答 是否足够 下一步产物
有没有普通摄像头体感游戏案例？ 有。Starri、Catch These Hands、Dance Dash、DanSparkling、Dance Junkie、Active 2048 等都证明 PC/webcam 体感游戏存在。 已回答 案例库和可复用点清单
MediaPipe 到底能不能用？ 能用，但它只应负责 landmarks。动作语义要放到时间窗口、特征提取、状态机和冷却机制里。 已回答 固定技术架构
跑步、跳跃、挥砍怎么识别？ 挥砍、举手、击中目标适合第一版。跑步和完整跳跃依赖全身入镜，不建议作为普通笔记本摄像头 MVP。 需收窄 动作规则库 v0
怎么避免骨架不显示？ 先做黄金骨架模板，固定摄像头权限、模型路径、VIDEO 模式、canvas 对齐、镜像和 overlay 绘制。 需实现 最小 HTML 模板
怎么让 AI 生成更可靠？ 提示词必须写入工程约束和验收清单，要求先出骨架、日志和参数面板，再做动作逻辑。 需模板化 AI 生成提示词模板
06 / MVP

推荐实施方案

第一版不要做完整体感游戏平台。先做一个“黄金骨架 + 三个上半身动作 + 一个可玩小关卡”的验证原型，把抽盲盒问题压住。

Core Architecture

固定工程链路

CameraAdapter → LandmarkEngine → DebugOverlay → MotionBuffer → FeatureExtractor → ActionRecognizer → GameEventBus。游戏层只消费动作事件，不直接读原始 landmarks。

Primary Stack

Web 先行，Unity 后置

第一版用 Web + @mediapipe/tasks-vision 更快验证摄像头和动作规则。等动作层稳定后，再迁移到 Unity 或 Steam 客户端。

First Actions

先做三个动作

举手、挥砍、手部击中目标。它们对全身入镜要求较低，适合普通电脑摄像头，也是体感小游戏最容易做出反馈的动作。

Boundary

第一版不承诺跑步

跑步、深蹲、完整跳跃、舞蹈评分都需要更稳定的全身入镜和更多数据。它们可以进入后续版本，不应放进第一版验收。

07 / Rules

动作规则库 v0

动作必须从自然语言拆成关键点、特征、状态机和冷却时间。下面这张表可以直接变成后续开发任务。

动作 需要关键点 触发特征 建议状态机 MVP 优先级
举手 raise_hand 肩、肘、腕、头部 手腕高于肩或头，持续若干帧，关键点置信度达标 Idle → Candidate → Active → Exit P0
挥砍 slash 肩、肘、腕、手部 手腕速度、轨迹方向、路径长度、穿过目标线 Idle → Candidate → Active → Cooldown P0
击中目标 hit_target 腕、掌心或指尖 手进入目标区域，同时速度超过阈值 Idle → Armed → Hit → Cooldown P0
双手张开 hands_open 左右肩、左右腕 两手距离大于肩宽倍数，保持若干帧 Idle → Candidate → Active → Exit P1
左右躲避 dodge 鼻子、肩中心、躯干中心 身体中心相对校准中心横向偏移 Idle → Candidate → Active → Cooldown P1
跑步 running 髋、膝、踝、肩 下肢交替周期、身体上下节奏、全身入镜 需要更长时间窗口或分类器 暂缓
08 / Prompt

AI 生成提示词模板

如果继续用 Trae / Workbody / Codex 生成代码，提示词必须把“先骨架、后动作、可调试、可验收”写死。

请先实现黄金骨架模板，不要直接写完整游戏。必须包含摄像头权限、MediaPipe PoseLandmarker + HandLandmarker、VIDEO 模式、canvas overlay、红点绿线骨架、FPS、推理耗时、模型加载状态、关键点置信度、当前动作状态、日志面板和可调参数。只有骨架稳定显示后，再实现动作规则。每个动作必须用 MotionBuffer、FeatureExtractor、FSM、cooldown 和 rejection reason，不允许只看单帧姿势。

建议作为后续 AI 生成项目的基础提示词
09 / Acceptance

验收标准

第一版是否成功，不用“感觉准不准”判断，而是看下面这些可以复现的指标。

Gate 01

摄像头 ready

video.readyState ≥ 2，videoWidth / videoHeight 大于 0，页面能明确显示当前摄像头设备和分辨率。

Gate 02

模型 ready

WASM 和 .task 模型资源加载成功，失败时能在页面上看到错误来源，而不是静默无骨架。

Gate 03

骨架 visible

摄像头启动后 2 秒内显示 landmarks 和连接线，canvas 尺寸、镜像和坐标映射正确。

Gate 04

动作 eval

每个 P0 动作至少测试 20 次，记录误触、漏触、平均触发延迟和 P95 延迟。

Gate 05

可录制回放

能导出 landmark JSON，并用同一段 JSON 离线复现动作触发结果，避免现场反复猜阈值。

Gate 06

失败可解释

动作没触发时必须显示 rejection reason，例如关键点置信度不足、速度不够、方向不匹配、冷却中。