企业官网建设流程全解析

• AI 技能
• 媒体生成

多段落长文案、功能列表、数据快闪、产品走读这类天然多段的提示词，最忌讳被硬塞进一个单镜头里——信息还没读完，动画就已经结束了。本篇指南以仓库中 skills/text-to-lottie/references/chapterization-transition-grammar.md 为核心，系统讲解「何时拆章、每章干什么、章与章之间怎么接缝」，并对照 motion-taste.md 的缓动锚点、SKILL.md 的工作流与 player-contract.md 的验证手段，讲清从「创作前规划」到「逐帧验收」的完整闭环。读完你将能判断提示词该拆成几幕、为每道接缝选择正确的转场类型、在关键帧落笔前写出一份可执行的 Seam Plan，并在官方 Skottie 播放器中用?frame=N逐帧验证接缝两侧的边界帧。

一句话定位：这套语法解决什么问题

当提示词信息密集、天然多段时，本文档（chapterization-transition-grammar）负责三件事的决策：

1. 是否拆分成章节（chapters）；
2. 每个章节承担什么可读职责；
3. 章节之间如何过渡（transition grammar）。

需要特别澄清的是：缓动锚点（Easing Anchors，详见 motion-taste.md 的 "Easing Anchors" 一节）在这里是支撑工具，它们服务于转场，但不是转场本身。一个转场的成立依赖"章节角色 + 时机 + 方向 + 切点 + 遮罩 + 缓动"六要素，缓动只是其中之一——这一点在"接缝机制"一节还会反复强调。

在 SKILL.md 的路由表中，本章节文档被明确指定给这些意图加载：长文本、多概念、列表/特性/步骤、时间线、前后对比、问题/方案、引语+证据、recap/故事、产品走读、多语言变体、多幕多拍序列、跳切/硬切与转场语法。换言之，它是"多拍序列"类任务的主参考，通常与 motion-taste.md 一起读取。

何时拆章（When To Chapter）

当提示词携带不止一个想法时，就应该拆成章节。文档列举的典型触发场景包括：

• 长文本（long text）；
• 多个论断（multiple claims）；
• 功能列表（feature list）；
• 多个统计数据（multiple stats）；
• 时间线（timeline）；
• 前后对比（before/after）；
• 问题/方案（problem/solution）；
• 引语 + 证据（quote+proof）；
• 铺垫/回报（setup/payoff）；
• 产品走读（product walkthrough）；
• recap/社交故事（recap/social story）；
• 多语言或重复内容变体（multi-language / repeating content variations）。

拆章的唯一标准是：一个章节只承载一个可读的想法（one readable idea per chapter）。这与 motion-taste.md 的 Gate 规则完全一致——"如果提示词承载多个想法，就把它们拆成章节，而不是硬塞进一个场景（cramming one scene）"。

何时不拆章（When Not To Chapter）

反过来，单一意图的场景必须保持一个节拍（one beat）并让它落定：

• 单一 Logo 定版（single logo lockup）；
• 单一 CTA；
• 单一图标动画；
• 单一简洁数据卡（one simple stat card）；
• 单个 UI 微交互；
• 法律条款等必须逐字阅读的文本块（legal/read-critical block）；
• 平静的 hero 时刻，其"最终落定"本身就是回报。

这些场景的收尾（settle）就是高潮，拆章反而会削弱它。这一点在 motion-taste.md 中同样有镜像表述："单用途节拍（logo lockup、一个 CTA、一个数字、法律文本、必须落定的平静 hero）保持一个节拍并落地（lands）。"

章节角色（Chapter Roles）

每个章节只承担一个可读职责。文档给出的角色清单：

• hook（钩子）
• setup（铺垫）
• claim（主张）
• proof（证据）
• contrast（对比）
• detail（细节）
• payoff（回报）
• CTA / final lockup（行动号召 / 最终定版）
• loop bridge（循环桥接）

角色决定章内"做什么"，也为后续选择转场提供依据——例如 proof 章倾向于克制、payoff 章适合落定式收尾。它与 motion-taste.md 中的 Reveal Grammar（build → settle → hold）配合使用：每章给主要信息一个 coast/hold 窗口，再接缝。

