wantsong
/
video-workbench
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: 完成 video workbench 重构案例库

This commit is contained in:
wantsong 2026-06-23 08:46:13 +08:00
parent c7e208a99e
commit 822b7456fe
6 changed files with 390 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
README.md
View File

@ -34,6 +34,8 @@ projects/
s02/
handoff/
docs/
cases/
investigations/
garden-gpt-image-2/
requirements/
@ -47,6 +49,7 @@ ccpe-consumption/
- `projects/<project>/visual-system/visual-system.md` records the current accepted visual system, materialization targets, iteration log, failure attribution, and next action. Reference images and iteration artifacts stay under `refs/` and `iterations/`.
- `projects/<project>/slides/` is the working area for slide, page, or shot execution. Each `sNN/` folder keeps that unit's prompts, narration, generated images, audio, and local notes together. Files inside `sNN/` must carry the `sNN` prefix, and iteration files use `sNN-vN-type.ext`, such as `s03-v1-prompt.md`.
- `handoff/` is for repo-level, cross-project, or context-window handoff notes.
- `docs/cases/` is the Codex-side local case-pattern library extracted from old real GPT cases. It preserves execution patterns, not old prompts, JSON packages, paths, or global text-rendering rules.
- `investigations/` is for research reports, experiments, comparisons, and draft workflow proposals. It replaces `tmp/` for durable investigation evidence.
- `garden-gpt-image-2/` is reserved for local image-generation prompt/workflow traces when that tool path is used.

2
VIDEO_WORKBENCH.md
View File

@ -40,6 +40,8 @@ projects/
Use root-level `handoff/` for repository-level, cross-project, series-level, or context-window handoff notes.
Use `docs/cases/` for Codex-side local case patterns extracted from old real GPT cases. These documents preserve reusable structure, granularity, asset layering, speaker-note style, and review dimensions. They do not restore old GPT final prompts, Codex JSON execution packages, output paths, or global text-rendering rules.
Do not split projects into `active`, `completed`, `abandoned`, `series`, or `standalone` folders. Status and series membership belong in project files because both can change during real production.
If a series needs more structure, create `projects/_series/` when the first real series needs it.

65
docs/cases/README.md Normal file
View File

@ -0,0 +1,65 @@
# Video Workbench Case Pattern Library
This directory is the local case-pattern library for Codex execution work in Video Workbench.
It is extracted from old GPT case files only at the level of structure, granularity, page or storyboard method, speaker-note style, visual asset layering, and review dimensions. It is not a prompt library and not a copy of the old GPT knowledge base.
## Source Basis
The first two patterns were localized from:
- `knowledge-vault/prompts/GPT/强哥的策划导演/30_CASE_典型视频分镜案例.md`
- `knowledge-vault/prompts/GPT/强哥的策划导演/31_CASE_典型培训AI_PPT案例.md`
Those source files remain historical GPT assets in Knowledge Vault. Video Workbench uses the extracted patterns below as Codex-side local execution guidance.
## Cases
| case | use when | local output focus |
| --- | --- | --- |
| [science-video-page-style-case.md](science-video-page-style-case.md) | Turning a deep article, model point, or public-facing concern into a PPT-style science video | Shot/page granularity, narration pacing, visual metaphor, review criteria |
| [training-ai-ppt-case.md](training-ai-ppt-case.md) | Turning AI education, method training, product enablement, or workshop content into a teachable slide deck | Teaching unit design, speaker notes, interaction, editable slide structure |
## Local Use
Use these cases after GPT V2 stage 0-5 planning has been accepted into a project `intake/` directory. Codex then converts the accepted planning into:
- `project.md` for project map and current focus;
- `execution-plan.md` for execution strategy, batch, round, and next decision;
- `visual-system/visual-system.md` for visual-system materialization and review;
- `slides/slides.md` and `slides/sNN/` for page or shot execution facts and assets.
## What To Extract
Extract these parts from old or future real cases:
- medium branch and audience;
- logic-to-page or logic-to-shot decomposition;
- page or shot function;
- one-unit-one-purpose granularity;
- editable page text vs visual asset vs narration or speaker notes;
- visual-system anchors and reusable motifs;
- review dimensions and acceptance criteria;
- batch/iteration advice.
## What Not To Inherit
Do not inherit these legacy assumptions:
- GPT outputs final image prompts.
- GPT outputs Codex JSON execution packages.
- GPT specifies local output paths, task lists, or generation parameters.
- the old assumption that every image prompt must forbid readable text.
- old source filenames or schemas become current Video Workbench contracts.
For current Video Workbench, text placement is an execution decision. Body copy is usually rendered in the editable PPT or video page layer; image-generated labels, formulas, diagrams, or text are allowed only when the execution plan and review criteria explicitly require that layer.
## Review Dimensions
When adding a new case pattern, check:
- Does the pattern state which medium branch it serves?
- Does it describe unit granularity without copying a full old case?
- Does it separate source logic, page or shot copy, visual assets, and narration/speaker notes?
- Does it provide review criteria that Codex can apply during small-batch iteration?
- Does it avoid old Prompt, JSON, path, and global text-rendering rules?

156
docs/cases/science-video-page-style-case.md Normal file
View File

