一、怎么理解 Skill？项目用还是不用？

1.1 Skill 的本质

Skill = 可复用的领域能力封装

普通代码	Skill
解决单个问题	解决一类问题
写死在项目里	可插拔、可配置
工程师视角	产品经理视角

1.2 这个项目用了 Skill 吗？

现状：半自动状态

你之前的 analyticsService.ts 其实就是埋点 Skill 的雏形：

// 这不是普通代码，这是 Skill 的 MVP 版本

trackEvent(eventName, properties) // 标准化事件记录

getMetricsSummary() // 标准化指标计算

AnalyticsEvents.EXAM_START // 预定义事件字典

但它还不是完整 Skill，因为：

• ❌ 没有配置文件（事件名散落在代码里）
• ❌ 没有可视化界面（需要控制台查看）
• ❌ 没有自动化分析（需要人工解读）

1.3 建议：Badcase 评估做成 Skill

为什么？

因为这是跨项目的通用能力——任何 AI 评分产品都需要验证准确性。

Skill 设计草案：

// badcase-skill/config.ts

export const BadcaseConfig = {

severityRules: [

{ level: 'critical', condition: (diff) => Math.abs(diff) > 1.5 },

{ level: 'major', condition: (diff) => Math.abs(diff) > 0.5 },

],

autoReviewRules: [

{ type: 'knowledge_error', autoConfirm: true, pattern: /语法纠正错误/ },

]

};

// badcase-skill/index.ts

export class BadcaseSkill {

async submit(data: BadcaseData): Promise<ReviewResult>;

async getStats(timeRange: string): Promise<StatsReport>;

async autoReview(pendingCases: Badcase[]): Promise<Reviewed[]>;

}

用还是不用？

场景	建议
本周上线	不用，先跑通手动流程
下周迭代	把 badcase 模块抽成 Skill，方便复用
做多项目	必须做成 Skill，否则每个项目重写

---

二、Badcase 是自动评估的吗？有自动回流吗？

2.1 当前项目状态

根据 badcases.html 代码，目前是纯人工审核：

// 运营人员点击按钮审核

async function reviewBadcase(id, action) {

await fetch(`/api/badcase/${id}/review?action=${action}`, {

method: 'POST'

});

}

没有自动评估，没有自动回流。

2.2 要不要做自动评估？

建议：分阶段做

Phase 1（现在-上线后1周）：纯人工

├── 运营人员听录音 → 判断对错 → 标记状态

└── 目的：积累数据，确定判断标准

Phase 2（有100条数据后）：半自动

├── 系统自动标记：分差>2分 → 直接标记 critical

├── 人工复核：0.5-2分 → 人工听录音确认

└── 目的：减少运营工作量

Phase 3（有1000条数据后）：全自动

├── 训练简单分类器：根据 transcript 特征判断是否是 badcase

├── 自动确认：confidence > 0.9 的直接确认

└── 目的：运营只看边缘案例

2.3 自动回流怎么做？

什么是回流？

用户反馈 → 确认是AI问题 → 修复Prompt/算法 → 回归测试 → 标记fixed

↑

这就是回流

自动回流系统设计：

// 1. 自动修复触发器

当 badcase 被标记为 confirmed 且 type = 'knowledge_error' 时：

- 自动提取 error_pattern

- 检索知识库，看是否有缺失/错误

- 生成修复建议（PR描述）

// 2. 回归测试

修复后，自动用原 badcase 数据重新跑评分

- 新分数 vs 旧分数

- 如果 improvement > 0.5 → 自动标记 fixed

- 如果恶化 → 回滚，人工介入

// 3. 知识库更新

