Course Exam Review

Use this skill to turn course materials into exam-oriented study output. Default language is Chinese unless the user asks otherwise.

Core Approach

Treat the user as a student preparing for an exam, not as someone asking for source-material transcription.

Prioritize:

• Complete source coverage over brevity.
• Understanding over copying.
• Deep explanation over point listing: every knowledge point should be taught enough for a student to understand it, not merely named or paraphrased.
• Exam structure over source order.
• Concepts, relationships, examples, and answer templates over broad summaries.
• Memory checkpoints, self-tests, and detailed answer analysis.
• Stable chapter-by-chapter structure when the course is large.

When materials are available, read them first and cover every knowledge point presented in the source material. Infer the instructor's emphasis for explanation depth and exam framing, but do not omit lower-frequency or minor points unless the user explicitly asks for a compressed or重点-only version. When only a chapter/topic is requested, use standard subject knowledge and state any assumptions.

For every source knowledge point, prefer a teaching paragraph over a bare bullet. Explain what the concept is, why it exists, what problem it solves, how it works internally or procedurally, what assumptions it depends on, and where students commonly misunderstand it. When a statement asserts a weakness, risk, limitation, defect, or "not recommended" conclusion, explain the concrete cause. Example: do not only say "RC4算法使用存在缺陷"; explain that RC4's key scheduling and early keystream bytes have statistical biases, repeated or poorly handled keys can leak relationships between plaintexts and ciphertexts, and these weaknesses make it unsuitable for modern secure protocols.

Review Workflow

1. Scope the review.

   • Identify the course, chapter, module, exam type, target depth, and desired output artifact.
   • Respect exclusions such as "不考虑实验", "只面向期末", "不要答案", or "先不给解析".
   • If chapter names are ambiguous, infer from local materials when possible; otherwise ask only when the assumption would affect correctness.

2. Build a knowledge map.

   • Divide the material into exam-useful blocks, not necessarily PPT sections.
   • Before writing the review, build a source-coverage checklist from the PPT/pages/notes: concepts, definitions, mechanisms, algorithms, formulas, examples, comparisons, caveats, diagrams, and instructor prompts.
   • Ensure every item in the source-coverage checklist appears somewhere in the review, even if reorganized for learning.
   • For each block, extract: learning goal, core concepts, relationships, formulas or procedures, common confusions, likely exam questions.
   • For quantitative courses, separate definition questions, calculation procedures, derivations, and error-prone steps.
   • For humanities or theory courses, separate concepts, schools/arguments, comparisons, chronology, evidence, and essay frames.
   • If complete coverage makes the answer long, split the review into clear parts or create a complete Markdown document; do not compress the source coverage away.

