# 测验验收

> 测验验收(quiz 验收):一段长工作会话或大改动结束后、合并/发布/交付之前, 生成一份"发生了什么"的直白报告 + 底部测验,用户满分才算验收通过。 解决的问题:Claude 干的活越多,用户越可能"以为自己懂了"——光看 diff 或摘要 只能获得表面理解,测验暴露真实的理解缺口。 触发词:测验验收、考考我、quiz、出个测验、「我想确认我真的理解了这次改动」。 当一次会话改动量大、决策多,而用户即将合并/发布/关闭会话时,应主动建议做一次测验验收。

- Skill: `chenyuxiaojin/skill` (Agent Skill)
- Install (CLI): `npx skillmds@latest add chenyuxiaojin/skill`
- Raw SKILL.md: https://api.skillmd.com/api/skills/chenyuxiaojin/skill/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: chenyuxiaojin (https://skillmd.com/u/chenyuxiaojin)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/chenyuxiaojin/skill

---


# 测验验收 · 满分才放行

方法论来自 Anthropic 工程师 Thariq《A Field Guide to Fable》:长会话后 Claude 完成的
往往比用户意识到的多,读 diff 只能获得浅层理解(很多行为取决于既有代码路径)。
让用户先通过测验再合并,是把"未知的未知"在出事前暴露出来的最后一道闸。

用户是非程序员——报告和题目都考**行为和决策**,不考语法和 API 记忆。

## 流程(三步)

### 第 1 步:盘点这次到底发生了什么

先取证,不凭印象:

- 有 git → 看本次会话涉及的 diff / 新增文件
- 无 git(文案、配置、素材类)→ 盘点本次会话产出和修改的所有文件
- 回顾会话中的**关键决策**,尤其:偏离原计划的地方、替用户做的假设、留下的隐患

### 第 2 步:生成报告 + 测验(HTML artifact)

一份 HTML,上半是报告,下半是测验。报告结构:

```
## 这次做了什么(一段话总览)
## 为什么这么做(关键决策 + 每个决策当时的理由)
## 偏离与假设(哪里没按原计划走、替你拍板了什么)
## 现在的行为(改动后,系统/文件/流程在真实使用中会怎么表现)
## 遗留与风险(没做的、将来可能咬人的)
```

测验规则:

- **5~8 题**,选择题为主、简答一两道
- 题目考的是:「这个改动之后,X 情况下会发生什么?」「当时为什么选 A 不选 B?」
  「如果要改 Y,应该动哪里?」「哪个隐患在什么条件下会爆?」
- 每道题必须对应一个**真实的理解缺口会导致真实代价**的点,不出送分题、不出抠字眼题
- 答案先不给,等用户作答

### 第 3 步:批改与放行

- 用户作答后逐题批改:答错的题 = 真实理解缺口,**详细讲解到懂**,不是报个对错
- 有错 → 讲解后针对错题换角度出补考题(不重复原题),直到满分
- 满分 → 明确宣布:**验收通过,可以合并/发布/收工**
- 用户答题过程中暴露出报告没覆盖的疑问 → 当场补讲,并检查是不是改动本身有问题

## 边界

- 测验暴露出"改动本身可能有错"时,停止验收流程,回到调试纪律:先用证据定位,不许顺手改
- 用户明确说"跳过测验直接合并"→ 尊重,但提醒一句这次改动里风险最高的一个点