@baimingtao/lbs-agent 1.0.0

package/extensions/skills/builtin/creative/manim-video/SKILL.md

@@ -0,0 +1,269 @@
+---
+name: manim-video
+description: "Manim CE 动画：3Blue1Brown 数学/算法视频。"
+version: 1.0.0
+platforms: [linux, macos, windows]
+---
+
+# Manim 视频制作流程
+
+## 何时使用
+
+适用于用户请求：动画讲解、数学动画、概念可视化、算法演 示、技术解析、3Blue1Brown 风格的视频，或任何包含几何/数学内容的程序化动画。使用 Manim 社区 Edition 创建 3Blue1Brown 风格的讲解视频、算法可视化、公式推导、架构图和数据故事。
+
+## 创作标准
+
+这是教育电影。每一帧都在教学。每个动画都在揭示结构。
+
+**在编写任何一行代码之前**，先阐明叙事主线。这纠正了什么误解？“顿悟时刻”是什么？什么样的视觉故事能带领观众从困惑走向理解？用户的提示词只是一个起点——请以教学上的抱负来诠释它。
+
+**几何先于代数。** 先展示形状，再展示公式。视觉记忆的编码速度比符号记忆快。当观众在看到公式之前先看到了几何形态，他们会觉得这个等式是顺理成章的。
+
+**首次渲染的卓越性是不容妥协的。** 输出必须在无需多轮修改的情况下，在视觉上清晰且美学一致。如果某些东西看起来杂乱、节奏糟糕，或者像“AI 生成的幻灯片”，那就是错的。
+
+**透明度分层引导注意力。** 永远不要让所有东西都以全亮度显示。主要元素设为 1.0，上下文元素设为 0.4，结构元素（坐标轴、网格）设为 0.15。大脑会分层处理视觉显著性。
+
+**留白与呼吸空间。** 每个动画之后都需要 `self.wait()`。观众需要时间来消化刚才出现的内容。绝不要匆忙地从一个动画跳到下一个。关键揭示后的 2 秒停顿绝不是浪费。
+
+**连贯的视觉语言。** 所有场景共享一个调色板、一致的字号排版和匹配的动画速度。一个技术上正确但每个场景都使用随机不同颜色的视频，在美学上是失败的。
+
+## 前置条件
+
+运行 `scripts/setup.sh` 以验证所有依赖项。要求：Python 3.10+，Manim 社区 Edition v0.20+（`pip install manim`），LaTeX（Linux 上使用 `texlive-full`，macOS 上使用 `mactex`）和 ffmpeg。参考文档基于 Manim CE v0.20.1 进行了测试。
+
+## 模式
+
+| 模式 | 输入 | 输出 | 参考资料 |
+|------|-------|--------|-----------|
+| **概念讲解** | 主题/概念 | 带有几何直觉的动画讲解 | `references/scene-planning.md` |
+| **公式推导** | 数学表达式 | 逐步的动画证明 | `references/equations.md` |
+| **算法可视化** | 算法描述 | 带有数据结构的逐步执行过程 | `references/graphs-and-data.md` |
+| **数据故事** | 数据/指标 | 动态图表、对比、计数器 | `references/graphs-and-data.md` |
+| **架构图** | 系统描述 | 组件及其连接的构建过程 | `references/mobjects.md` |
+| **论文讲解** | 研究论文 | 关键发现和方法的动画展示 | `references/scene-planning.md` |
+| **3D 可视化** | 3D 概念 | 旋转曲面、参数曲线、空间几何 | `references/camera-and-3d.md` |
+
+## 技术栈
+
+每个项目只需一个 Python 脚本。无需浏览器、无需 Node.js、无需 GPU。
+
+| 层级 | 工具 | 用途 |
+|-------|------|---------|
+| 核心 | Manim Community Edition | 场景渲染、动画引擎 |
+| 数学 | LaTeX (texlive/MiKTeX) | 通过 `MathTex` 渲染公式 |
+| 视频 I/O | ffmpeg | 场景拼接、格式转换、音频混合 |
+| TTS | ElevenLabs / Qwen3-TTS（可选） | 旁白配音 |
+
+## 流程
+
+```
+PLAN --> CODE --> RENDER --> STITCH --> AUDIO (可选) --> REVIEW
+```
+
+1. **PLAN（规划）** — 编写 `plan.md`，包含叙事主线、场景列表、视觉元素、调色板、旁白脚本
+2. **CODE（编码）** — 编写 `script.py`，每个场景对应一个类，每个场景均可独立渲染
+3. **RENDER（渲染）** — 使用 `manim -ql script.py Scene1 Scene2 ...` 渲染草稿，使用 `-qh` 渲染生产版
+4. **STITCH（拼接）** — 使用 ffmpeg 将场景片段拼接为 `final.mp4`
+5. **AUDIO（音频，可选）** — 通过 ffmpeg 添加旁白和/或背景音乐。详见 `references/rendering.md`
+6. **REVIEW（审查）** — 渲染预览静态图，对照计划进行验证并调整
+
+## 项目结构
+
+```
+project-name/
+  plan.md                # 叙事主线，场景拆解
+  script.py              # 所有场景在一个文件中
+  concat.txt             # ffmpeg 场景列表
+  final.mp4              # 拼接后的输出
+  media/                 # 由 Manim 自动生成
+    videos/script/480p15/
+```
+
+## 创作指导
+
+### 调色板
+
+| 调色板 | 背景 (Background) | 主色 (Primary) | 副色 (Secondary) | 强调色 (Accent) | 使用场景 |
+|---------|-----------|---------|-----------|--------|----------|
+| **经典 3B1B** | `#1C1C1C` | `#58C4DD` (蓝色) | `#83C167` (绿色) | `#FFFF00` (黄色) | 通用数学/计算机科学 |
+| **温暖学术风** | `#2D2B55` | `#FF6B6B` | `#FFD93D` | `#6BCB77` | 平易近人、有亲和力 |
+| **赛博科技风** | `#0A0A0A` | `#00F5FF` | `#FF00FF` | `#39FF14` | 系统、架构 |
+| **单色极简风** | `#1A1A2E` | `#EAEAEA` | `#888888` | `#FFFFFF` | 极简主义 |
+
+### 动画速度
+
+| 上下文场景 | run_time | 随后的 self.wait() |
+|---------|----------|-------------------|
+| 标题/片头出现 | 1.5s | 1.0s |
+| 关键公式揭示 | 2.0s | 2.0s |
+| 变形/转换 | 1.5s | 1.5s |
+| 辅助标签 | 0.8s | 0.5s |
+| 淡出清理 | 0.5s | 0.3s |
+| “顿悟时刻”揭示 | 2.5s | 3.0s |
+
+### 字体排版比例
+
+| 角色 | 字体大小 | 用法 |
+|------|-----------|-------|
+| 标题 | 48 | 场景标题、开篇文字 |
+| 标题 | 36 | 场景内的章节标题 |
+| 正文 | 30 | 解释性文本 |
+| 标签 | 24 | 注释、坐标轴标签 |
+| 说明 | 20 | 字幕、附属细则 |
+
+### 字体
+
+**所有文本均使用等宽字体。** Manim 的 Pango 渲染器在任何尺寸下使用比例字体都会导致字距损坏。完整建议请参见 `references/visual-design.md`。
+
+```python
+MONO = "Menlo"  # 在文件顶部定义一次
+
+Text("Fourier Series", font_size=48, font=MONO, weight=BOLD)  # 标题
+Text("n=1: sin(x)", font_size=20, font=MONO)                  # 标签
+MathTex(r"\nabla L")                                            # 数学公式（使用 LaTeX）
+```
+
+为保证可读性，最小 `font_size=18`。
+
+### 场景间的差异化
+
+绝不要对所有场景使用完全相同的配置。对于每个场景：
+- **从调色板中选择不同的主色调**
+- **不同的布局** — 不要总是把所有东西都居中
+- **不同的动画入场方式** — 在 Write、FadeIn、GrowFromCenter、Create 之间交替使用
+- **不同的视觉密度** — 某些场景密集，另一些则稀疏
+
+## 工作流程
+
+### 第一步：规划 (plan.md)
+
+在编写任何代码之前，先写 `plan.md`。详细模板请参见 `references/scene-planning.md`。
+
+### 第二步：编码 (script.py)
+
+每个场景对应一个类。每个场景都能独立渲染。
+
+```python
+from manim import *
+
+BG = "#1C1C1C"
+PRIMARY = "#58C4DD"
+SECONDARY = "#83C167"
+ACCENT = "#FFFF00"
+MONO = "Menlo"
+
+class Scene1_Introduction(Scene):
+    def construct(self):
+        self.camera.background_color = BG
+        title = Text("Why Does This Work?", font_size=48, color=PRIMARY, weight=BOLD, font=MONO)
+        self.add_subcaption("Why does this work?", duration=2)
+        self.play(Write(title), run_time=1.5)
+        self.wait(1.0)
+        self.play(FadeOut(title), run_time=0.5)
+```
+
+核心模式：
+- **为每个动画添加字幕**：在 `self.play()` 中使用 `self.add_subcaption("text", duration=N)` 或 `subcaption="text"`
+- **在文件顶部定义共享的颜色常量**，以保持跨场景的一致性
+- **在每个场景中设置 `self.camera.background_color`**
+- **干净的收尾** — 在场景结束时 FadeOut 所有的 mobjects：`self.play(FadeOut(Group(*self.mobjects)))`
+
+### 第三步：渲染
+
+```bash
+manim -ql script.py Scene1_Introduction Scene2_CoreConcept  # 草稿
+manim -qh script.py Scene1_Introduction Scene2_CoreConcept  # 生产版
+```
+
+### 第四步：拼接
+
+```bash
+cat > concat.txt << 'EOF'
+file 'media/videos/script/480p15/Scene1_Introduction.mp4'
+file 'media/videos/script/480p15/Scene2_CoreConcept.mp4'
+EOF
+ffmpeg -y -f concat -safe 0 -i concat.txt -c copy final.mp4
+```
+
+### 第五步：审查
+
+```bash
+manim -ql --format=png -s script.py Scene2_CoreConcept  # 预览静态图
+```
+
+## 关键实现说明
+
+### LaTeX 使用原始字符串
+```python
+# 错误: MathTex("\frac{1}{2}")
+# 正确:
+MathTex(r"\frac{1}{2}")
+```
+
+### 边缘文本的 buff >= 0.5
+```python
+label.to_edge(DOWN, buff=0.5)  # 绝不要小于 0.5
+```
+
+### 替换文本前先 FadeOut
+```python
+self.play(ReplacementTransform(note1, note2))  # 不要直接在上面 Write(note2)
+```
+
+### 绝不动画化未添加的 Mobjects
+```python
+self.play(Create(circle))  # 必须先添加
+self.play(circle.animate.set_color(RED))  # 然后再动画化
+```
+
+## 性能目标
+
+| 质量 | 分辨率 | FPS | 速度 |
+|---------|-----------|-----|-------|
+| `-ql` (草稿) | 854x480 | 15 | 5-15秒/场景 |
+| `-qm` (中等) | 1280x720 | 30 | 15-60秒/场景 |
+| `-qh` (生产) | 1920x1080 | 60 | 30-120秒/场景 |
+
+始终在 `-ql` 下进行迭代。仅在最终输出时渲染 `-qh`。
+
+## 参考资料
+
+| 文件 | 内容 |
+|------|----------|
+| `references/animations.md` | 核心动画、速率函数、组合、`.animate` 语法、时序模式 |
+| `references/mobjects.md` | 文本、形状、VGroup/Group、定位、样式、自定义 mobjects |
+| `references/visual-design.md` | 12 项设计原则、透明度分层、布局模板、调色板 |
+| `references/equations.md` | Manim 中的 LaTeX、TransformMatchingTex、推导模式 |
+| `references/graphs-and-data.md` | 坐标轴、绘图、BarChart、动态数据、算法可视化 |
+| `references/camera-and-3d.md` | MovingCameraScene、ThreeDScene、3D 曲面、相机控制 |
+| `references/scene-planning.md` | 叙事主线、布局模板、场景转场、规划模板 |
+| `references/rendering.md` | CLI 参考、质量预设、ffmpeg、旁白工作流、GIF 导出 |
+| `references/troubleshooting.md` | LaTeX 错误、动画错误、常见误区、调试 |
+| `references/animation-design-thinking.md` | 何时使用动画与何时展示静态图、解构、节奏、旁白同步 |
+| `references/updaters-and-trackers.md` | ValueTracker、add_updater、always_redraw、基于时间的更新器、模式 |
+| `references/paper-explainer.md` | 将研究论文转化为动画 — 工作流、模板、领域模式 |
+| `references/decorations.md` | SurroundingRectangle、Brace、箭头、DashedLine、Angle、注解生命周期 |
+| `references/production-quality.md` | 编码前、渲染前、渲染后检查清单，空间布局，颜色，节奏 |
+
+---
+
+## 创意发散（仅在用户要求实验性/创意性/独特输出时使用）
+
+如果用户要求采用创意、实验性或非传统的讲解方式，请在设计动画之前选择一种策略并进行推理。
+
+- **SCAMPER 奔驰法** — 当用户希望对标准讲解有全新的视角时
+- **假设反转** — 当用户希望挑战某事物的传统教学方式时
+
+### SCAMPER 转换法
+选取一个标准的数学/技术可视化并进行转换：
+- **替代**：替换标准的视觉隐喻（数轴 → 蜿蜒小径，矩阵 → 城市网格）
+- **组合**：融合两种讲解方式（代数方法 + 几何方法同步进行）
+- **反转**：逆向推导 — 从结果出发，解构至公理
+- **修改**：夸大某个参数以展示其重要性（学习率放大 10 倍，样本量放大 1000 倍）
+- **消除**：移除所有符号 — 纯粹通过动画和空间关系进行讲解
+
+### 假设反转法
+1. 列出该主题可视化方式的“标准”特征（从左到右、2D、离散步骤、形式化符号）
+2. 挑选最根本的假设
+3. 反转它（从右到左推导、将 2D 概念嵌入 3D 空间、用连续变形代替离散步骤、零符号）
+4. 探索这种反转揭示了哪些被标准方法所隐藏的东西

