每一条都来自一次真实的反馈：策划者的评价、观众的评论，或制作中摔过的跟头。它们写成对所有片子都成立的规则，让下一部片子不再犯同样的错。质量标准 讲成片要达到什么样子，这里讲最容易在哪里失手、怎样查。
- 开工前读这一阶段的几条。
node kit/tools/lessons.js show --stage <阶段>（例如--stage script、--stage design）只打印这一阶段的规则。不必通读全表。 - 交付前逐条下结论。 每部片子在
review/lessons.json里给每条规则写一个结论：pass（附证据：成片的语言、时段、怎么查的）、n/a（附理由）或open（已知未解决，交付时写进 README「交付」）。pending表示还没考虑过，check.js --final不放行。 - 规则变了，在制的片子跟着变。 新增规则或某条的要求改变时（
rev加一），运行node kit/tools/lessons.js <视频> sync，变化的几条回到pending。只改措辞不影响已有结论。 - 已发布的片子不返工。 新规则用在以后的片子上；旧片的问题记在它自己的 README「评价与复盘」里，作为对照。
- 记原话。 策划者的评价、评论区的意见，原样记进 反馈记录，编上 P（策划者）或 C（评论）号，写明日期、哪部片子、哪个时刻。同时在那部片子 README 的「评价与复盘」里引用编号。
- 找原因。 在成片上定位问题（时刻、帧、源码行），分清是叙事、画面、声音还是流程的问题。
- 提炼成通用的话。 先看能不能并进已有的一条（改写它、
rev加一）；确实是新问题，才新增一条。规则里不写片名，片名放进「案例」。 - 能查的做进工具。 能用工具查的（例如片尾是否配音、文字的可读时长、样式是否雷同），做成检查，在规则的
auto里注明。 - 改
docs/lessons.json，运行node kit/tools/lessons.js render重新生成下面的规则表；npm run check:repo核对规则、文档与反馈记录的编号一致。
当前版本 2026-11-10.1，共 29 条。
开工先写下观众看完能回答的一个问题，以及每章怎样推进它。标题、开头、每章、结尾回答的是同一个问题；相关但回答别的问题的段落删去或另立选题。定长短片的每一场都直接回答片名的问题。先通读连贯文案，确认解释与章节推进成立，再铺开视听制作；形式和自动检查通过不能代替内容质量。
- 为什么：材料可靠不等于该放进来；版本清单、历史与实现参数挤掉主线时，观众不知道在看什么。
- 怎样查：先通读文案，复述主问题、解释路径与结论，指出跳步和无关内容；再在成片上标出提出问题、各章推进、结尾回答的时刻。README 记清取舍与未解决的问题，每一段说得出它为什么留在这里。
- 也用于：文案、验收
- 案例：正面 myisam、postgresql；反面 lean4、openclaw-opencode-v2、openclaw-hermes、web-login
- 来源：P0、P5、P21、P33、P53、C10、C13（见 反馈记录）
用同一个具体例子走完机制：每一步交代输入、变化、原因和结果。讲多层系统时先建立整体结构与输入输出，再定位并展开局部，局部细节始终能回到全程中的位置；取证同时保留结构关系与一次操作的完整路径，不能只留内部字段。先讲清概念，再给术语、历史和数字。先定本片引入几个新名词，超出就删；每个术语第一次出现就用一句话讲清它是什么、为什么需要。难点先分到足够的时间，再安排包装与转场。
- 为什么：「有例子」不等于讲清楚；名词堆叠、概念跳跃时，观众跟不上。局部拆得再深，缺少整体结构和部件之间的关系，仍解释不了系统怎样工作。
- 怎样查：正常速度从输入跟到输出，每一步的原因都在画面或旁白里；列出全片新名词与它们的解释句。取证可还原整体结构与一条完整操作路径；文案与画面里的每个局部都说得出它位于整体哪里、负责哪一步。每个页号、编号第一次出现时，画面演出它从哪来：哪一页的哪一项指过来、按什么比较选中，不让它凭空跳到下一步。
- 也用于：文案、设计、验收
- 案例：正面 myisam、two-factor-auth；反面 lean4、innodb、postgresql、firebird、web-login、openclaw-hermes、openclaw-opencode-v2
- 来源：P9、P17、P18、P34、P50、C10、C11、P80、P118（见 反馈记录）
演示数据与终端回显从源头就用干净的环境和通用路径，不把真实的个人目录、主机名、凭据、内网信息带进素材；脱敏在数据源做，不在画面上遮。
- 为什么：曾有成片的终端画面露出个人目录。
- 怎样查：逐屏核对最终 MP4、字幕、封面与说明文字里的路径、用户名与地址。
- 也用于：实现、验收
- 案例：正面 luainstaller
策划者的意见、观众原话、作者自评、制作者推断分开记录，各带日期与出处。涉及事实的异议回到本片 FACTS 核查后再下结论；工具通过不等于观感通过。
- 为什么：把一条评论当成共识、把推断当成事实，都会让后面的修改走偏。
- 怎样查：反馈记录逐条有来源类别与定位；技术异议有核查结论或「未核」。
- 也用于：发布与反馈
名称、版本、比较对象和适用条件在第一次出现时说清。做比较时，两边共享同一个任务与同一套口径；说「更早」「更快」时说出和什么比。图注写含义：一串原始格式（例如快照的「最早进行中:下一个号:进行中列表」）不直接上屏，写成一句话；画面上的编号、数字写明是谁的。
- 为什么：口径交代晚了，观众先形成错误印象，后面的纠正很难追回来。
- 怎样查：逐个核对名称与比较第一次出现时的旁白、画面和结论；译文保留限制条件。
- 案例：反面 wsl、dense-vs-moe、postgresql
- 来源：P4、C5、C6、C7、C8、C14、P106（见 反馈记录）
每一集只靠它自己就能看懂：直接提出本章的问题，必要的背景在本片补齐；不要求观众记得前一集，不用「上一期第几个问题」导航。
需要观众读懂的外文标题、引文和术语，在画面上给出准确的中文释义；长材料移出主画面，只留支撑论点的那一句。
讲观众不熟悉的对象，先从熟悉的情境引入：它是什么、什么年代、当时解决什么问题、为什么值得看，再给本片的路线。新旧对照固定具体的版本与任务，不用今天的数据倒推过去。讲人造出来的东西，交代是谁、在什么处境下做出来的、当时要解决的难处，留一两个有趣的细节；篇幅服从本片主线。
- 为什么：一上来就讲系统内部，多数观众不知道对象是什么、为什么要看。
- 怎样查：第一次观看的人能复述对象、年代和本片要走的路线。
- 案例：反面 opencart-1-5-admin
- 来源：P22、P110（见 反馈记录）
文案只包含会被说出的话。署名、模型分工、开源链接只在画面上展示；片尾用无旁白的静默 cue（空字幕、pause、credits: true）保留时长。「片尾显示……」这类制作指令不写进文案。
- 为什么：片尾被配过音，制作说明被混进过文案。
- 怎样查：导出的校对稿里没有制作指令；成片片尾没有人声，名单完整可读。（工具：script-review.js 检查片尾 cue 无旁白）
- 也用于：实现
- 案例：反面 opencart-1-5-admin
- 来源：P12、P23（见 反馈记录）
画面和旁白只放观众需要的内容。不写说明制作取舍、脱敏、默认处理的话（如「只列常量名，不列值」「示意 · 按源码分支构造」），不反复提「本实验」「日志显示」；不展示的东西直接不展示。数据来源一行署名即可；口径限定只在会造成误解时，用一句自然的话放进正文。
- 为什么：这类话一看就是模型写的，正常人做视频不会提默认的事。
- 怎样查：逐屏列出说明性的小字与旁白，问一句「正常人做视频会不会写这句」，不会就删。
- 也用于：实现
- 案例：反面 opencart-1-5-admin、innodb
- 来源：P8、P25（见 反馈记录）
制作方对成片负责，也就对文案负责，不机械照搬已确认的稿。每次加句、删句、改章节之后通读整章：数字与画面、章节卡与旁白、前后的称呼是否一致（例：加了一个问题，「四个问题」要跟着改成「五个」）。发现错误或更好的讲法就主动改，改动写进 review/NOTES.md；改了含义的，交校对者确认后再配音。
- 为什么：MyISAM 第 4 稿加了「改和删」，这一章实际讲五个问题，章节卡和旁白仍写「四个」，制作方照着配了音、做了画面，直到策划者指出「指五为四」。策划者随后要求：「你有很大的自由权，有能力，可以主动的修改文案，而不是傻傻的遵循。」
- 怎样查：对照 review/NOTES.md 与当前 script.js：改句之后是否通读过整章？章节卡、数字、列举的个数与画面是否一致？制作中发现的文案问题是主动改的，还是等人指出的？
- 也用于：配音、实现
- 来源：P73（见 反馈记录）
每个新概念按这个顺序进场：先说观众会碰到的问题（「要按名字找 Alice，总不能把 47 页从头翻到尾」），再在贯穿的例子上演一次，最后才给名字和一句话的定义（「这叫……」）。概念第一次讲清时就选定一个说法和一个画法，后面各章沿用同一个（例：xmin 到 xmax 是一段可见范围，xmax 为 0 就一直延续下去；之后的查询、修改、并发、删除、回绕都用这条范围讲）。不提前用到后面才讲的东西（还没讲 VACUUM 就说「这一笔由 VACUUM 来记」）；两个相似的参数默认值不同，就点明是两样东西（「索引默认 90；表也有自己的，默认 100」），不让观众以为前后矛盾；不同实验测得的数（三个不同的事务号）不并列上屏当成同一件事。内容不删，宁可多一句铺垫。
- 为什么：PostgreSQL 一集 r7、r8：概念一个接一个，名字先于问题出现，前后说法打架，策划者看到 9 分钟就看不下去——「那么快那么多概念观众怎么跟得上」「不要假设观众比如看着xmin xmax就知道是事务可见性范围」「前面说默认90后面又默认装满」「不能让观众出现"疑问"的情绪」。按本条重写第 3 稿后：「粗看整体叙事好太多了, 一开始就应该这样的」。
- 怎样查：列出全片的新名词：每个都写出引出它的问题句、演示它的例子、给它起名的句子，三者依次出现；搜索每个名词第一次出现的位置，不早于讲清它的那一句；同名参数、同一个数字在各章说法一致。以只看过前几集的观众把文案通读一遍，标出每一处会冒出「这是什么」「为什么」的地方并改掉。
- 也用于：验收
- 案例：正面 myisam、postgresql
- 来源：P86、P87、P88、P93（见 反馈记录）
列出专名、多音字、数字和长句的试听清单，逐个确认读法；停顿按语义安排，字幕怎么切不决定口播怎么停。多音字逐个用耳朵核对：Whisper 回听会把同一个字的不同读音转成同一个字（cháng、zhǎng 都是「长」），查不出读音错。通用的读法替换（例如把数据的「行」换成同音的「航」）加进读法表之后，把全稿被替换的地方逐个列出来核对，排除表要列全。
- 为什么：成片里出现过读错与断句错，ASR 没有全部筛出来；「再长一层」读成了 cháng，回听的文本仍是「长」。
- 怎样查：逐句听实际音轨；ASR 只用来筛候选，读错与断句的判断以人耳为准，听不到的如实写明。中文稿对着交审稿的「多音字清单」逐条听，已由 SAY 表或 tts 改写的也听。（工具：asr.js 筛查候选；script-review.js 导出稿列出多音字清单（供人耳核对，不是闸门））
- 案例：反面 innodb、postgresql
- 来源：P14、P20、P81、P94、P105（见 反馈记录）
合成全片之前，用包含专名、长句、列举和解释句的代表段试听候选音色与语速：句子有起伏，强调处有重音，长句不被念成一串平读，讲解有往前推的感觉。音色气质贴合对象的年代与定位。音色记录里标为停用的不再选。代表段的试听交策划者确认。
- 为什么：读得对不等于读得好，「懒洋洋」的语气与不合适的音色都被直接否定过。
- 怎样查：成片后连续试听开头、难点段与章间；响度、语速数值和 ASR 都不检查语气。
- 案例：正面 postgresql；反面 tmux、opencart-1-5-admin、web-login
- 来源：P13、P29、P38（见 反馈记录）
先收集讲解对象自己的视觉材料（标志、官网样式表的颜色与字体、官方文档的部件、真实界面），以这些语汇作图，画面上有一个常驻的身份标识。随便截一帧，不看字幕也认得出在讲什么。比对时看官方页面实际渲染出来的样子（截图并排），版式、字重、部件与插图的画法都算，不只读样式表里的颜色。
- 为什么：通用的「科技感」版式换个主题也能用，等于没有设计。
- 怎样查：从成片任取几帧，不看字幕判断能否认出对象；列出每种颜色、字体、部件取自哪份官方材料。并排放一张官方页面的截图比对。
- 案例：正面 postgresql、luainstaller；反面 myisam、innodb
- 来源：P7、P28、P30、P109（见 反馈记录）
每一章都有一个以讲解对象为主角、说得出名字的主画面，尺度、层次与动作共同承载本章的解释，让人看完记得住。逐行出现、高亮、淡入可以用于引导注意，但不能代替该章需要讲清的结构、过程或关系；不靠镜头晃动、特效堆叠或元素数量充数。
- 为什么：主画面需要完成解释任务；只陈列标签或只追求冲击力，都会让观众记不住内容。
- 怎样查：连续观看每章，说出主画面表达了什么、观众如何从中理解结构或变化；图形与动作未承担解释任务时记为未通过。以实际理解效果判断，不以动作种类和数量打分。
- 也用于：实现、预览迭代、验收
- 案例：反面 postgresql
- 来源：P31、P53（见 反馈记录）
画面上的每个图形都说得出它服务于哪一段解释、表达哪个对象或关系，说不出就删；不要求一句旁白换一个画面（F22）。不用几何姿态（倾倒、旋转、堆叠、漂移）代替因果，不画空框或抽象块充数；只靠旁边标签才读懂的图形没有完成它的工作。声明过的形状与颜色语义全片不换用；图形在被讲到时已经在场。图形的几何与它代表的结构一致：指针指到对象的起点，长度从起点长出；连线从框上离开，不沿着框线走；看起来应当一样的东西真的一样，不一样的地方画出来并写明。
- 为什么：旁白在讲因果的地方，画面在做形状的表演。
- 怎样查：逐屏列出图形服务的解释与对应关系，指不出的改；核对同一形状、同一颜色有没有中途换义。结合完整段落判断，不机械要求逐句换屏。
- 也用于：实现
- 案例：反面 web-login、postgresql
- 来源：P39、P49、P53、P95、P103（见 反馈记录）
视觉系统、配乐和讲法为这一部重新建立：不沿用上一部或系列起点的配色、部件与曲子，不把别的片子的做法当成默认。系列只共享系列说明里写明的约定（标题格式、时长规则、常驻元素的位置等），其余每集按自己的对象设计。想复用另一部片子的好做法，先把它提炼进 kit/ 或 docs/，再从那里取用。
- 为什么：同一套纸色底、平涂版式和 120 拍秒针配乐反复出现，片子之间难以区分；任务书照搬系列风格，与策划者的要求冲突过。
- 怎样查：与近期两部片子并排看关键帧、并排听开头：说得出这一部的视觉和声音取自哪里、和它们有什么不同。（工具：check.js 提示样式表或配乐脚本与起点模板、其他片子完全相同）
- 也用于：声音
- 案例：正面 postgresql
- 来源：P3、P7、C2（见 反馈记录）
旁白是讲解的节奏，画面是这一段要传达的内容，两者要对得上，但不要求一句一画面，画面也不能被旁白锁死：旁白说到的才有、没说到的就空着，不合格。每个新名词、每个关键结构第一次出现时，画面上要有它的注解：是什么、指画面上哪一块、数字或出处；注解补旁白没说的，不等旁白，也不复述字幕（F25）。文案里用星号标出的术语，注解元素带 data-gloss。一组并列的对象（例如同一类的一批状态码、同一组可选部件）可以先成组摆出来，再只把正在讲的那几个高亮、推进或取出，其余留在画面上作背景；不必为了「配合这一句话」把画面切成一个个碎片。也不要把每样东西都钉在一个词上：逐词弹出、到下一段就收走，画面跟着字一下一下跳，停不住、读不完，看起来被旁白锁死。词的时刻用来对齐指认和关键动作；进场可以成组、提前，讲完的东西留够时间再走（F04）。画面上可以有旁白没提的元素与注解，前提是它服务于这一段，不另起一条讲解主线。反过来仍受 F20 约束：画面上的每个元素都要说得出它服务于哪一段内容，不能出现与内容无关的装饰。
- 为什么：把画面绑死在旁白的每一句上，会把一组并列的东西拆成一堆碎片，观众失去「这是一类」的整体印象（《96 秒了解 HTTP 状态码》审稿）。只「允许」画面多给东西还不够：InnoDB 新版的画面只给旁白说到的词贴同名标签，新名词出现时观众不知道它是什么、指哪一块，策划者指出「被旁白过度绑定」「聚簇索引的出现也缺少注解」「回表 覆盖索引之类也缺乏解释脚注」。 Firebird 一集几乎每个元素都按词的时刻进场、按下一段的时刻退场，readable.js 报 38 处停留不足，策划者看成片说「锁的太死」。
- 怎样查：看每个场景：旁白是否被画面切成了一帧一个的碎片？一组并列的对象是否整组在场、只推进其中的几个？列出全片的新名词与关键结构，逐个看它第一次出现时画面上有没有注解（是什么、指哪一块、数字或出处），关掉声音能不能看出它指的是什么？scan.js 的 GLOSS 报出的缺注解逐条补上。画面上有没有与内容无关的元素？数一数一段里有多少元素的进场、退场都卡在词的时刻上；连续几句都是「一个词一个东西」的，改成成组进场、只推进其中几个。（工具：scan.js GLOSS（标星号的术语第一次出现时，data-gloss 注解在场））
- 也用于：实现、预览迭代、验收
- 案例：反面 innodb、firebird
- 来源：P49、P79、P119（见 反馈记录）
讲机制的段落，用随时间推进的动画演示过程本身：时间轴与播放头、数据在结构里移动、状态随时间累积和改变，旁白骑在动画上讲。先把动画设计成能自己「跑」起来的过程模型（例：表锁的时间轴上，读锁条随播放头生长、写锁在斜纹里排队、轮到时独占），旁白的时刻只用来对齐关键节点。不要先定稿文字、再给每一句配一张逐条出字、面板淡入的画面；文字出现、高亮、淡入只作引导，不能当作推进本身。
- 为什么：先出文稿、再按句配画面的做法，让后来的片子变得像 PPT，失去了灵动；策划者点名喜欢旧版 MyISAM 表锁的滚动动画。
- 怎样查：逐章看讲机制的段落：画面里有没有随时间连续推进的过程，而不是靠新文字、新面板出现来推进？关掉声音，能否从动画本身看出发生了什么？连续几屏只是文字与面板依次出现的，记为未通过。
- 也用于：实现、预览迭代、验收
- 案例：正面 myisam
- 来源：P64（见 反馈记录）
镜头为内容服务。每一次平移、推近、拉远都要说得出它让观众看清了什么；说不出的就不动。移动途中与停稳之后，这一刻正在讲的内容都完整在可读范围里，不被画面边缘、顶栏或字幕栏切掉，缓慢漂移的幅度也算在内。字幕条（画面下方 968–1080）里不放要看的东西，图形也算：人物的脚、房间的地面、车辆、底部的标签和引线都收在字幕条之上。大范围、频繁的镜头运动会把注意力从内容上拉走，能在原地换内容就不必穿越画布；强调可以靠颜色、方框、箭头和元素自己的动作。动几次、用什么手法，由各片按自己的设计决定。
- 为什么：MyISAM 新版第一轮照旧文档「每场至少三次镜头运动、推近 1.3–1.6 倍、边缘文字被切属正常」去做，策划者看片指出镜头动作太大、到处乱动、内容都没了，要求根治「镜头动来动去不管内容看不看得见」。
- 怎样查：按每句说完的时刻与每次镜头移动的中途，用 look.js 或总览图看：正在讲的内容是否完整在画内、没有压在字幕栏或顶栏下？scan.js 的 CUT、CAPZONE 提示逐条看过，正在讲的内容被切的已经改掉，保留的写了理由？以正常速度连续看，有没有哪一段镜头的动作比内容更抢眼？scan.js 的 CAPZONE 只查文字；图形有没有伸进字幕条、被字幕压住，逐帧看或列出外框越过 968 的元素。（工具：scan.js CUT、CAPZONE（只查文字）；图形伸进字幕条暂无工具（Firebird 一集用临时脚本查出房间地面压在字幕下，候选做进 scan.js））
- 也用于：实现、预览迭代、验收
- 案例：反面 firebird
- 来源：P70、P71、P72、P119（见 反馈记录）
画面是讲解对象本身，旁白是指着它讲的那根手指。一段开始时，讲解对象（文件、字节、结构、时间轴、终端回显）就带着真实内容在场，旁白讲到哪里就点亮、指出、推动哪里；不要先摆一排空框、讲到一个词才往里填一个字。字幕已经说出的话，画面上不再写一遍；画面上的字留给数据本身、要记住的术语名、轴标与图例。画面需要的事实（年份、版本、数值）在 FACTS 里没有时，去查证补进 FACTS 再画，不因为缺事实就把画面删空。信息量要适中：空到只剩一行字和堆到要暂停才看得完都不合格。
- 为什么：MyISAM 新版第一轮画面跟着文案一句一句出字：结构先是空框、讲到才填，版本轴删到只剩两个版本号、没有年份，不少说明把字幕又写了一遍。策划者指出「被文案捆的太死，太 PPT」「文字没有画面就没有」「连个年份都不会写」，同时提醒「也不要画面信息过于密集」。
- 怎样查：关掉声音和字幕连续看：每一段有没有讲解对象的实物在场？有没有一段画面只是空框或空白在等旁白？画面上的字有没有在复述字幕？用 sheets.js 每 3 秒一帧通看，空荡的帧与挤满的帧各记下来改掉。
- 也用于：实现、预览迭代、验收
- 来源：P76、P97、P102（见 反馈记录）
范本是 MyISAM 一集：一分钟里屏上一直是同一张 .MYD 字节表，先一长串，再原地折成每行 16 字节，标注一层层叠上去，一句旁白只在它身上推进一小步。每一章都是这样一个画面：讲解对象常驻、在原地变化（页摊成字节表，一行从表里升起来摊成十六进制）；不是「一句话变一下」，不是一页页换的面板。章内要换段时，至少带一样东西过去——上一段的结论飞成下一段的对象（两个版本飞成索引那一段的「堆里两个版本」，一页缩进堆里那一格、下一段再从那一格放大出来），两段共用的对象摆在同一位置、换段前就到位，交叉淡变时它不动不闪。指认用对象本身的高亮或选区（字节表上的选区随旁白滑过去），不用一个框在文字之间跳来跳去；暂时不讲的部分退淡，同屏的字少一半。章节之间仍用系列约定的整屏章节卡。
- 为什么：PostgreSQL 一集 r7、r8 每段一个面板、一个红框在字之间移动：「动画整体还是太PPT 各个文字打框动来动去看的眼花」「你还是做PPT的思路, 而不是视频, 最直接的就是画面缺乏连续性」「视频是运动的画面和语句的有机结合, 而不是PPT, 一句话 变一下」「最优先参考MyISAM」。r9 按本条重做后策划者认可。
- 怎样查：按章用 sheets.js 看总览：每章说得出常驻的主对象是什么、它在哪几步里变了；每一处章内换段说得出带过去的是哪一样东西，整屏内容全换、什么都没带过去的要改；找出在文字之间移动的框改成原地指认；同屏文字多的段落，确认暂时不讲的部分已退淡。
- 也用于：实现、预览迭代、验收
- 案例：正面 myisam、postgresql
- 来源：P89、P90、P91、P92、P93、P96（见 反馈记录）
先排信息，再排动作。关键状态（结论、对比、报错、章节卡）完整出现后，至少稳定「1.5 秒 + 必要文字字数 ÷ 5 字/秒」再退场；一步机制完成后，另留看懂这一步的时间，其间不引入新东西。关键信息不在一句旁白的最后半秒才出现；镜头推近时，要读的部分在画内。非定长的片子宁可长一点；定长的片子靠删内容腾时间，不压留白。
- 为什么：全仓库最普遍的问题：信息还没看完、还没看懂，画面就过去了。
- 怎样查：用 readable.js 量每个关键状态从全部到位到开始遮挡或退场的区间；再以正常速度连续观看全片，需要暂停才看得完、没看懂就换场的画面都算未通过。逐帧量达标不能代替连续观看。（工具：readable.js 测量完整可读区间）
- 也用于：预览迭代、验收
- 案例：反面 opencart-1-5-admin、innodb、web-login、openclaw-hermes、firebird
- 来源：P2、P15、P24、P26、P36、P37、P98、P119（见 反馈记录）
每个关键动作都在展示对象、因果、数据流或状态变化：同一对象的初态、触发、变化、结果依次可见。擦除、刷屏、整屏换面板只作必要的过渡。镜头只在站与站之间移动；停在一屏上时不缩放、不推近、不往复、不环绕，最多朝一个方向极慢地横移（参考：一屏合计不超过 48 像素、每秒不超过 2 像素；一章之内各屏朝同一个方向、换屏时随内容回位，相邻两章方向相反，不左右来回），章节卡停留时至多整张极慢推近一次（不超过 3%）。画面停着时让内容分步变化，不用镜头动作掩盖。
- 为什么：反复的擦入刷出和晃动的镜头制造了动静，却没有解释任何东西，还分散注意力。为了让静止检查过关而加的往复缩放、慢推也是一样：观众看到的是一直在动的镜头，画面上的内容其实停着。
- 怎样查：连续观看代表机制段，能看见前因后果；与近期两部片子的开头、换章、解释段并排比较，不只是换了颜色或方向。scan.js 的 ZOOM 报出的停留缩放与往复逐条改掉；章节卡与元素自己的慢推工具量不到，连续观看时核对。（工具：scan.js ZOOM（镜头画布在停留时的缩放与往复））
- 也用于：预览迭代、验收
- 案例：正面 two-factor-auth、myisam；反面 innodb
- 来源：P3、P6、P17、P78、P85（见 反馈记录）
按实际字宽排版：文字不超出所在色块，色块不越过别的框线；后到的元素不盖住正在讲的内容；画面的前后层次事先定好：底板、示意图、引线、标签、卡片各在哪一层，后加的底板、面板、引出框垫在它要承托的内容下面，不压住已经在场、还要讲的东西；两样东西要占同一块地方时，旧的先让开或退场；反色高亮不让底色与字色同时渐变；元素退场交代去向，不在刚到达时直接消失。渐变、飞入、落位、退场的中间帧都要成立。同一个元素的显隐要接得上：已经收起或压暗的元素不再用写定起点的淡出收一次（会先闪回原样再消失），成组收起时只收要走的那几样，没写出现时刻的元素不会从场景开头就挂在画面上。不用元素的缓慢漂移凑画面变化。
- 为什么：成片里出现过溢出、压盖、渐变途中字与底同色、元素突然消失。
- 怎样查：每个动作前后逐 0.1 秒取帧，专看中间状态；scan.js 只报连续多帧的重叠与对比度，过闸不算通过。比对时间线上每段不透明度补间的起点与上一段的终点，列出跳变；列出场景开头就可见、之后才收起的带字元素。按层次查一遍：每个后加的底板、面板、引出框、人群和道具，有没有盖住已在场的文字、标志和图形（逐帧看，或在文字与标志的采样点上用 elementFromPoint 查最上层是不是它自己）。（工具：scan.js 部分覆盖（OVERLAP、CONTRAST）；显隐跳变与「开场就在」暂无工具（PostgreSQL 一集用临时脚本读 GSAP 时间线比对，候选做进 scan.js）；文字与标志被图形盖住暂无工具（Firebird 一集用临时脚本在采样点上查最上层元素，候选做进 scan.js））
- 也用于：预览迭代、验收
- 案例：反面 postgresql、web-login、firebird
- 来源：P32、P35、P36、P99、P100、P101、P119（见 反馈记录）
自动检查只量得出能量化的东西。请人审片或交付之前，制作方自己以观众身份把全片完整过一遍：能看视频的按正常速度看；只能看图的用 sheets.js 每 3 秒一帧通看全片的总览图，再对可疑处用 look.js 看原图。逐段问：正在讲的东西看得见吗？画面空不空、挤不挤、像不像幻灯片？镜头有没有抢戏？扫描的每一条提示都要看过，修掉或写明为什么保留。
- 为什么：MyISAM 新版第一轮在扫描、可读时长全部通过后交给策划者看，被接连指出镜头乱动、文字压在字幕条下、光标不闪、画面空荡、像 PPT；全片总览图逐帧复查是在策划者指出之后才做的。
- 怎样查：README「交付」里是否写明全片通看的方式（看视频或总览图）、时间与发现的问题？scan.js 的提示是否逐条有处理？
- 也用于：预览迭代、验收
- 来源：P70、P72、P75、P76、P77、P99（见 反馈记录）
配乐为本片单独设计：先有一层贯穿全片、带低频分量的铺底，再加动机与节奏，随章节发展；稀疏的钢琴或和弦不等于克制。换预设或换音色不算新配乐。音效只给有含义的关键动作，不同动作不同声音；慢移、阅读保持、装饰动作可以无声，不默认配气流声。
- 为什么：配乐太弱、各片配乐与「刷」声同质化，都被直接指出过。
- 怎样查：主混音、无配乐版、仅旁白版连续试听开头、密集段与章间，与近期作品比较；事件数量和响度数值不能代替听感，听不到的如实写明。
- 也用于：验收
- 案例：正面 myisam；反面 innodb、opencart-1-5-admin
- 来源：P3、P27、C2（见 反馈记录）
帧率、时长、响度、峰值、文件名与版本，一律在最终编码的文件上测量后再写进记录；混音 WAV、旧报告和文件名都不能代替。
- 为什么：曾有成片名为 60 帧实为 30 帧，曾有交付记录的峰值与最终文件不符。
- 怎样查：用 ffprobe 与响度测量读取最终 MP4，与 README 的交付记录逐项对照。（工具：finish.js 与 check.js --final 测量最终文件）
- 也用于：发布与反馈
- 案例：反面 openclaw-opencode-v2、innodb