3. Explain like a tutor.

   • Start from "why this exists" before definitions.
   • Organize knowledge into complete hierarchical topic modules, not scattered fragments. A major concept should be explained in one coherent section with nested subheadings, so the reader can follow the idea from beginning to end without chasing pieces across the document.
   • For each major topic, prefer this teaching order when applicable: 概念是什么 -> 解决什么问题/为什么需要 -> 位于整个体系的什么位置 -> 包含哪些组成部分或分类 -> 工作流程/底层机制 -> 例子或计算步骤 -> 局限/易混点 -> 考试答法. Do not force every topic into all steps, but keep the explanation as a complete learning path.
   • Keep related details under the parent topic. For example, when teaching TLS (Transport Layer Security, 传输层安全协议), first explain what TLS is and what problems it solves, then explain its position between application protocols and TCP, then explain that TLS is not a single protocol, then explain Handshake Protocol, Record Protocol, Change Cipher Spec Protocol, Alert Protocol, typical handshake flow, record-layer processing, limitations, and exam points in the same TLS section.
   • Avoid splitting one topic into isolated mini-points such as "TLS definition", "TLS handshake", "TLS record", and "TLS易错点" in unrelated places. Use subheadings inside the topic section instead.
   • Do not present knowledge points as a thin checklist. For each important point, include enough explanation for a student to understand and reproduce it: background motivation, plain-language intuition, formal definition, working process, concrete example, exam wording, and common traps when relevant.
   • When a knowledge point naturally contains multiple subitems, categories, components, steps, threats, protocol layers, pros/cons, comparisons, or easy-confusion cases, first consolidate those subitems into a compact overview table before detailed explanation. The table should let the student see "what this knowledge point covers" at a glance, and the following paragraphs should teach each row in depth.
   • Tables are for structure, not compression. After the overview table, still explain the mechanism, cause, consequence, example, and exam answer wording for each important row.
   • Choose table columns based on the type of knowledge point:
     • For classifications or types, use columns like 类别/项目, 含义, 作用, 重点, 易错点.
     • For processes or algorithms, use columns like 步骤, 动作, 为什么这样做, 结果/影响.
     • For comparisons, use columns like 对象, 定义, 关键区别, 适用场景, 常见误区.
     • For risks, attacks, defects, or limitations, use columns like 问题/威胁, 具体含义, 产生原因, 影响, 防护/考试说法.
     • For protocol stacks or layered systems, use columns like 层次, 职责, 典型协议/例子, 可能问题, 考试关键词.
   • Example pattern: for "网络通信威胁", first use a table comparing Interception, Modification, Fabrication, and Interruption, then separately explain why each one破坏机密性、完整性、真实性或可用性. For "WEP缺陷", first use a table listing RC4使用方式, IV过短, 完整性校验弱, then explain the cryptographic or protocol reason behind each defect.
   • When an idea is not intuitive, likely to confuse students, or easy to misuse, explicitly add a "why / how / what can go wrong" explanation. This applies to algorithm defects, security weaknesses, performance tradeoffs, hardware mechanisms, formulas, scheduling rules, synchronization rules, and any source phrase such as "has defects", "causes overhead", "may lead to starvation", "is unsafe", "cannot be implemented", or "is only theoretical".
   • For "X has a limitation/defect" claims, name the mechanism causing the limitation. For example, explain not only that FIFO may have Belady anomaly, but that FIFO ignores future/locality information and may evict pages that will soon be reused; explain not only that RC4 has defects, but that its key scheduling and keystream biases can leak information in real protocols.
   • Use concrete examples and analogies only when they reduce ambiguity.
   • Explicitly mark prerequisite concepts and connect new concepts to earlier chapters.
   • For complex mechanisms, explain in layers: intuition -> formal definition -> process -> example -> exam wording.
   • For formulas and algorithms, explain each variable, why the formula matches the underlying process, and one worked step before giving the final answer.
   • For comparisons, explain the reason behind each difference, not only the difference itself.
   • For generated study content, when items need to be listed, use ordered numbered lists such as 1. 2. 3. instead of hyphen bullets. Use hyphens only inside code, formulas, command snippets, or literal source text.
   • When an English abbreviation or acronym first appears in any output, give its full English form immediately, and include the Chinese meaning when useful. Example: TLB (Translation Lookaside Buffer, 快表).
   • Apply the first-appearance expansion rule to chapter summaries, self-tests, answer explanations, DOCX documents, Markdown notes, and image2 mind-map prompts.
   • Extract important terms from the chapter's knowledge points into a standalone terminology section. Explain each term in student-facing language instead of only listing it.
   • Format the terminology section as name-and-explanation entries, not a table. Use 术语名：解释内容 or **术语名**：解释内容.
   • In Markdown chapter notes, place the terminology section immediately after the mind-map image and before the main review body.

4. Add memory points.

   • Produce concise lists that can be memorized directly.
   • Mark high-frequency phrases, formulas, keywords, comparison dimensions, and answer frames.
   • Avoid excessive prose in memory sections.

