BadCase 有什么分类 为什么这么做？评估体系是什么？做这些的依据呢？埋点怎么做的？ 为什么这么做？数据指标都有什么？ 怎么搭建的？

一、Badcase 分类体系（4类3级）

1.1 四种类型（从 badcases.html 第79-84行）

类型	代码标识	定义	典型场景
评分偏差	score_deviation	AI分数 vs 实际水平不符	用户雅思7分，AI只给5分
知识错误	knowledge_error	报告中的知识点错误	语法纠错错了、词汇解释不对
建议不符	suggestion_mismatch	建议与题目不匹配	Part2让用工作话题词汇，但题目是家乡
用户反馈	user_feedback	用户主观不满	"我觉得这个评分不公平"

1.2 三级严重度（从 badcases.html 第31-36行）

.badge-critical { background: #fef2f2; color: #ef4444; } /* 严重 */

.badge-major { background: #fff7ed; color: #f97316; } /* 重要 */

.badge-minor { background: #f0fdf4; color: #22c55e; } /* 轻微 */

级别	判定标准	处理时效
Critical	分差>1.5分 / 知识性错误 / 多人反馈同一问题	24小时内
Major	分差0.5-1.5分 / 建议明显不匹配	3天内
Minor	分差<0.5分 / 措辞不当 / 主观感受	1周内

1.3 三种状态流转

pending（待审核） → confirmed（已确认） → fixed（已修复）

↓

ignored（已忽略）

---

二、为什么要做这个分类？

2.1 核心目的（产品视角）

没有分类	有分类
"用户说评分不准" → 不知道哪不准	"Critical评分偏差：发音维度系统偏低" → 精准修复
优化没方向，到处改Prompt	按类型统计，优先修复高频问题类型
面试吹"AI评分准"没底气	有数据：Critical级Badcase<5%，确认误差±0.5分

2.2 数据驱动决策（从 ENGINEERING.md 第140-141行）

运营后台查看：

- 评分偏差统计 → 看哪个维度不准

- 审核 badcase 状态 → 追踪修复进度

---

三、评估体系（完整闭环）

3.1 四层评估架构

├───────────────────────────────────────────────────────────

│ Layer 1: 实时评估（考试过程中） │

│ • 讯飞ISE API → 发音准确度、流利度 │

│ • 语音评测 → 实时音素级反馈 │

├───────────────────────────────────────────────────────────

│ Layer 2: 单题评估（每题回答后） │

│ • LLM四维评分 → 流利度/词汇/语法/发音 │

│ • 知识库检索 → 话题词汇、句型建议 │

├───────────────────────────────────────────────────────────

│ Layer 3: 整场评估（考试结束后） │

│ • 汇总分析 → 薄弱维度识别 │

│ • Gap分析 → 目标分数 vs 当前分数差距 │

├───────────────────────────────────────────────────────────

│ Layer 4: 长期评估（运营层面） │

│ • Badcase审核 → 验证AI准确性 │

│ • 数据统计 → 维度准确率、类型分布 │

├───────────────────────────────────────────────────────────

3.2 Badcase验证流程（闭环）

用户考试 → AI评分 → 用户点击"申诉"

↓

上报Badcase（类型自动标记/人工标记）

↓

运营后台审核：听录音 → 判断对错

↓

确认是AI错误 → 标记confirmed → 通知开发修复

↓

修复后回归测试 → 标记fixed

↓

统计各类型Badcase占比 → 指导优化优先级

3.3 关键评估指标

指标	计算方式	健康阈值
Badcase率	Badcase数 / 总会话数	<10%
确认率	Confirmed数 / Badcase数	反映真实问题比例
Critical占比	Critical数 / Badcase数	<20%
修复周期	从confirmed到fixed平均时间	<3天
维度准确率	各维度人工确认准确率	>85%

---

四、埋点体系（如何搭建的）

4.1 埋点位置（从 ENGINEERING.md 第40行）

┌────────────────────────────────────────┐

│ LocalStorage 埋点数据 │

│ • 用户行为（点击、跳转、退出） │

│ • 考试流程（开始、完成、跳过） │

│ • 错误事件（API失败、录音失败） │

│ • 性能数据（加载时间、API延迟） │

└────────────────────────────────────────┘

4.2 为什么用 LocalStorage？

方案	优点	缺点	你的选择
LocalStorage	零后端成本、立即实现	用户换设备丢失	✅ MVP首选
后端数据库	数据完整、多设备同步	需开发API、存储成本	延后
第三方统计(GA)	功能完善	数据在境外、隐私问题	可选补充

4.3 核心埋点事件

从 analyticsService.ts 预设事件：

AnalyticsEvents = {

EXAM_START: 'exam_start', // 考试开始

EXAM_COMPLETE: 'exam_complete', // 正常完成

EXAM_ABANDON: 'exam_abandon', // 中途退出

PART_COMPLETE: 'part_complete', // Part完成

QUESTION_SKIP: 'question_skip', // 题目跳过

VOICE_RECORD_START: 'voice_record_start',

VOICE_RECORD_STOP: 'voice_record_stop',

TTS_PLAY: 'tts_play',

REPORT_VIEW: 'report_view',

ERROR_API: 'error_api', // API错误

ERROR_MIC_PERMISSION: 'error_mic_permission',

}

4.4 查看方式（从 ENGINEERING.md 第147-155行）

快捷键：Alt + Shift + A → 打开仪表盘

控制台命令：

__analytics.trackEvent('test', { data: 'value' })

__analytics.getMetricsSummary()

__analytics.exportData()

---

五、数据指标体系（看什么？为什么？）

5.1 核心指标（运营仪表盘）

指标	定义	为什么看	正常范围
完成率	完成考试数 / 开始考试数	用户是否走完流程	>70%
活跃会话	最近1小时在线用户数	实时并发压力	根据预期
平均时长	完成考试平均用时	用户停留是否合理	10-20分钟
错误率	错误事件 / 总事件	系统稳定性	<5%
跳过率	跳过题目数 / 总题目数	题目难度是否合适	<15%

5.2 维度深度指标

Part 维度：

- Part 1 完成/跳过比例

- Part 2 完成/跳过比例

- Part 3 完成/跳过比例

→ 如果 Part 2 跳过率 50% → 题目太难或太长

5.3 Badcase专项指标

从 badcases.html 第102-130行代码可见：

// 统计面板展示

{

"严重问题": criticalCount, // 需立即处理

"待处理": pendingCount, // 审核队列长度

"7天新增": total, // 趋势变化

"平均偏差": avgScoreDiff // ISE vs LLM差异

}

---

六、完整搭建路径（怎么做的）

6.1 第一阶段：基础埋点（1天）

1. 创建 analyticsService.ts

2. 在关键事件处调用 trackEvent()

3. 实现 getMetricsSummary() 统计

4. 快捷键 Alt+Shift+A 打开仪表盘

6.2 第二阶段：运营后台（1-2天）

1. 创建 badcase_records 表

2. 实现 /api/badcase/submit API

3. 实现 /api/badcase/list API

4. 创建 admin/badcases.html 页面

5. 实现审核按钮和状态流转

6.3 第三阶段：知识库集成（2-3天）

1. 创建 knowledge_base/ 目录

2. 编写词汇、句型、发音JSON文件

3. 实现 _get_knowledge() 检索函数

4. 修改 Prompt 模板集成知识库内容

6.4 第四阶段：目标分数（1天）

1. 数据库添加 target_score 字段

2. 修改创建会话API接收目标分数

3. 实现 Gap 计算逻辑

4. 报告模板添加差距分析区块

---

七、总结：为什么要这么做？

模块	不做会怎样	做了的好处
Badcase分类	不知道AI哪里不准，优化没方向	精准定位问题，数据驱动迭代
三级严重度	小问题占用大量时间，大问题遗漏	资源优先投入Critical问题
埋点体系	上线后一无所知，用户流失找不到原因	实时监控，快速定位流失点
LocalStorage	后端开发2周，错过上线窗口	2小时搞定，立即能用
知识库	报告空洞，"多练习词汇"这种废话	具体建议，"用picturesque替代good"
目标分数	用户不知道还要努力多久	量化差距，明确努力方向

---

你现在有的 vs 还需要补的：

✅ 已完整实现：

• Badcase 分类体系（4类3级）
• 运营后台页面（badcases.html）
• 埋点快捷键（Alt+Shift+A）
• 知识库文件
• 目标分数Gap分析

⏳ 需要验证是否正常工作：

• Badcase提交API能否正常写入数据库
• 运营后台能否拉取到真实数据
• 埋点数据是否正确记录
• 知识库推荐是否出现在报告里