package/extensions/skills/builtin/creative/manim-video/references/animation-design-thinking.md

@@ -0,0 +1,161 @@
+# 动画设计思维
+
+如何决定“动画化什么”以及“如何构建”——在编写任何代码之前。
+
+## 我应该对这个进行动画化吗？
+
+并非所有内容都适合动画化。动态效果会增加认知负荷。糟糕的动画不如优秀的静态图解。
+
+**适合动画化的情况：**
+- 一个过程随时间展开（算法步骤、推导、pipeline 阶段）
+- 空间关系发生变化（变换、变形、旋转）
+- 由部件构建成整体（构建、组装、累积）
+- 对比不同的状态（前后对比、方法 A 与方法 B）
+- 核心重点在于时间维度上的演变（训练曲线、波传播、gradient descent）
+
+**适合静态展示的情况：**
+- 概念可以用单张带标签的图表表示（电路图、解剖图、架构概览）
+- 动态会干扰空间布局的呈现
+- 观看者需要仔细研究（密集的表格、参考图表）
+- 通过一张标注清晰的图，概念已经很直观
+
+**经验法则：** 如果你会用“先 X，然后 Y，然后 Z”来解释它——就把它做成动画。如果你是通过指着一张图的各个部分来解释——就保持静态展示。
+
+## 将概念拆解为动画
+
+### 第一步：先撰写旁白
+
+在编写任何代码之前，先写下旁白会说什么。这决定了：
+- **顺序** —— 哪个概念先出现
+- **时长** —— 每个点分配多长时间
+- **视觉呈现** —— 观看者在听到每句话时必须看到什么
+
+如果旁白说“梯度指向上坡”，那么在这个时间点场景中必须显示一个梯度箭头。如果视觉和音频不匹配，观看者的大脑就会分散注意力，导致两者都没接收到。
+
+### 第二步：识别视觉节拍
+
+“节拍”是指屏幕上发生变化的时刻。在你的旁白中标记出每一个节拍：
+
+```
+"Consider a function f of x."         → [BEAT: axes + curve appear]
+"At this point..."                     → [BEAT: dot appears on curve]
+"...the slope is positive."            → [BEAT: tangent line drawn]
+"So the gradient tells us to go left." → [BEAT: arrow points left, dot moves]
+```
+
+每个节拍对应一次 `self.play()` 调用，或一组小型的同步动画。
+
+### 第三步：为每个节拍选择合适的工具
+
+| 视觉需求 | Manim 实现方法 |
+| ------------- | ---------------- |
+| 对象首次出现 | `Create`, `Write`, `FadeIn`, `GrowFromCenter` |
+| 对象变换为另一个对象 | `Transform`, `ReplacementTransform`, `FadeTransform` |
+| 将注意力引向已有对象 | `Indicate`, `Circumscribe`, `Flash`, `ShowPassingFlash` |
+| 保持持续的关联关系 | `add_updater`, `always_redraw`, `ValueTracker` |
+| 对象离开场景 | `FadeOut`, `Uncreate`, `ShrinkToCenter` |
+| 保持可见的静态背景 | `self.add()` (无动画) |
+
+## 节奏：普遍的错误是太快
+
+### 时间控制规则
+
+| 内容类型 | 最短屏幕停留时间 |
+| ------------- | ---------------------- |
+| 新公式出现 | 2.0s 动画 + 2.0s 停顿 |
+| 新概念标签 | 1.0s 动画 + 1.0s 停顿 |
+| 核心洞察 ("aha moment") | 2.5s 动画 + 3.0s 停顿 |
+| 辅助注释 | 0.8s 动画 + 0.5s 停顿 |
+| 场景转换 (FadeOut all) | 0.5s 动画 + 0.3s 停顿 |
+
+### 留出缓冲空间
+
+每次展示新内容后，都要添加 `self.wait()`。观看者需要时间来：
+1. 阅读新文本
+2. 将其与屏幕上已有的内容联系起来
+3. 对接下来会出现的内容形成预期
+
+**不等待 = 观看者永远跟不上你的节奏。** 当你已经开始变换公式时，他们还在阅读公式本身。
+
+### 变换节奏
+
+单一不变的节奏感觉就像在听枯燥的讲座。请变换节奏：
+- **缓慢铺陈** 适用于核心概念（较长的 run_time，较长的停顿）
+- **快速连续** 适用于辅助细节（较短的 run_time，极少停顿）
+- **戏剧性停顿** 出现在关键揭示之前（在 "aha" 之前额外添加 `self.wait(2.0)`）
+- **快速蒙太奇** 适用于“并且这也适用于 X, Y, Z...”的序列（带有紧密 lag_ratio 的 `LaggedStart`）
+
+## 旁白同步
+
+### “先看后听”原则
+
+视觉元素应该在旁白描述它“之前”稍微提前出现。当观看者看到一个圆出现，然后“接着”听到“考虑一个圆”时，视觉画面已经在他们大脑中为该概念做好了铺垫。反过来——先听到，再看到——会造成困惑，因为他们会在屏幕上寻找尚未出现的东西。
+
+### 实用时间控制
+
+```python
+# 场景时长应与旁白时长匹配。
+# 如果此场景的旁白为 8 秒：
+# 总动画 run_times + 总 self.wait() 次数 = ~8 秒。
+
+# 使用 manim-voiceover 进行自动同步：
+with self.voiceover(text="The gradient points downhill") as tracker:
+    self.play(GrowArrow(gradient_arrow), run_time=tracker.duration)
+```
+
+## 公式拆解策略
+
+### “暗化与揭示”模式
+
+当逐步构建一个复杂的公式时：
+1. 以 `opacity=0.2` 的暗化状态显示完整公式（让观众对最终目标产生预期）
+2. 以完全不透明度高亮第一个项
+3. 解释它
+4. 高亮下一个项，将前一个项暗化至 `0.5`（它现在变成了背景上下文）
+5. 重复此过程，直到整个公式完全高亮
+
+这比从左到右构建要好，因为观看者始终能看到最终目标。
+
+### 项的顺序
+
+按照观看者需要理解的顺序来动画化各项，而不是按照它们在公式中出现的顺序。以 `E = mc²` 为例：
+- 先展示 `E`（我们想知道的事物）
+- 然后是 `m`（输入值）
+- 接着是 `c²`（使其成立的常数）
+- 最后是 `=`（将它们连接起来）
+
+## 架构与 Pipeline 图表
+
+### 方框的粒度
+
+最常见的错误：方框太多。每个方框都是观看者必须追踪的一个概念。五个标注清晰的方框胜过十二个带有缩写的方框。
+
+**原则：** 如果两个连续的方框可以分别被标注为“X”和“处理 X 的输出”，就将它们合并为一个方框。
+
+### 动画策略
+
+从左到右（或从上到下）构建 pipeline，并用箭头将它们连接起来：
+1. 第一个方框单独出现 → 解释它
+2. 箭头从第一个方框延伸至第二个 → “输出结果流入……”
+3. 第二个方框出现 → 解释它
+4. 重复上述过程
+
+然后展示数据流经的过程：沿着箭头使用 `ShowPassingFlash`，或者用一个彩色的点穿过路径。
+
+### 缩放与返回模式
+
+对于复杂系统：
+1. 展示整体概览（所有方框，尺寸较小）
+2. 放大进入其中一个方框（`MovingCameraScene.camera.frame.animate`）
+3. 展开该方框，显示其内部组件
+4. 缩小返回至全景概览
+5. 放大进入下一个方框
+
+## 常见设计误区
+
+1. **所有元素同时进行动画化。** 观看者只能同时追踪 1-2 个并行动画。再多的话什么也记不住。
+2. **缺乏视觉层级。** 如果所有元素都具有相同的透明度/大小/颜色，就没有重点突出了。请使用透明度分层。
+3. **没有上下文的公式。** 孤立出现的公式毫无意义。务必先展示或同时展示其几何/视觉解释。
+4. **忽略了“为什么”。** 只展示变换是“如何”工作的，却不说明“为什么”它很重要。添加一句话/标签来解释其目的。
+5. **全程节奏毫无变化。** 每个动画都是 run_time=1.5，每次等待都是 1.0。请变换时间设置。
+6. **忘记目标受众。** 面向高中生的视频在节奏和复杂性上需要与面向博士生的视频有所不同。请在规划阶段就确定好受众。