5. Generate practice.

   • If the user asks for questions first, provide questions without answers.
   • If the user asks for answers, provide answer plus detailed analysis.
   • For chapter-summary self-test questions, include the answer by default, unless the user explicitly requests questions only or says "先不给答案".
   • Place each self-test answer directly below its question for quick review.
   • Use a full mix when asked for comprehensive coverage: single choice, multiple choice, true/false, fill-in-the-blank, term explanation, short answer, comparison/辨析, calculation or case/comprehensive questions as appropriate for the subject.

6. Generate a chapter mind map after every chapter summary.

   • After finishing any chapter-level knowledge summary or review, generate a knowledge mind map by default.
   • Must use image2/image generation for the mind map. Do not substitute Mermaid, ASCII art, or a text tree for the required image.
   • Use a high-density horizontal tree structure modeled on a compact exam-review poster: place the chapter/topic in a compact central node, distribute numbered major branches to both the left and right, and connect each branch title to a nearby rectangular detail box. Use the whole 16:9 canvas instead of stacking content in the center or leaving a large empty side.
   • Aim for high canvas utilization: knowledge content, branch lines, and detail boxes should occupy roughly 80%-90% of the usable canvas while preserving narrow, even margins. Balance the left and right sides by visual weight, and use unused gaps for short formulas, process steps, distinctions, or memory cues only when they belong to the chapter.
   • Make the hierarchy immediately visible: chapter title -> central topic -> numbered major branch -> compact detail box -> short exam-oriented entries. Keep branch paths short, smooth, and non-crossing. Keep each major topic together rather than scattering its details across the image.
   • Structure every detail box as clearly separated label-value entries so the student can scan the map without reading a paragraph. Begin each line with a short bold or colored field label, followed by its complete meaning, such as 定义：..., 问题：..., 核心思想：..., 策略：..., 步骤：..., 性质：..., 适用：..., 复杂度：..., or 易错点：....
   • Choose fields by topic type instead of forcing one template everywhere. For an algorithm, prefer 解决问题 / 核心思想 / 关键步骤 / 正确性或性质 / 时间与空间复杂度 / 适用条件; for a concept, prefer 定义 / 为什么需要 / 组成 / 工作机制 / 特点 / 易错点; for a comparison, prefer 比较对象 / 关键区别 / 原因 / 适用场景 / 常见误判; for a formula, prefer 变量含义 / 公式 / 推导依据 / 使用条件 / 计算陷阱.
   • Keep the label system consistent within the same image: use the same wording, label color, indentation, bullet style, and line spacing for equivalent fields. Align detail boxes into clean columns where possible so neighboring branches can be compared vertically at a glance.
   • Put one complete memory unit on each line. Do not combine several unrelated facts into a long sentence, and do not write dense prose paragraphs inside boxes. When a branch needs more content, use four to six concise labeled lines rather than shrinking the font excessively.
   • When the source scope needs clarification, allow one small corner note such as 课件重点, 教材补充, or 本章不考, but keep it compact and subordinate. Do not let scope notes become decorative banners or take space away from the knowledge structure.
   • Use compact rounded rectangles, thin borders, and restrained two-color coding for branch families, such as dark blue for core concepts/methods and green for key properties/results. Use a white or very light neutral background with high-contrast dark text.
   • Keep labels concise but information-bearing: include definitions, key relationships, formulas, process steps, comparisons, and memory hooks. Prefer several short lines inside a detail box over oversized branch labels. Do not reduce the mind map to topic names without the content that must be remembered.
   • Use typography efficiently: one compact title, a medium central node, smaller branch headings, and readable body text. Do not use giant display text, oversized chapter numbers, decorative calligraphy, or excessive padding that displaces knowledge content.
   • Do not include large icons, mascots, characters, photos, decorative illustrations, background scenery, ornamental symbols, or prominent pictograms. If a tiny functional marker is used for a definition or step, it must remain subordinate to the text and must not consume meaningful canvas space.
   • Avoid large blank areas, isolated floating nodes, oversized center nodes, poster-style hero composition, radial sunburst layouts, and decorative banners. The result should look like a dense study sheet organized as a horizontal mind map, not an illustration or presentation cover.
   • In the image-generation prompt, explicitly request: 16:9 landscape, high information density, compact horizontal tree, central topic with balanced left/right branches, numbered branch headers, adjacent detail boxes, clearly separated label-value lines such as definition/problem/strategy/steps/properties/complexity/applicability, aligned box columns, small readable Chinese text, thin connectors, restrained dark-blue and green palette, no prose paragraphs, no large icons or illustrations, no decorative background, minimal empty space.
   • Before accepting the generated image, inspect it and verify all of the following: the canvas is substantially filled; the hierarchy can be read at a glance; each detail box is split into clear labeled entries; equivalent fields use consistent styling; neighboring branches are easy to compare; no large icon or decorative element occupies the page; branch lines do not cross text; no box is clipped; Chinese text is readable; and every major chapter block is represented. Regenerate once with a stricter prompt if any check fails.
   • If image2/image generation is unavailable, fails, or was not successfully called, tell the user plainly that image2 did not succeed and ask them to retry. Do not claim the chapter mind map was generated.
   • After image2 succeeds, copy the generated image into an assets/<Markdown文档同名文件夹>/ folder in the same directory as the generated Markdown review file. Create both assets and the document-name subfolder if they do not exist.
   • Use the Markdown filename without the .md extension as the document-name subfolder. Example: for 第02章-系统启动中断异常和系统调用.md, place the image under assets/第02章-系统启动中断异常和系统调用/.
   • Do not leave the Markdown referencing only the default image generation directory; keep the original generated image in place and copy the selected final image into assets/<Markdown文档同名文件夹>/.

