Deep Video Explanations
Transforms a topic into an explanation process that strangers are willing to start, can follow, feel is worth it after watching, and can retell. The default audience has general life experience, no relevant professional background, and has not yet decided to spend time learning. First, build interest, then gradually explain; adjust the background when the user explicitly specifies a professional audience. By default, organize visuals using the specified reference white-background isometric engineering animation, explaining mechanisms through continuous changes of concrete objects. Maintain original models and scripts; referencing style does not mean copying original assets, logos, or sounds.
Invocation and Scope
Use deep-video to deeply explain the thin-film lithium niobate industry: Complete research, script, storyboard, voiceover, animation, final video, and checks.Use deep-video portrait version to deeply explain solid-state batteries for WeChat Video, Douyin, and Xiaohongshu: Reorganize the storyboard in 9:16 format and deliver a single set of portrait videos for all three platforms.Use deep-video to improve this video: First read the specified video and available scripts, projects, identify issues, then complete the user's requested modifications; preserve the original video.Use deep-video to explain backside power delivery, only the script and storyboard: Deliver only the specified materials, then finish.Use deep-video to diagnose this video, do not modify it yet: Output a diagnosis with timestamps and specific modification actions.
Extract the topic and constraints from the context; if the topic is missing and cannot be inferred, only ask for the topic. Do not ask for information the user has already provided. Make ordinary production choices independently, without staged approvals. By default, produce one set of Chinese videos; when portrait is chosen, produce one set shared across three platforms. Do not automatically add platform-specific versions, horizontal-vertical dual versions, graphic content, marketing plans, or upload/publishing.
A regular "explain" or "deep explanation" request does not itself imply a video; only enter this flow when the user explicitly invokes this skill, asks for a video, or the current task is already determined to be video production.
Aspect Ratio Options
Landscape: 16:9, 1920×1080; if unspecified and no aspect ratio has been selected in the context, keep the existing default.Portrait: 9:16, 1080×1920, default 30 fps; for a shared master used on WeChat Video, Douyin, and Xiaohongshu.- User's explicit selection takes priority, followed by carrying over the aspect ratio already determined for the current task. For new tasks that only specify the above mobile platforms without specifying an aspect ratio, select portrait and briefly explain this choice. Merely mentioning a platform or adding a specification option does not imply a request to redo an existing video.
Record orientation, width, height, and fps in the creative card and rendering configuration. Before designing for portrait, read portrait-format.md and re-layout for mobile reading and interface occlusion; style and aspect ratio are independent options. Produce dual versions only when the user requests them; research and matching voice assets can be reused, but check the layout and timeline for each version separately.
0. First Build a Reason to Watch
For new productions, scripts, and dissemination improvement tasks, first read audience-design.md. For only fixing encoding, subtitle typos, or other local issues, handle them directly without redoing the entire video's narrative.
Check from first principles: What can the audience recognize? Why would they want to know the result? How much cognitive cost do they have to pay? Do they feel it's worth it after getting the answer? These are content design questions, not scoring formulas for recommendation algorithms. Expand the accessible audience while preserving the real mechanisms and key conditions; do not pursue a fictional "everyone will like it."
Preserve the user's selected topic. Within the same topic, compare 2-3 different entry points. For each, record the corresponding familiar phenomenon, who it attracts, the first visible result, the explanation cost, and evidence; choose one to complete production. This is a limited editorial comparison, not predicting a hit or increasing the number of video versions. For topics that are genuinely niche, build interest using visible phenomena, real scales, or specific choices; do not forcibly graft everyday losses, trending topics, or fear.
Create a short creative card: core audience and potential expansion groups, core question, one main takeaway, one optional surprise or aesthetic experience, main title and cover concept, first answer, and how the ending delivers. When account data is not provided, audience judgment is an editorial hypothesis.
Altruism review mandatory: Clearly state "who, in what context, after watching can explain, judge, or do what," and mark the delivery position in the body. Check each paragraph for new understanding gained and its use; return to the core question at the end and clearly conclude the main takeaway. Having lots of information, many terms, or claiming "pure dry goods" does not constitute passing criteria. Perform the specific check according to audience-design.md.
1. Research and Core Question
First, determine a one-sentence core question, a demonstrable phenomenon, and a learning objective. The learning objective must be specific about which causal relationship the audience can explain, for example, "Explain why polarization rotation can block returning light and why temperature changes affect isolator performance."
Support technology, company, and industry facts with currently verifiable primary sources; record the source, date, key conclusions, and applicable conditions. Distinguish between source facts, company claims, inferences, and unknowns. For theoretical topics, preserve theoretical boundaries; for industry topics, distinguish between experiments, samples, customer validation, mass production, and delivery. Label assumptions for calculations; do not write parameter examples as product specifications.
Conditions for entering the script: The core question is clear; the opening phenomenon can be identified without requiring academic terminology first; the key mechanism has a basis; the title, cover, and body content promise are consistent; any content pending verification has been removed, qualified, or marked. Do not fabricate accidents, prices, market share, or monopolistic positions to create conflict.
2. Organize the Script with Questions
5-second hook must be checked: Time compliance and appeal are judged separately; even if the first sentence is short, it must point out a specific object, contradiction, or judgment puzzle that a stranger audience can see. Time from the first frame of the final video; even if the audience hasn't seen the title and cover, they should recognize the topic object within 5 seconds and get a complete, worthwhile question or visible contrast. Check completion time against the final voiceover and visuals; do not use estimated word count as a substitute for actual measurement. If time is overrun, first delete preambles and shorten sentences; do not force-fit by continuing to speed up. When only delivering a script, mark the estimated duration; do not claim it has passed actual measurement.
Immediately after the hook, deliver a small answer or visible evidence. Within about the first 30 seconds, explain what the audience will gain by continuing to watch. Prioritize delivering a usable small judgment or visible evidence within about the first 15 seconds; do not delay the first gain with classifications, definitions, and table of contents. The ~15-second mark is an editorial pre-check point, not a platform threshold; introduce necessary background at a minimal dosage as problems arise. The opening should go directly into the phenomenon and action; do not use a table of contents, long titles, or historical background to postpone the highlight. The promises made in the title and opening must be fulfilled in the body.
Check the title, cover, and opening visuals individually; do not use brilliant content from later sections to defend the beginning. Write down what a stranger audience member expects to see at this moment, and why they stay or leave; if the reason relies on knowledge from later parts, redo the entry. This is an editorial pre-check; do not pretend to be a real user test.
For industry topics, prioritize the progression of "real problem → key mechanism → engineering limits → manufacturing difficulties → cost and customer value." For theoretical topics, use the progression "observable phenomenon → core concept → mechanism or experiment → explanation boundary → application." Adjust according to the topic; do not force in industry, company, or business chapters.
When suitable to use a case throughout, let the same object, project, or experiment undergo changes sequentially, avoiding rebuilding context for each section; mark real cases, hypothetical cases, and comparison situations separately. Before merging existing examples, unify assumptions, units, and measurement conventions; do not combine them into a fake real case. When theory or phenomena are not suitable for a single case, preserve necessary comparisons; do not force in a business case study.
Each paragraph should bear only one main explanation task, naturally introduced by the result of the previous paragraph. First present the phenomenon or object, then introduce terminology. When needed, use a natural question to lead to the next step, but provide the answer immediately; do not expect the audience to pause and answer.
Record, paragraph by paragraph, the audience's question upon entry, the new understanding they actually gain, the most likely point where they get stuck, and the next question. First answer a small question, then lead to a deeper question; mark the delivery position for any unresolved promises. Drive the narrative using real constraints, failed attempts, scale changes, and result comparisons; do not rely on repeatedly shouting "more astonishingly" or holding back answers to delay.
Layer the difficulty: intuitive phenomenon → a model sufficient to explain → necessary conditions and limitations. For each core new concept introduced, ground it with an action, example, or causal sentence. Analogies must return to the real object, pointing out necessary correspondences and boundaries. Regulate the pace with visible understanding, discoveries, and aesthetic experiences; do not turn the entire video into a uniformly dense lecture.
For industry explanations, be clear about how physical requirements affect processes, yield, failures, customer costs, or delivery consistency. Companies should only appear when they help explain a specific difference; a list of names does not represent ranking.
Use short sentences, clear subjects, stable terminology, and concrete verbs to implement the user-requested ASD-STE100-style controlled expression. Chinese does not claim compliance with the formal English standard. Delete repetitive summaries, vague transitions, and irrelevant knowledge; retain necessary conditions and understanding pauses. Duration is determined by the explanation; do not pad by fixed chapter numbers or uniform paragraph lengths.
The ending returns to the opening phenomenon, reinterprets it using the model just built, and delivers a conditional, retellable explanation. By default, adopt an outreach-style popular science closing: summarize the key causal relationships, limiting conditions, or one new observation worth noting; do not include think-questions, answer pauses, quizzes, or "think about it first" segments. Only add exercises when the user explicitly requests instructive interaction. Content that promises to help with judgment or action should also leave behind directly usable questions, record fields, or operational methods; aesthetic or phenomenon-understanding content should deliver through retellable explanations and new observations; do not force a checklist. Reasons to share, save, or follow come from genuine takeaways; do not use induced interaction or unfulfilled sequels as a substitute for a conclusion.
3. Turn the Script into a Continuous Storyboard
The default visual style is B: 'White Background Isometric Engineering Style' , with the user-specified reference being henryz's "How Large Models Run on GPUs"; do not generalize to the author's entire body of work. Before production, read visual-style.md along with its reference observations and storyboard rules. The main object, spatial layering, action relationships, typography, and color scheme must collectively achieve the reference style; changing only the background or color scheme is insufficient.
This is an update from the previous default warm editorial style. Use the reference warm-editorial-style.md when the user explicitly requests a warm-toned version; preserve the original style when only partially modifying an old video. Tasks that only update rules should not cause old videos to be remade. When the user gives new style instructions in the future, prioritize the new instructions.
The default style does not use chapter-specific serif large titles, stage labels, full-width color block subtitle strips, or regularly arranged rounded rect description cards. The main subject occupies the majority of the frame; short labels follow the components; bottom subtitles are visually separated from graphics using thin dividing lines. Layout remains centered; aspect ratio is independently chosen; portrait mode is rearranged for mobile specifications. The Yunxi 1.5x speed, 5-second hook, and altruism requirements are retained.
Do not mark the production method: Do not include production method labels like "AI-assisted production," "AI-generated," "synthetic voiceover," "TTS," "AI voice," etc., in the final video visuals, subtitles, cover, or end credits; also do not keep such small text permanently at the bottom. If old scripts or templates contain such text, delete it. If a declaration is needed for platform publishing, the publisher handles it in the platform backend; it does not go into the video visuals.
For each shot, specify: the audience's current question, the voiceover, the initial visual, the changes that occur, the conclusion the audience should understand, where they might get stuck, and the duration or voiceover trigger point. Estimate duration first; calibrate with the actual audio after the voiceover is generated.
Prioritize having the same object continuously undergo movement, rotation, decomposition, superposition, scaling, sectioning, and parameter changes. Establish traceable zoom-in/out relationships between the overall system and key components. Keep colors, spatial directions, and symbol meanings consistent; when changing viewpoints, coordinates, or scales, give a clear indication.
When involving quantitative changes, losses, or multi-stage systems, read mechanism-animation.md: preserve a comparison baseline, explain the relationships between variables, and establish the correspondence between equipment location and function.
Each change should answer a question. Light point cycles, fades, and zooms can assist guidance but cannot replace mechanism demonstration. Perform a check on mechanism shots with explanatory text removed: the viewer should still be able to observe how the object changes and why the result occurs. Merely moving words like "danger," "background," "reveal" or highlighting process boxes does not constitute having demonstrated the corresponding plot or production process; instead, use specific actions, material states, spatial relationships, or clear data changes.
When a composition is held for a relatively long time, check whether new causal information is presented during that time; if not, reorganize the content; if there are complex changes that require observation, preserve the time. Do not set mechanical switching cycles for all shots.
Each frame should have only one main visual center; highlight the object currently being discussed. Long titles, subtitles, annotations, and subtitles should not compete for attention simultaneously. Expand formulas according to "phenomenon → variables → relationships → illustrative example or parameter change." Briefly label assumptions, exaggerated scales, and non-realistic structures on the relevant frames.
Conditions for entering batch production: For the default style, first complete a short sample video containing an overall view, a local detail, and a mechanism action; check it against visual-style.md for acceptance; text rule updates cannot replace the sample video. Verify that each shot can explain "where to look, what changes, what it shows"; the opening has delivered a result; the core mechanism and cross-segment transitions have a clear demonstration. For paragraphs that can only be read as full-screen text, first rewrite them.
In the working materials, mark the first actual answer, key discoveries, the point of highest cognitive load, and the delivery point at the ending. Identify and modify segments that are continuously abstract or where the audience waits too long for an answer. First check with rough animations and voiceover before investing in fine rendering; seconds, transition frequency, and emotional curve are not used as universal traffic metrics.
4. Produce Voiceover and Animation
When actually generating the final video, read production-and-qa.md and execute the audio, timeline, and final video acceptance processes described therein. When only producing a script or diagnosis, you do not need to load production details.
First check existing projects and available runtime environments; reuse suitable tools and animation assets. If an old project only has 2D text boxes and page transitions, you must add isometric structures, object states, and continuous shot capabilities before it can be used for the default style; do not lower the locked style requirements for the sake of reuse. Do not treat the absolute path of a project on the current machine as a necessary dependency of the skill. You may use Manim, Remotion, or other tools capable of continuous geometry demonstration; choose based on actual demonstration capability; do not rewrite a mature workflow just to switch technologies.
By default, use the free Edge TTS voice Yunxi zh-CN-YunxiNeural at 1.5x the normal speaking speed, directly written into the final video; follow the user's request if they explicitly specify another voice or speed. First produce a short sample voice containing terms, numbers, questions, and conclusions, then batch generate the rest. Adjust speed and rebuild subtitles and animation timelines using the unified method in production-and-qa.md, preserving necessary pauses for understanding. On service failure, retry with limited attempts and reuse matching caches; if it still fails, report the specific obstacle and continue with work that can be done independently; without explicit user specification, do not switch to local or other voices. For small tasks like fixing only subtitles, do not re-voice existing videos as a consequence.
Output one complete video set according to the chosen aspect ratio: landscape 1920×1080, portrait 1080×1920, default 30 fps; other resolutions and frame rates follow user requirements and motion clarity. The renderer must read the aspect ratio configuration and apply the corresponding layout; it cannot simply swap width and height. Keep text and graphics editable; do not simply upscale low-resolution old videos as a "clarity upgrade."
5. Delivery and Status
Complete production delivers one set of final videos, Chinese subtitle files, script and sources, one main title, and one shared cover, along with a brief summary of check results. The title and cover are the entry points to the same work, not multi-platform versions; when the user wants only a video, use their scope as the basis. When modifying an existing video, save a new version to avoid overwriting the original. Other delivery modes only deliver the output specified by the user.
Report fact checks, technical checks, dynamic viewing checks, and subjective audio-visual checks separately. Passing screenshots of frames, decodability, and volume level does not prove complete viewing or listening checks have passed. When capabilities are insufficient, specifically describe the incomplete checks and their impact; do not use proxy indicators to claim passing. After fixing discovered issues, re-check the corresponding segments.
The core acceptance criteria are: Does the entry give a specific reason to watch? Does the body continuously deliver on its promises? Is the mechanism understandable? Does the ending leave a retellable takeaway? Number of chapters, duration, number of animations, and model self-scores are not proof of quality or dissemination effect.
Check records must include: aspect ratio, resolution, and frame rate; a small preview and occlusion pre-check for portrait mode on mobile phones (platform real preview is recorded separately); voice and speed settings; actual spoken audio/visuals within 5 seconds and hook completion time; the timestamp in the main body where the main takeaway is presented and the ending conclusion point. Check results must indicate "Pass, Needs modification, Not checked" along with the basis. Passing the 5-second compliance and altruism editorial review does not prove retention or learning effect.
Only read the reference recommendation-evidence.md when the user provides publishing data, requests traffic review, or asks about algorithms. Use data from the same source for problem diagnosis; prioritize modifying one main variable at a time. Without data, only report content-side judgments, do not predict view counts, diagnose throttling, or promise "most people will like it."