163 lines
6.7 KiB
Markdown
163 lines
6.7 KiB
Markdown
# Training AI PPT Case Pattern
|
|
|
|
This pattern is for training, AI education, customer enablement, internal workshops, and method lectures that need a teachable slide deck.
|
|
|
|
It is extracted from the old `31_CASE` training AI PPT case. The original topic, prompts, Codex JSON, output paths, and global text prohibitions are not carried forward.
|
|
|
|
## Use When
|
|
|
|
Use this pattern when the target is:
|
|
|
|
- a training deck, course deck, lecture deck, workshop deck, or AI education PPT;
|
|
- a slide sequence that must support live explanation, pause, discussion, and later reuse;
|
|
- a deck where each page is a teaching unit, not a video shot;
|
|
- not a customer proposal whose primary goal is decision conversion.
|
|
|
|
## Core Difference
|
|
|
|
Training PPT pages are not scenes. They are teachable units.
|
|
|
|
Each page should answer:
|
|
|
|
- What should the learner understand after this page?
|
|
- What misconception or resistance might exist before this page?
|
|
- What example, analogy, contrast, diagram, or exercise lowers the learning barrier?
|
|
- What can the learner do, judge, or remember after this page?
|
|
|
|
## Learning Path
|
|
|
|
Common sequence:
|
|
|
|
```text
|
|
problem entry
|
|
-> concept or model
|
|
-> method frame
|
|
-> example or contrast
|
|
-> practice or migration
|
|
-> summary and action
|
|
```
|
|
|
|
Not every deck needs all six parts, but the page order should behave like a learning path rather than a list of impressive points.
|
|
|
|
## Page Granularity
|
|
|
|
Default rule:
|
|
|
|
- one page solves one teaching goal;
|
|
- slide copy stays sparse and editable;
|
|
- speaker notes carry explanation, examples, and transition;
|
|
- interaction is included when the page benefits from learner reflection;
|
|
- abstract models need a diagram, matrix, loop, ladder, map, or other visible structure.
|
|
|
|
Avoid one page trying to explain a concept, prove a case, give a method, run an exercise, and conclude the section at the same time.
|
|
|
|
## Local Page Spec
|
|
|
|
For Video Workbench, put this in `slides/sNN/sNN-unit-spec.md` or use it as the basis for that file:
|
|
|
|
| field | purpose |
|
|
| --- | --- |
|
|
| `unit_id` | `sNN` identifier used by local files |
|
|
| `slide_role` | opening, concept, model, contrast, case, practice, summary, transition |
|
|
| `teaching_goal` | what the learner should understand, change, or be able to do |
|
|
| `core_message` | one sentence that gives the page its point |
|
|
| `slide_copy` | editable title, subtitle, bullets, labels, or quoted line |
|
|
| `layout` | comparison, triangle, matrix, timeline, loop, ladder, map, flow, dashboard |
|
|
| `visual_asset_brief` | background, metaphor, concept visual, diagram base, or scene asset |
|
|
| `speaker_notes` | how the instructor explains the page |
|
|
| `interaction` | question, quick vote, reflection, mini exercise, or none |
|
|
| `transition` | how this page connects to adjacent pages |
|
|
| `review_focus` | what Codex should inspect during iteration |
|
|
|
|
This is a local execution spec, not a final image prompt or JSON execution package.
|
|
|
|
## Slide And Asset Layering
|
|
|
|
Keep these layers separate:
|
|
|
|
| layer | owns |
|
|
| --- | --- |
|
|
| editable slide text | titles, subtitles, bullet points, labels, formulas, exact wording |
|
|
| layout | structure that controls learner attention |
|
|
| visual asset | background, metaphor scene, illustration, diagram base, icons, texture |
|
|
| speaker notes | explanation, example, pacing, transition, instructor emphasis |
|
|
| interaction | question or exercise that turns listening into retrieval or judgment |
|
|
|
|
Generated images should not be asked to carry precise deck body copy by default. If the design needs diagram labels or visible text inside an image, document that choice in `execution-plan.md` or the unit review criteria.
|
|
|
|
## Speaker Notes Style
|
|
|
|
Speaker notes should do three jobs:
|
|
|
|
- explain the key concept in plain language;
|
|
- give a concrete life, classroom, business, or product example;
|
|
- bridge to the next page.
|
|
|
|
Good notes are not page copy repeated aloud. They let the slide stay sparse while still giving the instructor enough material to speak for 1-2 minutes when needed.
|
|
|
|
## Common Page Patterns
|
|
|
|
| pattern | use when | layout hint |
|
|
| --- | --- | --- |
|
|
| structural problem | establish why the topic matters | triangle, tension map, before/after |
|
|
| misconception correction | replace a shallow belief with a better frame | split screen, false/true contrast |
|
|
| model introduction | name and explain a reusable model | matrix, loop, layered diagram |
|
|
| method frame | turn concept into steps or checks | flow, ladder, checklist, flywheel |
|
|
| case comparison | show how AI changes a task or judgment | traditional vs AI-enabled |
|
|
| practice page | make learners apply the frame | prompt, scenario, quick exercise |
|
|
| summary chain | close the logic path | timeline, chain, staircase, map |
|
|
|
|
"Traditional vs AI-enabled" is especially useful for AI training case pages, but it is a pattern choice, not a global rule.
|
|
|
|
## Review Dimensions
|
|
|
|
Review drafted or generated pages against these dimensions:
|
|
|
|
| dimension | pass condition |
|
|
| --- | --- |
|
|
| teaching goal | one page has one clear learner outcome |
|
|
| copy density | slide text is sparse enough to scan and edit |
|
|
| layout clarity | structure helps understanding rather than decorating the page |
|
|
| speaker notes | notes explain, exemplify, and transition |
|
|
| asset layering | visual assets do not replace editable slide text by accident |
|
|
| interaction | any question or exercise has a clear teaching reason |
|
|
| sequence | the page advances the learning path |
|
|
| live usability | an instructor can pause on the page and teach from it |
|
|
|
|
## Small-Batch Strategy
|
|
|
|
Do not build the full deck visually before validating the teaching system. Pick representative pages:
|
|
|
|
- one opening or problem page;
|
|
- one abstract model page;
|
|
- one method-frame page;
|
|
- one case-comparison page;
|
|
- one practice or summary page if interaction or closing tone is uncertain.
|
|
|
|
Record the selected batch in `execution-plan.md`, then track page-level status in `slides/slides.md`.
|
|
|
|
## Abstracted Example Shape
|
|
|
|
```md
|
|
## s08 Unit Spec
|
|
|
|
- slide_role: model introduction
|
|
- teaching_goal: Learners understand that the model is a decision aid, not a decorative framework.
|
|
- core_message: A usable model changes what people can notice, compare, and improve.
|
|
- slide_copy:
|
|
- title: short model name
|
|
- subtitle: one-line use claim
|
|
- bullets: three editable labels or dimensions
|
|
- layout: center matrix with one highlighted region
|
|
- visual_asset_brief: clean diagram base with subtle learning-path motion; exact labels remain editable in the slide layer
|
|
- speaker_notes:
|
|
- define the model in plain language
|
|
- give one concrete classroom or work example
|
|
- explain why the next page moves from model to use case
|
|
- interaction: ask learners which dimension they currently under-observe
|
|
- review_focus:
|
|
- model structure is legible
|
|
- page is not crowded
|
|
- notes can support live explanation
|
|
```
|