按意义切分，而非按长度（Split By Meaning, Not Length）

文档明确禁止两种偷懒做法：

1. 一次性整段铺上画面（never place a paragraph at once）；
2. 把长段落机械剁成小段（do not just chop it into smaller paragraph blocks）。

正确姿势是把长文本重写为简短、作者意图明确的节拍（authored beats），或渐进揭示（reveal it progressively），保证"一个章节一个想法"。这意味着拆章工作在文案层面就要发生：删冗余、提炼每章的核心句，而不是把原文原封不动地分配到多个镜头里。

两种结构模式（Structure Modes）

拆章之后，用哪种结构组织这些章节？文档给出两种模式：

• 重复骨架（Repeated armature）：保持相同版式与运动路径，只替换内容。最适合列表、统计数据、多语言、recap、supercut 等"同一模板反复出现"的场景。这类结构天然自带节奏重复（rhythm），因此也最容易支撑 jump cut / hard cut 类转场（见"接缝机制"中关于重复节奏的讨论）。
• 演进式故事版式（Evolving story layout）：对象/文字持续进入新位置，构图随章节演化。最适合产品走读、解释说明、流程展示、setup/payoff 和叙事性运动。

模式选择要在动笔前定，因为它直接影响后续每道接缝的类型选择：重复骨架适合"节拍对节拍"的硬接，演进式版式适合 carry / masked swap 这类连续性转场。

可读窗口（Readable Window）

**每一章的主信息在接缝之前都要有一段 coast、hold 或稳定时刻。**快速转场没有问题，但绝不能以牺牲可读性为代价（Fast transitions are fine, but never at the cost of the read）。

这与 motion-taste.md 的 Reveal Grammar 一脉相承："使用 build, settle, hold 作为默认揭示主轴，hold 是信息或品牌被观众记住的地方"。可读窗口的存在，是"剪在运动中（cut-on-action）"的前提——见下文接缝机制中"任何快速退出前必须先有可读的 coast/hold"。

转场语法（Transition Grammar）：七种接缝

每个接缝选择一种转场类型（pick one per seam）。文档定义的七种转场：

1. hard cut on action（运动中硬切）：焦点运动仍在进行时切入。
2. jump cut（跳切）：跨接缝匹配方向/速度的硬切。
3. motion-masked swap（运动遮罩置换）：出场运动本身变成下一拍的揭示/遮罩。
4. continuous carry（连续携带）：同一对象/文字跨章节旅行到下一位置。
5. occlusion wipe（遮挡扫除）：大型形状盖满画面，再揭开下一章。
6. hold/settle cut（落定切）：仅在节拍必须首先清晰落定时使用。
7. loop reset（循环复位）：节奏有意重复时使用。

七种转场完整对照表

文档给出的这张表是这套语法的核心资产，逐列拆解了"为什么成立""出画末帧""入画首帧""缓动锚点""何时切换"，必须逐格理解：

缓动锚点的配套用法

表内出现的锚点来自 motion-taste.md 的 Easing Anchors 表，全部为 cubic-bezier（x1,y1,x2,y2），描述的是运动行为而非图层类型：

chapterization-transition-grammar.md 强调"缓动锚点是支撑工具，不是转场本身"；motion-taste.md 则从另一侧印证："硬切/跳切/章节转场：出画用exit-accelerate（长距离旅行用travel-cut），在它落定前切断；需要连续性时配合 motion-masked swap"。

在 Lottie JSON 中，一个 cubic-bezier 会按 lottie-spec-map.md 的规则拆到两个关键帧上：起点关键帧的o:{x:[x1],y:[y1]}作为出向手柄，终点关键帧的i:{x:[x2],y:[y2]}作为入向手柄。例如exit-accelerate（1.00,.02,.54,.42）落成关键帧就是：

{ "a": 1, "k": [ { "t": 0, "s": [0], "o": { "x": [1.0], "y": [0.02] } }, { "t": 40, "s": [100], "i": { "x": [0.54], "y": [0.42] } } ] }