如果是词汇/句型问题 → 自动更新 knowledge_base/*.json

如果是评分算法问题 → 更新 Prompt 模板

当前项目需要吗？

• MVP阶段：不需要自动回流，人工更新即可
• 日均100+ badcase后：必须做，否则运营崩溃

---

三、人工评 vs 自动化：权衡框架

3.1 决策矩阵

Badcase 类型	自动化可行性	建议方式	理由
分差>2分	⭐⭐⭐ 高	自动标记 critical	数值判断，无需人工
知识错误（语法纠错错）	⭐⭐⭐ 高	半自动：关键词匹配	"should" 写成 "shoud" 明显错误
建议不匹配	⭐⭐ 中	人工审核	需要理解语境
用户主观不满	⭐ 低	必须人工	"我觉得不公平" 无法自动判断

3.2 成本对比（假设日均50条 badcase）

方案	运营成本	准确性	适用阶段
纯人工	4小时/天	95%	<100条/天
半自动	1小时/天	90%	100-500条/天
全自动	0.2小时/天	85%	>500条/天

3.3 给你的建议

现在（上线前）：纯人工，积累判断标准

上线后1个月：做"自动预标记 + 人工确认"

// 自动预标记逻辑

function autoLabel(badcase) {

const { aiScore, userClaimedScore, type } = badcase;

const diff = Math.abs(aiScore - userClaimedScore);

if (diff > 2) return { severity: 'critical', confidence: 0.95 };

if (diff > 1 && type === 'score_deviation') return { severity: 'major', confidence: 0.8 };

return { severity: null, confidence: 0 }; // 需人工判断

}

---

四、评估体系如何迭代？

4.1 迭代的本质

不是改代码，是改"标准"

阶段	标准来源	评估重点
V0	产品直觉	能不能跑通
V1	用户反馈	用户满不满意
V2	Badcase 数据	AI评得准不准
V3	A/B 测试	哪个版本更好

4.2 具体迭代路径

Week 1: 上线跑通

├── 核心问题：考试流程是否完整？

├── 指标：完成率 > 50%

└── 迭代：修bug，保流程

Week 2-3: 收集 Badcase

├── 核心问题：评分准确性如何？

├── 指标：Badcase 确认率 < 30%（说明AI大多是对的）

└── 迭代：调整 Prompt 权重，修复明显错误

Week 4-6: 优化体验

├── 核心问题：用户满意度如何？

├── 指标：NPS > 50，二次使用率 > 40%

└── 迭代：优化报告可读性，增强知识库推荐

Week 7+: 规模化

├── 核心问题：能不能批量服务用户？

├── 指标：成本/用户 < 0.5元，响应时间 < 3秒

└── 迭代：缓存优化，模型蒸馏

4.3 评估标准的演进

// V1：简单数值比较

const isAccurate = Math.abs(aiScore - humanScore) < 0.5;

// V2：维度级比较

const isAccurate =

fluencyDiff < 0.5 &&

vocabularyDiff < 0.5 &&

grammarDiff < 0.5;

// V3：情境化评估

const isAccurate = (context) => {

if (context.userLevel === 'beginner') {

// 对初学者，宽容度更高

return Math.abs(aiScore - humanScore) < 1.0;

}

return Math.abs(aiScore - humanScore) < 0.5;

};

---

五、数据指标值什么？怎么搭建？

5.1 指标体系金字塔

┌─────────┐

│ 北极星 │ 用户提分率

│ 指标 │ （核心商业价值）

└────┬────┘

│

┌─────────────┼─────────────┐

│ │ │

┌──┴──┐ ┌─┴─┐ ┌──┴──┐

│产品指标│ │质量指标│ │运营指标│

│ │ │ │ │ │

│完成率│ │准确率│ │Badcase率│

│活跃 │ │误差 │ │修复周期 │

│留存 │ │召回率│ │成本 │

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

5.2 每个指标的定义和计算

指标	计算公式	目标值	采集方式
完成率	完成考试数/开始考试数	>70%	埋点：exam_start vs exam_complete
准确率	(1 -	AI分数-人工分数	/9) * 100%
Badcase率	Badcase数/总会话数	<10%	数据库统计
修复周期	AVG(fixed_at - confirmed_at)	<3天	数据库时间戳
召回率	人工发现的错误数/总错误数	>90%	抽样人工全量审核

5.3 搭建步骤

# Step 1: 埋点（已实现）

- analyticsService.ts 记录用户行为

- LocalStorage 存储，零后端成本

# Step 2: 数据库表（已实现）

- badcase_records 表记录质量问题

- 状态字段：pending → confirmed → fixed

# Step 3: 可视化（部分实现）

- badcases.html 运营后台

- 缺少：实时数据仪表盘（可用 /api/admin/dashboard）

# Step 4: 自动化分析（待做）

- 每周自动邮件报告

- 异常自动告警（如错误率>10%）

---

六、知识库必须用 RAG 吗？

6.1 RAG 是什么？

RAG = Retrieval-Augmented Generation（检索增强生成）

传统方式：把所有知识塞进 Prompt

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

│ Prompt: 你是雅思专家。以下是所有词汇... │

│ [1000个词汇，占5000 tokens] │

│ 用户问题：评价这段回答 │

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

RAG 方式：先检索，再生成

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

│ Step 1: 根据用户回答的话题，检索相关词汇 │

│ 匹配到：hometown 话题，10个词汇 │

│ Step 2: 把这10个词汇塞进 Prompt │

│ [10个词汇，占100 tokens] │

│ Step 3: 生成报告 │

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

6.2 你的项目用了 RAG 吗？

用了，但是简化版 RAG-lite

# server.py 中的 _get_knowledge() 就是 RAG

def _get_knowledge(topic_hint: str, dimension: str) -> Dict:

# 1. 检索（Retrieval）

vocab_data = kb.get("vocabulary", {})

for topic_key, topic_data in vocab_data.items():

if topic_hint.lower() in topic_key.lower():

# 只取前5个，不是全部

results["vocabulary"].extend(topic_data.get("words", [])[:5])

# 2. 生成（Generation）时用上检索结果

return results

对比标准 RAG：

特性	标准 RAG	你的 RAG-lite	适用性
向量检索	✅ 用 embedding	❌ 字符串匹配	词汇量小，字符串够用
语义理解	✅ 语义相似	❌ 精确匹配	话题标签明确，精确匹配够用
动态排序	✅ 相关性排序	❌ 固定顺序	MVP够用
大规模数据	✅ 百万级	❌ 几百条	当前规模几百条够用

6.3 什么时候必须上标准 RAG？

现在（几百条词汇）：RAG-lite 够用，2小时实现

未来（上万条素材）：

├── 需要语义匹配："家乡" 能匹配到 "hometown"

├── 需要模糊搜索："科技" 能匹配到 "technology/AI/digital"

└── 必须上标准 RAG（向量数据库 + Embedding 模型）

6.4 给你的建议

现在：保持 RAG-lite，不要过度设计

扩展时：逐步升级

# Phase 1: 字符串匹配（当前）

if "hometown" in topic_hint: return hometown_vocab

# Phase 2: 同义词扩展

topic_synonyms = {

"hometown": ["家乡", "故乡", "出生地", "老家"],

"technology": ["科技", "技术", "数码", "AI"]

}

# Phase 3: 向量检索（未来）

from sentence_transformers import SentenceTransformer

model = SentenceTransformer('paraphrase-multilingual-MiniLM-L12-v2')

embeddings = model.encode([topic_hint, "hometown topic vocabulary..."])

similarity = cosine_similarity(embeddings)

---

总结：给你的行动清单

优先级	任务	判断
P0	保持当前人工审核 Badcase	数据量小，人工更准
P1	上线后加自动预标记（分差>2分自动标critical）	减少运营工作量
P2	评估体系按4周计划迭代	先跑通再优化
P3	知识库保持 RAG-lite	当前规模够用，别过度设计
P4	把埋点和 badcase 抽成 Skill	做多项目时再做

核心原则：

"不要为了用技术而用技术。MVP阶段，能人工不自动，能简单不复杂，能 fake 不真做。"

你现在的架构已经超过 90% 的同类项目了，先上线收集真实数据，再决定下一步。