搭建新题型出题管线的完整方法论

1.3 初轮量化分析（基础统计）

对采集的样题做至少 8 个维度的量化分析：

1.4 深度分析（ETS 味道拆解）

初轮统计只能告诉你"是什么"，深度分析要回答"为什么这样设计"。以下是必须做的深度维度：

1.4.1 干扰项工程（Distractor Engineering）

逐题拆解每个干扰项的设计机制。不是笼统标注"这是个错答案"，而是精确分类其错误类型和制造手法：

必须量化的指标：

• 每种干扰项类型的占比分布
• 每道题使用了几种不同类型的干扰项（目标：≥2种/题）
• 干扰项与原文/speaker 的词汇重叠率（lexical overlap）
• 干扰项的"看似合理度"光谱（明显错 / 看似可能 / 差点就对）

实操方法：写分析脚本（如 scripts/analyze-{taskType}-samples.mjs），提取共享词汇、分类干扰项类型、统计分布。

1.4.2 正确答案范式（Answer Paradigms）

不要只看"正确答案是什么"，要分析"正确答案WHY是对的"——它用了什么策略来正确回应。

以 LCR（听力选回应）为例，我们发现了 5 种正确答案范式：

关键发现：如果 AI 主要生成 direct_topical（直接回答），味道就完全不对。真题中 94% 的正确答案是某种形式的间接回应。

对每种题型都要：

1. 列出所有观察到的正确答案范式
2. 统计各范式的频率分布
3. 建立 speaker 意图 → 答案策略 的映射关系
4. 标注每种范式的难度等级

1.4.3 选项间关系分析（Option Interplay）

4 个选项不是独立的——它们作为一个整体构成考查点。分析：

• 选项间语法一致性：是否刻意使用不同句式结构（防止靠形式排除）
• 选项间长度差异：正确答案在长度排名中的位置分布（如 shortest 37.5%, middle 50%, longest 12.5%）
• 选项间语义覆盖：4 个选项是否覆盖了不同的"错误方向"
• 选项内 speech act 多样性：每道题的 4 个选项是否执行不同的言语行为（建议 vs 提问 vs 道歉 vs 陈述）

1.4.4 会话自然度模型（Conversation Naturalness）

对于涉及对话的题型（听力、口语），分析什么让一个回应"自然"：

1.4.5 难度杠杆识别（Difficulty Levers）

找出控制题目难度的独立维度。每个维度都可以独立调节。

例如 LCR 的 4 个难度杠杆：

1.5 ETS 味道公式（Flavor Scoring）

将所有分析浓缩为一个可量化的"味道分数"：

flavor_score = Σ(marker_weight × marker_present) - Σ(anti_pattern_penalty)

每种题型定义 5-8 个加权 flavor marker 和对应的 anti-pattern。例如：

目标分数：≥0.70。低于此值说明生成质量与真题有显著差距。

1.6 差距分析（Gap Analysis）

在首轮 AI 生成后，对比生成结果与真题 profile 的差距：

关键产出

• data/{section}/samples/{taskType}-reference.json — 结构化样题（含逐题干扰项分析）
• data/{section}/profile/{taskType}-ets-profile.json — 基础量化 profile
• data/{section}/profile/{taskType}-deep-analysis.json — 深度分析（干扰项工程+答案范式+选项关系+会话自然度）
• data/{section}/profile/{taskType}-flavor-model.json — ETS 味道公式（加权指标+反模式+难度杠杆+设计清单）
• scripts/analyze-{taskType}-samples.mjs — 可重复运行的分析脚本
• lib/{section}Bank/profile.js — Profile 常量模块

常见坑