依据信息与基调选择转场（message + tone）

文档给出了"内容 → 转场"的映射规则，选型时先看信息再定调：

• 动感列表 / supercut / recap→ 重复骨架 + 运动中的 hard cut / jump cut；
• 叙事 / 产品走读→ continuous carry 或 motion-masked swap；
• 对比或调色板/世界切换→ occlusion wipe 或 hard cut；
• 高级感 / 数据 / 证据→ 克制的遮罩或 hold/settle cut；
• 必须读清楚的内容→ 保持更久；绝不在被理解之前切断；
• 每道接缝都需要一个理由：保持连续性、制造对比、重置节奏、或落定一个观点。不要随机变换转场类型（Do not vary transition types randomly）。

这条"每道接缝必须有理由"的约束，在 motion-taste.md 中同样出现："根据接缝目的——保持连续性、制造对比、重置节奏或落定一个观点——来选择每种转场，而不是随机选择。"

接缝机制（Seam Mechanics）：一个转场不是缓动

文档给出的接缝公式是：

转场 = 章节角色 + 时机 + 方向 + 切点 + 遮罩 + 缓动——不止是缓动；锚点只是支撑。

并给出四条机制铁律：

1. 剪在运动中（cut-on-action）必须在运动进行中切入——绝不能在落定之后切；
2. jump cut 必须匹配方向与感知速度；
3. 任何快速退出前，必须先有一个可读的 coast/hold；
4. 被打断的运动只有在重复节奏下才读作"有意为之"（约 3–4+ 拍的骨架），单次出现会被看作失误。

核心技法：把出画运动"剪在终点之前"

文档强调要创作"剪在运动中"的出画，让自然终点活在可见切点之外：

• 可见章节是更长运动弧线的一个窗口——例如章节在 100 帧结束，但运动本会在约 120–140 帧才收束；
• 接缝在速度仍活跃（often rising）时打断运动，而非在运动落定后；
• 核心规则是主动延续（active continuation），不一定是加速：速度可以是上升的（kinetic exit）、稳定的（匀速平移 pan）、或已经高而稳定（快速物体掠过）——关键在于它尚未落定，若章节被延长，运动会继续。

落到验证上，这意味着：如果在接缝帧上物体已经到达它的最终创作目标，那这就是 settle cut，而不是 cut-on-motion。

创作前的接缝规划（Seam Plan）

文档要求在打关键帧之前，对每道接缝逐项决策：

• chapter role——这一拍做什么；
• readable window——信息在哪里 coast/hold；
• outgoing motion——结尾什么在动（方向 + 速度）；
• transition type——从语法表里选；
• incoming motion——开头什么在动；
• easing anchor——支撑曲线；
• cut/hold frame——精确接缝帧；运动中 vs 静止；
• reason for the seam——连续性 / 对比 / 节奏重置 / 落定观点。

这八项可以整理成一份可直接执行的创作检查单，例如：

Seam 1（hook → claim） - role: hook 引出话题，claim 抛出主张 - readable window: frame 60–72 给 hook 落定 - outgoing: 标题从左向右 pan，速度中等上升 - transition: hard cut on action - incoming: claim 元素以同方向速度入场 - easing: 出 exit-accelerate，入 entrance-sharp - seam frame: 72（运动中切断） - reason: 保持连续性 + 推进节奏

SKILL.md 的工作流同样强调"创作前决策"：路由任务 → 解析目标场景 → 先定背景策略 → 再写lottie.json。Seam Plan 正是这套"先想后写"原则在多层叙事场景中的具体化。

接缝验证（Seam Verification）：逐帧检查两个边界帧

文档要求对每道接缝检查其两侧的边界帧，并给出了按转场类型区分的验收标准：