@ -0,0 +1,156 @@
# Science Video Page-Style Case Pattern
This pattern is for PPT-style science videos: a deep article or model is reduced into a short public-facing video made of page-like shots, narration, and visual assets.
It is extracted from the old `30_CASE` video storyboard 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 3-10 minute public-facing science, cognition, AI, product-thinking, or method-explainer video;
- a PPT-style video with page/shot images plus narration;
- a video that explains a mechanism, risk, contradiction, method, or model through metaphors and staged visual pages;
- not a drama short, not a full video-editing workflow, and not a character-continuity MV.
## Core Pattern
```text
source point
-> public-facing concern
-> controlling metaphor
-> video outline
-> shot/page list
-> shot/page deep spec
-> narration
-> visual asset brief
-> review and iteration
```
The case value is not the original topic. The reusable method is "page-style explanation": each shot behaves like a compact visual argument, not like a literal filmed scene.
## Granularity
Default unit size:
- 6-10 units for a short explainer;
- 25-70 seconds per unit;
- about 90-260 Chinese characters per unit;
- one unit carries one logic function;
- one high-density method unit may be longer, but it still needs one clear governing frame.
Common unit functions:
| function | purpose |
| --- | --- |
| hook | create urgency or recognisable public concern |
| story anchor | give the viewer a concrete person, situation, or conflict |
| controlling metaphor | make the whole mechanism memorable |
| mechanism reveal | explain the hidden process or failure mode |
| practical frame | turn the concept into methods, checks, or choices |
| closing elevation | return to the larger judgment or changed mental model |
## Local Unit 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 |
| `source_anchor` | source paragraph, GPT V2 stage-5 row, or accepted intake note |
| `narrative_function` | hook, story anchor, metaphor, mechanism, method, or closing |
| `core_message` | one sentence the viewer should retain |
| `page_copy` | short overlay text or subtitle-layer copy, if needed |
| `voiceover_intent` | what narration must explain beyond page copy |
| `visual_task` | what the visual asset must make visible |
| `asset_layers` | background, metaphor object, human element, diagram, overlay, audio |
| `continuity_link` | how this unit connects to the previous and next unit |
| `review_focus` | the two or three things to inspect first in iteration |
This is a local execution spec, not a final image prompt. Final prompt files remain Codex-owned `sNN-vN-prompt.md` artifacts when image generation is actually performed.
## Page And Asset Layering
Separate layers before prompting or generating images:
| layer | owns |
| --- | --- |
| source logic | the concept, contradiction, risk, or method from accepted input |
| page text | the few words that may be rendered by PPT/video page layer |
| visual asset | metaphor scene, background, figures, diagram base, mood, composition |
| narration | full explanation, transition, examples, and punchline |
| review notes | whether the visual asset really carries the logic |
Do not treat "image contains no readable text" as a global rule. Decide per unit:
- If text must be editable or frequently revised, keep it in the PPT/video page layer.
- If labels, formulas, UI snippets, or diagram words are essential to the visual explanation, allow them only with explicit review criteria.
- If the image model is likely to garble precise wording, keep precise wording outside the generated image.
## Shot/Page Design Method
For each unit, answer in this order:
1. What is the viewer supposed to understand or feel at this moment?
2. What is the simplest visible metaphor or situation that makes it concrete?
3. What page text is useful, if any?
4. What must narration explain that the image should not carry alone?
5. Which part of the unit is high risk: logic, metaphor, composition, text placement, or visual generation?
6. What would make the unit fail review?
The visual should not decorate the narration. It should do at least one of these jobs:
- compress an abstract mechanism;
- expose a contradiction;
- make a risk feel real;
- separate similar concepts;
- hold attention while narration explains a dense idea;
- signal a transition in the argument.
## Review Dimensions
Review generated or drafted units against these dimensions:
| dimension | pass condition |
| --- | --- |
| logic clarity | one unit maps to one clear logic point |
| metaphor fit | the metaphor explains the point instead of becoming a side joke |
| public accessibility | a non-specialist can understand the visible situation |
| narration fit | voiceover adds explanation, not redundant caption reading |
| composition | image leaves safe space for page text if page text is planned |
| asset feasibility | the image can be generated or assembled without fragile exact text |
| continuity | the unit advances from the previous one and sets up the next one |
| medium fit | it remains a science/explainer page, not an accidental drama scene |
## Small-Batch Strategy
Do not generate every unit first. Pick representative high-risk units:
- one hook or opening unit;
- one controlling-metaphor unit;
- one mechanism-explanation unit;
- one practical-method or dense information unit;
- one closing or elevation unit when tone is uncertain.
Record the selected batch in `execution-plan.md`, then track unit-level facts in `slides/slides.md`.
## Abstracted Example Shape
```md
## s03 Unit Spec
- narrative_function: controlling metaphor
- core_message: The tool is useful only when matched to the weight of the real-world problem.
- page_copy: two short lines, rendered outside the generated image unless the execution plan says otherwise
- voiceover_intent: contrast everyday low-risk use with high-stakes decision use
- visual_task: make the mismatch between lightweight confidence and large external risk visible
- asset_layers:
- background: large-scale risk environment
- metaphor object: small helpful tool that looks insufficient at scale
- human element: ordinary user facing the environment
- overlay: optional page text layer
- review_focus:
- risk scale is obvious
- metaphor does not become comic noise
- composition supports 16:9 page use
```

162
docs/cases/training-ai-ppt-case.md Normal file
View File

@ -0,0 +1,162 @@
# 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
```

2
docs/context-handoff.md
View File

@ -59,6 +59,8 @@ projects/<project-id>/
Use root `handoff/` for repo-level, cross-project, series-level, or context-window handoff notes.
Use `docs/cases/` as the local Codex case-pattern library. It is allowed to extract structure, page or shot granularity, speaker-note style, visual asset layering, and review dimensions from old GPT cases, but it must not re-import old final-prompt, Codex JSON, output-path, or global text-rendering rules.
## Project Files
`project.md` is a Codex-maintained small note. It should link to intake files and key local execution files instead of duplicating the outline, storyboard, page design, or execution plan.