• 样题来源偏差：第三方练习题可能有自己的"味道"（如答案偏 B），不能直接当 ETS 标准。标注 source 并加权处理。
• 样本量不足：8 篇样题的统计不稳定，扩到 50+ 篇后数据才稳定。但即使 16 篇也足以发现核心模式。
• 遗漏维度：第一轮分析容易遗漏"选项间词汇独立性"、"日期分组"等细微维度
• 只看表面统计：不要止步于"平均词数 8.1"——要追问"为什么是 8.1？什么因素导致了这个分布？"
• 忽略干扰项设计：干扰项工程是真题味道最大的差异来源。AI 生成的干扰项往往要么太假（一眼看出错）要么太随机（和题目无关）。必须逐题分析并建模。

实际案例：LCR 题型的研究过程

Step 1: WebSearch 搜集 → 16 道样题（ETS官方+TestSucceed+TOEFLResources+知乎+TestDaily）
Step 2: 存入 data/listening/samples/lcr-reference.json（含完整干扰项分析）
Step 3: 写分析脚本 scripts/analyze-lcr-samples.mjs 提取量化指标
Step 4: 基础 profile → lcr-ets-profile.json（9 维度量化）
Step 5: 深度分析 → lcr-deep-analysis-v2.json（干扰项工程+答案范式+选项关系+会话逻辑）
Step 6: 味道模型 → lcr-flavor-model.json（5个答案范式+4种干扰项+4个难度杠杆+15项检查清单）
Step 7: 差距分析 → 对比 AI 生成 vs 真题，识别 6 个具体差距并提出修复方案

Phase 2: Prompt 工程（1-2天）

目标

写出能让 AI 生成"味道对"的题目的 prompt。

Prompt 架构

一个好的出题 prompt 包含 5 层约束：

Layer 1: 文本约束（长度、段落数、句式要求）
Layer 2: 风味约束（从 Profile 提取的量化指标）
Layer 3: 题目约束（题型分布、答案位置预分配）
Layer 4: 干扰项约束（每种题型的干扰项制造策略）
Layer 5: 反面约束（禁止第一人称、禁止反问句等）

核心原则

原则 1：用 Example 而不是 Rule

• ❌ "Sentence 1 MUST use passive voice"（DeepSeek 遵循率 30%）
• ✅ 给一个完整的 example passage，标注"KEY FEATURES TO COPY: Sentence 1 uses passive"

原则 2：答案位置预分配

• 在 prompt 中明确指定每道题的正确答案位置（A/B/C/D）
• 用 pool shuffle 确保批次内均匀分布
• 不要让 AI 自己决定答案位置（会严重偏 B）

原则 3：干扰项策略要具体到百分比

• ❌ "Write plausible distractors"
• ✅ "For factual_detail: Distractor 1 uses 2-3 passage terms but CHANGES their relationship (wrong_detail). Distractor 2 introduces topically-related content NOT in the passage (not_mentioned)."

原则 4：话题去重

• 从已有 staging 文件中提取已生成的 subjects
• 在 prompt 中明确列出"DO NOT WRITE ABOUT: cell membrane, coral reefs..."
• 使用 round-robin 在 topic pool 中循环

Prompt Builder 代码模式

function buildPrompt(count, opts = {}) {
  const { excludeSubjects = [], rejectionFeedback = [] } = opts;
  
  // 1. 话题选择 + 去重
  const selected = selectTopics(count, excludeSubjects);
  
  // 2. 答案位置预分配
  const posPool = shufflePositions(count * questionsPerItem);
  
  // 3. 组装 item specs
  const itemSpecs = selected.map((s, i) => {
    const positions = posPool.splice(0, questionsPerItem);
    return `${i+1}. Topic: ${s.topic}/${s.subtopic}\n   Questions: ${positions.join(", ")}`;
  });
  
  // 4. 拼接 prompt（约束层叠加）
  return `${PASSAGE_REQUIREMENTS}\n${QUESTION_REQUIREMENTS}\n${DISTRACTOR_ENGINEERING}\n${itemSpecs}\n${EXCLUSIONS}\n${OUTPUT_FORMAT}`;
}

关键产出

• lib/readingGen/{taskType}PromptBuilder.js