• cut-on-action / jump cut：出画末帧仍在运动（未落定）；入画首帧方向 + 感知速度匹配。检查出画运动在章节延长时是否会继续——若物体在接缝处到达最终目标，则它是 settle cut 而非 cut-on-motion；
• masked swap / occlusion wipe：不存在"两个章节都未构图"的间隙帧；遮罩/遮挡物在置换处完全遮蔽；
• continuous carry：被携带元素在跨接缝处位置 + 速度匹配，或运动逻辑肉眼可见地连续（相关元素/变换也可接受）；
• hold/settle cut：切前信息可读且静止；
• loop reset：首末帧匹配（位置、颜色、速度），除非复位是刻意的。

在 lottie 仓库中，这套验证可以落到真实工具链上：

1. 逐帧定格：官方播放器支持?frame=<N>定格到任意帧。在 src/context/canvas.tsx 中，路由查询参数frame会被解析并驱动anim.seekFrame(currentFrame())（见 src/context/canvas.tsx），加载即暂停在指定帧。因此接缝两侧边界帧的检查就是http://localhost:<port>/<project>/<scene>?frame=<N>两次导航。新建场景至少检查frame 0、中点和op - 1（player-contract.md "Frame Pinning"）；
2. JSON 校验：op是排他的、ip是包含的（ip: 0, op: 90, fr: 60渲染帧0..89，见 lottie-spec-map.md），因此op - 1才是最后一帧。写入后用 SKILL.md 给出的命令校验：

   node -e "JSON.parse(require('fs').readFileSync('public/projects/<project>/<scene-N>/lottie.json','utf8'))"

3. 确认场景已被官方播放器加载：curl -s http://localhost:<port>/__context返回项目树、活动场景、帧数、fps 与最后修改时间（实现见 vite-plugins/scenes.ts）。该端点也是 Agent 侧"场景是否在线"的观测入口；
4. 补全运动审查：只检查首末帧不够。evals/output-rubric.md 明确要求"拖拽播放（scrub playback）并检查关键节拍帧：帧 0、早期揭示、中点、落定或接近末帧、op - 1、循环接缝（如循环）、以及语义节拍（数字解析、词语落定、logo 定版、图表画完、CTA 出现、镜头运动落定）"——这与 Seam Verification 的"边界帧 + 运动中"检查正好互补。

护栏（Guardrails）

文档最后给出三条不可逾越的护栏：

1. jump/hard cut 需要重复节奏或明确的编辑理由；一个孤立的被打断运动会看起来像失误；
2. cut-on-motion 通常应跨切点匹配方向/速度；
3. 为平静的奢侈/机构化基调、最终 logo 定版、法律文本、以及任何必须落定才能被理解的内容，避免高能章节切。

这三条护栏与"选择转场"一节的基调映射互为表里：能量越高的转场，适用语境越窄；越需要"读清楚"的内容，越要 hold 到位。当场景属于"必须落定"的类型但又被硬切打断时，evals/output-rubric.md 的 Design Judgment Blockers 会直接判失败——"产出能渲染但缺乏清晰焦点""最终帧像偶然停点"都属于完成阻塞项。

落地路径：从规则到成品

把整套语法接入 lottie 仓库的实际工作流：

1. 路由：按 SKILL.md 的意图表，识别"多段 / 多拍 / 章节"类提示词，加载本章节文档与 motion-taste.md，并始终先读 player-contract.md；
2. 规划：按"Seam Plan"八项在关键帧前完成每道接缝的决策，包括可读窗口的精确帧号；
3. 创作：写入public/projects/<project>/<scene-N>/lottie.json（场景文件约定与目标解析规则见 player-contract.md 与 SKILL.md 的 Scene Rules；当前仓库的示例场景位于 public/projects/main-project/scene-1/lottie.json）；
4. 验证：JSON 校验 → 官方 Skottie 播放器（通过npm run dev启动，端口以 Vite 打印为准）→?frame=N逐帧检查每道接缝的两个边界帧与关键节拍帧 → 用 output-rubric.md 的节奏、层级、可读性标准收尾。

整套体系的最终目标与 SKILL.md 的定位一致：产出在官方 Skottie 播放器中**干净渲染、观感有意为之（feels intentional）**的场景——对多拍序列而言，"有意为之"恰恰体现在：该拆的章拆开、每章一个职责、每道接缝都有理由。

• AI 技能
• 媒体生成