Back to Details

branch-quiz

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Overview

概述

Quiz the user on a git branch's changes to verify genuine comprehension. Rather than passively reading diffs, the user answers targeted questions covering: runtime behavior, embedded assumptions, failure points, edge cases, API design decisions, data model changes, data flows, security implications, performance impacts, and dependencies & integration effects. Score their understanding and surface any gaps.
通过测验用户对Git分支代码变更的掌握情况，验证其是否真正理解变更内容。不同于被动查看代码差异（diff），用户需要回答针对以下维度的定向问题：运行时行为、隐含假设前提、故障点、边缘情况、API设计决策、数据模型变更、数据流、安全影响、性能影响，以及依赖与集成效应。对用户的理解程度进行评分，并指出存在的知识盲区。

Process

流程

1. Gather the Diff

1. 收集代码差异

Run 
git diff main...HEAD
to collect all changes on the current branch. If the branch has no diff against main, inform the user and stop.
执行
git diff main...HEAD
命令，收集当前分支的所有变更内容。若该分支与main分支无差异，告知用户并终止流程。

2. Analyze the Changes

2. 分析变更内容

Read through every changed file. Build a mental model of:
  • What behavior changed and why
  • What assumptions are baked into the new code
  • Where things could break under unexpected input or load
  • How the changes affect API contracts, data models, and data flows
  • Security surface area introduced or altered
  • Performance characteristics that shifted
  • How the changes ripple into other parts of the system
通读所有被修改的文件，构建如下认知模型：
  • 哪些行为发生了变化，以及变更原因
  • 新代码中隐含了哪些假设前提
  • 在意外输入或负载情况下，哪些地方可能出现故障
  • 变更如何影响API契约、数据模型及数据流
  • 引入或改变了哪些安全风险面
  • 性能特征发生了哪些变化
  • 变更如何影响系统的其他部分

3. Generate the Quiz

3. 生成测验题目

Produce 5-10 questions that test genuine understanding, not surface recall. Each question should:
  • Target a specific dimension (behavior, assumptions, failure, edge cases, API design, data model, data flow, security, performance, or dependencies)
  • Require reasoning about the code, not just restating what changed
  • Be answerable from the diff alone — no trick questions
Label each question with its dimension in brackets, e.g. 
[Failure Points]
.
Present questions one at a time using AskUserQuestion. Provide 3-4 multiple choice options per question when possible. For questions that require free-form reasoning, use open-ended format.
生成5-10道能测试用户真实理解程度的题目，而非仅考察表面记忆。每道题需满足：
  • 针对特定维度（行为、假设前提、故障点、边缘情况、API设计、数据模型、数据流、安全、性能或依赖）
  • 要求用户对代码进行推理，而非仅陈述变更内容
  • 仅通过代码差异即可作答——无陷阱题
在每道题前标注其所属维度，例如
[故障点]
。 使用AskUserQuestion工具逐个呈现题目。尽可能为每道题提供3-4个选择题选项；对于需要自由推理的题目，采用开放式提问形式。

4. Evaluate Answers

4. 评估答案

After each answer, respond with:
  • Correct or Incorrect
  • A brief explanation referencing the relevant code
  • The file and line range where the answer lives
Track the running score as the quiz progresses.
用户作答后，需反馈以下内容：
  • 正确或错误
  • 结合相关代码的简短解释
  • 答案对应的文件及行号范围
在测验过程中跟踪实时得分。

5. Report Results

5. 报告结果

After all questions, present a summary:
  • Overall score (e.g. 7/10)
  • Comprehension breakdown by dimension (which areas were strong, which had gaps)
  • For any missed questions, a focused explanation of what the user should review
  • Suggest specific files or sections to re-read for any weak areas
所有题目完成后，呈现总结内容：
  • 总分（例如：7/10）
  • 各维度的理解情况（哪些领域掌握较好，哪些存在盲区）
  • 针对答错的题目，给出重点解释，说明用户需要回顾的内容
  • 针对薄弱环节，建议用户重新阅读特定文件或章节

Common Mistakes

常见误区

  • Don't ask trivia questions. "What line number was changed?" tests nothing. Every question should require the user to reason about consequences.
  • Don't reveal answers in the question. Avoid leading phrasing that gives away the correct option.
  • Don't skip the diff analysis. Read every changed file before generating questions. Shallow analysis produces shallow questions.
  • Don't overwhelm with questions. Stay in the 5-10 range. Quality over quantity.
  • Don't grade harshly on wording. If the user demonstrates understanding with different terminology, mark it correct.
  • 勿提 trivia 类问题：“哪一行代码被修改了？”这类问题毫无意义。所有题目都应要求用户推理变更的影响。
  • 勿在题目中泄露答案：避免使用会暗示正确选项的引导性措辞。
  • 勿跳过代码差异分析：在生成题目前，务必通读所有被修改的文件。浅层次的分析只会产生质量低下的题目。
  • 勿用过多题目 overwhelm 用户：题目数量控制在5-10道，重质不重量。
  • 勿因措辞严苛扣分：若用户使用不同术语但能证明其理解了内容，应判定为正确。