Phase 3: 校验体系（0.5天）

目标

建立三级校验 + ETS 味道评分，自动拦截不合格的生成结果。

三级校验架构

Level 1: Schema 校验（硬性错误 → 直接拒绝）
  - 必填字段是否存在
  - 数值范围是否合规（词数、题数、选项数）
  - 枚举值是否有效（题型、答案位置）

Level 2: Profile 校验（软性警告 → 通过但标记）
  - ETS 风味指标（hedging、passive、contrast）
  - FK 可读性等级
  - 选项长度分布
  - 歧义风险检测（见下方 3.1）

Level 3: ETS Flavor 评分（0-1 分，加权量化）
  - 基于 Phase 1 研究的味道公式
  - 每道题算分，低于阈值标记警告
  - 批次平均分用于整体质量判断

3.1 歧义风险检测（关键！）

这是从 LCR 题库质审中学到的最重要教训。 103 道 AI 生成的题中有 7 道（6.8%）存在"干扰项其实也是合理回应"的问题。全部被人工发现后删除。

歧义检测的机械规则：

// 检测 1: "off_topic" 干扰项与 speaker 共享 ≥3 个内容词
const shared = sharedContentWords(speaker, distractor);
if (shared.length >= 3) warn("ambiguity_risk: shares keywords");

// 检测 2: "Do you know...?" 类问句 + 干扰项以 "Yes" 开头 + 包含话题词
if (/^do you know/i.test(speaker) && /^yes/i.test(distractor) && shared.length >= 1)
  warn("ambiguity_risk: Yes + topic word");