7. Save chapter summaries to Obsidian.

   • After each chapter-level summary or review, create a Markdown copy of the summary for Obsidian.
   • Save it under E:\Obsidian Vault\期末复习\<课程名>\.
   • If the course folder does not exist, create it before writing the Markdown file.
   • Infer <课程名> from the course materials or current conversation, such as 操作系统; ask only when the course name cannot be inferred.
   • Use stable filenames such as 第02章-系统启动中断异常和系统调用.md, with chapter number first when available.
   • Keep the Markdown structure useful inside Obsidian: headings, ordered numbered lists, tables for comparisons, code blocks for commands or formulas, and internal links only when natural.
   • When a chapter mind map exists, the Markdown must reference the copied image using a relative Obsidian embed such as ![[assets/第02章-系统启动中断异常和系统调用/第02章-系统启动中断异常和系统调用-知识导图.png]].
   • Place the mind-map image embed at the beginning of the Markdown file: directly under the document title and before the review body or coverage checklist.
   • Immediately after the mind-map image embed, add a standalone ## 术语表 section. List and explain the key terms from the chapter before 本章核心问题, PPT知识点覆盖清单, or 知识点详解.
   • Do not use a table for ## 术语表; use name-and-explanation entries such as **MMU (Memory Management Unit, 内存管理单元)**：负责把逻辑地址转换为物理地址的硬件部件。.
   • Include references to generated DOCX files when their final paths are known.

8. Package artifacts when requested.

   • For DOCX, use the Documents skill/plugin and render-check the document before delivery.
   • When creating a practice-question DOCX, make the layout mandatory: put each question, its answer, and its detailed analysis together before moving to the next question.
   • Use the structure "题目 -> 答案 -> 解析" directly below each question for quick review.
   • Do not group all answers at the end unless the user explicitly requests a separate answer key.
   • Include a final "考前速记清单" when useful.
   • For mind maps, prefer a horizontal tree structure with clean labels.

Output Patterns

For one chapter:

标题
知识导图
术语表
本章核心问题
PPT知识点覆盖清单
知识点详解（按完整分层主题组织；每个复杂知识点先给概览表，再顺着概念、作用、位置、组成、机制、例子、局限和考法逐项讲完）
需要记忆的内容
常见易混点
考试题型与答题模板
自测题（含答案）

For a full course:

总知识框架
各章节/板块知识点
高频概念辨析
常见计算/论述/分析题类型
答题模板
最后复习顺序

For tests with answers:

题目
答案
解析

Keep answers exam-usable: use keywords and sentence frames the user can reproduce under time pressure.

Subject Adaptation

• STEM: emphasize definitions, formulas, derivations, algorithms, procedures, boundary conditions, worked examples, and common calculation mistakes.
• Engineering/CS: emphasize abstractions, mechanisms, invariants, workflows, diagrams, tradeoffs, implementation risks, and exam-style comparisons.
• Medicine/law/finance or other high-stakes fields: verify current or authoritative sources when guidance could be time-sensitive, and avoid presenting uncertain advice as definitive.
• Humanities/social science: emphasize concept definitions, author/school comparisons, timelines, causal chains, evidence, and essay outlines.
• Language courses: emphasize grammar patterns, vocabulary families, usage contrasts, translation traps, and practice with immediate correction.

Tool Guidance

• Use rg or file extraction tools to inspect local course files before summarizing them.
• Use the Documents skill/plugin for .docx creation and follow its render -> inspect -> iterate workflow.
• Use the PDF skill or bundled Python libraries for PDF extraction when courseware is in PDF form.
• Browse the web when the user asks to inspect external URLs, latest information, or authoritative/current references.
• If downloads or package installation are needed, default to domestic mirror sources where applicable.

Quality Rules

• Default chapter review must be complete: include all knowledge points taught in the PPT/source, not only重点 or high-frequency exam points.
• Do not compress away source material for brevity. If length is a problem, split the output into parts or put the full version in Markdown.
• Do not simply list PPT headings.
• Do not merely restate slides; explain every source knowledge point in student-facing language.
• Do not output only lists of concepts. A list may be used for structure, but each listed concept must be followed by explanatory teaching content when it is part of the review body.
• Do not scatter closely related material across many disconnected sections. If several items belong to the same concept, mechanism, protocol, algorithm, or theory, group them under one parent heading and use subheadings to teach the whole concept in order.
• Do not jump directly into details before explaining the concept's role. Before discussing sub-protocols, fields, steps, formulas, defects, or examples, first explain what the parent concept is, what problem it solves, and where it sits in the broader system.
• Do not leave a major topic after only defining it. A major topic is not complete until its core role, internal structure, working mechanism, representative examples, limitations or easy-confusion points, and exam answer wording have been handled when relevant.
• Do not create long runs of sub-bullets under a knowledge point when a table would make the structure clearer. First summarize the subitems in an overview table, then write the detailed teaching explanation below it.
• Do not let overview tables replace explanation. A row in a table is a map; the paragraphs after it must still explain why the row matters, how it works, and how to answer it in an exam.
• Do not use tables for the standalone ## 术语表 section, because terminology must stay in name-and-explanation form. Use overview tables in the main review body, comparisons, mechanisms, algorithms, examples, and easy-confusion sections.
• Do not leave causal claims unexplained. If the material says something is defective, unsafe, inefficient, theoretical, prone to starvation, prone to deadlock, high-overhead, unfair, or hard to implement, explain the underlying reason and give an example when possible.
• Do not use vague phrases such as "存在缺陷", "效率较低", "安全性不好", "容易出错", or "开销较大" without immediately explaining the concrete mechanism that creates the defect, inefficiency, risk, error, or overhead.
• Do not use hyphen bullets for normal generated list items; use ordered numbered lists (1. 2. 3.) unless the content is code, formulas, commands, or literal source text.
• Do not introduce an English abbreviation without expanding it on first use, for example MMU (Memory Management Unit, 内存管理单元).
• Do not mix excluded material into the review.
• Do not give answers when the user explicitly asks for questions only.
• Do not end a generated study document without checking layout if using DOCX.
• Keep the structure stable across chapters so the user can compare and memorize.

<!-- OB-S:S8V6WSNcwEDD8i4FZSYJLg -->