// 检测 3: Where/When 问句 + 干扰项给了相关方位/时间信息
if (/^where/i.test(speaker) && /^it('s| is) (on|at|near)/i.test(distractor))
  warn("ambiguity_risk: gives location for where-question");

常见歧义模式（从真实审核中总结）：

防御原则：每个干扰项在写完后必须过一次"现实对话测试"——如果有人在现实中这么回答，对方会不会觉得很自然？如果会，就不能用作干扰项。

批次校验

• 整批答案位置分布是否接近均匀（25% each）
• 话题多样性（批次内是否有重复主题）
• 体裁覆盖度（RDL 是否 email/notice 都有）
• ETS Flavor 平均分（目标 ≥0.70）
• 缩写率 / 话语标记率 / 答案范式分布

ETS Flavor 评分模式

对每道题计算加权味道分，用于量化"真题感"：

function scoreFlavor(item) {
  const scores = {};
  scores.indirect_answer = isIndirect ? 1 : 0;          // 权重 0.25
  scores.word_trap = hasWordTrapDistractor ? 1 : 0;      // 权重 0.20
  scores.distractor_diversity = uniqueTypes >= 2 ? 1 : 0; // 权重 0.15
  scores.natural_register = hasContraction ? 0.6 : 0;    // 权重 0.15
  scores.constructive_tone = isConstructive ? 1 : 0;     // 权重 0.10
  scores.plausible_distractors = allPlausible ? 1 : 0;   // 权重 0.10
  scores.length_neutrality = correctNotLongest ? 1 : 0;  // 权重 0.05
  
  return weightedSum(scores); // 0-1, target ≥ 0.70
}

关键产出

• lib/{examType}Gen/{taskType}Validator.js

Phase 4: AI 审核 + 歧义防御（1天）

目标

用 AI 作为"第二审核官"，从两个角度验证题目质量：

1. 答案正确性：AI 是否同意标注的正确答案
2. 歧义性：是否存在多个合理答案（最重要！）

三层防御架构

题目质量问题不能只靠一层防御。经 LCR 实战验证，需要三层：

Layer 1: Prompt 防御（预防）
  ↓ 从源头减少问题生成
Layer 2: Validator 检测（预警）  
  ↓ 机械规则标记可疑项
Layer 3: AI Audit（判定）
  ↓ AI 独立作答，最终裁决
  → 通过 / 拒绝

Layer 1: Prompt 层防御

在 prompt 中加入真实失败案例，让 AI 知道哪些模式会导致题目被删除：

### AMBIGUITY PREVENTION (READ CAREFULLY):
The most common fatal flaw: a distractor that ALSO works as a valid response.
Before writing each distractor, ask: "If someone said this in real life,
would it be a reasonable reply?" If YES → rewrite it.

REAL FAILURES FROM OUR QUALITY AUDIT:
- Speaker: "Do you know which chapters we're supposed to read?"
  BAD distractor: "I haven't read the chapters yet either."
  ← THIS IS A NATURAL RESPONSE, not a distractor!

- Speaker: "Do you know if the gym is still open?"  
  BAD distractor: "Yes, I was there yesterday."
  ← IMPLIES THE GYM EXISTS AND OPENS!

关键原则：用真实被删除的坏题做反面教材，比抽象规则有效 10 倍。每次人工审核发现新的歧义模式，都要回填到 prompt 中。

Layer 2: Validator 层检测

参见 Phase 3 的 3.1 歧义风险检测。机械检测不能替代 AI 审核，但能提前标记可疑项，在日志中醒目显示。

Layer 3: AI Audit 层

这是最关键的一层——AI 独立做题，检测答案是否唯一正确。

审核模式

模式 A: 阅读/听力 MCQ（RDL/AP/LCR 等）

Pass 1: 独立作答 + 逐项评级

• 把题目+选项发给 AI（不告诉正确答案）
• AI 对每个选项评级：valid / partially_valid / invalid
• AI 选出 best answer
• 判定逻辑：
  • AI best ≠ 我们的 answer → MISMATCH（直接删除）
  • 多个选项被评为 valid → AMBIGUOUS（直接删除）
  • AI best = 我们的 answer 且只有 1 个 valid → CLEAN（通过）

async function auditItem(item, callAI) {
  const prompt = `Rate each option as valid/partially_valid/invalid,
    then pick the SINGLE BEST response.
    Speaker: "${item.speaker}"
    A. ${item.options.A}  B. ${item.options.B}
    C. ${item.options.C}  D. ${item.options.D}
    Return JSON: { ratings: {A:..., B:..., C:..., D:...}, best: "X", reasoning: "..." }`;
  
  const result = await callAI(prompt);
  const parsed = JSON.parse(result);
  
  const match = parsed.best === item.answer;
  const validCount = Object.values(parsed.ratings).filter(r => r === "valid").length;
  const ambiguous = validCount > 1;
  
  return { match, ambiguous, ratings: parsed.ratings };
}

Pass 2: 不看原文猜题（仅阅读题型，验证可猜性）

• 只发题目+选项（不给原文/音频文本）
• AI 靠常识猜
• 如果猜对 → GUESSABLE warning（干扰项太弱）

审核参数

• temperature: 0.1（低温确保确定性）
• model: 和生成用同一个（DeepSeek）
• timeout: 30s/题
• 每批所有 accepted 的题全部审核（不抽样）

审核效果实测

LCR 的歧义问题是所有题型中最严重的（20%），因为对话回应天然有多种合理方式。这就是为什么 LCR 需要三层防御而不是仅靠 AI audit。

反馈闭环

审核发现的问题要回流到前面的层：

AI Audit 发现新的歧义模式
  → 加入 Prompt 的反面案例（Layer 1）
  → 加入 Validator 的检测规则（Layer 2）
  → 更新 flavor model 的 anti-pattern（Phase 1 数据）

每次批量生成后，检查被 audit 拦截的题目，分析失败模式，更新管线。这个循环持续运转，管线质量会越来越好。

关键产出

• lib/{examType}Gen/{taskType}Auditor.js — 题型专用审核模块
• lib/readingGen/answerAuditor.js — 阅读题通用审核（可跨题型复用）

常见坑

• 只靠 AI audit 不够：AI audit 能抓住大部分歧义，但偶尔 AI 自己也会误判。三层防御互相补位。
• 不要跳过 audit 节省 API 调用：LCR 的 20% 歧义拦截率意味着不跑 audit 会有 1/5 的坏题进库。
• 审核 prompt 要用低温：temperature 0.1，确保 AI 判断一致。高温会导致同一道题每次审核结果不同。
• 审核发现的坏题是宝贵数据：每个被拦截的题都是一个反面教材，要收集并回填到 prompt 中。

Phase 5: 生成脚本（0.5天）

目标

串联以上所有模块的编排脚本。

标准流程

1. 解析 CLI 参数 (--count, --difficulty, --skip-audit, --dry-run)
2. 从 staging 目录读取已有 subjects 做去重
3. 调用 PromptBuilder 构建 prompt
4. 调用 AI API（DeepSeek/GPT/Claude）
5. JSON 解析 + 部分响应 salvage
6. 逐 item 校验（schema + profile + quality）
7. 批次校验（答案分布、话题多样性）
8. [可选] AI 审核（移除 mismatch 的 item）
9. 保存到 staging 目录
10. 输出统计摘要

JSON Salvage 机制

AI 的 JSON 输出经常被截断（尤其是大批量时）。必须有 salvage 逻辑：

function salvagePartialJson(text) {
  const body = text.slice(text.indexOf("[") + 1);
  const items = [];
  let depth = 0, objStart = -1;
  for (let i = 0; i < body.length; i++) {
    if (body[i] === "{" && depth === 0) objStart = i;
    if (body[i] === "{") depth++;
    if (body[i] === "}") depth--;
    if (body[i] === "}" && depth === 0 && objStart >= 0) {
      try { items.push(JSON.parse(body.slice(objStart, i + 1))); } catch {}
      objStart = -1;
    }
  }
  return items;
}

批量限制（经验值）

• CTW: 无限制（token 轻量）
• RDL: ≤10 题/批（超过 10 JSON 截断率高）
• AP: ≤5 题/批（5 题 × 5 问 × 4 选项 + 解析 = 大量 token）

关键产出

• scripts/generate-{taskType}.mjs

Phase 6: 压力测试 + 迭代（1-2天）

测试计划

常见问题 + 解法

迭代循环

生成 → 统计 → 发现问题 → 改 prompt/validator → 再生成 → 再统计 → ...

一般需要 3-5 轮迭代才能稳定。

Phase 7: 前端集成（1天）

标准集成点

1. 首页入口卡片 — 在 section content 中加 task card
2. 路由页面 — /reading?type={taskType} 渲染做题组件
3. 做题组件 — 复用已有模式（如 RDLTask 可被 AP 复用）
4. Session 保存 — 调用 saveSess() 保存完整题目数据
5. 练习记录 — 在 ProgressView 中加入新类型的筛选和展开详情

Session 数据设计

必须保存完整题目数据（不只是对错），这样练习记录才能显示原题回顾：

saveSess({
  type: "reading",
  correct: result.correct,
  total: result.total,
  details: {
    subtype: "ap",
    passage: item.passage,        // 完整原文
    questions: item.questions,    // 完整题目+选项+解析
    results: result.results,      // 用户作答+对错
  },
});

7.1 Session 防丢失（关键！涉及 AI 评分的任务必须做）

这是从写作模块真实线上事故中学到的教训。 用户花 7 分钟写完一篇邮件，提交评分后 AI 超时，退出页面后发现整条记录消失——作文内容彻底丢失，无法重新评分。

丢失场景分析

任何涉及异步 AI 评分（写作、口语）的任务都有以下丢失风险：

三层防丢失架构

Layer 1: catch 分支保存（评分失败时）
  ↓ 异常被捕获时立刻 saveSess({scoringFailed: true, userText, promptData})
Layer 2: beforeunload 保存（关闭标签页时）
  ↓ window.addEventListener("beforeunload", savePartialOnExit)
Layer 3: useEffect cleanup 保存（路由切换/组件卸载时）
  ↓ return () => { savePartialOnExit(); }

实现代码模式

// 1. 追踪是否已保存（防重复保存）
const sessionSavedRef = useRef(false);

// 2. useEffect 同时挂 beforeunload + cleanup
useEffect(() => {
  if (!persistSession) return;
  function savePartialOnExit() {
    if (sessionSavedRef.current) return; // 已保存则跳过
    const hasText = text && text.trim().length > 10;
    const needsSave = hasText && (phase === "scoring" || (phase === "done" && !fb));
    if (!needsSave || !promptData) return;
    sessionSavedRef.current = true;
    saveSess({
      type, score: null, band: null, wordCount: wc(text),
      scoringFailed: true,
      scoringError: "用户在评分完成前离开了页面",
      details: { promptData, userText: text, feedback: null },
    });
  }
  window.addEventListener("beforeunload", savePartialOnExit);
  return () => {
    savePartialOnExit(); // 组件卸载时也触发
    window.removeEventListener("beforeunload", savePartialOnExit);
  };
}, [persistSession, text, promptData, fb, type]);

// 3. 评分成功时标记已保存
if (persistSession) {
  saveSess(successPayload);
  sessionSavedRef.current = true;
}

// 4. catch 分支也保存 + 标记
catch (e) {
  if (persistSession && promptData) {
    saveSess({ ...partialPayload, scoringFailed: true, scoringError: errMsg });
    sessionSavedRef.current = true;
  }
}

// 5. 切换新题目时重置
sessionSavedRef.current = false;

保存的失败记录格式

失败记录必须包含足够的数据来支持后续重新评分：

{
  type: "email",
  score: null,           // 未评分
  band: null,
  wordCount: 95,
  scoringFailed: true,   // 标记为失败
  scoringError: "网络超时（90秒），请重试",
  details: {
    promptData: { ... },  // 完整题目（用于重新评分）
    userText: "Dear ...", // 完整作文（用于重新评分）
    feedback: null,       // 无 AI 反馈
  }
}

防丢失检查清单

• saveSess() 在 success 分支和 catch 分支都有调用
• beforeunload 事件监听器已注册
• useEffect cleanup 函数中调用了保底保存
• sessionSavedRef 防止重复保存
• 失败记录包含 promptData 和 userText（可重新评分）
• 切换新题目时 sessionSavedRef.current = false
• 模考模式下 persistSession=false 时跳过所有保存（模考有自己的保存机制）

常见坑

• 只在 success 分支保存：最常见的 bug。async 函数的 catch 分支必须也保存。
• beforeunload 不触发：在 SPA 中路由切换不触发 beforeunload，必须同时用 useEffect cleanup。
• 重复保存：三层保护可能导致同一条记录被保存多次。用 ref 追踪状态。
• 模考模式冲突：嵌入式写作任务（模考中的 Task 2/3）设 persistSession=false，它们有自己的 deferred scoring 流程，不应触发独立保存。

清单：搭建新题型需要创建的文件

lib/{examType}Bank/
├── {taskType}Profile.js          # Profile 常量

lib/{examType}Gen/
├── {taskType}PromptBuilder.js    # Prompt 构建器
├── {taskType}Validator.js        # 校验器
├── answerAuditor.js              # AI 审核（可跨题型复用）
└── {taskType}Difficulty.js       # [可选] 难度估算

scripts/
├── generate-{taskType}.mjs       # 生成脚本
├── analyze-{taskType}-flavor.mjs # [可选] 味道分析脚本
└── audit-{taskType}-staging.mjs  # [可选] 独立审核脚本

data/{examType}/
├── samples/{taskType}/           # 样题数据
├── profile/                      # 分析结果
├── bank/                         # 题库（部署后）
└── staging/                      # 生成暂存区

经验数据：三条管线的实际表现